fix(docs): attribute the Referral Note's Medications SHALL to CONF:1198-30923 - #108
Merged
Merged
Conversation
…98-30922 The Medications stamp slice (#107) said a Referral Note built by this package failed CONF:1198-30664. It cannot fail that CONF. 1198-30664 sits in the p-urn-hl7ii-2.16.840.1.113883.10.20.22.1.2-2015-08-01-errors pattern, and the concrete rule extending its abstract rule has context cda:ClinicalDocument[cda:templateId[@root='...22.1.2' and @extension='2015-08-01']], i.e. a CCD. buildCcda({documentType:"referralNote"}) emits ...22.1.1 + ...22.1.14 and never ...22.1.2, so a Referral Note falls outside that rule's context entirely. Its equivalent assert is CONF:1198-30922, in the ...22.1.14 pattern. The substance was right and only the citation was wrong: both asserts are byte-identical in their test XPath, each requiring ...22.2.1.1 at 2014-06-09, and differ only in the rule that selects them. So one fix does correct both document types, and no emitted byte changes here. This is a citation correction, not a behaviour change. The error is the same rule-context misreading that refuted #106 pass 1 -- an assert read without walking to the concrete rule that selects it -- which makes it the third instance in this repo. Reading the assert body is never enough. Corrected in all three copies in one commit, per #82 pass 3's "the durable fix is fewer copies, not more careful copies": the MED_SECTION_EXT docblock in src/builder/build-ccda.ts, the pending changeset, and the agent-notes record. The Referral Note test in test/builder.test.ts now names 1198-30922 as its source, so the correct id has a home next to the behaviour it governs. No new changeset: the wrong id never published. Both changesets are still pending, the registry is at 0.0.13 and CHANGELOG.md contained no copy of it, so the fix lands inside the already-pending patch rather than adding a second entry correcting something no consumer ever saw. Also narrows the "every conformance claim below is read directly off the normative Schematron" vouch in the agent-notes Provenance block, which was one sentence too broad when written: this was the claim it covered but did not cover. An umbrella vouch is only as true as its weakest claim and hides that claim rather than flagging it. Both CONF ids re-verified sentence-unique against the normative artifact (HL7/CDA-ccda-2.1, sha256 04be58046a675735616e46cf52053688a2fc9d0c88010f14fd1c5a2f4ca5bd54, re-fetched byte-identical), each walked from its abstract rule to its concrete context. verify.sh green, 928 tests, agent-notes contract gate green separately since the shared ladder does not run it.
…, not -30922 Self-caught before merge, on top of f907c64 rather than by amending it, because that sha is under a refuter pass. f907c64 replaced a wrong CONF id with another wrong CONF id. Each of these Schematron asserts carries TWO conf ids, and the <sch:assert id> is the COMPONENT requirement, not the section one: This structuredBody SHALL contain exactly one [1..1] component (CONF:1198-30922) such that it SHALL contain exactly one [1..1] Medications Section (entries required) (V2) (identifier: urn:hl7ii:...22.2.1.1:2014-06-09) (CONF:1198-30923). So 1198-30922 is the analogue of the CCD's 1198-30663, and the analogue of 1198-30664 -- the id that actually names this section template -- is 1198-30923. Citing the @id for a section requirement is wrong by exactly one and looks entirely plausible. All four ids re-verified sentence-unique. This is the CLAUDE.md trap "re-check a refuter's spec claim exactly as hard as your own" firing a second time in this repo: pass 2 named 30922, the previous commit adopted it, and it very nearly shipped to four sites again. The general rule, now paid for twice: the assert LABEL is not the sentence. Search for the sentence, require exactly one hit, and read which of its ids names the thing you are citing. Also records the two further document types whose errors/warnings patterns require the same stamp, neither emitted by buildCcda, so they bound the claim rather than widen it: Transfer Summary (...22.1.13, SHALL, section CONF 1198-28278) and Consultation Note (...22.1.4, SHOULD, section CONF 1198-28926). Four asserts require ...22.2.1.1 at 2014-06-09 in total; only the CCD's and the Referral Note's are reachable from this builder. Still no emitted byte changes and still no new changeset: the wrong id never published, so the correction stays inside the already-pending patch. check:agent-notes and check:no-emdash green; builder suite 205 passing.
The bullet cited a placeholder sha that never existed. It is 136d8c7.
NSchatz
changed the title
Written after pass 2 returned NOT REFUTED on 8b469c2, so this delta is disclosed as ungraded. All four changes are prose; none touches code, tests or emitted bytes. Pass 2 minor 1 (INTRODUCED): the correction bullet cited PR #109, which does not exist, and called it "pass 2" without saying whose. It was #107's pass 2 that named the wrong id, and #108 that fixes it. Both corrected. Pass 2 minor 2 (PRE-EXISTING, byte-identical at main so it could not block): the changeset's empty-section paragraph said "A document with no medications ... still fails CONF:1198-30664", but a Referral Note in that state fails 1198-30923, never -30664. Its agent-notes counterpart already said "A CCD", so the two copies disagreed in scope and this one publishes verbatim. Scoped to a CCD and the Referral Note case named alongside it. Pass 1 minor 2: a spliced paragraph seam in the same bullet, where the new block ran into the old text mid-line. Broken into its own paragraph. Pass 2 nit: the docblock and the test comment compressed the rule context to "a ...22.1.2-stamped ClinicalDocument", dropping the @extension='2015-08-01' half of the predicate. Both now name both halves. The conclusion is unchanged, a Referral Note carries neither root, but this saga has been about reading a predicate precisely enough, so the short form is the wrong economy here. check:agent-notes, check:no-emdash and check:no-internal-refs green; builder suite 205 passing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
#107said a Referral Note built by this package failed CONF:1198-30664. It cannot fail that CONF.1198-30664sits in thep-urn-hl7ii-...22.1.2-2015-08-01-errorspattern, and the concrete rule extending itsabstract="true"rule has contextcda:ClinicalDocument[cda:templateId[@root='...22.1.2' and @extension='2015-08-01']], i.e. a CCD.buildCcda({documentType:"referralNote"})emits...22.1.1+...22.1.14and never...22.1.2, so a Referral Note falls outside that rule's context entirely. Its equivalent assert isCONF:1198-30923, in the...22.1.14pattern.🛑 The lesson, self-caught mid-PR
The first commit here (
f907c64) replaced a wrong CONF id with another wrong CONF id, and the second (136d8c7) fixes it. Each of these asserts carries TWO CONF ids, and the<sch:assert id>is the COMPONENT requirement, not the section one:So
1198-30922is the analogue of the CCD's1198-30663; the analogue of1198-30664is1198-30923. Citing the@idfor a section requirement is wrong by exactly one and looks entirely plausible.This is the
CLAUDE.mdtrap "re-check a refuter's spec claim exactly as hard as your own" firing a second time in this repo: the refuter pass named30922, the first commit adopted it, and it nearly shipped to four sites again. The assert LABEL is not the sentence. All four ids re-verified sentence-unique.Why the substance still holds
Only the citation was wrong. The two asserts are byte-identical in their
testXPath, each requiring...22.2.1.1at2014-06-09, and differ only in the rule that selects them. So#107's claim that one fix corrects both document types is true, and no emitted byte changes here.It is also the same rule-context misreading that refuted
#106pass 1, which makes it the third instance in this repo.Scope
Corrected in all copies at once, per
#82pass 3's "the durable fix is fewer copies, not more careful copies": theMED_SECTION_EXTdocblock, the pending changeset, theagent-notes.mdrecord, and the Referral Note test comment.Also recorded: two further document types assert the same stamp and neither is emitted by
buildCcda, so they bound the claim rather than widen it. Transfer Summary (...22.1.13, SHALL, section CONF1198-28278) and Consultation Note (...22.1.4, SHOULD, warnings pattern, section CONF1198-28926). Four asserts require the pair in total; only two are reachable from this builder.No new changeset: the wrong id never published. Both changesets are still pending, the registry is at
0.0.13, andCHANGELOG.mdcontained no copy, so the fix lands inside the already-pending patch rather than adding an entry correcting something no consumer ever saw.Provenance
Verified against the normative artifact (
HL7/CDA-ccda-2.1, sha25604be58046a675735616e46cf52053688a2fc9d0c88010f14fd1c5a2f4ca5bd54, re-fetched byte-identical), each assert walked from itsabstract="true"rule to its concretecontext, and each CONF id checked for exactly one hit.Gates
verify.sh ccdagreen (all 11 ladder steps audited in theran:list), andcheck:agent-notesrun separately since the shared ladder does not run it.