HL7 Version 3 is a lingua franca used by healthcare computers to talk to other computers. The name HL7 comes from 'Healthcare' and the top level (Level 7) of the Open Systems Interconnection (OSI) model, which carries the meaning of information exchanged between computer applications. HL7 Version 3 is mainly used in large interoperability projects, such as the NHS Connecting for Health programme in the UK, Health InfoWay in Canada, etc. Version 3 has significant differences from HL7 Version 2, which is mainly used within individual hospitals. Read Introduction to HL7 V3 Books and Guides.
Why is HL7 needed?
A specialised healthcare language is required to avoid the sort of ambiguity that is common in everyday medical English. Computers cannot easily deal with synonyms (saying the same thing using different words) or homonyms (where the same term or phrase means different things depending on context). Furthermore, healthcare data is uniquely complex in scope and structural complexity. Joined-up healthcare is difficult when patients have multiple problems and are being treated by several specialists in different locations.
HL7 and XML
HL7 messages are XML documents, which look somewhat similar to HTML. Each message is a string of text with information enclosed by tags, wrapped in angle brackets. Start tags look like <tag> and end tags look like </tag>. Tags can be qualified by attributes such as <tag attribute="value">. The HL7 tags and attributes are derived from the HL7 Reference Information Model (RIM) and the HL7 Data Types. The structure of each HL7 message is set out in an XML schema, which specifies the tags and attributes needed or allowed in the message, their order and the number of times each may occur, together with annotations describing how each tag shall be used.
The HL7 RIM Reference Information Model
HL7 is a language, and every language has a grammar. The HL7 RIM (Reference Information Model) specifies the grammar of HL7 messages and, specifically, the basic building blocks of the language and their permitted relationships. The RIM is not a model of healthcare, although it is healthcare specific, nor is it a model of any message, although it is used in messages. At first sight the RIM is quite simple. The RIM backbone has just five core classes and a number of permitted relationships between them. In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Each Act may also be related to other Acts, via Act-Relationships. Act, Role and Entity classes also have a number of specialisations. For example, Entity has a specialisation called Living Subject, which itself has a specialisation called Person. Person inherits the attributes of both Entity and Living Subject.
RMIM Refined Message Information Model
HL7 has developed a notation, called Refined Message Information Model (RMIM), which displays the structure of a message as a colour-coded diagram. Most RMIMs can be shown on a single sheet of paper or PowerPoint slide and these RMIM diagrams are used to design messages and to explain what each HL7 message consists of.
Structural Attributes
Structural attributes are used to specify more precisely what each RIM class means when used in a message. For example, Act has a class code and a mood code. The class code states what sort of Act this is, such as an observation, an encounter, or the administration of a drug. Mood is analogous to the tense of a verb. Mood code indicates whether an Act has happened (an event), or is a request for something to happen, or a goal or even a criterion. For example, "weight = 100kg" is an observation event; "measure weight daily" is a request; "reduce weight to 80Kg" is a goal and "if weight is greater than 80Kg" is a criterion.
Attributes and Data Types
The RIM defines a set pre-defined Attributes for each class and these are the only ones allowed in HL7 messages. Each attribute has a specified Data Type. These Attributes and Data Types become tags in HL7 XML messages.
Principles of Health Interoperability HL7 and SNOMED-
Healthcare depends on the two leading standards HL7 and SNOMED CT for functional and semantic interoperability. Tim is one of the most experienced teachers of both HL7 V3 and SNOMED CT.
Message specifications, to do a particular task, use a sub-set of the available RIM Attributes, listing each element used and how many repeats are allowed. This is known as refinement. Each Data Type is constrained to the simplest structure that meets the requirements of the task.
Identifiers and Codes
One common data type is the Instance Identifier, which is used to give unique identity to people, persons, organisations, things and information objects. HL7 uses two main types of code. The first type covers the specialised codes used for structural attributes and are defined by HL7 itself. The second type covers externally defined terms and codes such as SNOMED CT (Clinical Terms).
Scope and Extensibility
HL7 covers the whole scope of healthcare communications in an unambiguous way, using a relatively small set of constructs, which need to be learnt. Healthcare communications are complex and any language needs to accommodate this complexity and also handle future needs.
NOTICE: All of the tools available thru this page are designed to support the development and publication of HL7 Version 3 Messaging standards. These tools carry a license that restricts their use to activities that support the development and implementation of standards by members of HL7 and of the HL7 International Affiliate organizations.
NOTICE:This release was assembled to reflect the tools that should be used for preparing Ballot 2007May. The Tooling Committee will keep these tools stable throughout the period, and will release required updates only in the case that a serious bug affecting users content is found.
Detailed documentation of HL7-supported tools, including their architecture, functions, inter-relationships, strengths and weaknesses. Prepared for Tooling Committee.
Installs a Publication DB and necessary support files. VB code in the Pub DB will invoke WYSIWYG editing of the XML markup using XML Spy Suite 4.4 or 5.0 Supports local publication of domain content. Requires CURRENT RoseTree. User Guide included. Be sure to 'remove' or uninstall the previous version before installing this one.
The previous pubDb release is provided to facilitate migrating data older than PubDb release 201.
The Pub DB Manager is a widget created to facilitate the alignment of artifact status and topic content across PubDbs and Design repositories, and the merger of PubDbs, both across domains and within a domain. Its primary focus is for internal use in publishing HL7 ballots.
The Description Editor is a component of the Pub Db that can be installed separately to support editing of descriptive text for HL7 ballots. Do not install this if RoseTree and/or the PubDb are already on your system. It is installed as part of those packages and a separate installation will cause conflicts. User Guide included.
This Access database holds consolidated data from V3 Ballot Reconciliation Spreadsheets. The data span ballot cycles '2005jan' through '2006may' and include all reconciliation sheets uploaded through 5/15/2006.
The DB includes software for batch import of data from new spreadsheets, and limited documentation on the use of this.
Version 3 Static Model Design & Documentation Tools
Contents: This is an intelligent installer for the HL7 R-MIM design templates for interactive design with Visio 2000 or 2002. These tools do not work with Visio 2003 (See advisory).
This tool requires a Design/RIM Repository (below) and the installation of RoseTree (below) to function. The installer includes instructions for installation and use of these tools. This is the latest "official" release.
May be updated based on data from Committees as CMETs change status. CMETinfo.txt file is used by the RMIM design tools (in Visio) to specify the CMETs that may be included in a design. This file should be downloaded and placed in your Visio "Solutions\HL7" directory if it is more recently released than the Visio RMIM Designer tools
Formal naming in the RMIM designer can be updated independently from the Formal Naming Source file. Installation instructions are on a ReadMe in the archive.
This release of 1/14/2007 does not contain all vocabulary changes approved at Harmonization in November 2006. To meet the needs of TCs that require this daya, there will be a later repository release when these changes are available.
The most recent HL7 Model Repository for capturing message designs. Includes the most recent RIM and Vocabulary. This is updated as additional columns and tables are added to the repository.
Note: Use of this design repository with the RMIM Designer (in Visio) or with other RoseTree-supported applications requires RoseTree Version 3.0.0 or later.
The archive also holds the latest formal naming source file for the RMIM Designer in Visio. This source file can also be downloaded separately.
Contents: This is the most current release of RoseTree, which builds R-MIMs and HMDs for the Version 3 demonstration. This will INSTALL RoseTree.exe on your system, works with the published, R-MIM-enabled repository. It will also install Microsoft's MSXML4 (if this is not already on your machine) to perform XML extracts from Repository. Be sure to 'remove' or uninstall the previous version before installing this one.
The HL7 Model Interchange Format (MIF) defines a series of schemas for XML files that will hold the content of HL7 Version 3 specifications. These files will be the foundation for HL7 Version 3 Tooling in the future when all HL7 supported tools will use MIF-based files as their source of data and will emit MIF-based files as their output. (See tools documentation.)
A subset or replacement of the Generator will be release near the end of January 2007 to support "desktop" publishing of Static Model TableViews. HL7 3 Generator (requires Java Runtime 1.4.2) is a successor to the Schema Generator. It takes XML representations of RIM, Vocabulary, HMDs, etc. and "generates" MIF files, Schemas, Table Views and Excel views. Use of this Generator requires source files distributed separately (see following entry). Extract the files from the ZIP file, preserving the directories. Instructions are in the "HL7 Version 3.htm" file which is installed in "documentation" directory.
Additional source files (Domain HMDs and domain dynamic models) for use with the Generator software.
Source files are posted from a particular ballot cycle. See the release notes on the Gforge downloads to determine which ballot was used for a particular release..
HL7 Australia
-
a very popular introductory book
-
the Study Guide to the above textbook.
-
Healthcare depends on the two leading standards HL7 and SNOMED CT for functional and semantic interoperability. Tim is one of the most experienced teachers of both HL7 V3 and SNOMED CT.
-
an important article from "Health Management Technology"
-
the title says it all...
-
excellent
-
a reader focussing on the formal verification of standards
to
learn the secrets of Health Level 7.
