Current and Future State of API in CEHRT
This week Keith Boone made an interesting post on the future of FHIR and pontificating on which version ONC will adopt on its forthcoming regulations around 21st Century Cures and information blocking. He sees two possible choices: FHIR DSTU2 with Argonaut, or the newer FHIR R4 with US Core, either of these with SMART on FHIR, and his bet is on FHIR R4 with US Core and SMART on FHIR.
Like Keith, I expect ONC to adopt a specific set of FHIR requirements instead of the general API compliance we have now in 2015 Edition. 2015 Edition certification requires implementing an API, but they did not state a specific profile to use. I don’t fault ONC for leaving it open given they finalized these rules in 2015 and API market was still very much in its nascent stage without a clear profile to use, but at the same time, it is now clear we need to standardize.
Recently, ONC released a study of current EHRs 2015 Edition certified on a API criteria. They did a manual study of the API documentation of the certified EHRs to see what type of API functionality they had implemented. Some quick highlights...
Over 50% are using OAuth for authorization. The other half has authorization identified as simply Other or Unknown.
About a third are using FHIR DSTU2 (Release2). Slightly over 20% are using some other version of FHIR or FHIR with a clear identification of release. The remaining group, around 50% of those who are certified on API are identified as using REST or some other API.
These numbers definitely show the fragmented API market and the need to standardize on something. At the same time, a deeper dive shows there is a market direction.
In that same blog post, ONC indicates that 10 of the largest vendors -Epic, Cerner, MEDITECH, CPSI, Allscripts, MEDHOST, eClinicalWorks, GE Healthcare, athenahealth, and NextGen - cover over 80% of the hospital market and 2/3rds of the ambulatory market.
Looking at them from an API perspective, all ten are using OAuth, and all but one (eClinicalWorks) use FHIR DTSU2 (eCW uses FHIR STU3). Thus, the clinical health IT space, in terms of technology in the hands of the majority of clinicians and hospitals, has more or less adopted Release 2.
Going back to Keith’s question of what will be chosen, it is one of the classic dilemmas in policy: standardize on the most widely implemented current option to allow the industry to more quickly align or push for a newer and more advance and better standard. The former requires less overall man-power across the industry to develop since so many have already implemented it but it may be soon outdated or simply lacking in necessary features which the newest option provides. Of course, going to FHIR R4 with US Core requires everyone to make some changes and update their technology, which may be a hard sell given developers just finished significant work to become 2015 Edition certified.
I don’t know enough about FHIR R4 with US Core to best answer this question, but my general leaning is to go with DTSU2 and bring in the SMART on FHIR and other aspects to really advance the client app interface interoperability. I think we often spend too much time pursuing the next standard when it would be better served making the current one really work.
However, I actually expect ONC to propose in the NPRM to adopt FHIR R4 with US Core. In NPRMs, you often shoot high and take in the industry feedback to determine if you need to change. It is always easier to fall back from the NPRM to the Final Rule in terms of requirement complexity than to increase them. The industry stakeholders responses will ultimately determine what they land on.
