This wiki has undergone a migration to Confluence found Here
Difference between revisions of "CDA R3 Right Hand Side of Model Analysis"
Jump to navigation
Jump to search
Line 27: | Line 27: | ||
* 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. | * 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. | * Use open standards. | ||
+ | |||
+ | =CDA R3 scope statement= | ||
+ | |||
+ | * CDA R2 scope | ||
+ | * common clinical documents generated at point of care | ||
+ | * public health reporting | ||
+ | * ... (Liora, Grahame preparing a draft) ... | ||
+ | |||
=CDA R3 requirements for right side of model= | =CDA R3 requirements for right side of model= | ||
Line 32: | Line 40: | ||
* Scope: | * 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 | ** Administrative and Financial Data needs to be addressed | ||
− | + | ** Consideration of Common product Model, Public health Model. | |
− | ** Consideration of Common product Model, Public health Model | + | |
− | * Consistency | + | * 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 | ** Support for domain (analysis) models from other committees | ||
** Internal consistency across domains | ** Internal consistency across domains | ||
Line 48: | Line 67: | ||
** Adopt existing extensions | ** Adopt existing extensions | ||
− | * Implementation | + | * Implementation: |
** Enter into the architecture at varying degrees of sophistication (levels of CDA) | ** Enter into the architecture at varying degrees of sophistication (levels of CDA) | ||
** Simplicity for implementers | ** Simplicity for implementers | ||
Line 55: | Line 74: | ||
** Support for schema tooling (e.g., binding, API creation, et cetera). (GG: support how?) | ** Support for schema tooling (e.g., binding, API creation, et cetera). (GG: support how?) | ||
− | + | * Identical XML between HL7 V3 standards: | |
− | * Identical XML between HL7 V3 standards | ||
** May want to consider a different ITS | ** May want to consider a different ITS | ||
= Potential Metrics for decision making = | = Potential Metrics for decision making = | ||
− | * | + | * How much work required on HL7's part to produce? |
+ | * Expressivity | ||
= Potential Solution Notes = | = Potential Solution Notes = |
Revision as of 22:45, 3 November 2009
SDWG page.
Contents
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
- CDA R2 scope
- common clinical documents generated at point of care
- public health reporting
- ... (Liora, Grahame preparing a draft) ...
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.
- 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
- Consistency types
- Formalization of best practices established over the past five years. (GG: aren't this a general CDA thing? what do they say about RHS?)
- Extension mechanisms
- Creator and Recipient Roles and Responsibilities
- Adopt existing extensions
- Implementation:
- Enter into the architecture at varying degrees of sophistication (levels of CDA)
- Simplicity for implementers
- 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
- 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.