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

Modelling and Profiling

This page collects modelling and profiling guidance for municipal use of FHIR.

The goal is to make it easy to move from a need to the right resource, the right profile and the right links between data.

Binding Principles

  • Where a no-basis profile exists, it SHALL be used as the starting point.
  • Municipal derived profiles SHOULD be small, precise and justified by use cases.
  • Municipal profiles SHALL NOT introduce new local resource models when standard FHIR resources cover the need.
  • Deviations from no-basis or national practice SHALL be documented explicitly.
  • Resources that describe the same service episode SHOULD be linked with consistent references.
  • Each profile SHOULD have at least one non-normative example.

Design Choices For Municipal Profiles

These profiles are intended as a careful first iteration of municipal domain profiles, not as new base profiles.

  • The profiles build on no-basis where relevant national base profiles exist.
  • The profiles introduce only a few additional requirements that are useful across municipalities.
  • Mandatory fields are kept to a low level to preserve local flexibility.
  • MustSupport is not used in this version. Important minimum requirements are instead expressed through cardinality and references.
  • The profiles do not introduce new national code systems in this version.
  • The profiles define no custom extensions in this version. Needs for extensions SHOULD be documented with a concrete use case and assessed against standard FHIR, no-basis and other Norwegian work first.

Learning Points From Existing Work

Other municipal work points in the same direction as this IG. We use this as inspiration, without making the guide dependent on more specialized profiles or code systems at this stage.

  • digital contact can use Encounter.class = VR when this is appropriate
  • CarePlan can be used broadly for different types of municipal follow-up
  • identifier can be useful when a municipality needs a stable business identifier, but it is not made mandatory

From Need To Data

Use this simple logic:

  1. Is a service requested? Use ServiceRequest.
  2. Should follow-up be planned? Use CarePlan.
  3. Should a completed contact be documented? Use Encounter.
  4. Do you need shared context over time? Use EpisodeOfCare.
  5. Should a decision or supporting document be shared? Use DocumentReference.

Visual Overview

The same municipal episode can contain several requests and several contacts. The diagram shows a recommended starting pattern, not a complete process flow. The two requests in the figure are examples showing that the same episode can be linked to several assignments. The main point is that ServiceRequest describes what was requested, while EpisodeOfCare, CarePlan and Encounter describe different aspects of the same municipal follow-up. Common patient references are omitted from the figure so the profile and resource relationships are easier to see.

Visual overview of the recommended municipal modelling pattern Diagram showing supporting documents, requests, episode, plan, completed contacts, planned contact and supporting data. DocumentReferenceno-basis-DocumentReferencedecision or supporting document no-kommune-ServiceRequesthome nursing request no-kommune-ServiceRequestrehabilitation request no-kommune-EpisodeOfCaremunicipal follow-up episode no-kommune-CarePlanfollow-up plan no-kommune-Encountershort-term stay no-kommune-Encounterhome visit no-kommune-Encounterphone/video follow-up no-kommune-Encounterevaluation meeting Appointmentno-basis-Appointmentplanned contact Observationmeasurement/assessment arrows show recommended model context, not complete FHIR reference direction

The figure above is a pedagogical model sketch. It shows reading direction from supporting documents and request to follow-up over time, but it is not a complete technical reference diagram. Common references to Patient and actor resources are not drawn. The actual FHIR reference direction is shown in the pattern below.

Technical Reference Pattern

In the diagram below, arrow direction means that the resource at the start of the arrow has a reference field pointing to the resource at the end of the arrow. Solid arrows show central links in this starting pattern. Dashed arrows show supporting information, planned activities or outcomes used when relevant.

Technical reference pattern for municipal FHIR profiles Diagram showing actual FHIR reference direction between ServiceRequest, EpisodeOfCare, Encounter, CarePlan, Appointment, DocumentReference and outcome resources. referralRequest episodeOfCare basedOn activity.reference activity.reference activity.outcomeReference supportingInfo supportingInfo basedOn appointment no-kommune-EpisodeOfCareepisode context no-kommune-ServiceRequestrequest or assignment DocumentReferenceno-basis-DocumentReferencesupporting document no-kommune-Encountercompleted contact no-kommune-CarePlanplan, goals and activities Appointmentno-basis-Appointment Outcome or supporting dataEncounter, Observation, Procedureor DocumentReference central links used when relevant

Technically, this means:

Resource with reference Field Points to Use
EpisodeOfCare referralRequest ServiceRequest Collects one or more requests in the same episode context.
Encounter episodeOfCare EpisodeOfCare Links a completed contact to a municipal episode.
Encounter basedOn ServiceRequest Shows which request or assignment the contact follows from.
Encounter appointment Appointment Links a completed contact to a planned appointment when the contact fulfills a known Appointment.
Appointment basedOn ServiceRequest Links a planned contact to the request or assignment it is allocated to.
CarePlan activity.reference ServiceRequest, Task or Appointment Links planned activities to a request, task or appointment.
CarePlan activity.outcomeReference Encounter, Observation, Procedure or DocumentReference Points to the result of a planned activity where relevant.
ServiceRequest or CarePlan supportingInfo DocumentReference or Observation Links supporting documents, measurements or assessments to a request or plan.

In FHIR R4, ServiceRequest has no direct reference to EpisodeOfCare, and CarePlan also has no direct reference to EpisodeOfCare. Episode context is therefore maintained through EpisodeOfCare.referralRequest, Encounter.episodeOfCare, Encounter.basedOn, optional Encounter.appointment and shared patient context.

Planned contact should normally use Appointment. In this IG there is no separate no-kommune-Appointment profile; planned contact should use no-basis-Appointment where the national base profile is applicable.

When a planned contact follows from a request or assignment, Appointment.basedOn SHOULD point to the relevant ServiceRequest. When the contact is later documented as completed, Encounter.appointment SHOULD point back to Appointment if the planned appointment is shared as a separate resource. Appointment.supportingInformation can still be used for additional context such as a supporting document, assessment or other supporting data.

No-basis is used as the foundation around the pattern: Patient, Practitioner, PractitionerRole, Organization, RelatedPerson, Location, HealthcareService, Appointment, DocumentReference and Procedure should use no-basis profiles where they exist. The municipal profiles in this IG are separate domain profiles for the parts not covered as base profiles in the no-basis package: ServiceRequest, EpisodeOfCare, CarePlan and Encounter.

Which Profile To Use When

Profile When it is used Practical minimum Interoperability
no-kommune-Encounter When a concrete contact has been completed (physical, digital, phone) status, class, subject, type, period.start, serviceProvider Linked to request via basedOn and to episode via episodeOfCare
no-kommune-EpisodeOfCare When the municipality has a coherent follow-up episode status, patient, period.start, managingOrganization Collects contact, plan and responsibility in the same episode
no-kommune-CarePlan When goals, interventions and planned follow-up should be described status, intent=plan, subject, period.start, author Connects decision/request to practical follow-up
no-kommune-ServiceRequest When a referral, assignment or order should trigger municipal follow-up status, intent, code, subject, requester Separates request/assignment from decision document and local workflow

Normative use:

  • Municipal contact SHOULD use no-kommune-Encounter.
  • Municipal episode SHOULD use no-kommune-EpisodeOfCare.
  • Municipal follow-up over time SHOULD use no-kommune-CarePlan.
  • Municipal request or assignment SHOULD use no-kommune-ServiceRequest when it is shared as part of this IG.

In practice this means:

  • Use the profiles when data is shared or used as a common basis for interoperability.
  • Do not try to model the complete local journal structure in these profiles.
  • Keep local adaptations outside the profiles as far as possible.

Modelling Rules Per Resource

Encounter

  • Encounter SHALL represent an actual contact.
  • Encounter SHOULD state contact form in type and context in class.
  • For digital or virtual contact, class SHOULD normally use VR when this is appropriate.
  • Encounter SHOULD have period.start and responsible municipal unit in serviceProvider.
  • Encounter SHOULD include participant and location where relevant.
  • Encounter.location is optional and should normally be used for physical contact. For phone or video contact, location may be omitted.
  • Planned contacts MAY be modelled as Appointment and linked when completed using Encounter.appointment.
  • Nursing home stays, short-term stays and other stay situations MAY be modelled as Encounter when the need is to describe the actual stay, location and time period.

Appointment

  • Appointment SHOULD be used when a contact is planned before it has happened.
  • Appointment SHOULD use basedOn to point to the ServiceRequest when the appointment follows from a request or assignment.
  • Appointment MAY use supportingInformation for supporting documents, observations or other information that supports the planned contact.
  • no-basis-partof MAY be used when several Appointment resources represent a main appointment with sub-appointments, but is not needed for ordinary single planned municipal contacts.
  • When the contact has happened, the completed activity SHOULD be represented as Encounter. The Encounter MAY point to the same ServiceRequest through Encounter.basedOn and to the planned appointment through Encounter.appointment.

EpisodeOfCare

  • EpisodeOfCare SHOULD be used for coherent follow-up over time.
  • EpisodeOfCare SHALL have clear status and time frame (period).
  • EpisodeOfCare SHOULD have responsible organization in managingOrganization.
  • EpisodeOfCare SHOULD NOT be used alone to describe a concrete contact or a concrete stay. Use Encounter for what actually happens, and link to EpisodeOfCare when it is part of broader municipal follow-up.

CarePlan And CareTeam

  • CarePlan SHOULD be used for goals, interventions and follow-up over time.
  • CarePlan.intent SHOULD be plan when the profile is used as a follow-up plan.
  • CarePlan in this IG is intentionally broad. It should work in several municipal contexts without assuming fully structured plan content.
  • CarePlan.category can be used to distinguish, for example, service overview, intervention plan and visit plan.
  • goal, addresses (problem/condition) and activity (intervention) are often relevant elements, but are not mandatory in this first version.
  • CarePlan.activity.reference SHOULD be used to link the plan to ServiceRequest, Task or Appointment when relevant for follow-up.
  • CareTeam SHOULD be used when multiple roles or units share responsibility.

Observation

  • Observation SHOULD be used for structured measurement and assessment when the information is shared in machine-readable form.
  • This is especially relevant for vital signs, National Early Warning Score 2 (NEWS2)-like assessments and patient-generated measurement data from digital home follow-up or welfare technology.
  • IPLOS/KPR-like functional assessments SHOULD be visible as municipal decision support when they are used to justify service need, a plan or further follow-up. A single structured functional assessment, for example activities of daily living (ADL), assistance need, cognitive function or coping, SHOULD normally be represented as Observation.
  • When a complete assessment form or questionnaire should be shared as a whole, QuestionnaireResponse MAY be used. Relevant individual findings from the assessment can additionally be shared as Observation when they should be searchable, visible or usable as decision support across systems.
  • Functional assessments can be linked through ServiceRequest.reasonReference or ServiceRequest.supportingInfo when they justify a request, and through CarePlan.supportingInfo when they explain goals, interventions or planned follow-up.
  • This IG does not define its own IPLOS code system in v0.2. Implementations SHOULD use official national code systems or document local codes clearly in Observation.code/QuestionnaireResponse.questionnaire.
  • In this version, Observation is used as a supporting resource and example, not as a separate municipal profile.
  • Measurement data shared through Welfare Technology Hub (Velferdsteknologisk knutepunkt, VKP) or Patient's measurement data (Pasientens måledata, PMD) SHOULD follow the VKP/PMD information model. This IG describes the municipal context around the measurements, such as plan, episode, contact and responsible unit.

ServiceRequest And Task

  • ServiceRequest SHOULD be used for request/initiation.
  • no-kommune-ServiceRequest SHOULD be used when the request or assignment is shared as municipal follow-up context.
  • ServiceRequest is not a decision document. Decisions SHOULD be represented as DocumentReference and linked as supporting information where relevant.
  • Task MAY be used for workflow related to ServiceRequest.

Decisions And Documentation

  • Decisions SHOULD be represented as DocumentReference.
  • Composition MAY be used when the document should be structured into sections.

Reference Chain In A Municipal Episode

Recommended flow:

  1. Decision and request: DocumentReference + ServiceRequest
  2. Episode context: profile no-kommune-EpisodeOfCare on EpisodeOfCare
  3. Plan: profile no-kommune-CarePlan on CarePlan
  4. Delivery: profile no-kommune-Encounter on Encounter

Links that should be in place:

  • EpisodeOfCare.referralRequest SHOULD point to the relevant ServiceRequest when an episode follows from one or more requests.
  • Encounter.episodeOfCare SHOULD point to the relevant EpisodeOfCare.
  • Encounter.basedOn SHOULD point to the relevant ServiceRequest.
  • Encounter.appointment SHOULD point to the relevant Appointment when the contact fulfills a known planned appointment.
  • CarePlan SHOULD be linked to ServiceRequest through activity/reference when the activity traceably follows from the request.

Examples In This IG

For a workflow-oriented overview of how the example instances fit together, see Examples.

The examples are guidance.

Relation To no-basis

Central no-basis profiles in this context:

References And Modelling Choices

Modelling choices are inspired by: