"Level Seven" refers to the highest level of the International Organization for Standardisation (ISO) communications model. This is a model for achieving Open Systems Interconnection (OSI), a way of trying to make lots of different computer programs work together.
In overview, the ISO model for OSI initially divides the world of successful computer communications into seven layers:
The idea is that this model makes standardising data comms easier, because it breaks the task down into smaller pieces. If you can agree on how to standardise each layer, then you will de facto have successfully standardised the whole. And interoperability may become a reality.
This ISO OSI model is not specific to medical informatics - it is a way of thinking about any large IT system with lots of components built by different people. The ISO model tries to address a specific problem: in the real world, many different pieces of software and hardware are manufactured by different companies. These devices could in theory be put together to make a system that is more than the sum of its parts if - and this is a big if - data could be shared between different applications and re-used.
Data sharing, however, is not possible if the different devices make different assumptions about how the data is to be stored or communicated. For example, there may be difficulty sharing data if one application assumes that ALL TEXT DATA WILL BE IN UPPER CASE, another assumes it must all be in lower case and a third application is hAPpy tO rEceiVe a MiXtuRe or (worse) cAn'T EVen TelL tHe DIffEreNce.
Open systems interconnection, therefore, requires that all the assumptions and expectations about data communication are out in the open and known to all system component builders. An important part of this is the openness - manufacturers normally want to keep everything about their products closed and secret, so that nobody can copy their good ideas and also so that you have to buy their other products because only those fit.
The idea behind open systems is that only a very small number of huge supplier companies (MegaCorp) have the resources such that each of them is capable of building and marketing a complete system that does everything. However, there are also many more smaller, faster, leaner and meaner companies (TinyCorps) who have very good component products. But TinyCorp can't get their component products to work with the MegaCorp systems because MegaCorp won't tell them how to plug their little component onto the side of the relevant monolithic software device. In order to get into the market, TinyCorp companies must join forces and give up just enough of their secrecy in order to allow their products to interwork. This means being open, at least to a controlled degree, in order to interconnect your systems: OSI.
For OSI to work it shouldn't really matter exactly which assumptions and choices are made. What matters is that, wherever assumptions have been made, it is known and the nature of the assumptions is documented for all to read. This way, everybody has a chance to either all make the same choices or work around them. However, as shown later in this document through the example of HL7 version 2, having too many choices can still lead to chaos and confusion and not a lot of interconnectivity.
In this spirit - that openness is all that is required, while agreement is optional - the main purpose of the ISO model for OSI is not to fix how particular choices must be made. Instead, it tries to provide a standard and systematic framework for finding and documenting all the important assumptions and choices that do get made. The OSI model provides a detailed methodology for examining and describing a complex IT system - from circuit board voltages, through which communication protocol is used (Novell or TCP/IP ?), to how the data is structured when it is transmitted. By following the ISO model, all the various choices and assumptions can be looked for, found and documented.
So, Level seven in the ISO model addresses the interaction between two software applications. It defines the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.
Health Level Seven, therefore, is an OSI level 7 model of how software applications should interact in the specific domain of healthcare. Confusingly, however, the term HL7 is also used to mean the organisation of people trying to work together to author that model.
The importance of HL7 outside the USA: Impact Assessment in the UKAlthough HL7 is originally a USA-based standards organisation, the decisions it makes are increasingly relevant outside the USA. This is at least partly because a lot of US healthcare IT companies sell their products successfully in countries other that the US. Such IT systems will de facto be HL7 compliant (to meet the requirements of their main market, the USA). This means that if non-US customers already have or later purchase such US-originate systems, then they will probably get HL7 compliance whether they need it or not. Meanwhile, the chances of US system suppliers adding compliance with other standards - such as CEN - just to amuse smaller individual international markets is small. Version 2 of the HL7 standard now has a widely installed base across many countries outside the USA, including Canada, Australia, Japan, New Zealand, Germany, the UK, the Netherlands, Finland, South Africa, Argentina and India. All these named countries have national affiliate organisations to the parent body of HL7. In March 2001, the United Kingdom NHS Information Authority (NHSIA) published a report that sets out what impact HL7 is expected to have on the UK. You can read this here (30 pages) if you are interested. |
Go to the HL7 web site. Follow the 'Resources..HL7 standards' link. This section of the site lists the various standards that HL7 have produced, or are in the process of producing. Make a note of the following:
Now return to the main HL7 page. This time, follow the 'Committees..Special Interest Groups' link. Make a note of the following:
A crude measure of the purpose, and success of the different HL7 versions, was put forward recently by Dan Russler, one of the people at the centre of HL7 and an employee of HBOC, one of the large US system suppliers. He said (roughly):
When two healthcare providers in the USA merge (one buys the other) they often have different computer systems. To make one business IT system, you need to get the two systems working as one system, if possible. Before HL7 version 2, the whole thing was such a mess that it could easily cost more than a million dollars and take forever. With HL7 version 2 it is estimated that it still costs several hundred thousand dollars and takes months. HL7 version 2 is, therefore, better than nothing but far from ideal. We need to do better (because there are a lot of US healthcare organisations merging right now).
The hope is that connecting two HL7 version 3 systems together might only cost a few tens of thousands of dollars and take a few weeks, because trying to work out how to make the data flow will require even fewer experts and less time. This is because a lot more things that were previously variable or optional in version 2 will now be fixed or compulsory in version 3.
HL7 version 2 was released to the world in 1988. Various revisions and improvements were agreed over the years (it is now at version 2.4) and by 1994 HL7 v2 was widely adopted. When system vendors say that their system is already HL7 compliant, they may mean version 2.
However, HL7 version 2 failed to achieve any great degree of OSI. This is widely attributed mainly to the fact that version 2 still allowed too many choices - too much 'optionality'. This allowed all the different system vendors to build a big Tower of Babel. A useful summary of the key limitations of HL7 version 2 is:
HL7 version 3 is the version being worked on now (2001), but it is not yet final. One very important technical difference between version 2 and 3 is that all HL7 mini-standards developed, covering the various interactions between specific application types, will arise from a single common Reference Information Model (RIM). All application messages will comply with a predefined set of requirements known as the Message Development Framework (MDF). The aim is consistent definition of different information objects and their representation in messages. This should allow for easier implementation of the standard as a whole and clearer conformance requirements.
Standards as a battlefield: HL7 as a case studyThe development of HL7 version 3 from version 2 is, perhaps, an interesting illustration of the way standards are influenced by the continuous battle between system suppliers and their customers. HL7 version 2 was marketed as solving the interoperability problem when, in fact, it didn't. There was enough of an illusion of interoperability to persuade the customer to buy, but not enough real interoperability to alter the fact that in reality the customer was more or less locked-in to their system supplier. If you decided you did not like your existing supplier, the fact that their system was HL7 v2 compliant did not mean you could simply throw away their software, buy a different product, plug it in and carry on using all your old data. Meanwhile, other powerful market forces in the USA healthcare system have recently arisen: the move from cost-per-case to capitated care means that suddenly HMOs needed to be contracting to look after a much larger population than previously - ideally at least 1.5 million people per HMO. Any less than this and there is a real risk that rare, but very expensive, illnesses - like random leukaemia clusters on the doorstep - can blow big and unpredictable holes in their finances. With a total population in the USA of 300 million, this means that in risk management terms there is room for only around 200 separate HMOs to be in business without the constant fear of being made bankrupt by random disease events. In fact, at the start of the process, there were originally 8000 different HMOs. Once exposed to this new risk (previously a risk born by the insurance companies rather than the people actually running the hospitals as businesses) the US market of HMOs went through an aggressive round of mergers and acquisitions. The sound of colliding information systems was deafening, and the reality of just how far short HL7 version 2 fell of true interoperability became clear. Plus, there were new information needs not accounted for at all in the old HL7 version. Previously, HMOs only had to worry about recording what had been done after it had already been done, so that they could bill for it (and make a profit). Now they need to know about it before it actually happens, in order to decide whether to do it at all - because profit now comes from doing as little as possible, not as much as possible. The rationalisation of the US health market is far from complete and there are also similar pressures growing in other countries. Having been burned once, and recognising that they need new information systems anyway, the HL7 standards forum has become full of a lot of heat and light aimed at trying to make HL7 interoperability more real. |
The goal of the HL7 organisation is to develop a single, all-encompassing model of the data structures that healthcare applications can exchange. This result is known as the HL7 Reference Information Model. The RIM is usually presented as a UML representation, typically covering an A0 piece of paper in small type.
As an organisation, HL7 addresses the large domain of medicine initially by dividing itself into a number of technical committees and special interest groups. Individuals and companies must subscribe to the HL7 organisation if they want to influence the final form of the HL7 and RIM specification, and they would choose to attend committees or SIGs that interest them.
The subscribers meet three times each year at a location in the USA. Each meeting typically lasts 3 to 5 days. Several hundred people usually attend. The meeting is divided into a number of parallel streams, each typically focussed on a particular class of application or other interest group. An example of an interest group is the vocabulary group, and another is the decision support group.
The cost of standardisation: HL7 as a case studyAlthough HL7 has been active in the US for a long time, the commercial pressures described above have in recent years made it much more important in that country. As a result, much more effort and money is being applied through HL7 than previously and the forum has acquired a new sense of urgency and drive. This reinvigorated HL7 has not escaped the attention of European based standards folk who, ordinarily, would pursue their interests only via CEN or ISO. Many have concluded that they need to become involved in HL7 as well as (or even in place of) CEN - if only to avoid the nightmare scenario of the world being dominated by US-originate healthcare IT systems that don't or can't take into account any of the peculiarities of the European healthcare scene. However, participating in HL7 for a European is an expensive undertaking. To begin with, you have to pay an annual subscription cost (USD$350) just to be allowed to attend. Then, each of the 3 plenary meetings costs a transatlantic flight (USD$700) plus hotel for a week (USD$900), amounting to a total travel cost of USD$5150 annually. However, over and above the travel cost is the labour cost of the delegate, which amounts to three full weeks a year physically at the plenary meetings, plus a week or two around each meeting reading documents. This amounts to 6 weeks labour which, assuming a modest expert's salary, might be an opportunity cost to your regular employer of around USD$7000. So, it costs about USD$12000 annually for each European delegate to attend and participate in HL7. |
The special interest groups try to ensure that the RIM meets their needs. At each working group meeting, the current state of play is presented and new proposals for improvements are discussed.
For a couple of weeks after the main subscribers meeting, many document revisions are circulated by e-mail to the protagonists of each working group. The results of this consultation and argument process are then fed into the RIM harmonisation committee. This is a much smaller group of people than the full HL7 community, and they have a meeting of their own in between the main HL7 meetings. The RIM harmonisation committee takes all the suggestions and requests and issues a new RIM model draft, in UML, just before the next full HL7 meeting. Actually, the final preparation of the new draft is done by one person who everybody else trusts. This is currently a man called Gunther Schadow.
Then the cycle starts again.
Download this 136kb file from the DMI site. It contains two Excel spreadsheets in a single Excel workbook. Both the spreadsheets were originally copied from the HL7 site itself. Open the file.
You should see two different spreadsheets in the Excel workbook, each containing a UML diagram. One is for version 0.99, the other for version 1.02 of the HL7 Reference Information Model. Make a note of:
Now compare the two diagrams. A lot has changed in a short time. Examine the [Person] object in each version of the RIM.
Can you think why, for example, the {credit_rating-cd} attribute was originally included in the earlier version of the RIM but was removed in the later, simpler one ?