T2

2  Interaction Overview

Technical interactions between entities in the NHIN involve transactions between software clients (typically an EHR, secure browser, or proxy server, and called NHIN clients throughout) and either the RLS or the ISB.

2.1  RLS Use Cases

The Record Locator Service (RLS) is essentially a master patient index within a SNO that refers to record locations at more than one institution within that SNO. It has two required interactions with the participating entities in a SNO: it accepts updates to patient demographics and record locations; and it accepts queries for the location of patient records and returns record locations when it finds matches.

Accepts Updates to Patient Record Location

The RLS accepts updates to patient record locations held by participating sources of clinical data. These updates contain identifying details of the patient, the identifier of the source system, and a medical record number (MRN) unique key for the location of that record within the source system. In practice, this will often be expressed as a Uniform Record Identifier (URI), but may include other formats, such as fax numbers as contact details for those queries that can't be made over the Web.

The intent of these updates is to provide the raw information necessary to accept demographic queries for patient records, and to be able to return a unique pointer to the data for patient records that do match. The four possible modes of behavior that a clinical data source may request of the RLS are: add a new record number and attendant identifying data; update an existing record; remove a record; and merge or unmerge two records (though merge is actually a composite function, acting as an atomic update+remove function acting on two records at once). The updates will generally be in batch mode, and may in some cases even be loaded from physical media. While a rapid cycle for updating pointers to materials held in the various source systems is desirable, the loading of the data and the return of the confirmation can be asynchronous.

Because of the variability of delivery of data sources from participating entities and of the patient databases underlying any given RLS, the methods for loading records may vary SNO by SNO, and are not specified in this guide.

Accepts Queries and Returns Record Locations

The RLS accepts queries from authorized entities looking for patient records. The queries will include demographic details of the patient whose records are being sought, and, optionally, an institution ID and MRN.

The RLS must have a method for determining which patients, if any, match the demographics presented, and must guarantee that the chance of a false positive falls below the target threshold for incidental disclosures. This matching algorithm is not part of the RLS itself, but is an internal service the RLS relies on, and can vary between SNOs, so long as whatever matching algorithm is used produces sufficient accuracy of matches.

The RLS should return the locations of the records that match the submitted demographics and are above the target threshold for accuracy of match. These records will be ideally expressed as a URL that fuses the institution location with the MRN. However, other methods for requesting record information, such as phone or fax numbers of those institutions operating without an electronic health record (EHR) system may be returned when the location can't be expressed as a URL.

Patient queries will generally be in synchronous request-response mode, and should be optimized to operate as near real time as possible. It is possible that a clinic, for example, will want to submit batch or asynchronous individual queries to obtain record locations for the following day's visits, but the querying capability should be designed and optimized for real-time and synchronous requests as the principal interaction. Additionally, the SNO can allow or provide for the use of proxy servers to aggregate the clinical results on behalf of the requesting client. For a more complete description of questions of synchrony and aggregation, see “The Common Framework: Technical Issues and Requirements for Implementation document.”

The interaction between the RLS, the clinical data sources, and the requestor of data locations can be seen in the following diagram. Note that the requesting and return of the actual records does not involve the RLS directly, but is listed here for conceptual completeness:

Figure 1: RLS Interactions

2.2  ISB Use Cases

The Inter-SNO Bridge (ISB) is an interface to a particular SNO, for queries originating from outside the SNO (either from another SNO, or from unaffiliated entities). It exists to simplify conversations between remote entities, so each institution is not required to know the names of all other institutions (which would create significant problems of scale). Instead, by routing NHIN traffic between SNOs, and by having each SNO manage its own internal traffic (which is has to do anyway), the problem becomes much smaller. In addition, it provides a highly observable point for all remote traffic, benefiting security.

The ISB has a single required interaction with outside entities—it receives requests for patient records in exactly the same format as an RLS does, and it returns either a) the locations of those records for further use by the requestor (the 'two-pass' pattern) or b) acts as an aggregator of the records themselves, and returns the aggregate clinical data (the 'one-pass' pattern).

Two Pass

The ISB accepts queries from other SNOs looking for patient records. The canonical conversation is between the ISB of the requestor and the ISB being queried; both ISBs must have valid SSL certificates. Other than specifying an address of the SNO to be queried, the queries are otherwise identical to those made to an RLS, and will include demographic details of the patient whose records are being sought, and, optionally, an institution ID and MRN.

The ISB will confirm receipt of the query, record the address where the results should be returned, and then pass the query to its local RLS, exactly as if were an ordinary entity within the SNO. If the requesting SNO has requested a two-pass interaction, the ISB will receive the record locations from the RLS (or, optionally, any additional proxy servers used by the SNO), and will then initiate a second transaction with the original requestor.

The original requestor may then choose any or all of the record locations it would like to receive data from, and will dispatch a second query to the ISB listing those locations. The ISB will confirm receipt of the second query, record the address where the results should be returned, and then ask the local entities (or any optional proxies) for the records themselves, exactly as if were an ordinary entity within the SNO. The ISB will receive the records from the local entities (or proxies), and will then initiate a transaction with the original requestor to deliver the aggregate records.

Interactions with the ISB will always be asynchronous; the requestor must specify an address where the results of the query will be deposited. For a more complete description of questions of synchrony, see “The Common Framework: Technical Issues and Requirements for Implementation document.”

The two-pass interaction between the ISB, the local clinical data sources, and the requestor of data locations can be seen in the following diagram:

Figure 2: ISB Two Pass Interactions

One Pass

The ISB accepts queries from other SNOs looking for patient records. The canonical conversation is between the ISB of the requestor and the ISB being queried; both ISBs must have valid SSL certificates. Other than specifying an address of the SNO to be queried, the queries are otherwise identical to those made to an RLS, and will include demographic details of the patient whose records are being sought, and, optionally, an institution ID and MRN.

The ISB will confirm receipt of the query, record the address where the results should be returned, and then pass the query to its local RLS, exactly as if were an ordinary entity within the SNO. If the requesting SNO has requested a one-pass interaction, the ISB will receive the record locations from the RLS (or, optionally, any additional proxy servers used by the SNO), and will then initiate a second set of transaction with the local holders of the record specified by those locations. The ISB will receive the records from the local entities (or proxies), and will then initiate a transaction with the original requestor to deliver the aggregate records.

Interactions with the ISB will always be asynchronous; the requestor must specify an address where the results of the query will be deposited. For a more complete description of questions of synchrony, see “The Common Framework: Technical Issues and Requirements for Implementation document.”

The one-pass interaction between the ISB, the local clinical data sources, and the requestor of data locations can be seen in the following diagram:

Figure 3: ISB One Pass Interactions

2.3  NHIN Data Interchange

All messages in the NHIN, whether within or between SNOs, are specified as client/server SOAP conversations. A client requesting information within a SNO of which it is a member formulates its data query and sends it to the SNO’s RLS. A client requesting information from a SNO of which it is not a member formulates its data query and sends it to the remote SNO's ISB.

NHIN queries are based on the HL7 query model. A single NHIN query-and-response may consist of one SOAP conversation (a “synchronous” query-and-response) or two SOAP conversations (an “asynchronous” query-and-response, where the request and the subsequent delivery of results are two separate transactions). In the synchronous query-and-response case, the query is sent in the SOAP request message and the query results are returned in the SOAP response message. In the case of the asynchronous query-and-response, the query is sent as the SOAP request and simply acknowledged in the SOAP response. In a subsequent SOAP conversation, the query results are sent back to the query client as the SOAP request message and simply acknowledged in the corresponding SOAP response.

RLS Data Interchange

When a NHIN client sends the SOAP query to the ISB (the NHIN server), the ISB immediately acknowledges receipt of the query and terminates the SOAP communication. The ISB probes the databases(s) within its SNO to get the requested data. Once that is complete, the ISB generates the query response, opens a new communication channel back to the client or its designee, and returns the response information.

When the RLS receives a query, it may satisfy that query in any manner it so chooses, as long as it interprets the query according the rules set forth in his document and responds to the query in the format prescribed herein. For example, one SNO might contain a central server on which health data is aggregated from all of the other SNO members. That SNO’s ISB responds to a patient-based NHIN query by reading data from its single aggregation server and responding to the NHIN client. Another SNO might have no central aggregation of data. When that SNO’s ISB receives the same NHIN query, it would interrogate all of its other SNO systems to obtain the requested data. Several NHIN prototype systems have an approach somewhere in between these two paradigms. Those SNOs maintain an aggregated (community) Master Patient Index (MPI), but do not aggregate any other clinical content. For a patient-based query, the ISB for one of those SNOs would query the aggregated MPI to find out which other SNO nodes might contain the requested data and then query only the potential data-bearing nodes for information.

SNO Data Interchange

When a NHIN client sends the SOAP query to the ISB (the NHIN server), the ISB immediately acknowledges receipt of the query and terminates the SOAP communication. The ISB probes the databases(s) within its SNO to get the requested data. Once that is complete, the ISB generates the query response, opens a new communication channel back to the client or its designee, and returns the response information.

When an NHIN server receives a query, it may satisfy that query in any manner it so chooses, as long as it interprets the query according the rules set forth in his document and responds to the query in the format prescribed herein. For example, one SNO might contain a central server on which health data is aggregated from all of the other SNO members. That SNO’s ISB responds to a patient-based NHIN query by reading data from its single aggregation server and responding to the NHIN client. Another SNO might have no central aggregation of data. When that SNO’s ISB receives the same NHIN query, it would interrogate all of its other SNO systems to obtain the requested data. Several NHIN prototype systems have an approach somewhere in between these two paradigms. Those SNOs maintain an aggregated (community) Master Patient Index (MPI), but do not aggregate any other clinical content. For a patient-based query, the ISB for one of those SNOs would query the aggregated MPI to find out which other SNO nodes might contain the requested data and then query only the potential data-bearing nodes for information.