CDA R3 Right Hand Side of Model Analysis

SDWG page.

CDA R3 Assessment of Right Hand Side of Model

To review the current assessment analysis for various strategies see:"Right hand side assessment"

As part of the CDA R3 Right hand side assessment, Structured Documents conducted a straw poll further narrow the choices for the right had side of the model.

Results of CDA R3 Right Hand Side Straw Poll

CDA R2 Design Principles

The goals of the CDA are:

• Give priority to delivery of patient care.
• Allow cost effective implementation across as wide a spectrum of systems as possible.
• Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
• Promote longevity of all information encoded according to this architecture.
• Enable a wide range of post-exchange processing applications.
• Be compatible with a wide range of document creation applications.
• Promote exchange that is independent of the underlying transfer or storage mechanism.
• Prepare the design reasonably quickly.
• Enable policy-makers to control their own information requirements without extension to this specification.

A number of design principles follow from consideration of the above goals:

• This architecture must be compatible with XML and the HL7 RIM.
• This architecture must be compatible with representations of clinical information arising from other HL7 committees.
• Technical barriers to use of the architecture should be minimized.
• The architecture specifies the representation of instances required for exchange.
• The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
• The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
• Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
• Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
• CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.
• Use open standards.

CDA R3 scope statement

• The scope of the Clinical Document Architecture (CDA) R3 is “clinical documents”.
• Clinical documents meet the requirements of the heuristics defined in CDA R1 and R2.
  • Persistence
  • Stewardship
  • Potential for Authentication
  • Context
  • Wholeness
  • Human readability
• Clinical documents are defined by usage, not the specific content -- depending on usage, a particular type of content may be appropriate for either a clinical document or a message.
• Clinical documents are used for patient care
  • primary usage: related to a patient chart, as a component in a longitudinal record of care
  • secondary usage: information derived from one or more patient charts, e.g., public health, quality, safety, research
    • Note that in secondary usage the subject "patient" may not be a single person, or the subject may not be a patient. The subject may be a population, defined in some fashion such as the population of a hospital ward, etc.
• Out of scope:
  • Usage that does not require implicit or explicit review by clinicians or other professionals
    • Examples: Automatic event-based messages that are part of a workflow
      • encounter management
      • action management (i.e., trigger event driven data exchange)
      • order management
      • care plan management
  • Usage that does not require a canonical readable form
    • Examples: Narrative legal documents
      • business partner agreements
      • financial reports
      • medical literature
  • Updates to documents that do not replace the whole document are out of scope although the standard may provide guidance on how to do that with messaging.

 Note: while these would not be CDA R3 instances, the contents of a CDA R3 instance may contain 
 elements/extracts from and references to these out of scope documents and messages.

CDA R3 requirements for right side of model

• Scope:
  • All CDA R2 requirements continue to be in scope.
  • Approved formal proposals and those proposals already assigned to workplan.
  • CDA R3 project scope statement approved by TSC.
  • Support for those domain models from other committees that are within CDA R3 scope.
  • Support for that portion of the RIM that is within CDA R3 scope.
  • Administrative and Financial Data needs to be addressed
  • Consideration of Common product Model, Public health Model.
  • Adopt existing extensions

• Consistency:
  • Consistency types
    • Between CDA R3 and V3 messages (limited by degree of consistency between message models)
    • Between different CDA R3 implementation guides
    • Between CDA R2 and CDA R3
  • Semantic consistency (at level of RIM class, attribute, relationships, vocab, etc).
    • A machineable back and forth translation between CDA R3 and (in scope portion of) message model for a given domain.
      • --Lmckenzi 23:29, 1 December 2009 (UTC) Not sure what "in scope portion of" means. A prescription in a message should be fully representable in a document without losing *any* semantic content, be it financial or otherwise
  • Does not imply use of identical XML element names.
  • Support for domain (analysis) models from other committees
  • Internal consistency across domains
  • Clear forwards migration path from CDA R2
    • Principles Support
    • Wire format

• Implementation:
  • Enter into the architecture at varying degrees of sophistication (levels of CDA)
  • Simplicity for implementers
    • May differ for different implementers (e.g. folks with single purpose vs. those with broader use case)
  • Limited/Fixed set of CDA -Schemas- Instance formats for implementers
  • Explicit schema validation support for RIM based extensions
  • Support for schema tooling (e.g., binding, API creation, et cetera). (GG: support how?)

• Identical XML between HL7 V3 standards:
  • May want to consider a different ITS

Potential Metrics for decision making

• How much work required on HL7's part to produce?
• Expressivity

Potential Solution Notes

• Right hand side = RIM normative content [1], minus some stuff.
  • Alternative to RIM-based RMIM is Grahame's RIM serialization.
  • Necessitate a new and improved template life cycle management approach that focuses on implementation support.
  • Need a decision making process for determining what gets removed (e.g. act relationship types, class codes, etc).
• Right hand side = Clinical Statement model [2], plus some stuff.
  • Need to show how to add in financial classes.
  • Need to understand ability to create templates based on committee domain models.
• Right hand side = start with CDA R2, and add based on clearly defined requirements and proposals.
  • Calvin's idea: for those RIM portions that aren't clearly in scope, provide an extension mechanism such that they validate against the CDA R3 schema.
• Right hand side = lots and lots of specific clones, obviating the need for (many) templates.