The Direct Project has the capability to handle a variety of data formats, including all the standard healthcare formats. Computer to computer sharing of patient health information is simplified by XDM packaging. All of the metadata for the content, such as CCD/CDA, CCR, HL7 V2, DICOM, etc., is defined in a metadata file. This allows the receiving system to decide rather simply how to process the content.
In addition, content can be displayed without the need to parse apart the document. Take for instance the very simple prospect of displaying a CCD document. Without metadata, even when the document is in an XML format (such as CCD/CDA or CCR), the receiving application would still need to “look inside” the content before it can decide how to render the contents. But with XDM metadata available, the application can do that, and a lot more decision making about how to process the content, without ever looking inside it. This allows for a much simpler processing path.
Roles of an Interface Engine with Direct Project
The Direct protocol will simply be another connection method into and out-of integration engines. However, the integration engine can determine how involved it will be in the formation of the Direct message.
A base level of Direct support would involve creating an unsecure MIME message and handing this off to a HISP. The HISP would then be responsible for encrypting the data with a public key, signing the payload with hash and a private key, and routing the message via SMTP to the receiving HISP.
a full participation in direct would involve the integration engine performing all the functions of a hisp, including encrypting and signing on the sending side and decrypting and authenticating on the receiving side along with managing all the certificates.
if the integration engine acts as a full hisp, then the engine could choose to only act as a hisp for messages that flow thru the integration engine, or it could also act as a hisp for any other application that wants to send secure e-mails.