This wiki has undergone a migration to Confluence found Here

Difference between revisions of "HL7 v3 Requirements"

From HL7Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page and its descendant links are an attempt to define the functional and non-functional requirements HL7 has for its standards development methodology, as well as how the methodology meets those requirements and how the requirements are manifested in HL7's metamodel, the [[MIF]].
+
{{V3 Methodology Requirements}}
 
+
These are high-level HL7 requirements identified by HL7 for the v3 methodology, based on past experience, industry best practice or brought forward by the HL7 membership.
The requirements are broken into several sections.  The first describes the requirement.  Following each requirement is a list of supporting rationale.  I.e. "Why is this a requirement".  Finally, there's up to two additional sections:
 
 
 
* a list of how the requirement is implemented in the methodology.  The methodology section explains the mechanism(s) that support that requirement within the HL7 v3 standards development methodology. Each methodology reference is a link to a separate tab that describes the methodology.  Each methodological approach may have its own set of requirements that are driven by the methodological approach
 
* a list of MIF data elements that 'implement' the requirement in HL7's v3 metamodel
 
 
 
 
 
==High-level HL7 V3 requirements==
 
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
Line 21: Line 14:
 
| '' Methodology''  
 
| '' Methodology''  
 
|
 
|
 +
*[[Requirements-Business Names|Business Names]]
 +
*[[Requirements-CMET Substitution|CMET Substitution]]
 +
*[[Requirements-Constraint Derivation|Constraint Derivation]]
 +
*[[Requirements-Context Binding|Context Binding]]
 
*[[Requirements-Realm Localization|Realm Localization]]
 
*[[Requirements-Realm Localization|Realm Localization]]
*[[Requirements-Constraint Derivation|Constraint Derivation]]
 
*[[Requirements-CMET Substitution|CMET Substitution]]
 
*[[Requirements-Vocabulary Binding|Vocabulary Binding]]
 
 
|}
 
|}
  
Line 32: Line 26:
 
| HL7 v3 standards must provide both functional and semantic and interoperability.
 
| HL7 v3 standards must provide both functional and semantic and interoperability.
  
I.e. HL7 v3 specifications must standardize both the data structures and mechanics of information exchange as well as the understanding of what that data means and how it is to be used.
+
I.e. HL7 v3 specifications must standardize both the data structures and mechanics of information exchange as well as the understanding of what that data means, how and when it is to be exchanged and how it is to be used.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
Line 38: Line 32:
 
*In order for shared information to be safely usable, shared understanding of the meaning of the data is essential
 
*In order for shared information to be safely usable, shared understanding of the meaning of the data is essential
 
*Semantic interoperability was often "weak" in HL7 v2, leading to incompatible implementation
 
*Semantic interoperability was often "weak" in HL7 v2, leading to incompatible implementation
 +
*Knowledge of data structures alone isn't sufficient for safe interoperability.  Without agreement on how and when data is to be exchanged and what the responsibilities of the sender and recipient are, clinical and business processes cannot be safely executed.
 
|-
 
|-
 
| '' Methodology''  
 
| '' Methodology''  
 
|  
 
|  
 
*[[Requirements-Shared Reference Model|Shared Reference Model]]
 
*[[Requirements-Shared Reference Model|Shared Reference Model]]
 +
*[[Requirements-Static Model|Static Models]]
 +
*[[Requirements-Dynamic Model|Dynamic Model]]
 
|}
 
|}
  
Line 47: Line 44:
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
| HL7 v3 standards should, as much as possible, be independent of an particular implementation technology and should be capable of making use of particular implementation technologies in a standardized way.
+
| HL7 v3 standards should, as much as possible, be independent of any particular implementation technology and should be capable of making use of particular implementation technologies in a standardized way.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
Line 53: Line 50:
 
|-
 
|-
 
| '' Methodology''  
 
| '' Methodology''  
| To do
+
| [[Requirements-Implementation Technology Specification|Implementation Technology Specification]]
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| HL7 v3 specifications should be authored and maintained in a manner that ensures and automates, as much as possible, that published artifacts are consistent with the HL7 methodology
 +
|-
 +
| ''Rationale''
 +
|
 +
* If we don't follow the methodology, then we are likely to fail to achieve some or all of the requirements that the methodology is intended to support
 +
* The methodology is complex and lack of automated support would make it too time-consuming to follow and too vulnerable to errors
 +
* With a volunteer resource base, it's essential to make the standards development process as automated as possible
 +
|-
 +
| '' Methodology''
 +
|
 +
* [[Requirements-Repository-based artifacts|Repository-based artifacts]]
 +
* [[Requirements-Tool-based maintenance/Publication|Tool-based maintenance/Publication]]
 +
|}
 +
 
 +
 
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| HL7 v3 specifications and artifacts must capture basic metadata such as names, identifiers, attribution, legal constraints, etc.
 +
|-
 +
| ''Rationale''
 +
| HL7 specifications are effectively "documents" that need to be searched and interpreted like any other.  That means knowing things like the title for the artifact, the identifier for the artifact, who is responsible for it, whether it's been superseded, etc.
 +
|-
 +
| '' Methodology''
 +
| [[Requirements-Metadata|Metadata]]
 
|}
 
|}

Latest revision as of 02:43, 11 November 2009

These are high-level HL7 requirements identified by HL7 for the v3 methodology, based on past experience, industry best practice or brought forward by the HL7 membership.

Requirement HL7 standards must be usable in diverse healthcare environments communities throughout the world in circumstances where global consensus down to the detailed 'implementable' level is not (yet) feasible.
Rationale
  • HL7 is international in scope with affiliates from over 30 countries from 6 continents
  • There are variations in healthcare across countries, cultures, medical discipline (e.g. internal medicine vs. psychiatry), type of patient (e.g. human vs. veterinary or pediatric vs. geriatric)
Methodology


Requirement HL7 v3 standards must provide both functional and semantic and interoperability.

I.e. HL7 v3 specifications must standardize both the data structures and mechanics of information exchange as well as the understanding of what that data means, how and when it is to be exchanged and how it is to be used.

Rationale
  • In order for shared information to be safely usable, shared understanding of the meaning of the data is essential
  • Semantic interoperability was often "weak" in HL7 v2, leading to incompatible implementation
  • Knowledge of data structures alone isn't sufficient for safe interoperability. Without agreement on how and when data is to be exchanged and what the responsibilities of the sender and recipient are, clinical and business processes cannot be safely executed.
Methodology


Requirement HL7 v3 standards should, as much as possible, be independent of any particular implementation technology and should be capable of making use of particular implementation technologies in a standardized way.
Rationale With HL7 v2, the organization experienced the challenges associated with a specification that was too tightly bound to a particular implementation technology. One of the objectives for HL7 v3 was to be technology independent.
Methodology Implementation Technology Specification


Requirement HL7 v3 specifications should be authored and maintained in a manner that ensures and automates, as much as possible, that published artifacts are consistent with the HL7 methodology
Rationale
  • If we don't follow the methodology, then we are likely to fail to achieve some or all of the requirements that the methodology is intended to support
  • The methodology is complex and lack of automated support would make it too time-consuming to follow and too vulnerable to errors
  • With a volunteer resource base, it's essential to make the standards development process as automated as possible
Methodology


Requirement HL7 v3 specifications and artifacts must capture basic metadata such as names, identifiers, attribution, legal constraints, etc.
Rationale HL7 specifications are effectively "documents" that need to be searched and interpreted like any other. That means knowing things like the title for the artifact, the identifier for the artifact, who is responsible for it, whether it's been superseded, etc.
Methodology Metadata