Why are provider directories important?
When you think of the 3 necessary components to transport healthcare data from point A to point B, you need a routing method (REST, SOAP, SMTP), a directory that tells you where to route, and certificate management to ensure the message is not read or modified during transmission.
The granularity of the directory(organization level or person level) has been a major part of the discussion.
If you want to route a message to John Halamka, do you route it to me as a person or BIDMC as my provider organization? My EHR is hosted at the organizational level, so if you want to route it into my EHR, you should send it to my organization. I may have different preferences for communication depending on the urgency and the time of day/day of week. Such detailed communication preferences are best implemented at the local organization level, so once the data arrives at the organization it can be further routed.
Another advantage of organization to organization communication is that fewer certificates are needed. There are 70 hospitals in Massachusetts with 20,000 doctors. It's much easier to manage 70 certificates than 20,000.
The details of how organization to organization directories should work is outlined in the Provider Directory task force materials.
In Massachusetts, we've implemented a slightly different approach. The New England Healthcare Exchange Network (NEHEN) is a set of organization to organization gateways. It works well for administrative data exchange and e-prescribing. Although it is being used for clinical summary exchange, the challenge from a user's viewpoint is figuring out the right organization to receive data for a given clinician. If I want to route a clinical summary to Dr. Bob, how do I know what organization hosts his EHR? What if he works at multiple organizations?
Here's what NEHEN has done per Greg Debor's testimony to the Provider Directory Workgroup.
'NEHEN administrative message handling and e-prescribing are based on preconfigured addressing schemes designed to deliver a message to a predetermined organization. Program management staff maintain addressing tables and distribute them with NEHEN software. This method easily supports routing an insurance eligibility request or claim to a payer, for example, or an electronic prescription to Surescripts for machine-to-machine processing.
Clinical health information exchange, however, is not nearly as straightforward. There are multiple orders of magnitude more potential recipients, making centralized maintenance impractical and costly. Many recipients may not be known to the sender, requiring a lookup capability akin to using an online Yellow Pages or White Pages directory. In addition, not all processing by the recipient will be machine-to-machine, requiring some knowledge of the receiver�s preferences for fax, e-mail, human readable documents or EHR integration. Recipients may delegate processing to certain staff, requiring knowledge of individuals rather than simply organizations. Finally, the more sensitive nature of clinical information requires more complex access control to track and determine who at a recipient organization has been authorized to handle and view the information.
NEHEN has developed and deployed a Community Participant / Provider Directory to support these aspects of clinical HIE, along with tools to allow delegated, self-managed registration and maintenance of directory entries. The NEHEN directory supports both Yellow Page / White Page lookup and HIE routing. Participants can use the NEHEN toolset to:
*Register and maintain organization, location, provider, clinical affiliation (practice hierarchies, etc.), receiving / message delivery preferences and other data using the NEHENExpress web-based user interface
*Delegate a person or destination specified by a provider to receive an electronic clinical message in addition to or instead of the provider (e.g., another covering physician, a practice assistant or practice e-mail inbox, a fax number an EHR URL, etc.)
*Upload provider, delegation and preference data in bulk (new and updates) via a NEHEN-specified web service
*Search for participating organizations, individual providers and delegates to add and maintain affiliations and delegate instructions
*NEHEN participants can now use the data in the directory in the course of data exchange to:
Determine whether another provider is eligible to participate in clinical data exchange via NEHEN
*Obtain routing information for a provider
*Select among multiple clinical affiliations to determine where an electronic message should be routed
*View provider data, clinical affiliation data, delivery preference and delegate data
These capabilities enable a number of functions critical to solving for the complexities inherent in clinical exchange such as allowing a patient or other person, such as a registration clerk, to accurately identify a patient�s provider of care to whom clinical messages should be routed. For example, if two physicians named Smith practice in the same town, the practice name or address may be used to identify the Dr. Smith who provides care for the patient.
Allowing a receiving participant to route an incoming clinical message to the correct internal system for the provider to whom the message is addressed. For example, if a participant�s providers use separate physical instances of an EMR, the location identified on an incoming message may be used to identify the EMR instance the message should be routed to. If Dr. Smith is associated with Location A, a message for Dr. Smith can be routed to the EMR instance associated with Location A.
Discovering information about other participants� availability for clinical HIE and their routing requirements. This is equivalent to looking up a financial institution�s Bank Routing Number to determine how to accomplish a wire transfer, etc.
In designing the Community Participant / Provider Directory and functionality, NEHEN determined that no standards or comprehensive data sources are present today in the industry or cross-industry. This led to the design of a simple data scheme, the elements of which are consistent with HL7 naming and data types.
NEHEN is now in discussion with leading providers of self-managed sources of provider data to pre-populate provider tables via web services for a richer data set for NEHEN users and to simplify database maintenance. In pursuing this strategy, which NEHEN anticipates executing on in late-2010, NEHEN intends to provide its participants with provider, organization and routing data on a national level to enable data exchange across the NHIN."
Given the evolving national work on provider directories, heterogeneous state directory implementations, and emerging commercial products, it will be a very interesting year. It's too early to tell if we'll have directory convergence or chaos.