This wiki has undergone a migration to Confluence found Here

201709 Consumer Centered Data Exchange Implementation Notes for

From HL7Wiki
Jump to navigation Jump to search

Using as the target EHR

e.g information flows from another server to

Sequence of steps:

  1. get the JWT
  2. authorize the JWT on the other server
  3. Ask to start copying data
  4. find out how copying data is going
  5. stop copying data

Acquiring's JWT

you get the JWT by:


Where [uri] is the address of the source system. Source is a mandatory parameter, though it does not make any difference to

this returns a 200 OK with a body content type of application/jwt:


(note that some browsers don't like this content type in the return body)

Calling $connect

post to$connect:



200 OK

<OperationOutcome xmlns="">
       <status value="generated"/>

Connection Accepted

       <severity value="error"/>
       <diagnostics value="Connection Accepted"/>
</OperationOutcome> will now start consuming data using the S4S interface specified in source

Using as the source EHR

Sequence of steps:

  1. set up consent on JWT
  2. get a JWT form some other system
  3. connect that JWT to the consent using the $authorize function


Use this consent resource as the base for authorization (post it to the server, record the id that the server assigns):

<Consent xmlns=""> 
 <status value="active"/>
   <reference value="Patient/example"/>
 <policyRule value=""/>  
   <type value="permit"/>
       <system value=""/>
     <system value=""/>


  • you can change the patient but it must be a patient that exists on the server. If you logged via smart on fhir, and you chose a particular patient during the login, the consent must refer to that patient.
  • you can use json instead if you want


This is what you post to the server as a body to the $authorize routine (this time in json):

 "resourceType" : "Parameters",
 "parameter" : [{
    "name" : "duration",
    "valueDuration" : {
      "value" : "3",
      "system" : "",
      "code" : "mo"
  }, {
    "name" : "jwt",
    "valueString" : "{packed JWT from the target server}"

The response contains a key value: the authorization token:

   "resourceType": "Parameters",
   "parameter": [
           "name": "Message",
           "valueString": "Application Validation is not implemented yet"
           "name": "id",
           "valueId": "a81de03d-cfad-462d-a81b-3f8254909622"

Acquiring an Access Token

Once $authorize has been called, the target EHR may acquire an access token for the FHIR API:

 Authorization: Bearer [JWT]
 Content-Type: application/x-www-form-urlencoded

where [JWT] is the JWT provided to $authorize in the previous step and [id] is the token returned from the $authorise operation above

The response will be:


   "access_token": "urn:oauth:e8a4131c-1c04-4c2f-aba0-985ce472b90d",
   "token_type": "Bearer",
   "expires_in": "7621372",
   "scope": "user/*.*",
   "patient": "example"


The token returned with this can now be used in the Authorization header to read what data the patient authorized

GET [base]/Patient/[id]
Authorization: Bearer urn:oauth:e8a4131c-1c04-4c2f-aba0-985ce472b90d

Client Application Verification Service also implements the Client Application Verification Service. The CAVS end-point is

No authentication is needed to call the cavs.

todo: JWK sources

The decision making behind the cavs is based on the device, organization and observation resources stored in This is a matter of internal convenience; these are not directly suitable for the task, and there's no recommendation that other systems should follow this example. It was just a matter of convenience. There's a client app that edits the content - you can get that by asking