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 49: | Line 49: | ||
** usage that does not require implicit or explicit review by clinicians or other professionals | ** usage that does not require implicit or explicit review by clinicians or other professionals | ||
*** ''Examples:'' Automatic event-based messages or documents | *** ''Examples:'' Automatic event-based messages or documents | ||
− | + | **** 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 | ** usage that does not require a canonical readable form | ||
*** ''Examples:'' Narrative legal documents | *** ''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. | *** 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. | ** 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. |
Revision as of 17:36, 20 January 2010
SDWG page.
Contents
CDA R3 Assessment of Right Hand Side of Model
To review the current assessment analysis for various strategies see:"Right hand side assessment"
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 or documents
- encounter management
- action management (i.e., trigger event driven data exchange)
- order management
- care plan management
- Examples: Automatic event-based messages or documents
- 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.
- Examples: Narrative legal documents
- 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.
- usage that does not require implicit or explicit review by clinicians or other professionals
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
- 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
- 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.