Patient information

Introduction

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

The resource is avaialble to make it possible for EPJ systems to write and update information about the patient. SFM is checking patient information against PREG in order make sure that the information provided from the EPJ is correct. (Other communication will not refere 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 is restricted to users with priveliges and should only be used when the user is editing information about the patient. POST and GET require that an patient-ticket is generated and used to request the information.

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

Write patient information

putPatient

  1. The user with priveliges creates or updates patient informaiton within EPJ.
  2. EPJ PUT or POST updated information to SFM
  3. If patient has FNR/DNR, SFM checks with PREG if FNR/DNR is valid.
  4. SFM receives feedback from PREG and checks internally that the FNR/DNR is not in use on another patient.
  5. If the checks are OK, SFM store/update the patient. SFM then return FHIR status response (200/400)
  6. EPJ present OK or error to user.

Merging patient records (Planned, not available yet)

When the EPJ detects that two differnt patient records represents 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 refered 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 requires 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 need for changing an Identifier, an update with relevant identifer 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 patientinformation is written:

  • if fnr/dnr is provided SFM will check if it has been previously registered a record for the patient.
    1. If POST is used SFM will respond with an error if patient exists in SFM
    2. If PUT is used SFM will respond with an error if patient does not excist in SFM
    3. SFM will (in the future) look the patient up in natioan registry. If provided PID is not the official or not valid, SFM will return an error.
  • 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 store 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 valiadated or stored:

  • use
  • text
  • prefix
  • sufix
  • period

It is expected that EPJ update with current name.

In Address the following will not be validated or stored:

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

It is expected that EPJ update with current addresses.