Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, February 24, 2011

Putting the Lego Together

On Sunday I taught a workshop that used a lego theme to explain how IHE has the building blocks to create many different things.  Of course, the images rolled around in my head all week, and I realized what's really right about that analogy.  Anyone who is familiar with Lego Technic parts realizes that there are a limited number of different connector types, and that what really makes a design is NOT the connectors, but rather the shape of what the connectors are attached to.

The Chopper below illustrates the point.  You can find several pieces that have similar connectors on them, but if the shape of the peice where the connectors are was different, well, it just wouldn't be as cool a chopper as this one.

Red Technic Chopper Motorcycle by Mike Cummings

But all IHE tells you is the shape of the connectors, not the shapes of the pieces they are attached to.  That's what makes Lego (and IHE) so cool.  The shapes of the connecting components are standardized, but the rest of the piece can be custom made to fit.  Sometimes this makes it difficult to understand how to use an IHE profile, because it really is the shape if the pieces that inspires the use case and the profile, be it an EHR, HIE, RIS, PACS, Workstation, et cetera.

So what happens when we describe only the connectors is that sometimes the shape of the body to which they are attached is lost, or we don't understand how it works.  That's what happened today while I was talking to Arien Malec about his concerns about the scalability of the NwHIN Exchange using IHE's Cross Community Architecture. 

The XCA profile builds on the XDS query capabilities, and defines a transaction that looks almost exactly like an IHE XDS Stored Query transaction.  The only difference is that it has one additional requirement regarding the home community identifier that must be included in the metadata.  The whole point of this transaction is to support fan-out of an XDS query from a gateway to other  HIEs that might have information on a patient.

So, imagine that there's an HIE in Florida and one in Boston, and I'm the patient in Orlando.  I'm a visitor, and they need to get my records from Boston.  So, they query the gateway in Orlando, the gateway queries the HIE in Boston, and violla, they have my data.  So far, so good.  But the scalability problem that Arien is worried about has to do with the number of HIEs that query will need to fan out to in order to find me.  If they don't know to ask in Boston, and we have 100 or more regional HIEs, that query could go to every HIE in the nation, and only 1 out of 100 would return any data for me.  That's a LOT of wasted CPU bandwidth.

So, how does the XCA gateway in Orlando know who to ask?  Enter into the picture the Cross Community Patient Discovery profile.  This is to PIX/PDQ version as XCA is to XDS.  You can issue a query for patient demographics and get back a result listing the patient ids and their home comunity ids.  So, the XCA gateway issues an XCPD query, and it returns the home community ids where we know that patient has data.

This seems like a shell game, because we've just transferred the magic about figuring out who to fan out from XCA to XCPD, right?  Not really. 

One possible solution makes the HIE responsible for the patient's medical home responsible for keeping track of the care locations from which they recieved care, and make all care locations which treat the patient responsible for telling that HIE to associate the patient with their home community id.  This is one of the possible implementation mechanims that could be supported using by XCPD.  There are others, but I can't give away ALL the good stuff.

So, XCA without XCPD, potentially 100 queries to fan out to, of which most would be expected to fail.  XCPD has one query to perform, and then based on the results of that query, a query to each holder of records for that patient.