 |
Tim Benson |
Standards guru Tim Benson argues that understanding health interoperability, HL7 and SNOMED CT will become increasingly important in this taster of his new book.
When we look back over seven years of the National Programme for IT in the NHS, one of the greatest disappointments has been the failure of NHS Connecting for Health to deliver, implement and deploy the full suite of interoperability standards needed to deliver the right information at the right time and the right place, right across the health service.
Only a small subset of the stringent standards for interoperability called for by Derek Wanless in his report for the Treasury on the future funding needs of the NHS have been delivered; and these mainly consist of links to and from the central Spine. Where are the rest?
Look across the pond
Each of the ‘Clinical 5’ set out by the NHS Informatics Review in 2008 depends on standards to exchange information within and between provider organisations. The standards that are needed have not been agreed nationally, let alone implemented or deployed.
One of the priorities for our national health informatics strategy should be to mandate that all suppliers support nationally agreed interoperability standards for these and other use cases.
We should take note of what is happening in the USA. One of the first very first acts of the Obama administration was to establish by law a federal advisory committee to recommend standards to be used for electronic exchange and use of health information (see http//:healthit.hss.gov).
Understanding interoperability
The base standards of healthcare interoperability are HL7 and SNOMED CT, but these are base standards, not plug and play solutions out of the box. For each and every task, we have to set out and agree stringent specifications or “profiles”, based on the base standards. Each profile must be implemented and deployed in systems at both ends before any information can flow.
Confusingly, the term interoperability applies to three different skill sets; technical interoperability, computable semantic interoperability and process interoperability. Technical interoperability just gets data from A to B, reliably. This is now a commodity, as demonstrated by the Internet and the New NHS Network (N3).
Our immediate focus is computable semantic interoperability, which is to transfer data from system A to system B in a form that system B can process and use – not just display. Electronic data interchange (EDI) of this type typically involves a two-stage translation process.
The first translation is from system A’s local data structure and codes into an appropriate message standard typically using HL7 with SNOMED CT codes. The second translation is from the common standard into the codes and data structures used by system B.
Each message has to be translated twice, by a different set of computer programmers at each end. The avoidance of all error or misunderstanding at this stage is one of the greatest challenges. It is the main reason why interoperability is hard.
Process interoperability occurs when we re-engineer the business processes at each end to provide a much better service. This can only be done once the links are working, but it is the only way to realise the potential benefits of interoperability.
Understanding syntax and semantics
Everyone involved in healthcare interoperability really needs a basic understanding of the process, and HL7 and SNOMED CT in particular. Each message standard is created using a specialised healthcare interoperability language.
All languages have both syntax and semantics. Syntax is the structure or grammar of the language. Semantics relates to the meaning of expressions. In all practical languages, the syntax and semantics are inextricably interwoven. One of the challenges in health informatics is that there is an overlap, which has to be resolved case by case, between what can be done in HL7 and what is done using SNOMED CT.
HL7 has been around for about 20 years in two distinct versions: Version 2 and Version 3. HL7 Version 2 is widely used in hospitals for patient administration system links to share patient identification details, demographics, episode and case-mix data with other applications.
It is also used for test orders and results reporting. The structure of HL7 Version 2 messages is quite simple. Each message has a number of predefined segments, each with a 3-character segment identifier.
Each segment contains predefined components and sub-components separated by special delimiter characters. The meaning of each component is specified in the standard and you need to use the standard as a reference to understand each part of a message. The system is flexible, but has no overall architecture and provides many ways of doing the same task.
HL7 Version 3 tackles these issues by using a Reference Information Model (RIM), which specifies health information in terms of Acts (things that happen), Participations, Roles and Entities. The power of Version 3 is based on the consistent use of the RIM.
CDA (Clinical Document Architecture) refers to a category of Version 3 messages, which share many of the properties of paper documents. Each CDA document has a header, specifying message metadata (who, what, when, where and why), and a body, which has human-readable sections and coded clinical statements (in CDA Release 2 Level 3). Templates specify exactly what is allowed in each message.
SNOMED CT came into existence as a result of merging the NHS Clinical Terms (Read Codes) and SNOMED RT in about 2002.
SNOMED CT has three main types of component: concepts, descriptions (human-readable terms) and relationships between concepts. These components all use a common identifying code, the SCTID (SNOMED CT ID), which is up to 18 digits. It may be thought of as a 64-bit integer.
SNOMED CT defines concepts in terms of their relationships with other concepts, which are specified using a special machine-readable notation called description logic. For example, the concept Laparoscopic Appendicectomy is defined in terms of three other concepts; it is (1) an excision of (2) the appendix (3) using a laparoscope.
This allows us to retrieve data using any of these relationships. If a single code is allocated to the concept defined in this way it is pre-coordinated; alternatively it is possible to put a whole description logic expression into a patient record, which is then referred to as being post-coordinated.
SNOMED CT has almost 400,000 concepts, which makes it hard to find what you want. The solution to this problem is to define navigation subsets, which are use-case specific groups or hierarchies that reflect what the user does, sometimes referred to as the model of use. SNOMED maps these to the underlying model of meaning specified within SNOMED CT (the model of meaning), which is used for analysis.
Core subjects
Health interoperability, HL7 and SNOMED CT are core subject matter of health informatics. They are not simple or straightforward, but the need to understand them is going to grow.
The full text of Tim Benson’s new book on HL7 and SNOMED is available for download from his web-site – www.abies.co.uk – and will remain so until the book itself is published in November. Benson also runs courses on standards.
Tim Benson will be one of the speakers at E-Health Insider Live ’09, where he will be running a session on “why is health interoperability so hard?” The full speaker list, further details of the conference and exhibition, and information on how to register is available on the E-Health Insider Live ’09 website.
Write for the site: Is there a subject you feel strongly about? If so, why not submit a “personal view” to Lyn Whitfield, managing editor, E-Health Insider. Articles should be no more than 800 words in length and will be subject to editing.