FHIR Implementation Guide for the Norwegian Municipal Sector
0.3.0 -
FHIR Implementation Guide for the Norwegian Municipal Sector - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This chapter describes Norwegian context that municipal FHIR use must take into account:
no-basis as the national profiling baselineVelferdsteknologisk knutepunkt, VKP) and Patient's measurement data (Pasientens måledata, PMD)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 municipal service allocation (KPR KTT) 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 and ICD-11 | Used where clinically appropriate, but should not be confused with municipal service code systems. |
The table shows a selection of no-basis profiles that are often relevant in the municipal sector. Address and HumanName are data types; the others are resources. The full overview is available in the Simplifier project.
Practical reading guide:
Patient, Practitioner, PractitionerRole, Organization).Location, Appointment) and documentation (DocumentReference, Composition).MedicationStatement, AllergyIntolerance) when the content is actually clinical.| Resource/data type | 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. |
no-basis is the national set of base profiles. It is open and general, and intended for use across many applications in Norway.
The four municipal profiles inherit directly from standard FHIR R4. The hl7.fhir.no.basis#2.2.2 package has no base profiles for ServiceRequest, EpisodeOfCare, CarePlan or Encounter. Municipal profiling should still:
no-basis directly where possibleMustSupport in the municipal profiles in this version; other profiles may have their own requirementsno-basis and standard FHIRThe following references SHOULD use relevant no-basis profiles. The table shows where they fit in the municipal profiles. References are not restricted to these profiles by machine-enforced constraints.
Reference constraints use standard FHIR types, such as Reference(Patient). Validating a municipal profile therefore does not confirm that all referenced content conforms to no-basis. These constraints MAY be tightened in later versions when the need is established.
The table covers no-basis references. When supporting information or an outcome is a KPR functional assessment, the example uses standard Observation; see KPR KTT functional assessments.
MustSupport or bindings when necessary for interoperability.This IG should be read together with ongoing national work and documentation from concrete implementations, but it does not replace national information services or vendor service documentation.
| 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 0.3.0. Measurements may be included as supporting data in municipal follow-up. Follow PMD profiles and APIs for integration; a municipal functional assessment is not automatically a PMD measurement. |
| 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. |
| Open Aidn | Vendor-specific integration platform with FHIR R4 endpoints and OAuth 2.0 for integrations enabled for a municipality. | Demonstrates practical use of resources including Patient, EpisodeOfCare, Encounter, Observation and Task. Its documentation is an implementation example, not a national profile or a normative source for this IG. |
| 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:
no-kommune-ServiceRequest, 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.
This IG does not introduce new municipal code systems. It points to relevant national sources and demonstrates concrete use of code systems from KPR municipal service allocation (KPR KTT).
Especially relevant to build on
KPR municipal service allocation (KPR KTT):
Provides national code systems for service type, functional assessment, decisions and reporting. KPR KTT was previously referred to as KPR IPLOS and KPR health and care; the former IPLOS register was a separate register. See FHI's description of KPR KTT.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:
May provide a basis for sharing measurements and calculated scores using standard FHIR Observation. Using NEWS2 requires the measurements and scoring method to be described; this IG defines no NEWS2 profile.Practical consequence for this IG
CodeSystem resources or bindings.Numbers such as 9151 and 9111 identify code systems, not individual codes. Choose a code according to the information being shared and the agreement between the parties.
Service type in KPR municipal service allocation (9151) is relevant when the information actually describes a service in that code system:
| Element | What it describes |
|---|---|
ServiceRequest.code |
The service or assignment being requested. |
Encounter.serviceType |
The service within which a contact occurs. The contact form is described separately in Encounter.type. |
CarePlan.activity.detail.code |
An activity described directly in the plan. If the activity instead references a request, the service is described in ServiceRequest.code. |
EpisodeOfCare.type describes the nature of the episode and uses a source classification or text. In the example journey, 9151 is used in ServiceRequest.code and Encounter.serviceType; the plan references the request instead of repeating the service code.
The 9151 bindings use example strength: the value set demonstrates possible use without restricting permitted codes. ServiceRequest.code must still be populated; see binding and cardinality.
Contact form, plan type, service type, diagnosis and assessment result are distinct information and are coded separately.
KPR KTT functional assessments can be shared using the standard FHIR Observation resource. This guide defines no Observation profile. In the example, Encounter describes the assessment visit, while Observation contains the assessed domain and result. The request uses reasonReference for the assessment that directly justifies the service and supportingInfo for other relevant supporting material. The plan uses supportingInfo.
When the source is a KPR KTT functional assessment, the following code systems are used in Observation:
| Information | Relevant code system | Placement in the example |
|---|---|---|
| What was assessed | Functional domain (9111), such as personal hygiene or vision. | Observation.code |
| Result | Functional value (9165). Vision and hearing have separate scales: vision value (9166) and hearing value (9167). | Observation.valueCodeableConcept |
Each assessment has its own time and responsible practitioner or organization. The scales have different meanings and are not interchangeable. Other assessment methods may require other code systems or, for example, QuestionnaireResponse.
The example journey demonstrates specific codes, history, an absent result and reassessment. KPR KTT also includes code systems for private assistance, living situation, coercion and other reporting data. They are outside the four profiles because those data are not modelled here.
In FHIR, Coding.system identifies the code system and Coding.code the selected code. The examples use the code systems' OID URNs. Include Coding.version when the source has an identifiable version, and use a documented namespace for local codes. Multiple coding entries in one CodeableConcept must describe the same concept.
FinnKode and FHI's reporting guide are the sources for meaning, validity and reporting rules. The FHIR examples demonstrate interoperability and are not a KPR KTT reporting format. Example codes were checked on 1 September 2026.
identifier.system and identifier.value SHALL be used together.identifier.system SHOULD point to an official namespace (OID/URI) when a national identifier exists.HER-id SHALL NOT be used as the primary identifier for Organization, Practitioner, Location, HealthcareService or Endpoint in FHIR REST.
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 uses hl7.fhir.no.basis#2.2.2, as specified in the SUSHI configuration for both languages. 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.
Use FHI and FinnKode for current reporting requirements and code validity. The Directorate of Health guidance below also provides background on registration and functional assessment.