Managing and Using Organization, CareTeam and Practitioner

 

Origin and Use of Organization

Most FHIR Organizations in the eHealth Infrastructure are automatically created and updated as described in Importing and updating Organization information from SOR and FK-Organisation into eHealth Infrastructure. Most organisations including municipal ones are imported from the Health Organisation Registry (SOR), but for municipal organisations, separate FHIR Organization resources are created as a result of importing from the municipal KOMBIT system STS-ORG. Depending on how municipal organisations are registered in SOR and STS-ORG, this can lead to duplicate FHIR Organization for municipal organisations. As no source is available for SSL organisation data, these must be maintained manually.

The different types of organisations and their use are shown in the table below.

Type

Origin

Use

Type

Origin

Use

Regional

SOR

General

General Practitioner

SOR

General

Municipal

SOR

In CDA documents and preferred in audit logging (registering of Practitioner’s actions and access to Patient data) to MinLog2 - see Architecture and Domains | System Context of eHealth Infrastructure (see explanation below).

Other

SOR

General

Municipal

FK Organiation

General, but not directly in CDA documents (see explanation below)

SSL Organization

Manual

Limited to login and security context and managing organization for SSL CareTeam.

General use covers:

As will be apparent on subpages, the described duality in origin must be taken into account when finding and using Organization.

On Use of Municipal Organisations Originating from SOR

A municipal employee (Practitioner) will use the eHealth Infrastructure in a municipal organisational context. The organisational context is designating a municipal-type organisation with origin in STS-ORG.

When Patient data is archived as a CDA document in a national document sharing infrastructure, see Behind the Scenes | Sharing through Registering Documents in National Document Sharing Infrastructu..., a municipal organisation must be designated using its SOR identifier. Therefore, CDA document assembly involves traversing from a municipal organisation of STS-ORG origin to its possible counterpart with SOR origin.

When a municipal employee (Practitioner) creates, alters or accesses Patient data, it is audit-logged automatically by registering an entry in the national MinLog2 service. This way, a citizen can determine that the employee has acted on the citizen’s data, for instance, through the citizen portal sundhed.dk. The registering of entry has a preference for organisational context identified by the SOR identifier.

For both these uses, a relation must be established between the municipal organisation of STS-ORG origin and a counterpart with SOR origin. Currently, this is a manual process which involves capturing the mapping from municipal organisation identifier to SOR code in a file and loading it into the infrastructure, as described in Load relationships between organisations imported from KOMBIT STS Organisation and SOR.