Compose a launch
The launch steps on this page are the same for HTI as SHOF
Last updated
The launch steps on this page are the same for HTI as SHOF
Last updated
To perform the launch, the following steps must be performed for both HTI and SHOF:
The HTI:core v2.0 profile describes the following claims:
| HTI claim | Type | Required | Description |
|---|---|---|---|
An example of the resulting HTI claims:
The HTI:core v2.0 profile also contains claims that are always set on a JWT:
These two sets of claims should be combined to form a valid HTI v2.0 JWT. For example:
The timestamps follows the "UNIX time" convention, being the number of seconds since the epoch.
After the JWT is completely filled, it must be signed. For this, Signing the JWT can be followed.
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).
There are minimal differences between sending via HTI and SHOF.
| Description | Field | Value |
|---|---|---|
resource
string
yes
The identifier of the task to be executed by the person in the sub field.
definition
url
no
A Reference that refers to the FHIR ActivityDefinition. The reference can be found on the Task.instantiates extension.
sub
reference
yes
This is a person reference to the patient, practitioner or related person.
patient
reference
no
This is a person reference to the patient, only used when the 'sub' is not a patient
intent
string
no
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 FHIR value set RequestIntent
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.