Patient information

Introduction

Using the Patient resource in SFM is restricted to using the sfm-Patient resource.

The resource is available to make it possible for EPJ systems to write and update information about the patient. SFM does not look up or retrieve patient data from PREG/Persontjenesten when using the Patient resource; the EPJ remains responsible for the correctness of the information supplied. SFM performs local validation and consistency checks on the data received. (Other communication will not refer to the Patient resource directly, as the temporary patient-ticket is obscuring the "real" patient in the communication.)

Only the commands PUT, POST and GET are made available for users. PUT and POST are restricted to users with privileges and should only be used when the user is editing information about the patient. POST and GET require that a patient-ticket is generated and used to request the information.

The attribute active is required to define whether or not the patient is in active use. In this way patients that are set to inactive for different reasons are also marked in SFM as inactive, but may be re-activated later.

Write patient information

putPatient

  1. The user with privileges creates or updates patient information within EPJ.
  2. EPJ PUT or POST updated information to SFM.
  3. SFM validates the payload according to its rules (identifiers, required fields, uniqueness of FNR/DNR across patients, and related checks). No call is made to PREG/Persontjenesten to fetch or verify the patient record for this operation.
  4. If the checks are OK, SFM stores or updates the patient. SFM then returns a FHIR status response (200/400).
  5. EPJ presents OK or error to user.

Merging patient records (Planned, not available yet)

When the EPJ detects that two different patient records represent the same patient, it is possible to merge the records by using method POST, and add information about how the records are related. The attribute Link shall be used to identify the Patient record that should be linked to current Patient. SFM only supports Link.type = replaces. SFM will set the referred record as inactive and merge the journal information into current patient.

Notes on identifier cardinality

The Identifier.use property accepts currently only old and official. The DNR and FNR identifiers require one and only one use = official. For the XXX-id use = official should be used to indicate that this identifier shall be included in further API communication.

When there is a need for changing an Identifier, an update with relevant identifier use is requested. As the cardinality specified for XXX-id is 0..1 it is not possible to write the old value together with the new. This is an unlikely operation and should be carried out with care. SFM MAY in this case return more than one XXX-id for informational reasons, but the EPJ must ensure that the cardinality is correct on update operation, as SFM will not accept both the old and the new XXX-id.

Input information and checks performed

SFM will do the following checks when patient information is written:

  • If FNR/DNR is provided, SFM will check whether a record has already been registered for the patient.
    1. If POST is used, SFM will respond with an error if the patient exists in SFM.
    2. If PUT is used, SFM will respond with an error if the patient does not exist in SFM.
  • Either FNR, DNR or xxx-id is required on create or update.
  • One, and only one among FNR and DNR shall have use = official.
  • First and family name must be provided.
  • In address, type, postal code and city must be provided as a minimum. Line should be provided if registered in EPJ.
  • In absence of FNR or DNR, then gender, birthdate and xxx-id shall be provided. In this case Identifier.use must be official.

Input data that will not be stored or validated

The following will not be validated or stored in SFM:

  • maritalStatus
  • multipleBirth
  • photo
  • contact
  • communication
  • generalPractitioner
  • managingOrganization

In HumanName the following will not be validated or stored:

  • use
  • text
  • prefix
  • suffix
  • period

It is expected that EPJ updates with current name.

In Address the following will not be validated or stored:

  • propertyinformation
  • official
  • urbanDistrict
  • text
  • state
  • period

It is expected that EPJ updates with current addresses.