T6

4 Logical View

The architecturally significant subsystems/components that make up the RLS are identified and their interactions that provide the required services are described in this section. A top-down approach is taken starting with the high level functional component view, and decomposing this into more granular components that can be translated into system components and services.

4.1 Conceptual RLS-Services View

Based on the activity diagram that defines the RLS patient lookup process it is clear that functionality is required at three processing nodes. These are the healthcare practitioners, the clinical data sources, and a patient index.

A conceptual view of the interaction between RLS and its ‘subscribers’ may be viewed as shown in Figure 5.¹²

Figure 5: RLS Conceptual Architecture of Operation

By maintaining the patient index pointers to patient record locations in multiple clinical data sources systems, RLS serves as a directory of patient records in clinical systems. Besides the patient index, the RLS also maintains the registry of all members of the network, and their network addresses.

This model is seen to very similar to the classic service-oriented invocation paradigm where the service consumer, provider, and broker interact in the ‘publish / bind / find’ pattern, as shown in Figure 6. This similarity suggests that RLS should play the role of a patient record registry and that clinical data sources should be exposed as services that are accessible via open standards based messaging interfaces.

Figure 6: Service Oriented Interoperation

Service oriented architecture (SOA) is an architectural style that promotes system agility and extensibility through loosely-coupled software components interoperating through generic messaging interfaces. Interfaces may be separated from implementation by expressing application semantics through XML messaging interfaces. Extensibility should allow new versions of the service to be published and consumed without breaking the existing service, which is facilitated through XML Schema versioning.

Web services are implementations of SOA across enterprise boundaries where interfaces use Internet transport protocols (HTTP, SMTP, and FTP). Web service communications commonly use SOAP protocols for message packaging and WSDL for service description. Service brokers and registries are also accessed through SOAP messages. Thus, in keeping with the architectural principles set out in Section 2, RLS should be implemented as an Internet accessible service using standard protocols such as SOAP and WSDL.

In addition, RLS should use healthcare domain data standards that support semantic interoperability with the various clinical systems. This would expose the resources managed by RLS (i.e. patient index) to consumers in the network through a standard representation based an industry standard information model, such as the HL7 RIM. HL7 v3 messages are derived from the RIM and, therefore, have intrinsically better semantic interoperability characteristics than earlier versions.

There are practical difficulties in implementing the above open-standards messaging interface based interaction pattern in a healthcare information exchange setting:

• While a large number of clinical systems support HL7 2.x messaging and interface with other systems within enterprise networks, message implementations are not consistent and inter-enterprise data sharing is difficult. Use of HL7 RIM is not widespread in the industry and HL7 v3 implementations are extremely scant.
• Most clinical data sources do not conform to inter-enterprise interoperability messaging standards, and very few are ‘Web service enabled’ to consume or provide Web services.
• Canonical message formats are essential to support practical peer-to-peer information sharing. Otherwise, in a network with n nodes sharing data, it is likely that the number of distinct translations for each message exchange(request/response) is of the order of: n x (n-1).

RLS provides the master patient index service to locate patient records at distributed clinical data sources, components to interface with each of the clinical data sources, and canonical data formats for the patient index publish and lookup messages.

4.2 RLS Application Services

The common framework does not place any requirements of the RLS internal application architecture. As long as the external RLS interfaces conform to the proposed messaging standards, interoperability does not depend on the implementation details of the service. Nevertheless, the following discussion provides guidelines based on the experiences with RLS prototype development that are expected to be useful for other RLS implementation projects. As the discussion below shows, the use of SOA principles enables flexible implementation models, and network topologies while conforming to essential interoperation standards, which is a primary requirement of the common framework.

As discussed in Section 4.1, services are application components that expose their functionality through standard interfaces. In addition, the service model is fractal in that services may be created by combining other services to expose new, aggregated capabilities. Such an aggregation is also called an ‘orchestration’ or ‘composition’ of services. The ‘composability’ of services is important to the agility of SOA applications, and to understanding the RLS application architecture.

Following the service-oriented approach, the RLS application is logically structured as an aggregation of coarse-grained loosely-coupled services. In systems architectures it is useful to classify services as business services or infrastructure services. Infrastructure services are reused across multiple business services, enabling cost effective systems development and operations. The RLS is composed of multiple services, both business and infrastructure. The core business service provided by RLS is:

• Patient index service
  • Responds to patient lookup queries with a list of patient record locations
  • Accepts patient index (record location) updates from clinical data sources

RLS business services are supported by common infrastructure services such as:

• Security: Services that handle user identity management, authentication and authorization, protection of patient privacy, and consent management.
• Systems management: Covering automated administration, installation, configuration, and operational monitoring, control and optimization of systems.
  • Logging: To meet auditing and system maintenance requirements
• Data services: Provide persistent storage and management of data, as well as common data access mechanisms for application components.
• Message transport: Enables reliable, synchronous, message based communication between system components.
• Message transformation: Overcomes the real-world problem of disparate data format standards supported by different systems.
• Web-services interface: Leverages the numerous WS-* standards to expose RLS services through XML based messaging API accessible over HTTP transport networks.

Web service interface services may be categorized as belonging to certain standard architectural patterns, called ‘service gateway’ and ‘service interface.'¹³ The service gateway is an agent, encapsulating the details of communicating with remote web services, and enabling legacy applications to consume web services. The ‘service interface’ is a façade, encapsulating the legacy application by overlaying a web services wrapper, and enabling remote systems to communicate to it.

Technically, RLS can be implemented as a composition of the above services to provide services to remote applications over the globally available Internet. But in recognition of the practical constraints of legacy clinical systems, the architecture also provides guidance on connecting clinical systems to RLS. This may be accomplished through a web service interface as listed above and:

• Adaptors: Facilitate connections to clinical systems and databases through database interfaces or custom API

The message transformation, web services interface and adaptor components are the key infrastructural service for the interoperation of disparate clinical systems. Essentially, these infrastructure services expose the RLS patient index as well as clinical systems as web services, and enable them to consume web services. Thus connectivity in the network is established using platform and payload agnostic, open standards.

4.3 Gateway Services

Following the principle of deploying applications as aggregations of loosely coupled services, the infrastructure services listed above could be bundled to form a composite ‘Clinical Data Exchange (CDX) Gateway’ for the clinical systems to interoperate with each other. By designing the CDX Gateway to support general purpose, secure, and reliable messaging between clinical systems, it serves as the standards-based on-ramp to a health information network.

The RLS may be realized as the orchestration of the following two service compositions, which may be considered as the business service and infrastructure service respectively:

• Patient Index: Central service that maintains the community patient index, and a registry of clinical systems with routing information to direct service requests and responses to appropriate end-points.
• CDX Gateway: Distributed service that interfaces to each network node, converts from the legacy data messaging format to the standard message (if needed), and communicates to other gateways in the network through Web services.

The CDX Gateway needs to be a small footprint, low-cost service that can be deployed in participant institutions with minimal customization to interface with disparate clinical systems on one side, and to other Gateways via the public Internet on the other. A CDX Gateway is also deployed at the RLS to support messaging with the other network nodes, exposing the Patient Index to external systems through this common utility component.

Figure 7: RLS Distribution of Components

Such a gateway serves as a general purpose utility to support medical records retrieval as well as RLS communication services. Users acquire patient record locations (pointers) from the RLS and access data from multiple clinical data sources as shown in Figure 7. Note the parallels with the conceptual architectural vision in Figure 5.

As may be seen from Figure 7, communication between all network nodes is through the CDX Gateway at that node. In addition, presentation and business services would be required for the user interface functionality of the RLS (patient search criteria entry, and selection of patient record locations to query). Online users would log into the CDX Gateway co-located with the clinical system to which they are affiliated and access RLS services.

The collection of clinical systems that hold patient medical information at each network node is called the Electronic Health Record (EHR) in the figure, and in the following discussions. In the figure an online interaction is shown at the CDX Gateway at EHR-1, whence the patient lookup request is made to the RLS. The other nodes EHR-2 and EHR-3 serve as clinical data sources. Data retrieval from backend systems at the clinical data sources is done through the adaptor services in the CDX Gateway. The data sources publish patient index updates to the RLS also via the CDX Gateway services at those nodes. Although not shown in the figure, online users at EHR-2 and EHR-3 can also access patient lookup services at RLS (and other clinical data exchange services).

RLS receives service requests through a CDX Gateway at its location. RLS needs an administrative user interface to manage the application, which would be the responsibility of the presentation and business services in the gateway at the RLS.

The gateway based architecture provides significant flexibility and scalability. More clinical data sources could be added by deploying a CDX Gateway at that location and customizing adaptors to connect with the clinical system there. The Gateway transforms local message formats into standard ones and manages their secure, reliable communication to other Gateways.

In general, the expectation is that CDX Gateways that are approximate clones of each other would simplify deployment, configuration and administration of this distributed service. The CDX Gateway, thus, serves as a general utility service that may be plugged in at different EHR locations. In addition the CDX Gateway serves as an infrastructure component which realizes the common framework standards in a packaged form.

CDX Gateway application architecture is based on a multi-tiered pattern of presentation, business, and data and integration tiers. The integration tier is the service that interfaces with clinical systems / data sources at the backend, and communicates with remote Gateways through orchestrated web services at the other. Gateways also include capability to serve as messaging intermediaries. This is a side-effect of implementation of WS-* standards which include WS-Security and WS-Addressing in the CDX Gateway that enables secure, reliable SOAP intermediary functionality.

A more detailed view of the CDX Gateway and its interaction with other gateways is shown in Figure 8. The distribution of functionality between a pair of communicating Gateways is flexible, dependent on the capabilities available at the clinical systems at each network node. The architecture shown in Figure 8 depicts the two EHR nodes playing distinct roles: healthcare practitioner and clinical data source. There are no backend clinical systems at the healthcare practitioner node and the presentation and business services are not deployed at the clinical data source. Within the gateway, the message handling, clinical system adaptors and web service interfaces are shown encapsulated in an Integration Broker service.

It is expected that each CDX Gateway deployment initially requires significant custom localization of the Integration Broker service to cater to EHRs that do not conform to prescribed standards. Over time clinical systems are expected to develop standard Web service interfaces. This would reduce the processing requirements of CDX Gateway, and would enable lighter weight Gateways to be directly pluggable into the data sources.

CDX Gateways communicate with each other using Web services protocol (WSDL and SOAP) over the standard HTTP/SSL transport protocol. Gateways could extend in future to adopt alternate transport protocol such as Secure FTP for batch file transfer, and SMTP using industry standard S/MIME encryption for email.

Figure 8: Gateway based interaction in a health information network

4.4 RLS-Based Networks

The RLS-based network strategy may be summarized as: Web-service enabling clinical systems. Nodes communicate with each other through HL7 (or other domain-specific standard format) messages wrapped in SOAP envelopes over HTTPS transport. Such a peer-to-peer clinical information network is shown in Figure 9.

Figure 9: Network of clinical systems communicating peer-to-peer

The diagram shows diverse ways of deploying CDX Gateway to connect health information network participants to RLS. While clinical systems routinely send patient index updates to the RLS, users connect to RLS, via their local clinical system, to query patient record locations (patient lookup). Patient lookup can also be done in a non-interactive manner through request / response messages exchanged between gateways at EHR locations and the RLS. In addition a user can query RLS from anywhere on the Internet using only a thin viewer. This mode requires the CDX Gateway at the RLS location to serve up the user interface and business logic much as a gateway at an EHR location would. Since CDX Gateways are clones of each other, this can be achieved by configuring the services in the RLS gateway appropriately.

In addition, it should be noted that the gateway service could play the role of a data cache. The data storage layer in the CDX Gateway (see Figure 8) could potentially hold a data repository into which clinical data is replicated from the EHR and made available to network access. Indeed, it is thought that clinical enterprises would likely prefer to have database queries be directed at such a proxy cache rather than exposing operational systems to remote queries over a health information network.

4.5 Regional and National Network Support

Current thinking on national health information network envisages interconnected exchanges hosted by Regional Health Information Organizations (RHIOs). Such a network of networks is shown in Figure 10.

Figure 10: Network of RLS-based networks (potentially used by RHIO)

The RLS architecture itself presumes no regional dimension; the scoping function of the RLS is the community master patient index that maintains pointers to patient records in distributed EHRs in the community. However, RLS clearly is a candidate for the central coordinating service of a RHIO network. In regards to inter-RHIO communication, it is easy to see that the RLS could also play a key role in routing and coordination of services across RHIOs.

Some RHIOs may be based upon a centralized data repository as determined by regional policy considerations (as well as legacy architectural considerations); others are decentralized. Both models, as well as intermediate ones, are supported by the proposed NHIN architecture. Using a common framework based on open standards and common policies allows a RHIO to be agnostic about the architecture of another RHIO. The service oriented CDX Gateway architecture also enables a degree of flexibility in implementation styles and operational configuration as discussed further in the following section.