Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

Introduction

The eHealth Infrastructure performs import of organizations information from Sundhedsvæsnets Organisationsregister (SOR) and KOMBIT Fælleskommunalt (FK) Organisation (formerly Støttesystemet Organisation (STS-ORG)) to the eHealth Infrastructure daily.

During the import new or updated information in SOR and FK Organisation is updated in the eHealth Infrastructure.

A relationship between the FK Organization and the SOR-imported counterpart must be established.

This relationship can be established in two ways:

  1. The customers provide mapping as MS Excel files to the Systematic AO team, which then triggers the relationship being created.
    The customer provides organisation relationship file(s) containing mappings between KOMBIT STS Organization identifiers and SOR identifiers. This input is provided to an operation in the eHealth system by SRE. The operation will then process the file line-by-line and establish the relevant related-to relationships in the FHIR Organization resources.

  2. FUT Infrastructure automatically creates the relationship during import from FK Organisation if the SOR code is available in FK Organisation.
    The Municipalities FK Organisation administrator registers the SOR kode in the FK Organisation system (as address of type SOR ID), and the FUT infrastructure will automatically create the relationship during import.

eHealth Infrastructure imports from Sundhedsvæsnets Organisationsregister (SOR)

The eHealth Infrastructure imports organization information from Sundhedsvæsnets Organisationsregister (SOR) every night approximately 1 hour after SOR publishes the daily data file.

See Automated Processing for when the import is performed.

The SOR data file contains all organizations in SOR. The data file is published at http://filer.nsi.dk/sor/data/sor/sorxml/v_2_0_0/Sor.zip and is used in all FUT environments (exttest, test002 (education), pre-prod, production).

The import excludes the organization tree below 'Sundhedsdatastyrelsen' (SOR Identifier 634491000016008), and all children found below the organization.

All non-excluded InstitutionOwner, HealthInstitution and OrganizationalUnit resources found in the data file are transformed into eHealth Organization resources and imported.

Data mapping overview

The import respects the address inheritance rules defined by SOR by copying the relevant addresses from parents if not available for the current organization.
The import does not copy other attributes and values from the parent, and the current organizations are imported as-is.

The following table explains how each of the attributes on the FHIR resource is mapped from the SOR data model.

ehealth-organization element

Source from SOR

Description

id

N/A

Generated by FHIR server

meta.*

N/A

Generated by FHIR server

implicitRules

N/A

text

N/A

contained

N/A

extension

N/A

ehealth-organization-relatedTo

N/A

modifierExtension

N/A

identifier[0].use

Always set to official

identifier[0].type

N/A

identifier[0].system

always set to 'urn:oid:1.2.208.176.1.1'

identifier[0].code

SorIdentifier

The SOR identifier is stored in eHealth Infrastructure

identifier[0].period.start

SorStatus.FirstFromDate

identifier[0].period.end

SorStatus.ToDate

identifier[0].assigner

N/A

active

Computed based on SorStatus.ToDate and SorStatus.FirstFromDate

Set to true when:

sor1:ToDate is not set or is in the future and sor1:FirstFromDate is not a future date.

Set to false when

sor1:ToDate is in the past or sor1:FirstFromDate is a future date.

We will be using FirstFromDate as this is the flag used in SOR to set organizations active - FromDate is set when other data on the organization changes.

type

EntityTypeIdentifier

name

EntityName

alias

Concatenation of entityName from the top of the tree down to and including the current entity.

Example: For SorIdentifier=914571000016002 with name "KOL Klinik" the constructed alias will be:

"Region Midtjylland, Aarhus Universitetshospital, Lungesygdomme, Lungesygdomme Klinik, KOL Klinik"

cvrNumber

CVRNumberIdentifier

If the SOR organization has a CVR number, it is stored.

Only if available on the current SOR entity. (no inheritance)

Source

Always set to SOR.

See Organization Source - eHealth Infrastructure v3.0.0 (sundhed.dk)

partOf

Calculated from ParentSorIdentifier

Relationships defining the organization trees are reflected in the Organization.partOf element.

FHIR id for the parent organization according to the SOR hierarchy.

telecom[n].value

  • VirtualAddressInformation.EmailAddressIdentifier

  • VirtualAddressInformation.Website

  • VirtualAddressInformation.TelephoneNumberIdentifier

  • VirtualAddressInformation.FaxNumberIdentifier

telecom[n].system

Code calculated from

  • VirtualAddressInformation.EmailAddressIdentifier

  • VirtualAddressInformation.Website

  • VirtualAddressInformation.TelephoneNumberIdentifier

  • VirtualAddressInformation.FaxNumberIdentifier

Stored as ContactPoints

See https://hl7.org/fhir/R4/valueset-contact-point-system.html

If not present on the current element the VirtualAddressInformation are inherited from the SOR parent.

address[n]

Two addresses will be stored in FHIR.

PostalAddressInformation

And either an

VisitingAddressInformation or ActivityAddressInformation

PostalAddressInformation are mapped to an address using type = 'postal'.

Then a prioritized select of VisitingAddressInformation, ActivityAddressInformation is stored with type = 'physical'

http://filer.sst.dk/sor/docs/sorxml/v_2_0_0/SorXmlDocumentationV2.html describes inheritance of addresses in the SOR structure (translated to english):

  • If "HealthInstitution" doesn't have a "PostalAddressInformation" the address is inherited from the parent.

  • If "HealthInstitution" doesn't have a "VisitingAddresseInformation" the unit's "PostalAddressInformation" is used.

  • If "OrganizationalUnit" doesn't have a "PostalAddressInformation" the address is inherited from the parent (either a HI or OU).

  • If "OrganizationalUnit" doesn't have a "VisitingAddressInformation" the unit's "PostalAddressInformation" is used.

  • If "OrganizationalUnit" doesn't have a "AcvitivityAddressInformation" the unit's "VisitingAddressInformation" is used.

After applying the inheritance logic the values are copied to the FHIR model. Ie. addresses are not left blank in the FHIR model.

address[0].type

PostalAddressInformation are mapped to an FHIR address using type = 'postal'.

address[0].text

PostalAddressInformation.AdditionalAddressInformationText

address[1].type

Either an VisitingAddressInformation or ActivityAddressInformation stored with type = 'physical'

contact

N/A

Not created during import.

municipalityCode

PostalAddressInformation.MunicipalityCode

regionCode

PostalAddressInformation.RegionCode

providerIdentifier

ProviderIdentifier

Translates to the danish 'Ydernummer'

specialty

SpecialityIdentifier

eHealth Infrastructure imports from KOMBIT Fælleskommunalt (FK) Organisation

The eHealth Infrastructure imports organization information from the FK Organisation every night around midnight.

For the import to be performed a Service Agreement in KOMBIT Serviceplatform must be established per municipality.

The import performs the following:

  • Process all 98 municipalities given they have a Service Agreement.

  • For OrganisationEnhed to be imported they must have the KLE code ‘29.70.10 Telesundhed' or '29.70.20 Telemedicin' assigned as Opgaver as either udførende or ansvarlig.

  • Import and update information from each municipality individually

eHealth Environment

Service Agreements in place

KOMBIT Environment imported from

FK Organisation Service

Production

For all municipalities

PROD

https://prod.serviceplatformen.dk/service/Organisation

Non-production (e.g. EXTTEST)

For fewer municipalities (at the time of writing)

TEST

https://exttest.serviceplatformen.dk/service/Organisation

Organization discovery

For each municipality, the import starts by

  1. Search for all OrganisationEnhed having the KLE code ‘29.70.10 Telesundhed' or '29.70.20 Telemedicin' assigned as Opgaver as either udførende or ansvarlig.

  2. For all found OrganisationEnhed their parent organizational tree is found using the RelationListe.Overordnet attributes.

  3. For OrganisationEnhed not having a RelationListe.Overordnet the RelationListe.Tilhoerer attribute will be used to retrieve the Organisation.

  4. Then the Virksomhed is referenced by the Organisation's RelationList.Virksomhed attribute will be retrieved.

  5. Lastly, the referenced addresses will be retrieved from the Adresser service and Danish Adresse Register (DAR).

  6. The found Organisation and OrganisationEnhed resources are transformed into eHealth Organization resources and imported.

Data mapping overview

Data mapping from FK Organisation objects to FHIR Organization of profile ehealth-organization:

  • The Organisation identifier is stored as an Organization.identifier with system 'https://www.kombit.dk/sts/organisation'.

  • The OrganisationEnhed identifier is stored as an Organization.identifier with system 'https://www.kombit.dk/sts/organisation'.

  • The CVR Number defined on the Virksomhed is copied to all children in the organizational tree.

  • Relationships defining the organization trees are reflected in the Organization.partOf element.

  • (upcoming functionality) Address: Adresse resources with Rolle 'SOR-ID' a relationship to the related SOR organization is reflected in the Organization.relatedTo element.

  • Telecom: Adresse resources with Rolle 'Email' or 'Telefon' are stored as ContactPoints under the organization.telecom element.

  • Address: Adresse resources with Rolle 'Postadresse' are stored as Organization.address.

In case the resolution of the Address and telecom fails, it is logged and processing continues. This leaves the Address and telecom unchanged.

Establish the relationship between the FHIR Organization and the SOR-imported counterpart

A relationship between the municipal FHIR Organization and the SOR-imported counterpart must be established.

This relationship can be established in two ways:

  1. The customers provide mapping as MS Excel files to the Systematic AO team, which then triggers the relationship being created or

  2. FUT Infrastructure automatically creates the relationship during import from FK Organisation if the SOR code is available in FK Organisation.

FUT Infrastructure automatically establish the relationship during import from FK Organisation

If the SOR code is available in the FK Organisation, the Municipalities FK Organisation administrator registers the SOR kode in the FK Organisation system (as address of type SOR ID), and the FUT infrastructure will automatically create the relationship during import.

Systematics AO team establishes the relationship from MS Excel files provided by the customer

The customer provides organisation relationship file(s) containing mappings between KOMBIT STS Organization identifiers and SOR identifiers. The Systematic operation team will make the eHealth then process the file line-by-line and establish the relevant related-to relationships in the FHIR Organization resources.

The process:

  • The municipality creates a case against support with SOR mapping.

  • Systematic Application Operations (AO/SRE) carry out the task of loading SOR mapping.

  • Systematic reports back if there are errors or successful loading of SOR mapping.

  • No labels