hl7 / cda-core-2.0 Goto Github PK

A handful of fields that were embedded in their parent have a type of "Element" - this introduces FHIR's id and extension fields which we don't want in CDA.

Ultimately, most of these should actually be their own profiles; e.g. in the following picture from SubstanceAdministration, consumable and subject should just be profiles based on the CDA Consumable and Subject class.

Some V3 Acts have an id element inside, e.g:

• ClinicalDocument.id [1..1]
• SubstanceAdministration.id [0..*]

This V3 Acts are represented as Logical Models in FHIR. Logical Models have a base of "Element" or another logical model. The base content of the FHIR Element has already an id and an extension element, which have different datatypes (string) and defined cardinality.

This leads to the following problems:

• SubstanceAdministration.id: illegal constrained type http://hl7.org/fhir/cda/StructureDefinition/II from string in http://hl7.org/fhir/StructureDefinition/Element
• Element SubstanceAdministration.id: derived max (*) cannot be greater than base max (1)

A related problem occurs with the II datatype which has an extension attribute which conflicts with the extensions defined in Element.

• The title of the pages. Currently is "Australian Based Implementation Guide". Would like it to be "Clinical Document Architecture (CDA) 2.0".
• Would like to change the navbar to have "Models" and "Data Types" separately.
• Would like some custom pages to include narrative guidance from the CDA spec.

CCDA Validator if failing for the CCD with sdtc:functionCode tag inside performer tag.

Example for Care Teams XML from repo.

Care Teams Sample XML generated with MDHT library.

CCDA Validation is passing only when sdtc:functionCode is the first child of perfomer tag and fails if it is not the first child of performer tag.

The following CCD passes Validation.

The following CCD fails Validation.

Can someone provide solution how to address the issue of positioning functionCode tag while using MDHT library ?

These are all single-instance types, so may not be as urgent to create

See
https://jira.hl7.org/browse/CDA-20765

All profiles have a "Detail Descriptions" and "Mappings" tab.
Suggest fixing "Detailed Descriptions" tab so that it shows the descriptions of the elements, extra constraints (invariants), etc.
Suggest removing the "Mappings" tab entirely... Don't think we will be defining many mappings for the core CDA spec.
Suggest removing the JSON and Turtle tab, as I don't think we want to encourage CDA documents in JSON format. That's not how CDA is intended, by any stretch.

In the Patient class, there are two elements with the same name raceCode. One is from the core CDA namespace, and the other is from the SDTC namespace.

<element id="Patient.raceCode">
  <path value="Patient.raceCode"/>
  <min value="0"/>
  <max value="1"/>
  <type>
    <code value="http://hl7.org/fhir/cda/StructureDefinition/CE"/>
  </type>
  <binding>
    <strength value="extensible"/>
    <valueSet value="http://terminology.hl7.org/ValueSet/v3-Race"/>
  </binding>
</element>
<element id="Patient.raceCode">
  <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-namespace">
    <valueUri value="urn:hl7-org:sdtc"/>
  </extension>
  <path value="Patient.raceCode"/>
  <min value="0"/>
  <max value="*"/>
  <short value="sdtc:raceCode" />
  <type>
    <code value="http://hl7.org/fhir/cda/StructureDefinition/CE"/>
  </type>
  <binding>
    <strength value="extensible"/>
    <valueSet value="http://terminology.hl7.org/ValueSet/v3-Race"/>
  </binding>
</element>

When profiling Patient, the snapshot generator does not recognize the difference between cda:raceCode vs. sdtc:raceCode, even though the elementdefinition-namespace extension is added to the profile'd element.

<element id="ClinicalDocument.recordTarget.patientRole.patient.raceCode">
    <path value="ClinicalDocument.recordTarget.patientRole.patient.raceCode"/>
    <short value="raceCode"/>
    <definition value="This patient SHALL contain exactly one [1..1] raceCode, which SHALL be selected from ValueSet Race Category Excluding Nulls urn:oid:2.16.840.1.113883.3.2074.1.1.3 DYNAMIC (CONF:1198-5322)."/>
    <min value="1"/>
    <max value="1"/>
    <binding>
        <strength value="required"/>
        <valueSet value="https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.3.2074.1.1.3"/>
    </binding>
</element>
<!--element id="ClinicalDocument.recordTarget.patientRole.patient.raceCode">
    <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-namespace">
        <valueUri value="urn:hl7-org:sdtc"/>
    </extension>
    <path value="ClinicalDocument.recordTarget.patientRole.patient.raceCode"/>
    <label value="The sdtc:raceCode is only used to record additional values when the patient has indicated multiple races or additional race detail beyond the five categories required for Meaningful Use Stage 2. The prefix sdtc: SHALL be bound to the namespace “urn:hl7-org:sdtc”. The use of the namespace provides a necessary extension to CDA R2 for the use of the additional raceCode elements."/>
    <short value="The sdtc:raceCode is only used to record additional values when the patient has indicated multiple races or additional race detail beyond the five categories required for Meaningful Use Stage 2. The prefix sdtc: SHALL be bound to the namespace “urn:hl7-org:sdtc”. The use of the namespace provides a necessary extension to CDA R2 for the use of the additional raceCode elements."/>
    <definition value="This patient MAY contain zero or more [0..*] sdtc:raceCode, which SHALL be selected from ValueSet Race Value Set urn:oid:2.16.840.1.113883.1.11.14914 DYNAMIC (CONF:1198-7263)."/>
    <min value="0"/>
    <max value="*"/>
    <constraint>
        <key value="1198-31347"/>
        <severity value="error"/>
        <human value="If sdtc:raceCode is present, then the patient **SHALL** contain [1..1] raceCode (CONF:1198-31347)."/>
    </constraint>
    <binding>
        <strength value="required"/>
        <valueSet value="https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.1.11.14914"/>
    </binding>
</element-->

The Address CDA Type AD has a usablePeriod element. The useablePeriod can have multiple types, therefore the element ID should have an [x] in the element id value like in the path value.

<element id="AD.useablePeriod[x]">
  <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-defaulttype">
    <valueString value="SXPR_TS"/>
  </extension>
  <path value="AD.useablePeriod[x]"/>

With the current definition igpublisher hangs, see HL7/fhir-ig-publisher#36.

No other choices in the spec end in [x], so it would be best to make this consistent. (Alternatively; add the [x] to all of the others to match FHIR, but simpler seems easier at this point)

AD.useablePeriod

SubstanceAdministration.effectiveTime

Observation.value

The data type of each of the elements in the profiles is the full URL. When clicking the only the link/url, it goes to a page that doesn't exist.

Instead of showing:

It should show:

(where the link in "Type" is a valid link that goes to the desired profile - StructuredBody, in this case)

In cda-ccda-2.2, the "Goal Observation" profile references itself... Ex: A goal can have sub-goals.

        <element id="Observation.entryRelationship:entryRelationship2.observation">
            <path value="Observation.entryRelationship.observation"/>
            <short value="observation"/>
            <definition value="SHALL contain exactly one [1..1] Goal Observation (identifier: urn:oid:2.16.840.1.113883.10.20.22.4.121) (CONF:1098-32880)."/>
            <min value="1"/>
            <max value="1"/>
            <!--
                TODO: this recursive profile is not supported right now 
            <type>
                <code value="http://hl7.org/fhir/cda/StructureDefinition/Observation"/>
                <profile value="http://hl7.org/fhir/cda/ccda/StructureDefinition/2.16.840.1.113883.10.20.22.4.121"/>
            </type>
            -->
        </element>

Currently, the IG Publisher fails to generate a snapshot when a profile references itself, saying the snapshot could not be generated.

The cda-ccda-2.2 repo has this commented out, all you need to do to reproduce the issue is uncomment the above lines in the 2.16.840.1.113883.10.20.22.4.121 structure definition.

Hi,
We have singed some CDA following HL7 Digital Signatures and Delegation of Rights, Release 1.

Once CDA signed we try to validated output CDA document using CDA_SDTC.xsd but we get the following error.
Invalid content was found starting with element '{"urn:hl7-org:v3":digitalSignature}'. One of '{"urn:hl7-org:v3":reference, "urn:hl7-org:v3":thumbnail, WC[##other:"urn:hl7-org:v3",""]}' is expected.
We have validated some CDAR2_IG_DIGITALSIG_DSTU_R1_2014OCT samples against CDA_SDTC.xsd and we get the same message.

After reviewing extensions schemas we guess the issues comes form this:

• HL7 ED datatype has the following modification:
  <!-- Begin Schema Fix: Added to fix Schema to allow XML/XHTML content in ED data type --> <xs:any minOccurs="0" namespace="##other" processContents="skip" /> <!-- End Schema Fix: Added to fix Schema to allow XML/XHTML content in ED data type -->
• So it means signature element must be in another namespace different from urn:hl7-org:v3
• But CDAR2_IG_DIGITALSIG_DSTU_R1_2014OCT signature element is defined as follow:
  <sdtc:signatureTEXT mediaType=”text/xml” representation=”B64”> <thumbnail mediaType=”text/plain” representation = “TXT”> Text representation of the signature (see Section 3.3.2) </thumbnail> <digitalSignature> <authorizedSigner> XAdES-X-L signature of Authorized Signer </authorizedSigner> </digitalSignature> </sdtc:signatureText>

Where digitalSignature is in namesapce urn:hl7-org:v3

Our question is, is there any issue at CDAR2_IG_DIGITALSIG_DSTU_R1_2014OCT documentation or at CDA_SDTC.xsd extension

Thank you