Migrating data to SFM

The purpose of Migration is to import relevant data into the SFM system.

Migration in this context means that data is written via SFM's migration API and not via the data sharing API (where only personal data can be transferred for the patient and user). If patient data is migrated, user data must also be migrated.

When a customer with an existing journal start using SFM, there should be an evaluation of what data is needed to be included in SFM before the customer can start using the system in an efficient way.

What type of Migration Strategies you as a Vendor should offer your customers will be a consideration based on different factors:

  • Has the original system already been using e-resept so that structural data is available?
  • Do the customers need historical data over 3 years in SFM?
  • Is it a possibility for historicization (of data older than 3 years) in the old system?

The important thing is to fulfill the legal documentation obligations, as well as having a practically usable solution for the customer when starting using SFM.

Considerations

As stated initially, it is important to evaluate what data is needed to be included in SFM before the customer can start using the system in an efficient way.

The data responsible needs to ensure compliance with the legal obligations regarding documentation and storage of such data. Data can be migrated to SFM, but consideration should also be given to whether historical data need to be easily accessible to the user or not. Making history available in the EHR in other ways (than migrating) is also an option that should be considered. Making use of lookups in KJ with a longer range (up to 3 years) could also be used to get a broader picture of the patient's drug use over time, and probably cover most needs for historical information.

The GP is normally the doctor who has the best overview of what drugs the patient is using and which drug reactions they have recorded. This is documentation that is important for the GP, and it is often considered as a minimum to migrate the active drug list (aktiv LIB) and active drug reactions (where the quality is good enough).

For organizations that have not adopted e-prescription/KJ API previously, it should be considered not to migrate patients and user data to SFM. This applies to the vast majority of municipalities (with some exceptions where FM with integration to RF/KJ is used). In these cases, there might be local records on patients that cannot be reconciled with information from RF/KJ. After lookup in RF/KJ, these will appear in SFM as duplicate treatments and needs manually handling to ensure that the e-prescriptions will be the once that continues to be used. This manual handling will often be considered to be larger and more error prone than starting with an empty LIB and include necessary information successively. If information is migrated to SFM, it must be assessed which status that should be used when transferring the data, to separate the local record from records coming in from RF/KJ.

Regardless of migration, the organisation need to carry out a controlled transition to SFM, to ensuring that an overview of active treatments and drug reactions is recorded correctly when switching over to use SFM.

Most used Migration Strategies

Here are some pro and cons for the most used Migration Strategies for SFM.

No up-front Migration of data

  • Data from KJ (all active prescriptions + 3 months history) will be automatically retrieved when personnel with HPR open each Patient for the first time. Extended lookups from SFM (to KJ) may be done to retrieve history up to 3 years.
  • History over 3 years needs to be available for lookups in other sources (historicization)
  • Treatments without prescriptions needs to be manually registered in SFM
  • Legemiddelreaksjoner may be added in KJ (will sync to SFM) or in SFM (will sync to KJ)

No upfront migration

Migration of active LIB only

  • Migrate only active LIB
  • History beyond this can be retrieved via KJ up to 3 years
  • History (over 3 years) available for lookups (historicization)
  • Legemiddelreaksjoner may be added in KJ (will sync to SFM) or in SFM (will sync to KJ)

Active Lib Only

Full export/import of drug data (from e.g FM)

  • Import format based on export format from FM
  • Including all history

Full export import

Alternative migration methods in SFM

When migrating data to SFM, the vendors can use the SFM DataImporter API directly, or using the SFM File Uploader.

  • Third party EHR may upload directly to the SFM migration API
  • Third party EHR may use a dedicated SFM File Uploader.
    • The previous medication module (FM) has been extended with encrypted, file based export suitable for SFM import. The FM installation must be upgraded to a version supporting this if not already done. A dedicated file uploader is available for upload to SFM migration API.
    • Third party EHR may also export to the same (FM) format and use the SFM uploader.

See following pages for details