I made the Karen's Cross observation about the NPRM, but I seemed to have failed to make it clear. The transport identified in Meaningful Use 2 as (b) is NOT a transport, it is a functional specification for a service that converts Direct to/from XDR. It is a service specification. It is NOT a transport specification. Both sides of this service specification are fully specified. On one side is Direct, on the other side is XDR. What makes this more difficult to understand is the (a)+(b) or (b)+(c) math...
Why did we need Karen's Cross?
Back when the Direct Project was working hard on defining the specification and other parts around it. There was a recognition that those that can talk Direct, and those that can talk XDR can talk to each other if we work out exactly how to convert from one to the other.
This was graphically shown on the white board by Karen, and thus became known as Karen's Cross. The diagram did get cleaned up and is shown at the above, pulled from the Direct project wiki article on the Intersection with Exchange . The top of the Cross shows two systems communicating using the Direct specification, the bottom shows two systems communicating using the NwHIN-Exchange push transport (which is XDR). If one stays totally on top, or totally on the bottom there is no problem. But if you want to cross over then you need the RED arrows. It is these RED arrows that make up the “XDR and XDM for Direct Messaging”.
What Karen's Cross shows is that the end systems don't need to know what the technology of the other system is, and that the conversion is done using automation transparently. In Deployment Model terms, here is the diagram for the RED arrow from the top left to the bottom Right. It shows how this system converts a Direct e-mail message into an XDR message delivered over the NwHIN-Exchange.
The RED arrow from the bottom left to the top right is shown here.
There is far more description done at the Direct wiki Deployment Models page. I encourage even a quick look at this. This is simply further proof of the magic of the use of Standards, the little blue box.
The alternate view is that ONC just means the minimal metadata specification. I am hopeful this is the right read.
§ 170.202 Transport Standards. (b) ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in § 170.299).
§ 170.202 Transport Standards. (b) ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in § 170.299).
The specification is properly identified, you can find it here, it is actually this, and comes from XDR and XDM for Direct Messaging.
If they meant only to require the metadata portions as mandatory, they should have said that. Actually these metadata requirements have been incorporated into IHE XDR as a specific option. So they could have identified this option. But they did not, they said the WHOLE SPECIFICATION.
The (b) transport is pointing toward a specification that was written as part of “The Direct Project”. This specification shows how interoperability can be achieved when one system is using purely the secure e-mail of “The Direct Project” and another system is using IHE-XDR. Both specifications are PUSH, both support the same high-level goals. They are simply different transport/session level encoding. This specification shows the relationship between the e-mail transport and the IHE-XDR + SOAP transport. For example it explains how an XDR submission set with multiple documents can be converted into an XDM submission set with multiple documents, the result zipped according to the XDM option for “secure e-mail”, and this ZIP file placed into a secure e-mail message following “The Direct Project”.
If they meant only to require the metadata portions as mandatory, they should have said that. Actually these metadata requirements have been incorporated into IHE XDR as a specific option. So they could have identified this option. But they did not, they said the WHOLE SPECIFICATION.
 |
| Karen's Cross |
The (b) transport is pointing toward a specification that was written as part of “The Direct Project”. This specification shows how interoperability can be achieved when one system is using purely the secure e-mail of “The Direct Project” and another system is using IHE-XDR. Both specifications are PUSH, both support the same high-level goals. They are simply different transport/session level encoding. This specification shows the relationship between the e-mail transport and the IHE-XDR + SOAP transport. For example it explains how an XDR submission set with multiple documents can be converted into an XDM submission set with multiple documents, the result zipped according to the XDM option for “secure e-mail”, and this ZIP file placed into a secure e-mail message following “The Direct Project”.
The following table shows the cases of conversion that SHALL be performed.
Receivers RFC5322 + MIME RFC 5322 + XDM SOAP + XDR Senders RFC 5322 + MIME No Conversion No conversion
- receiver expected to be able
to use non-XDM format- Transport Conversion
- Metadata is createdRFC 5322 + XDM No Conversion
- receiver is expected to be able
to handle XDM packageNo conversion - Transport conversion
- metadata simply transformedSOAP + XDR - Transport conversion
- metadata is simply transformed
- delivered as XDM package- Transport conversion
- metadata is simply transformed
- delivered as XDM packageNo conversion
This is a proxy or bridging specification. It isn't a specification that EHR technology would implement. It is the bridging technology, a proxy service, that allows for mostly-seamless interaction regardless of if both sending and receiving support the very same transport. It is a specification that shows how two radically different transports can be made to work by a proxy system. This proxy or bridging service would typically be running at the edge of one type of network as a transparent gateway to the other network. So there would be only a few of these proxy/bridge systems.
Why did we need Karen's Cross?
Back when the Direct Project was working hard on defining the specification and other parts around it. There was a recognition that those that can talk Direct, and those that can talk XDR can talk to each other if we work out exactly how to convert from one to the other.
This was graphically shown on the white board by Karen, and thus became known as Karen's Cross. The diagram did get cleaned up and is shown at the above, pulled from the Direct project wiki article on the Intersection with Exchange . The top of the Cross shows two systems communicating using the Direct specification, the bottom shows two systems communicating using the NwHIN-Exchange push transport (which is XDR). If one stays totally on top, or totally on the bottom there is no problem. But if you want to cross over then you need the RED arrows. It is these RED arrows that make up the “XDR and XDM for Direct Messaging”.
What Karen's Cross shows is that the end systems don't need to know what the technology of the other system is, and that the conversion is done using automation transparently. In Deployment Model terms, here is the diagram for the RED arrow from the top left to the bottom Right. It shows how this system converts a Direct e-mail message into an XDR message delivered over the NwHIN-Exchange.The RED arrow from the bottom left to the top right is shown here.
There is far more description done at the Direct wiki Deployment Models page. I encourage even a quick look at this. This is simply further proof of the magic of the use of Standards, the little blue box.
Conclusion
It is very possible that all that ONC wanted to pull from this specification was the minimal metadata. This is a reasonable thing to pull from the specification. This minimal metadata recognized that some metadata that IHE had originally identified as required simply isn't always going to be available. However if this is what they wanted to do they should have said so. IHE has adopted this minimal metadata directly into XDR specification and XDM specification --> Support for Metadata - Limited Document Sources. So there is no need to use such specification pointing gymnastics. I think I am going to assume that all they intended was the minimal metadata.
The whole transports could have been said far more simply using IHE profiles. There is NO technical difference. It is so frustrating that all this specification complexity is because there is a desire somewhere to keep IHE profiles out.
No comments:
Post a Comment