We have worked to clarify an individual’s legal right to access their health information and transmit it where they choose—whether it’s to a family member or to their smartphone. These efforts help advance our Administration’s goal of fostering the seamless and secure flow of electronic health information when and where it is needed most.
Empowered patients – e-patients – desire the ability to gather, share, and control their health data. (Gimme My DaM Data!) Currently, we find health data on paper, in people’s memories and digitally – in databases, spreadsheets, software (such as electronic medical records), in various devices, apps, or clouds.
But the sources of this data are often spread far and wide and may be impossible or arduous to find. The older the person and the more complex the health conditions, the more likely that the data is in a growing number of places. Also, the more complex a person’s health conditions, the more likely that the person or their care partner is the vehicle to share that data. Some people want to know and give permission to who has access to or is accessing that data. They may change their minds about this over time. Many people entrust a family member or care partner to manage their data for them.
Clinicians, other health professionals, community health workers, researchers, healthcare organizations, policy makers, and insurers want or need health data to diagnose, plan care, pay for care, create evidence of practice and treatment effectiveness, and communicate with individuals receiving care and each other.
Adding to the difficulty is the sheer volume of data, sometimes the lack of data, and the inevitable errors in data – like drinking dirty water from a firehose.
Necessary to this data exchange are standards for data elements, data security, permissions, and data correction. In other words, wherever data is housed, it means the same thing. Creating standards requires trusting relationships in dangerous waters – trust between people, organizations, vendors, and government in any combination. It won’t happen by itself. Creating standards requires a team devoted to collaboration – finding, proposing, testing, and communicating solutions. Standards already exist. They’re called HL7, FHIR, OAuth, OpenID Connect, UMA and more. These standards fill different purposes and need to work together. If they contradict each other, it’s just more mess. Also, this crazy complicated problem needs a simple solution, so everyone can understand it and use it. To keep this process honest and grounded in real people’s experience, it helps to picture different users of data using it in different ways with different needs and desires. These are called use cases.
The OpenID Connect HEART Working Group is such a standard setting collaboration that
intends to harmonize and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others.
REST (REpresentational State Transfer) is a popular approach of accessing and managing remote resources on the Internet that relies on a stateless, client-server, cacheable communications protocol. More information can be found here.
An application programming interface (API) is a set of subroutine definitions, protocols, and tools for building software and applications. A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer.
More information about User-Managed Access can be found here.