T6

5 Process View

The RLS application is a collection of loosely-coupled interoperable services, and is itself a service that can be invoked by external consumers. Components that are distributed across network nodes communicate via XML messages using Web service standards, primarily SOAP and WSDL. Additional Web service standards may be used to support reliable messaging, error handling, and security.

The essential RLS functions to fulfill the patient lookup and publish patient index use cases are realized through distributed processing of the RLS services as described below.

5.1 Patient Lookup and Peer to Peer Medical Records Retrieval

The patient lookup process may be visualized as shown in the simplified communication diagram in Figure 11, where the flow of information and messages between the distributed processing components may be tracked through the sequence numbers provided.

Figure 11: Patient Lookup with RLS and Medical Records Retrieval through CDX Gateways

The interaction diagram illustrates the use of gateways to manage all communications between network nodes. Gateways also encapsulate presentation, business, and data access services thereby providing a full application stack for flexible implementation of RLS services. For example, while the patient lookup is shown as an interactive process it could as well be transacted offline, in batch mode.

5.2 Patient Index Publish

The patient publish process is simpler in that it is a notification-type background interaction. The initiating message is triggered by a registration event at the clinical data source and essentially serves to update the patient index with details of the patient whose record has been updated, i.e. added, revised, cancelled, or merged with another patient record in the clinical data source. This interaction is shown in Figure 12.

Figure 12: Patient Publish into RLS Patient Index

Typically, patient registrations are maintained in ADT systems in hospital environments. An ADT event message is broadcast to the other ancillary systems in the hospital such as laboratory, radiology, transcription, etc. The RLS patient publish message is generated by tapping off the same broadcast ADT message, requiring minimal changes to existing hospital systems. While this message is notification only, a basic exception handling capability needs to be built, where errors in posting the update to the RLS patient index are communicated to the data source. If the error does not require reentry of the ADT transaction, a mechanism to fix the data problem and resend the message to RLS needs to be built in the clinical system or interface engine.

5.3 Centrally Mediated Medical Records Retrieval

The scenario shown in Figure 11 represents a federated architecture, supporting peer-to-peer clinical data exchange. Alternate scenarios exist, such as a hub and spoke model where patient medical requests are mediated by a central gateway service. The collaboration diagram below demonstrates how a user could log in directly to a central CDX Gateway (in this case, co-located with RLS) and perform the same function.

Figure 13: Centrally Mediated Patient Lookup and Record Retrieval (Hosted Gateway)

Note that the healthcare practitioner is shown as logging directly into the gateway at the RLS location and executing the patient lookup query directly on RLS. This is another variation of the use of the CDX Gateway, and demonstrates the implementation flexibility a standard gateway utility based network architecture allows.

5.4 Central Medical Records Aggregation

Yet another processing model would remove the need for a two step process altogether and have the patient lookup request be combined with a medical records request which the CDX Gateway at the RLS would orchestrate. Such a scenario is shown in Figure 14.

Figure 14: Patient Lookup and Records Retrieval—In One Step

This interaction pattern is more appropriate for unattended RLS usage where a clinical system collects remote patient records and has them ready for review by a healthcare practitioner at later time. The orchestration process in the CDX Gateway is now more complex and should implement workflow processes of the healthcare practitioner, including selection of appropriate medical records to retrieve from various sources.

Other supplementary processes include the need for secure information sharing, and the establishment of contracts between the RLS and the various clinical data sources that would share patient medical records with each other. In both of these situations RLS, serves as a trusted intermediary, and reduces the need for the many-to-many relationships between the various clinical data sources. The secure messaging process is described below.

5.5 Security Processes

RLS needs a security framework to authenticate users, authorize access to specific services, and ensure confidentiality and integrity of messages. The implementation of security across a disparate, distributed computing network is optimally effected through a federated identity management architecture, where each user is authenticated by an assigned node that vouches for the user to other nodes. Federated security architecture is complex and considered beyond the scope of the current release of RLS. RLS uses a simpler model that can be extended to a federated architecture in later releases.

A distributed authentication/authorization architecture that is based on overlapping trust relationships is shown in Figure 15. Users’ identity and credentials are maintained at the gateway that they log in to. Gateways are within the clinical enterprise domain, and may be integrated with the enterprise security infrastructure to support single sign-on for users. Gateways are in a trust relationship with other gateways and authenticate each other through server-side certificates. An authentication / authorization assertion is communicated in the SOAP message along with the user identifier string for audit purposes.

Secure Socket Layer (SSL) is a session layer protocol for sending encrypted information over HTTP. SSL provides an encrypted channel with confidentiality, integrity and one-way or two-way authentication. SSL is used to secure messages between gateways in the RLS-based network. Gateway authentication may be provided by server-side digital certificates.

Figure 15: RLS Authentication Service

Over the longer term, CDX Gateways should leverage WS-Security, the emerging security standard for SOAP messaging, where different security tokens are embedded in SOAP Headers. The XML Signature and XML Encryption standard provides a platform neutral approach to message-level authentication, confidentiality, integrity, and non-repudiation.

Security Assertion Markup Language (SAML) provides a technology neutral way to exchange security information using XML to communicate authentication, authorization and other user attribute information. SAML also allows interoperation across different platforms such as J2EE, .NET and CORBA. WS-Security supports the use of a SAML token in the SOAP header.

The distributed authentication process implemented in the RLS prototype is shown in more detail in Figure 16.

Figure 16: Authentication Mechanisms for Patient Lookup and Medical Records Retrieval

5.6 Messaging Patterns

RLS defines contracts to govern message exchanges that implement services. These message exchange patterns, or message scenarios, are the basic transactions that Web services are designed around. The logical components and services described in the previous section may be considered as the ‘plumbing’ (or the Common Framework) for the health information exchange. The framework is capable of supporting various message scenarios that support multiple use cases.

There are four common messaging interaction patterns that characterize service oriented scenarios:

• One-way: or fire-and-forget messaging, involves the sending of a message from requester to provider with no acknowledgement expected
• Request / Response: implies that a response message is generated for every request received by the provider
• Notification: may be considered a mirror image of the one-way pattern, where the provider sends a one-way message to the requester
• Solicit response: is the reverse of request / response in that the service provider sends a solicitation for a request to a requester

The contract between service provider and requestor is defined using a standard XML based language called Web Services Description Language (WSDL). Note that the WSDL 1.1 messaging terminology above have been superseded in the WSDL 2.0 specifications with more precise names; these do not have a material impact on the RLS specifications and are not used.¹⁴

The message scenarios supported by RLS prototype are listed below:

Table 2: List of Messaging Interactions Supported by RLS Prototype

Each message scenario assumes that an error message (SOAP Fault) is returned by the receiver to the sender if the message results cannot be parsed or results in any application error.

The flow of logic across the different service layers in the RLS / CDX Gateway solution architectures is shown as sequence diagrams in Figure 17 and Figure 18 where the application process logic may be visualized as a series of messages exchanged between application services. The services oriented architecture is realized through implementation of messaging between application components, as shown here. Figure 17 depicts the interactions between RLS application components to provide the patient lookup service to users logging in to remote gateways.

Figure 17: Patient Lookup Sequence Diagram

As can be see in the figure, the Gateway services communicate with each other through the integration broker services.

The other core RLS service is that of accepting updates to patient indices from clinical data sources and applying them to the RLS CMPI. This may be visualized in the sequence diagram in Figure 18.

Figure 18: Publish Patient Index Sequence Diagram