Swagger UIswagger

DataLink FHIR API Documentation
 v1 

[ Base URL: https://dl-sb-firely.azurewebsites.net/ ]

Fast Healthcare Interoperability Resources (FHIR, pronounced “Fire”) defines a set of “Resources” that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. Technically, FHIR is designed for the web; the resources are based on simple XML or JSON structures, with an http-based RESTful protocol where each resource has predictable URL. Where possible, open internet standards are used for data representation.

https://dl-sb-firely.azurewebsites.net

Service Base URL

Client Application Requirements

  • Support for HL7 FHIR 4.0.1
  • US Core 4.0
  • Smart App Launch 1.0.0
  • Bulk Data Version 1.0.1

SMART on FHIR applications will need to be registered by DataLink before they can be used. To start the registration process, please email supportticket@datalinksoftware.com with the subject titled "FHIR API Client Registration". Include in the email, the name of your application, contact information, and a short description of the application.

DataLink will review your request and if you are approved you will receive an OAuth client_id to use on subsequent requests following the protocols specified in the official SMART App Authorization Guide. DataLink APIs are authenticated using the OAuth 2.0 protocol. All API requests must include an Authorization header with an Access Token of the form: Authorization: Bearer MY_JWT_TOKEN

Terms and Conditions

Relied Upon Software: Firely
Firely Terms & Conditions: Terms - SIMPLIFIER.NET

Confidential clients, such as web apps, which are capable of securely storing credentials will be issued a client_secret that may be used in conjunction with the client_id to form an authorization grant, which can be used to obtain refresh and access tokens. Our refresh tokens are long-lived and conform to Health IT criteria documented here.

Public applications, such as native apps, which are incapable of securely storing credentials will not be issued a client_secret. Instead, the authorization_code grant flow will be used to issue refresh tokens. As recommended in the OAuth 2.0 Authorization Framework spec, we require additional security measures when issuing refresh tokens to native applications. Specifically, we enforce refresh token rotation for all public applications, which is an auth flow in which each refresh token issued is valid for one use only. Whenever a public application uses a refresh token to request an access token, a new refresh token will be returned in the response body in addition to the requested access token.

May require an annual cost for FHIR API capabilities utilizing Firely’s FHIR & Authentication servers to interact with SMART on FHIR applications. Please contact DataLink for specific pricing details.

No other restrictions, limitations, obligations or cost.