Getting Started with FHIR APIs

Standard based interoperability is critical in today’s patient care ecosystem. This site describes Enabledoc (FHIR Fast Healthcare Interoperability Resources) APIs that enable customers and third party developers to develop their own solutions that work with our platforms to provide patient and provider applications with secure access to patient Protected Health Information (PHI). Third party developers are encouraged to open a developer account and register their applications to use our applications to request access to a practice's patient PHI. Applications can use Oauth and FHIR to let patients access their own individual patient PHI via their secure portal login. Enrolled apps must be approved by the administrator of an organization, so that patients can be shared with the app developer. Public Oauth access is granted to patients without enrolling an app. FHIR version R4 is certified to the ONC’s Final Rule (g)(10) criterion.


Types of Apps

Enabledoc FHIR API uses the SMART App Launch Framework and SMART Backend Service to connect third-party applications to Enablemypractice data, allowing apps to launch from inside or outside the user interface of our system. The framework supports apps for use by medical providers, clinical staff, patients, and other medical professionals via our Enablemyhealth patient and wellness platform. Our Enablemyhealth platforms operates Microsoft Identity Framework for Oauth 2.0 and Open ID to provide a reliable, secure authorization protocol for all apps.There are two types of apps with four use cases we support:


  1. Front Facing Confidential and Public Apps:


  1. Backend Service: Pull data for one, multiple or all patients


App Developer Guidelines and Responsibilities

App developers are responsible for signing business associate agreements with healthcare organizations, maintaining security to protect Patient Healthcare Information, maintain HIPAA compliance, understand FHIR and SMART design framework, and be familiar with healthcare practice principles and workflow.


All apps that use our technology and interact with our software to comply with our Terms of Use.  You and your apps should follow these guidelines:  



Developer Accounts and App Enrollment

3rd party application developers, customers and other EHRs must create a Developer Account to access our Oauth 2.0 (see authentication) and FHIR APIs for provider facing applications. Click Register above to create your account. Here is the process to create an account:

  1. Click Register.
  2. Enter an ID
  3. Enter password. A password must be a minimum of 8 characters with at least one number, one upper case letter, one lowercase letter and a special character.
  4. Confirm the password
  5. Enter a Name,  email, telephone, and Company name
  6. Click Submit.
  7. Click Create App.
  8. Select Front Facing or Backend. Front Facing is for patients or providers to use Oauth to authenticate for access to patient data. Backend requires an organization administrator to approve, grant permissions and share patients with a developer. Click Continue.
  9. Enter an App Name and Description, select Patient or Provider app, and check that you agree to Terms and Conditions. Click Continue.
  10. Select the Scope of access and click Continue.
  11. Enter the group or hospital ID provided by the Administrator of that organization and click Send Request for approval.
  12. The Organization Administrator will receive a text and email notification asking them to approve or decline access.
  13. Administrator logs into the portal and goes to the FHIR Approval Screen under Administration.
  14. Admin clicks on App Name to review the app information and scope.
  15. Admin approves or rejects the app, which sends a text and email notification to the developer and generates a JWT token with ID and secret.
  16. Admin click Share to select patients to share with the developers app token.
  17. The Developer uses the JWT token to authenticate their app.




Enabledoc’s FHIR REST based API based on HL7 specifications R4 in both XML and JSON format. The official FHIR HL7 R4 Standards Can Be Found Here


The following is a list of our available functions.



Retrieve Patient Demographic information based on USCDI verison 1. The search interaction enables the client to query for patients based on a specified set of demographics information. The Patient Search endpoint allows clients to establish an identifier for a patient without previously receiving unique identification from the server for the patient.



Encounter is defined as an incident of care for ambulatory environments and bundle or group of encounters for in patient care.



Retrieve data about an organization or provider. The Practitioner resource supplements many of the resources within FHIR by providing information about a primary care provider, prescriber, or the clinician ordering a lab or diagnostic test for a patient.



Provenance resource tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing those entities and agents involved in that episode of care. This information can be used to form opinions and further investigations about the quality and trustworthiness of the clinical information.  



This will allow you to retrieve all prescribed and administered medications for a patient.



Medications Request returns all medications related to a patient. It can return various types of medications, including inpatient-ordered medications, clinic-administered medications, patient-reported medications, and reconciled medications from external sources as well as patient-reported medications. This is commonly called the Current Medications list.



This will allow you to retrieve known allergies for a patient.



The Condition retrieves a patient’s problems, diagnoses, or other health concerns during the encounter or visit.The condition could be a point in time diagnosis in context of an encounter, it could be an item on the practitioner's Problem List, or it could be a concern that doesn't exist on the practitioner's Problem List.



This will allow you to retrieve vitals, pediatric vital percentiles, BMI,  Lab Result values, and Social History (smoking status) for a patient.


Diagnostic Report

Retrieves files and reports for request diagnostic report, atomic results, and images.



DocumentReference is used to categorize the type of clinical note or documentation.


Immunization Records

This will allow you to retrieve Immunization records for a patient.



This will allow you to retrieve procedures, lab and diagnostic orders for a patient.


Implanted Devices

This will allow you to retrieve a list of implanted devices installed in the patient.


Binary: CDA Document Retrieval

This will allow you to retrieve a CDA clinical summary document (C-CDA) for a patient.


Care Plan

Retrieve a patient’s longitudinal Care Plan health concerns and goals, care team, and plan of treatment with assessments.



Retrieve a patient’s intended health objectives, status, and due date.


Care Team

The CareTeam includes all the people, teams, and organizations who participate in the coordination and delivery of care for a patient. Caregivers, such as family members, guardians, and others, maybe part of the CareTeam.


Bulk Data Export

The FHIR Bulk Export Service is designed to comply with the ONC bulk data export requirements. This feature uses the FHIR API functions certified under the ONC CEHRT (g)(10) criterion. The FHIR Bulk Export service enables API developers to make asynchronous requests to export USCDI (United States Core Data for Interoperability) clinical data for shared patients by the approved group. With FHIR Bulk Export, you can retrieve data for multiple patients at a time. Our FHIR APIs are secured using OAuth scopes, which is requested in Developer Account via an approve application process.