CursaHealth FHIR Documentation

Technical documentation regarding FHIR resources and API methods to interoperate with CursaHealth FHIR platform will be found here. Default syntax is JSON, authorization is performed by using OAuth2 (under TLS 1.2)

Client Registration

Client Applications can be registered with CursaHealth by submitting a request by filling out theClient Registration FormOnce the registration process is successfully completed, Client will be issued an OAuth Client ID, Secret Key.

Components and Configurations

Confidential Clients: To be registered as a confidential client, the client must be capable of storing a client secret.
Public Clients: Clients that are not capable of securely storing a client secret will be registered as public clients.
Bulk Export: Clients using the Bulk Export API must support authorization using the Client Credentials Flow with JWT Credential.
Standalone Launch: Standalone Launch is currently supported for patient-facing 3rd-party applications. These Apps must support the Authorization Code Flow as outlined in the SMART App Launch IG 1.0.0.
EHR Launch: EHR Launch is currently supported for provider-facing applications that are integrated with the EHR. These Apps must support the Authorization Code Flow as outlined in the SMART App Launch IG 1.0.0.

Authorization Server Info

The FHIR Authorization root URL :

https://fhirauth.cursahealth.com/connect/authorize

Token URL :

https://fhirauth.cursahealth.com/connect/token

OpenID Connect well-known configuration :

https://fhirauth.cursahealth.com/.well-known/openid-configuration

API Information

FHIR Base URL:
```
https://fhirapi.cursahealth.com/api
```

FHIR Capability Statement URL:

https://fhirapi.cursahealth.com/api/metadata

SMART Configuration URL:

https://fhirapi.cursahealth.com/api/.well-known/smart-configuration

TOKEN VALIDATION THROUGH INTROSPECTION ENDPOINT

Introspection endpoint is used for validating tokens.

https://fhirauth.cursahealth.com/connect/introspect

Token Refresh / OFFLINE_ACCESS

A Refresh Token is returned by the authorize endpoint when the offline_access scope is requested and obtained with the user’s authorization. To get an access token from a refresh token, you will need to form a new token request providing the refresh token in the refresh_token parameter a nd refresh_token as the value for the grant_type parameter. An app will also need to specify in the scope parameter which of the previously granted scopes your app would like included in the new access token.

Accessing Resources

To access FHIR® resources utilizing an access token, include a "bearer" authorization header in your HTTP request per RFC 6750 as follows:

Authorization: Bearer eyJraWQiOiIyMDE2LTExLTAxVDE1OjExOjQ4LjY1NS5lYyIsInR5

Resources

Allergy Intolerance

This resource conforms to USCDI profile for Allergy Intolerance - refer to US Core AllergyIntolerance Profile. Allergy Intolerance response can be requested in JSON or XML format as per FHIR standard R4 version AllergyIntolerance - FHIR v4.0.1(hl7.org) supports the following data elements

GETSearch Allergies

GETAllergy Intolerance By Id

POST_search

BMI For Age Observation

This resource conforms to USCDI profile for Observation - refer toUS Core BMI for Age Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as BMI Percentile.

GETSearch BMI For Age Observation

GETObservation By Id

POST_search

Condition Health Concerns

This resource conforms to USCDI profile for Condition - refer to US Core Condition Profile. Condition response can be requested in JSON or XML format as per FHIR standard R4 version Condition - FHIR v4.0.1 (hl7.org) supports the following data elements documented as follows.

GETSearch Condition

GETCondition By Id

POST_search

CarePlan

This resource conforms to USCDI profile for CarePlan - refer to US Core CarePlan Profile. CarePlan response can be requested in JSON or XML format as per FHIR standard R4 version CarePlan - FHIR v4.0.1 (hl7.org) supports the data elements documented as Assessment and Plan of Treatment

GETSearch CarePlan

GETCarePlan By Id

POST_search

CareTeam

This resource conforms to USCDI profile for CareTeam - refer toUSCore CareTeam Profile.CareTeam response can be requested in JSON or XML format as per FHIR standard R4 version CareTeam - FHIR v4.0.1 (hl7.org) supports the following data elements.

GETSearch CareTeam

GETCareTeam By Id

POST_search

Device

This resource conforms to USCDI profile for Device - refer to USCore Device Profile. Device response can be requested in JSON or XML format as per FHIR standard R4 version Device - FHIR v4.0.1 (hl7.org) supports the following data elements documented as Unique Device Identifier(s) for Patient's Implantable Device(s).

GETSearch Device

GETDevice By Id

POST_search

DiagnosticReport

This resource conforms to USCDI profile for DiagnosticReport - refer to US Core DiagnosticReport Profile. DiagnosticReport response can be requested in JSON or XML format as per FHIR standard R4 versionDiagnosticReport- FHIR v4.0.1 (hl7.org) supports the following data elements documented DiagnosticReport as Laboratory.

GETSearch DiagnosticReport

GETDiagnosticReport By Id

POST_search

DocumentReference

This resource conforms to USCDI profile for DocumentReference - refer to US Core DocumentReference Profile. DocumentReference response can be requested in JSON or XML format as per FHIR standard R4 version DocumentReference - FHIR v4.0.1 (hl7.org) supports the following data elements:

GETSearch DocumentReference

GETDocumentReference By Id

POST_search

Encounter

This resource conforms to USCDI profile for Encounter - refer to US Core Encounter Profile. Encounter resource response can be requested in JSON or XML format as per FHIR standard R4 version Encounter - FHIR v4.0.1 (hl7.org) supports the following data for Encounter.

GETEncounter

Goal

This resource conforms to USCDI profile for Goal - refer to US Core Goal Profile. Goal response can be requested in JSON or XML format as per FHIR standard R4 versionGoal - FHIR v4.0.1 (hl7.org) supports the data element Patient Goals

GETSearch Goal

GETGoal By Id

POST_search

Head Occipital-frontal Circumference

This resource conforms to USCDI profile for Observation - refer toUS Core Pediatric Head Occipital-Frontal Circumference Percentile Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as Occipital-frontal Head Circumference Percentile.

GETSearch Head Occipital-frontal

GETObservation By Id

POST_search

Immunization

This resource conforms to USCDI profile for Immunization - refer to US Core Immunization Profile. Immunization response can be requested in JSON or XML format as per FHIR standard R4 version supports the data elements documented as Immunization.

GETSearch Immunization

GETImmunization By Id

POST_search

Laboratory Result Observation

This resource conforms to USCDI profile for Observation - refer toUS Core Lab Result Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as Lab Result Observation.

GETSearch Laboratory Result Observation

GETObservation By Id

POST_search

Location

This resource conforms to USCDI profile for Location - refer to US Core Location Profile. Location resource response can be requested in JSON or XML format as per FHIR standard R4 version Encounter - FHIR v4.0.1 (hl7.org) supports the following data for Location.

GETLocation

MedicationRequest

This resource conforms to USCDI profile for MedicationRequest - refer to US Core MedicationRequest Profile. MedicationRequest response can be requested in JSON or XML format as per FHIR standard R4 version MedicationRequest - FHIR v4.0.1 (hl7.org) supports the following data elements documented as Medications.

GETMedicationRequest By Patient Id

GETMedicationRequest By Id

POST_search

Observation Body Height

This resource conforms to USCDI profile for Observation - refer to US Core Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org) supports the data elements documented as Body Height.

GETSearch Observation Body Height

GETObservation By Id

POST_search

Observation Body Temperature

GETSearch Observation Body Temperature

GETObservation By Id

POST_search

Observation Blood Pressure

GETSearch Observation Blood Pressure

GETObservation By Id

POST_search

Observation Body Weight

GETSearch Observation Body Weight

GETObservation By Id

POST_search

Observation Heart Rate

GETSearch Observation Heart Rate

GETObservation By Id

POST_search

Observation Respiratory Rate

GETSearch Observation Respiratory Rate

GETObservation By Id

POST_search

Organization

This resource conforms to USCDI profile for Organization - refer to USCore Organization Profile. Organization response can be requested in JSON or XML format as per FHIR standard R4 version Organization - FHIR v4.0.1 (hl7.org)supports the following data elements:

GETOrganization

Patient

This resource conforms to USCDI profile for Patient Demographics - refer to USCore Patient Profile. Patient resource response can be requested in JSON or XML format as per FHIR standard R4 version Patient - FHIR v4.0.1 (hl7.org)supports the following data for Patient

GETSearch Patient

GETSearch Patient By ID

POST_search

Procedure

This resource conforms to USCDI profile for Procedure - refer to US Core Procedure Profile. Procedure response can be requested in JSON or XML format as per FHIR standard R4 version Procedure - FHIR v4.0.1 (hl7.org) supports the data elements documented as Procedures.

GETSearch Procedure

GETProcedure By Id

POST_search

Practitioner

This resource conforms to USCDI profile for Practitioner - refer toUSCore Practitioner Profile. Practitioner response can be requested in JSON or XML format as per FHIR standard R4 version Practitioner - FHIR v4.0.1 (hl7.org) supports the following data elements:

GETPractitioner

Provenance

This resource conforms to USCDI profile for Provenance - refer to US Core Provenance Profile. Provenance response can be requested in JSON or XML format as per FHIR standard R4 version Provenance - FHIR v4.0.1 (hl7.org) supports the following data elements:

GETProvenance

Pulse Oximetry

This resource conforms to USCDI profile for Observation - refer toUS Core Pulse Oximetry Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as Pulse Oximetry.

GETSearch Pulse Oximetry

GETObservation By Id

POST_search

Smoking Status Observation

This resource conforms to USCDI profile for Observation - refer toUS Core Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as Smoking Status.

GETSearch Smoking Status

GETObservation By Id

POST_search

Weight For Height Observation

This resource conforms to USCDI profile for Observation - refer toUS Core Pediatric Weight For Height Observation Profile. Observation response can be requested in JSON or XML format as per FHIR standard R4 version Observation - FHIR v4.0.1 (hl7.org)supports the data elements documented as Weight for Length Percentile.

GETSearch Weight For Height Observation

GETObservation By Id

POST_search

Errors and Exceptions

ERROR HANDLING

Requests made without an access token, an invalid or expired access token, or for resources not permitted under the user's privileges defined by the authorization will result in an HTTPS 401 status code. An "Unauthorized" API may return a status code for communicating the result of each transaction/API call. The complete list of status codes typically returned by API are as follows:

Code	Meaning
200	The request was processed appropriately.
400	Invalid parameter.
401	The request did not have a valid authorization token or none was provided. Obtain a valid authorization token and add it to the authorization header.
403	The user is not authorized for the operation. The user may not have access to the patient, or an invalid scope was provided.
404	Not found.

Terms & Conditions

Terms and Conditions of Use

Please read these Terms of Use before using the API hosted on https://fhirapi.cursahealth.com/. Your access to use the Service is based on your acceptance with these Terms. These Terms apply to all users of CursaHealth API. If you disagree with any part of the terms then you may not access the Service.

Account Security: You are responsible for safeguarding the password that you use to access the CursaHealth API and for any activities or actions under your password, whether your password is with our Service or a third-party service. You agree not to disclose your password to any third party. You must notify us immediately upon becoming aware of any breach of security or unauthorized use of your account.
Termination of Access and use: Company may, in its sole discretion, terminate the right to access and use the API of any Eligible Application that has violated these Terms and Conditions
License: Company hereby grants you a non-transferable, non-exclusive, limited license to use the API subject to the terms and conditions of this Agreement. You may not, either on your own behalf or through any agent or third party decompile, disassemble, reverse engineer, or otherwise attempt to derive source code from the software components of the API, or modify or create derivative works based on the software components of the API.
Modifications: Company reserves the right, at our sole discretion, to modify or replace these Terms at any time. If a revision is made we will try to provide notice prior to any new terms taking effect. What constitutes a material change will be determined at our sole discretion. By continuing to access or use our Service after those revisions become effective, you agree to be bound by the revised terms. If you do not agree to the new terms, please stop using the Service.
Acceptance: Use of the API signifies your acknowledgement and acceptance of these Terms of Use. If you do not agree to these terms of use, please do not use the API.