Picture an ideal healthcare environment where fitness trackers, patient apps, hospital systems, pharmacy software, and lab tools effortlessly exchange data. In this imagined world, any concerned party — from patient to physician to medical researcher — can instantly access corresponding files via smartphones.
But reality looks quite different. Over 90 percent of US patients from all 50 states complain about the lack of data sharing, with 67 percent planning to change care providers because of it. What’s even more surprising is that faxes and phone calls remain the communication means of choice in health departments across the country that invented the Internet.
To address this problem, interoperability rules were introduced in 2020. Aiming at seamless data transmission in the medical domain, they are expected to put a lid on using archaic devices. Instead of fax machines, healthcare stakeholders will primarily rely on application programming interfaces or APIs.
If you are not familiar with the technology, please, read our article What is API? or watch the dedicated video on YouTube.
The video explains how systems communicate with each other.
This article deals with the current use of APIs across the industry. Namely, we’ll investigate
- EHR APIs,
- consolidated APIs to access patient data,
- clinical data management and analytics APIs,
- public health content APIs,
- drug data and drug interaction checking APIs,
- symptom checker APIs. and
- telehealth APIs.
But first, we’ll explore data exchange standards, specific to healthcare and critical for understanding how healthcare APIs work.
Key standards of healthcare data exchange
Healthcare sticks to data standards that help industry systems and professionals be on the same page. You may learn more about codes and formats used across the industry from our article Data Standards in Healthcare. Here, we’ll focus only on the most critical norms related to data exchange via API.
FHIR API and its role in interoperability
Short for Fast Healthcare Interoperability Resources, FHIR is the main industry standard, developed for sharing healthcare data, specifically — Electronic Health Records. It utilizes the REST API architecture, implemented on HTTPS (HTTP Secure) protocol, and enables health systems to exchange data in JSON and XML formats.
The idea behind FHIR is to represent patient records as a set of resources, or separate data pieces of the same size and structure. Each resource has a unique ID and contains a small portion of information (say, a lab result or medication details). Depending on the query, the FHIR-based API retrieves a single resource or a combination merged in a larger document.
FHIR data model. Source: HL7 FHIR Release 4
Under the interoperability rules, healthcare providers and payers must implement FHIR to make certain elements of clinical and claims data available to patients via health apps.
However, it is expected that over time the standard will find widespread adoption across the entire industry, with all medical data structured as small, discrete resources.
USCDI standard
USCDI stands for United States Core Data for Interoperability. It defines a set of mandatory data pieces to be exposed via their FHIR APIs at a patient’s request.
The data elements in USCDI align with those in FHIR and fall into larger data classes such as
- Allergies and Intolerances,
- Assessment and Plan of Treatment,
- Care Team Members,
- Clinical Notes,
- Goals,
- Health Concerns,
- Immunizations,
- Laboratory Tests and Results,
- Medications,
- Patient Demographics,
- Problems,
- Procedures,
- Provenance,
- Smoking Status,
- Unique Device Identifiers for a Patient’s Implantable Devices, and
- Vital Signs.
The second version of USCDI, which is now at the draft stage contains two new classes: Diagnostic Imaging and Encounter Information.
Data classes and elements in the second version of USCDI. Source: HeathIT.gov
Security standards
More often than not, data that goes through healthcare APIs can be classified as protected health information (PHI.) So, it’s subject to privacy and security standards, aimed at preventing unauthorized access to and misuse of sensitive details.
In the US, these standards are dictated by the Health Insurance Portability and Accountability Act (HIPAA.) Among other things, it explains what technologies and procedures must be used to guarantee the proper level of security. In the European Union, health data is secured by the General Data Protection Regulation (GDPR.)
Both laws grant patients the right to access their personal information and oblige most healthcare APIs to be HIPAA- or GDPR-compliant. This means data must be accessible to the authorized users only and encrypted before transmission.
SMART on FHIR
SMART stands for Substitutable Medical Apps & Reusable Technology. Its purpose is to outline how to safely integrate EHR systems that use FHIR with third-party applications. Among other things, SMART dictates applying OAth2.0 authentication protocol. However, compliance with HIPAA and other regulations is beyond its scope.
The framework supports both patient and provider apps, that can be launched as standalone solutions or plugged directly into an EHR system.
Keeping standards in mind, let’s proceed with the intended use case for FHIR APIs in healthcare — access to Electronic Health Records.
EHR API: extracting data elements from health records
Data exposed: USCDI data elements and other patient information stored within one health IT system
What to build with them: patient-facing health apps, telehealth platforms, patient management solutions to track and monitor treatment plans, augmentation to existing patient portals.
Naturally, leading EHR vendors were first to comply with interoperability rules, long before they went into effect. Here, we’ll review FHIR resources from the EHR systems with the largest market share, namely
- Epic (29 percent),
- Cerner (26 percent),
- MEDITECH (17 percent), and
- Allscripts (7 percent).
Together, the Big Four spans almost 80 percent of US hospitals and health systems, so their APIs deserve closer study.
Epic on FHIR API
Over 250 million American patients have their health records in the Epic ecosystem. Access to this data is provided via Epic on FHIR APIs. Developers may create apps that will retrieve over 50 data elements including but not limited to the USCDI set.
Epic offers a self-service testing sandbox to try integrations and understand their behavior before going live. The responses and supported actions (search, read, create) vary depending on who is using the app — patients or medical workers.
Epic doesn’t verify developers or license the software they design with FHIR APIs. So, you are fully responsible for your product and its compliance with all applicable regulations.
Cerner Ignite APIs
Covering nearly 100 million US patients, Cerner offers the Ignite APIs that support over 30 FHIR resources. They can be searched, read and, in some cases, created or updated.
Besides that, Cerner has a separate API to retrieve data from its population health management platform Healthelntent. It automatically constructs patient records from many data sources — instead of extracting pieces of information from a single document. The API is meant for business-to-business solutions only.
The company's open sandbox allows developers to test their app without authentication. On completion, software must undergo the validation process that can take 10 to 14 weeks.
The validation process of an app built against Cerner APIs. Source: Cerner’s Open Developer Program
MEDITECH Patient Health Data API
The number one acute care and home health EHR enables client applications to interact with its database via Patient Health Data APIs. They give read-only access to 16 data resources coinciding with USCDI data classes.
For testing projects against a real MEDITECH EHR, the company has a development environment called Greenfield. The sandbox includes detailed documentation, technical support from licensed MEDITECH developers, and an online forum.
However, the option is available for MEDITECH Expanse customers only. To gain this status, you must submit data about you and the purpose of your app via a special form.Then, just wait and hope that your submission is approved.
Allscripts FHIR API
In 2020, Allscripts was ranked the top EHR vendor for ambulatories and inpatient hospitals. Totally, the company connects 20 million patients. Its FHIR API links third-parties to all products by Allscripts.
Currently, the API works with 14 USCDI classes. Developers may test their integrations in the corresponding sandbox environment. All you need to work with FHIR-enabled APIs is to sign up with Open Allscripts Developer Program (ADP). However, this option allows for building only patient-side apps. Health companies who want to connect to Allscripts products must become ADP Integrators, which grants them the right to use the company’s proprietary APIs.
Consolidated patient data APIs: combining data from EHRs, labs, wearables, and more
Data exposed: USCDI and non-USCDI data on patients, collected from various sources
What to build with them: health and wellness apps, disease and medication management tools, telemedicine platforms.
Read the main article Health Data APIs
Representatives of this FHIR-based API family are vendor-neutral, meaning that they extract patient data from a wide range of sources, including EHR systems and wearables. Here are three examples of such consolidated patient data APIs.
FHIR elements accessible via different APIs.
Apple Health Records API
Health Records API by Apple integrates with over 500 health systems and consolidates data into a single document to be displayed on iOS devices. It uses the OAuth 2.0 protocol for authentication and periodically pulls new records from a patient’s EHR, notifying the user of updates.
The data in transit is encrypted and doesn’t pass through Apple’s network. When at rest, the content is protected with the patient’s iPhone passcode, Touch ID, or Face ID.
Human APIs
Human Clinical API connects to labs, EHR systems, pharmacies, and patient portals across the US, reaching over 264 million patients. A separate Wearable API extracts data from nearly 300 health devices. Together, they ingest information from more than 40,000 sources and transform it into FHIR-compatible format with the help of AI algorithms.
Particle Health API
Particle Health API offers access to over 300 million patient records from most EHR systems via a single entry point. It also comes pre-integrated with most pharmacies and labs in the US. A standalone Data Transformation API converts legacy clinical datasets into FHIR files by extracting USCDI elements.
Clinical data management APIs: using the power of Amazon, Google, and Microsoft analytics
Features exposed: NLP engines and machine learning algorithms to derive insights from unstructured medical documents
What to build with them: health analytics solutions, clinical decision support systems, tools for precision medicine.
Read the main article Health Data APIs
Tech giants like Amazon, Google, and Microsoft also strive to expand their footprint in digital healthcare by launching powerful APIs to ingest and analyze medical data in different formats.
Amazon Comprehend Medical APIs
Amazon Comprehend Medical APIs connect to an NLP engine that automatically extracts meaningful components from various types of clinical documents — say, EHRs, doctor’s notes, or trial reports. These components are then linked to corresponding entities from medical coding systems. Besides that, Amazon APIs provide services to recognize and delete protected health information (PHI).
Google Cloud Healthcare API
Cloud Healthcare API by Google supports all major healthcare standards and allows for a wide range of operations with data. This includes
- importing data from various sources, from EHRs to wearables;
- transforming data into FHIR format;
- removing PHI;
- storing, managing, and analyzing files in the DICOM (Digital Imaging and Communication in Medicine) format;
- consolidating data in various formats into a single document;
- and more.
Similar to Amazon, Google offers Natural Language Processing capabilities via a standalone NLP API.
Microsoft Azure API for FHIR
Microsoft Azure API for FHIR helps health systems move their legacy documents stored in disparate repositories to cloud storage. It takes care of protected health information and normalizes medical data using the FHIR standard. Also, Microsoft has a special IoT connector to ingest biometrics from medical devices, analyze it, and build IoMT systems.
Public health content APIs: getting surveys and statistics from WHO, HHS, FDA, and others
Data exposed: evidence-based content about diseases, health risks, and ways to stay healthy
What to build with them: website, portals and extensions to educate both patients and doctors, patient engagement solutions.
Read the main article Health Data APIs
Public health information APIs deal with recommendations, statistics, surveys, and other valuable data, systematically reviewed by medical specialists.
ODPHP MyHealthfinder Content API
MyHealthfinder Content API can be easily integrated with a hospital website to provide patients with health tips, based on age, sex, and habits. Recommendations supervised by the Office of Disease Prevention and Health Promotion (ODPHP) are reviewed at least once every two years. The API works with JSON and XML files.
WHO data API
Athena API is built by the World Health Organization to integrate third-party apps with the global data portal — the Global Health Observatory (GHO.) It collects statistics by country, covering a wide range of topics, from child nutrition to immunization to particular diseases. By default, the API retrieves data in XML format, but also has basic support for JSON.
HHS Content Syndication APIs
Content Syndication APIs by the US Department of Health and Human Services (HHS) consolidate news, articles, surveys, and other content from HHS partners — such as the US Food and Drug Administration (FDA) or National Cancer Institute (NCI). The data is returned in JSON and XML formats to be displayed on websites, social media pages, mobile apps, etc.
Free drug data, medicine database, and interaction checker APIs: getting trustworthy information on medications
Data exposed: detailed information on drugs, their side effects, and drug interactions
What to build with them: pharmacy management systems, e-prescribing and clinical decision support modules for EHR systems, computerized physician order entry (CPOE) systems, patient portals, prescription adherence apps.
Read the main articles Medicine and Drug Data APIs and Drug Interaction Checker APIs
Where is drug data accumulated and how trustworthy is it? To answer these questions, we must trace the journey of medicine information, from pharma manufacturers to medical professionals, general consumers, and health systems.
Registration. A pharma manufacturer, repacker, or relabeler must register a new drug product with the US Food and Drug Administration (FDA.) For this, the pharma company submits registration and listing information in the Structured Product Labeling (SPL) format.
Getting an NDC. Based on the submission, the product is assigned a unique 10 or 11-digit National Drug Code (NDC). It consists of the labeler code, product code, and package code. FDA publishes all listed identifiers in the NDC directory, which is updated daily. But assignment of the NDC code doesn’t automatically mean that the drug is FDA-approved.
NDC format example. Source: NDC list
DailyMed publication. The FDA sends information on drugs marketed in the US to its official website, DailyMed, launched in 2005 by the National Library of Medicine (NLM.) Through DailyMed, trustworthy data on prescription medicines and their side effects become publicly available for health systems, physicians, and general users.
Connecting NDC codes with RxNorm names. Besides DailyMed, the NLM maintains and updates the RxNorm clinical drug vocabulary. In contrast to NDCs, an RxNorm concept unique identifier (RxCUI) is associated with drug ingredients, strengths, and dose forms. For example, cetirizine hydrochloride 5 MG Oral Tablet has a single RxCUI (1014676), but is linked to 25 NDC codes, corresponding to different labelers and package sizes.
Designed to facilitate interoperability, RxNorm is the standard of choice for data exchange between health systems.
So, it comes as no surprise that key drug data APIs are somehow related to one of the mentioned-above organizations and support SPL, NDC, and /or RxNorm standards.
All key federal players, involved in drug data standardization and promotion, have free public APIs aimed at boosting openness and educating consumers.
In turn, commercial tech providers work with a wide range of data sources, from mentioned-above public datasets to research databases and medical journals. Often, such services also offer drug interaction checking capabilities.
Drug interaction checking via APIs.
openFDA APIs
openFDA APIs is an open-source platform that gives access to data on drugs for both animals and humans, medical devices, foods, tobacco, and more. As for human medications, the platform covers
- reports on adverse events and medical errors;
- SPL-formatted drug labels;
- NDC numbers with the related information on drugs marketed in the US; and
- data on drug recalls, or events when certain medications are removed from the market.
All APIs return responses in JSON format. It’s worth noting that not all information provided by openFDA APIs is validated for clinical or production use.
DailyMed RESTful API
The DailyMed RESTful API retrieves SPL information, including
- NDC codes,
- product-level RxCUI codes,
- code packaging descriptions,
- drug names, and
- drug classes.
The service supports both XML and JSON formats.
RxNorm APIs
RxNorm APIs extract information in JSON and XML formats from publicly available sources by the US National Library of Medicine (NLM), National Institutes of Health (NIH), and Department of Health and Human Services. Besides the current RxNorm vocabulary, the platform links to drug-drug interactions datasets.
DrugBank APIs
DrugBank, a pharmaceutical knowledge base, markets a suite of standalone integration-ready APIs supporting JSON, XML, and SQL format. The solution allows for searching over 100,000 drugs by NDC numbers, RxNorm codes, and other identifiers. Its drug-drug interaction database lists over 1,4 million interactions and is updated daily.
First DataBank Cloud Connector API
First DataBank (FDB) maintains the widely used drug database called MedKnowledge. It contains
- drug images,
- dosing and ordering data,
- pricing information,
- drug-drug, drug-food, and drug-allergy interactions, and
- other details.
Third-party developers can connect the database to existing health systems using FDB Cloud Connector API
IBM Micromedex APIs
IBM Micromedex is one of the largest online databases for drug information. It offers two JSON-based API options for different target groups. Summary Drug API enables nurses, insurance companies, and patients to get answers to general questions on medications. In-Depth Drug API is meant for medical professionals who require detailed information on complex care.
Symptom checker APIs: improving diagnostics and triage workflow
Data exposed: likely conditions, care recommendations
What to build with them: pre-diagnostic decision support tools, triage solutions for call centers and emergency department care, health chatbots, and self-diagnostic patient apps.
Read the main article Symptom Checker APIs
The goal of this module is to inform patients about possible causes of their conditions and help doctors make better decisions at the pre-diagnosis stage.
How symptom checker APIs work.
A typical symptom checker combines
- a knowledge base with data on diseases and treatment procedures, and
- a diagnostic engine that generates a list of likely conditions and recommendations based on patient input.
Below are several examples of advanced symptom checker APIs.
Infermedica API
Infermedica API features an AI-powered diagnostic engine with NLP capabilities to capture symptoms and risk factors in patient messages. Its knowledge base covers 1,500 symptoms and 800 conditions. The declared accuracy of the solution is 93 percent. The API doesn’t ask for personal information to preserve compliance with HIPAA.
Mayo Clinic API
The Mayo Clinic symptom triage API also uses AI algorithms to connect data from the knowledge base with real-time patient inputs. It identifies over 300 common symptoms and returns actionable guidance to save unnecessary care costs. The API supports JSON and XML formats.
Isabel Healthcare API
The Isabel Symptom Checker API covers over 10,000 diseases and promises 96-percent accuracy. In response, it consolidates a list of likely diagnoses, with an account of a patient’s age, gender, and even place of residence. The module comes pre-integrated with many popular EHR systems including Cerner and Epic. It supports XML and JSON formats.
Telehealth APIs: embedding remote care capabilities
Features and data exposed: operations with medical documents, appointment management, patient records, secure video visits.
What to build with them: telemedicine systems, scheduling tools, doctor and patient apps for remote care.
Read the main article: Telehealth APIs
Telehealth and telemedicine are two terms often used interchangeably when speaking of remote care services. This includes but is not limited to patient data exchange, remote visits, appointment scheduling, and lab test ordering. Let’s look at some APIs designed with telehealth in mind.
APIs for telehealth software.
DrChrono API
DrChrono API enables developers to build custom solutions on top of DrChrono, the first EHR system with telehealth functionality for iPad and iPhone. Apps created with the API let their users schedule appointments, exchange data elements from patients medical records, and manage medical documents.
Health Gorilla FHIR-based APIs
Health Gorilla FHIR-based API suite connects to nearly 65,000 healthcare facilities across the US to extract medical documents. Its NLP engine derives meaningful components from texts and image files. The platform also allows for submitting electronic test orders and getting results from over 100 labs. A separate FHIR Store API is designed for managing data in FHIR format.
Bluestream API
Bluestream API is designed for hospitals, seeking ways to quickly embed virtual care in their workflow. Among features provided are HIPAA-compliant video visits, scheduling of virtual appointments, and real-time activity tracking. The integration takes two to four weeks depending on the number of services a hospital wants to use.
Deadlines and pandemic accelerate API adoption
Currently, healthcare still lags behind other industries in API usage. Among key obstacles experts cite
- a lack of bidirectional data exchange. For now, patients have read-only access to their health records and can’t make any changes via FHIR APIs;
- confusion around the process of API implementation;
- hidden costs related to using web services via APIs; and
- vulnerability to cyber attacks.
Finance or travel APIs are commonly used by customers to access their personal data and change service providers in one click. When will healthcare see this level of API adoption? No one knows, but interoperability deadlines coming up in 2022 and challenges created by COVID-19 are obviously drawing this date closer.