HL7 v3 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.

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	Business Names CMET Substitution Constraint Derivation Context Binding Realm Localization

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 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
Methodology	Shared Reference Model

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.
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	To do

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	Repository-based artifacts Tool-based maintenance/Publication