CDA R3 Right Hand Side of Model Analysis

SDWG page.

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
  • usage that does not require a canonical readable form
  • examples:
    • legal documents
      • business partner agreements
      • contracts
      • financial reports
      • medical literature
      • etc.
    • administrative documents and messages
      • ADT
    • action management (i.e., trigger event driven data exchange)
      • order management
      • care plan management
    • 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.
  • 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

• Take the SDA Approach, build one model that has four choice boxes [one for each backbone class]...
• 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.
• Ensure that use of components is invariant (e.g., C-METS) for some period of time based on review.