Using SFM patient ticket

In order to safeguard privacy when transferring information between EPJ and SFM, the communication is based on a two-step model where EPJ requests a patient ticket with a limited duration in order to be able to access patient information from SFM and write patient information to SFM. The patient ticket must be used in the URL when opening the SFM GUI and when using the SFM Datadeling API.

The patient ticket acts as a key between the patient ID and the medication data, with purpouse limited to obscure the real identity of the patient related to medication data.

Note that the patient ticket should be renewed for each new practitioner (user) and patient. The patient ticket should be used throughout the user session. This means that a new patient ticket should not be requested for each call to the SFM Datadeling API.

The patient ticket is unique to the SFM service and specified so that it should not be possible to guess at a valid ticket. This also means that it is not possible to write or read across organizations. The solution is thus fault tolerant. The request for access to a patient ticket must contain a patient ID (eg fnr, dnr, xxx-id). Since the ticket has a limited lifespan, it is possible to renew the ticket in the same way that the system also renews the access token. The patient ticket implements a sliding lifetime, the same ticket will be re-used and lifetime exended as long as it is valid.

Using patient ticket as patient reference

When a patient is referenced in SFM datadeling API, the patient ticket is used.

Patient ticket is used in the following resources:

• sfm-Task.for
• sfm-MedicationStatement.subject
• sfm-Condition.subject
• sfm-Observation.subject
• KjAllergyIntolerance.patient

The patient ticket is used in the GUI portals as parameter to the setPatient postMessage.

Obtaining a patient ticket

The patient ticket is a text string of a maximum of 200 characters. Patient ticket may be a GUID, but the format is intentionally not limited, eg: 44300220-455f-4333-b6e8-1464a7f44608.

The SFM Session service offer an endpoint for obtaining the patient ticket:

POST /api/PatientTicket
Content-type: application/json
Accept: text/plain (AND/OR ) application/json 
 :

{
"patientPid" :" 10092939427"
}

The patientPid parameter will be searched along the known identities of a patient registered in SFM with the following proiry: 1: FNR (norwegian fødselsnummer) 2: DNR (norwegian d-nummer) 3: XXX-id (unspecified identity used by the EHR system)

When the accept header in the request includes the application/json type, the response from SFM will be a JSON record:

 :
Content-type: application/json
Expires: Wed, 04 May 2022 16:00:00 GMT
 :

{
"patientTicket" :"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
}

in all other cases the response will be a simple plaintext in the body:

 :
Content-type: text/plain
Expires: Wed, 04 May 2022 16:00:00 GMT
 :

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

NOTE: The Expires date format complies to RFC 7231 / RFC 5322 as specified for HTTP header fields, allthoug currently using the obsolete (but still valid) variant for time zone

Relevant error codes

http status	explanation
400 Bad Request	Malformed request, probably not correct JSON
401 Unauthorized	Missing, not valid token or not recognized client or user
404 Not found	the patient is not found in this SFM compartment
405 Method not allowed	the client has used GET or PUT or other verb that is not allowed