MSK Blaze FHIR Server Documentation¶

Clinical trials attempt to answer questions. To help do this effectively, it’s important to leverage best in class technology to rapidly increase the speed with which research data can be shared and tear down barriers that impede this process. Sharing research data faster can lead to better outcomes for patients, less time spent on manual coding and redundant data mapping, and reduced costs typically associated with new drug or therapy development. By leveraging the HL7 FHIR standard (Fast Healthcare Interoperability Resources), academic sites and clinical trial sponsors can unite to achieve these shared goals.

To this end, Memorial Sloan Kettering (MSK) has developed a FHIR server for clinical research data. This server is named “Blaze.”

Core Features¶

Complaince with FHIR version 4.0.0
OAuth (client_credentials) authentication flow
Coverage of the following FHIR Resources:
- Observation (e.g. Laboratory Results)

Guide¶

Introduction¶

Assumptions¶

This documentation assumes that the reader has a familiarity with the HL7 FHIR specification, as well as a basic understanding of RESTful Web Service concepts.

MSK Blaze conforms to the eSource Consortium CR Implementation Guide, located here: https://esource-consortium.github.io/fhir-clinical-research/

Getting Started¶

API Reference¶

The MSK Blaze API is organized around REST. Each FHIR resource type currently supports read and basic search capabilities.

Authentication¶

In order to make use of Blaze, you’ll need to be set up as an MSK “partner” so that you can consume clinical research data. If you would like to request access to data for a research study at MSK, please send a request to rtmcritds@mskcc.org.

Authentication is based on the Client Credentials grant. This means that clients will need to generate an access token and supply it in the headers of each request being made. Once you are established as a partner, you’ll be given a client_id and a client_secret, which you will use for generating tokens and using them to make authenticated requests to the server.

Generating Tokens¶

To generate access tokens, partners need to make a POST request to the appropriate endpoint using their client_id and client_secret:

Base URL (Test)¶

https://webapit.mskcc.org/

Base URL (Production)¶

Coming Soon...

Request

POST /auth/oauth/v2/token
Content-Type: application/x-www-form-urlencoded
client_id=YYYY
client_secret=XXXX
grant_type=client_credentials
scope=oob

Response

{
    "access_token": "7ef1949a-fab1-4600-89ca-fbeb499ef68f",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "oob"
}

Making Requests¶

To make requests, include the bearer token you generated in your requests as a part of the Authorization header. Consider the following request for retrieving observations for a research study:

Request

GET /api360/v2/clinical/observations?researchstudy=TEST&category=laboratory&_count=5
-H Authorization: Bearer {access_token}

Response (some attributes omitted for brevity)

{
    "resourceType": "Bundle",
    "identifier": {
        "system": "https://datapedia.mskcc.org/index.php/IDB.PROTOCOL",
        "value": "TEST"
    },
    "type": "searchset",
    "total": 20,
}

Authorization¶

All data access is restricted on a per protocol basis. It is assumed that incoming requests to Blaze always contain a researchstudy parameter, which identifies what research study the client is requesting data for.

Your client_id determines what research studies you have access to at MSK. This information is used in combination with the researchstudy parameter to authorize requests. If a partner has sufficient authority to access protocol data, the request will proceed - otherwise they will get an error message.

Core Resources¶

Observations¶

Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns and even capture demographic characteristics.

Laboratory¶

Representative of laboratory results, such as blood glucose, or an estimated GFR.

Endpoint

GET /api360/v2/clinical/observations?researchstudy={id}&category=laboratory

Please see the implementation guide for more example RESTful FHIR interactions related to observations.