T6

This document describes the early design process for the Record Locator Service (RLS) as implemented in Massachusetts, and is included here as background on the technical conversation around the design of the Markle Connecting for Health prototype. It is included here as a background guide to the issues surrounding the design of the RLS as constructed in Massachusetts; as noted in “The Common Framework: Technical Issues and Requirements for Implementation,” the placement of aggregation services can vary between sub-network organizations (SNOs). In this document, aggregation takes place via a clinical data exchange service; other architectural models are possible.

In addition to the overview of the architectural design decisions included in “The Common Framework: Technical Issues and Requirements for Implementation,” the technical details surrounding message exchange in the current prototype are documented in the “Health Information Exchange: Architecture Implementation Guide.”

1 Introduction

The Record Locator Service (RLS) is envisioned as the key infrastructure component of the 'Common Framework,' which Markle Connecting for Health (CfH)¹ has proposed to facilitate healthcare information networks in the USA. The common framework is a set of standards, policies, and methodologies intended to ensure secure and reliable connectivity between healthcare systems and enterprises.

The common framework includes the essential set of standards and policies that would allow healthcare information networks to interoperate with each other. This would enable communities and regional networks to connect and incrementally grow into a national healthcare information network, as a "network of networks."

Building a national network through internetworking multiple regional and local health information networks implies a natural bias towards decentralization. A centralized national patient registry or clinical data repository is not considered a realistic objective. Adoption of common architecture and protocols across the networks and sub-networks would, similarly, suggest decentralization in sub-networks, with data stored in separate locations to be accessed when needed. Leaving patient data where they are now, in the healthcare enterprises’ clinical data sources also provides for appropriate patient data privacy safeguards and clear accountability for medical data ownership/stewardship.

This does not preclude sub-networks based on a regional data repository or a community master patient index. As long as the networks support the principles and protocols of the common framework, they would be capable of interoperation with other networks. Smaller participants may choose to use data aggregators to expose their clinical data securely and reliably. As the CfH Roadmap states, “Because many providers will not be able or perhaps willing to provide the levels of service required to participate in a federation, they may have to contract with business associates (in the HIPAA sense) to store their data in a repository that will sustain these service levels.”²

The common framework that underlies the decentralized healthcare information network is expected to need a small set of critical technical infrastructure components to support interoperability. The RLS is one of them.

The RLS provides authorized users of a regional health information network with pointers to the location of patient health information across the network nodes, i.e. the clinical data sources. This would enable users to access and integrate patient healthcare information from the distributed sources without national patient identifiers or centralized databases. Such an integrated view of patient clinical data would help achieve the CfH vision of improved patient safety and quality of care, and reduced costs of healthcare delivery.

Massachusetts SHARE (Simplifying Healthcare Among Regional Entities),³ a regional collaborative initiative operated by the Massachusetts Health Data Consortium, seeks to foster improvements in community clinical connectivity, allowing appropriate sharing of inter-organizational healthcare data among the various participants in the healthcare system—including patients, doctors and other practitioners, hospitals, government, insurers, HMOs and other payers. MA-SHARE promotes the inter-organizational exchange of healthcare data using information technology, standards and administrative simplification, in order to make accurate clinical health information available wherever needed in an efficient, cost-effective and safe manner.

MA-SHARE’s vision includes the goal of building a utility service that would enable member organizations to hook up to the regional healthcare network (or “grid”) simply and cost-effectively. The RLS architecture advances the design of such a utility service that would connect the healthcare systems in a community securely over the Internet.

This document describes the proposed architecture of the RLS, and provides an overview of the technical components of the common framework. The RLS prototype project tests the architecture presented here and demonstrates the viability of direct peer-to-peer interoperability of disparate electronic health record (EHR) systems that are the ultimate source of clinical data in the network. This document serves as the primary record of all architectural design decisions made in the course of developing the RLS prototype.

1.1 Purpose

The Framework Technical Overview defines and describes the basic functional components that make up the RLS, and the interfaces between these components. The document presents the RLS architecture using a number of different architectural views to depict different aspects of the system, and outlines the data and transport standards used in accessing the services offered by RLS. RLS plays a critical role in the healthcare interoperability common framework, and the RLS service architecture is aligned with the clinical data exchange processes that the common framework also supports. This document also conveys the architecturally significant trade-offs and decisions which have been made in designing the system and the network.

Business stakeholders may use this document to validate the functionality of RLS in the patient care setting, and to gain understanding of the major services provided by the system. The RLS architecture is intended to serve as a reference for system designers to guide the detailed design of the system during the elaboration and construction phases of a system development project.

1.2 Scope

The Framework Technical Overview provides details of the technical architecture of the Record Locator Service prototype and outlines the strategy to meet the architectural (longer-term) requirements for the RLS as defined in the Markle Connecting for Health Common Framework Record Locator Service Reference Implementation Statement of Work.⁴

Technical architecture covers the domains of data, application and technology infrastructure. While technical architecture needs to be developed in the context of the organizational and business process architecture, these domains are out of scope of Framework Technical Overview. This document uses prior work by CfH to define the RLS business context and defines the technical architecture to fulfill the use case requirements thereof. The other important component of the common framework is the policy framework produced by the CfH Policy Sub-committee. This element of the framework was under development during the production of this technical architecture document; policy based requirements have been considered where available.

1.3 References

• [CfH2004] Achieving Electronic Connectivity in Healthcare, A Preliminary Roadmap from the Nation’s Public and Private Sector Healthcare Leaders, Markle Connecting for Health, Markle Foundation, July 2004.
• [CfH2004a] Accurately Linking Information for Healthcare Quality and Safety, Markle Connecting for Health, Markle Foundation, Draft Final Report by Working Group on Accurately Linking Information for Healthcare Quality and Safety, September 2004.
• [CfH2004b] Markle Connecting for Health Reference Implementation Launch, In Collaboration with the RWJF and Foundation for eHealth Initiative Confidential Draft Document for Discussion Only October 29, 2004
• [CfH2005] Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy, Carol Diamond, Markle Connecting for Health, Markle Foundation, HIMSS 2005
• [CfH2005a] Markle Foundation Connecting for Health Common Framework Record Locator Service Reference Implementation Statement of Work, CSC, February 2005.
• [CfH2005b] Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy, Working Group on Accurately Linking Information for Healthcare Quality and Safety, February 2005.
• [MAeHC2004a] Expanding the Use of Electronic Health Records and Establishing a Regional Health Information Infrastructure in Massachusetts, Request for Applications, December 6, 2004, The Massachusetts eHealth Collaborative.
• [MHDC2004a] Analysis of Approach to Uniquely Identifying Patients in Massachusetts, Massachusetts Health Data Consortium, Inc. 2004

1.4 Document Overview

The Framework Technical Overview document provides a high level overview of the software artifacts that make up the RLS. The document lays out the key business processes that the RLS is intended to support, a logical view of the components and their behavior, and the proposed deployment of the software on completion of development. The remainder of this section defines the concept of software architecture and describes the notation used to document it.

Section 2 defines the goals, principles, and constraints of the RLS architecture.

Section 3 lists the subset of use cases and scenarios that impact the architectural design of the system. Use cases represent the major business or functional requirements that the software is expected to meet.

Section 4 shows the decomposition of the solution into a set of logical elements, i.e., classes, subsystems, packages, and collaborations.

Section 5 presents the process structure of the system. The process view maps the logical view elements to the processes and threads in the solution.

Section 6 presents the implementation view of the system, i.e. the decomposition of the system into layers and packages. Alternative implementation models are presented that may be appropriate for specific scenarios.

Section 7 presents the deployment view, which maps the prototype components to a set of hardware and network nodes on which they execute.

Section 8 provides a view of the persistent data storage of the system to the extent that this is significant in a network with minimal central data storage.

A glossary of key terms, abbreviations, and acronyms used in this document is provided in Section 9.

1.5 Architectural Representation

The RLS software architecture defines the overall structure of the system in terms of the behavior of its components. Software architecture needs to be viewed from multiple perspectives and at different levels of abstraction to gain a full understanding of the system. In this document, the following architectural views are used:

• Use-case view: outlines the functional requirements of RLS from an end-users perspective.
• Logical view: where the major subsystems and components of RLS are identified and a conceptual view of their working provided.
• Process view: describes the runtime behavior of RLS components in meeting key functional requirements.
• Implementation view: provides the organization of the RLS software artifacts in terms of layering and packaging.
• Deployment view: describes how the various RLS software packages and runtime components are deployed on hardware and network nodes.

These views are shown in Figure 1, which illustrates the central role of the use-case (or business oriented) view as the driver of the whole software architecture. This architecture representation follows the ‘Rational Unified Process’ reference architecture standards.⁵ The system stakeholders that are primary audiences of the views are shown in the callout boxes attached to each view.

Figure 1: Architecture views and their contents

This document presents architectural views in the form of models (or diagrams) that use the Unified Modeling Language (UML) notation, where applicable.⁶

The keywords "MUST," "REQUIRED," "SHALL," "SHOULD," "RECOMMENDED," "MAY" and "OPTIONAL" in this document are to be interpreted as described in IETF Network Working Group RFC2119.⁷