The Office of the National Coordinator for Health IT this week released a brief describing the experiences of participants in the Sync for Science pilot, nearly five years since the project’s launch.
The S4S pilot supported organizations in enabling patients to donate data to researchers at the National Institutes of Health through the development of APIs.
By the end of the pilot project period, 11 provider sites were participating via Allscripts, Cerner, eClinicalWorks and Epic.
Six of those successfully launched with connectivity to the NIH’s All of Us research project are: Cedars-Sinai Health Clinic, Cerner Health Clinic, Duke University Health System, Partners HealthCare, Rush University Medical Center and University of Missouri Health Care.
According to the brief, ONC used the participants’ experiences to identify barriers to broader adoption of patient-directed data sharing, as well as facilitators for that broader adoption.
WHY IT MATTERS
S4S used the HL7 SMART on FHIR and OAuth 2.0 Authorization Framework standards – the same as those used within the ONC Cures Act Final Rule.
“The assessment aimed to understand the approaches taken by the S4S team, health IT developers, and provider sites to inform future expansion of S4S and support ONC and its federal partners in expanding opportunities to use SMART on FHIR standard APIs and third-party apps by patients,” read the brief.
Over the course of the pilot project, three versions of the FHIR standard specification were released. Some health IT developers maintained several standards, while others used only one. Because the S4S All of Us integration only allowed for the use of the Draft Standards for Trial Use version 1.0.2 (DSTU 2) standard, provider sites using Standards for Trial Use version 3.0.2, or STU 3, were unable to connect and participate.
Although developing the APIs themselves was straightforward, evaluating their performance using realistic test cases was time-consuming – and half the provider sites required a special upgrade to their EHR software before testing the FHIR standard API. Perhaps unsurprisingly, sites with past experience with API connectivity to third-party apps required less testing.
When it came to using APIs for research, the S4S pilot project showed how research requirements – including institutional review board review and approval – can affect the ability to adopt APIs and third-party apps.
“The IRB application submission and approval time frame and process created project delays for onboarding both health IT developers and provider sites, which caused a loss of momentum and engagement for some provider sites,” read the brief.
“IRB requirements that restrict or specify user interface or technical architecture requirements can limit the flexibility to incorporate pilot feedback or updates to the technology,” it continued.
The ONC recommended several other considerations with regard to using third-party apps for research, including establishing a formal governance structure, conducting user validation and testing, and providing clear documentation for health IT developers’ and providers’ sites on how to continue support beyond the initial API launch.
THE LARGER TREND
As the ONC brief notes, organizations are currently implementing the patient-facing standards-based API enabling individuals to share data with the apps of their choice in response to the ONC Cures Act Final Rule.
“The S4S pilot project established early efforts to support patient-directed sharing of health information with research,” read the brief.
However, the establishment of the FHIR standard alone isn’t enough. As health IT leaders noted at the American Medical Informatics Association annual virtual symposium this week, barriers remain to integrating externally developed third-party apps both into EHRs and into clinician workflow.
“Our clinicians will use a clunky app that’s integrated in the workflow over a sleek app” outside of it, explained University of Utah CMIO Maia Hightower.
ON THE RECORD
“The S4S pilot project assessment provided a wealth of information and insight from four health IT developers, five provider sites, and All of Us partners on the successes, challenges, barriers, and lessons learned from the initial phase of this collaboration,” read the brief.