Koppeltaal-2.0-Dev-Guide
  • Developer Guide
  • POC (Walking Skeleton)
    • Proof Of Concept
      • Koppeltaal Server
      • Domain Management
      • Auth Server
      • Koppeltaal IdP
      • Domain Access Test Suite
      • Koppeltaal Test Tooling
  • Domain access
    • Joining a domain
    • Role-based access control
      • Autorisation model
      • Creating a role
      • Search Narrowing
      • Revoke Permission
  • Technical HOW-TO
    • Koppeltaal Test Tooling
    • Request Koppeltaal server metadata
    • Connecting to Koppeltaal
      • Requirements
        • Create a key pair
        • Signing the JWT
        • JWKS setup
      • Access to Koppeltaal
    • Managing resources
      • Versioning
      • CRUD Operations
        • Retrieve all Resources
        • Retrieve specific Resource
        • Create a Resource
        • Update a Resource
        • Delete a Resource
      • Subscribing to changes
    • Launching
      • HTI Flow
      • SHOF Flow
      • Compose a launch
      • Initiating a launch
      • Receiving a HTI launch
        • Token introspection
      • Receiving a SHOF launch
    • Detailed technical guidance
  • Hackathon Use Cases
    • Requirements
      • Install and configure Yivi
    • Use-Cases
      • Use-Case 1: Create a Task
        • Create an ActivityDefinition
      • Use-Case 2: HTI Launch
      • Use-case 3: SHOF Launch
      • Use-case 4: Subscribing to changes
  • Useful Links
    • Simplifier Profiles
    • FHIR Docs
    • HTI documentation
    • GitHub
    • Koppeltaal 2.0 Specifications & Architecture
    • Koppeltaal 2.0 Implementation Guide
    • Koppeltaal 2.0 OpenAPI Specs
Powered by GitBook
On this page
  • 1. Create HTI context claims
  • 2. Create the JWT
  • 3. Sign the JWT
  • 4. Launch
  • Topics
  1. Technical HOW-TO
  2. Launching

Compose a launch

The launch steps on this page are the same for HTI as SHOF

To perform the launch, the following steps must be performed for both HTI and SHOF:

1. Create HTI context claims

The HTI:core v2.0 profile describes the following claims:

HTI claim
Type
Required
Description

resource

string

yes

The identifier of the task to be executed by the person in the sub field.

definition

url

no

sub

reference

yes

patient

reference

no

intent

string

no

An example of the resulting HTI claims:

{
    "resource": "Task/5f684c5f-2837-4505-a534-365431912f37",
    "definition": "ActivityDefinition/d76ba97b-bfce-4a75-8e7a-2133778d1089",
    "sub": "Practitioner/225d67a7-69b9-4343-b488-064945fe3fd3",
    "patient" : "Patient/b592f103-f75b-4a63-a5dd-b75799775258",
    "intent": "plan"
}

2. Create the JWT

The HTI:core v2.0 profile also contains claims that are always set on a JWT:

Description
Field
Value

Issuer

iss

The client_id van het portaal

Audience

aud

The device id of the module provider. This can be found via the ActivityDefinition.resource-origin extension.

Unique message id

jti

A unique identifier for this message. This value MUST be treated as a NONCE, a subsequent message with an identical jti MUST be rejected. The jti value must be a random or pseudo number, the jti MUST contain enough entropy to block brute-force attacks.

Issue time

iat

The timestamp of generating the JWT token, the value of this field MUST be validated by the module provider to not be in the future.

Expiration time

exp

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The value MUST be limited to 5 minutes. This value MUST be validated by the module provider, any value that exceeds the timeout MUST be rejected.

These two sets of claims should be combined to form a valid HTI v2.0 JWT. For example:

{
  "iat": 1585564845,
  "aud": "Device/123",
  "iss": "portal-client-id",
  "exp": 1585565745,
  "jti": "679e1e4c-bcb9-4fcc-80c4-f36e7063545c"
  "sub" : "Practitioner/225d67a7-69b9-4343-b488-064945fe3fd3",
  "resource" : "Task/5f684c5f-2837-4505-a534-365431912f37",
  "definition" : "ActivityDefinition/d76ba97b-bfce-4a75-8e7a-2133778d1089",
  "patient" : "Patient/b592f103-f75b-4a63-a5dd-b75799775258",
  "intent": "plan"
}

3. Sign the JWT

4. Launch

The signed token can now be launched to the client. To find the endpoint to be launched to, the ActivityDefinition.endpoint extension can be used. The correct ActivityDefinition can be found using Task.instantiates extension (see Retrieve specific Resource).

Topics

PreviousSHOF FlowNextInitiating a launch

Last updated 5 months ago

A Reference that refers to the FHIR ActivityDefinition. The reference can be found on the extension.

This is a to the patient, practitioner or related person.

This is a to the patient, only used when the 'sub' is not a patient

The intention of the launch, this field should be used to provide the intention of the launch such as the preparation, performance or review of the resource, is used, a value from the

The timestamps follows the convention, being the number of seconds since the epoch.

After the JWT is completely filled, it must be signed. For this, can be followed.

There are minimal differences between sending via and .

"UNIX time"
Signing the JWT
HTI
SHOF
TOP-KT-007 - Koppeltaal Launch
Task.instantiates
person reference
person reference
FHIR value set RequestIntent