CDA Suggested Enhancements

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 - TO BE ADDED TO WORKPLAN

• [ADD TO WORKPLAN] 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)

• [ADD TO WORKPLAN] 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.

• [ADD TO WORKPLAN (make them consistent)]ParentDocument.code should be changed from CD to CE.

• [ADD TO WORKPLAN] Review general header constraints template

• [ADD TO WORKPLAN] Add nonXMLBody/id

• [ADD TO WORKPLAN] For all vocabulary, list the Concept Domain, coding strength, OIDs, Value Set, static/dynamic, etc.

• [ADD TO WORKPLAN] 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).

• [ADD TO WORKPLAN] All enumerated CNE domains should be x-domains (value sets) - eg. OrganizationPartOf.statusCode

• [ADD TO WORKPLAN] Add entryRelationship.priorityNumber

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

• [ADD TO WORKPLAN] Review the differences in header Performer vs. body Performer to see if they should be reconciled. (e.g. Header Performed has a functionCode (attending, participating...) , whereas body Performer has a modeCode (electronically, etc.) ).

• [ADD TO WORKPLAN] [SEE in conjuction with [open proposal]http://wiki.hl7.org/index.php?title=CDA_R3_Proposal_-_Append%2C_Edit%2C_Correct_Enhancements] 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.]

• [ADD TO WORK PLAN] How does region of interest work for vector graphics? (Currently expressed only as pixels, not scalable for DICOM or vector graphics.)

• [ADD TO WORK PLAN] Add support for GOL/RSK and GOAL/RISK to the entries. User:Kboone (Will be addressed through adoption of Clinical Statement &/or the RIM)

• [ADD TO WORK PLAN] 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 In theory, every data type should carry a null (inherited from ANY). Review in light of data types 2.

• [ADD TO WORK PLAN] 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.

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

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

• [ADD TO WORK PLAN - will be addressed as part of model bake off] remove constraint typeCode <= ActRelationshipEntryRelationship on entryRelationship to allow for all typeCodes in order to support richer semantics -- Frank Oemig 16 July 2009

• [ADD TO WORKPLAN] Use the human identifier pattern consistently thoughout CDA (see MnM hot topic on design patterns) --Grahamegrieve 06:00, 27 May 2009 (UTC)

• [ADD TO WORKPLAN] from Doug Pratt September 10, 2009: Work with other committees (including OO and Patient Care) to develop a common generic model constraint mechanism that yields the same content representation for messages and documents.

• [ADD TO WORKPLAN] In the case of multiple preconditions, are they to be AND'd or OR'd?

CDA Suggested Enhancements - FORMAL PROPOSAL NEEDED

• [FORMAL PROPOSAL NEEDED] 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.
• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] CustodianOrganization – why is phone number restricted to just 0..1?

• [FORMAL PROPOSAL NEEDED (may be subsumed by other CDA model and RIM harmonization changes)] Add "entry" as allowable classCode for the Organizer clone.

• [FORMAL PROPOSAL NEEDED] Remove the need for populating the narrative block (so long as a style sheet is attached)?

• [FORMAL PROPOSAL NEEDED] 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.
• [FORMAL PROPOSAL NEEDED] Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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?

• [FORMAL PROPOSAL NEEDED] Section-level authentication (? or possibly even more fine-grained – e.g. ICU flow sheet example, reference lab)

• [FORMAL PROPOSAL NEEDED] Digital signatures / digital rights management (applies to signature.txt on participations; add as optional)

• [FORMAL PROPOSAL NEEDED] Consider use of ClinicalDocument.text rather than nonXMLBody, renaming NonXMLBody, and/or deprecating nonXMLBody.(Rick should review in terms of the outstanding proposal for nonXMLBody.)

• [FORMAL PROPOSAL NEEDED] 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 specific constraints spilling over into the CDA architecture)

• [FORMAL PROPOSAL NEEDED] Per Paul - should not include xsi:schemaLocation in examples.

• [FORMAL PROPOSAL NEEDED] 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. (Appears to be covered by current participants.)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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
  

• [FORMAL PROPOSAL NEEDED] Should we make custodian mandatory vs. required? User:Rgeimer (We need to revisit the custodian role outside the core usage for exchange of information between providers.)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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). (First issue, however, is more general and requires RIM harmonization proposal.)

• [FORMAL PROPOSAL NEEDED: OUT OF SCOPE FOR CDA R3] Develop a Plan of Care structured document

• [FORMAL PROPOSAL NEEDED] Allow an informant to also be an information system. (Are considering this for author and other roles.)

• [FORMAL PROPOSAL NEEDED: OUT OF SCOPE FOR CDA R3] 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.

• [FORMAL PROPOSAL NEEDED] Review IHE profile for sending lab results in CDA to identify additional CDA R3 requirements. (Consider in light of harmonization Laboratory Result, Release 1.)
• [FORMAL PROPOSAL NEEDED] Provide guidance for image annotations.

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] Fixed font support for the narrative block

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED]

- 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)

• [FORMAL PROPOSAL NEEDED] make explicit that negationInd defaults to false, including in the schema.--GrahameGrieve 08:58, 20 June 2008 (UTC)
• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] list APND and RPLC as on allowable combination in the restrictions of relatedDocument typeCode

• [FORMAL PROPOSAL NEEDED] 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:

[FORMAL PROPOSAL NEEDED] 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)

[FORMAL PROPOSAL NEEDED] 2) Consent-based document/record access control

[FORMAL PROPOSAL NEEDED] 3) Expansion of confidentiality code - mechanics/specification of control AND applicability at attribute level

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] support multi-language support across different sections with links to the same entries -- Frank Oemig 16 July 2009

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] from Helmut Koenig September 4, 2009: Add order participations for service event(s) to allow for conveying information on referring/ordering physicians.

• [FORMAL PROPOSAL NEEDED] from Helmut Koenig September 4, 2009: Introduce "preliminary flag" (suggested values: "preliminary", "final") for CDA documents. DICOM CP 931 specifies that label for DICOM SR reports and it would be beneficial to align the standards.

CDA Suggested Enhancements - FORMAL PROPOSAL PRESENT

• [FORMAL PROPOSAL PRESENT]
  • 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.

• [FORMAL PROPOSAL PRESENT] 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)

• [FORMAL PROPOSAL PRESENT] Allow multiple race/ethnicity entries. User:Rgeimer - Added as CDA R3 Formal Proposals.

• [FORMAL PROPOSAL PRESENT] 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

• [FORMAL PROPOSAL PRESENT - "CDA R3 Proposal - Append, Edit, Correct Enhancements"] 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

• [FORMAL PROPOSAL PRESENT] 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