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

Use cases

This page describes prioritized use cases for municipal interoperability and how they are used in this IG.

The use case page is guidance. It shows recommended use of profiles, searches and examples, but does not replace normative profile requirements. Normative requirements are found in the profiles, Conformance, Modelling and profiling and API.

The goal is that readers with limited FHIR experience can quickly see:

• which municipal interoperability need is being solved
• which actors typically interact
• which information should be possible to retrieve
• which FHIR resources and municipal profiles are normally used

How To Use The Use Cases

The use cases are written for two practical roles:

• a vendor exposing municipal data from an electronic health record (EHR), professional system, EHR platform or integration layer
• a vendor consuming municipal data in a user interface, decision support tool, interoperability service or other municipal health solution

Here, integration layer means middleware or an API platform that exposes or transforms data between municipal source systems and consuming services. It does not mean the Norwegian Summary Care Record (Kjernejournal).

For each use case, an implementation should be able to answer four questions:

Question	What the vendor should clarify
Which situation is this?	Discharge, stay, ongoing follow-up, digital follow-up or decision/request
Which resources must be findable?	Typically EpisodeOfCare, Encounter, CarePlan, DocumentReference and ServiceRequest
Which searches must the client support?	Patient-oriented searches returning a standard FHIR Bundle
How are the resources connected?	References between patient, episode, contact, plan, request and supporting documents

This means that a vendor does not need to support the whole IG at once. It is better to implement one limited use case well than to support many resources without clear context.

Overview And Starting Points

This IG uses the following resources and profiles:

When you want to describe	Use FHIR resource	Municipal profile in this IG
Municipal follow-up over time	EpisodeOfCare	no-kommune-EpisodeOfCare
A plan for goals, interventions or further follow-up	CarePlan	no-kommune-CarePlan
An actual completed contact, such as home visit, phone call or meeting	Encounter	no-kommune-Encounter
A request, referral or assignment	ServiceRequest	no-kommune-ServiceRequest
A document, such as decision, discharge summary or journal note	DocumentReference	no-basis where relevant
A measurement or assessment	Observation	No separate municipal profile in this version

The municipal profiles are a shared minimum for interoperability. They are not intended to describe the full internal information model of a GP, nursing home or home care service.

For measurement data from digital home follow-up and welfare technology, this IG should be read together with Welfare Technology Hub (Velferdsteknologisk knutepunkt, VKP) and Patient's measurement data (Pasientens måledata, PMD). This IG describes the municipal context around measurements, not an alternative measurement data model.

Three Main Use Cases

This IG uses three high-level use cases as its starting point:

Main use case	What it covers	Typical example variants
Discharge and follow-up	Transition from specialist health service, rehabilitation, short-term stay or other institution to further municipal follow-up	Hospital to home care, rehabilitation center to home care, hospital to nursing home/short-term stay
Planned municipal follow-up	Ongoing municipal plan, contacts, assessments and evaluation in health and care services	Home nursing and GP, nursing home and physician, rehabilitation team, digital home follow-up as part of a municipal plan
Service need, decision and request	Municipal service need, decision, request/assignment and link to practical follow-up	Decision on health and care services, request to delivery unit, changed need requiring reassessment

The example variants are not an exhaustive priority list. They show how the same main patterns may be used in different municipal situations without making the IG a complete catalog of all municipal services.

Implementable Starting Variants

For vendors getting started, the broad main use cases should be broken into small, testable variants:

Starting variant	Primary resources	Minimum that should work	Do not solve first
Nursing home stay or short-term stay	Encounter, Location, Organization, Patient	Find active or recent stay, place, period and responsible unit	The full internal workflow of the institution
Home care after discharge	EpisodeOfCare, CarePlan, Encounter, DocumentReference	Find active episode, plan and first municipal contacts after discharge	Complete rehabilitation model or full journal structure
Digital home follow-up	CarePlan, Encounter, Observation	Show municipal plan/contact around measurements, while measurement data follows VKP/PMD where used	A competing measurement data model
Decision to request	DocumentReference, ServiceRequest, CarePlan	Separate decision/supporting document from request and practical follow-up	Full case handling process

This enables stepwise implementation. A solution does not need to support all municipal resources before it can provide value.

Shared Implementation Expectations

The searches in the use cases should behave consistently across vendors:

• Successful search returns Bundle.type=searchset.
• No matches returns an empty Bundle, not an error.
• Request errors return OperationOutcome.
• Clients should not treat absence of one resource as proof that the whole use case is invalid. A solution may for example start with Encounter and CarePlan even if EpisodeOfCare is added later.

Connections vendors should prioritize:

From	To	Use when
Encounter.subject	Patient	Always for municipal contact or stay
Encounter.episodeOfCare	EpisodeOfCare	The contact is part of a municipal episode
Encounter.basedOn	ServiceRequest	The contact follows from a request or assignment
Encounter.appointment	Appointment	The contact fulfills a known planned appointment
Appointment.basedOn	ServiceRequest	The planned contact follows from a request or assignment
CarePlan.subject	Patient	Always for a municipal plan
CarePlan.activity.reference	ServiceRequest	The plan shows how a request is followed up
CarePlan.supportingInfo	DocumentReference or Observation	The plan is supported by documents, assessments or measurements

Use Case 1: Discharge And Follow-Up

Purpose

Ensure continuity in transitions between levels of care with clear episode context, responsible municipal unit and plan for further follow-up.

Need Covered By This Use Case

The municipality needs to quickly understand what needs follow-up, who is responsible and which supporting documents exist when the patient moves from one service setting to another. Without shared structure it becomes unclear whether the information concerns the hospital stay, a rehabilitation stay, a short-term stay or the municipal follow-up that starts afterwards.

This use case can also be read as a FHIR-oriented view of information needs that are familiar from Norwegian care and coordination message flows (pleie- og omsorgsmeldinger, PLO) between specialist health care and municipal services. The IG does not replace PLO message exchange, but it shows how the same kind of follow-up context can be exposed as FHIR resources.

Typical Situation

A patient is discharged from hospital after a hip fracture. Further follow-up may take place in home care, a short-term unit, nursing home or municipal rehabilitation team. The main point is that the receiving municipal service needs the same type of minimum information: episode context, plan, responsible unit, supporting documents and completed contacts.

Actors

Role	Example
Sender	Hospital, rehabilitation center, short-term unit or other institution
Receiver	Home care, nursing home, short-term unit or municipal rehabilitation service
Patient	Person needing follow-up at home
Other possible actors	Next of kin, GP, physiotherapist, occupational therapist

What The Receiver Needs To Know

• That the patient has been discharged and needs municipal follow-up.
• What the follow-up concerns.
• Which period the follow-up concerns.
• Which municipal unit is responsible.
• Which documents are relevant, such as discharge summary or decision.
• Which contacts have already been completed in the municipality.

Recommended FHIR Use

Information	FHIR resource	Comment
Municipal follow-up after discharge	no-kommune-EpisodeOfCare (EpisodeOfCare)	Collects municipal follow-up over time.
Plan for further follow-up	no-kommune-CarePlan (CarePlan)	Shows interventions, goals, plan period and responsibility.
Planned follow-up contact	Appointment	Used when a visit, control or other contact is planned but not yet completed. Use no-basis where applicable.
First home visit or other contact	no-kommune-Encounter (Encounter)	Shows that the contact was actually completed.
Decision, discharge summary or other supporting document	DocumentReference	Use no-basis profile where relevant.
Measurements or functional assessment	Observation	Supporting resource for structured assessment, no separate municipal profile in this version.

Minimum For Vendor

Part	Concrete expectation
Server should expose	Active or recent EpisodeOfCare, relevant CarePlan, planned Appointment resources where planned contacts are shared, municipal Encounter resources after discharge and supporting documents as DocumentReference.
Client should be able to	Search per patient, show active episode/plan, sort contacts by date and display supporting documents without importing the whole journal.
Links should be in place	CarePlan.subject, Appointment.basedOn when the planned contact follows from a request, Encounter.subject, Encounter.episodeOfCare where an episode exists, and DocumentReference.subject.
Outside minimum	Full documentation write-back to EHR, full PLO message replacement, complete discharge message and full case handling process.

Recommended Searches

Information need	Example search	Expected result
Find active municipal follow-up	GET [base]/EpisodeOfCare?patient=Patient/[id]&status=active	Active episode or empty Bundle
Find active follow-up plan	GET [base]/CarePlan?subject=Patient/[id]&status=active	Active plan or empty Bundle
Find planned municipal contacts	GET [base]/Appointment?patient=Patient/[id]&date=ge[YYYY-MM-DD]&status=booked	Planned contacts or empty Bundle
Find municipal contacts after discharge	GET [base]/Encounter?patient=Patient/[id]&date=ge[YYYY-MM-DD]	Completed contacts in the period
Find relevant documentation	GET [base]/DocumentReference?subject=Patient/[id]&date=ge[YYYY-MM-DD]	Document references, for example discharge summary or decision

Running Example In This IG

Kari Hansen is discharged on 12 January. Grünerløkka district creates a municipal episode from 13 January. There is a decision and request for home nursing, practical assistance and follow-up after hip fracture. The follow-up plan shows goals, plan period, multidisciplinary team, supporting documents and relevant interventions. The first home visit on 15 January is registered as a municipal contact, followed by digital follow-up, phone contact and multidisciplinary evaluation.

In this IG, the running example chain is shown with:

The same chain is also available as a navigable overview on Examples.

• ExamplePatient
• ExampleDocumentReference
• ExampleServiceRequest
• ExampleRehabilitationServiceRequest
• ExampleEpisodeOfCare
• ExampleCarePlan
• ExampleAppointment
• ExampleEncounter
• ExampleShortTermStay
• ExampleEncounterFollowup
• ExampleEncounterPhone
• ExampleEncounterEvaluation
• ExampleObservation
• ExampleGoal
• ExampleCareTeam

Important Modelling Point

The sender's contact and the municipality's contact are not necessarily the same Encounter. Encounter is not hospital-only in FHIR, but each Encounter should describe the contact owned by the actor that performed or documented it. The hospital contact describes specialist health service activity. The rehabilitation center or short-term unit contact describes activity there. The municipality's no-kommune-Encounter describes the municipality's actual follow-up after the transition.

Use Case 2: Planned Municipal Follow-Up

Purpose

Represent planned follow-up, completed contacts, measurements and evaluation consistently over time.

Need Covered By This Use Case

Municipal services often follow the patient over time, and multiple actors need the same situation picture: what is the plan, what has been done, what has been observed and who is responsible. This use case shows how this may be described with municipal minimum profiles without turning the IG into a complete specification for digital home follow-up or measurement data sharing.

Typical Example Variants

Variant	What it shows
Home nursing and GP in medication follow-up	Municipal contacts and observations are shared as basis for medication assessment.
Nursing home and physician when health condition changes	Contacts, measurements and plan give the physician an overview before assessment.
Rehabilitation team and home care	Plan, goals, functional assessment and multidisciplinary contacts are connected in the same municipal episode.
Digital home follow-up as part of a municipal plan	Measurements may be supporting data, while this IG describes plan, responsibility and municipal contact around the follow-up.

What The Receiver Needs To Know

• Which municipal services the patient receives.
• Which plan or request the follow-up is linked to.
• Which contacts have been completed.
• Which observations or measurements are relevant.
• Who is responsible in the municipality.

Recommended FHIR Use

Information	FHIR resource	Comment
Ongoing municipal follow-up	no-kommune-EpisodeOfCare	Shows that the patient is followed by the municipality over time.
Plan for follow-up	no-kommune-CarePlan	Can represent follow-up plan, intervention plan, visit plan or service overview.
Planned visit, control or meeting	Appointment	Used until the contact has happened. Appointment.basedOn should point to the relevant request when there is one.
Home visit, phone, video, meeting or supervision documented as a separate contact	no-kommune-Encounter	Used when the contact has actually been completed.
Measurements or clinical observations	Observation	Used for structured information such as functional assessment, vital signs or home-based measurements.
Note or documentation	DocumentReference	Used when information is shared as a document.

Minimum For Vendor

Part	Concrete expectation
Server should expose	Active CarePlan, relevant planned Appointment, relevant completed Encounter, responsible unit and any Observation where the service already supports structured measurements.
Client should be able to	Retrieve active plan, latest contacts and relevant measurements for a patient within a period.
Links should be in place	Appointment.basedOn when the planned contact follows from a request, Encounter.subject, Encounter.episodeOfCare where an episode exists, Observation.subject and optionally Observation.encounter when the measurement was made in a concrete contact.
Outside minimum	Complete rota/visit schedule, internal task workflow and a separate model for measurement data streams that belong in VKP/PMD.

Recommended Searches

Information need	Example search	Expected result
Find active municipal follow-up	GET [base]/EpisodeOfCare?patient=Patient/[id]&status=active	Active episode or empty Bundle
Find active follow-up plan	GET [base]/CarePlan?subject=Patient/[id]&status=active	Active plan or empty Bundle
Find planned municipal contacts	GET [base]/Appointment?patient=Patient/[id]&date=ge[YYYY-MM-DD]&status=booked	Planned contacts or empty Bundle
Find latest municipal contacts	GET [base]/Encounter?patient=Patient/[id]&date=ge[YYYY-MM-DD]	Completed contacts in the relevant period
Find relevant measurements	GET [base]/Observation?subject=Patient/[id]&date=ge[YYYY-MM-DD]	Structured observations where the service supports this

Example Variant: Home Nursing And GP

Home nursing observes that the patient is dizzy after a medication change. The municipality shares the latest relevant contacts, follow-up plan and observations. The GP uses this as basis for assessment.

The GP consultation is normally the GP's own Encounter. The home nursing visit is the municipality's no-kommune-Encounter. They may concern the same problem, but they are owned and described by different actors.

Example Variant: Nursing Home And Physician

A nursing home resident has increasing shortness of breath and reduced general condition. The nursing home records observations and contacts a physician. The physician retrieves the latest municipal contacts, observations and plan before assessment.

For nursing homes, Encounter.location is often relevant because the physical place matters. For a phone contact with a physician, place may be less important, while participant and time are more important.

Minimum For Nursing Home Stay

Part	Concrete expectation
The stay	Represent active or recent stay as Encounter with patient, status, type/class, period, responsible unit and relevant Location.
Longer follow-up	Use EpisodeOfCare when the stay is part of a broader municipal episode, and link Encounter.episodeOfCare where possible.
Physician contact	Register physician contact as a separate contact when it is actually a separate assessment or consultation. Do not use the same Encounter for both the stay and a separate physician contact if responsibility and event differ.

Example Variant: Fall At Home And Planned Follow-Up

An older patient receiving home nursing falls at home, is assessed by ambulance and emergency primary care, and returns home with increased municipal support. The municipality may expose the ongoing home nursing follow-up as EpisodeOfCare, the adjusted wound care and observation plan as CarePlan, the request for increased support as ServiceRequest, emergency care documents as DocumentReference, vital signs or frailty assessment as Observation, the GP control in ten days as Appointment, and completed home nursing visits as Encounter.

The ambulance contact, emergency primary care contact and GP consultation are normally the responsible services' own Encounter resources. The municipality should not reuse those as municipal no-kommune-Encounter resources unless the municipality is actually documenting its own contact. If the municipality only receives the external assessment as a note, DocumentReference is usually the better fit.

Example Variant: Digital Home Follow-Up

The patient is followed at home with digital measurements such as blood pressure, weight, oxygen saturation or symptom questionnaire. The measurement is normally Observation or QuestionnaireResponse. An Encounter is used only when a contact or assessment actually happens and should be documented as a contact.

This IG does not replace or override VKP or Patient's measurement data (PMD). VKP and PMD describe specific handling, collection and availability of measurement data, including detailed use of Observation for relevant measurement types. This use case only shows how measurements may be included as supporting data in a broader municipal follow-up context together with no-kommune-EpisodeOfCare, no-kommune-CarePlan and no-kommune-Encounter.

Practical interaction:

• PMD/VKP should be the source for the measurement data stream where the service is used.
• This IG can describe which municipal plan, contact or responsible unit the measurement belongs with.
• A municipal solution should document whether Observation is retrieved from PMD/VKP or from a local journal/API.

Important Modelling Point

Planned contact and completed contact should not be mixed. Planned contacts may be modelled as Appointment where relevant. Completed contact is modelled as Encounter when the contact is actually documented as a separate contact.

Use Case 3: Service Need, Decision And Request

Purpose

Model municipal service need, decision, request/assignment and further follow-up so that basis, responsibility and delivery can be followed in interoperability.

Need Covered By This Use Case

Municipal health and care services often start with an assessment of need and a decision or decision-like act about a service. The assignment must then be translated into practical follow-up by the delivery unit. This use case makes the distinction clear: the decision is a supporting document, the request describes what needs follow-up, and plan/contacts show how the service is actually delivered.

This is not intended as a Norwegian Labour and Welfare Administration (NAV) use case or a general administrative case handling model. The use case concerns health and care services where a decision, request or assignment is relevant for municipal health care and practical follow-up.

Typical Example Variants

Variant	What it shows
Decision on home nursing, practical assistance or rehabilitation	Decision is shared as a supporting document and linked to follow-up.
Request or assignment to municipal delivery unit	ServiceRequest describes what needs follow-up.
Acute deterioration with further follow-up	Municipal contact and observations may provide basis for emergency services or a new request.

What The Receiver Needs To Know

• Which need or decision is the basis.
• Who made the request.
• Which municipal unit or role should deliver or follow up.
• Which period the assignment applies to.
• How request and supporting documents are connected to episode and plan.

Recommended FHIR Use

Information	FHIR resource	Comment
Decision or supporting document	DocumentReference	The decision is a document, not the request itself.
Request, referral or assignment	no-kommune-ServiceRequest (ServiceRequest)	Describes what is requested or should be followed up.
Municipal follow-up over time	no-kommune-EpisodeOfCare	Gives context when the decision concerns a longer service episode.
Plan for delivery	no-kommune-CarePlan	Links request and interventions to practical follow-up.
Execution or workflow	Task	Supporting resource that may be used where the implementation needs workflow.

Minimum For Vendor

Part	Concrete expectation
Server should expose	DocumentReference for decision/supporting document, ServiceRequest for active request or assignment, and optionally CarePlan/EpisodeOfCare when the assignment is followed over time.
Client should be able to	Distinguish decision from request, show status/period/requester/performer where available, and find the plan showing practical follow-up.
Links should be in place	DocumentReference.subject, ServiceRequest.subject, CarePlan.activity.reference to relevant ServiceRequest, and Encounter.basedOn when a contact follows from the assignment.
Outside minimum	Complete municipal case handling, decision production, complaint flow and internal work distribution.

Recommended Searches

Information need	Example search	Expected result
Find decision-relevant documents	GET [base]/DocumentReference?subject=Patient/[id]&type=[code]	Relevant document references
Find active assignments or requests	GET [base]/ServiceRequest?subject=Patient/[id]&status=active	Active requests or empty Bundle
Find active episode for the assignment	GET [base]/EpisodeOfCare?patient=Patient/[id]&status=active	Active municipal episode
Find plan linked to follow-up	GET [base]/CarePlan?subject=Patient/[id]&status=active	Active plan

Example Variant: Decision And Request

Kari Hansen has a decision for home nursing and practical assistance after discharge. The decision is represented as DocumentReference. The request to the municipal delivery unit is represented as ServiceRequest. The episode is represented as no-kommune-EpisodeOfCare, and the delivery plan is represented as no-kommune-CarePlan.

Example Variant: Acute Deterioration

Home care detects acute deterioration in a patient at home and contacts emergency medical services. Emergency services need a quick overview of active municipal follow-up, latest contacts, relevant measurements and who in the municipality can be contacted. After the event, the municipality may also need to change follow-up, for example with a new assessment, adjusted plan or new assignment to a delivery unit.

Important Modelling Point

Decision and request are not the same. The decision may be shared as DocumentReference. Request, referral or assignment is typically modelled as ServiceRequest. Practical follow-up is collected in no-kommune-EpisodeOfCare, no-kommune-CarePlan and no-kommune-Encounter.

Same Profile, Different Content

The same profile may be used in several interoperability situations, but the content is not identical.

Profile	Discharge and follow-up	Planned municipal follow-up	Service need, decision and request
no-kommune-EpisodeOfCare	Follow-up after discharge	Ongoing home care, nursing home stay or digital follow-up	Context for decision or assignment over time
no-kommune-CarePlan	Plan for rehabilitation and follow-up	Intervention plan, visit plan, service overview or follow-up plan	Plan for delivery of requested service
no-kommune-Encounter	Home visit after discharge	Home visit, phone, video, supervision or meeting	Contact linked to assignment, change or evaluation
no-kommune-ServiceRequest	Request or referral that triggers follow-up	Active request behind planned follow-up	The assignment that needs follow-up
DocumentReference	Discharge summary, decision or supporting document	Note, assessment or plan as document	Decision or other supporting document
Observation	Functional assessment or measurement	Vital signs, National Early Warning Score 2 (NEWS2)-like assessments or home-based measurements	Documents observation that may justify further follow-up

Minimum Data Across Use Cases

For data to be useful across actors, these minimum details should be present:

Resource	Most important to include
no-kommune-EpisodeOfCare	patient, status, start date and responsible organization
no-kommune-CarePlan	patient, status, plan period and plan author/responsible party
no-kommune-Encounter	patient, contact form/type, time and responsible unit
no-kommune-ServiceRequest	patient, status, intent, requested service, requester and performer where relevant
DocumentReference	patient, document type, date, author and link/content
Observation	patient, code/description, time, value and who/what performed the measurement

Related Profiles And Examples

• Profiles: no-kommune-ServiceRequest, no-kommune-Encounter, no-kommune-EpisodeOfCare, no-kommune-CarePlan
• Examples: ExampleEpisodeOfCare, ExampleCarePlan, ExampleAppointment, ExampleEncounter, ExampleShortTermStay, ExampleEncounterFollowup, ExampleEncounterPhone, ExampleEncounterEvaluation, ExampleServiceRequest, ExampleRehabilitationServiceRequest, ExampleDocumentReference, ExampleObservation, ExampleGoal, ExampleCareTeam, ExamplePatient