HL7 Norway
FHIR Implementation Guide for the Norwegian Municipal Sector
Shared starting point for understanding and consistent use of FHIR in municipal health and care services.
Norwegian

FHIR Implementation Guide for the Norwegian Municipal Sector
0.2.0 - ci-build NO

FHIR Implementation Guide for the Norwegian Municipal Sector - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Norwegian Context

Purpose And Role

This chapter describes Norwegian context that municipal FHIR use must take into account:

  • no-basis as the national profiling baseline
  • relevant national services such as Welfare Technology Hub (Velferdsteknologisk knutepunkt, VKP) and Patient's measurement data (Pasientens måledata, PMD)
  • municipal code systems, classifications and reporting sources
  • principles for further municipal profiling

Norwegian base profiles (no-basis) are the national starting point for FHIR profiling in Norway. The profiles are intended as an open baseline for further profiling in concrete use cases.

Short version:

Topic Meaning for this IG
no-basis Used as the national base layer before new municipal variants are established.
VKP, municipal interoperability services and PMD Cover national data flows and services where relevant. This IG does not replace them.
KPR (Kommunalt pasient- og brukerregister), IPLOS (Individbasert pleie- og omsorgsstatistikk) and ICF (International Classification of Functioning, Disability and Health) Important semantic sources for further work on service type, decision, function and need for assistance.
ICPC-2, ICD-10, ICD-11 and SNOMED CT Used where clinically appropriate, but should not be confused with municipal service code systems.

Where no-basis Is Published

Overview Of Base Profiles (Guidance)

The table shows a curated selection of no-basis profiles that are often relevant in the municipal sector. The full overview is available in the Simplifier project.

Practical reading guide:

  • Start with patient and actors (Patient, Practitioner, PractitionerRole, Organization).
  • Add context (Location, Appointment) and documentation (DocumentReference, Composition).
  • Use clinical resources (MedicationStatement, AllergyIntolerance) when the content is actually clinical.
Resource no-basis profile Typical relevance
Patient no-basis-Patient When data concerns a patient in a service episode, follow-up or documentation.
Person no-basis-Person When a person should be described across roles/systems without the context being a concrete patient contact.
Practitioner no-basis-Practitioner When identity of an individual service provider is needed.
PractitionerRole no-basis-PractitionerRole When responsibility or function must be linked to organization and role, not only to a person.
Organization no-basis-Organization When unit, organization and organizational responsibility should be described.
RelatedPerson no-basis-RelatedPerson When next of kin or related persons are relevant in follow-up and interoperability.
Location no-basis-Location When service site or physical location matters for a contact or intervention.
Appointment no-basis-Appointment When a contact is planned before a completed Encounter.
DocumentReference no-basis-DocumentReference When decisions, letters or other documentation should be shared as a reference to document content.
Composition no-basis-Composition When the document is structured into sections, for example a journal note or structured decision.
Endpoint no-basis-Endpoint When technical addresses/endpoints for interoperability must be published and managed.
HealthcareService no-basis-HealthcareService When the service offering should be described independently of a concrete contact.
Procedure no-basis-Procedure When a performed intervention or procedure should be shared as its own resource.
Address no-basis-Address When Norwegian address format must be used consistently across resources.
HumanName no-basis-HumanName When names should be represented consistently according to Norwegian naming practice.
Medication no-basis-Medication When the medication object itself should be described.
MedicationStatement no-basis-MedicationStatement When information about actual medication use for a patient should be shared.
AllergyIntolerance no-basis-AllergyIntolerance When allergies or intolerances must be available in follow-up and decision support.
Substance no-basis-Substance When substances must be identified across use, for example in allergy and medication contexts.

Use Of no-basis In This IG (Normative)

  • Where a no-basis profile exists, it SHALL be used as the starting point.
  • Derived profiles SHOULD specify municipal context and requirements without breaking national assumptions.
  • Deviations from no-basis SHOULD be documented explicitly in the guide.

Relationship Between no-basis And Municipal Profiles

no-basis is the national set of base profiles. It is open and general, and intended for use across many applications in Norway.

The municipal profiles in this IG are derived domain profiles. They should therefore:

  • reuse no-basis directly where possible
  • only tighten fields that are important for municipal interoperability
  • not use MustSupport in this version, since the profiles are early and should remain close to no-basis
  • avoid new local variations when the same need can be covered by no-basis and standard FHIR

no-basis References In Municipal Profiles

The following references SHOULD use no-basis profiles in practice. The requirements are documented in profile descriptions and narrative, not as machine-enforced bindings, to preserve compatibility with systems that use standard FHIR types or locally derived profiles.

Field Recommended no-basis profile
no-kommune-Encounter.subject no-basis-Patient
no-kommune-Encounter.participant.individual no-basis-Practitioner, no-basis-PractitionerRole or no-basis-RelatedPerson
no-kommune-Encounter.location.location no-basis-Location
no-kommune-Encounter.serviceProvider no-basis-Organization
no-kommune-EpisodeOfCare.patient no-basis-Patient
no-kommune-EpisodeOfCare.managingOrganization no-basis-Organization
no-kommune-EpisodeOfCare.careManager no-basis-Practitioner or no-basis-PractitionerRole
no-kommune-CarePlan.subject no-basis-Patient
no-kommune-CarePlan.author no-basis-Practitioner, no-basis-PractitionerRole or no-basis-Organization
no-kommune-CarePlan.supportingInfo no-basis-DocumentReference
no-kommune-CarePlan.activity.reference (appointment) no-basis-Appointment
no-kommune-CarePlan.activity.outcomeReference no-basis-DocumentReference when the outcome is a document, and no-basis-Procedure when the outcome is a performed intervention/procedure
no-kommune-ServiceRequest.subject no-basis-Patient
no-kommune-ServiceRequest.requester no-basis-Practitioner, no-basis-PractitionerRole or no-basis-Organization
no-kommune-ServiceRequest.performer no-basis-Practitioner, no-basis-PractitionerRole, no-basis-Organization, no-basis-HealthcareService or CareTeam
no-kommune-ServiceRequest.supportingInfo no-basis-DocumentReference where the supporting information is a document

Machine-enforced reference constraints in the profiles use base FHIR types, such as Reference(Patient), so validation works regardless of whether the receiving system supports no-basis profiles. no-basis is recommended in narrative and profile description, and MAY be tightened into machine-enforced requirements in future versions when the profiles are more tested.

Principles For Further Profiling (Normative)

  • no-basis is a national starting point, not a complete final model for all use cases.
  • Municipal derived profiles MAY tighten cardinality and may later use MustSupport or bindings when necessary for interoperability.
  • Such tightening SHOULD be justified by concrete use cases and documented as deviations from no-basis.

Relationship To VKP, PMD And Other Norwegian Work

This IG should be read together with ongoing national work, but it does not replace national information services or platforms.

Initiative Role Relationship to this IG
no-basis National base profiles for FHIR in Norway This IG builds on no-basis and defines municipal domain profiles where municipal context must be clarified.
VKP / APIs for welfare technology and digital home follow-up Welfare Technology Hub (Velferdsteknologisk knutepunkt, VKP) offers retrieval from electronic health record (EHR) systems and documentation write-back to EHR systems for welfare technology solutions and digital home follow-up. This IG does not describe VKP flows, access control or documentation write-back. It describes municipal context around episode, plan and contact.
Patient's measurement data (PMD) National information service for measurement data. PMD exposes a FHIR API for Observation. This IG does not define a separate measurement data profile in v0.2. Measurements may be included as supporting data in municipal follow-up.
Oslo municipality / welfare technology and digital home follow-up Municipal service development, handbooks, testing and use of data from welfare technology. The experience is relevant for use cases and examples, especially digital home follow-up, but this IG does not turn Oslo models into national requirements.
Oslo municipality / NO Municipal API Municipal FHIR work with profiles and API pages for resources such as Encounter, CarePlan, EpisodeOfCare, Observation and DocumentReference. Used as experience and inspiration. This IG lifts the work into a more general municipal starting point and builds on no-basis.
Municipal interoperability platform / municipal interoperability services Platform and solution pattern for standardized interoperability services, with the Norwegian Health Network (Norsk helsenett, NHN) as a central platform actor. This IG can contribute semantic clarification and municipal profiles that may be used in such contexts.

Practical consequence:

  • Use no-basis for Norwegian base profiles.
  • Use VKP, PMD or other national services where they actually cover the data flow and service need.
  • Use this IG to describe municipal follow-up context: no-kommune-EpisodeOfCare, no-kommune-CarePlan and no-kommune-Encounter.

VKP should be described as work in development, not only as one static solution. Norsk helsenett (NHN) describes VKP as a data sharing service for welfare technology and digital home follow-up, with APIs for search/retrieval, safety and coping, and digital home follow-up. NHN also describes municipal interoperability services as standardized services for documentation write-back and interoperability. This means this IG should focus on semantics and municipal profiles without competing with platform and service work.

Oslo municipality is especially relevant as experience because it has worked systematically with welfare technology, digital home follow-up, digital supervision, digital medication support and use of data from welfare technology services. Oslo municipality's published NO Municipal API also shows that several of the same FHIR resources are practically relevant in a municipal context, including Encounter, CarePlan, EpisodeOfCare, DocumentReference and Observation.

This supports the need for a general municipal FHIR IG that can describe episode, plan, responsibility and contact around measurement data and welfare technology. At the same time, this IG should not be presented as a copy of the Oslo work. The ambition is a shared municipal starting point that can reuse the experience, while being clearly anchored in no-basis and broader Norwegian context.

Relevant Code Systems And Classifications

This IG does not introduce new municipal code systems in the first version. However, some classifications and registration sources are especially relevant as a semantic background for further work.

Municipal code systems matter because many municipal information needs concern service type, decision, functional level, need for assistance, interventions and reporting. This guide should therefore point to relevant code systems and classifications, but not copy them into new FHIR code systems before the need has been clearly clarified.

Especially relevant to build on

  • KPR (Kommunalt pasient- og brukerregister) and registration of municipal health and care data: Provides a national conceptual basis for municipal services, service codes, decisions and reporting requirements. This is especially relevant for further work on decision, service type, scope, start, end and municipal service context.
  • IPLOS (Individbasert pleie- og omsorgsstatistikk): IPLOS concepts and the history around reporting of health and care data remain important for municipal understanding of function, need for assistance and service type. In further FHIR work, IPLOS/KPR concepts should be assessed before new local municipal code systems are established.
  • ICF (International Classification of Functioning, Disability and Health): Relevant as a conceptual basis for function, need for assistance, goals and follow-up.
  • ICD-10, ICD-11 and ICPC-2: Relevant when municipal systems already use diagnosis, reason-for-encounter or problem codes as a basis for follow-up. ICPC-2 is especially relevant in primary care and GP context, but is not a municipal service code system.
  • NEWS2 (National Early Warning Score 2) and similar measurement sets: Relevant for sharing measurements through Observation, especially in work on digital home follow-up and welfare technology.
  • SNOMED CT: May be relevant where nationally anchored terminology use exists, but should not be used to establish local municipal code systems without clarified need and governance.

Practical consequence for this IG

  • We should use these sources as professional and semantic references in mapping and further profile development.
  • We should not copy them uncritically into new FHIR CodeSystem resources or bindings in an early, general municipal IG.
  • Before new municipal FHIR code systems are established, existing KPR/IPLOS, ICF, International Classification of Primary Care (ICPC-2), International Classification of Diseases (ICD-10 and ICD-11), SNOMED CT and relevant national code systems should be assessed.
  • If a separate profile or more precise model for municipal decision is developed later, KPR concepts and registration requirements are a natural place to start.

Identifiers And HER-id (Normative)

  • For business identifiers, identifier.system and identifier.value SHALL be used together.
  • identifier.system SHOULD point to an official namespace (OID/URI) when a national identifier exists.
  • If no national identifier exists, a local identifier MAY be used, but with a stable system URI and clear documentation.
  • HER-id SHALL NOT be used as the primary identifier for Organization, Practitioner, Location, HealthcareService or Endpoint in FHIR REST.

Updates And Versioning (Guidance)

no-basis profiles are maintained by HL7 Norway and published on Simplifier. Always refer to the current version in the Simplifier project when updating this IG.

This IG currently has a technical dependency on hl7.fhir.no.basis as specified in sushi-config.yaml. The package version used in this build is the no-basis package version, not a separate version of this municipal IG. Before a release or consultation, the current no-basis version SHOULD be checked against HL7 Norway's published package overview, and any changes in no-basis SHOULD be assessed explicitly in the changelog.

References