Service-Oriented Architecture (SOA) Principles
Remote patient monitoring truly represents a superset of health-care integration use cases, sitting at the hub of a complex coordination of care -- across clinical specialists, home care, lab, pharmacy, hospital, and assisted living facilities. Chronic disease management adds a further layer of complexity, given that most home-care and remote monitoring systems were developed as proprietary systems with only a passing acquaintance with health-care and technology standards. Also, it is not uncommon for these CDM systems to be used alongside one or more of the major commercial EMR systems.
A Service Oriented Architecture (SOA) provides the essential grounding, agility, and extensibility to manage and reduce complexity when integrating health-care systems, services, and information. It is adaptable to a challenging and ever-changing business climate, and represents a proven return on investment [1, 2, 11, 12]. The SOA provides the necessary bridge between legacy and proprietary environments and moves us towards standards-based deployments that can scale to handle many network end points and a rich diversity of health-care data services. In this section we outline key considerations and SOA principles when establishing an RPM solution.
With health-care integration, it is important to leverage architecture that is flexible across different deployment models and data-use agreements. Figure 3 depicts three common deployment models, wherein health information is maintained in a centralized, federated, or hybrid database model. The model selected largely depends upon data-use agreements in the region -- whether to maintain data centrally to a given region, remotely (federated), or as a hybrid model of the two. The centralized model is optimum both in terms of performance and access to a consistent, normalized data set, suitable for both health-care delivery and clinical research. However, the centralized model requires the political will by all participants, public and private alike, to agree to centralized data sharing and data-use agreements.
Due to concerns over data sharing, ownership, and local control, the federated model is frequently chosen over the centralized or hybrid. When a discharge summary or lab report is required, a record locator service query is issued from the center to each of the federated or member organizations. If the federated service is available and the appropriate agreements are in place, one or more relevant documents are returned that pertain to the patient in question. Due to concerns over performance and availability, deployment models frequently shift over time from federated to hybrid, maintaining a small set of demographic data and centralized pointers to records maintained at the perimeter.
The federated model can be quite effective for very large, distributed data sets, but the records must be normalized at the edge by the use of agreed-upon terminology standards. The political will to use such standards can be even more challenging to achieve than that required for the centralized model. An excellent example of the federated model is the caBIG (Cancer Biomedical Informatics GRID at cabig.nci.nih.gov), which links physicians, patients, and researchers to clinical, cancer, and genomics repositories distributed worldwide in a standard normalized fashion.
Remote patient monitoring requires the integration of health information from a variety of disparate sources. The SOA is well suited to adapt and extend to this level of service, data origin, and terminology complexity. A key success factor in deploying RPM is to leverage a flexible architecture which can scale from small institutions, to regional health information exchanges, to national networks. Finally, the deployment model and technology selected must readily scale to processing at the core or at the edge of the network.
Service Extensibility, Virtualization of End Points
Traditional peer-to-peer approaches to integration lead to the N2 problem as depicted in Figure 4, in that each and every application requiring integration causes a geometric expansion of up-front cost and ongoing maintenance. In health-care integration, the N2 problem is made manifest by the inconsistent adoption of health-care and technology standards by legacy and proprietary systems. When a new application joins the network, each and every adapter has to be modified, in addition to the new application.
Integration Brokers change the cost model from geometric to linear, but have their own share of challenges, with the risk of establishing heterogeneous "islands" of integration. Integration Brokers rely upon a hub-and-spoke architecture, creating a single point of failure by routing all messaging traffic through a central hub. Only with a standardized information model, service extensibility, and virtualization of end points, provided by an Enterprise Service Bus (ESB), can one completely address the N2 problem.
The heart of the N2 problem lies in the simplistic framing of integration as a two-dimensional use case. When we frame the exchange of health information as a simple, bidirectional exchange between a total of two points, we obfuscate the actual complexity involved. In reality, the RPM exchange requires multiple data sources, or network end points, in order to complete the CDM view of the patient, including vital signs, assessment responses, functional status, lab results, prescriptions, diet, exercise, treatment plan, and clinical notes, to name just a few. The information needs to be addressable by using a standardized information model, and over time, each of the data services should be exposed by using a standard set of query and retrieval methods.
A service network architecture allows for building the "on-ramp" once, with no adapter maintenance required, as other applications join or leave the network. Service extensibility serves to virtualize the end points, abstracting the details of transport protocols and peer-to-peer connections. Services can be dynamically registered, discovered, and rerouted to scale as performance and reliability needs dictate.
Network Compute Model
The HL7 v3 CDA Release 2  constrains the v3 RIM and leverages the full richness of its health-care informatics model and standardized terminology, delivering computable, health-care information as well as human-readable clinical documents. By first composing all of the telehealth data to the HL7 v3 CDA Release 2 (i.e., the network on-ramp in Figure 5), it becomes a repeatable exercise then to perform any secondary transforms to legacy or proprietary messaging protocols and local terminology (i.e., the network off-ramp).
This integration pattern accelerates adoption of the latest health-care informatics standards, while lowering the barriers of adoption for smaller organizations that need to proceed at their own pace.
A robust network informatics exchange model can be used to establish trust at the network level -- a health-care dial tone. Peer systems may validate, authenticate, and audit the encrypted XML payloads at any point in the network. Moreover, the network compute model enables the ability to route, compose, and decompose fine-grained business objects according to national and regional, legal and regulatory, privacy, data protection, and patient consent requirements.
Pluggable Services in the Cloud
A Service Oriented Architecture provides the ability to leverage services available within the data center or across the Internet. New services can be brought online and directly utilized by network participants, without requiring additional modifications to each end point. Since the service location is virtualized, and the service implementation is encapsulated, a service can be readily created or replaced without impacting existing service consumers. The OMG/HL7 Healthcare Services Specification Project (HSSP at http://hssp.wikispaces.com/) is working to define standard Web service methods to access critical health-care infrastructure services, including entity identity, controlled terminology, record locator, decision support, and clinical research filtered query services. Similarly, there is a need for advanced health-care data services, such as drug interaction checks, adverse event reporting, clinical trial recruitment, and public health reporting. SOA design methodology allows for incremental implementation, at first utilizing simple data match routines and then, when the complexity of exchange dictates, readily switching to industry-strength identity and terminology services, all without changing the service interface.