US healthcare is exceptional among rich economies. Exceptional in cost. Exceptional in disparities. Exceptional in the political power hospitals and other incumbents have amassed over decades of runaway healthcare exceptionalism.
The latest front in healthcare exceptionalism is over who profits from patient records. Parallel articles in the NYTimes and THCB frame the issue as “barbarians at the gate” when the real issue is an obsolete health IT infrastructure and how ill-suited it is for the coming age of BigData and machine learning. Just check out the breathless announcement of “frictionless exchange” by Microsoft, AWS, Google, IBM, Salesforce and Oracle. Facebook already offers frictionless exchange. Frictionless exchange has come to mean that one data broker, like Facebook, adds value by aggregating personal data from many sources and then uses machine learning to find a customer, like Cambridge Analytica, that will use the predictive model to manipulate your behavior. How will the six data brokers in the announcement be different from Facebook?
The NYTimes article and the THCB post imply that we will know the barbarians when we see them and then rush to talk about the solutions. Aside from calls for new laws in Washington (weaken behavioral health privacy protections, preempt state privacy laws, reduce surprise medical bills, allow a national patient ID, treat data brokers as HIPAA covered entities, and maybe more) our leaders have to work with regulations (OCR, information blocking, etc…), standards (FHIR, OAuth, UMA), and best practices (Argonaut, SMART, CARIN Alliance, Patient Privacy Rights, etc…). I’m not going to discuss new laws in this post and will focus on practices under existing law.
Patient-directed access to health data is the future. This was made clear at the recent ONC Interoperability Forum as opened by Don Rucker and closed with a panel about the future. CARIN Alliance and Patient Privacy Rights are working to define patient-directed access in what might or might not be different ways. CARIN and PPR have no obvious differences when it comes to the data models and semantics associated with a patient-directed interface (API). PPR appreciates HL7 and CARIN efforts on the data models and semantics for both clinics and payers.
By KENNETH D. MANDL, MD, MPH, DAN GOTTLIEB, MPA, and JOSHUA MANDEL, MD
This piece is part of the series “The Health Data Goldilocks Dilemma: Sharing? Privacy? Both?” which explores whether it’s possible to advance interoperability while maintaining privacy. Check out other pieces in the series here.
A patient can, under the Health Insurance Portability and Accountability Act (HIPAA), request a copy of her medical records in a “form and format” of her choice “if it is readily producible.” However, patient advocates have long complained about a process which is onerous, inefficient, at times expensive, and almost always on paper. The patient-driven healthcare movement advocates for turnkey electronic provisioning of medical record data to improve care and accelerate cures.
There is recent progress. The 21st Century Cures Act requires that certified health information technology provide access to all data elements of a patient’s record, via published digital connection points, known as application programming interfaces (APIs), that enable healthcare information “to be accessed, exchanged, and used without special effort.” The Office of the National Coordinator of Health Information Technology (ONC) has proposed a rule that will facilitate a standard way for any patient to connect an app of her choice to her provider’s electronic health record (EHR). With these easily added or deleted (“substitutable”) apps, she should be able to obtain a copy of her data, share it with health care providers and apps that help her make decisions and navigate her care journeys, or contribute data to research. Because the rule mandates the ”SMART on FHIR” API (an open standard for launching apps now part of the Fast Healthcare Interoperability ResourcesANSI Standard), these apps will run anywhere in the health system.
It’s heavy tech time at THCB. Health 2.0 is running a developer conference called Health:Refactored on May 13-4, and a big topic there will be the opening of APIs from Microsoft, Intel, Walgreens, NY Health Information Network, MedHelp, Nuance and more. What’s an API, why does it matter for health care? Funny you should ask but Andy Oram from O’Reilly Radar wrote an article for THCB all about it!–Matthew Holt
As the health care field inches toward adoption of the computer technologies that have streamlined other industries and made them more responsive to users, it has sought ways to digitize data and make it easier to consume. I recently talked to two organizations with different approaches to sharing data: the SMART platform and the Apigee corporation. Both focus on programming APIs and thus converge on a similar vision off health care’s future. But they respond to that vision in their own ways. Differences include:
SMART is an open source project run by a medical school and is partially government-funded; Apigee is a private company.
SMART tries to establish a standard; Apigee accepts whatever APIs its customers are using and bridges between them.
”…address well-documented problems that have impeded adoption of health IT and to accelerate progress towards achieving nationwide meaningful use of health IT in support of a high-performing, learning health care system.”
One of these grants was awarded to a Harvard group led by Drs. Ken Mandl and Isaac Kohane, based in Children’s Hospital Boston and Harvard Medical School. This research team is tackling the problems associated with developing an ecosystem of modular, plug-and-play medical applications, what we have referred to as Clinical Groupware. (Disclosure: DCK is on the Harvard SHARP grant’s advisory board.)
The research is aimed at creating a “medical apps store” based on the iPhone/iPad model of substitutable applications running on a device or platform. The name of the project, SMArt, stands for “Substitutable Medical Applications, re-useable technology.” The approach could impact both the EHR industry and the federal regulatory and standards process, possibly within a relatively short period, i.e., 1-3 years, so we think it merits your attention.