Message Authentication Codes (MACs) are used to ensure that the message sent between two systems is communicated ungarbled. A MAC is usually a computation over the message that produces a short code. When the same computation is performed over the data on the receiver side, if they don't get the same code, they know the message didn't come over correctly. The simplest of these is an XOR over all data bytes. Other more complex computations include CRC, and cryptographic algorithms such as SHA-1. These all operate pretty much at the syntactic or even lower levels of granularity in the transmission.
When messages are sent by computer, the MAC is computed and sent by the originator. If the message is good from the receiver's perspective, it sends back an ACK. If not, it sends back a NAK. In early communications protocols, these messages used the ACK and NAK ASCII characters, but these days they are a bit more complex.
Humans use ACKs, NAKs, and MACs too, but differently. It's fairly common in various leadership training classes to hear experts talk about listening skills. One skill that is often taught is reflecting: Responding back to the speaker in your own words your understanding of what they just said. It's also a skill taught to messengers and other communicators. While it requires some level of practice, this is still pretty easy to do between humans.
The protocol goes something like this:
MSG: Speaker: "..."
ACK: Responder: So, [MAC = essential points from ... above], right?
ACK: Speaker: Right.
OR
MSG 1: Speaker: "..."
ACK: Responder: So, [MAC = essential points from ... above], right?
NAK: Speaker: Wrong.
Communication could stop here, but more typically, we fall back to a different level of communication:
MSG 2: Speaker: re-explains ... in a different way
ACK: Responder: Ah, so [MAC = essential points from ... WITH correction].
ACK: Speaker: Right.
The point of reflective listening is that the essential semantics are conveyed back to the speaker, but the definition of essential is focused on the original speakers point of view. The MAC is never communicated, because we leave it up to the responder to figure it out, and the speaker to evaluate whether they got it right.
This isn't very easy at all to do between computers. IEEE originally defined interoperability as:
... the ability of two or more systems or components to exchange information and to use the information that has been exchanged.(NOTE: The new definition is slightly different):
A key point in this definition is that the information being used by the receiver may not be what the sender considers to be essential. [This leads to an interesting correspondence to the term "secondary use", which describes cases in which how the receiver uses or considers data varies from how the sender was designed to use or communicate it.]
It is fairly common in messaging environments to reflect back the original content received, perhaps (in a few cases) removing that content that wasn't stored or acted upon by the receiver. This becomes a "Semantic MAC", indicating what parts of the message were successfully communicated. But often, we don't ever get that feedback, or as many implementations do, we just get copy the content received without any evaluation of it.
Of what use would a semantic MAC be in Healthcare IT? Consider my youngest daughter's story (starting at 1'25'') about getting her ear drops. If the receiver of the e-prescribing message had sent back a "semantic MAC" that indicated what would be given to my daughter, the sender would have known that it didn't understand what ear drops should be given.
Doing this would be very complicated. The problem is that the final receiver of the message is often several systems removed from the sender, and the content of the message wouldn't even be inspected until after the sender had moved on to other things (possibly long after). The original message sender may not even be accessible to the final receiver (and vice versa). This is why HL7 supports both message acknowledgments and application acknowledgments to messages. The former validates syntax, the latter semantics.
The challenge with application acknowledgment is that in order for it to be effective, it has to be communicated to the originating system, not to the message deliverer, and the sooner the better to avoid the need to retain the sender's context.
When you receive a nice gift through the mail or UPS, do you thank the driver or mail carrier? No, you write a thank you letter (or e-mail) to the original message sender. And if you receive a package you didn't expect, the most effective thing to do is contact the sender to ask what it is and why you are receiving it. Asking the delivery driver why it showed up won't help you. If you receive a package at 5:00pm on the west coast from a business on the east coast that closes at 6:00pm (EST), trying to call them to find out what happened won't succeed until the next day, when they open up again. This reflects another challenge of application acknowledgments, which is that the message originator may not always be available when the receiver is ready to acknowledge the message.
You might think it would be easier if every system was always on and always accessible over the interwebs so that we could avoid the need for store and forward. But few store and forward systems do just that. Often they add value to the communications, reducing costs and increasing effectiveness in other ways.
There is no guarantee of immediacy in the communication between the message originator and the final receiver of the message. To resolve this issue, we take additional steps to ensure that communications are not garbled semantically when the standard is developed. When a standard is designed, we decide which parts of the content are essential by marking them as being required, recommended or optional. These terms describe the "essentialness" of the elements in the communication.
I get numerous questions about whether a given component of a CDA document, or XDS message, or other standard HAS to be present, or if it can be null. There's no amount of documentation in the standards that will eliminate these questions. The reason for that is because even though these standards are developed through consensus, some systems just won't be able to support them without being changed. Change is hard, and has costs, and many would like to avoid it.
If you are a message sender, try to put yourself in the receivers shoes. They need to be able to clearly understand what you've communicated. If you omit stuff because it is hard, you make the job of the receiver even harder. Most of the Health IT communications today are not really dialogues, but rather a sequence of monologues. So you have to make sure your communication is clear, the first time.
Isn't that what this means
ReplyDelete