The ONC has been steadily working to implement needed standards to support fluid, nationwide interoperability, considering a new approach to endpoint lists. (Photo by Silvio Avila/Getty Images)

The Office of the National Coordinator is considering a more standardized approach to the FHIR resource format and corresponding resources for published endpoint information used in its interoperability effort, after its Lantern tool discovered a variability in the public endpoint lists. 

The issue made it difficult for users and Lantern to systemically consume the endpoint information.

Lantern was developed by ONC with input from industry stakeholders to develop a standard format for endpoint lists while identifying endpoint data that should be made available to “facilitate interoperable linkages to these endpoints.”

ONC explained that “these electronic endpoints are the specific locations on the internet that make it possible for an app to know where to go to access health information on behalf of the users.”

However, ONC quickly found the aforementioned variability in the public endpoint lists. As it stands, the current FHIR endpoint resource structure allows just one listing per organization: the managing organization. It’s problematic, as one managing entity may represent many organizations serviced by the endpoint.

In December, ONC received feedback that sought to address this issue with greater standardization of the endpoint information published in the FHIR endpoint resource format.

The proposed fix would enable the endpoint data to “be made publicly accessible outside the FHIR server’s authentication/security framework” and “allow a user to query a publicly accessible endpoint’s system for associated organizations and retrieve them in the standardized FHIR format already supported by the system.”

The shift in tactic, according to ONC, would better support both developers and users of the certified API technology used in the nationwide interoperability effort.

The proposed approach was published in an ONC update on the progress of its interoperability efforts through the HL7 FHIR APIs and the supportive Lantern tool meant to monitor the nationwide FHIR API implementation, issued just two weeks after unveiling the Trusted Exchange Framework and Common Agreement.

Feedback to the ONC showed broad agreement that the standardization would benefit both developers and users of the certified API technology. ONC is asking for greater input from healthcare industry stakeholders to determine the right path forward to securely support the overall interoperability push.

Does the update address issues with security?

What’s noticeably missing from this update and workshop discussion is “security and trust” language,” explained Dirk Schrader, global vice president of security research for NNT, part of Netwrix. “

The noted provisions for authentication methods are a strong foundation, but “the words ‘security’ and ‘trust’ are not mentioned once in the certification guidance document published online,” said Schrader. 

“In a network of endpoints — built, operated and maintained by independent entities, with the purpose of exchanging ePHI — this aspect simply cannot be left out,” he continued. The language is a crucial part of “security’s ‘least common denominator,’ which usually is no security at all.”

The certification guidance should directly reference the required standards to secure information in transport to orchestrate “the mutual trust between endpoints and applications, from the certification.” He noted, “that line of thought is corroborated by the ONC stating that the rule of ‘Preventing Harm Exception’ should not interfere with access to and exchange or use of patients” data.

The infrastructure to support this important interoperability movement must have “rigorous protection mechanisms, and these have to be a requirement, not a nice-to-have.”

For Lee Barrett, executive director of the Electronic Health Network Accreditation Commission, the security mechanisms noted are certainly important and the lack of these mechanisms would raise serious concerns. But ONC could be avoiding “mandates” of these security standards to ensure greater participation.

By starting off voluntarily, ONC may be able to move the industry forward on the vastly important interoperability effort with enough participants. From there, the effort can build on “success models of data exchange” and how patients respond to getting a lot more of their information.

As more use cases become success models, and the industry hears about it, it could be an “almost de facto, that if you don't get involved, you become competitively disadvantaged, rather than ONC putting down the gauntlet and mandating it,” said Barrett.

Progress on API security and interoperability

ONC has been steadily pushing to provide patients with better access to their healthcare data for four years, as seen in the number of enforcement actions taken against providers that fail to timely respond to patient access requests. Those will likely continue into the foreseeable future, as each step of the interoperability plan takes hold.

And as Barrett stressed, ONC is certainly working on security to combat these key challenges even if it isn’t overtly advertising those efforts. There will always be risk and concerns in this area, but there are a lot of players behind the scenes working to address the security issue, and “it’s not being swept under the rug.”

As an industry, interoperability, and the means to accomplish it, must be examined through a lens that determines where the risk vectors exist and how to reduce the risk of attack or breach.

One important piece of the interoperability effort is the unified data access protocol, or UDAP: a supportive standard for FHIR APIs.

“As we look to operationalize uninterrupted interoperability, it needs to be pretty dynamic to get to and install and exchange the large number of APIs that are going to be out there,” Barrett. That dynamic must also cover the various servers that will become designated API servers.

The way to accomplish this is with UDAP and continued accreditation programs that raise the bar on API privacy and security, such as the CARIN code of conduct. Barrett explained that UDAP is one way ONC is raising the bar from an interoperability perspective to identify and address the risk vectors.

At the end of the day, the ONC interoperability team has incorporated these various codes of conduct into the API accreditation programs that will require entities to submit their API to be accredited, based against a testing engine on the UDAP to ensure the API is meeting those standards.

Last May, ONC recommended health IT developers certify to the new FHIR-based API certification criterion when publishing endpoint lists. The more developers that leverage this approach, the more standardized and consistent endpoint ingestion will be — without the need for potential customization of individual lists.

Despite the recommendation, more progress is needed to create greater uniformity and consistency. The more healthcare moves forward with the interoperability plan, the more risks, vulnerabilities, and solutions can be identified: like Lantern finding the endpoint issue, Barrett concluded.