this page is under construction
What is a 'message'?
In health informatics, the term 'message' is used in a fairly specific way to mean a packet of information sent between two applications, containing predefined content. Historically messages have been defined by HL7, EDIFACT, ASTM and other standards organisations. Each message definition specifies the structure and contents for a particular transmission. Historically messages have been used for pharmacy orders, lab orders and results among other things. Messages have always been manually defined by groups of people within standards organisations. Semantically, they carry requests, replies, many of which are 'changes in state'. For example, an HL7v2 message is defined containing a blood film result in such a way that the complete result can be sent, or just one or two analytes, marked as corrections with respect to a previous message carrying the complete result. The same scheme is used for microbiology results, due to the culturing time and the need to generate intermediate results.
Messages have historically been developed on the assumption that the internal information models of participating applications or systems do not matter, and cannot in general be known. Systems developers have had to generate messages via a transform of their own data into the prescribed message formats.
In summary, the usual meaning of 'message' and 'messaging' in health informatics has been:
- manually defined
- fine-grained
- relatively fixed content
- supports updates and corrections
- supports stateful communication
- point to point
What is an EHR?
A generally accepted definition of an Electronic health record is a record of care that is:
- longitudinal
- patient-centric
- shared among carers
The important thing about an EHR is that it is an accumulation of information about a patient that tells the current state of the care process of the patient as well as a history of events. Further aspects of a workable EHR include:
- versioning - supporting historical views and indelibility
- audit trailing of modifications and possibly reads
- privacy features
There are many others of course. Two useful resources defining the EHR are:
- ISO DTR 20514 - Electronic Health Record Definition, Scope and Context (PDF)
- ISO TS 18308 - Requirements for an Electronic Health Record Reference Architecture (PDF zip file)
Can messages be used to build an EHR?
A common idea among some people in health ICT is that an EHR can be constructed as a series of accumulated messages. This idea seems particularly prevalent in government, for the obvious reason that if messages, which already exist, could be aggregated within a central database, nothing more would be needed to create an EHR. However, an inspection of what is needed in an EHR and what messages provide show that this is not the case. The following sections explain why.
Messages usually come from more than one source
In most non-trivial health information environments, messages come from multiple sources - typically multiple pathology laboratories. The general case is that each such source uses slightly (or maybe radically) different message structures to transmit similar information. Often the software at some sources implement a different version of the same message, while other sources use a different system of messaging altogether.
Clearly using a collection of such disparate as an EHR will not work. At a minimum, format, version and message system conversions would have to be made. Even when the same message structures are used, terminology differences (or lack of coding altogether) will often mean that similar messages cannot be processed in the same way.
Messages are change-based
to be continued
Many messages are not relevant
The scope of EHR content includes information about the care delivery process with respec to a patient. What goes in an EHR is by and large what is useful and meaningful to physicians delivering care. Much of this kind of information is not available in messages, rather it is captured in GUI applications used by nurses, doctors and other health professionals. Conversely, there is much information that does exist in messages - e.g. the order and response relating to a patient being moved from their bed to radiology - that is of no interest at all to clinicians. There is of course some content overlap between messages and the EHR - lab results, orders, referrals and so on - this will vary with jurisdiction and to what extent messages are being used.
Point of care applications generate EHR data, not messages
to be continued
Are there alternatives to messages?
Messages as generated artefacts
to be continued
Service-oriented architectures (SOA)
to be continued
Content definition of messages
to be continued
Do we need messages?
The technical idea of a message as a packet of information transmitted between a requester and a responder system wil never go away. The real question is: what kind of messages do we need? The future will be to do with messages whose definitions are machine generated from content models, and whose actual content is automatically generated by services interfaces. However it is clear that the manual kind of messages will be around for a long time - HL7v2 is for instance still maturing with version 2.8 being released recently. The relative simplicity of such technology and economic viablity for its limited scope (mostly lab, pharmacy and referrals) means that vendors do not have any obvious reason to adopt another technology and implement it. Conversion of most such messages is also mostly solved by existing message gateway products.
The future will therefore be a mixture of both kinds of messages, and EHR systems need to take account of this. Any modern EHR system needs to be able to import old-style messages, as well as interoperate via SOA interfaces for data interchange with more recent systems.
From a strategic point of view, manually defined messages should be phased out in the long term and replaced by machine generated definitions based on shared content models. There is no reason why existing HL7v2 and EDIFACT message structures could not be generated by an appropriate converter for some time, allowing the existing HL7v2 and EDIFACT message infrastructure to continue.
What is the role of CEN EN13606 and HL7 CDA?
to be continued