This initial profile localizes the STU2 version of the HL7 International specifcation: https://hl7.org/fhir/smart-app-launch/STU2/ , defining what context properties should be expected in the Australian usage, and highlight the core capabilities, not redefine/change those.
Although some existing servers may be implementing the v1 scopes, we should be moving to adopt the v2 scopes which provide greater granularity of control.
Note: Initially we only plan to support practitioner usage launching direct from the PMS (Clinician Access for EHR Launch), and no patient or standalone usage will be expected (although implementations may do this according to the HL7 International specification)
Many systems permit administrative users to access parts of the clinical record for activities such as completing administrative forms, or making appointments, these users do not have a Medicare Provider Number, however would be operating as a delegate of the practitioner, and thus could delegate access using their medicare provider number.
Implementer Question: How should this be represented in the SMART profile? The NCSR does this through the inclusion of the providerNo and isDelegate in the id_token.
Is there a standard workflow/user experience that would make sense for this?
There are many installation types of PMS systems in Australia, and this may impact the configuration of OAuth Client IDs used in SMART Apps. The specific configuration that could be problematic where there are many (thousands) of on-site PMS systems hosting smart apps that all have a unique individual issuer (local to the site) and if these all had a seperate client ID, this would be difficult to manage from a SMART App perspective.
Implementer Question: Who should be allocating OAuth Client IDs, can these be by negotiation between the systems?
Conformance
Refining the details from the core specifcation https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#using-well-known
One of the significant change between the v1 and v2 FHIR SMART App Launch profiles is the move away from the extensions in the CapabilityStatement for the auth endpoints, and to referencing the new /.well-known/smart-configuration to read the configuration (note that the value does not have .json on the end, which was in earlier revisions of the spec)
Systems may choose to still utilize the (now legacy) capability statement extensions.
Capability Sets
Initially only covering support for Clinician Access for EHR Launch (section 8.1.1.4 from the FHIR SMART App Launch spec)
Capabilities
Launch Mode: Require launch-ehr
Authorization Methods: Require authorize-post
Client Types: Support either client-public or client-confidential-symmetric
Launch Context: Require context-ehr-patient, optional context-ehr-encounter and context-banner
Permissions: Require permission-v2, and require one or both of permission-patient, and permissions-user and optional permission-offline
Implementer Question: Will the exclusion of the permission-v1 capability cause issues?
Implementer Question: Should we be defining an additional capability for context-ehr-practitionerrole or via a new scope (e.g. openid fhirUserRole)? (which indicates that the user context supports practitionerrole)
Implementer Question: Is there any interest in the sso-open-id-connect profile?
FHIR Authorization Endpoint and Capabilities Discovery - Metadata
(Section 8.2.2.1 from the FHIR SMART App Launch spec)
The following metadata will be included:
| Metadata property | Required | Notes |
|---|---|---|
| issuer | Y | String conveying this system’s OpenID Connect Issuer URL that creates the JWT token - can be used to locate the public keys if using the kid or x5u JWT header parameter. |
| authorization_endpoint | Y | |
| token_endpoint | Y | |
| token_endpoint_auth_methods | (conditional) | Required when the Client Type is a client-confidential-symmetric system |
| scopes_supported | Y | Refer to Scopes section below - propose inclusion of launch/location (for requesting the Location the practitioner is working in for this session) |
| response_types_supported | Y | |
| capabilities | Y | (values as noted above) |
| code_challenge_methods_supported | Y |
Implementer Question: Should we be supporting these additional optional extra parameters?
"introspection_endpoint": "https://ehr.example.com/user/introspect",
"registration_endpoint": "https://ehr.example.com/auth/register",
"management_endpoint": "https://ehr.example.com/user/manage",
"revocation_endpoint": "https://ehr.example.com/user/revoke",Adding introspection helps alleviate the potential issues with the size of v2 tokens with large scope constraints on things like observations
Implementer Question: One implementer has required that the issuer be the name of the issuer of the digital certificate issuer used to sign the cert - this is wrong?
e.g. "Test Medicare Australia Organisation Certification Authority"
Example Metadata Request
GET /fhir/.well-known/smart-configuration HTTP/1.1 Host: ehr.example.com
Example Response
HTTP Status: 200
content-type: application/json
{
"issuer": "https://ehr.example.com",
"authorization_endpoint": "https://ehr.example.com/auth/authorize",
"token_endpoint": "https://ehr.example.com/auth/token",
"token_endpoint_auth_methods_supported": ["authorize-post"],
"scopes_supported": ["openid", "profile", "launch", "launch/patient", "launch/location", "patient/*.rs", "user/*.rs", "online_access", "offline_access"],
"response_types_supported": ["code"],
"code_challenge_methods_supported": ["S256"],
"capabilities": [
"launch-ehr",
"permission-v2",
"client-public",
"client-confidential-symmetric",
"sso-openid-connect", // optional
"context-banner", // requires a patient banner to be displayed in the SMART app via need_patient_banner token parameter
"context-ehr-patient",
"context-ehr-encounter",
"permission-offline", // for refresh tokens - requested through offline_access scope
"permission-user", // support for user level scopes e.g. user/Appointment.rs
"permission-patient", // support for patient level scopes e.g. patient/Observation.rs
"permission-v2" // support for SMARTv2 granular scope syntax (recommending over v1 scopes)
]
}
Scopes
https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html
Recommending only leveraging v2 scopes, and where v1 scopes are present, the conversion to v2 scopes should be encouraged.
Specific scopes focused for Australian EHR Launch usage
| Scope | Additional usage notes |
|---|---|
| launch | Smart App can request this from the Auth server to indicate that they need to see the patient/practitioner context |
| launch/patient | The SMART App is requesting access to the selected patient (if there is none selected, then the service should make the user select a patient before continuing |
| launch/location | (Experimental proposal) request that the location of the practitioner be provided with the along with context - this then indicates that the practitionerRole should be included in the id_token so that the SMART app is then able to get access to the Practitioner's Medicare Provider Number. |
Launch Context arriving with the access_token
All these parameters are optional depending on their context of use, but typically will expect patient, practitioner, practitionerRole and location/organization
| Launch context parameter | Example | Description | Requested scope |
|---|---|---|---|
| access_token | The access token that can be used to access the FHIR api - to be used as a bearer token. This may be a full JWT with the claims all visible, or could be a reference token that requires the use of an introspection endpoint to retrieve the claims from, this introspection may not be visible to the SMART App. | (n/a) | |
| patient | "123" | Resource ID of the Patient in context | launch, launch/patient |
| encounter | "123" | Resource ID of the Encounter (if any) in context | launch, launch/encounter |
| need_patient_banner | true | This is an optional parameter that may not be supported by all clients. For some systems like the NCSR SMART App, they will include a patient banner inside always - as this includes the details of the patient as known in the NCSR, not the EMR that is hosting the smart app. | (n/a) |
| practitioner | "p123" | Resource ID of the Practitioner using the system | launch/location |
| practitionerrole | "pr123" | Resource ID of the PractitionerRole applicable to the practitioner currently using the system (this is particularly important in Australia to be able to retrieve the Practitioner's Medicare Provider number) | launch/location |
| organization | "org1" | Resource ID of the organization listed in the practitioner role (as defined above) | launch/location |
| location | "loc1" | Resource ID of the location listed in the practitioner role (as defined above) | launch/location |
| id_token | The Identity Token for the user | "openid fhirUser", "openid profile" | |
| refresh_token | (optional) Request a refresh_token that can be used to obtain a new access token to replace an expired one | offline_access, online_access |
Implementer Question: Should the practitioner, pracRole and organization properties be included in the id_token as well as the launch context parameters, or just leave them in the id_token only?
App Launch Intent
Implementer Question: Question if we should be including some options for these? and should HL7 be cataloging a set of these for the industry?
e.g. intent=smart-form(Questionnaire canonical URL) or intent=smart-form when opening a smart form application, with and without a form ID
Identity Token
When signing the ID token using the NASH digital certificate, and storing the public key into the token response, either as an x5u (URL reference to the public key) or x5c (the complete x509 public certificate - base64encoded) https://self-issued.info/docs/draft-ietf-jose-json-web-signature.html#x5cExample
Using the NASH key they permits the receiver to check the validity of the public certificate against the NASH infrastructure, ensuring that the HPI-O in the certificate should be trusted.
Note: The alternative for using the NASH certificate here is to use private/public key pairs and the jku/kid, jwk claims, however that won't be able to verify the organization making the call, and will require significant pre-registration, and verification of matching identifiers etc.
| Property | Example | Required | Description |
|---|---|---|---|
| sub | | Y | The internal user ID of the user - doesn't have any meaning outside the organization that creates the JWT, however it should be unique within their context, and is typically used for logging. |
| profile | | Y | The complete FHIR resource URL of the user, typically the Practitioner, and for this EHR Launch context it will be the Practitioner reference |
| iss | "https://ehr.example.com" | Y | The URL of the openid connect Issuer (used to retrieve other content to verify the validity of the token |
| aud | | Y | The URL of the application this id_token was created to provide access to, this should be the URL of the SMART Application itself (or the system it is representing) |
| exp | | Y | Expiry time for this token (ticks/epoch time) |
| jti | "fddd892c15654879939feb4d2945f520" | Y | Unique token identifier (may be generated with something like a GUID) |
| iat | | Y | The time this token was issued (ticks/epoch time) |
| nbf | | Y | This token is not to be used before this time (ticks/epoch time) |
| providerNo | | Medicare Provider Number for the practitioner accessing the system (or on their behalf) (should we be including this here?) | |
| isDelegate | "N" | Is the user accessing the system a delegate of the supplied Medicare Provider Number | |
| pmsver | | This provides details of the name/version of the software that produced the token for support/logging purposes | |
| practitioner | "123" | Resource ID of the Practitioner using the system | |
| practitionerrole | "123" | Resource ID of the PractitionerRole applicable to the practitioner currently using the system (this is particularly important in Australia to be able to retrieve the Practitioner's Medicare Provider number) | |
| organization | "123" | Resource ID of the organization listed in the practitioner role (as defined above) | |
| location | "123" | Resource ID of the location listed in the practitioner role (as defined above) |
Example Identity Token
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlHWkRDQ0JVeWdBd0lCQWdJQ0loZ3dEUVlKS29aSWh2Y05BUUVMQlFBd2VqRUxNQWtHQTFVRUJoTUNRVlV4RERBS0JnTlZCQW9UQTBkUFZqRVdNQlFHQTFVRUN4TU5TSFZ0WVc1elpYSjJhV05sY3pGRk1FTUdBMVVFQXhNOFZHVnpkQ0JOWldScFkyRnlaU0JCZFhOMGNtRnNhV0VnVDNKbllXNXBjMkYwYVc5dUlFTmxjblJwWm1sallYUnBiMjRnUVhWMGFHOXlhWFI1TUI0WERUSXdNREl4TnpBeU5Ea3hPVm9YRFRJeU1ESXhOekF5TkRreE9Wb3dnZUV4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0poZFRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTI1bGRERWdNQjRHQ2dtU0pvbVQ4aXhrQVJrV0VHVnNaV04wY205dWFXTm9aV0ZzZEdneEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKcFpERWdNQjRHQ2dtU0pvbVQ4aXhrQVJrV0VEZ3dNRE0yTWpNeU16TXpOamN4TURBeElEQWVCZ05WQkFvVEYxUmxjM1FnU0dWaGJIUm9JRk5sY25acFkyVWdOelV6TVR3d09nWURWUVFERXpOblpXNWxjbUZzTGpnd01ETTJNak15TXpNek5qY3hNREF1YVdRdVpXeGxZM1J5YjI1cFkyaGxZV3gwYUM1dVpYUXVZWFV3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ3h0cUg0U1RuVjFhWWwzZU1rSVVMV25yODhucG92Zm56T0dWUFhpMUZncVFLUG9HQW9UU054R2tqUmxkUXNRQVRrbmoxSWRvNkxZS2IvdGZ2NGNoT3ZjSzRYSkdLSWRIV3FVSXE1VVZSalFTQ2VNUmlmK3Fzb0loZ1p2RjE5VFd6SWhMNEl1MTFzQUdNS1hSTi9EQmhmemhnNUJJR1dCSGhEYTQ1UWV6YUdIVHMvYmdIRE5oYzZmeUdDbXZNUnRndHBkSWtsNHlvVXVYbTVBeXhxSi9XeCtZSVdxVmdTbnI5TWxmRUsxZ1ZmNVZuakc5aGtlekR5VTF2OXlTWVdKbE9MNHlxRVB1WDlCRnF2anNqVFR5VTVrNU93RXU0NUoyMFBDTTJjazZuaXlBT3BJMGFhellpME5MQSswQU9zMlNFVXY0cDczVUx2bjZUNUs2R0JSNnQ3QWdNQkFBR2pnZ0tLTUlJQ2hqQU1CZ05WSFJNQkFmOEVBakFBTUV3R0NDc0dBUVVGQndFQkJFQXdQakE4QmdnckJnRUZCUWN3QVlZd2FIUjBjRG92TDIxaGRHVnpkRzlqYzNBdVkyVnlkR2xtYVdOaGRHVnpMV0YxYzNSeVlXeHBZUzVqYjIwdVlYVXZNSUlCSEFZRFZSMGdCSUlCRXpDQ0FROHdnZ0VMQmdvcUpOTCtnSGNCRkFFQk1JSDhNSUhMQmdnckJnRUZCUWNDQWpDQnZocUJ1ME5sY25ScFptbGpZWFJsY3lCcGMzTjFaV1FnZFc1a1pYSWdkR2hwY3lCRFVDQnRkWE4wSUc5dWJIa2dZbVVnY21Wc2FXVmtJRzl1SUdKNUlHVnVkR2wwYVdWeklIZHBkR2hwYmlCMGFHVWdRMjl0YlhWdWFYUjVJRzltSUVsdWRHVnlaWE4wTENCMWJteGxjM01nYjNSb1pYSjNhWE5sSUdGbmNtVmxaQ3dnWVc1a0lHNXZkQ0JtYjNJZ2NIVnljRzl6WlhNZ2IzUm9aWElnZEdoaGJpQjBhRzl6WlNCd1pYSnRhWFIwWldRZ1lua2dkR2hwY3lCRFVDNHdMQVlJS3dZQkJRVUhBZ0VXSUdoMGRIQTZMeTkzZDNjdWFIVnRZVzV6WlhKMmFXTmxjeTVuYjNZdVlYVXZNQmtHQ1Nva281Q1ZGd0hPR1FRTUZnbzNOVEF6TXpJMk1UVTBNRTBHQTFVZEVRUkdNRVNHUW1oMGRIQTZMeTl1Y3k1bGJHVmpkSEp2Ym1samFHVmhiSFJvTG01bGRDNWhkUzlwWkM5b2FTOUlVRWt0VHk4eExqQXZPREF3TXpZeU16SXpNek0yTnpFd01EQU9CZ05WSFE4QkFmOEVCQU1DQkxBd0h3WURWUjBqQkJnd0ZvQVVyMkRlZFdITFQyb3dvVGFUUmsxbE13Q0lyZTR3VGdZRFZSMGZCRWN3UlRCRG9FR2dQNFk5YUhSMGNEb3ZMMjFoZEdWemRDNWpaWEowYVdacFkyRjBaWE10WVhWemRISmhiR2xoTG1OdmJTNWhkUzlOUVU5RFFUSXZiR0YwWlhOMExtTnliREFkQmdOVkhRNEVGZ1FVUnY4SGc0c1BSRXpEcnphYXBNd05xRWNjNHQ0d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCR3V5N0hRL2Y0bll6L2xkalpMckdpbXdETnM2Szlhc25ieWN5VzZaa2gvaDZtQXdjYzJ3RitYQUpuenFqVkJUcThIYnJkQi82Vzkrb0IvRGtaMEZBWkxDSUJXRlBmcGErcWswWklEaEtSWmd2aEZ6eWlyaDcrdDRiN1Jac0xPZHpkTzhOdnB6NnRBS2RoTFBBVnRnd2h5N1lIYjZZcGwrSFhKRTZZQm04YWlEcUVDMHcrdzc5Sk5YVVZUOHVGNkc0SzVJbisxS2wyMWFxS09uSHdXNk9tb09GRWVpZnJpYVZySGs3bEMxdjJRUUdOT2pVS1dKQ1BVNjFyNGFCT2ZqeVp6Yjc1TjdKdGF5ZUwzeDhKQ2o3Q1YvaFJHZ0x1d1hIeVVHZ3lsVGhRNlB1dHMvSlJlRFFrTG1HMkFYUVhQT3dCWkhOM3Y1WlNLajZKblkvNFJFME09Il19.eyJzdWIiOiIwIiwibmFtZSI6IlRlc3QgRG9jdG9yIE5hbWUiLCJwcm9maWxlIjoiaHR0cHM6Ly90ZXN0LmZoaXItZmFjYWRlLmxvY2FsaG9zdC9QcmFjdGl0aW9uZXIvMCIsImlzcyI6IlRlc3QgTWVkaWNhcmUgQXVzdHJhbGlhIE9yZ2FuaXNhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSIsImF1ZCI6Imh0dHBzOi8vZmhpcnRlc3QuZW1lcmdpbmcuY29tLmF1IiwiZXhwIjoxNjI2NjczODQ0LCJqdGkiOiJmZGRkODkyYzE1NjU0ODc5OTM5ZmViNGQyOTQ1ZjUyMCIsImlhdCI6MTYyNjY3MDE4NCwibmJmIjoxNjI2NjcwMTg0LCJwcm92aWRlck5vIjoiOTc2MTY2Q0giLCJpc0RlbGVnYXRlIjoiTiIsInJvbGVzIjpbIlByYWN0aXRpb25lciIsIlByYWN0aWNlTWFuYWdlciJdLCJwbXN2ZXIiOiJFeGFtcGxlIEVIUiB2MS4zNCIsInByYWN0aXRpb25lciI6IjAiLCJwcmFjdGl0aW9uZXJyb2xlIjoiZWZkMDE1NmZlMjNjNDM5ZDkwNDIyZWViNWMwMTM4Y2UiLCJvcmdhbml6YXRpb24iOiIwIn0.bSMu1hNCIhvFcPAeETDhQap95jXdgwPPZpN17qf35sqykHvZPVvVFmm6fIloZgccAfNWpd9YGHMTO33U4oq35VeyRXAhPMUrshQF5ozVDH6otSKRCHKiddMFzCiotNNe3RAmlS8m3vP28eSf325cPzPE4sddPqxxNUBgrIT0bFpNmSu3rBw4_Ql6MO_ZBFr2pnZak2FiFlzW6sU-XVEbJL5U8cBQ7YZhX4xF6PNEmdrY1zcVT5lHZwKgYOCziH1gK47_TuVbaGvTwpVqE6T3YuzCpUNllc_MW9kKtEslpqE6hz1YbRT4unuVa2SjpqHiM5nDwcw-e0TZ5uEeHPpwVA
Header Parameters:
{
"alg": "RS256",
"typ": "JWT",
"x5c": [
"MIIGZDCCBUygAwIBAgICIhgwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCQVUxDDAKBgNVBAoTA0dPVjEWMBQGA1UECxMNSHVtYW5zZXJ2aWNlczFFMEMGA1UEAxM8VGVzdCBNZWRpY2FyZSBBdXN0cmFsaWEgT3JnYW5pc2F0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTIwMDIxNzAyNDkxOVoXDTIyMDIxNzAyNDkxOVowgeExEjAQBgoJkiaJk/IsZAEZFgJhdTETMBEGCgmSJomT8ixkARkWA25ldDEgMB4GCgmSJomT8ixkARkWEGVsZWN0cm9uaWNoZWFsdGgxEjAQBgoJkiaJk/IsZAEZFgJpZDEgMB4GCgmSJomT8ixkARkWEDgwMDM2MjMyMzMzNjcxMDAxIDAeBgNVBAoTF1Rlc3QgSGVhbHRoIFNlcnZpY2UgNzUzMTwwOgYDVQQDEzNnZW5lcmFsLjgwMDM2MjMyMzMzNjcxMDAuaWQuZWxlY3Ryb25pY2hlYWx0aC5uZXQuYXUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxtqH4STnV1aYl3eMkIULWnr88npovfnzOGVPXi1FgqQKPoGAoTSNxGkjRldQsQATknj1Ido6LYKb/tfv4chOvcK4XJGKIdHWqUIq5UVRjQSCeMRif+qsoIhgZvF19TWzIhL4Iu11sAGMKXRN/DBhfzhg5BIGWBHhDa45QezaGHTs/bgHDNhc6fyGCmvMRtgtpdIkl4yoUuXm5AyxqJ/Wx+YIWqVgSnr9MlfEK1gVf5VnjG9hkezDyU1v9ySYWJlOL4yqEPuX9BFqvjsjTTyU5k5OwEu45J20PCM2ck6niyAOpI0aazYi0NLA+0AOs2SEUv4p73ULvn6T5K6GBR6t7AgMBAAGjggKKMIIChjAMBgNVHRMBAf8EAjAAMEwGCCsGAQUFBwEBBEAwPjA8BggrBgEFBQcwAYYwaHR0cDovL21hdGVzdG9jc3AuY2VydGlmaWNhdGVzLWF1c3RyYWxpYS5jb20uYXUvMIIBHAYDVR0gBIIBEzCCAQ8wggELBgoqJNL+gHcBFAEBMIH8MIHLBggrBgEFBQcCAjCBvhqBu0NlcnRpZmljYXRlcyBpc3N1ZWQgdW5kZXIgdGhpcyBDUCBtdXN0IG9ubHkgYmUgcmVsaWVkIG9uIGJ5IGVudGl0aWVzIHdpdGhpbiB0aGUgQ29tbXVuaXR5IG9mIEludGVyZXN0LCB1bmxlc3Mgb3RoZXJ3aXNlIGFncmVlZCwgYW5kIG5vdCBmb3IgcHVycG9zZXMgb3RoZXIgdGhhbiB0aG9zZSBwZXJtaXR0ZWQgYnkgdGhpcyBDUC4wLAYIKwYBBQUHAgEWIGh0dHA6Ly93d3cuaHVtYW5zZXJ2aWNlcy5nb3YuYXUvMBkGCSoko5CVFwHOGQQMFgo3NTAzMzI2MTU0ME0GA1UdEQRGMESGQmh0dHA6Ly9ucy5lbGVjdHJvbmljaGVhbHRoLm5ldC5hdS9pZC9oaS9IUEktTy8xLjAvODAwMzYyMzIzMzM2NzEwMDAOBgNVHQ8BAf8EBAMCBLAwHwYDVR0jBBgwFoAUr2DedWHLT2owoTaTRk1lMwCIre4wTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL21hdGVzdC5jZXJ0aWZpY2F0ZXMtYXVzdHJhbGlhLmNvbS5hdS9NQU9DQTIvbGF0ZXN0LmNybDAdBgNVHQ4EFgQURv8Hg4sPREzDrzaapMwNqEcc4t4wDQYJKoZIhvcNAQELBQADggEBABGuy7HQ/f4nYz/ldjZLrGimwDNs6K9asnbycyW6Zkh/h6mAwcc2wF+XAJnzqjVBTq8HbrdB/6W9+oB/DkZ0FAZLCIBWFPfpa+qk0ZIDhKRZgvhFzyirh7+t4b7RZsLOdzdO8Nvpz6tAKdhLPAVtgwhy7YHb6Ypl+HXJE6YBm8aiDqEC0w+w79JNXUVT8uF6G4K5In+1Kl21aqKOnHwW6OmoOFEeifriaVrHk7lC1v2QQGNOjUKWJCPU61r4aBOfjyZzb75N7JtayeL3x8JCj7CV/hRGgLuwXHyUGgylThQ6Puts/JReDQkLmG2AXQXPOwBZHN3v5ZSKj6JnY/4RE0M="
]
}
Payload Data:
{
"sub": "BQcwAYYwaHR0cDovL21",
"name": "Test Doctor Name",
"profile": "https://test.fhir-facade.localhost/Practitioner/0",
"iss": "Test Medicare Australia Organisation Certification Authority",
"aud": "https://fhirtest.emerging.com.au",
"exp": 1626673844,
"jti": "fddd892c15654879939feb4d2945f520",
"iat": 1626670184,
"nbf": 1626670184,
"providerNo": "976166CH",
"isDelegate": "N",
"pmsver": "Example EHR v1.34",
"practitioner": "0",
"practitionerrole": "efd0156fe23c439d90422eeb5c0138ce",
"organization": "0"
}