USCDI's power will be stifled until write access is required
Today is the final day to submit feedback to the ONC on version four of the USCDI. Since USCDI first came out in 2020, the ONC has made several useful updates and regularly raised the bar on the data that Certified Health Information Technology must be able to exchange. For example, version 2 added sexual orientation and gender identity as constituent data elements to better support care for LGBTQ+ patients, and version 3 brought the first billing-related data class of health insurance information. No doubt USCDI is an important standard that moves healthcare interoperability forward.
Yet USCDI can't reach its full potential as long as the regulations for CHIT continue to focus on read and search capabilities. Currently, vendors are required only to provide a standard API that can "respond to requests" for the mandatory data points. This solves only one half of the interoperability equation. The ability for external systems to create and update data in a patient's chart is equally important in the pursuit of a competitive app-based ecosystem.
Write about that
Why is write access as important as read? For one, the ability to write data into an EHR opens up a large number of workflows for digital health companies. Remote patient monitoring, insurance verification, diagnostic questionnaires, and clinical research immediately come to mind, but the possibilities go well beyond such a short list.
Secondly—and just as importantly—write access better enables innovators to challenge the dominant position of EHRs as the guardians of our health information. Prioritizing read and search implies that the EHR knows all and you should just accept that. Anyone with experience in this industry, however, recognizes that the fragmented nature of health IT means the EHR can't be everywhere and know everything. There are numerous sources of data—from patients to wearables to insurance payers—that could meaningfully contribute to a patient's health record if they just had an easy, standards-based way to do so.
Plus, establishing a floor for CHIT to accept data over RESTful APIs will accelerate our shift to modern standards and technologies. Nowadays plenty of write operations occur, but vendors must work around limited API support and leverage options such as HL7v2 interfaces and file imports. These can work well in many instances, but they can take longer to implement, are harder to scale, and come with extra baggage such as the need for a VPN. The technology for 21st-century data exchange exists; we just need to nudge CHIT developers towards robustly supporting it.
Do it the write way
To be clear, federal rules don't need to require unlimited write access. They could take an incremental approach, first obligating updates and then create operations, and it may not make sense to mandate delete access via APIs. I acknowledge too that mandating write access will create additional burdens for CHIT developers, since validating, sanitizing, and ingesting data from an external source is inherently more complex and riskier than responding to a request. Yet another reason why slow and steady is likely best here. Nevertheless, it's important that we begin this journey now; otherwise the power of USCDI will continue to be stifled.
---
Photo by Michael Anthony on Pexels
