The COVID-19 crisis has thrown a harsh spotlight on flaws in America’s healthcare system. One of those flaws isn’t getting much attention now, but will be critical in our post-pandemic future: the lack of health data portability.
The pandemic has made it clear how important it is for healthcare data to move seamlessly between multiple systems and users. Public health officials and journalists alike have struggled to get a complete picture of the pandemic in part because the necessary data — including basic information like the number of cases in a county, or ICU capacity at a given hospital — gets stuck in inaccessible silos. Without interoperability between clinical systems and healthcare applications data is extremely difficult to manage and nowhere near as useful as it could be.
Looking beyond the pandemic, easy and secure data-sharing is crucial to building the future of healthcare that everyone wants. It’s a future in which you control your own healthcare data, you can share it easily with a new doctor or specialist, and you can use innovative new apps to glean insights from your healthcare data that improve your life.
Or we could start with a more modest goal: a future where you don’t have to fill out those endless medical history forms every time you see a new doctor, because it’s easy for you to grant electronic access to that information. Either way, easy data sharing is crucial to creating a more user-friendly healthcare system with more tightly coordinated care and, ultimately, better outcomes.
New federal regulations will help healthcare data move…
Right before the pandemic hit America last March, new regulation aiming to create this future was finalized. This regulation requires healthcare providers to adhere to a set of data standards known as Fast Healthcare Interoperability Resources, or FHIR. Without getting too technical, it mandates that electronic health records (EHR) systems use APIs, the common protocol modern software applications use to respond to data requests. APIs enable software applications to “talk” with each other better and share data more easily. Because of the pandemic, however, the FHIR requirement won’t be enforced until July 2021.
Moving the fragmented U.S. healthcare system towards a common standard for the secure storage and portability of patient data is an important step. And the idea that patients deserve easy access to their own data is a rare area of bipartisan agreement within government. The new regulation was finalized by the Trump administration, but stems from the 21st Century Cures Act, an Obama-era bill championed by Joe Biden in the last days of their tenure.
But regulation alone won’t solve the problem. There are additional hurdles that healthcare providers and the private sector will have to clear in order to make healthcare data truly accessible to patients and useful to improve care.
…but it won’t solve the interoperability problem entirely.
The fee-for-service model most American healthcare providers still work under creates powerful anti-data-sharing incentives. Large EMR companies have made data-sharing purposefully difficult for providers. If you’ve ever changed doctors, you know how hard it can be to share medical records with a new provider. In a fee-for-service world where doctors are paid per visit, per test, or per procedure, EMRs aren’t designed to make it easy for patients to get a second opinion, or even see a specialist in a different practice.
Shifting to a value-based care model would remove some of those barriers, and the pandemic may accelerate this shift. A value-based care model would incentivize all healthcare players to coordinate efforts to improve patient care — including sharing your medical records in a format more usable than a jumbled 30-page fax.
Healthcare interoperability requires read-write access to succeed.
The other hurdle is more technical. The new regs only require EHRs and clinical systems to allow read-only access to patient data. That means that you can ‘pull’ data out of an EHR or clinical system, but ‘pushing’ data may not be supported. ‘Push’ matters here in that it allows patients to update their data based on work with other providers or their use of other applications. Put in plain language: read-write access enables the patient’s digital records to reflect all the care they’ve received, accurately and in real-time. Read-only access on a shared standard is an important step forward, but on its own it won’t unlock patient data and deliver the full-performance interoperability we need.
Developers need the ability to both read and write data from EHRs in order to create the innovative applications that will actually improve our healthcare system. Say a developer creates a new app for managing diabetes, paired with an at-home monitoring kit. To maximize usefulness for both patient and provider, the app must be able to download data from the patient’s medical records, but also add new data to that record to enable collaboration with clinicians.
Developers and entrepreneurs alike should work to align all stakeholders’ incentives around true data sharing. As useful as the FHIR regulation might be, it only goes halfway towards true data liquidity. Given the pandemic and historical precedents for prior healthcare-tech regs like Meaningful Use, FHIR is very likely to get delayed.
In the meantime, the healthcare industry needs true data-sharing, and we need it now. That’s the only way to create the future we all want: one where you as a patient can easily access your own health care data, where you can easily share that data with all your doctors, and where innovative developers can create new apps that help you and your doctors better manage your health. Virtually all modern software applications run on APIs and share data freely and securely as needed. It’s time that EHRs and healthcare applications are built to do the same.
portalId : ‘2024640’,
target : “#hsformContainer-block_5f9203b231eb4”,
formId : “dc8afe08-4cff-4c23-b20a-349e9e1d9a52″,
css : ”,
The post New Regulations Aim to Set Healthcare Data Free—But More Needs to be Done appeared first on Redox.