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 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
- may be lifelong
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 come from more than one source
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 a different version of the same messages
to be continued.
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
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