Next week is the final opportunity for public comment on the ONC’s proposed Trusted Exchange Framework and Common Agreement. I’ve prepared a set of comments and recommendations that focus on the scope and mechanics of individual access, including technical standards, security requirements, identity proofing, authentication, and authorization.
Given the importance of health data exchange to the SMART Health IT community, I’m sharing the full letter and 15 recommendations here in PDF.
January 30, 2018
Ken Mandl (Twitter @mandl)
Despite spectacular advances in diagnostic imaging, non-invasive surgery, and gene editing, healthcare still faces a lackluster problem: many patients can only get health records from their doctor if the fax machine is working. Even when records are stored electronically, different chunks of every patient’s health information sit in the non-interoperable, inaccessible electronic record systems in different doctor’s offices.
Anyone who needs her medical files gets them either printed or faxed, or has to log on into separate portals for each doctor and hospital, and even then getting view-only access. View-only apps can’t access data to help patients share information with family and healthcare providers, make decisions, monitor disease, stay on course with medications, or just stay well.
On the positive side, this is changing, sort of. Using the iPhone Health app, patients will soon be able to download and view health records on their phones. On the one hand, don’t get too excited–it will initially only work for patients at a handful of institutions, Android users are still out in the cold, and the data available will be limited. And, some dismiss the impact of Apple’s move because of others’ failures to give patients control of their records.
However, Apple’s move is a decisive and consequential advance in patients’ struggle to get a copy of their own health data. Apple wisely chose to use open, non-proprietary approaches that will float all boats–even for Android users.
Every patient deserves a ‘bank account’ of her health data, under her control, with deposits made after every healthcare encounter. After my colleagues and I demonstrated an open, free version of a “bank account” to companies in 2006, Google and Microsoft launched similar personally controlled health records — GoogleHealth and Microsoft Healthvault. Walmart and other employers offered our version, Indivo, as an employee benefit. Unfortunately, even these industry giants couldn’t shake loose data from the proprietary computer systems in doctors’ offices, or make the case to patients that curating the data was worth the effort.
But 12 years later, Apple’s product enters healthcare under different circumstances. A lot more patient data is electronic after a $48 billion federal investment in promoting the adoption of information technology to providers. But those products, mostly older software and purchased at enormous expense, still don’t promote record sharing with doctors or patients.
Recognizing this unacceptable limitation and having received a generous grant comprising a tiny fraction of that federal investment, our team created SMART on FHIR. SMART is an interface to make doctors’ electronic health records work like iPhones do. Apps can be added or deleted easily. The major electronic health record brands have built this interface into their products.
Apple uses SMART to connect the Health app to hospitals and doctors offices. The good news for patients, doctors, and innovators is that Apple chose a standardized, open connection over a proprietary, closed one. This approach lets any other app, whether running on the web, iPhone, or Android, use that very same interface to connect.
So Apple will compete on value and customer satisfaction, rather than on an exclusive lock on the data. Does Apple’s approach help Americans trying to stay well or manage their conditions? Yes. But only with follow-through by Apple, health systems, technology companies, patient groups, policy makers, and government regulators. The emerging ecosystem’s nuances must be appreciated.
First of all, the floodgates for patient information are at least a crack open and will be very hard to close. As patients gain access to their data, they will recognize it is incomplete and feel frustrated it’s not available everywhere. But, patients in need will drive demand for data access in their role as health consumers.
Secondly, the government is effectively using law and regulations to compel an open interface. By selecting SMART on FHIR, Apple and its healthcare launch partners mark the importance of standardization. A uniform approach is critical for scale. Imagine if every electrical product required a differently shaped 120V outlet. Understanding this, Google, Quest Diagnostics, Eli Lily, Optum, and many other companies are using the same interface to plug into healthcare.
Thirdly, Apple’s first version of health records brings data onto the phone, but from there, like the portals many patients are already familiar with, the data are still “view-only.” In 2009, I had the chance to meet with Apple’s rockstar Bud Tribble and talk about how the iPhone could serve healthcare. We concluded that crucial data–like the medication list–had to be as easy for iOS developers to use in their apps as contacts and location are now. I would not be at all surprised if this is the next step in Apple’s journey–making the health records available to iPhone app developers. Here too is an opportunity to chose open interfaces, and to allow patients to export the data to another device.
Lastly, competition in healthcare IT is hot. Amazon, Google, Apple and Facebook all have healthcare divisions. Apple’s extraordinary hardware, including sensors in the phone and watch, will monitor patients at home. Google’s artificial intelligence will lead doctors and patients to diagnoses and decisions. Amazon is rumored to be eying pharmacy management. Facebook has sifted through posts to detect and possibly intervene when users may be suicidal.
There are so many opportunities to compete. Locking up a patient’s data should never be one of them.
Ken Mandl, MD, MPH directs the Boston Children’s Hospital Computational Health Informatics Program and is the Harvard Medical School Donald A.B. Lindberg Professor of Pediatrics and Biomedical Informatics.
SMART Platform (www.smarthealthit.org) is a project that lays the groundwork for a more flexible approach to sourcing health information technology tools. Like Apple and Android’s app stores, SMART creates the means for developers to create and for health systems and providers to easily deploy third-party applications in tandem with their existing electronic health record, data warehouse, or health information exchange platforms.
To deploy SMART-enabled applications, health systems must ensure that their existing health information technology infrastructure supports the SMART on FHIR API. The SMART on FHIR starter set detailed below lists the minimum requirements for supporting the API and SMART-enabled applications. You may wish to augment this list of minimum requirements with suggestions from the Add-On Functionality listed depending on the types of applications your organization wishes to deploy.
This document is intended as a resource for providers and health systems as they draft Request for Proposals (RFPs) and negotiate with their HIT vendors for added functionality. It has multiple authors from across the SMART team and its advisors. Feedback is welcome.
The vendor must support the SMART on FHIR platform, a vendor agnostic API that allows third-party developers to build external apps and services that integrate with the vended product.
At a minimum, the vendor product should include the following components in order to support SMART on FHIR and SMART-enabled applications:
The provider organization may also want to consider the following additions to its RFP depending on the types of applications it wishes to develop and run in the future.
The IP of any app integrated through the SMART on FHIR API belongs to the author and not the vendor.
Should a vendor neglect to provide SMART on FHIR natively, the client has the right to provide a custom extension to the vendor’s API. The ownership of the IP for the custom extension is negotiable between the client and the vendor, but the ownership of the app using the custom extension belongs to its author.
In an evaluation developed in partnership with SMART and funded by the Office of the National Coordinator for Health Information Technology (ONC), KLAS Research spoke with clinical leaders at nearly 50 healthcare organizations about how they select and use clinical apps today, what they would like to see in the future, and the concerns they have around adopting apps.
Findings include:
The role of apps in healthcare is growing, with many organizations looking to third-party vendors to supply niche solutions that improve patient care and organizational efficiency.
Increasing adoption of the SMART and FHIR application programming interfaces (APIs) by EHR vendors and health systems is streamlining the process of connecting these apps to clinical systems, and strong regulatory support requiring APIs in certified health IT is expected to continue driving this trend. With app discovery tools, such as the SMART App Gallery, making it easier for healthcare providers to find and evaluate apps, there is a bright future for connected apps in healthcare.
One aim of the 21st Century Cures Act recently passed by Congress is to make digital health data more accessible, emphasizing the use of APIs in healthcare to increase EHR interoperability and improve patient records matching. Aligning closely with the SMART Health IT focus on creating a app ecosystem for healthcare, the act states that a year from now, open APIs will be necessary for EHR system certification.
“… that the entity has in place data sharing programs or capabilities based on common data elements through such mechanisms as application programming interfaces without the requirement for vendor-specific interfaces;
[…] publish application programming interfaces and associated documentation, with respect to health information within such records, for search and indexing, semantic harmonization and vocabulary translation, and user interface applications; and
[…] demonstrate to the satisfaction of the Secretary that health information from such records are able to be exchanged, accessed, and used through the use of application programming interfaces without special effort, as authorized under applicable law.”
Read the full document at 21st Century Cures Act
About the Initiative
Guided by an 18-member steering committee, the National Academy of Medicine (NAM) has called on more than 100 leading researchers, scientists, and policy makers from across the United States to provide expert guidance on 19 priority focus areas for U.S. health policy. The resulting collection of discussion papers is organized around three overarching goals for the United States: better health and well-being; high-value health care; and strong science and technology.
“As the country orients toward alternative payment models, measuring individual health outcomes and disparities among vulnerable populations is crucial for driving innovation toward outcomes that matter most to individual lives.”
“Simply building APIs into EHR products so that data can be called by external applications will improve the current state. But the most important goal is that—as in an “app store”—an app written once will be able to run anywhere in the health care system and that a decision support service will be able to be created once and be called from any care point in the system. “
Read the Discussion Paper On Information Technology Interoperability and Use for Better Care and Evidence
President Obama’s Cancer Panel defines connected health as “the use of technology to facilitate the efficient and effective collection, flow, and use of health information.” In their 2016 report to the President, the panel highlights the benefits of using the SMART On FHIR open-access API for development of health applications.
“The Precision Cancer Medicine (PCM) app was designed to present patients’ genomic test results to oncologists in real time as a component of clinical practice, as well as provide links to external knowledge bases that otherwise would be unavailable through the native EHR system. PCM was piloted at Vanderbilt University and integrated into that institution’s EHR system. However, because the app was developed based on an open-access API (Substitutable Medical Applications and Reusable Technology, or SMART) and uses the emerging HL7 Fast Healthcare Interoperability Resources standard, it could easily be deployed for other compatible EHR systems.”
“The Panel urges all stakeholders—health IT developers, healthcare organizations, healthcare providers, researchers, government agencies, and individuals—to collaborate in using connected health to reduce the burden of cancer through prevention and improve the experience of cancer care for patients and providers.”
Improving Cancer-Related Outcomes with Connected Health: A Report to the President of the United States from the President’s Cancer Panel. Bethesda (MD): President’s Cancer Panel; 2016.
A web-based version of this report is available at: https://PresCancerPanel.cancer.gov/report/connectedhealth
As part of a broader survey of 1,300 physicians covering digital health tools, the SMART Health IT Project and the American Medical Association collaborated on a set of questions to better understand how providers wish to discover, evaluate and purchase apps that connect with their EHR system.
One important finding for app creators is that 81% of physicians ranked integration with their EHR as a very important or important requirement for digital health tools. Additionally, more than half of the physicians indicated that they are extremely likely or very likely to purchase apps that extend their EHR system’s capabilities and securely integrate into the EHR workflow.
Download the full report at: https://www.ama-assn.org/sites/default/files/media-browser/specialty%20group/washington/ama-digital-health-report923.pdf
We’re looking for a senior developer to work full time on the open source SMART on FHIR project!
The Boston Children’s Hospital Computational Health Informatics Program (http://www.chip.org), a Harvard Medical School affiliate, is seeking an experienced full stack web developer to join the SMART Health IT team.
The platform is REST-based, incorporates OAuth2 and related technologies on the security layer and can use JSON and XML serialization formats. The team you will be joining writes services, applications and frameworks for web and mobile platforms in various programming languages and likes to give the latest and greatest technology a try.
The ideal candidate:
Bonus points if:
Please submit a cover letter describing your background, a resume and a code sample that represents your best work to: smart.dev.job@gmail.com
You must be logged in to post a comment.