Documentation

  • API Version: 2.0
  • Product: StreamlineMD
  • Last Revised: September 23, 2022

Terms of Use

Documentation of API portal and materials including support of the FHIR® Specification (referred to as the “Materials”) have been made available to developers for development and testing. The Materials are provided to developers as-is with no other warranties expressed or implied. Developers may use the Materials with adherence to the below terms and conditions:

  1. StreamlineMD FHIRAPI portal has the most up-to-date documentation. Developers may keep copies of the Materials; however, they may not be distributed.
  2. Developers own developments using the Materials. StreamlineMD owns the Materials, as well as any improvements to or derivatives of the Materials, such as enhancements to the testing tools or documentation. A dynamic developer environment is encouraged. Any suggested improvements of the Materials may become part of the Materials without any obligation or notice to the submitter.
  3. Developers are responsible for the products developed and how the products connect to the community members’ software. Developers are also responsible for complying with all applicable laws, including not infringing on StreamlineMD’s or others’ intellectual property rights.
  4. Developers interested in advertising products using StreamlineMD EHR FHIRAPI, StreamlineMD's name, or StreamlineMD's logo, please contact helpdesk@streamlinemd.com to obtain permission.

Introduction

Integration with the SMART App Launch Framework via FHIR allows a third-party application to connect with Provider(s) using the StreamlineMD EHR and retrieve Electronic Health Record data from those Providers. These applications can be launched from inside or outside the user interface of StreamlineMD EHR. The framework supports Apps that can be used by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system where a user can give permissions to launch an App. StreamlineMD EHR has built this API using the HL7 FHIR standards.

This documentation is intended for use by third-party application developers which will describe registration, syntax, functionality and errors/exceptions they will see when using the StreamlineMD FHIR API to integrate with provider(s)/ practices using the StreamlineMD EHR.





FHIR R4 Base URLs

Download List of FHIR R4 Base URLs

Click here to download a machine-readable CSV file of all StreamlineMD and non-StreamlineMD FHIR R4 base URLs certified to the ONC’s Cures Act Final Rule (g)(10) criterion, along with the patient-facing names of associated healthcare organizations.





SVAP (Standards Version Advancement Process)

Content: StreamlineMD EHR uses SVAP for ONC g(10) FHIR API. StreamlineMD EHR uses SVAP US CORE V 4.0.0.


Registration

Developers wishing to integrate with the StreamlineMD FHIR API must complete the registration process. Once the request is approved the developer will be able to consume the StreamlineMD FHIR API. Depending on the access type the Client ID and/ or Client Secret shall be provided.

During setup, developers will be required to provide the Practice Administrator with the following information about their App needs:

  1. “Confidential App” vs. “Public App”
    • The Practice Administrator will set the developer application as a “Confidential App” if the app is able to protect a client_secret.
    • The Practice Administrator will set the developer application as a “Public App” if the app is unable to protect a client_secret.
  2. Developers will be required to provide the Practice Administrator with a “redirect_uri”. This is a security measure used to make sure that the API only sends responses back to the verified redirect URI of the developer.

Finally, developers can request/provide the following information to the Practice Administrator during App setup:

  1. EHR Launch Access: Developers can request “Launch” access by providing a Launch URI to the Practice Administrator during registration. See the “Launch Sequence” section for more information about the EHR Launch sequence.
  2. Bulk Export Access: Developers can request “Export” access by providing JWK Set URL with at least one valid JWK in the RS384 format. See the “Bulk Export” section for more information about Bulk Exporting.

Configurations

A third-party developer App needs to meet the following configuration requirements:

  1. The App must read and parse JSON responses.
  2. The App must assure that sensitive information (authentication secrets, authorization codes, tokens) are transmitted ONLY to authenticated servers, over TLS-secured channels. §170.315(g)(10) requires secure connection using TLS version 1.2 or higher.
  3. If the App is a Bulk Export application, the application may need to be setup to handle longer lasting connections based on the data that are being exported.
  4. The App must send requests over HTTPS.

Launch Sequence

Depending on how your developer account has been setup will change how you communicate with the API to obtain authorization tokens and subsequently access to the StreamlineMD FHIR Resources.

Before the developer can obtain an authorization token, they will need some context of where to retrieve the tokens (such as token endpoints, authorization endpoints, etc.)

Below are the ways in which your Application can handle initial “kickoff” requests BEFORE authorization tokens are granted:

EHR Launch

In an EHR Launch, a user establishes an EHR session and then decides to launch your App from within the EHR (such as a dashboard, single-patient app, scheduler, appointment manager, etc.) The EHR will initiate the “Launch Sequence” by opening a new browser instance (or perhaps an iframe) and point to your App’s registered Launch URI with some additional context.

Below are the “context” parameters included in a Launch request to your application:

Launch Parameters

iss required Identifies the EHR's FHIR endpoint, which your App can use to obtain additional details about the EHR, including its authorization URL, token endpoints, etc.
launch required Opaque identifier for the specific launch. Your App will be required to communicate this value back to the EHR once you are ready to send an authorization request. This will be used to validate the correctness of a valid Launch Authorization request..

An example “Launch Request” that your App can expect to see may look something like this:

https://YourLaunchURI?iss=FHIR_ENDPOINT&launch=SampleLaunch

On receiving the launch notification, your App would call the issuer’s (iss) “.well-known/smart-configuration” endpoint which contains the OAuth authorization and token endpoint URLs to use when requesting authorization to access FHIR resources.

An example “Call” that your App would make after getting the “iss” (where “FHIR_ENDPOINT” is the “iss” from the launch sequence):

https://FHIR_ENDPOINT/.well-known/smart-configuration

Later, when your App prepares a list of access scopes you want to request from the EHR authorization server, it will be associated with the existing EHR context by including the launch notification in the scope.

Standalone Launch

In the Standalone Launch, a user selects your App from outside the EHR (such as tapping an App icon on mobile devices, or maybe even from another application). Your App will launch from its own URL without Launch Context (such as in the EHR Launch sequence).

Once your App has been launched, in order to obtain further context and request authorization to access FHIR resources, your App will need to discover the EHR’s OAuth authorize and token endpoint URLs by querying the “.well-known/smart-configuration” endpoint.

An example “Call” that your App would make:

https://FHIR_ENDPOINT/.well-known/smart-configuration

Finally, your App can declare its own launch context requirements by adding specific scopes to the request it sends to the EHR’s authorization server. The authorize endpoint will run checks based on what the App was registered for and ensure your App correctly follows the authorization process.


Authorization and FHIR Access

Below are the steps for authorization/FHIR Access.

Authorization Request

Your App will construct a request for authorization by adding the following parameters to the query component of the EHR’s “authorize” endpoint URL:

Parameters

response_type required Fixed value: code.
client_id required This is the Client ID you received at registration.
redirect_uri required This is your Redirect URI you gave at registration.
launch optional This will be the value you received from the EHR “launch” parameter.

Note: This is ONLY used for EHR Launch authorization requests.

scope required Each scope will follow the syntax of “[patient | user]/[resource].read” where [resource] is the name of the Resource, or the “*” resource (indicates you wish to have access to ALL Resources). Examples are “patient/Observation.read”, “user/Patient.read”, “patient/*.read”, etc.

Additionally, you MUST include either the “launch” scope if you are performing an EHR Launch or the “launch/patient” scope for Standalone launches.

state required An unpredictable, opaque value that your App will generate to maintain state between the request and callback. The authorization server includes this value when redirecting back to your App.
aud required URL of the EHR resource server. This parameter prevents leaking a genuine bearer token to a counterfeit resource server.

In the case of an EHR Launch, this value is the same as the “iss” value received during the Launch sequence.

An example of an authorization request for an EHR Launch may look something like this (query parameters are separated line by line for clarity):

https://FHIR_AUTHORIZE_ENDPOINT? response_type=code& client_id=YourClientID& redirect_uri=https://YourRedirectURI& launch=EHR_LAUNCH_VALUE& scope=launch+patient/Observation.read+patient/Patient.read+openid+fhirUser& state=randomvalue& aud=https://FHIR_ENDPOINT

Once an authorization request is sent to the server, a decision is made by the server on the authenticity of the request (which may additionally request authorization from the end-user). In the context of the FHIR API, this typically means that a user of your App will need to sign-in. Users will need to have their accounts created by the Provider, who controls which Clients/Patients that each User is allowed to see and the scopes of which resources that User is allowed to access.

The EHR will decide whether to grant or deny access. This decision is communicated to your App when the EHR authorization server returns an authorization code (or, if denying access, an error response).

Authorization codes are short-lived and will expire within one minute.

The code will be sent to the “redirect_uri” of your App and includes the following parameters:

Parameters

code required The authorization code generated by the authorization server which will expire within 1 minute.
state required This is the state value that your App generated before sending the authorization request. If you receive a response that includes an incorrect state parameter, do not trust the response.

An example response from the authorization server may look something like this (query parameters are separated line by line for clarity):

https://YourRedirectURI? code=codegeneratedbyFHIRServer& state=randomvalue

Here is the list of error codes for the Authorization endpoint:

Errors

400 invalid_request The request was not formatted correctly or a parameter was missing.
This may be caused by an invalid or missing “aud”, “client_id”, “redirect_uri”, “response_type”, “scope” or “state” parameter in the authorization request.
This may be caused by an invalid or missing parameter during each stage of the “Login”, “Pick Client” and “Pick Scopes” pages.
This may be caused if a request is made for an authorization code using a user who is requesting access to a client/patient they do not have the rights to see.
state The server is unresponsive or unable to handle your request.

Exchange Code for Access Token

After obtaining an authorization code, your App will trade the code for an access token via a HTTP POST to the EHR authorization server’s token endpoint URL, using content-type “application/x-www-form-urlencoded”.

For a Public App, authentication is not possible, since an App with no secret cannot prove its identity when it issues a call.

For a Confidential App, an Authorization header using HTTP Basic authentication is required, where the username is the App’s “client_id” and the password is the App’s “client_secret”. As an example, if the “client_id” is ‘myclient’ and the “client_secret” is ‘myclientsecret’, then the header uses the value B64Encode(“myclient:myclientsecret”), which converts to bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=.

This gives the request the Authorization header for “Basic Auth” which looks like:

Authorization: Basic bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=

The actual request will be sent using these parameters:

Parameters

grant_type required Fixed value: authorization_code
code required The code that your App received from the authorization server.
redirect_uri required Your App’s registered redirect_uri.
client_id conditional Required for “public apps”. Omit for “confidential apps”.

An example of this request may look something like this:

Authorization: Basic bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=POST /connect/token HTTP/1.1
Host: FHIR_ENDPOINT
Authorization: Basic bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=
Content-Type: application/x-www-form-urlencoded grant-type=authorization_code& code=codegeneratedbyFHIRServer& redirect_uri= https://YourRedirectURI
Note: For Public client, you will not pass an Authorization header. Instead you will be required to pass your client_id as a separate URL parameter.

The EHR authorization server SHALL return a JSON object that includes an access token or a message indicating that the authorization request has been denied.

The JSON structure for a successful response includes the following parameters:

Parameters

access_token required The access token issued by the authorization server.
token_type required Fixed value: Bearer
expires_in required Lifetime in seconds of the access token, after which the token SHALL NOT be accepted by the resource server.
scope required Scope of access authorized. This list may be different than what was initially requested by the App depending on the exchange between the code and the access token grant. Additionally, there may be permission conflicts which may deny access to scopes versus what was initially requested.
id_token optional Authenticated patient identity and user details, if requested in the scopes of the code exchange (open_id and fhirUser scopes must both be requested in order to an id_token to be issued).
refresh_token required Token that can be used to obtain a new access token, using the same or a subset of the original authorization grants.
patient required This represents the Client/Patient that was chosen during the authorization process.
need_patient_banner required This will always be “false”. We do not support patient banners.
smart_style_url required This is a URL to the server’s smart_style. Your app may use these colors to design your App to StreamlineMD's color scheme.

An example response from the code exchange may look something like this:

{
“id_token”: “eyJhbGciOiJSUzI1NiIsImtpZCI6IkQ2RTAwNkQ2M0VGRkVFNkUyNUM5QkM4NkREMzY0QTI5IiwidHlwIjoiSldUIn0”
“access_token”: “C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83”,
“expires_in”: 3600,
“token_type”: “bearer”,
“refresh_token”: “0DD523D3870B61A7284ADAC313831FA4E440797AF6579FEA7B092F9F306C1130”,
“scope”: “patient/Observation.read patient/Patient.read”,
“patient”: 463,
“smart_style_url”: “https://FHIR_SMARTSTYLE”, “need_patient_banner”: false,
}
Note: All access_token have an expiration date of 3 months from when the token was issued.

Here is the list of error codes for the code exchange:

Errors

400 invalid_request The request was not formatted correctly or a parameter was missing.
This may be caused by an invalid or missing “grant_type”, “code” or “redirect_uri” parameter in the request.
May be caused by passing an unrecognized/invalid “client_id”.
May be caused by passing an unrecognized/invalid “redirect_uri”.
400 access_denied The request was denied for a variety of reasons.
May be denied because the request found both an “Authorization” header and a “client_id” parameter. Requests must use one or the other, but not both.
May be denied because the “code” was expired or invalid.
May be denied because your App is setup as a Public/Confidential App, but you are using the incorrect format (ex: you are a Public App using an Authorization header).
500 The server is unresponsive or unable to handle your request.

Using Access Token for Resources

With a valid access token, your App can access protected EHR data by issuing a FHIR API call to one or more of the FHIR endpoint(s) on the EHR’s resource server.

The request includes an Authorization header that presents the access_token as a “Bearer” token (in a real request, {{access_token}} is the actual token you got from the code exchange):

Authorization: Bearer {{access_token}}

Let’s take a real example to the “Patient” resource using the access_token received in the previous section. We are going to be getting the info for Patient “463”:

GET https://FHIR_ENDPOINT/Patient/463
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

See the “Resources” section later in this document for more information on all the Resources, including which parameters to use when calling the Resource.

Here is a list of errors you may see when making a GET request to a Resource:

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
401 access_denied This may occur for a variety of reasons:
The Access Token was not a valid JWT or has an improper structure.
The Access Token does not contain the correct authorization scope to access the Resource.
The user that the Access Token was generated for does not have the correct permissions to see the Resource, regardless of the scopes contained in the Access Token.
500 The server is unresponsive or unable to handle your request.

Using Refresh Token for new Access Token

Refresh tokens are issued to enable sessions to last longer than the validity period of an access token. With a valid refresh token, your App can request a new access_token by “trading in” the refresh_token to the token endpoint of the EHR’s authorization server.

For a Public App, authentication is not possible, since an App with no secret cannot prove its identity when it issues a call.

For a Confidential App, an Authorization header using HTTP Basic authentication is required, where the username is the App’s “client_id” and the password is the App’s “client_secret”. As an example, if the “client_id” is ‘myclient’ and the “client_secret” is ‘myclientsecret’, then the header uses the value B64Encode(“myclient:myclientsecret”), which converts to bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=.

This gives the App the Authorization token for “Basic Auth” which looks like:

Authorization: Basic bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=

The actual request will be sent using these parameters:

Parameters

grant_type required Fixed value: refresh_token
refresh_token required The refresh token obtained from a successful authorization exchange.
scope optional Your App may optionally pass a list of scopes for the new token. Note that the list of scopes must be equal to or a subset of the scopes of the original access_token that you are using a refresh_token for.
If you choose not to include this parameter, the new access_token will automatically use all of the scopes of the original access_token.

An example of this request may look something like this:

POST /connect/token HTTP/1.1
Host: FHIR_ENDPOINT
Authorization: Basic bXljbGllbnQ6bXljbGllbnRzZWNyZXQ=
Content-Type: application/x-www-form-urlencoded grant-type=refresh_token& refresh_token=0DD523D3870B61A7284ADAC313831FA4E440797AF6579FEA7B092F9F306C1130

If the refresh_token exchange is successful, a JSON object SHALL be returned that includes an access token or a message indicating that the authorization request has been denied.

The JSON structure for a successful response includes the following parameters:

Parameters

access_token required The new access token issued by the authorization server. token_type
token_type required Fixed value: Bearer
expires_in required Lifetime in seconds of the access token, after which the token SHALL NOT be accepted by the resource server.
scope required Scope of access authorized. This list may be different than what was in the original access_token before the refresh, depending on the optional scopes that may have been passed during the refresh request.
id_token optional Authenticated patient identity and user details, if requested in the scopes (open_id and fhirUser scopes must both be requested in order to an id_token to be issued).
refresh_token required Token that can be used to obtain another new access token once this new access_token expires.
patient required This represents the Client/Patient that was extracted from the refresh_token.
need_patient_banner required This will always be “false”. We do not support patient banners.
smart_style_url required This is a URL to the server’s smart_style. Your app may use these colors to design your App to StreamlineMD's color scheme.

An example response from the code exchange may look something like this:

{
“id_token”: “eyJhbGciOiJSUzI1NiIsImtpZCI6IkQ2RTAwNkQ2M0VGRkVFNkUyNUM5QkM4NkREMzY0QTI5IiwidHlwIjoiSldUIn0”
“access_token”: “00FDF5F61B6A4B327302DA939C50FC24778242C84E4022EE2C05BDE6CA024FED”,
“expires_in”: 3600,
“token_type”: “bearer”,
“refresh_token”: “5F53B3C93B9749052FF0D35558EE8C59D581AE8C92385F632E83D97C8CA0F7FD”,
“scope”: “patient/Observation.read patient/Patient.read”,
“patient”: 463,
“smart_style_url”: “https://FHIR_ENDPOINT_SMARTSTYLE”,
“need_patient_banner”: false,
}
Note: All access_token have an expiration date of 3 months from when the token was issued.

Here is the list of error codes for the refresh_token exchange:

Errors

400 invalid_request The request was not formatted correctly or a parameter was missing.
This may be caused by an invalid or missing “grant_type” or “refresh_token” parameter in the request.
May be caused by passing an incorrect authorization header.
400 access_denied The request was denied for a variety of reasons.
May be denied because the “refresh_token” was expired or invalid.
May be denied because none of the scopes requested in the optional “scope” parameter could not be granted (this would generate an access_token with no scopes).
500 The server is unresponsive or unable to handle your request.

Bulk Export

App’s that want to export data from an EHR via the FHIR API will need to be registered, setup and have permissions applied to their account for exporting Resources using the Bulk Export process. It is up to the Provider to control which Resources that a particular developer/App will get to export. Providers will also be responsible for setting up “groups” of Clients that the App can use during export requests.

Note: In order to use the Bulk Export process, your App MUST be able to protect a private/secret key!
Your App also must register a JWK set with at least one JWK in the RS384 format, which includes an “n” and “e” value pair (modulus and exponent).

Obtaining Endpoint Information

Your App will need to discover the EHR’s OAuth Bulk Export authorize and token endpoint URLs by querying the “.well-known/smart-configuration” endpoint of the Bulk Server.

Authorization Request

Before your App can request an access token, it SHALL generate a one-time-use JSON Web Token (JWT) that will be used to authenticate your App with the Bulk Export FHIR server. The authentication JWT SHALL include the following claims, and SHALL be signed with your App’s RS384 private key:

Authentication JWT Header Values

alg required The algorithm (RS384) used for signing the authentication JWT.
kid required The identifier of the key-pair used to sign this JWT. This identifier SHALL be unique within your App’s JWK Set.
typ required Fixed value: JWT.
iss required Issuer of the JWT, which is the client_id , as determined during registration with the FHIR authorization server (note that this is the same as the value for the sub claim)
sub required Your client_id , as determined during registration with the FHIR authorization server (note that this is the same as the value for the iss claim)
aud required The Bulk Export FHIR authorization server's "token URL".
exp required Expiration time integer for this authentication JWT, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC). This time SHALL be no more than five minutes in the future.
jti required A nonce string value that uniquely identifies this authentication JWT.

After generating an authentication JWT, your App will request a new access token via HTTP POST to the Bulk Export FHIR authorization server’s token endpoint URL, using content-type application/x-www-form-urlencoded with the following parameters:

Parameters

scope required The scope of access requested. Each scope will follow the syntax of “system/[resource].read” where [resource] is the name of the Resource you want to export, or the “*” resource (indicates you wish to export ALL Resources).
grant_type required Fixed value: client_credentials
client_assertion_type required Fixed value: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion required Your generated and signed JWT using the RS384 format.

An example of an access token request for the Bulk Export may look something like this (query parameters are separated line by line for clarity):

https://BULKEXPORT_AUTHORIZATION? scope=system/*.read& grant_type=client_credentials& client_assertion_type= urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion=YourGeneratedJWT

Once an authorization request is sent to the server, a decision is made by the server on the authenticity of the request. The server will first validate that the client_assertion is a valid JWT, then parse the client_id from the token. Once parsed, the server will use the client_id and attempt to fetch the JWK Set URI that was set up at registration time to decode the JWT. The server will iterate over each RS384 JWK until it finds one that can successfully decode the JWT. If no JWK Set is found or none of the RS384 keys in the JWK Set work, the token will be rejected and an access token will NOT be granted.

If the exchange is successful and the JWT is validated, the server will response with a JSON object that looks like the following:

Bulk Export Access Token Response

access_token required The access token issued by the Bulk Export Authorization.
token_type required Fixed value: bearer.
expires_in required The lifetime in seconds of the access token. This will always be 300, for a five-minute token lifetime.
scope required Scope of access authorized by the server, which may be different from the scopes originally requested based on permissions.

An example response may look something like this:

{
“access_token”: “5392B2DA500B76BB10FE5ADB0BE0673F6C740491136DF2228C07C009938A6EBB”,
“token_type”: “bearer”,
“expires_in”: 3600,
“scope”: “system/*.read”
}

Here is a list of errors that may occur during the authorization/access token exchange:

Errors

400 invalid_request The request was not formatted correctly or a parameter was missing.
This may be caused by an invalid or missing “scope, “grant_type”, “client_assertion_type”, or “client_assertion” parameter in the request.
May be caused by using an incorrect ‘content_type’ during the token exchange.
400 invalid_scope The Bulk Export token exchange only accepts scopes that are formatted according to this syntax: system/[resource].read where the [resource] is the name of the Resource you wish to export or the “*” scope, which requests export access to ALL Resources (ex. system/*.read)
400 invalid_client The “client_id” that was found in the JWT token is invalid, non-existent or does not have the rights to Bulk Export.
The “client_id” may not have a JWK URL setup in their developer account.
A valid JWK Set Key could not be found for the “client_id” in the RS384 format after querying their JWK URL.
A valid JWK Set was found, but none of the key(s) could decode the JWT for “client_id”
405 invalid_method Requests must use HTTP POST to access the token exchange endpoint.
500 The server is unresponsive or unable to handle your request.

Starting the Export Process

With a valid access token, your App can start exporting protected EHR data by issuing a “Group Kickoff Request” with the correct export format.

All export requests will include an Authorization header that presents the access_token as a “Bearer” token (in a real request, {{access_token}} is the actual token you got from the code exchange):

Authorization: Bearer {{access_token}}

To start the export process, you will first need to issue a “Kickoff Request” for the Export:

GET https://FHIR_ENDPOINT/Group/19/$export
Authorization: Bearer 5392B2DA500B76BB10FE5ADB0BE0673F6C740491136DF2228C07C009938A6EBB

In the example above, the app would be requesting an export process for Group # 19. Groups are collections of Client/Patient records which the Provider can assign to your developer account. Once a Kickoff Request is started, each Client/Patient in the Group will be included in the export.

A successful “Kickoff Request” will return a HTTP 202 “Accepted” response with an OperationOutcome FHIR JSON response, which will look like the following:

{
“resourceType”: “OperationOutcome”,
“text”: {
“status”: “generated”
},
“issue”: [{
“severity”: “information”,
“code”: “processing”,
“diagnostics”: "Request accepted. Check status at: https://FHIR_ENDPOINT/CheckStatus?_jobid=t1N0ButfwMSv65PU8X0l"
}]
}

Each successful request will present a link in the diagnostics where you can go to check the status of the Export.

Here is a list of errors you may see when initiating a Kickoff Request:

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
400 OperationOutcome This is a FHIR generated response JSON object that indicates the severity, error and a diagnostic message to tell the developer what error/problem occurred.
400 invalid_client The “client_id” that was found in the JWT token is invalid, non-existent or does not have the rights to Bulk Export.
The “client_id” may not have a JWK URL setup in their developer account.
A valid JWK Set could not be found for the “client_id” in the RS384 format after querying their JWK URL.
A valid JWK Set was found, but none of the key(s) could decode the JWT for “client_id”
405 invalid_method Requests must use HTTP POST to access the token exchange endpoint.
500 The server is unresponsive or unable to handle your request.

Checking the Status of the Export Process

After initiating a successful Kickoff Request, the response will give you a link where you can go to check the status of the Export request.

In the example below, we are sending a GET request to check the status for Export "t1N0ButfwMSv65PU8X0l" (this will be replaced with the identifier of your unique Export request):

GET /CheckStatus?_jobid=t1N0ButfwMSv65PU8X0l HTTP/1.1
Host: FHIR_ENDPOINT
Authorization: Bearer 5392B2DA500B76BB10FE5ADB0BE0673F6C740491136DF2228C07C009938A6EBB

Note that the GET request SHALL contain the Access Token in the authorization header as a “Bearer” token.

Checking the status will return either a HTTP 202 “Accepted” response with an OperationOutcome FHIR JSON response (if the Export is still processing) or a HTTP 200 “OK” response with a JSON structure that will look similar to the example below:

                        
{
“transactionTime":"10/17/2022 05:56:30",
"request":"/Group/test/$export”,
“requiresAccessToken”:true,
“output:[
{
“type”:“Patient”,
“url”:“https://FHIR_ENDPOINT/$exportfilerequest/?_id=t1N0ButfwMSv65PU8X0l&filename=patient.ndjson”
},
{
“type”:“AllergyIntolerance”,
“url”:“https://FHIR_ENDPOINT/$exportfilerequest/?_id=t1N0ButfwMSv65PU8X0l&filename=allergyintolerance.ndjson”
},
…],
“error”:[],
}

In the example above:

  • transactionTime: This is the time when the Export process began.
  • request: This is the calling Kickoff Request URL that started the Export.
  • requiresAccessToken: This boolean indicates if you will be required to provide an access token for each NDJSON “bulkfiles” request. This will always be “true” to enforce security measures before obtaining the NDJSON of an Export.
  • output: This is an array of JSON objects, where each object declares the “type” of Resource that is being exported and a URL link to the NDJSON for that export. Each NDJSON link follows this syntax: [groupID]/[resource].ndjson
  • error: This array indicates and errors that occurred during the Export.

Here is a list of errors you may see when checking the status of an Export:

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
400 OperationOutcome This is a FHIR generated response JSON object that indicates the severity, error and a diagnostic message to tell the developer what error/problem occurred.
500 The server is unresponsive or unable to handle your request.

Deleting an Export Process

After initiating a successful Kickoff Request, the App may choose to delete the Export before it has been completed by sending an HTTP DELETE request to the bulkstatus link received from the initial Kickoff Request.

In the example below, we are sending a DELETE request for Export "N6tCp4IJF8WWEzaILmcB" (this will be replaced with the identifier of your unique Export request):

DELETE /CheckStatus?_jobid=N6tCp4IJF8WWEzaILmcB HTTP/1.1
Host: FHIR_ENDPOINT
Authorization: Bearer 5392B2DA500B76BB10FE5ADB0BE0673F6C740491136DF2228C07C009938A6EBB

Note that the DELETE request SHALL contain the Access Token in the authorization header as a “Bearer” token.

As an additional note, deleted Export processes CANNOT be recovered. You will need to re-issue a new Kickoff Request in order to start a new Export process (which may involve generating an entirely new Access Token).

Sending a successful DELETE request will return the following OperationOutcome FHIR JSON response:


{
“resourceType”: “OperationOutcome”,
“text”:
{
“status”: “generated”
},
“issue”: [
{
“severity”: “information”,
“code”: “processing”,
“diagnostics”: "Export request has been cancelled."
}]
}

Here is a list of errors you may see when deleting an Export:

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
400 OperationOutcome This is a FHIR generated response JSON object that indicates the severity, error and a diagnostic message to tell the developer what error/problem occurred.
500 The server is unresponsive or unable to handle your request.

Obtaining the NDJSON from an Export

Once an Export has been completed, you can use the status link of the Kickoff Request to obtain an array of JSON objects in the “output” field. This array of JSON objects will have their own “type” and “URL” to call to get the NDJSON.

All you need to do is make a GET request to the NDJSON link, with your Access Token in the authorization header as a Bearer token. This will return zero or more JSON objects that are separated by new-line delimiters. The JSON for each Client/Patient in the Export Group will be included in the response. The specifics on each particular Resource is described in more detail in the next section.

Here is a list of errors you may see when making a NDJSON GET request:

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
401 access_denied This may occur for a variety of reasons:
The Access Token was not a valid JWT or has an improper structure.
The Access Token does not contain the correct authorization scope to access the Resource.
The requesting application does not have the correct permissions to see the Resource, regardless of the scopes contained in the Access Token.
500 The server is unresponsive or unable to handle your request.

Resources

Below is an overview of each supported FHIR resource, including the parameter list that can be used in each Resource for various data needs. Note that Bulk Export requests will not call the Resource directly but rather receive each JSON response in a NDJSON structure.

Here is a list of errors you may see when making a GET request to a Resource (all Resource’s share a common set of errors):

Errors

401 invalid_grant Requests must use the “Bearer” Authorization header type.
401 access_denied This may occur for a variety of reasons:
The Access Token was not a valid JWT or has an improper structure.
The Access Token does not contain the correct authorization scope to access the Resource.
The requesting application does not have the correct permissions to see the Resource, regardless of the scopes contained in the Access Token.
500 The server is unresponsive or unable to handle your request.

Allergy Intolerance

For an example JSON response for Allergy Intolerance, please see the following: AllergyIntolerance.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/AllergyIntolerance?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/AllergyIntolerance/_search
content-type: application/x-www-form-urlencoded
Parameter: _id=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific AllergyIntolerance record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/AllergyIntolerance/[value] (by allergy id/unique id)
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/AllergyIntolerance?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/AllergyIntolerance?patient=463

Care Plan

For an example JSON response for Care Plan, please see the following: CarePlan.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/CarePlan?category=assess-plan&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/CarePlan/_search
content-type: application/x-www-form-urlencoded
Parameter: _id=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific CarePlan record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/CarePlan/[value] (by care plan id/unique id)
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/CarePlan?_revinclude=Provenance:target&category=assess-plan&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
category GET [base]/CarePlan?category=assess-plan
patient GET [base]/CarePlan?patient=463

Search Parameter Combination Summary:

Parameter Combination Example
patient+category GET [base]/CarePlan?patient=463&category=assess-plan

Care Team

For an example JSON response for CareTeam, please see the following: CareTeam.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/CareTeam?patient=[value]&status=active
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/CareTeam/_search
content-type: application/x-www-form-urlencoded
Parameter:patient=[value]&status=active
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific CareTeam record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/CareTeam/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/CareTeam?_revinclude=Provenance:target&patient=[value]&status=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
status GET [base]/CareTeam?status=active
patient GET [base]/CareTeam?patient=463

Search Parameter Combination Summary:

Parameter Combination Example
patient+status GET [base]/CareTeam?patient=463&status=active

Search Composite OR Summary:

Parameter Example
status GET [base]/CareTeam?status=active,inactive

Condition

For an example JSON response for Condition, please see the following: Condition.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Condition?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Condition/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Condition record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Condition/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Condition?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/Condition?patient=463

Device (Implantable Device)

For an example JSON response for Implantable Device, please see the following: Device.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Device?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Device/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Device record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Device/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Device?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/Device?patient=463

Diagnostic Report

This Resource covers Cardiology, Radiology, Pathology and Laboratory Result Reporting.

Profile Details:

For an example JSON response for a Cardiology Report, please see the following: Cardiology.

For an example JSON response for a Laboratory Report, please see the following: Laboratory.

1. Diagnostic Report for Laboratory Results

This resource is called like the following:

GET https://FHIR_ENDPOINT/DiagnosticReport?category=LAB&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/DiagnosticReport/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]&category=LAB
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific DiagnosticReport record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/DiagnosticReport/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/DiagnosticReport?_revinclude=Provenance:target&category=LAB&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

2. Diagnostic Report for reprot and note exchange

This resource is called like the following:

GET https://FHIR_ENDPOINT/DiagnosticReport?category=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/DiagnosticReport/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]&category=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific DiagnosticReport record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/DiagnosticReport/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/DiagnosticReport?_revinclude=Provenance:target&category=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
category (Radiology) GET [base]/DiagnosticReport?category=LP29684-5
category (Pathology) GET [base]/DiagnosticReport?category=LP29708-2
category (Cardiology) GET [base]/DiagnosticReport?category=LP7839-6
category (Laboratory Result) GET [base]/DiagnosticReport?category=LAB
patient GET [base]/DiagnosticReport?patient=463
code (Radiology) GET [base]/DiagnosticReport?code=LP29684-5
code (Pathology) GET [base]/DiagnosticReport?code=LP29708-2
code (Cardiology) GET [base]/DiagnosticReport?code=LP7839-6

Search Parameter Combination Summary:

Parameter Combination Example
patient+category+date GET [base]/DiagnosticReport?patient=463&category=LAB&date=2015-06-22T00:00:00.00%2B00:00
patient+code+date GET [base]/DiagnosticReport?patient=463&code=LP29684-5&date=2015-06-22T00:00:00.00%2B00:00
patient+code GET [base]/DiagnosticReport?patient=463&code=LP29684-5
patient+category GET [base]/DiagnosticReport?patient=463&category=LAB

Document Reference

This resource supports the 5 Common Clinical Notes.

Profile Details:

For an example JSON response, please see the following: DocumentReference.

This resource is called like the following:

GET https://FHIR_ENDPOINT/DocumentReference?patient=[value]&_id=[value]&category=[value]&type=[value]&date=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/DocumentReference?_id=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/DocumentReference?patient=[value]&category=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/DocumentReference?patient=[value]&type=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/DocumentReference?category=[value]&date=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/DocumentReference/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific DocumentReference record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/DocumentReference/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/DocumentReference?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
_id GET [base]/DocumentReference?_id=1
category (Discharge) GET [base]/DocumentReference?category=18842-5
category (Consult Note) GET [base]/DocumentReference?category=11488-4
category (History & Physical) GET [base]/DocumentReference?category=34117-2
category (Progress Note) GET [base]/DocumentReference?category=11506-3
category (Procedure Note)) GET [base]/DocumentReference?category=28570-0
patient GET [base]/DocumentReference?patient=463
type GET [base]/DocumentReference?type=11488-4
date GET [base]/DocumentReference?date=2015-06-22T00:00:00.00%2B00:00

Search Parameter Combination Summary:

Parameter Combination Example
patient+category+date GET [base]/DocumentReference?patient=463&category=11488-4&date=2015-06-22T00:00:00.00%2B00:00
patient+type GET [base]/DocumentReference?patient=463&type=11488-4
patient+category GET [base]/DocumentReference?patient=463&category=11488-4

Encounter

For an example JSON response for Encounter, please see the following: Encounter.

Profile Details:

You can retrieve a specific Encounter record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Encounter/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
_id GET [base]/Encounter?_id=1
patient GET [base]/Encounter?patient=463

Goal

For an example JSON response for Goal, please see the following: Goal.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Goal?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Goal/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Goal record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Goal/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Goal?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/Goal?patient=463

Immunization

For an example JSON response for Immunization, please see the following: Immunization.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Immunization?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Immunization/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Immunization record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Immunization/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Immunization?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/Immunization?patient=463

Location

For an example JSON response for Location, please see the following: Location.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Location
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Location record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Location/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Medication

For an example JSON response for Location, please see the following: Medication.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Medication
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Medication record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Medication/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource does not support any parameters and can only be called directly.

Medication Request

For an example JSON response for MedicationRequest, please see the following: MedicationRequest.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/MedicationRequest?intent=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/MedicationRequest?intent=[value]&patient=[value]&status=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/MedicationRequest/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]&intent=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific MedicationRequest record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/MedicationRequest/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_include” information with any request using the following:

GET https://FHIR_ENDPOINT/MedicationRequest?[parameter=value]&_include=MedicationRequest:medication
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/MedicationRequest?_revinclude=Provenance:target&intent=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
status GET [base]/MedicationRequest?status=active
intent GET [base]/MedicationRequest?intent=filler-order
patient GET [base]/MedicationRequest?patient=463

Search Parameter Combination Summary:

Parameter Combination Example
patient+intent+status GET [base]/MedicationRequest?patient=463&intent=filler-order&status=active

Search Composite OR Summary:

Parameter Example
status GET [base]/MedicationRequest?status=active,stopped
intent GET [base]/MedicationRequest?intent=filler-order,instance-order

Observation

This Resource covers Laboratory Result,Blood Pressure,BMI Tests,Head Circumference ,Body Height,Body Weight,Body Temperature,Heart Rate,Prediatric BMI for Age,Pediatric Head Occipital-frontal Circumference Percentile,Pediatric Weight for Height,Pulse Oximetry,Respiratory Rate,Smoking Status.

For an example JSON response for Smoking Status, please see the following: Smoking Status.

For an example JSON response for Pediatric Weight for Height, please see the following: Pediatric Weight for Height.

For an example JSON response for Laboratory Result, please see the following: Laboratory Result.

For an example JSON response for Pediatric BMI for Age, please see the following: Pediatric BMI for Age.

For an example JSON response for Pulse Oximetry, please see the following: Pulse Oximetry.

For an example JSON response for Pediatric Head Occipital-frontal Percentile please see the following: Pediatric Head Occipital-frontal Percentile.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Observation?category=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Observation?code=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Observation record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Observation/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Observation/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]&category=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
POST https://FHIR_ENDPOINT/Observation/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]&code=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Observation?_revinclude=Provenance:target&category=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Observation?_revinclude=Provenance:target&code=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
category (laboratory) GET [base]/Observation?category=laboratory
category (vital-signs) GET [base]/Observation?category=vital-signs
patient GET [base]/Observation?patient=463
code (Smoking Status) GET [base]/Observation?code=72116-2
code (Weight for Height) GET [base]/Observation?code=77606-2
code (BMI) GET [base]/Observation?code=39156-5
code (Pediatric BMI for Age) GET [base]/Observation?code=59576-9
code (Pulse Oximetry) GET [base]/Observation?code=2708-6
code (Pulse Oximetry) GET [base]/Observation?code=59408-5
code (Body Height) GET [base]/Observation?code=8302-2
code (Temperature) GET [base]/Observation?code=8310-5
code (Blood Pressure) GET [base]/Observation?code=85354-9
code (Body Weight) GET [base]/Observation?code=29463-7
code (Head Occipital) GET [base]/Observation?code=8289-1
code (Head Circumference) GET [base]/Observation?code=9843-4
code (Heart Rate) GET [base]/Observation?code=8867-4
code (Respiratory Rate) GET [base]/Observation?code=9279-1
date (Respiratory Rate) GET [base]/Observation?date=2015-06-22T00:00:00.00%2B00:00

Search Parameter Combination Summary:

Parameter Combination Example
patient+category+date GET [base] /Observation?patient=463&category =laboratory&date =2015-06-22T00:00:00.00%2B00:00
patient+code+date GET [base]/Observation?patient=463&code=8867-4&date=2015-06-22T00:00:00.00%2B00:00
patient+code GET [base]/Observation?patient=463&code=8867-4
patient+category GET [base]/Observation?patient=463&category=laboratory

Organization

For an example JSON response for Organization, please see the following: Organization.

Profile Details:

You can retrieve a specific Organization record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Organization/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Patient

For an example JSON response for Patient, please see the following: Patient.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Patient?_id=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Patient?identifier=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Patient?name=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Patient?birthdate=[value]&name=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Patient?gender=[value]&name=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Patient/_search
content-type: application/x-www-form-urlencoded
Parameter: _id=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Patient record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Patient/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Patient?_id=[value]&_revinclude=Provenance:target
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
_id GET [base]/Patient?_id=463
birthdate GET [base]/Patient?birthdate=1980-05-16
gender GET [base]/Patient?gender=Male
identifier GET [base]/Patient?identifier=463
name GET [base]/Patient?name=Pass

Search Parameter Combination Summary:

Parameter Combination Example
birthdate+name GET [base]/Patient?birthdate=1980-05-16&name=Pass
gender+name GET [base]/Patient?gender=male&name=Pass

Practitioner

For an example JSON response for Practitioner, please see the following: Practitioner.

Profile Details:

You can retrieve a specific Organization record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Practitioner/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Procedure

For an example JSON response for Procedure, please see the following: Procedure.

Profile Details:

This resource is called like the following:

GET https://FHIR_ENDPOINT/Procedure?patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83
GET https://FHIR_ENDPOINT/Procedure?date=[value]&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource is called like the following by search:

POST https://FHIR_ENDPOINT/Procedure/_search
content-type: application/x-www-form-urlencoded
Parameter: patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve a specific Procedure record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Procedure/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

You can retrieve the “_revinclude” information with any request using the following:

GET https://FHIR_ENDPOINT/Procedure?_revinclude=Provenance:target&patient=[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

Search Parameter Summary:

Parameter Example
patient GET [base]/Procedure?patient=463
date GET [base]/Procedure?date=2016-08-31T00:00:00.00+00:00

Search Parameter Combination Summary:

Parameter Example
patient+date GET [base]/Procedure?patient=463&date=2016-08-31T00:00:00.00+00:00

Provenance

For an example JSON response for Provenance, please see the following: AllergyIntolerance + Provenance Bundle.This is an Allergy Intolerance response with the Provenance attached at the end (in response to a _revincludes parameter).

Profile Details:

You can retrieve a specific Provenance record “directly” using an Unique ID (like 123, 1234, 12345 etc):

GET https://FHIR_ENDPOINT/Provenance/[value]
Authorization: Bearer C02C96B042EA0FEC1EC9972410281A120FE0C06902FCAC742354FD6DDF0EEE83

This resource does not support any parameters and can only be called directly.