Page Comparison

...

To use Kjernejournal (the norwegian Core Journal -“KJ”from now on), information about the place of treatment (in addition to“juridisk person”- in most cases the organization number of the municipality) is required to be included in access tokens issued by HelseID. This is information which only the system accessing KJ knows at the time of treatment. Therefore, mechanisms have been implemented to transmit thisinformation this information to HelseID when the user authenticates.

HelseID supports two methods of passing organization numbers from the client. The most commonly used mechanism allows the client to specify the place of treatment (child unit) the user represents while the parent unit is set as a fixed value on the client configuration. The other mechanism allows the client to specify both the parent and child units in the same request. HelseID only allows this for selected clients, it is not meant to be used by most clients.

Terms

Kjernejournal (“KJ”)

...

The following must be in place for HelseID to approve a submitted place of treatmentorganization information.

POST must be used

Signed JWTs can be large, and there are size restrictions in browsers and web servers on GET requests. POST must be used when passing requests to the authorization endpoint in HelseID. This causes some complexity in native applications (“tykke klienter”) that use an integrated browser for authentication to HelseID. See our sample code for how this can be handled.

Valid subunits parent units or sub units must be pre-registered in HelseID

When HelseID receives a sub-unit organization information from the subject system, a validation is made if it is validvalidated. The subunits units that are valid for a professional system must therefore be pre-registered in HelseID. This is currently done in the HelseID portal.

For clients that should specify both parent and child units the list of parent units must be setup manually by the HelseID operations team. The process for setting this up must be agreed upon before using the mechanism. At the time of writing HelseID only validates the parent unit, the child unit is still represented in tokens but it is not validated by HelseID.

Public key for validating the signed Request Object JWT must be pre-registered in HelseID

When HelseID receives a sub- unit from the professional subject system, the signature on the JWT in which it is located is validated. The public key to be used for this must be pre-registered in HelseID. This is currently done in the HelseID portal.

...

Code Block

    JWK
}.
{
    "nbf":1575463285,
    "exp":1575463345,
    "iss": "some_client_id",
    "client_id": "some_client_id",
    "jti": "some_unique_value",    
    "aud":"https://helseid-sts.nhn.no",
    "authorization_details": {LOOK BELOW FOR FORMAT}
}.
{
    SIGNATURE
}

Authorization Details for specifying child units

The following structure must be used to provide the organization number for the place of treatment. This structure expresses the following:

...

Code Block

"authorization_details":
{
    "type":"helseid_authorization",
    "practitioner_role":
    {
        "organization":
        {
            "identifier":
            {
                "system":"urn:oid:2.16.578.1.12.4.1.2.101",
                "type":"ENH",
                "value":"[org number]",
            }
        }
    }
}

Authorization Details for specifying both parent and child units

The following structure must be used to provide the organization numbers for the parent and child units. Ths structure is similar to the one described above, but with the following changes:

“system” must be “urn:oid:1.0.6523” instead of "urn:oid:2.16.578.1.12.4.1.2.101".
“value” must be of the form "NO:ORGNR:[parent orgnumber]:[child orgnumber]"

Code Block

"authorization_details":
{
    "type":"helseid_authorization",
    "practitioner_role":
    {
        "organization":
        {
            "identifier":
            {
                "system":"urn:oid:1.0.6523",
                "type":"ENH",
                "value":"NO:ORGNR:[parent orgnumber]:[child orgnumber]",
            }
        }
    }
}

Name	Defined By	Description
		Explanation of Authorization Details Items
authorization_details	The Rich Authorization Requests specification	Rich Authorization Requests Parameter Name
type	Type of authorization request. Only valid value is `helseid_authorization`	FHIR links organization and health professionals through the role of health care professionals.
practitioner_role	FHIR	FHIR links organization and health professionals through the role of health care professionals.
organization	FHIR	The organization health personnel has a role in.
identifier	FHIR	Unique identification for an organization.
system	FHIR	Organization.system contains a uri (in this case an OID) that uniquely identifies the registry in which the organization is registered. Must have the value `urn: oidoid: 22.16.578.1.12.4.1.2.10` indicating the Unit Registery in Norway, or the value `urn:oid:1.0.6523`. which indicates ISO standard 6523.
type	FHIR	Description of the register in which the organization is registered. Must have value `ENH` indicating the Unit Register in Norway.
value	FHIR	The If specifying a child unit this value should be the identifier of the treatment site / sub-unit, ie a Norwegian organization number. Nine digits. If specifying a parent and child unit this value should include the identifiers of the parent organization followed by the identifier of the child organization, setup as follows: `NO:ORGNR:[parent orgnumber]:[child orgnumber]`

Example of full request

Below is an example of an http request to the authorization endpoint which includes a claim for a place of treatment.

...

Versions Compared

Old Version 3

New Version 4

Key

Terms