A story with enormous implications for the health of all Americans is likely flying below their radar and that of their physicians. In a nutshell, it’s this: A proposed rule that sets data standards will make electronic health information more accessible to patients and doctors through smartphone-style apps and will transform health care.

Most Americans are familiar with this scenario: During the “conversation” parts of a medical appointment, the doctor faces a computer screen and types information into an electronic medical record system. Such systems store data on hundreds of millions of Americans.

Yet even with all of this data entry going on, it is a struggle for patients to get copies of their records, and an even bigger one to get them in useful, digital formats. Even more alarming, despite the vast amount of data collected by electronic medical record systems, little of it is used to help clinicians make decisions about their patients’ care. That’s unacceptable.

advertisement

Each of us should reasonably expect that health systems invest as much into providing clinicians with insights to make the right diagnosis or choose the right treatment as they currently invest in determining the right ad to display on a webpage. Although that hasn’t been the case so far, there’s now an opportunity to take a quantum leap to meet that expectation.

The Department of Health and Human Services proposed a new rule earlier this year that sets data standards for health information technologies to communicate and interact with each other. This might sound like a boring or bureaucratic endeavor, of interest mainly to tech folks like us, but defining a universal interface has surprisingly large implications for what it means to receive health care in the U.S.

Here’s an analogy: The early internet did not provide a universal method for displaying richly formatted text and images, and so each document had its own unique structure. This sprawl precluded use of the internet for commercial purposes. But once Tim Berners-Lee created a few specifications that were then codified by a global consortium, standardization made it possible for a web page to be viewed anywhere by any browser. Voilà: the World Wide Web was born.

We believe that similar, straightforward data standards for how apps connect to electronic health records could spark an apps-based health information economy that gives patients and providers choices in the functionality they want and need to use, and creates a large market for innovators’ inventions.

Ten years ago, as the federal government kicked off its $48 billion investment in promoting the adoption of electronic health records (the private sector ultimately invested far more in this effort) we proposed such a specification in a Perspective in the New England Journal of Medicine. We sought to reimagine electronic health records as smartphone-like platforms to which apps could be added or deleted. A year later, the Department of Health and Human Services gave us funding to design and build SMART (Substitutable Medical Applications, Reusable Technologies) — now often called SMART on FHIR as it uses definitions for data elements defined by Health Level Seven’s Fast Healthcare Interoperability Resources (FHIR) framework.

SMART on FHIR specifies a universal application programming interface or API, that lets apps connect to electronic health records. The kind of apps we’re talking about are, for example, dynamically created, individualized, user-friendly medication instructions for patients available in many languages. For physicians, an example is an app that helps manage blood pressure in kids with hypertension, even though blood pressure norms vary widely by age. The SMART universal API approach enables an app written once to run on any platform, such as any brand of electronic health record. This property will underpin a robust market for health apps, foster innovation by kids in their garages as well as by giant technology companies, and vastly improve the health information technology experience for patients and their doctors — studies have linked electronic health record use and design to physician burnout.

Many startups now die on the vine while attempting complex integrations of their health apps with electronic health record systems at hospitals and medical practices. Other innovative health IT startups wither waiting to make even one sale. Companies creating SMART apps can readily market and distribute their products through app stores and galleries — think how easy it is to get Snapchat on your phone — instead of making one-at-a-time sales to hospitals. Apple proved the value of the SMART on FHIR interface by using it to connect its native Health app to hundreds of health care systems so iPhone users can acquire copies of their electronic health record data in a computable format.

More good news is that health apps selected from one or more app stores would compete with each other on functionality, usability, and value. Those that work best for doctors and patients will get good reviews and win.

To ensure that these benefits become ubiquitous, one of us (KDM) successfully lobbied for language in the 21st Century Cures Act that requires a universal API for health information technology. We also strongly advocated for provisions in the proposed rule that would specifically define SMART as the universal API and so foster a robust marketplace by eliminating prohibitively expensive fees by electronic health record companies for using APIs. Right now, a health care provider or an app vendor can be charged fees for every use of the API — for example, for an app to look up a patient’s blood count. These fees currently slow or stop the movement of medical information toward the doctors and patients who need it.

Current pricing and terms for apps to be listed in electronic health record app stores or even connecting to the SMART API often preclude a sustainable business model for app developers. Electronic health record companies often require sharing revenue, or even intellectual property, with app developers and assume a gatekeeping role. The proposed rule addresses the problem and limits API fees, but the economics are complex and costs must somehow be covered. Our team recommends a study in the months following implementation of the proposed rule that would evaluate the real-world cost of the SMART on FHIR interface and the effect of regulations on the development of a robust and thriving ecosystem of apps with physician- and patient-facing functionality.

A universal interface would allow physicians or hospitals to decide which apps they connect to their electronic health records without getting permission from the electronic health record vendor, and would let patients choose which apps can access their electronic health records. Providers and patients should be able to contract directly with app companies, and not have to rely on the electronic health record company as an intermediary. As things stand now, gatekeeping, revenue sharing, and intellectual property considerations tend to restrict innovation to the electronic health record companies, limiting new entrants into the health information economy.

The proposed rule creates a highly promising road map toward the easy exchange of electronic health information that exemplifies a minimalist regulatory approach for creating the standardization and uniformity needed to spark an apps marketplace. It would also create economic and commercial guardrails to promote a level playing field between electronic health record vendors and app developers. These regulations are an essential ingredient for a burgeoning apps market.

All six individuals who previously served as the national coordinator of health information technology have endorsed the rule. It has sparked robust conversation: During the public comment period on the proposed rule, nearly 2,000 comments were submitted about interoperability and information blocking. As might be expected, there is pushback from the electronic health record industry on timelines and price controls.

The proposed timeline — two years of development— has proven highly realistic, given the successful implementation of SMART on FHIR among the major brands of electronic health records by the Argonaut working group in just one year, and the work of the CARIN alliance to help connect patient apps to the SMART API.

Health system leaders and patient advocates would be well-served to look up from their smartphones and tablets long enough to see this extraordinary opportunity and help make it a reality, so when they look back down their phones and tablets are helping them and their families improve their health.

Kenneth D. Mandl, M.D., is director of the Computational Health Informatics Program at Boston Children’s Hospital and professor of pediatrics and biomedical informatics at Harvard Medical School. Isaac S. Kohane, M.D., is chair of the Department of Biomedical Informatics and professor of biomedical informatics and pediatrics at Harvard Medical School.

Leave a Comment

Please enter your name.
Please enter a comment.

  • I agree these standards are a help, but you are missing the forest for the trees. Despite interoperability challenges, large clinical data repositories are being assembled, many by medical society registries. The biggest problem in health care is: ‘data garbage in, data garbage out’ – physicians don’t have the time to enter much necessary data into structure EMR fields, so they type or dictated free text – which is totally unsearchable. For example, less than 40% of oncology patients have ‘cancer stage’, a key metric, recorded in structure. NLP data mining is a help, but not accurate enough without expensive human oversite. Until we get better data entry, which means scribes because we can’t ask the doctors to spend more time in data entry, we won’t have the quality inputs we need to do the real decision support analytics that will improve care

    • Artificial intelligence may have advanced to the point where it could serve an intermediate function as the interface for data entry (dictated or typed). An initial or draft form with the optimal fields designed by practice area experts could lurk within the app and fill in the fields as best as possible as the dictation occurs. Then, when the dictation is finished, the physician says or presses “show results,” which displays the populated form, with flags on questionable and missing fields for the physician to dictate in on a second pass. It could also include a text box showing what was unable to be condensed into the form. It’s not perfect but would save time and result in more standardized data capture. Plus the AI tool could be programmed to learn from, say, hundreds of users to improve the form itself. Eventually the practice area would have an essentially standard data capture tool, but one which would continue to learn as new diagnostic elements are discovered.

A roundup of STAT’s top stories of the day in science and medicine

Privacy Policy