This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

CDA R3 Allow embedding external structured message structures as Entries

From HL7Wiki
Jump to navigation Jump to search

Return to SDTC page; Return to CDA R3 Formal Proposals page.

Submitted by: Lloyd McKenzie Revision date: <<Revision Date>>
Submitted date: 2009-02-17 Change request ID: <<Change Request ID>>


The HL7 community is broken into a large number of work groups each of which focus on standards development supporting a particular clinical domain. These work groups have significant domain expertise in their respective clinical domains and represent this knowledge in constructing the RMIMs and other static models representing their domain content.

These static models can be leveraged by implementations using a "messaging" or "services" approach to communication. Unfortunately, there's no mechanism to directly leverage these static models when pursuing a "document" approach to communication. This prevents the full expertise of the HL7 organization from being appropriately applied when using documents. It also tends to result in the design process being independently repeated when communicating equivalent content using documents. This distinct design process tends to result in models that are not fully equivalent and sometimes are not even mappable.


  • Allow message types defined by other committees to be "wrapped" within a CDA entry. (I.e. treat one of the entry choices as a "stub")
  • Allow semantic content encompassing multiple "sections" to be encompassed in a single "entry", with the document then listing the sections (and rendered content) then referencing to locations within the entry via X-path or other mechanisms


This would allow the semantic content of an instance to be sent identically in both a messaging and a document approach. This ensures consistent representation of content and that data structures for a given clinical domain are represented consistently regardless of communication mode. It also means that the design of the "organization/presentation" of a document can be handled separately from the design of the semantic content itself. Multiple documents definitions could be designed that reference the same clinical message type.


  • This proposal pre-supposes acceptance of the CDA R3 Support full RIM content proposal, as incorporation of external content may mean stepping outside the bounds of clinical statement. Though I suppose you could do "clinical statement + stub" to allow either an externally defined 'standard' message structure as well as any locally defined content that is consistent with clinical statement.
  • It won't always be possible for a section to reference a location within an existing entry based on "id". For example, if the Entry is a prescription message as defined by the pharmacy group, it might be desirable to have distinct sections for the core prescription, dosage instructions, dispensing instructions, related observations, indication for therapy, etc. Not all of these areas will have a distinct id. Because sections might be created for all sorts of reasons, we can't expect the domain committees to assert id attributes all over the place to allow for easy section referencing. Possible solutions include:
    • Referencing elements within an Entry by some x-path like solution (a la X-forms)
    • Defining some sort of ITS solution that allows embedding reference ids on the fly independent of what's in the referenced message type.

Recommended Action Items


Feb 23, 2010 SDWG. This is subsumed by adoption of right hand side of model being essentially RIM content. There is no requirement in CDA that entries must all be in the same section as the corresponding narrative. No action necessary. All CDA documents will conform to a single XML schema (as a necessary, but not sufficient conformance criteria). We reject the notion of simply plugging another model onto the right hand side of the model if this means that there is not a single CDA schema. opposed: 0; abstain: 0; in favor: 9.