« Return to Markle Common Framework

Related Practice Areas

 

Additional Resources

 

  Download P9: A Common Framework for Networked Personal Health Information

Section 4: Background on the Common Framework Architecture

Markle Connecting for Health has created a structure, called the Common Framework, which is specifically designed to strike an appropriate, consensus-based balance between the need to share personal health information electronically and the need to protect it from inappropriate access or use. Although the Common Framework was originally designed to guide personal health information exchange among health care providers, its underlying principles were developed to support consumer access. Below we briefly discuss these principles.

Common Framework Policy Principles

The Common Framework has endorsed a set of fair information practices to guide systems that support the exchange of personal health information. These principles are fully presented in “P1: The Architecture for Privacy in a Networked Health Information Environment.”76 Here we summarize them:

  • Openness and transparency: Consumers should be able to know what information exists about them, the purpose of its use, who can access and use it, and where it resides. They should also be informed about policies and laws designed to ensure transparency on how privacy is assured.
  • Purpose specification and minimization: The purposes for which personal data are collected should be specified at the time of collection, and the subsequent use should be limited to those purposes or others that are specified on each occasion of change of purpose.
  • Collection limitation: Personal health information should only be collected for specified purposes and should be obtained by lawful and fair means. Where possible, consumers should have the knowledge of or provide consent for collection of their personal health information.
  • Use limitation: Personal data should not be disclosed, made available, or otherwise used for purposes other than those specified.
  • Individual participation and control: Consumers should be able to control access to their personal information. They should know who is storing what information on them, and how that information is being used. They should also be able to review the way their information is being used or stored.
  • Data quality and integrity: All personal data collected should be relevant to the purposes for which they are to be used and should be accurate, complete, and current.
  • Security safeguards and controls: Personal data should be protected by reasonable safeguards against such risks as loss or unauthorized access, destruction, use, modification, or disclosure.
  • Accountability and oversight: Entities in control of personal health information must be held accountable for implementing these principles.
  • Remedies: Legal and financial remedies must exist to address any security breaches or privacy violations.

Common Framework Technical Principles

The Common Framework also prescribes several technical principles upon which health information exchange networks should be based. We summarize them below:

  • Make it “thin”: Data exchange networks should impose the minimal requirements for storing and transmitting health data, leaving as much processing as possible to applications at the edges of the network.
  • No requirement of a national health ID: We argue that a national health identifier is neither likely nor necessary.
  • Avoid “rip and replace”: The health care industry has already invested heavily in technology. The network should take advantage of the technology currently in use, not require its replacement.
  • Separate applications from the network: The roles of the network and of applications should be distinct. The purpose of the network is simply to transfer data. All other data-related functions should reside at the application level. This architecture provides for a stable infrastructure upon which application developers may build innovative functions. Because this distinction is critical to our recommendations for networked PHRs, we discuss it further in Appendix B: How Applications Interact with Networks.
  • Decentralization: Data should remain with the originators of that data (e.g., providers, pharmacies, etc.). Consumers already have trusted relationships with these entities.
  • Federation: A federation of network members based on mutual agreements is necessary given the complexities of a decentralized network.
  • Flexibility: The network should be designed such that it can scale and adapt over time and allow participation by a wide variety of network members.
  • Security and privacy: Privacy protection and security should be top priorities that guide the design and development of the network.
  • Accuracy: There should be a low tolerance for errors with regard to identifying people and their data records. There should also be a means to correct data errors that are discovered.

Markle Connecting for Health put these principles into practice in a three-region prototype documented in previous Common Framework technical and policy papers. This paper adds to a compendium of policy resources for interoperable electronic health information exchanges. Those resources consist of:

  • An overarching “architecture” for privacy based on nine interdependent principles.
  • Model privacy policies and procedures.
  • Notification and consent policies.
  • Policies for correctly matching patients with their records.
  • Policies for authentication of system users.
  • Patient information access rights summary based on the Health Information Portability and Accountability Act (HIPAA).
  • Policies for audit logs.
  • Policies for breaches of confidential health information.

The Common Framework as an Architecture for Networked PHRs

To date, the Markle Connecting for Health policies have been designed to enable interoperable exchange of patient data among clinicians. It is a substantial challenge to add consumers to the exchange. From the policy standpoint, these principles must be translated into an adequate set of information-sharing policies to which both consumers and institutional data custodians can agree. On the technical side, a network architecture must be developed that is consistent with the above principles, yet scalable and adaptable to the many combinations of relationships that consumers have with various health care entities. These technical and policy challenges must be addressed in tandem.

Definitions in the Markle Connecting for Health Common Framework Architecture

Previously released Common Framework documents described Markle Connecting for Health's vision of a nationwide network for health information exchange. The fundamental design elements of that network architecture would not be changed by granting consumers access to the network. In fact, consumer access has always been a design principle of the work. Below we review some of the key architectural concepts described more fully in prior Common Framework reports.

Nationwide Health Information Network (NHIN): As its name implies, the NHIN is an overarching network that connects exchange networks within the nation. Thus, it is envisioned as a network-of-networks.

Regional Health Information Organization (RHIO): The current trend in health information exchange is to build provider-centric, regionalized networks. These networks are usually referred to as RHIOs. A functioning RHIO would connect multiple provider institutions in a region, such as a state or county.

Sub-Network Organization (SNO): A Sub-Network Organization is a business structure comprised of entities that agree to share personal health information in accordance with a minimum set of technical and policy requirements embodied in the Common Framework. A SNO may be organized on a geographic basis (i.e., a RHIO) or in support of other business relationships that are not determined by location. For instance, the Veterans Administration (VA) has a network of hospitals and clinics that exchange health information on a nationwide level. Both RHIOs and non-regional networks like the VA would be sub-networks of the NHIN. Thus, we prefer the term "SNO" because it is a more inclusive term than RHIO.

Record Locator Service (RLS): As its name implies, the RLS is a service that queries the locations of patient records within a SNO. Each SNO has its own RLS. The purpose of an RLS is best described by an example. A physician or other health care professional may wish to retrieve data on a patient from other institutions that the patient has visited. The physician would send a query to the RLS, which returns a list of record locations, but not the data itself. Thus, the RLS might inform the doctor that her patient has medical records at institutions X, Y, and Z. The contents of those records are not revealed by the RLS. Retrieval of data contained in an identified record is a separate process that occurs directly between the requesting physician and the institution that stores the record.

Inter-SNO Bridge (ISB): A physician might want to search for records outside his SNO. Thus, he would send a query to the RLS of another SNO. The ISB is the conduit through which these queries and responses flow. Each SNO would have an ISB, which would be its single gateway for channeling all requests and responses from other SNOs.

In summary, the Common Framework architectural vision is a network of networks (one NHIN made up of many SNOs). Each SNO uses an RLS to locate the consumer’s records and an ISB to talk to other SNOs. Institutions that want to share information across the network must be members of a SNO, comply with Common Framework policies, maintain an RLS or equivalent service, and build an ISB.

As noted in Opportunity Analysis in the Current Health Care Landscape, many important pieces of the consumer’s record are already held in digital format. The custodians of this information include:

  • Health insurance plans (both private and public).
  • Pharmacy services and clearinghouses.
  • Nationwide laboratory services.
  • Self-insured employers’ data warehouse services.
  • Large, integrated delivery networks.
  • And, to a lesser extent, some small hospitals and smaller-practice EHRs.

The next section discusses how PHRs could become part of this network, connecting consumers to their own unique slice of data and enabling them to drive health care transformation.