...
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:
- complete result
- update on previous result (e.g. due to longer culturing time)
- correction on previous result (due to
...
- error)
- part of a result (whatever is available at an intermediate point in time)
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 respec 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 be continuedretrieve 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?
...