Download T6: Record Locator Service: Technical Background from the Massachusetts Prototype Community
This section describes how the major components of the RLS logical architecture are distributed across hardware nodes in a health information network. Given that only the interface (inter-node messaging) specifications are expected to be consistent, deployment of systems based on the RLS architecture could vary widely based on local technology policies and preferences. This section provides deployment related information, for general guidance.
RLS components and services are designed to be flexible and highly configurable to enable deployment across a wide variety of sites. RLS requires the deployment of software on the following two types of server nodes:
The RLS Patient Index is deployed at a central facility that provides robust data center management capabilities. This represents the one new patient data location that the health information network introduces. It is essential that HIPAA rules be observed at the RLS data center, much as they would in a covered entity.
Gateway servers are located within the circle of trust of the clinical system, and are typically deployed at the edge of the enterprise IT infrastructure zone in what is popularly known as the “DMZ”. An application firewall separates the Internet accessible gateway server from the internal network resources of the clinical enterprise. Only specific and authorized messages from the gateway are allowed past this application firewall.
Depending on volume of message traffic and throughput requirements, consideration may be given to deploying an ‘XML firewall’ that protects against malicious XML content based attacks. Such devices also feature XML processing capabilities, including XML Encryption and XML Digital Signatures using X.509 digital certificates based public keys. Typically, XML processing in hardware would provide significantly higher message handling performance. However, XML-aware network infrastructure is an emerging product category, and organizations should ensure that lock-in to proprietary features is avoided by insisting on conformance to open standards and verifying interoperability with XML software solutions.
Gateways can also invoke Web services on each other, enabling server processes to query the RLS. Such ‘batch’ mode queries and response processing will require additional functionality including the services of a job scheduler on the gateway server. The systems management services layer of the gateway is expected to manage these processes, which may be integrated with enterprise standard utilities as needed.
In a production network, deployment is expected to span a large number of CDX Gateway nodes that communicate with RLS and with each other. Sample production deployment topology is shown in Figure 23. Hardware sizing at each node is done based on production deployment requirements, which would be driven by network characteristics such as clinical transactions and patient registry volumes.
Figure 23: Potential Production Deployment View of RLS
Systems management is critical to RLS-based network operations. The CDX Gateway architecture provides for comprehensive message logging and auditing capability. The same logs could be readily extended to support monitoring and reporting using simple scripting and system utilities. Several enterprise and network systems management tools exist that can be deployed to manage the CDX Gateway within the enterprise network context. Gateways need to be instrumented with the appropriate Simple Network Management Protocol (SNMP) agents for this purpose.
A Web services systems management standard: OASIS Web Services Distributed Management is expected to gain ground in the near future and advance SOA management using Web services. WSDM is based on SNMP and the Common Information Model and would represent a natural evolution from current distributed management standards to Web services based ones. The advantage of WSDM is that it uses Web service methods to manage distributed services such as those proposed for the RLS-based health information network, and therefore aligns well with the RLS architecture. Additional system management services would need to be added to the CDX Gateways to monitor and control message traffic using the WSDM protocol.
One of the key features of WSDM is SOAP based deployment of Web services. This would allow the Gateways to be deployed and configured from a central location (such as from RLS). This would further the goal of a utility service that can be cloned and deployed at the distributed network nodes with minimal disruption to the EHR systems at the node.
Since RLS’ major communication security functionality is embedded in the gateway, this offers a convenient approach to localizing the deployment and management of security services. The major security infrastructure that needs to be deployed with the RLS and CDX Gateways are the Digital Certificates required to support SSL and, in future, WS-Security.
Directory services (LDAP or Active Directory) are often used as certificate stores, and as the user identity and roles repository. Enterprises directories should be used if this shared service is available on the EHR network. Gateways should be interfaced with the enterprise directory using LDAP interfaces.
The reader is referred to directory and PKI documentation for detailed guidance on the deployment and management of public key certificates.