CDA Suggested Enhancements

Return to SDWG page.

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.

The initial ballot of CDA R3 is planned for September 2009. See also CDA R3 Formal Proposals, which contains formal proposals that have been reviewed and voted on by committee.

CDA Suggested Enhancements

• Masahura Obayashi, Nagayo-RHIE CDA implementation project (Japan): request that section.code be of datatype CD instead of CE. This because of a requirement to add a qualifier to the code. The underlying use-case is related to the measurement of 'mobility scores' at various points in time within the context of a stroke rehabilitation clinical pathway. There are multiple 'mobility score' sections within one single document, (according to protocol) 1 month after the stroke, 3 months after the stroke, etc. These time intervals are coded and would serve as qualifiers of the section.code.
• Introduce "Level 4" to identify Entries that are linked (by means of content ID) to the section text. A level 4 document is a level 3 document *with content links*. Rene spronk 08:13, 21 April 2008 (CDT)
• Rewrite section on backwards compatibility. Bring in line with overall v3 compatibility rules, document that the safe (semantic) option is to only map the human readable parts. Rene spronk 11:44, 18 January 2008 (CST)

• 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)
  • See Stylesheet Semantics for full discussion (a summary of an e-mail exchange) of this topic.
  • See Clarify Stylesheet Semantics for the formal CDA R3 proposal related to this issue.

• 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

• Reconcile with existing models, to include:
  • Clinical Statement
  • Medical Records header
  • Family history representation / Clinical Genomics model
  • Pharmacy (e.g. use of CAGNT (to match REPC_RM000021UV), ADMM (to match REPC_RM000021UV), MAT (to match REPC_RM000021UV). (Modify model so that one can be allergic to other than manufactured materials; Enable the ability to indicate dose form and concentration in separate fields).
  • Patient Care
  • Lab (e.g. requiring effectiveTime for lab results, add code attribute to SpecimenRole / compare with specimen CMET, age/sex conditions for reference ranges).

• 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.

• 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). User:Rgeimer

• 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. User:Rgeimer

• • This is a bad idea. There is just one attribute. Pre-coordinating the name of the attribute with the type will mean the creation of unnecessary choice code when the type difference is not important. There will also be a profusion of names for different types - and it pretty much does exclude use of xsi:type - after all, if you create a physicalQuantity alternative, it will only be useful if no one can use <value xsi:type="PQ" anymore. Mr Norman Walsh may not like xsi:type, but he is silent on whether he thinks polymorphism is a bad idea or not. You'd still need to refer the datatypes spec for each observation, since that's what provides the definitions. --GrahameGrieve 16:48, 12 February 2008 (CST)
• 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. User:Rgeimer
  • Sounds like a good idea at face value, but I'm not so sure it's a good idea. As well as being a constraint on XHTML functionality, narrative block also extends it and subtly redefines the notion of a document. So I don't see that it would really make any difference to implementers. Running a transform is pretty simple...--GrahameGrieve 16:48, 12 February 2008 (CST)

• Allow multiple race/ethnicity entries. User:Rgeimer - Added as CDA R3 Formal Proposals.

• 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.  User:Rgeimer
  

• Should we make custodian mandatory vs. required? User:Rgeimer

• Clarify Relationship between a section and its entries. Narrative block issues: Resolve DRIV ambiguity (what does it mean with respect to the target of the OriginalText reference); Clarify if the target of a reference into the narrative block can be ID's other than those in the <content> tag; What if the narrative is rendered based on the displayName of the code - why would you use the originalText to point; Clarify if other than originalText can point to <content>; Conformance wording for when such referencing should be used; Do we need an extension to the ANY datatype that would allow any attribute to reference originalText? (e.g. do we need to reference from effectiveTime)

• How does region of interest work for vector graphics?

• language code: Be sure not to overly constrain RFC-3066 (e.g. see Harry's ballot comment on CCD, row 6 in the Jan 2007 ballot reconciliation package)

• Confidentiality codes: Work with CBCC (Community Based Collaborative Care) on consent and confidentiality code extensions for x_BasicConfidentialityKind. We potentially need the confidentialty code attribute at the entry level. May need to increase the cardinality of the confidentialty code attribute (across the board for CDA).

• Develop a Plan of Care structured document

• Allow an informant to also be an information system.

• Would like to have a common definition of advance directive – esp between ASTM, HL7, NUBC (contact: Bob Davis), and Public Health Data Standards Consortium (contact: Bob Davis) for future implementation guides that reference advance directives.

• Add support for GOL/RSK and GOAL/RISK to the entries. User:Kboone

• Review IHE profile for sending lab results in CDA to identify additional CDA R3 requirements.

• Add a nullFlavor attribute for section/text to provide a way to identify that no information was provided for a section that might otherwise be required. Using section/@nullFlavor is not appropriate, because then the section could not have a code to identify what kind of section had no information. User:Rgeimer

• Provide guidance for image annotations.

• From Lcerulli: CDA R3 should bridge the gap between clinical and administrative content. Clinical Documents often contains also Financial or Administrative infromation that are part of the document itself (money paid by patient, exemptions, ..etc). Structured classes already exist in HL7 domains so the CDA R3 should provide a way of incorparating or referencing this kind of classes wrapped in the same CDA R3 architecture or if not possible in a brand new administrative document architecture that can be cross referenced. User:Lcerulli

• We have the use case that we have more than 1 legally responsible authenticator. Suggest to change the cardinality of <legalAuthenticator> from 0..1 to 0..* User:kheitmann

• Allow multiple telecom values for custodian. Right now there is no way to add a phone number and email address for a custodian. User:Rgeimer

• Add a means to capture the reason for why a document was replaced with a new version. Ideally this would consist of a code and a text description. User:Rgeimer

• Fixed font support for the narrative block

• Representation of subject participant in the case of no family history should be reviewed in CDA R3. Representation of a statement about a group (e.g. grandparents lived into their 90s) should be clarified.

• Create RIM proposal to add a ProfileId attribute (with semantics equal to Message.profileId) to the ClinicalDocument class. NHS uses a workaround in its CDA documents to achieve the purpose of a profileId. Rene spronk 10:51, 23 November 2007 (CST). See Add ProfileId to ClinicalDocument for formal CDA R3 proposal.

• The use of text.reference and code.reference should be included in the examples in the standard to help clarify that code / originalText should only be referencing the narrative block when the narrative block contains original text.

• clarify whether nested tables and footnotes are allowed in the narrative block--GrahameGrieve 17:06, 12 February 2008 (CST)

• allow for alignment to applied to paragraphs. Otherwise people have to invent 1*1 tables simply to get paragraph alignment.--GrahameGrieve 17:06, 12 February 2008 (CST)

• remove align=justify from the table alignment properties - it's a paragraph alignment aspect--GrahameGrieve 17:06, 12 February 2008 (CST)

• clarify how setting a span on a colGroup makes sense --GrahameGrieve 17:13, 12 February 2008 (CST)

• make explicit that negationInd defaults to false, including in the schema.--GrahameGrieve 08:58, 20 June 2008 (UTC)

• adopt Data types R2 (should be done as a R2.1 release!)--GrahameGrieve 08:58, 20 June 2008 (UTC)

• add participation.uncertaintyCode (requires RIM harmonization proposal) for cases where the act is certain, but a participation is not. --GrahameGrieve 08:59, 20 June 2008 (UTC)

• list APND and RPLC as on allowable combination in the restrictions of relatedDocument typeCode

• from ServiceDeliveryLocation, add an IDENT RoleLink to a new role AccreditedEntity, with a scoper Entity of the accrediting organization. This allows the document to support conveying accreditations, as requested by the American College of Cardiology for imaging lab reports. -- Harry Solomon, 20 January 2009

• from Gary Dickinson Feb 18, 2009: Here are several items for CDAr3 consideration:

• remove constraint typeCode <= ActRelationshipEntryRelationship on entryRelationship to allow for all typeCodes in order to support richer semantics -- Frank Oemig 16 July 2009

• introduce support for further document relationship in header (this way one can see that e.g. a lab report has been used in a discharge summary without interpreting all level 3 entries) -- Frank Oemig 16 July 2009

1) Items discovered and unresolved when the EHR and SD WGs co-developed the "Implementation Guide for CDAr2 - Reference Profile for EHR Interoperability DSTU" (passed ballot in Jan 2008). This IG focuses on how CDAr2 can be used as the common unit of record for the EHR, based on EHR record requirements specified in the HL7 EHR Interoperability and Lifecycle Models (EHR/IM and EHR/LM).

1a) Non-patient specific documents/records (EHR/IM 3.6.2) 1b) Device/network location (address) of document/record origination or amendment (EHR/IM 3.13) 1c) Access control for document/record origination/amendment (EHR/IM 3.18.2) 1d) Audit entry/trail tracking document/record access/use (EHR/IM 3.19.3) 1e) Audit entry/trail tracking document/record transmittal/disclosure (EHR/IM 3.19.5) 1f) Audit entry/trail tracking document/record receipt (EHR/IM 3.19.6) 1g) Audit entry/trail tracking document/record de-identification or aliasing (EHR/IM 3.19.7) 1h) Audit entry/trail tracking document/record deprecation (EHR/LM 11.11)

2) Consent-based document/record access control

3) Expansion of confidentiality code - mechanics/specification of control AND applicability at attribute level

• from Dan Russler Feb 18, 2009: One issue that has come up in Quality Reporting is the need for structured documents describing the nature and content of patient education and counseling delivered, e.g. stop smoking education and counseling; medication-taking education and counseling; surgical risk education and counseling, etc. Observations on patient understanding of the education also needs to be included. Pt signature on receiving the education and counseling should be supported. Note, that this signature requirement is different from collecting a patient consent signature. These patient education-related activities should be considered within the context of CDA R3 Entry level requirements.
• Need a header for patient's registered/normal General Practitioner (PCP, lots of names all round the world). Has been mapped as Primary Information Recipient, but this is not right. Can be done using functionCode on participation on service event, but only when the service event is the right kind of service event. See also CCD 3.17 --Grahamegrieve 05:37, 27 May 2009 (UTC)
  • For formal CDA R3 proposal see: Extend CDA R3 Header with supprt for GP/PCP
• Use the human identifier pattern consistently thoughout CDA (see MnM hot topic on design patterns) --Grahamegrieve 06:00, 27 May 2009 (UTC)