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:

What is an EHR?

A generally accepted definition of an Electronic health record is a record of care that is:

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:

There are many others of course. Two useful resources defining the EHR are:

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 often change-based

In a temporal sense, messages often carry information relating to a change in something.  Laboratory messages can carry any of the following:

In the EHR, the required view is of the complete result, as far as it is known at a given time. A series of messages containing a mixture of the above types of information cannot simply be added to the EHR, they have to be integrated in the correct way. Updates on a result should replace the previous issue of the result; a correction on a result needs to be used with the previously issued version of the result to create a complete new version.

Many messages are not relevant

The scope of EHR content includes information about the care delivery process with respect 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

In most GP, nursing and other point of care situations, graphical applications are in use by end-users. These applications normally generate new data in their own database or make calls to a data-management component, a middleware layer or a service interface to retrieve and store data. The structure and content of such data may be highly variable. In current applications, messages are not the output, nor would they be suitable, due to the variability.

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