API Standards Your Healthcare IT Vendor Should Use
With heightened demand for improved interoperability, well-developed APIs won’t just be a nice-to-have in healthcare. EHR vendors are increasingly seen as a launchpad for new and important digital health applications, meaning forward-thinking API standards for electronic health record platforms are more important than ever. But whether you’re hiring a developer for your practice, or you’re a developer new to the healthcare space, it’s important to know some of the fundamental building blocks an API should consist of in the industry.
Formatting & Healthcare Industry Standards: JSON, FHIR and Restful APIs
JSON
JSON has been adopted across many industries as the ideal format for sending and receiving information via APIs, but it’s not the only way to display information. Health Level 7, or HL7, is an early set of healthcare-specific standards for transporting clinical information, and while it’s still in use, it’s not particularly encouraged for new app development in the healthcare industry anymore.
“HL7 is an old format for healthcare records, and we could have built the API using that, but it’s a little outdated, so making an API looking into the future and using JSON- which is what a lot of other APIs use- makes it a lot easier for programmers to develop,” said Briggs McKnight, one of DrChrono’s API developers.
For programmers that do need HL7-formatted data, app integrations are oftentimes available to convert the information, but it’s recommended to build an API on a modern language and provide the option for HL7 conversion in those edge cases.
Restful API
REST APIs are important for platforms that handle continuous data calls, and it tends to be favored over the more rigid SOAP protocols.
“It means that we’re sending information in HTTP [hypertext transfer protocol], so we are sending information like a URL. We have a lot of endpoints which are essentially a bunch of URLs that people can go to,” said Briggs.
That makes it easier and more compatible for large amounts of data to be sent and received, especially for mobile applications.
FHIR
Fast Healthcare Interoperability Resources, or more commonly known as FHIR, is a newer API format used by Apple Health Records and other companies developing solutions for issues around patient health record access. DrChrono’s OnPatient app - a platform where patients can manage records and appointments- was created with the FHIR format due to its high regard as the future of healthcare formatting.
“FHIR is the future, and it’s starting to take over HL7. It’s useful in coding too, because it looks a lot like JSON in the sense that you’re using objects like JavaScript. So the FHIR format looks very similar to JSON format, and you could convert it easily, whereas HL7 can just be a headache,” Briggs said.
The shift to this new format is not just hype either. Recent policies are starting to encourage or outright require the transition to FHIR formats. The Center for Medicare and Medicaid Services (CMS), recently issued a rule requiring some government-funded plans, such as Medicaid and Qualified Health Plan payers, to build their APIs using FHIR in order to improve access and cut prior authorization turnaround times.
Security
OAuth 2.0 is a reliable standard for ensuring a secure connection to the API. While not universally adopted, it’s viewed as an important security measure and is in use by large tech companies like Google and Apple. It’s particularly important when dealing with patient data and HIPAA regulations.
“It is an industry standard for secure log-ins. A lot of social media sites, like YouTube, use it, for example. DrChrono uses that not just on the API, but on the front end as well in order to make sure that whoever is connecting to DrChrono is in fact the user and not a machine,” said Aaron Bethea, API developer at DrChrono.
It’s usually an easier way to obtain authorization, as it simply requires the user to confirm access, rather than using an API key.
Documentation & Support
Documentation is one of the most crucial components of navigating the API, and its importance should not be underestimated.
“[Good documentation] makes it so much easier for programmers to come in and get going. It makes it so that everything is outlined. You can look for and find a particular endpoint, see what it does and understand it a bit better. It just helps programmers build better,” said Briggs.
Documentation helps with not only finding endpoints- the point at which an API connects with the program it needs to communicate with- but it also helps developers complete the authorization process more seamlessly, connect with webhooks, integrate iframes and much more.
In addition, maintaining a community forum helps those who are trying to build off an API but are running into obstacles. Google Groups, for example, is frequently used as a place to connect developers with those who have previously run into similar challenges.
Searching, Paging and Sorting
After ensuring that the API you’re building on has secure connections, documentation and relevant formatting, you’ll want to know that you can easily search the criteria you’re looking for at a granular level. And because API calls can return large quantities of appointment and patient information, this data should be sorted and timestamped.
Paging is also critical. A good API should limit the amount of visual data returned to make it digestible for the user, while still demonstrating that there is more available according to the specifications requested.
While most of these characteristics have been widely adopted in other industries, their usage becomes even more crucial as patients, providers, legislators and health systems move closer towards robust health data standardization.