Finland's Kanta and Nordic FHIR migration

All four countries are converging on FHIR R4, each from a different legacy - which is why the region calls for an integration layer rather than a replacement of the existing systems.

The EHDS deadlines apply across all four - patient summaries and e-prescriptions flowing through MyHealth@EU by March 2029 - as the EHDS checklist lays out, so the national migrations and the European one converge on the same FHIR R4 target.

Kanta is one of the longest-running national systems in the world - electronic prescriptions and the patient data repository run on HL7 v3 messaging and CDA R2 documents, standards that are being phased out internationally. Kelain and the Kanta PHR introduced FHIR interfaces, and new work follows the FHIR direction while the v3 core keeps operating.

For integration teams the consequence is a long transition in which both stacks are live - systems that post CDA documents to Kanta and systems that consume FHIR from newer interfaces coexist, and an integration layer that speaks both keeps each application unaware of the other side's format.

Danish healthcare messaging runs through MedCom standards connecting general practice, hospitals, municipalities and laboratories - historically OIOXML and EDIFACT messages. MedCom is replacing them with FHIR messaging standard by standard - hospital notifications, municipal care communication and onward - each migration a translation project between a legacy message format and FHIR resources.

That translation is integration-layer work by definition - receive the legacy format, map, emit FHIR - and it is the same service pattern as the HL7 v2 to FHIR mapping, with a different source format on the left-hand side.

The service below is the shape of every Nordic bridge - a legacy message arrives over a channel, Python maps it, a FHIR server receives the result. Here the source is an HL7 v2 feed from a hospital system, the pattern is identical when the source is a MedCom message or a CDA document parsed with any Python XML library.

# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

# The Finnish personal identity code system
hetu_system = 'urn:oid:1.2.246.21'

class NordicBridge(Service):
    name = 'demo.nordics.bridge'

    def handle(self) -> 'None':

        # A legacy feed, parsed by its channel ..
        msg = self.request.input

        # .. the national identifier and demographics ..
        hetu = msg.pid.patient_identifier_list.id_number
        family_name = msg.pid.patient_name.family_name

        # .. become a FHIR Patient in the national shape.
        client = self.fhir['FHIR.Kanta']

        patient = client.resource('Patient',
            identifier = [{'system': hetu_system, 'value': hetu}],
            name = [{'family': family_name}],
        )

        patient.save()

National profiles put their specifics into identifiers, extensions and slices - path access with matchers reads them without positional assumptions, the same way the German and UK pages on this site handle their national identifier systems.