RFI 23. Describe the major design principles/elements of a potential technical architecture for a NHIN. This description should be suitable for public discussion.
The Booz Allen Collaborators define the NHIN as a capability that provides access to the health information that resides in the many different health information networks – it is NOT a physical central repository of health information. We think of the NHIN as the medical Internet where any qualified provider that is using an electronic health record can discover published information and choose to use or incorporate that information into the electronic health record at the point of care. Using this same network, consumers of healthcare could access personal health records.
We also define the NHIN as a non-proprietary, highly scalable, distributed peer-to-peer “network-of-networks”
that is powered by the Internet using a federated model to realize a standards-based message and services oriented architecture – it is NOT a closed or private network that mandates each user acquire and implement a pre-determined set of hardware or software technology. We envision that any locality-based (e.g., regional or state) or domain-based (e.g., cancer research community) health information network that chooses to follow community-defined norms and rules that prescribe what behavior may, must, or may not be performed by members can become part of the NHIN network-of-networks.
Major NHIN design principles focus on enabling patient-centric interoperability.
NHIN design principles in this section represent high-level quality-of-service (QoS) requirements that have to be met to address the key technical challenges around sharing patients’ medical data over an open and public network with a large number of private networks, systems, and potentially personal computers.
Industry best practices in Enterprise Systems and applications Integration (EAI) can contribute a great deal to the NHIN design principles, because NHIN can be viewed as a collection of networks comprised of private systems and applications. Aimed at achieving interoperability, the following EAI best practices center on the concept and design principles of Services Oriented Architecture (SOA) that holds the greatest potential to fulfill the following QoS requirements.
• Extensibility –The NHIN will be built incrementally and cannot truly envision an end state. It will constantly evolve through inter-connecting new systems, and local networks, and services. Additionally, business around patient-centric healthcare and technological advances requires constant modifications and calibration of individual systems and services components. It is vital for NHIN to be extensible to allow new systems, service consumers and providers to be changed without interrupting interoperability.
• Discoverability – The NHIN architecture must have a mechanism to allow services and data to be discovered by data consumers within the context of NHIN. This does not, and should not mandate a centralized registry of services, although such a registry is one design option that can be considered
• Accountability of Services – This design principle calls for services that collaborate with each other in NHIN to have a mechanism to collectively fulfill the delivery of requested data. If one of the collaborating services components fails, others should continue.
• Descriptive Message Semantics – Messages from a services consumer to a services provider should be descriptive, rather than prescriptive. That is, a services consumer should describe what is wanted, instead of how the services must be performed. These descriptive semantics allow more flexibility for services vendors and providers to change their services without impacting the fulfillment of the request.
• Structured Message Semantics – Well-defined vocabulary and message structures are a necessity for interoperability.
• Loose Coupling – This requirement eliminates any integration based on Application Programming Interfaces (APIs). Rather, it requires a small number of simple and ubiquitous interfaces using generic semantics that are understood by providers and consumers of services.
The design principles that are specific to the NHIN focus on the patient-centric characteristic and are presented in Exhibit 23.
Exhibit 23 – Major Design Principles of a Potential Technical Architecture for a NHIN NHIN design principles focus on enabling patient-centric interoperability
Barrier Areas Architecture Considerations Potential Enablers
Data Security
and Privacy y There should be signed agreement between the patient and the PCP on authorizing data use (much like the existing paper based mechanisms).
y As the data owner, the patient needs to have full control over his/her records as it relates to who can access and what can they access.
y The PCP should explicitly authorize data access by any care provider entities (including referrals), with or without the patient’s acknowledgement depending on the agreement.
y ER will need full override privilege, and any data request and usage by ER needs to be fully audited or tracked in NHIN.
y Minimize patient identifying information passed over the NHIN wherever possible.
y The existing paper-based framework with explicit or implied agreements between the PCP and patient.
y Care giving organizations have full ownership of implementing and enforcing the security mechanisms in their local EHR systems.
Data Exchange
over the Network y Bandwidth needs to support potentially large amounts of data.
y Security mechanisms should ensure that unauthorized access to data will never be able to identify the owner/patient associated with the data.
y Explore the on-demand-use of high bandwidth, based on the utility-computing concept.
y Standardize the data elements that are identity-sensitive and standardized encryption mechanisms.
y Standardize semantics to allow common interpretations of privately implemented and owned security mechanisms at local networks.
Barrier Areas Architecture Considerations Potential Enablers Interoperability y Data needs to be created, maintained, and
interpreted consistently. y A set of standards, adopted from industry, and/or developed specifically for NHIN including standards for medical data, safety data, and messaging specification.
y Use of existing standards, communications and protocols y Common repositories of medical and patient safety
vocabularies as defined by the standards.
y A common set of services implemented based on the defined and adopted standards with system and application programming interfaces (SPI/API) to allow consistent integration and interoperability.
The NHIN we envision creates conditions for collaboration and data exchanges by offering a federation of services based on a common semantic and syntactical foundation for interoperability.
The NHIN is conceptualized as a network of private networks and systems that are interconnected through a set of core services that are built on service-oriented technologies and operate over the public Internet using industry standard protocols.
As shown in Exhibit 24, the private networks (or local networks) include clinical EMR systems that support the operations of care providers. They also include community based LHIIs and RHIOs, Government run Health systems (such as VA, DOD, IHS), as well as health surveillance systems deployed in various Federal agencies.
Exhibit 24 depicts typical scenarios in which different user communities will interact with NHIN. Each scenario is denoted by a line connecting a user to a conceptual local network, or to NHIN, and labeled alphabetically.
Exhibit 24 – NHIN Conceptual Technical Architecture
Each scenario labeled in the exhibit above is described in the table below along with a list of considerations.
This information illustrates the barriers and challenges associated with interoperability. Many of the implementation considerations hold for multiple scenarios; to hold complexity of the table down these considerations are generally not repeated.
Exhibit 25 – NHIN Conceptual Technical Architecture – Implementation Considerations Scenario
Label Brief Descriptions Implementation Considerations
A An ER care giver attempts to look up a patient’s medical records across NHIN
• If a patient is unconscious, how will the search be performed based on limited information?
• How can the requester (ER doctor) be identified?
• How will NHIN ensure security and privacy while ER doctors have power to override security measures?
• How will the patient identify be protected or exposed?
• How can the search be made as successfully and timely as possible, considering that many networks/systems are being queried?
• If the patient’s condition calls for a large volume of data, how can a speedy transmission of the data be ensured?
B&C A PCP attempts to look up patient’s additional medical or health records (reactions to medication, for example) across NHIN or within a local network
y How can the doctor be identified?
y How do you ensure the patient is under the care of the doctor? If not, should the patient’s care provider permit such use of data (for fear of losing business to the doctor performing search)? Should permission be restricted, then how?
y How is the patient’s privacy policy enforced (e.g., the patient may not want all data shared)?
y How can the search be made as successfully and timely as possible?
D A PCP attempts to create medical records of a newly enrolled patient to the PCP’s practice, and transfer existing records from another PCP.
y Should the patient authorize the transfer? If yes, how, and what supporting technologies need to be in place and who is responsible for implementing them?
y Should the records be transmitted in real-time, or in batch over the open network, or off-line via physical media (CDROM or DVD, for example)?
y How could the newly created records and the services to retrieve them be made known to NHIN services?
y What will happen to the records transferred (single vs. duplicate)? How will the service and data registration differ from that of the new records?
y How will the new PCP reconcile the data? Will the original PCP archive the patient’s records?
E A patient attempts to look up his/her medical records from all available sources across NHIN
y How do you identify the patient without a centralized Identity Management System?
y Will the patient have access to the PCP’s systems?
F A payer requests a patient’s medical records associated to a claim, via NHIN or directly wired to private systems.
y What data is the payer entitled to see?
G A consumer searches across NHIN to see reported side effects of a medication
y Will a comprehensive indexing of safety reports exist to accelerate performance?
H A product safety evaluator/medical doctor searches and analyzes adverse events related to a medicinal product A researcher (from academic or Pharma communities) searches and analyzes adverse events related to a medicinal product
y How the request can be formatted to contain complex query requirements?
y How the response can be normalized to support the requester’s analysis needs.
y How will the search be restricted to the de-identified medical records?
The conceptual technical architecture presented in this section creates the right conditions for collaboration and data exchanges by offering a federation of services that rely on a common semantic and syntactical foundation for interoperability. Each service would be a group of related functionalities used by multiple other technical components, hiding the details of the implementation and providing published interfaces to facilitate use in clinical settings.
The NHIN is enabled and interconnected through a set of services.
In the following paragraphs, we will discuss the services that are required to allow data exchange and interoperability at a national level. Further development of the architecture will drive definition of additional services. The services need to be highly scalable and non-proprietary and are based on a federated model.
Provided by independent ASPs, or through government sponsored development, these services are implemented based on the design principles and, therefore, should exhibit the characteristics of SOA as outlined earlier in this section. It is likely that the implementation of the services will be based on Web Services standards and technologies. They will collaborate in a distributed fashion, and follow a request and response mechanism using standard protocols such as SOAP and HTTP(S) over the public Internet.
It is envisioned that the request/response will be carried out through messages based on defined specifications and interfaces, and are required to contain at the minimum the following information:
• Requester Identifying Information
• Patient Identifying Information (when applicable)
• Purpose of the Request
• Semantics-based and Descriptive Indication of Data Need
• Requester’s capability of supported data standard
We define User Services as critical components of NHIN to primarily support user-initiated requests. A user is considered anyone within the stakeholder communities. In order for user requests to be answered, several Core Services are required to collectively deliver the requested services. These Core Services are the building blocks of NHIN that are distributed across NHIN networks and are discovered at times of need. In addition to Core Services and User Services, we identify several Value-Added Services that represent extensions to expedite data transfer and improve performance. Exhibit 26 presents the relationships between the different sets of services.
Exhibit 26 – Crosswalk of User, Core, and Architectural Services
User Services Core Services Value-Added Services
y Patient Health Information Service y Requester Identification Service y De-identified Health Information
Service y Audit Services
y Care Provider Registration y Patient Data Registration y Patient Identification Services y Data Transformation y Transaction Management y Security/Privacy Services y Vocabulary Management
y Indexing y Medical Library y Medical Product/
Ingredient Library
A Patient Health Information Service – A Patient Health Information Service is one example of a user driven action of the NHIN. In this scenario, patient health information is requested. In order to do so, the user interface connecting to NHIN will require a user to enter several key data elements. First is information pertaining to a patient. Since a national patient identifier will not be used, the user would have to enter multiple standard data elements for a patient that would specify the individual whose data is to be accessed.
A requester id, coupled with a purpose for the request will allow the services provider to determine what information the requester is entitled access to, as specified by provider and patient privacy rules and policies.
Requester Identification Service – As mentioned before, not all users of NHIN will be entitled to see all details of a patient’s health record. In order to control user access, the interface to NHIN will require a user to enter standard data elements about him/her. For example, an ER Physician could be granted full access to a patient’s health record (as opposed to restricted access for a foot specialist), as long as the ER requester is authenticated.
De-Identified Health Information Service – In addition to patients and physicians, the research community, regulatory users, public health consumers and payers will have a great interest in health data across NHIN.
However, it is imperative for reasons of privacy for these users to obtain de-identified health information, usually in an aggregated form. The response to this request will have all patient sensitive information omitted to maintain privacy and security standards.
Audit Services – Since patient information will be shared through NHIN, it is critical to provide a service which supports analysis of who has seen specific data and why. For example, patients can see who has viewed their health record, or inquired about it (even if access was not granted). In essence, the response to this request would be an activity log summarizing who has requested, viewed, or edited a patient’s health record, as well as time stamps associated with these actions.
Care Provider Registration Service – The main objective of the Care Provider Registration Service is to function as a repository of care givers based on standardized provider data elements. This registry will facilitate Security Services’ authentication mechanisms.
Data Registration Service – This service is to register a patient’s health record upon creation. If a physician’s local network is connected to NHIN and a patient’s health record has been registered, it can be shared or transferred across NHIN.
Patient Identification Service –The Patient Identification Service is to provide a mechanism that assists different participants in the network in verifying that they are communicating about the same patient. One technique might be to create, maintain and interpret a set of keys based on the hash values of a standardized set of data elements for patients that have associated data registered in NHIN. The keys could not be used to
“reversely” identify the patient. For example, standardized data elements could include name, mother’s maiden name, birth date, and city of birth. Looking up a patient’s medical record might use any combination
of these data elements to support different user initiated scenarios. This service would manage keys and the identity related data elements based on semantics that would have no relevance to real-world use of these data elements.
Data Transformation Service – The Data Transformation Service is to support the translation of medical data from one standard format/vocabulary to another to allow interoperability between systems using different standards. Currently, there is no single set of standards that ensures widespread adoption and effectively supports a large number of sub-domains with vastly differing needs of capturing, storing, and exchanging data. Additionally, there is typically a need for supporting multiple versions of the same standards as standards mature and evolve. The Transformation Service will support the Patient Health Information, Requester Identification, De-Identified Requester and Data Services.
A Transformation Service is most likely required, but the location of this service can differ. In one scenario, the Transformation Service would reside at the NHIN infrastructure level. This would support multiple data formats coming in from local networks and multiple data formats going out to the local network of a requester of data. A second option is for the Transformation Service to reside at the local network level. This would allow the sender and requester of data to transform data to a defined standard at the point of exchange at a local level. In this case, a Data Transformation component would not be part of the NHIN Infrastructure; all messages across the NHIN would conform to a single standard.
A third option is not to have a Transformation Service. This would require users of NHIN to adopt and operate with a national data standard(s) set forth by a standards governance body. In this scenario, all users of NHIN would natively use the NHIN specified standards.
Transaction Management Service – The Transaction Management Service provides necessary
transactional level security audit, and coordination of services, as well as to oversee the delivery of data as requested.
Security/Privacy Services – Our conceptual NHIN relies on the security mechanisms at local networks and individual systems to fully ensure protection of data and compliance with privacy requirements resulting from patients, and/or Federal and State regulations. Information on technologies and standards for data security and privacy can be found in Standards and Policies to Achieve Interoperability.
Vocabulary Management Service – Vocabulary Management Service is to maintain repositories of standard medical vocabularies, and fulfill lookup requests (A PCP looking up a medical term while charting a patient diagnosis, for example). A main user of the Vocabulary Management Service is the Data Transformation Service. The vocabularies will include, but not be limited to, industry standards specifying medical data and messaging that have be adopted for NHIN (such as HL7, X12, various Coding systems) as well and NHIN specific messaging standards. It can also interface with external systems such as Medical Libraries and Medical Product Libraries.
Indexing Service – This is an optional service that, if implemented, could increase efficiency of requests that would otherwise have to query multiple networks or systems to find the desired information. The Indexing Service would contain linkages between patient credential keys and data records stored in different local networks or systems. For example, Patient A’s electronic health record was created at his/her Primary Care
Indexing Service – This is an optional service that, if implemented, could increase efficiency of requests that would otherwise have to query multiple networks or systems to find the desired information. The Indexing Service would contain linkages between patient credential keys and data records stored in different local networks or systems. For example, Patient A’s electronic health record was created at his/her Primary Care