T6

3 Use-Case View

The RLS system architecture is primarily driven by the functional requirements of the health information network. Functional requirements are captured in use case models or requirements definition documents, as well as vision and mission statements describing the longer term strategy. In addition, architectures have technology drivers and need to be cognizant of constraints of the information processing environment in which the system operates and the technology platforms used to implement the architecture.

The Use Case view represents the end users view of the system, and provides insight into the business goals of the system. Use cases represent the interactions that take place between the system and its users. Use case diagrams provide a schematic view of the end-user requirements that the system expects to satisfy. Use cases do not capture all the functionality of a system, only the users’ activities with respect to the system. Also note that use case specification diagrams need to be supplemented by textual descriptions that provide details of the requirements, which are not provided in this document.

3.1 RLS Functions

RLS is intended to serve as a key infrastructure element in a regional health information network. RLS primarily maintains an index of pointers to the network location of patient information, but not the personal health information itself. The index of pointers is akin to a ‘master patient index’ as deployed in integrated healthcare delivery networks with multiple independent clinical systems maintaining patient records.

RLS serves as a coordinating service that obviates the need for a national health identifier, by linking diverse patient records across distributed clinical data sources through probabilistic demographic matching techniques. Such a service can facilitate a federation of diverse clinical data sources to enable a consolidated view of a patient’s electronic health care records. The clinical data nomenclature includes a range of information from medical records in provider systems, dispensed drug information at pharmacy systems, to administrative and financial information in payer systems. 

Various institutional models have been discussed for ownership and operation of an RLS. In the current environment, the logical organizational framework for an RLS would seem to be a regional health information organization (RHIO). RHIOs are considered key elements of the strategy for constructing an interconnected and interoperable network of networks that forms the national health information network (NHIN).

Massachusetts SHARE (Simplifying Healthcare Among Regional Entities), a regional collaborative initiative operated by the Massachusetts Health Data Consortium, may play the role of a RHIO. One of MA-SHARE’s goals is to create a sustainable community utility for clinical connectivity and data exchange. The future extension of RLS to serve as such a utility is a consideration in its architecture.

While RLS primarily supports individual caregivers by facilitating access to aggregated patient information, it may facilitate information sharing across other authorized stakeholders as well, including the patient. A longer term ‘concept of operations’ view of RLS is shown in Figure 2.

Figure 2: RLS Long term Concept of Operations

3.2 Use Cases

The architecturally significant use cases of RLS are shown in Figure 3. The primary end user function of RLS is to provide healthcare practitioners with pointers to clinical data stored at distributed network nodes. To establish context it useful to understand the complete usage scenario from a healthcare practitioner’s perspective, which would include subsequent retrieval of patient records. Patient records retrieval is not an RLS function, and is shown as a separate ‘clinical data exchange’ service in the use case diagram.

Actors are entities (both human and system) that interact directly with the RLS. RLS actors include:

1. Healthcare practitioners: Individual care providers who have been assigned rights to access a patient’s clinical record. This category includes providers, payers, diagnostic services etc., as well as the patient.
2. Clinical Data Source: The information systems in use by a healthcare provider or payer to maintain patient related information. Data sources encompass systems at physician offices, hospitals, laboratories, imaging centers, pharmacies and other healthcare service entities.
3. RLS Administrator: Persons (or entities) authorized to administer the Record Locator Service and the community patient index as may be required. Note: this role is expected to be progressively automated as the RLS implementation matures.

Figure 3: RLS Prototype Use Case Diagram

Note that the core RLS function is only to locate patient records. This essentially implies providing indexing services for distributed clinical data sources, which publish patient registry events into the RLS. This separation of services is a key aspect of the CfH strategy which seeks to decouple the standards and policies relating to separate functions of the network.¹⁰

The following use cases are architecturally significant to the RLS, in that they exercise critical aspects of the system architecture:

Table 1: List of Architecturally Significant Use Cases

3.3 Use-Case Realizations

The patient lookup and patient publish use cases are both realized through messages sent securely from nodes in the health information network to the RLS requesting lookup and publish services respectively. The ‘lookup patient’ and ‘publish patient index’ use cases are realized in the manner shown in the activity diagram in Figure 4.

The swimlanes in the activity diagrams correspond to the actors shown in the use case diagram. Healthcare practitioners and clinical data sources are roles played by entities such as hospitals, physician practices, diagnostic services, payers, public health agencies etc. Thus, a provider system at a network node could play the role of a clinical data source, and also be the channel through which healthcare practitioners access the RLS.

While the core functionality of RLS is to support publishing into, and searching the CMPI, the RLS-based network would require information processing in each of the nodes interacting with the patient index to support secure, reliable and standards based communication between them. This communication function is the core of the common framework that enables the various network nodes to exchange information with the RLS and with each other. The communication functionality at these nodes share many common processing capabilities which may be encapsulated into a common technology artifact as shown in Section 4.

Figure 4: Lookup Patient and Publish Patient Index Activity Diagrams

Other functional aspects that influence the RLS architecture include:

3.4 Security, Patient Privacy and Consent Management

Protection of patient privacy is a legal and regulatory requirement that is realized through system security as well as policies implemented by the RLS and the various participants in the healthcare information network. Patient and healthcare practitioner trust in the security and privacy protection features of the RLS-based network is a critical pre-requisite to its success.

Privacy protection is based on restricting network access to the data to only authorized personnel, monitoring all access to patient data to audit the operational use of the network, and implementing architectural safeguards to manage the risk of accidental or malicious spillage of data in the course of network operation.

3.4.1 Identity Management

The RLS is intended for use by large networks of healthcare enterprises, each of which may have large user end user populations. RLS must not be required to manage the network identities of all individual users. End users (healthcare practitioners) are authenticated by the enterprise to which they are affiliated and referred to RLS as authenticated principals. Identity management is a local function. Patients who use hospital / IDN patient web sites are referred to RLS as authenticated principals by the clinical systems at the hospital / IDN. RLS and all participating entities have the ability to mutually authenticate each other before exchanging data.

3.4.2 Confidentiality, Authentication, Integrity & Non-Repudiation

The RLS network architecture uses the following high level security requirements in implementing messaging as well as application data management:¹¹

• Confidentiality: Information shall only be disclosed to authorized users who need it for healthcare treatment, payment, or operations.
• Authentication: Receivers of requests for information shall be able to verify the identity of the requester. A network participant shall not be able to masquerade as anybody else.
• Integrity: Communication between network entities shall be protected against unauthorized alteration, and all alterations shall be logged. Receiver shall be able to verify that the message has not been altered.
• Non-repudiation: Transactions cannot be unilaterally revoked or altered by either party. A sender cannot falsely deny sending a message and a receiver cannot falsely deny receipt of a message.

3.4.3 Patient Data Privacy

The health information network is architected on the presumption that data privacy is easier to protect locally, i.e. on the edges of the network where data are stored. Release of information from the clinical data source to healthcare practitioners is governed by policies established and maintained by the data source.

RLS, being a directory of patient record locations, is itself a source of protected health information. RLS shall publish and maintain a clear policy governing discovery of patient information in the directory. The specific rules governing sharing of RLS directory information pertaining to individual patients are created by the patient and provider at the time of the encounter and communicated to the RLS along with the message of that encounter event.

Healthcare information networks need to pay special heed to ‘sensitive’ data disclosure:

• There are categories of medical information that need additional safeguards which RLS should be cognizant of. These include mental health, AIDS, and substance abuse related care data.
• While RLS does not itself retain patient care data, the availability of patient records at a mental health facility is itself disclosing. RLS access control policies should be informed by such considerations.
• The patient consent process should be capable of allowing the patient to set varying restrictions on the different categories of sensitive data.
• A ‘break-the-glass’ function should allow authorized providers to override patient privacy constraints in emergency situations that require access to sensitive data. 

3.4.4 Consent Management

Some states require that explicit patient consent be obtained to share their medical records across the network. There are varying degrees of restrictions of privacy / consent requirement and RLS must be capable of handling this variability. The following policies have been proposed for the RLS-based health information network to manage the consent process:

• Require that patients be fully informed in writing of a provider’s or health plan’s participation in the RLS before their information is exchanged through the network; 
• Mandate that the written notice given to patients contain certain disclosures about how information is used and exchanged through the RLS
• Permit providers and health plans to include the disclosures about the RLS in their HIPAA privacy notices
• Give each patient the right to decline to have their information exchanged through the RLS (“opt-out”); and 
• Prohibit providers and health plans from withholding treatment or benefits to patients who have opted out.

3.5 Patients Records Linking and Matching

The key function of the CMPI is to link patient records across different institutions, each of which maintains patient data independently and, often, inconsistently. Various algorithms are available for matching person records based on limited sets of demographic attributes, for which software implementations exist. The algorithms should match the patient attributes used as search criteria with those in the CMPI records using NYSIIS matching, digit transposition checks, etc. RLS should be capable of using integrating with a variety of patient matching software.

Two models exist for implementing the linking / matching process.

• Patient records may be linked when they are loaded based on running a matching algorithm with the rest of the patient records in the database. An online query would then be matched using the same algorithm to the pre-linked records. This process is typically supported with some level of human disambiguation of data. For example a data administrator may examine records that match marginally and manually ascertain a positive or negative match. Note: this function could potentially grow into a large data maintenance organization.
• Matching is done during a RLS patient lookup query, but no explicit linking of records is done in the CMPI database. Very fast database matching speeds have been achieved using probabilistic algorithms that also provide high assurance of no false positives. A disadvantage is that this completely automated process could potentially result in higher false negatives. Patient privacy considerations (no false positives) imply high thresholds for probabilistic matching, which would miss patient records that match marginally.

Human disambiguation of patient matching results is considered undesirable. While an interactive narrowing down of patient matches may be appropriate within a hospital setting where the degree of trust is high, this is considered unacceptable when RLS is serving as a CMPI to multiple institutions. Therefore, probabilistic matching algorithms should have their positive match threshold set high enough to reduce the percentage likelihood of false positives to negligible levels.

• RLS patient lookup service shall not support wild-card matching. This could open the door to database fishing which would be an egregious violation of patient privacy principles.
• RLS should support the retrieval of record locations using a local patient ID.
  • There could be situations where a patient is well-identified locally (e.g. has a long-established MRN). It should be possible to get the linked records from RLS rather than do a demographics attributes based search
  • This may technically be considered a subset of the demographics based search. RLS maintains both patient source institution and institution local MRN.