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
Revision as of 19:20, 17 February 2009 by Lmckenzi (talk | contribs) (New page: {{CDA R3 Open Proposals}} Return to SDTC page; Return to CDA R3 Formal Proposals page. {|width=100% cellspacing=0 cellp...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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>>

Issue

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.

Recommendation

  • 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

Rationale

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.

Discussion

  • 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

Resolution

(Resolution is to be recorded here and in the referenced minutes, which are the authoritative source of resolution).