CDA Suggested Enhancements

NOTE: Membership on this list bestows no special privileges. The list is just a convenient catalog of various comments received along the way. Each of these suggested enhancements will need use case backing, a formal proposal, etc before being considered for CDA Release 3. There is no requirement that an item be on this list to be considered for CDA Release 3. There is no timeline for the balloting of CDA R3.

CDA Suggested Enhancements

• Clarify Relationship between a section and its entries
• Clarify the subject and recordTarget: If the context of a section or entry doesn't explicitly assert a Subject (remembering that the Subject may have been asserted higher up and propagates down through context conduction), one shall infer that the Subject is the RecordTarget.

• CustodianOrganization – why is phone number restricted to just 0..1?

• Add "entry" as allowable classCode for the Organizer clone.

• Remove the need for populating the narrative block (so long as a style sheet is attached)?
  • This sounds nonsensical. STDC should document the statement that "Stylesheets shall never carry any semantics, as the use of stylesheets by the receiver is optional". Rene spronk 23:54, 16 Aug 2006 (CDT)

• ParentDocument.code should be changed from CD to CE.

• ID/IDREF and getting narrative block into datatypes - change outbound references to point to Act ID's rather than XML ID's, and deprecate the XML ID additions to the CDA schema.
  • Requires extension of datatypes R2, a proposal has been made.
• Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.

• Compare CDA constraints against those in implementation guides (e.g. CRS and CCD as a US realm example) to see where CDA itself can be more constrained.

• Review common extensions used in implementation guides (e.g. CRS and CCD as a US realm example) as potential enhancements to CDA.
  • Look at the various uses of header's Participant in implementation guides (e.g. CRS and CCD as a US realm example), and see which should be further broken out as specific participants and/or that we have the necessary components.

• Allow for associations to be NULL with a particular null flavor (use of nillable attribute). (There are cases where the cardinality is optional, but you want to explicitly nill something with a null flavor)

• Define a canonical extension mechanism to use components of the Clinical Statement model that aren't part of the current CDA standard

• Add nonXMLBody/id

• For all vocabulary, list the Vocabulary Domain (along with coding strength, and OID), Value Set

• Clinical Statement Comparison / reconciliation

• Medical Records header Comparison / reconciliation

• Family history representation – compare / reconcile with Genomics family history representation

• All enumerated CNE domains should be x-domains (value sets) - eg. OrganizationPartOf.statusCode

• ServiceEvent vs. EncompassingEncounter - ordering provider - we have referrer on the encounter, but perhaps we need the ordering provider on the service event instead - this would cover ordering a test, or ordering a referral. or on Order for the ordering provider?

• Add entryRelationship.priorityCode

• Where we've constrainted CE to CS (ROI.code, languageCode) - consider changing to CE (per M&M recommendations that came out subsequent to release of CDA R2)

• Section-level authentication (? or possibly even more fine-grained – e.g. ICU flow sheet example)

• Digital signatures / digital rights management

• Consider use of ClinicalDocument.text rather than nonXMLBody, renaming NonXMLBody, and/or deprecating nonXMLBody.

• Review the differences in header Performer vs. body Performer to see if they should be reconciled. (e.g. Header Performed has a functionCode, whereas body Performer has a modeCode).

• The participations identified in the header do not correspond to the signature roles defined in ASTM E1762. Consider the implications of non-harmonization, and perhaps provide a mapping. ASTM E1762 includes a list of roles for participations. DICOM is considering the use of these by the security group. Consider comparison / gap analysis for CDA, R3 and bring back to committee (e.g. to review with Security committee)
  • Note: As long as the harmonization is universal in nature (and does not lead to US Realm sprcific constraints spilling over into the CDA architecture)

• Per paul - should not include xsi:schemaLocation in examples.

• How does document succession impact contained acts? For instance, in the case of a replacement document, one can use the RPLC relationship on a revised Act, so we could comment on this. In the case of a repudiation, all contained acts are impacted. [From Rene: I think that at least there should be some kind of warning or implementation guidance within the CDA standard. This need not be elaborate, but it could describe that those parties that extract data from CDA documents should consider the context of that data. The detailed rules may be as agreed upon at the affinity domain level. So I don't envision the CDA making normative statements about the application behaviour (HL7 shies away from that kind of statement anyway), but I expect it to remind users of the standard that this pitfall/implementation issue should be addressed - somehow. The exact policies have to be defined and agreed upon within or between organizations.]

• In addition to saying that, for instance, Doctor X is the legalAuthenticator, there is a need to show that Doctor X is co-signing on behalf of the author and/or one of the authenticators.

• From Rick Geimer: Allow coded entries for nonXMLBody. Will also need to provide some guidance for when this is/is not appropriate (using PDF in a negotiated exchange would be ok, but sending Quark Express files in a blind exchange would not).

• From Rick Geimer: Create clones of the <value/> element (inside an observation) that are pre-bound to specific datatypes, i.e. <physicalQuantity/> would be pre-defined as a PQ. This avoids the hack of having to use xsi:type every time you have a value, which is awkward at best, and unworkable in some tools. It may also limit the use of alternate schema languages to validate CDA documents (I don't belive RelaxNG understands xsi:type). I do not suggest removing the ability to do use xsi:type, just don't make it mandatory for all cases.

  In the following observation:
     <observation classCode="OBS" moodCode="EVN">
         
         <statusCode code="completed"/>
         <effectiveTime value="200004071430"/>
         <value xsi:type="PQ" value="1.77" unit="m"/>
     </observation>
  you could replace
     <value xsi:type="PQ" value="1.77" unit="m"/>
  with
     <physicalQuantity value="1.77" unit="m"/>
     
  This would make authoring a lot easier (no need to refer to the datatypes spec 
  for each observation), and would make it possible to use tools that do not 
  support the use of xsi:type to redefine datatypes.

  For more reasons why the use of xsi:type is often frowned upon, refer to Norm's 
  blog entry on the subject: 
  http://norman.walsh.name/2004/01/29/trainwreck.
  After speaking with Dr. Dolin and others, it seems likely that making this 
  change will require input from M&M and probably a change to the XML ITS as well. 

• From Rick Geimer: Consider allowing a true subset of XHTML for the narrative block (in the XHTML namespace), and only use specific elements in the HL7 namespace when absolutely necessary. This will make rendering CDA documents very simple.

• From Rick Geimer: Allow multiple race/ethnicity entries.

• From Rick Geimer: Simplify referencing external files. Seems like you have to jump through hoops just to link to a GIF. Maybe allow renderMultiMedia to reference a URL directly. Currently you need to do something like the following (some required markup removed):

  <text>Erythematous rash, palmar surface, left index finger.
      <renderMultiMedia referencedObject="MM1"/>
  </text>
  <entry>
      <observationMedia classCode="OBS" moodCode="EVN">
          <value mediaType="image/gif">
              <reference value="lefthand.gif"/>
          </value>
      </observationMedia>
  </entry>
  While I can see the value in when you need to provide a lot of detail about an 
  image, it actually makes it impossible to reference images in a level 1 or 
  level 2 CDA document, unless I have missed something. So I propose this as an 
  alternative.
   <renderMultiMedia mediaType="image/gif" value="lefthand.gif"/>
   ... or if we decide to allow XHTML in the body:
   <xhtml:img src="lefthand.gif"/> 
  The downside is that this provides yet another way to reference external data 
  in a CDA. 
  

• From Rick Geimer: Should we make custodian mandatory vs. required?