Monday, February 28, 2011

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?

5 comments:

  1. Another point to mention is that some home communities might be interested in farming queries out to other close-by locations. The Northern NJ NHIO might also check NY City, and the Trenton NHIO might also check in with the Philadelphia NHIO for example.

    ReplyDelete
  2. Here's what I think you are (or what I interpret you to say based on what I know of the underlying specs):

    1) The NwHIN Patient Discovery (XCPD) and Directory (UDDI) define appropriate constraints on the IHE and OASIS specs
    2) Nothing in them defines or constrains an architecture for XCPD discovery, defines a recommended algorithm to follow, or constrains an onboarding process
    3) The UDDI spec for NwHIN allows for keys (great) but does not define a constrained vocabulary for keys (not so great)

    To define the flow you describe, we need a model that allows:

    1) An NwHIN Participant to define the categories for which it is authoritative (or at least may be a good place to look)
    2) Those categories need to be standardized

    Right now, the single allowed categorization is: "uddi:uddi.org:ubr:categorization:iso3166" for registering the state name.

    Based on the NwHIN UDDI spec, the only approach for looking up XCPD endpoints is:
    1) By homeCommunityID OID (implying that someone has a hard-coded list of OID to organizations) or by state.

    This implies an architecture where XCPD queries can be done only to well-known organizations (e.g., Kaiser) or to a state (which then must serve as the authoritative gateway for either maintaining a single MPI or multicasting to registered sub-HIOs.

    If we want the more flexible architecture you describe, we need to:

    a) Expand the known key types available in the UDDI registry and
    b) Define the algorithm for XCPD lookups (right now, even the spare algorithm I described is undocumented)

    ReplyDelete
  3. I think you've got it. One key type can be Health Domain name, another is as you say, the home community ID OID, and another state.

    ReplyDelete
  4. Keith, The NHIN endpoint address is an 'identifier'. Please don't try to take an identifier apart and interpret the component parts. The domain part might be owned by a PHR or HISP provider; but it could also be owned by a simple e-mail provider (e.g. gmail, hotmail, etc). Identifiers are identifiers.

    Arien, you seem to be implying that you want a network that is dynamically built with no prior knowledge. Even in NHIN Direct this doesn't happen. With an architecture where one is allowing QUERY and RETRIEVE there is a much stronger need to know 'who are you querying, are they an authority, are they trustworthy, do they maintain records accurately', and in the other way a service needs to understand 'who is asking for this information, should I trust them, do they understand my language, do they agree to highlevels of policy'. These are preconditions, otherwise one could see ANYONE (e.g. bad-guy) querying and retrieving all the data they want; or someone (e.g. bad-guy) putting up a service that provides false data that could cause harm or allow them access to valuable things.

    To the extent that we can, we allow late-binding; this is what XCPD and XCA do allow. These things have been discussed in detail in the committees; at IHE and at NwHIN Exchange (and to an extent at HITSP before that). These discussions have been informed by GLOBAL projects such as epSOS. Many times over. So to open these issues up co casually is very frustrating to those of us that have already had the discussions multiple times.

    Worse yet is to open these discussions up on a BLOG, or in a FACA committee meeting where those with the answers are kept behind a 'public-mute' with only the opportunity to make a comment at the end of the committee meeting after minds have been made up.

    I want TRANSPARENCY. That to me is OPEN and INCLUSIVE.

    ReplyDelete
  5. John,

    The NHIN Direct Address has two parts, one of which is DEFINED to be the Health Domain Name. So, I can, by definition, take it apart to see if there is an organization supporting XCPD behind it.

    On your last point, yes, I think this discussion has reached a point where it needs a project that is transparent, open and inclusive.

    Keith

    ReplyDelete