Patent data details

Patient data uses definition for the element PatientExport in the XML schema ExportImport.xsd.

The SFM migration format is based on available fields in the SFM data model. When exporting from the EPJ system it is not required to export all fields that are defined in the export definition (XSD). The Required column denotes the minimum functional requirements to migrate the data elements in addition to schema validation imposed by ExportImport.xsd.

Messages

Messages that have been sent or received by EPJ can be exported. The following types of messages can be exported:

• All RF resept lookup requests and replies (M9.5 and M9.6)
• All RF PLL/multidose lookup requests and replies (M9.11 and M9.12)
• All KJ lookup requests/responses
• All M25.1, M25.2 and M25.3 messages (sent or received) for each patient
• All prescription messages (M1). Note, that this only includes messages that have been sent to RF or received from RF/KJ. Note that FM also stores M1 messages for prescriptions that are not e-resept, e.g. printed, fax, telephone or locally registered prescriptions (Reg). These prescriptions will be exported (as described in section 2.4.2.4.1), but the M1 messages will not be exported. Also, M1 messages for drafts and unsent M1 messages will not be exported.
• All delivery messages (M6, M8, M8.1, M9.8, M25.3)
• All recall messages (M5)
• All recall notifications (M7)
• All Helfo applications and replies (M2, M12)
• MD patient status update requests and replies (M9.21, M9.22)
• Subscription to receive delivery notifications (M24.1, M24.2)
• Multidose responsible doctor registrations and replies (M27.1, M27.2)
• All SLV replies (M15)
• Notifications about changed multidose-responsible doctor (M28)
• Any AppRec messages related to the above messages. These can be either AppRec messages that FM has received from RF or Helfo, or AppRec messages that FM has sent. Note that in some cases there can be more than one AppRec related to each message, e.g. when sending an M1 fails with a negative AppRec and re-sending the M1 succeeds.
• M25.1 messages generated as a part of a medication review for a patient. This represents the local LIB at the time of review.

The following information is exported for each message record:

• Local unique id
• ParentId (RefToParent from MsgHead)
• Correspondance (RefToConversation from MsgHead)
• State (Successful or Failed)
• MsgId (from MsgHead)
• Type (from MsgHead)
• GenDate (from MsgHead)
• Message file (Relative path to message file on disk)

Cave (legemiddelreaksjon)

All known CAVE information can be exported. This includes CAVE records registered in EPJ or received from EPJ or via M25 messages. This includes history for each CAVE record and will include records marked as inactive, discarded, disproved ("avkreftet") or deleted. The CAVE information can be exported with the following information for each CAVE record:

• A unique ID for the record
• A groupID for keeping track of history. Different versions of the same CAVE record will have the same groupID. If there is no history, ID = groupID and HeadOfHistory = true.
• HeadOfHistory flag will indicate if this is the latest (current) version of the record.
• Flag to indicate reaction to an inactive ingredient or an active ingredient. (HjelpestoffReaksjon)
• Text describing the reaction. (GrunnlagForCave)
• Date of registration. (RegistreringsDato)
• The name of the user who registered the CAVE. (Signatur)
• Flag to indicate if the CAVE entry is active or inactive. (Innaktiv)
• The medication, active substance or ATC code.(LegemiddelMerkevare,Virkestoff,ATC)
• The type of allergic reaction (from coding system 7497). (Reaksjon)
• The source of the CAVE information (from coding system 7498). (Kilde)
• Seriousness (code for critical/serious/less serious). (Alvorlighetsgrad)
• Likelihood (kodeverk 7521). (Sannsynlighet)
• When discovered (date or age or unknown/not specified). (Oppdaget)
• Flag for "discarded"
• Flag for "deleted", along with reason and user who deleted
• Disproved flag and comment (Avkreftet, AvkreftetKommentar)

Treatment/prescription information

All prescription information can be exported. This export can include all prescriptions that are (or have been) a part of the VIB (Varer i bruk), including:

• All types of prescriptions: medications, NIB, FIB and vaccines.
• Local registrations (Reg)
• All known history for these prescriptions, including a detailed version history.
• Prescriptions that have been deleted or removed (as part of the remove/replace LIB operation).
• Prescriptions received in an RF/KJ lookup and have been marked as discarded, or have not been handled locally. Note that these prescriptions have never been a part of the local LIB.
• AK journal information
• Drafts

This export will be structured as treatments, where each treatment may contain one or more prescriptions and each prescription will have one or more versions. As an example, adding a new medication prescription draft to the LIB will create a new treatment with a prescription that has one version. If this draft is then edited, a new version will be created. Accepting the draft will create the third version and signing and sending this to RF will create the fourth version. If this item is later renewed, a new prescription will be created.

Medication treatments (LIB)

The following medication treatment information can be exported:

• A unique ID. If a resept exists, this will be the resept-id (i.e. the MsgId of the M1 message), otherwise an ID generated by FM. This can be used to match to an exported M1 message
• For prescriptions that are not e-resepts (i.e. no M1 message is exported), the corresponding prescription data will be exported using a data structure based on the Resept element from the M1 definition, i.e. without the MsgHead envelope.
• LIB ID (to keep track of history items for a treatment). For PLL, this will be the M25 LIB ID
• Reference to previous version of this treatment, to support history.
• For locally registered medications: reference to local medication/preparation
• Prescription type
  • eRp/uRp (not yet sent or printed)
  • eRp (e-resept)
  • uRp (printed)
  • fRp (fax)
  • tRp (telephone)
  • Reg (local registration)
  • iRp (imported)
  • iReg (imported without resept)
• Seponering information (for stopped treatments)
  • Date/time
  • Coded reason
  • Comment
  • User
• Delivery information for all known deliveries
• Start date
• Date/time of creation
• Local status
  • M1 pending
  • M1 failed (including an error message)
  • M5 pending
  • M5 failed (including an error message)
• Responsible users
  • Instituert av (instituted by): The doctor and/or the institution/ward that started the treatment.
  • Forespurt av (requested by): When registering a draft prescription, this specifies the doctor who requested the prescription.
  • Registrert/sist endret av (registered by/last edited by): The user who created or last edited the prescription. This may be any user with privilege to create/edit a prescription (i.e. including assistants, nurses, etc.). This is not shown when the prescription has been sent/printed.
  • Godkjent av (approved by): The user who approved a draft version of the prescription. This may be a nurse if this is a "double-signed" local registration.
  • Forskriver (forskriver): The name/HprId of the prescriber. When registering a prescription draft or renewal, an assistant can select any local doctor as Forskriver. Doctors however cannot do this - the doctor registering a prescription will always be set as the Forskriver.
• Diagnosis code (indikasjon) ICD10/ICPC
• Flag to indicate if generic substitution is allowed or not
• Reason for not allowing generic substitution
• Reason for ignoring CAVE warning
• Recall reason
• Change reason
• "Forholdsregel ved inntak"
• Anticoagulation information
  • INR value
  • Date of INR measurement
  • Minimum INR
  • Maximum INR
  • Date of next planned INR measurement
  • Comment
  • Date of next planned dosing evaluation
• For drafts: draft type
  • New prescription
  • Renewal
  • Import
  • Stop
  • Recall
• Pharmacy questions and answers (only for multidose)
• For prescriptions that have been removed from the LIB or discarded external items, i.e. explicitly excluded from local LIB:
  • Date/time of removal
  • User who removed
  • Type of removal:
    • Deleted
    • Discarded
    • Local LIB emptied by user
    • Rejected pharmacy proposal (M25.2)
  • For deleted prescriptions: Coded delete reason (from kodeverk 9237)
  • Comment

Local LIB comments

For each medical treatment, there may exist a local comment. Each comment may have a history, i.e. a new version is created when the comment is edited. The comment history is exported for each treatment, also comments that have been deleted. This includes the following data:

• Date/time created/edited
• User who created/edited
• The comment
• If the comment has been deleted:
  • Date/time of deletion
  • User who deleted

NIB, FIB and vaccine treatments

The exported information for NIB, FIB and vaccine treatments will use the same structure as for the LIB treatments described above. Some elements are not applicable (e.g. AK information). The main difference is that the NIB and FIB information will have a ReseptDokHandelsvare element whereas LIB and Vaccine have a ReseptDokLegemiddel.

Guide to SetImportedTreatmentsToInactive.

It is possible to configure if imported treatments are set to active or inactive. If value is set to 1/true then imported treatments will default to inactive(grey). Lookup from RF/KJ will determine if they result in being active or not. If value is set to 0/false then imported treatments will default to active(white). To set and read this GET and PUT operations are available.

Examples: GET

GET https://datashare-endpoint/Basic/SetImportedTreatmentsToInactive?_query=sfm-config
content-type: application/json
Authorization: Bearer {token}

PUT

PUT https://datashare-endpoint/Basic/SetImportedTreatmentsToInactive?_query=sfm-config
content-type: application/json
Authorization: Bearer{token}

Payload

{
"resourceType": "Basic",
"id": "SetImportedTreatmentsToInactive",
"meta": {
"versionId": "1",
"profile": [
  "http://ehelse.no/fhir/StructureDefinition/sfm-config"
 ]
 },
 "code": {
 "coding": [
  {
    "system": "http://ehelse.no/fhir/CodeSystem/sfm-config",
    "code": "1"
  }
 ]
 }  
 }

Note that if vibStatus is set then this will override the configured setting.

Medication review

All medication reviews performed for a patient will be exported

• Patient Id
• Doctor who performed the review
• Date of review
• Comment
• Information sources (e.g. Pasient, Kjernejournal, Reseptformidleren, Epikrise)
• An M25.1 document that contains the patient's LIB (and CAVE) at the time of review

Helfo applications

All HELFO applications can be exported. These can be electronic, where an M2 was sent and M12 reply may have been received

• Patient Id
• Medication (brandname, product group (NIB), local medication, preparation)
• Requesting doctor (HPR id)
• Date/time sent
• Refusjonshjemmel
• Refusjonskode
• "Draft" flag
• For deleted applications:
  • date/time of deletion,
  • user who deleted
• For electronic applications (M2 sent)
  • Reference to M2 document
  • Reference to (zero or more) M12 reply documents
• For local registrations (no M2 sent)
  • Applicant name
  • Reply
    • Date of acceptance
    • Status (granted or rejected)
    • Justification (text)
    • Valid until (date)

Handled medication interactions

When interactions are detected between medications in the VIB, the user may (or be required to) mark them as "handled". This can be done for a particular interaction (where medications A and B interact). For these, the following data is exported:

• Treatment1 Id
• Treatment2 Id
• Interaction Id (from FEST)
• Active flag
• Comment
• Date/time when marked as handled
• User that marked as handled

Similarly, when the same medicine is prescribed twice (or two closely related medicines), the warning shown can be marked as "handled". For these handled warnings, the following data is exported:

• Treatment1 Id
• Treatment2 Id
• Interaction Id (from FEST)
• Active flag
• Comment
• Date/time when marked as handled
• User that marked as handled

When prescribing a medicine where the patient has a registered CAVE, the user is required to "handle" the related warning. For this, the following information is exported:

VIB confirmations

All VIB confirmations that have been done will be exported. This information includes

• Patient Id
• The user that confirmed
• Confirmation type (Admission, PreliminaryAdmission, Discharge, AfterChange, Other)
• Date/time of confirmation
• Comment
• Other information (text)
• Institution Id
• M25.1 message Id (when registering an automatic VIB confirmation after sending a PLL message, this refers to the M25.1)