CDA R3 Split Semantics and Rendering

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

See CDA R3 Formal Proposals for instructions on using this form. Failure to adhere to these instructions may result in delays. Editing of formal proposals is restricted to the submitter and SDTC co-chairs. Other changes will be undone. Comments can be captured in the associated discussion page.

Submitted by: Lloyd McKenzie	Revision date: <<Revision Date>>
Submitted date: 2009/09/20	Change request ID: <<Change Request ID>>

Issue

The CDA model presently combines two aspects of a document in an intermingled fashion:

• The "semantic" information - the acts, relationships and other information that express the clinical or other information in a computationally interpretable manner; and
• The "rendering" information - the organization of information into a hierarchy of labeled sections and subsections with renderable text

This creates several issues:

1. The semantic information must be broken up across the different sections, resulting in the loss of the semantic relationships between data spread across sections or the need to embed and traverse 'reference' links scattered throughout the semantic portion of the model to re-constitute the full semantic picture
2. The need to break information down into sections is a significant barrier to the use of standardized models to represent semantic information. "Standard" models created by domain committees for prescriptions, lab results, patient summaries, etc. do not need section or subsection information for computer interoperability and therefore do not include it. The lack of such information prohibits the direct re-use of these models within CDA specifications.
3. Intermingling semantic and rendering information results in the need for a profusion of document specifications. Even if there is a consensus on the appropriate "semantic" modeling for a particular structure, there can be variations in how that data is organized for human presentation. For example, should a document have a single section for all "health conditions", or should allergies and intolerances be split out into their own section? Should allergies and intolerances be split? How about drug vs. non-drug? Severe vs. moderate? Depending on the use-case, any of these degrees of granularity could be appropriate. However, the need to support each one results in a need to re-duplicate the full semantic structure, re-organized according to the way the data is to be rendered. Similar differences might be made for documents intended for exploration on small-display or mobile devices vs. full-size computers
4. A given document can only be rendered in one manner. If you want to allow multiple renderings, you need to send multiple documents
5. Within the marked-up text of a document, there's no direct linkage to the semantic data. You need to trust that the rendered results and the data in the discrete elements are actually the same
6. There's no way to exchange "definitional" document structures that provide a mechanism for capturing or rendering a standardized set of information

Recommendation

Adopt a convention similar to that used by the XForms standard to conveying data within a CDA document. XForms separates the description of the data portion of a form (model) from the rendering portion of a form (control). Linkages between the two (bindings) are achieved using XPath where each element in the rendering portion of the form references the XPath of the data it needs to render.

Rationale

Sections and sub-sections are arbitrary categorizers for human readability. Unless the sole content of a section is human readable text, the sections and subsections do not add any semantics. They simply organize the existing data in a manner appropriate for human consumability. This is a useful feature but should be seen as distinct from encoding the information for computational interoperability, decision support and analysis. Regardless of how a set of health condition and allergy information might be broken down across sections and sub-sections, it does not change the semantic meaning of the information.

Splitting the structure that divides the presentation of information into labeled sections and subsections with rendered text from the semantic data being expressed in those sections in no way changes the overall capabilities of the document. In fact, the capabilities are enhanced:

• A single document could be sent with multiple sets of "rendering" instructions, either for different devices or for different types of practitioners.
• The 'text' portion of a sub-section could include direct XPath references to the data to be exposed, increasing confidence that the rendered data and computer-interpreted data are in sync (because the data is only being sent in one place).

Splitting the model and the rendering information also allows division of labor and helps manage the "standardization" process. You can separate arguments about "what information is needed and how does it relate?" from arguments about "how is this data best presented to clinicians".

In addition, this would create a platform for potential expansion of scope for structured documents where specifications could be created not only for the sharing of data but for defining common structures for the capturing of data. Obviously this would be beyond the scope of CDA R3, but would still fall within the overall mandate of Structured Documents if they wanted to go there and there would be an architectural consistency between defining the capture structures and defining the instances to be shared.

Most importantly, separating semantic and presentation structures allows easy re-use of clinical domain structures within CDA documents. An RMIM produced by Pharmacy or Lab or Clinical Genomics can easily be leveraged for use in a clinical document by defining a simple structure of labeled sections and sub-sections with XPath references to the portions of the clinical domain model appropriate to each section.

Resolution

March 30, 2010 SDWG: [1] RIM graph vs. narrative: Agree to clarify that RIM graphs can be separate from the narrative content in the sections. [2] RIM graph SHOULD|SHALL be separate from narrative: While we'd like to get rid of optionality, we don't yet know how [1] will be modeled, so will revisit this one at that time. opposed: 0; abstain: 0; approve 8. [3] Ability to have multiple narratives for a given RIM graph: Use cases aren't clear. Defer on this one for now. There is a need to definitively know the attested content. opposed: 0; abstain: 0; approve: 8.