An EHR Developers' Ring of FHIR
HL7® and FHIR® are registered trademarks of Health Level Seven International.
If Johnny Cash were alive today, he might be inclined to change the lyrics to his famous song, “The Ring of Fire” to something like this:
ONC FHIR mandates are a burning thing,
and they make a FHIRy ring,
to meet the short-term deadlines is the desire,
and to put out the compliance Ring of FHIR.
Deadlines are approaching and they burn, burn, burn.
Come to our Webinar and learn, learn, learn.
In our past blogs on Cures Act compliance, we have covered Information Blocking, Real World Testing, (g)(10) FHIR API certification, and how they are impacting the EHR developer community. Many are stumped by the Build vs. Buy decision, and suffer sleepless nights as the deadlines draw closer at an ever-increasing speed. EHRs that we are working with are faced with similar challenges and have similar burning questions. In this blog, we will focus on some of these questions.
Being the first company to complete the ONC certification criteria for the FHIR-based API (g)(10), we have had the opportunity to work with many EHRs to offer guidance and solutions on developing a roadmap to achieve compliance with these Cures Act mandated criteria - update their C-CDA to the USCDI v-1 and the API to the (g)(10) FHIR API. These mandatory updates are required not only as a part of the Base-EHR Certification but also are the focal point of the Information Blocking portion of the Cures Act.
Often, EHR developers miss that multiple components are required to satisfy the (g)(10) FHIR-API criteria. Some of these components are over and above fulfillment of patients’ requests for their information. Additionally, the API must work seamlessly in production. The Initial testing for the 2015 Edition Certification required an EHR to break the API into three criteria, (g)(7,8,9), and they were able to test with Postman. However, there are no breaks in the action in the Cures Act compliant world. Also, Postman is not a third-party app available to patients and thus is unacceptable. The Cures Act requirements are replete with many such intricacies.
Once an EHR development team steps in to the ring of FHIR, they find themselves surrounded by many questions like:
What version of FHIR do we need to support?
What are all the components of API? Is Developer Portal one of them?
How will our providers use the API and inform their patients about it?
Rather than expound on each of these questions one by one, we invite you to join us for a Webinar to understand the intricacies of Cures Act requirements, particularly (g)(10) FHIR API, and discover a simple solution.
