SOAP-XDR Issues, Addressed
Note: For brevity, we refer to a profile here called "XDD". XDD isn't a "real" standard; it's a pseudo-acronym referring to simplification of the XDR standard with fewer required or meaningful data fields, allowing the implementation to scale down to meet practical and technical realities. A system that can parse XDR can parse XDD without extra development, although it may need to change its logic to deal correctly with absent or dummy data fields.
Separate routing metadata from content metadata
Also raised by HITSC review and an important HITPC Privacy and Security Tiger team consensus option
Short Answer: The routing metadata will be present in the SOAP Header in addition to the XD* metadata, allowing the whole SOAP body to be encrypted using WS-Security X.509 (if necessary).
Discussion:
The XDR profile specifies fields that are expected to be filled with personally identifiable health information, in order to allow systems receiving the pushed data to act accordingly. The simple nature of NHIN Direct communications encompasses a number of scenarios where such information is not available or displayable: a message that cannot be associated with a patient, a sender who cannot technically supply patient information, or an intermediary who is not trusted to process patient information. The XDD standard does not require a patient identifier, thereby addressing these scenarios, while still providing a clear path for the scenarios where patient information is available or processable.
Why bother? Why deal with patient information at all? Because systems that can (technically and legally) use patient information to drive program logic are smarter. They offer better, simpler, and more efficient workflows, reducing the thought-burden on the users who are dealing with NHIN-D messages. We definitely need to support the limited and low tech cases, but XDD gives us a way to do that while providing easy scalability for a richer implementation.
Enable transport of simple messages without requiring CDA attachments or "step-ups"
We assume that "CDA attachments" is shorthand for "attachments in healthcare format", e.g. CDA, HL7 V2 messages, X12 messages, etc. When a Source HISP (implementing the sending side of the SOAP/XDR push) receives a message, its job is to create a SOAP envelope containing XDD package that holds the bit of content that represents the message itself (the attachment mentioned above). If the attachment is "simple", then the content is the message, the XDD package contains a dummy patient identifier, defaulted minimal metadata, and the SOAP header contains the "to" and "from".
Enable HISPs that can deliver messages without viewing the content metadata, only the to/from information (no PHI)
Short Answer: The Documents that reach the Source HISP can be encrypted at the source, in which case minimal metadata is defaulted to complete the XDD package.
Discussion: An "untrusted" HISP, one who receives an encrypted content package, is technically unable to parse any information from this package. Facing this, it dumps the encrypted content into the XDD package (jokingly called the Matryoshka approach), defaults the minimal metadata, and sends the entire thing via SOAP to the destination HISP. The destination HISP unpacks the SOAP envelope and XDD package, realizes that it too cannot open any more Russian nesting dolls, and delivers the encrypted content package to the destination who (presumably) has the security to finish unpacking and access the creamy nougat center.
Allow end-to-end content encryption
XDD end-to-end encryption is achieved via WS-Security, using the X.509 profile. In this case the HISPS are simple SOAP proxies, without the need for any XDD capabilities.
Enable Transport of Content Not Related to a Single Patient
The only Stage 1 MU requirement that is not patient-specific is the submission of quality data to CMS. This aggregated quality data is currently being submitted via an HTTP interface from registries, which do the aggregation. It is not clear how small providers will be able to do the aggregation themselves, but in this case it seems that since the recipient is a single federal organization, a SOAP (not XDD) transaction can handle that requirement.
Substantially Drop Total Implementation Costs
See "Enable HISP-in-a-box"
Discussion: It's pretty easy to look at the barest form of XDD and ask oneself, "Why the excess cruft? Aren't we introducing needless complication?" And it's true - for the cases we mention here, we're putting a lot of wrapping paper on a very small present. But we're also planning for the future - for scenarios where, when we can, we have the ability to make systems that actually provide more intelligent behaviors than just a simple e-mail model. Consider the Outlook routing rules that allow you to put all the messages from the NHIN D Google Group into your special "read over lunch" folder, while flagging messages from Vassil Peytchev with a special purple flag. It's the richer metadata that allows you these efficiencies, and we think that as NHIN Direct succeeds (as it most certainly will), we'll see a greater demand for more intelligent behavior based on message content. This is the best path toward the "social scalability" mentioned in discussions - an implementation that can start simple but that has a proven model for the functionality our users will eventually require.
Substantially better documentation and all-in-one document specifications and implementation guides
We agree, documentation can stand improvement. We're attempting to simplify now, and we'll continue to do so in the future. Consider a hospital using a fully IHE-awesome EMR, which, through NHIN Direct, starts to receive hundreds of messages daily. That hospital (and the providers who practice there) benefits when those messages can be processed efficiently, so it makes sense to make it easy for the sending providers to provide the best messages available. And the non-commercial vendor community who is eager to provide advanced functionality to the (currently underserved) small provider needs a quick and clear path for starting small but eventually delivering the most advanced and useful features to that provider.
Much better reference guides defining samples, particularly for metadata
Here's a start.
Better overviews describing all the parts that are required to send a transaction
Required parts include a "to", a "from", a SOAP builder (widely available in open source and commercial language implementations) and an XML builder (ditto). We intend to expand this explanation more fully and to also provide reference implementations.
Skinny the minimal requirements for creating an XDR (or XDD) message
XDD is designed as the skinniest possible interpretation of a traditional XDR message - only the To and From are necessary in the XDD minimal metadata set. We were going to call it XDSkinny, but "XDS" was already taken and we thought it best not to introduce further confusion.
Address requirement for UDDI and central infrastructure
While UDDI can provide federation using a root server, that is not a requirement. A UDDI server can be provided by a community or a HISP, and federation (via replication) can be achieved on a peer-to-peer basis. Why did we consider UDDI? UDDI provides a general solution for a routing directory. Since the provider directory aspect of NHIN Direct is yet to be discussed, there are certain features (e.g. to allow for a destination to declare the level of metadata required to accept a transaction) that don't have a home yet, and could be potentially provided by a UDDI registry. Once there is a clearer picture of the directory requirements, and their interaction with the routing requirements, we may find better solutions for determining an endpoint for a given destination address and trust circle - e.g. LDAP.
Enable "HISP in a box"
We plan to implement a NHIN-SOAP agent that can be added to a pure SMTP HISP, allowing that HISP to provide that advanced functionality mentioned elsewhere. This plugin will take inputs such as the To, From, and (optionally!) other metadata and will output a SOAP message that follows the model we describe on this page.