Finnish Base Profiles
2.0.0 - release

Finnish Base Profiles, published by HL7 Finland. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/fhir-fi/finnish-base-profiles/ and changes regularly. See the Directory of published versions

## Example Encounter: Encounter - patient is currently receiving care at a ward treating surgical patients

### How to find a patient in a ward?

Many systems have a need to answer the question: "How to find patients/encounters that are at ward X at moment T?".

There are key points to consider when forming the search criteria:

- We are most likely interested only in `IMP` (inpatient encounter) encounters, so we should filter by `class`.
- We are interested only in `in-progress` encounters, so we need to filter by `status`.
- We are most likely interested in querying by organizational hierarchy, the organizational unit (ward) responsible for the patient (not physical location).

Organizational ward should be communicated using the `serviceProvider` property.

FHIR request parameters: `GET /Encounter`

- class = `IMP`
- status = `in-progress`
- period `gt` and `le` filters as per target moment
- serviceProvider = id of the ward organization resource

Historically some systems keep the ward encounter active when the patient is sent to ICU. Leaving the encounter in an `in-progress` state would cause a gotcha: encounter says that it's active but patient is not really there. Using encounter´s `location` elements could be used to express that the patient has no active location in the ward, but this might be difficult to process for client systems and depend heavily on the organizational and location structures of a facility. Because of these problems, the encounter SHOULD not be kept `in-progress` when the patient is in an ICU period (if there is a need for "recycling" the ward period encounter, it should be set to `finished` and then back to `in-progress` upon return from the ICU).

#### Why not use Location.managingOrganization?

`Encounter`s `location` field is a reference to `Location` that has a field `managingOrganization`. Use of this to find the organization responsible for the patient is problematic. `Location.managingOrganization` might change for different reasons (a room is assigned to another organization) and this would have an unexpected effect on the responsibility-concern. `Location.managingOrganization` is "too far" from the encounter to be useful in this context.

#### Querying by physical location

Querying by location is also an option. Here the focus is on the physical location and not the organizational responsibility towards the patient. This blog post will describe the process.

Profile: FI Base Encounter

identifier: id-for-ward-encounter (use: usual, )

status: In Progress

class: ActCode IMP: inpatient encounter

subject: Testi Henkilö Male, DoB: 1990-01-01 ( National Identifier for Finland (use: official, ))

period: 2022-02-27 01:03:00+0200 --> (ongoing)

### Locations

- | Location | Status | Period
* | Location Vuode 3 | Active | 2022-02-27 01:03:00+0200 --> (ongoing)

serviceProvider: Organization Kirurgian vuodeosasto 4B, Länsi-Pohjan keskussairaala, LPSHP