We have a long-stated goal of making sure that, as we add new use cases to the NHIN, we don't disrupt the existing use cases and technology choices.
It is important to note that, as discussed in a previous post, the user stories for the NHIN Direct project are additive to the user stories that informed the existing NHIN technology stack. That is, we aren't defining an alternative path for the same use cases.
One approach to ensuring that the architecture and standards harmonize is to re-use the existing NHIN specifications, and model the NHIN Direct orchestration on top of them, using the Abstract Model. I have taken a first pass at that mapping.
To accomodate the new functionality, we need to extend the current XCA and NHIN transactions in the following way:
- Add XDS metadata to model the routed-to provider, and support them with the Provide and Register Document Set and Registry Stored Query transactions
- Enable UDDI lookups that map from the routed-to provider's domain to the SOAP endpoints for the health service provider
As a downside, that additional support comes at the cost of a deeper technology stack for implementation. That includes supporting SOAP, WS-Security, SAML, XDS submission and document metadata, and, for enabling organizations, UDDI.
We may decide that something like the REST implementation is easier to implement, and the IHE implementation is more powerful. At that point, we'll need to decide how to proceed. There are a number of options here, with tradeoffs among them.
I would like, first, to invite comment on the draft IHE implementation. I'm sure it needs work. I would particularly like comment on how we could skinny down the technology stack to reduce the cost of implementation.