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?