Skip to content

chore(deps): bump @cosyte/ccda from 0.0.8 to 0.0.15 - #44

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/cosyte/ccda-0.0.13
Open

chore(deps): bump @cosyte/ccda from 0.0.8 to 0.0.15#44
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/cosyte/ccda-0.0.13

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 11, 2026

Copy link
Copy Markdown

Bumps @cosyte/ccda from 0.0.8 to 0.0.15.

Release notes

Sourced from @​cosyte/ccda's releases.

v0.0.15

What changed

  • PHI scanner: the repository-wide sweep now reads the bytes git carries, as a union with the working-tree walk.
  • Docs: name the real reason the branch-and-merge fixture went red, and drop the reading that said the index came back empty.

Full detail for each change is in CHANGELOG.md.

Install

npm install @cosyte/ccda@0.0.15

npm: https://www.npmjs.com/package/@​cosyte/ccda/v/0.0.15

v0.0.14

What changed

  • Settle the CCD required-section (SHALL) set against the normative C-CDA R2.1 Schematron: it is six sections, and the parser and builder now agree on it.
  • Emit the Medications section under its own 2014-06-09 version stamp, so a CCD built with medications stops failing CONF:1198-30664.

Full detail for each change is in CHANGELOG.md.

Install

npm install @cosyte/ccda@0.0.14

npm: https://www.npmjs.com/package/@​cosyte/ccda/v/0.0.14

v0.0.13

What changed

Internal tooling and CI only. No change to the published package surface.

Install

npm install @cosyte/ccda@0.0.13

npm: https://www.npmjs.com/package/@​cosyte/ccda/v/0.0.13

v0.0.12

What changed

  • Report three plan-surface facts that were previously silent, without changing what the library returns or accepts.
  • Refuse a build whose narrative label is missing, instead of fabricating one.

... (truncated)

Changelog

Sourced from @​cosyte/ccda's changelog.

0.0.15

Patch Changes

  • d3807af: PHI scanner: the repository-wide sweep now reads the bytes git carries, as a union with the working-tree walk.

    pnpm phi-scan with no arguments (the sweep CI runs) enumerated the working tree and nothing else. Where the working tree and the index disagree, the walk was the only voice, so the gate could print OK, no hits and exit 0 over tracked content it never opened. Four such states were reproduced on the previous release, each over a tracked file holding a whole synthetic patient identity: the path occupied by a directory, the path under a name the walk skips wholesale (dist, coverage, .cache and the rest), the working tree missing almost every tracked file, and a submodule whose working tree is absent. No such content existed in this package; the states were reproduced rather than found.

    The sweep now also scans the stage-0 blob of every tracked path whose bytes the walk did not already read. Deduplication is by content rather than by path, so a clean checkout reads nothing twice, and a path whose two copies differ (end-of-line normalization, a scrubbed working copy) has both scanned rather than one standing in for the other. A hit found this way names its locus as <path> (as git carries it).

    Three new refusals, all exit 2. A tracked path git records as a symbolic link or as a submodule carries no content to scan there; an unmerged path has no single merged blob, only two sides and their base, and is refused under its own message; and a sweep cannot run at all when git will not name the index or names it empty. No refusal ever prints a link target.

    The suite now carries a positive control: it copies every tracked file into a throwaway repository, reproduces the clean result over it, and then proves the same sweep fires on that corpus with one synthetic marker planted, once on disk and once reachable only through git. A clean report is a decision, not an absence.

  • 498ef6d: Docs: name the real reason the branch-and-merge fixture went red, and drop the reading that said the index came back empty.

    The note and the test comment covering the unmerged-index case both explained the red CI run as git ls-files -s returning no records for the path at all. That is false. The run's own output reads expected [ Array(1) ] to have a length of 3 but got 1, and the calls above it assert a clean exit on the add and the commits, so a stage-0 record necessarily existed. What actually happened is that the draft handed its git merge no committer identity, so the merge died before it touched the index and left the record the last commit wrote; the premise assertion, written as "not zero means it conflicts", accepted that crash as a conflict. A premise assertion that accepts any non-zero exit accepts a crash.

    No behavior change: the scanner, the fixture and every assertion are untouched.

0.0.14

Patch Changes

  • bdd551e: Settle the CCD required-section (SHALL) set against the normative C-CDA R2.1 Schematron: it is six sections, and the parser and builder now agree on it.

    buildCcda named five SHALL sections for a CCD (including Vital Signs) while requiredSectionKeys("ccd") named four (excluding it). The live consequence was an asymmetry: a built CCD always carried a Vital Signs section, but parseCcda stayed silent when a third-party CCD lacked one. Both halves now name the same six, read off the CCD (V3) errors rule of the normative Schematron published by HL7: Allergies and Intolerances (CONF:1198-30662), Medications (-30664), Problem (-30666), Results (-30670), Social History (-30688) and Vital Signs (-30690). Procedures (-30668) and Plan of Treatment (-30686) sit in that template's warnings rule as SHOULD, so neither is asserted.

    Those six CONF ids are scoped to the R2.1 stamp: the rule they live in matches only a ClinicalDocument whose CCD templateId carries @extension="2015-08-01". So socialHistory and vitalSigns are asserted only against an R2.1-stamped document. An R1.1-origin CCD (the same root with no extension, the condition that raises TEMPLATE_EXTENSION_ABSENT) keeps exactly its previous reading of Allergies, Medications, Problems and Results. That is not a claim that R1.1 omitted the other two; there is no R1.1 Schematron in hand, and narrowing the original four would be as unsourced as broadening them. requiredSectionKeys and missingRequiredSections both take an optional { r21Stamped: false } for the unstamped reading, and the new RequiredSectionOptions type is exported. The stamp is detected the way the Schematron's context predicate is written, existentially: a document is R2.1-scoped when any of its document-level templateIds carries the root together with @extension="2015-08-01", so the common dual-stamped backward-compatible shape (both the extension'd and the bare templateId) is read correctly whatever order the two appear in.

    What changes for you:

    • requiredSectionKeys("ccd") and missingRequiredSections("ccd", ...) now include socialHistory and vitalSigns. An R2.1-stamped CCD that lacks either now raises a REQUIRED_SECTION_MISSING warning it previously did not. This is a warning, never a fatal, so nothing stops parsing. R1.1-origin CCDs are unaffected.
    • buildCcda now always emits a Social History section for a CCD, as a spec-clean empty nullFlavor="NI" shell when no smokingStatus is supplied. That shell is conformant and invents no clinical fact: the Social History Section (V3) requires only code, title and text, and its Smoking Status entry is SHOULD, not SHALL. It has no entries-required template variant, so the shell still carries exactly the template the CCD SHALL constraint names.
    • A CCD that does supply a smokingStatus emits the Social History section exactly once, as before.

    Document types whose SHALL set excludes Social History, such as the Referral Note, are unchanged: they still emit it only when populated.

  • a0fba0a: Emit the Medications section under its own 2014-06-09 version stamp, so a CCD built with medications stops failing CONF:1198-30664.

    The six CCD SHALL sections do not share one version stamp, and the builder assumed they did. Each assert in the normative C-CDA R2.1 Schematron's CCD (V3) errors rule names a @root and an @extension, as a pair. Five are 2015-08-01: Allergies (…22.2.6.1), Problem (…22.2.5.1), Results (…22.2.3.1), Social History (…22.2.17) and Vital Signs (…22.2.4.1). Medications (…22.2.1.1) is 2014-06-09. R2.1 revised that section at the earlier stamp and never re-issued it at the later one: the Schematron carries section rule contexts for both Medications roots (…22.2.1 and …22.2.1.1) at 2014-06-09 and zero rule contexts for either root at 2015-08-01.

    medicationsSection called sectionElement and emptySection without an extension argument, so both took the builder's R21 default and stamped …22.2.1.1 with 2015-08-01. That pair is unsatisfiable by any rule in the IG, so every CCD and every Referral Note this builder produced failed its own document type's Medications assert, populated or empty: a CCD fails CONF:1198-30664, a Referral Note CONF:1198-30923. Both call sites now pass a named MED_SECTION_EXT. The two asserts are byte-identical in their test XPath, both requiring …22.2.1.1 at 2014-06-09, and differ only in the rule context that selects them, the CCD's …22.1.2 against the Referral Note's …22.1.14, so the section template's identity is document-type independent and one fix corrects both; editCcda rebuilds sections through the same function and inherits it.

    This changes the emitted bytes on every document carrying a Medications section, so a consumer keyed on the exact old root + extension pair stops matching. It is not a breaking API change: this package's own parser, sectionForTemplateRoot and the editable-section table all match on the root alone, so parse, edit, section lookup and round-trip are unaffected, and no conformant consumer could have been keyed on a stamp the IG does not define. The parse fixtures and both docs samples that carried the same non-existent stamp were corrected with it, including the quickstart sample that labels itself "Clean, spec-conformant input" while carrying a pair no rule in the IG defines; the serializer snapshot moves by exactly that one attribute, which is the round-trip fidelity check doing its job. Note that the executable docs gate could not have caught either, because section recognition matches the root alone.

    Why a root-only test never caught this: the pre-existing assertion checked for 2.16.840.1.113883.10.20.22.2.1.1 with no stamp, and passed throughout. The new tests assert the pair for all six SHALL sections, and additionally assert the 2015-08-01 pair is absent, so a reverted default reds instead of passing vacuously. Five of the eleven tests touching this are red at the previous commit and six are green there as controls, the five non-Medications SHALL rows plus the round-trip re-parse.

    Scope, stated rather than implied. This closes that one CONF for a populated document. It does not upgrade the package's general conformance claim: nothing in CI validates an emit against the Schematron, so every CONF id this code cites remains mechanically unenforced, and "a built document round-trips with zero warnings" still does not mean "a validator would pass it". A CCD with no medications emits the entries-optional root only, because declaring entries-required with zero entries violates that template's own "SHALL contain at least one entry", so such a document still fails CONF:1198-30664 (a Referral Note in the same state fails CONF:1198-30923, never -30664). That is inherent to having no medications rather than a residue of this change, and it applies equally to Allergies, Problems, Results and Vital Signs.

    What landed for enforcement is a transcription of the six asserts with the source artifact's sha256 recorded next to it, not a Schematron run. A real harness needs an XPath engine, correct sch:extends expansion and first-rule-wins semantics, and the .sch is deliberately not vendored, so it stays its own slice. Getting rule-context semantics wrong inside a harness would be worse than having none: the assert behind this defect sits in an abstract="true" rule that carries no context at all, and reading it without following the concrete rule that extends it is the same misreading that produced the bug.

... (truncated)

Commits
  • 28c8fd8 Version Packages (#112)
  • 498ef6d docs(phi-scan): the branch-and-merge fixture went red on a committer identity...
  • d3807af fix(phi-scan): the all-mode sweep reads the bytes git carries, as a union wit...
  • dbdf84d Version Packages (#109)
  • c10f70d fix(docs): attribute the Referral Note's Medications SHALL to CONF:1198-30923...
  • a0fba0a fix(conformance): stamp the Medications section 2014-06-09, not 2015-08-01 (#...
  • bdd551e fix(conformance): settle the CCD SHALL set at six sections against the normat...
  • 4fb4c9f Version Packages (#104)
  • 89c8ec2 fix(phi-scan): scan the tracked corpus every route used to read past (#103)
  • 941afff docs: relocate eight CLAUDE.md blocks to agent-notes to get under budget, and...
  • Additional commits viewable in compare view

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Aug 11, 2026
Bumps [@cosyte/ccda](https://github.com/cosyte/ccda) from 0.0.8 to 0.0.15.
- [Release notes](https://github.com/cosyte/ccda/releases)
- [Changelog](https://github.com/cosyte/ccda/blob/main/CHANGELOG.md)
- [Commits](cosyte/ccda@v0.0.8...v0.0.15)

---
updated-dependencies:
- dependency-name: "@cosyte/ccda"
  dependency-version: 0.0.13
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot changed the title chore(deps): bump @cosyte/ccda from 0.0.8 to 0.0.13 chore(deps): bump @cosyte/ccda from 0.0.8 to 0.0.15 Aug 29, 2026
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/cosyte/ccda-0.0.13 branch from ba1ef2b to c27e5a6 Compare August 29, 2026 05:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants