...
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.
...
- longitudinal
- patient-centric
- may be lifelongshared 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:
...
In any non-trivial health information environment, messages come from multiple sources - at least multiple pathology laboratories. The general case is that each such source uses slightly (or maybe radically) different message structures to transmit the same information. Often the software at each source implements some sources implement a different version of the same messagesto be continuedmessage, 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.
Messages are change-based
...
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?
...
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