Invoking activated CDS Hooks based services

After registering and activating a CDS service set, CDS services can now be called through the interopiO™ gateway. The URL for the call has the format "<gateway_url>/cds-services/<cds_service_id>". The "cds_service_id" will be the "override id" if one was specified or created automatically for that service. CDS service invocations are performed with a POST REST call with a request body conforming to the CDS Hooks specification (https://cds-hooks.org/specification/1.0/#calling-a-cds-service). What should be included in the request body depends on what the provider needs as well as the gateway configuration. Below outlines three possible scenarios:

Scenario 1 - Provider performs no FHIR calls

POST https://interopio.com/gateway/fhir/account-id/env-id/gtwy-id/cds-services/example-service-id
 
{
    "hookInstance" : "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
    "hook": "patient-view",
    "context": {
        "patientId": "patient-01",
        "userId": "Practitioner/practitioner-01"
    },
    "prefetch": {
        ... optional ...
    }
}

Not yet available.

Scenario 3 - Provider performs FHIR® call to internal interopiO™ service (i.e. interopiO™ CDR), invoked the Provider Portal

CDS Services registered in interopiO™ and activated on a gateway that does not require a launch proxy, may make FHIR calls to the gateway as long as the app is launched from the Provider Portal. To accomplish this we use the portal access token to authenticate the incoming CDS Service invocation, then inject a new fhirAuthorization object containing a valid access token for the gateway.

If you wish to allow a downstream CDS Service to make to an interopiO gateway, when invoking the CDS Service through the Provider Portal, the request should look like:

POST https://account.interopio.com/gateway/fhir/account-id/env-id/gtwy-id/cds-services/another-service-id
 
{
    "hookInstance" : "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
    "hook": "patient-view",
    "fhirServer": "https://interopio.com/gateway/fhir/account-id/env-id/gtwy-id",    
    "context": {
        "patientId": "patient-01",
        "userId": "Practitioner/practitioner-01"
    },
    "prefetch": {
        ... optional ...
    }
}

Note that the fhirAuthorization object can be left blank and that the fhirServer property should match exactly the full URL of the gateway base: https://interopio.com/gateway/fhir/account-id/env-id/gtwy-id 

Scenario 4 - Provider performs FHIR® call to external FHIR® server

This occurs on a gateway which has a "default data source" that points to an external FHIR (i.e. Epic, Cerner, etc.). The `fhirServer` value must match the "default data source" url. The `fhirAuthorization` object must include an access token which can be used to access the`fhirServer`.

POST https://account.interopio.com/gateway/fhir/account-id/env-id/gtwy-id/cds-services/another-service-id
 
{
    "hookInstance" : "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
    "hook": "patient-view",
    "fhirServer": "https://open-ic.epic.com/fhir/DSTU2",
    "fhirAuthorization": {
        "access_token": "eyJqa3UiOiJodHRwczpcL1wvYXV0aC5oc3Bjb25zb3J0aXVtLm9yZ1wvandrIiwia2lkIjoicnNhMSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJhdWQiOiJzYW5kX21hbiIsImlzcyI6Imh0dHBzOlwvXC9hdXRoLmhzcGNvbnNvcnRpdW0ub3JnXC8iLCJleHAiOjE1NjIwODI3MTcsImlhdCI6MTU2MTk5NjMxOCwianRpIjoiZDk3YTI2ODMtNjZiOS00NGNjLWIzZTQtNTBiM2I4NTc1NTBlIn0.MSj77hO4J6VJkQMlv0nPJUAJ3GDlw9lO03iBqvHygF25oAzkoDBZ4nNHF9dyydA4MTktFgP15J2lnMZbVq-8lcwqc9P872vUeaNR23A1gkFJm2rx4PKmzWJiIsYZ5kO1c_QGsdkW951c0SEAnpCysEaVSiihiQW9LytyDSesWjunAtIgHiP-bFZfFWIuRgNUy8zibY5BgHfYXyo3Hq0gKw9F6FRfKs5qOQJ1XsAP6LWyJs3Eg5fPVldfUHWWuN0WphbNd0u8WyLdwEAZ-_vCeu548OKD7AbjOml0qQa4VaaTCKY1YzALAZTk6Us0cEtIh-S6dsNZH1Up0k0ZtSM9Xg",
        "token_type": "Bearer",
        "scope": "patient/*.read user/*.read",
        "subject": "special-client-id"
    },
    "context": {
        "patientId": "patient-01",
        "userId": "Practitioner/practitioner-01"
    },
    "prefetch": {
        ... optional ...
    }
}