From Profile to Architecture

What's the right way to implement an IHE Profile in code and/or services?  The answer if you look at it might very well surprise you.  I did an exercise recently with a small team of architects where we looked at a particular user scenario: Handling the referral of a patient to another provider and getting back the results (e.g., the 360X Referral Project) We broke the scenario down into several steps, each of those comprising a particular task for the user.  We went back through the the steps and focused on the task of sharing a referral package from the referring provider to the referred to provider.  From the user perspective, the healthcare provider wants to collect and share information on a specific patient to another provider.  They don't care about how it gets there, so long as it is available to that provider.  If fax is the only way to do it, so be it, but ideally they'd like it to be an electronic transmission (which has a much higher fidelity and quality of service).

So, the service that needs to be delivered is to "share a package of information" with another provider, on a single patient.  Oh, and did I mention that the referred to provider might not even be known (it could be up to the patient).  So the first step of the service is to figure out how to get the document to where it needs to go.  If there is a destination (the referred to provider), routes to that provider might be discovered by looking up information in a Healthcare provider directory.  Having established routes, the system must now choose one (or more in some cases).  The mechanism by which the route is chosen depends upon the needs of the referring physician and the patient.  Does it need to get there with high reliability and fidelity?  Direct might be OK, but a push using an HIE or Point to point connection might be better.  Or is it more important that it be quickly but low fidelity is OK and there's not a digital route?  Fax might be the best choice.

Even without a known target provider, a route can still be established.  In regions where everyone uses the HIE, that's probably the best destination.  But another possibility is CD or USB stick.  The route is simply to media.  Another route is to a private store and pull location, which would allow a provider at the opposite end with the right tools and the retrieval key to be able to access and download the content.

Before transporting the package of content over the route, a few things might need to be massaged.  For example, the patient identity might need to be mapped from the referring providers identity domain to another identity domain that the referred to provider understands.  You might need to map metadata about the documents across "affinity domains" (e.g., as in XCA).  These are additional services that need to be supported.  Mapping the patient identity could use PIX, PDQ or XCPD profiles, depending on the route and information available in the original package.

This architecture looks nothing at all like XDS, XDR, XDM or the Direct Protocol, or HPD, or PIX/PDQ/XCPD.  I've thrown in a few extra pieces like FAX (which could also be viewed as secure printing), and you could also imagine that other routes like use of DICOM CSTORE could also be used as the method of transport.

Deeper in the service layer, there are places where these profiles finally come into play, and that is between system boundaries.  Once you've determined the route to the end user, you've also helped to define the service contract used between the sharing systems, and the profile enables the two systems to be communicated.

A naive implementation would develop a "Document Registry/Repository" Service, and implement the Provide and Register, Query and Retrieve Document transactions.  It's there, but only at the system boundaries.  Within the systems implementing the IHE profiles, the path to those services looks much different.

I traverse those boundaries in my head all the time without thinking about it, and so do many of my standards colleagues.  What we need to be able to do is illustrate how these services enable interoperability at the application level, without requiring applications to really get into all the gory details.  The profiles have to put that in front of engineers, but most neither need, nor want to deal with that level of complexity.  The complexity exists for many reasons, some out of necessity, and some because of history (and some would say, bad design decisions).  However, we can make it simpler for developers to understand at the level their applications need to.

What we learned from this was that the profiles and standards are the building blocks.  How you put them together is really what determines how good the space looks and how well it functions for it's designed purpose.  In HL7 and IHE (and elsewhere) we build the bricks and shape the beams.  It's the architecture that makes it pretty.  We may need a few more good examples to show the way. Here's one example thanks to John Moehrke and others: A Service-Oriented Architecture (SOA) 
View of IHE Profiles, which helped to shape how my exercise was developed.

It worked out rather well. I don't have the full picture yet (or even an artists rendering), but I'm starting to get the picture in my head.