SMART on FHIR Team: Proposed Interoperability Rule ‘an Enormous Step Forward’
The SMART on FHIR team members who 10 years ago proposed that EHRs could serve as a platform with a universal application programming interface (API) supporting substitutable apps are enthusiastic about the 21st Century Cures Act Proposed Interoperability Rule, calling it an enormous step forward. “The rule addresses and reinforces virtually all of the major underpinnings which are currently feasible and needed to produce an interoperable apps-based ecosystem,” they wrote in submitted comments. But they do offer suggestions and constructive criticism on a few specifics such as immature standards.
Among the key recommendations from Dan Gottlieb, Josh Mandel and Kenneth Mandl on electronic health information (EHI) export is that the Office of the National Coordinator for Health IT (ONC) should require certified EHRs to support full EHI export at the patient level via patient-accessible API, and at the population level via data-provider-accessible API.
The ONC proposes the “API Resource Collection in Health” (ARCH) Version 1 implementation specification, which would list a set of base FHIR resources that health IT modules certified to the proposed API criterion would need to support. The SMART team suggests that ONC populate it using community-developed standards by groups like Argonaut and HL7, who can take functional requirements from USCDI versions, and produce implementation guides. “If ONC maintains an ARCH definition, this definition should be limited to referencing implementation guidance from community-developed processes; ONC should not ‘get out ahead’ of the community process. For example, the ARCH should not make unilateral determinations about which FHIR resource or data elements are needed to meet a given USCDI requirement. Instead, that determination should be made through a community-driven, iterative process with real world testing of use cases.”
While they noted that the vast majority of referenced standards in the rule are mature, in real world use, and widely embraced, the team members expressed concern about two, data segmentation for privacy (DS4P) and Consent2Share, which they called “not ready for prime time.” Saying they recognize privacy maintenance and consenting are essential functions in healthcare, “we are very concerned that a premature push for adoption of these immature standards would have unintended negative effects. ONC should omit these from the certification criteria (including voluntary certification) and focus on driving real-world implementation experience before pursuing regulations.”
The SMART team members also expressed concern that image sharing may slip through the cracks. Although EHRs often contain metadata around the available imaging studies, the imaging studies themselves are frequently stored in separate picture archiving and communication system (PACS) systems. They recommend making PACS vendors subject to EHR certification rules, specifically for API access requirements.
Likewise, while some clinical laboratory result data are accessible to patients through EHR APIs, historical data may not be comprehensive, they note. “Recently, national laboratory companies have begun to make these data available through API access for select apps. To promote a robust ecosystem of clinical applications, guidance should be provided on how this access should be expanded to an open ecosystem of apps to comply with the information blocking restrictions in the rule.”
