T6

2 Architectural Goals, Principles, and Constraints

Architecture best practice calls for the definition of common principles at the outset to serve as a consistent basis for design decisions to be made downstream. Information Technology (IT) architectural principles define the fundamental rules and guidelines for the development and deployment of IT resources and assets. They reflect a level of consensus among the various stakeholders of the system, and form the basis for making coherent and consistent architecture and design decisions.

Architectural principles are, therefore, high level statements that govern the system architecture development process. Based on the CfH charter and the longer term MA-SHARE vision, the following RLS architecture goals, principles and constraints are proposed.

2.1 Goals

The guiding vision for RLS is that to provide directory and registry services for a regional health information network which supports the interoperability between disparate healthcare information systems in a community, reducing healthcare delivery costs and improving quality of care as well as patient safety.

CfH defines the primary objective of the Reference Implementation of the Record Locator Service as: to validate a set of standards that would, if implemented across communities, enable health information exchange within and between communities regardless of the hardware and software platforms used.⁸ Such standards and profiles are part of an interoperability architectural framework, which has been referred to as the ‘Common Framework’ by CfH. The technical standards would align with the other components of the common framework, which includes policies and methods.

The RLS is assumed to operate under the auspices of a Regional Health Information Organization (RHIO) that coordinates the various healthcare enterprises in the region (or community). RHIOs serve as distributed hubs of a prospective National Health Information Network.

2.2 Principles

• Patient privacy protection: Clinical data sharing shall be subject to very stringent privacy and security constraints. All access to patient health data must be secured through strong authentication and authorization, comprehensively auditable, and subject to sanctions for policy violations.
  • Secure and confidential treatment of patient information shall be a fundamental property of all technological and process artifacts pertaining to RLS. This tenet shall be built into the RLS architecture.
  • Given the varying privacy regulations existing across states in the US, RLS should support the most stringent protection of health information, including the requirement of explicit patient consent for disclosure of data.
  • In some cases varying levels of protection are required for different categories of clinical information pertaining to conditions such as mental illness and AIDS.
• Decentralized and federated architectures: Respecting the mandate for a de-centralized, federated architecture of healthcare information networks, RLS shall employ federated information architecture ensuring that each node in a RLS connected network retain ‘informational sovereignty."⁹
  • A central data repository of aggregated patient healthcare data creates a large target and poses an unacceptable privacy risk in the current political and network environment.
  • A ‘National Health Identifier’ for each person is impractical in the decentralized world of healthcare in the USA. Instead, RLS would support linking of health records that remain distributed and managed at their points of origin.
  • Data distribution should be biased to local control of clinical records and access to them. Personal health information should continue to reside where they do now, primarily with hospitals and healthcare providers. Decisions about disclosure of such information should be made at the source of the data, with patient consent if so required.
  • Users shall be authenticated and authorized to access patient information at the “edges” as well, obviating the need for centralized identity management of all authorized users.
• Open Standards: All solutions / components shall be based on open standards and not be dependent on any proprietary technologies. While standards in themselves do not guarantee interoperability, emphasizing standards across the network communication stack helps mitigate most of the common problems that have impeded information sharing in the past.
  • HL7 (version 2.x or 3.0) and NCPDP SCRIPT, the de facto industry messaging standards for general healthcare and prescription data respectively, should be used where applicable. The HL7 Reference Information Model offers a ready set of data standards that provide the semantic interoperability underpinning for HL7 messaging standards.
  • XML 1.0 is the data message notation standard for inter-application data communication and shall be the default message serialization format.
  • New or private network services shall not be required: the solution should be based on secure data transport over the public Internet. Secure Sockets Layer (SSL) protocol, the most widely adopted security protocol standard for the Internet, shall be used.
  • ‘Web services’ are the industry standard for platform-neutral, distributed application interoperation over the Internet. Web services should be used to effect data sharing across the health information network.
  • The Web Services-Interoperability Organization (WS-I) provides profiles to assure that web services built on disparate platforms have higher assurance of interoperability.
• Vendor and platform neutral: The RLS solution needs to be vendor-neutral to ensure wide-spread adoption of the architectural standards. As an extension of the open-standards principle, this principle stipulates that no dependence on specific vendor technology be introduced.
  • Leverage commercial-off-the-shelf (COTS) master patient index solutions for the prototype, but develop the architecture in a manner that future adherents to the Common Framework can make their own build vs. buy decisions.
  • Assume that comprehensive integrated application suites are potentially cost-prohibitive for wide-spread deployment across a range of healthcare systems from small family practices to large hospital networks.
• Best Practices: RLS service should be designed for agility and extensibility to meet varying regional clinical data exchange implementation requirements.
  • Service-oriented architecture enables applications to be more flexible, and interface well with external facing web-services. Following the service-oriented approach, the RLS application should comprise loosely-coupled coarse-grained components that can be readily reused. However, the internal architecture of the RLS application is not itself relevant to the standards based external messaging that is the primary requirement.
  • RLS should support existing regional and community health information networks as well as prescribe best practices and patterns for new networks to adopt.
  • Variability across regional networks should be mediated through shared specifications based on the open standards as prescribed above.
• Promote Widespread Adoption: The following system constraints should be taken into account to enable rapid deployment of a solution that builds on the RLS prototype:
  • Widespread distribution of the RLS solution demands a light-weight inexpensive solution for all new components at the edges.
  • Participants have diverse vendor relationships and must not be bound / committed to any one vendor to benefit from RLS-based connectivity. RLS specifications and standards should be open to implementation by healthcare information technology vendors.
  • Standards based, loosely coupled, and flexible design should be used to avoid ‘rip and replace’ implementation across the current healthcare landscape. The architecture should support an incremental migration from current technology to future standards based interoperation.
  • Participants in health information networks have significant investments in EHR and personal health record (PHR) applications. RLS should support connectivity between them, with incremental migration paths that call for moderate incremental investment.
• Flexible Implementation Models: The RLS architecture should enable top-down and bottom-up implementation strategies, favoring local network infrastructure development to promote widespread usage and national interoperability models to promote inter-regional information sharing. From a technological standpoint, the RLS architecture should support three implementation models:
  • Gateway: Physically deployable service that may be integrated into RLS subscriber enterprise IT environment, and allowing secure access to RLS.
  • Application Programming Interface specifications: Allow solution providers (package vendors and custom development shops) to implement RLS components independently on platforms of their choice without detracting from interoperability.
  • Hosted: All RLS services are hosted for subscribers unable or uninterested in owning and operating the RLS access infrastructure. Such a solution would be an attractive option for smaller physician practices and institutions that prefer to outsource their information technology services.