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
This page is a practical reading aid for moving from municipal concepts to FHIR.
The target audience is people who understand municipal health and care services, but who do not necessarily know FHIR well. The table below is therefore not a complete data model. It shows the recommended starting point: which FHIR resource you should normally look at first, and what should not be mixed together.
Start with the question you are trying to answer:
| Question | Typical FHIR starting point |
|---|---|
| Who is the information about? | Patient, optionally RelatedPerson for next of kin / related persons |
| Who is responsible? | Organization, PractitionerRole, Practitioner, CareTeam |
| What has been decided or documented? | DocumentReference, optionally Composition |
| What has been requested or ordered? | ServiceRequest / no-kommune-ServiceRequest |
| Which municipal episode does this belong to? | EpisodeOfCare / no-kommune-EpisodeOfCare |
| What is the follow-up plan? | CarePlan / no-kommune-CarePlan |
| Has a contact been planned but not completed? | Appointment / no-basis where relevant |
| What actually happened? | Encounter / no-kommune-Encounter |
| What was measured or assessed? | Observation, optionally QuestionnaireResponse |
| Municipal concept | Use FHIR resource | When does it fit? | Important elements | Comment |
|---|---|---|---|---|
| Patient / service user | Patient |
When the information concerns a person receiving health care or municipal follow-up. | identifier, name, birthDate, address |
Use no-basis-Patient when patient data is shared. |
| Next of kin / related person | RelatedPerson |
When a person is relevant because they are related to the patient. | patient, relationship, name, telecom |
Used for next of kin, contact person or another related person in follow-up. |
| Municipal unit / responsible service | Organization |
When the responsible municipality, district, provider organization or service unit should be described. | identifier, name, partOf, type |
Use no-basis-Organization. |
| Service provider | Practitioner |
When the individual who performs or assesses should be identified. | identifier, name, qualification |
Role and organization should often be described with PractitionerRole. |
| Role/function in the service | PractitionerRole |
When a person acts in a role for an organization. | practitioner, organization, code, specialty |
Useful for coordinator, nursing role, physiotherapist role, etc. |
| Multidisciplinary team | CareTeam |
When several roles share responsibility for follow-up. | subject, participant, managingOrganization |
Provides better context than listing individual persons loosely. |
| Service site / patient's home / base | Location |
When physical location is relevant for a contact or service. | name, address, managingOrganization |
Use no-basis-Location when location is shared. |
| Decision, letter, discharge summary or supporting document | DocumentReference |
When a document should be referenced or shared. | type, subject, date, author, content |
A decision is a supporting document. It is not the same as a request/order. |
| Structured document | Composition |
When the document should be represented with sections and structure. | type, subject, author, section |
Relevant for structured decisions, notes or reports, but not necessary for every document. |
| Request, referral or order | ServiceRequest / no-kommune-ServiceRequest |
When someone asks for something to be performed or followed up. | status, intent, code, subject, requester, performer, occurrence[x] |
Used for the order/request. The document behind the order can be represented as DocumentReference. |
| Municipal service episode | EpisodeOfCare / no-kommune-EpisodeOfCare |
When the municipality follows a patient over time and has responsibility or service context. | status, patient, period, managingOrganization, careManager, team |
Groups plan, contacts, responsibility and supporting documents in the same context. |
| Follow-up plan, intervention plan, visit plan or service overview | CarePlan / no-kommune-CarePlan |
When goals, interventions, plan period and follow-up should be described at an interoperability level. | status, intent, category, subject, period, author, activity, goal, supportingInfo |
Should not model the full local worklist or rota. Valuable when the plan should be shared or found across systems. |
| Completed contact | Encounter / no-kommune-Encounter |
When a contact actually happened and is documented as a separate contact: home visit, phone, video, meeting, supervision or assessment. | status, class, type, subject, period, participant, serviceProvider, episodeOfCare, appointment |
Do not mix with planned contact. Planned contact may be Appointment, and completed contact can point back using Encounter.appointment. |
| Planned contact | Appointment |
When a contact is planned but not completed. | status, start, end, participant, basedOn |
Use no-basis-Appointment where applicable. Appointment.basedOn should point to the relevant ServiceRequest when the planned contact follows from a request or assignment. Once the contact is completed, it can be documented as Encounter. |
| Measurement or assessment | Observation |
When a structured measurement or assessment should be shared. | code, value[x], effective[x], subject, performer |
Measurement data should follow relevant national profiles/services where they exist, for example Patient's measurement data (Pasientens måledata, PMD). |
| Form or functional assessment | QuestionnaireResponse or Observation |
When information comes from a form, assessment or structured evaluation. | questionnaire, item, answer or Observation.code/value |
Functional assessments related to IPLOS (Individbasert pleie- og omsorgsstatistikk), KPR (Kommunalt pasient- og brukerregister) or International Classification of Functioning, Disability and Health (ICF) should be assessed carefully before creating custom extensions. |
| Condition, problem or diagnosis | Condition |
When a health problem or clinical condition is relevant for follow-up. | clinicalStatus, verificationStatus, code, subject, onset[x] |
ICPC-2, ICD-10, ICD-11 or SNOMED CT may be relevant depending on context and system. |
| Task / workflow | Task |
When workflow, assignment or task status must be described. | status, intent, focus, owner, executionPeriod |
Use only when workflow is actually shared. Not required for every plan. |
| Do not mix | Short explanation |
|---|---|
| Decision and request | The decision is a supporting document (DocumentReference). The request or order is often ServiceRequest. |
| Planned contact and completed contact | Planned contact may be Appointment. Completed contact is Encounter. |
| Measurement and contact | Measurement is normally Observation. A contact or assessment conversation is Encounter. |
| Municipal episode and treatment contact | EpisodeOfCare describes follow-up/responsibility over time. Encounter describes an actual contact. |
| Local record structure and interoperability minimum | This IG describes data that should be shared or understood across systems, not the full internal electronic health record (EHR) model. |
| Norwegian Labour and Welfare Administration (NAV) / case handling and municipal health care | NAV or administrative case handling processes are not modelled here. Relevant documents may optionally be referenced as DocumentReference. |
Norwegian care and coordination messages (pleie- og omsorgsmeldinger, PLO) are important as a source for real municipal-specialist care coordination processes. This IG does not define a one-to-one FHIR replacement for PLO message XML. The recommended approach is to map the meaning of a PLO flow to the FHIR resource that best represents the information need.
| PLO-like information or process | Preliminary FHIR direction |
|---|---|
| Notification that a patient is admitted, discharge-ready or discharged | Use DocumentReference when the message/document itself is shared. Use Encounter and EpisodeOfCare when the need is to expose contacts, stays or follow-up context over time. |
| Health information, discharge report, discharge summary or other clinical document | Use DocumentReference, optionally Composition when structured document sections are needed. Key structured facts may additionally be represented as Observation, Condition, CarePlan or other clinical resources. |
| Request, assignment or need for municipal follow-up | Use ServiceRequest for what is requested, and link supporting documents through supportingInfo or DocumentReference. |
| Plan for municipal delivery after a transition | Use CarePlan for goals, interventions, planned activities and responsible roles. Planned contacts may be Appointment; completed contacts are Encounter. |
| Dialogue, question, answer or coordination message | Consider Communication when the message exchange itself must be represented. Use Task only when shared workflow state is actually needed. |
If the message envelope or event semantics must be preserved, a FHIR message Bundle with MessageHeader can be considered by an implementation. That is outside the minimum REST/search pattern in this IG.
Municipal code systems are relevant, but this IG does not establish new municipal code systems in v0.2. The principle is to use existing Norwegian and international code systems before new local code systems are established.
| Need | Relevant sources | Preliminary FHIR direction |
|---|---|---|
| Service type, service group, decision and reporting basis | KPR (Kommunalt pasient- og brukerregister), IPLOS (Individbasert pleie- og omsorgsstatistikk) and registration of municipal health and care data |
Consider for ServiceRequest.code, CarePlan.category, EpisodeOfCare.type and document type/category. No binding in v0.2. |
| Function, assistance needs and coping | International Classification of Functioning, Disability and Health (ICF) and IPLOS/KPR functional assessment | Should normally be modelled as Observation or QuestionnaireResponse, optionally with Goal when it concerns follow-up goals. |
| Reason for contact, problem and diagnosis in primary care | ICPC-2, ICD-10, ICD-11 and optionally SNOMED CT where relevant | Can be used in Condition.code, Encounter.reasonCode or Observation.code when the implementation already has this coding. |
| Measurement data and vital measurements | Unified Code for Units of Measure (UCUM), National Early Warning Score 2 (NEWS2) and national measurement data services such as PMD | Should be modelled as Observation. This IG does not define a separate measurement data profile. |
When code systems are used in a concrete API, supported codes and bindings should be documented in the service's CapabilityStatement or related service documentation.