CDA R3 Right Hand Side of Model Analysis

SDWG page.

CDA R3 requirements for right side of model

• Support for domain models from other committees
• Internal consistency across domains
• Identical XML between HL7 V3 standards
  • May want to consider a different ITS
• Simplicity for implementers
• Limited/Fixed set of CDA Schemas for implementers
• Enter into the architecture at varying degrees of sophistication (levels of CDA)
• Administrative and Financial Data needs to be addressed
• Formalization of best practices established over the past five years.
  • Extension mechanisms
  • Creator and Recipient Roles and Responsibilities
  • Adopt existing extensions
• Extensions need to be “validatable” against schema
  • Support for schema tooling (e.g., binding, API creation, et cetera).
• Bob’s Idea: Take the SDA Approach, build one model that has four choice boxes [one for each backbone class]...
• Ensure that use of components is invariant (e.g., C-METS) for some period of time based on review.
• Expressivity

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.