Record Location Services at a National Scale using IHE XCPD

One of the recent discussions coming up around the most recent TEFCA related specifications has to do with how one might implement record location services for patients at a national scale.  The basis for this is the IHE Cross Community Patient Discovery Profile (XCPD).

Here's the problem in a nutshell.  Assume you are a healthcare provider seeing a patient for the first time, and you want to find who else might have information about this patient?  How can you do so?

The first step obviously is to ask the patient who their prior doctor was, and here's where the first fundamental challenge appears.  Sometimes the patient is unable to answer that question, either at all, or at least completely.  So, then, how do you get a complete list?  What you don't want to do is ask everyone who ever might have seen the patient anywhere in the country, because that is not going to scale.

I think that about sums it up.

The IHE XCPD profile is designed to address this.

If the patient is only able to give a partial response, then you know where to start looking.  Here's the key point, once you know where to start looking, the organizations and networks who can answer the question can also point you to others who've seen the patient, and that can get you a more complete list, which eventually will lead to closure.

But wait! How do these organizations know who else has seen the patient?  It's really pretty simple.  Somebody asked them, and in the process of asking them, also told them that they would be seeing the patient, and so the original provider gains the information about the new provider seeing them, which makes them able to answer the question accurately for the next new provider.  And so the well known provider becomes more authoritative, while the new provider is able to provide equally authoritative data.

If the patient is unable to answer that question at all, then you have to figure out who else you might be able to ask that question of.  If the patient is local, you could ask others in the area who might know the patient.  If the patient isn't local (e.g., just visiting), you might try asking others near to where patient resides, which hopefully you can determine.  Since TEFCA is about a network of networks, it's reasonable to assume that there are some regional networks of whom you might ask about a given patient, and they might be able to ask other, smaller regional networks they know about (this could become turtles all the way down, but at some point, you'd expect to stop).

There are some other issues to address.  Just because we got the new provider and the old provider synchronized, doesn't mean everyone else is.  Who has that responsibility?  That's an implementation decision.  It could be the original provider, or it could be the new provider.  Since the new provider is gaining the benefit, one could argue it's there responsibility to notify other networks that have already seen the patient that they are now seeing the patient.  That would be the way I'd implement it.

Note: This doesn't have to be perfect.  It has to be good enough to work.  Perfecting the algorithm for record location to ensure the right balance of performance and accuracy in the RLS is going to take time.  But we can certainly build something that gets the right networks talking to each other.

IHE IT Infrastructure Technical Framework Documents Published

IHE Community:

Supplement for Trial ImplementationThe IHE IT Infrastructure Technical Committee has republished the following supplement to the IHE IT Infrastructure Technical Framework for Trial Implementation as of March 4, 2011:

• Cross-Community Patient Discovery (XCPD)

This profile will be available for testing at IHE Connectathons beginning in January 2012. The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm#IT. Comments should be submitted to the online forums at http://forums.rsna.org/forumdisplay.php?f=198.

White Paper for Public Comment
The Committee has also published the following White Paper:

• XDS Patient Identity Management

The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm#IT. Comments should be submitted to the online forums at http://forums.rsna.org/forumdisplay.php?f=198.

Patient Discovery

I started a discussion on building blocks last week.  There are still some ideas kicking around that need more exploring around the concept of Patient Discovery.  The concept is important enough that the NwHIN Specification Factory devoted a specification (pdf) to it.

That specification makes some assumptions:

1. The initiating NHIO has identified other NHIOs likely to hold a specific patient’s information. Patient Discovery requests are not intended to be broadcast across the NHIN.
2. The initiating NHIO provides patient-specific demographic data for use by the responding NHIO to evaluate whether the patient is known to the responding NHIO.
3. If the responding NHIO makes a match, it provides the set of demographics locally associated with of the matched person to the initiating NHIO who can either trust the candidate match, or use the returned patient demographics to evaluate the candidate match.
4. The specification allows NHIOs to independently make identity correlations based on their own algorithm and not that of another NHIO.

The assumptions become the basis for creating a specification allowing the discovery patient data at other NHIOs (I'll use their acronym, just think of it as an HIE).  But assumption number 1 is problematic.  It assumes that there is an easy way to identify the other NHIOs, and there probably is, but the way to go about it isn't described.

Let me recap what we know:
Required: Patient Demographics, Name, Address, Gender and Birthdate
Highly Likely: Other Patient Identifiers
Possible: NwHIN Direct PHR address for the patient or their healthcare provider, or other identifiers for the same (e.g., from an NHIO Patient Identity Card).

This is presumed to be known by the "Initiating NHIO", and so can be used in that first step of identifying other NHIOs that are likely to hold the patients information.

Let us assume that there is a "Home NHIO" for the patient, and that this Home NHIO has several responsibilities.  One of these responsibilities to to ensure that there is an XCPD end-point that can be used for notifications and queries.  Another is to maintain a registration record in the NwHIN UDDI registry that points to that end-point.  (There's a spec [pdf] for that also).  There's one more responsibility, but we'll get to that in a minute.

There is one key operation:
Locating the Home NHIO:
If a Patient Identifier is specified and that is an NHIO Patient Identity, obtain the Home NHIO identity from the NHIO Patient Identity.  That could be algorithmic, or printed as one of the many identifiers on an NHIO Patient Identity Card.  This could even be reported as the NHIE Home Community ID.  Prescription drug benefit cards already contain an identifier that indicates where to send the drug benefit transactions.  We could do the same for NHIO Patient Identities.

If a Patient Identifier is specified as an NwHIN Direct address, use the health domain name as the NHIO Identifier.

Lookup the NHIE XCPD endpoint using the NHIO Identity.  This is where you would send the XCPD query and notificatin messages.

Once you have the Home NHIE(s) (there could be several), perform the XCPD query against it(them).

Payers could get into the act too.  All they'd need to do would be to expose an XCPD end-point, and register it in the NwHIN UDDI registry. 

What if you didn't have an NHIO Identifier for the patient?  Well, how about trying to use the patient's address to resolve the possible NHIOs?  That could work.  All you'd need is the State.  Of course if they lived in California or New York, you might still have 10-20 NHIOs to deal with, but you might be able to resolve that better if you have some regional data to work with, and that is still much better than 200-300 NHIOs to query.

A couple of points of protocol are needed:

1. If you aren't the Home NHIO for the patient, yet records get stored in your NHIE, notify the appropriate Home NHIO(s) of the update so that they can keep up with who has records for the patient.
2. If you are the Home NHIO, maintain a record of the Home Community ID for the notifications you've recieved, and return them as appropriate to queriers of information.

So, now we need to update the NwHIN UDDI specification to support storing end-points for the XCPD service.  Wait, that's already done.  Ok, so we need to assign identifiers to home communities.  Nope, that's done too.  So, what else do we need to do?

Seems like we need a 1 pager to spec the protocol.  Nah, that's already done here.

Any questions?