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.
OK - I am now officially stealing your analogy for my Interop & Standards course! This is the clearest exposition of how to use IHE, and standards in general, that I have seen.
ReplyDelete@Keith -- super helpful, but I'll admit to being still confused. Assume I get how XCPD and XCA work, and I get the gateway architecture for NwHIN.
ReplyDeleteLet's pretend I succumbed to dehydration and exhaustion from walking the halls in Orlando and my medical home is at BIDMC.
The natural dialog between my and the Orlando ED intake nurse is:
Nurse: Where do you receive care?
Me: BIDMC
Nurse:
EHR:
I'm interested in what gets entered into the ED EHR, and what the ED EHR says to the gateway, and what the gateway does from there.
This dialog can get worse:
Nurse: Where do you receive care?
Me: Dr. Good at North Oakland Family Practice (a smallish physician practice)
There are a few models for how I can imagine this to work.
First, I could imagine each state maintaining an central MPI and a central document registry. In this model, there's an EHR dropdown of perhaps 60 entries (states, territories, VA/DoD and other trans-state health systems) which correspond to a small set of both XCPD and XCA nodes. My personal view is that this outcome requires more centralization and more uniform state-based coordination than is likely to happen in many states; in many regions of the country, we are going to have a heterogenous, overlapping mix of models that align around many different kinds of regional and organizational lines.
The second model is that each state maintains an MPI and a registry not of documents, but of data homes for the patient. This would be a pure Markle-style RLS -- it doesn't tell anyone what records I have, just where I've designated my medical home or homes to be. So the nurse asks the patient: in which state or states do you receive care, the EHR does a query to the gateway which issues XCPD queries to the state level gateways, and all further transactions are XCA directly to the medical home(s). This implies many XCA nodes but few XCPD nodes.
Third, I might have access to a search engine that allows me to query directory services and get back the home community ID for BIDMC or North Oakland Family Practice. I then issue XCPD & XCA queries directly to the medical home. This implies lots of XCPD and XCA nodes on the network.
Fourth (and not incompatible with the second), I might have a health URL (a Direct Address or something similar) which could be advertised by BIDMC or North Oakland Family Practice as the locus for Direct pushes to the medical home *and* the key for directory service lookups. Otherwise, same model as the third.
Am I on the right track here?
@Keith, excellent and clear post, using analogies everyone understands to clarify technical points that most people don't understand (but are closer to, thanks to your post).
ReplyDelete@Arien, despite Keith's clarity, I agree that you've raised provocative questions about scalability in practice, not just in the design. I'm a little confused about your fourth point though. I'd think that in the ED, they would first want to "pull from" BIDMC or NOFP, rather than push to. How would the Direct Address serve as the key for directory service lookups? Are you surmising about what it might be if this health URL evolves into much more than a Direct push destination as we know it today? Lots of places will have Direct addresses as recipients, but how will they become directory services? Almost sounds like the "HealthURL" for a patient would become his unique patient identifier (? !)
@David -- the thought was to use the Direct Address/Health URL as a key to lookup the homeCommunityID. People are comfortable and conditioned to remembering and typing in e-mail addresses or URLs, OIDs not so much. (BTW, I meant to type "Fourth (and not incompatible with the *third*)" up above).
ReplyDeleteJust to highlight what David picked up on, I'm not so interested in technical scalability, but in how the clinical dialog maps to the technical dialog. In epSOS, it makes perfect sense for me to ask Austria for the record if the patient is in France and there are only 20-some EU member states and regions that will be in the potential UI dropdown (and a trivial mapping that the gateways can make between country and OID). If there are 300-500 HIOs in the US, the system can scale just fine technical, but doesn't have "human" or cognitive scalability.
ReplyDelete@Arien You mentioned alternatives and a specific use case, let's look at a couple of ways that might work. I'm going to equate a Direct Address with an Identifier because it is one.
ReplyDeleteWhat you do know:
Patient Demographics, including name, address, birthdate and gender.
What you should also know:
Some identifier, like the patient's health plan ID, ACO/Medical Home id, and/or drivers license or state ID number.
What you might also know:
Patient's PHR Direct address (ID), GP/ACO Direct address (ID), PCP Provider ID, et cetera.
Using XCPD, you can transmit patient related identifiers like their PHR Direct address, health plan ID, ACO/Medical Home ID, and/or driver's license/state ID number in the XCPD query. When there is a PHR Direct Address, Health Plan ID, or ACO/Medical Home ID, you can use the information about who created the ID to get to the endpoint that can resolve the XCPD query, and then perform the query. Note that I've made no assumptions here about who could do it, and in fact, all of them might be able to.
The provider ID can also be transmitted in the query, using either NPI, or the provider Direct address. All you really need is a single OID to indicate that that the identifier being used is a Direct address. That can also be used to resolve to a location that can give you the end point where the XCPD query will be resolved.
So, human scale is to use the information gathered in the workflows we already have today, we can add in the Direct Address, and we can add in an ACO Identifier.
Any of these work, and in fact, I suspect that we should make sure that all of them do, so that there is not just "one path to success", but that all paths lead to it.
Here's where the lego analogy proves really useful. In the first case, the "Initiating Gateway" is the edge system, and the "Responding Gateway" is the local HIE. This is how the edge connects to the rest of the world.
The HIE uses the query parameters to find one (or more) appropriate endpoints to query to answer the question. The connector used between these two is ITI-55, and the shape of the HIE end of the connector is that of a router or directory/router.
In the second part of how this works, the initiating gateway is the HIE, and the responding gateway is the HIE or MPI at the other end of the communication. The responding gateway simply answers the question posed by the query and passed it back. In this case, the shape of the responding gateway is that of an MPI, but the connectors used are still
ITI-55.
It works, and it scales at the human level because it uses the same information we use today, or the easily memorable Direct addresses of either the patient's PHR or the patient's provider, and it also works when its just the the computers talking using all the gobbelty gook we humans don't care to remember.
Arien and Keith -
ReplyDeleteNote that the way you are using the "Direct Address" is exactly as designed in the XCPD context, and very much like a "Voluntary Patient ID". That is a patient ID that the patient is in total control of.
Arien, XCPD is a working instance of the abstract concept defined in the Markle RLS. A good example of using the SOA concepts of an abstract model to derive a service interface instance. Unlike SOA, IHE only defines the interface and not all of the functionality of the service. The advantage of this is to allow creativity on how the interface gets satisfied. For example, a service instance could be designed functionally to totally hide all 600 HIEs that you are worried about and spider them. One instance might know by identity domain which are the most likely to provide results and prioritize them, while other implementations might do it differently.
+1 for the notion of using a Direct Address as the "voluntary UPID"
ReplyDelete+1 for the notion of using the "organization" that issued the Direct Address (the domain) as the point of directing a query to find out more about the patient.
If the issuing organization is a "regulated" health bank type of organization, then it might actually be able to directly respond to an XCA/XDS query (from the local EHR) and return the necessary data.
Or, if the issuing organization is a less strictly defined entity, perhaps like a PHR, then it might be able to respond with an XCPD-like response detailing the regional locations known to have patient data, to which the XCA/XDS queries could be sent.
--david mcc.
Good discussion.
ReplyDeleteLet's pretend you wanted to define, not Legos, but a functional architecture for an NwHIN.
Let's pretend you had a bunch of states, all with different models for information sharing, all with different privacy laws.
Let's pretend that the business model for trans-regional shared services was not yet fully established, there was a bit of money out there, but no commitment for long-term governmental funding, and, just to make it crazy talk, imagine there was both a financial crisis, and an ongoing discussion towards minimization of governmental services.
Let's also pretend that there were a bunch of local communities, organized around business lines, and a move to create additional incentives for such communities to form around patient-centered care. Assume the number of such communities is rather large, and that there is no simple or easy law to the geography of such communities (i.e., communities will overlap, will follow a power law for size of community, and will not respect state-based boundaries).
Let's pretend there was a strong bias against models that require centralized storage of patient data.
Let's also pretend that there was a diverse and changing marketplace, and no certainty about how the final business model or models was going to shake out.
Let's pretend that we had some tools to nudge, but not order, organizations (including states, health systems, technology vendors, etc.) in a direction, but that the architecture needed to be robust to lots of variation in how.
Let's also pretend, again, that we know how the underlying Lego parts work. We get the concept of gateways, homeCommunityID OIDs, gateway to gateway queries, etc.
Under the hood, someone or something is going to need to translate the clinical context we started with (patient, receives care at a provider or system, with some reasonable data about both) to [an|a set of] XCA endpoint(s). (Let's assume magically that trust, identity, etc. are solved -- we only need to discover the RLS and use it to discover the data home(s)).
I want to know what the "tools to nudge" should be.
I had a whole long post that seems to have disappeared. It was brilliant, though :-).
ReplyDeleteI might re-write it, but at this point, I'm interested in the following answer:
"The HIE uses the query parameters to find one (or more) appropriate endpoints to query to answer the question."
That's what I'm interested in. How is that done, and I mean practically, in a way that allows giving advice to, say, a state or ACO who wants to connect to NwHIN.
I'm a gateway. The data I have to go on is demographic info, address, birth place and address, patient IDs and provider IDs.
I need a mapping table that allows me to take those parameters and figure out which nodes to multicast XCPD queries to? (e.g., if address == CA, query CA XCPD node, if provider ID (or Direct Address) == blah, query BIDMC XCPD node).
How do I get that mapping table on my local gateway? Who's the authoritative answer for that? Is that stored in the UDDI directory? (and does that continue to imply a single centralized UDDI directory?)
Arien, I saved your response from the spam filters. Your second post boils it down to essentials.
ReplyDeleteYour question amounts to: What technology can be used to resolve an address or identifier to an XCPD or XCA endpoint. UDDI is one possible solution, but you could also use DNS SRV records as well, and LDAP and provider directories might also provide a solution.
I have some questions that might help us evolve a solution. Does the NwHIN have or support any infrastructure of it own? Directories? DNS? UDDI?
What else is out there?
Before we spend time on a solution, it would be helpful to understand what infrastructure is available to play with.
I don't doubt that a solution is possible, because I can think of at least three (all of which may have holes in them).
NwHIN has a UDDI central directory, currently only used to map the OID to the WS endpoint.
ReplyDeleteThe discussion continues here.
ReplyDelete