From 362d527d698ae697f38369c80c445bb3904830c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Thu, 26 Jan 2023 10:22:43 +0200 Subject: [PATCH 1/8] Describe how to query ward encounters --- ...ctureDefinition-fi-base-encounter-intro.md | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 input/pagecontent/StructureDefinition-fi-base-encounter-intro.md diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md new file mode 100644 index 0000000..3357c77 --- /dev/null +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -0,0 +1,43 @@ +### Scope and Usage + + +### 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 stored in `serviceProvider`. + +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.manangingOrganization? +`Encounter`s `location` -field is a reference to `Location` that has a field +`manangingOrganization`. Use of this to find the organization responsible for the patient is +problematic. `Location.manangingOrganization` might change for different reasons (a room is +assigned to another organization) and this would have an unexpected effect on the +responsibility-concern. `Location.manangingOrganization` 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) +will describe the process. From 9da226407c231c599014def6b16b26a425d48959 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Thu, 26 Jan 2023 16:14:47 +0200 Subject: [PATCH 2/8] Fix typo --- .../StructureDefinition-fi-base-encounter-intro.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index 3357c77..eb4b5a0 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -29,12 +29,12 @@ these problems, the encounter should not be kept `in-progress` when the patient (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.manangingOrganization? +#### Why not use Location.managingOrganization? `Encounter`s `location` -field is a reference to `Location` that has a field -`manangingOrganization`. Use of this to find the organization responsible for the patient is -problematic. `Location.manangingOrganization` might change for different reasons (a room is +`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.manangingOrganization` is "too far" from the encounter to be +responsibility-concern. `Location.managingOrganization` is "too far" from the encounter to be useful in this context. #### Querying by physical location From de77ccab4fc9d3f732fd08bda276f412ab4b16df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Fri, 27 Jan 2023 08:15:59 +0200 Subject: [PATCH 3/8] Improve wording in encounter intro --- .../pagecontent/StructureDefinition-fi-base-encounter-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index eb4b5a0..2453e9e 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -11,7 +11,7 @@ There are key points to consider when forming the search criteria: * 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 stored in `serviceProvider`. +Organizational ward should be communicated using the `serviceProvider` property. FHIR request parameters: `GET /Encounter` From 96b541ac819df6335add8a0ed058373a146a50f0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Fri, 27 Jan 2023 09:26:38 +0200 Subject: [PATCH 4/8] Add encounter examples Provide more context to encounter intro with an example. Add encounter example fsh:s. --- input/fsh/examples/encounterAmbulatory.fsh | 16 +++++++++ .../examples/encounterAtWardInProgress.fsh | 18 ++++++++++ ...ctureDefinition-fi-base-encounter-intro.md | 35 +++++++++++++++++++ 3 files changed, 69 insertions(+) create mode 100644 input/fsh/examples/encounterAmbulatory.fsh create mode 100644 input/fsh/examples/encounterAtWardInProgress.fsh diff --git a/input/fsh/examples/encounterAmbulatory.fsh b/input/fsh/examples/encounterAmbulatory.fsh new file mode 100644 index 0000000..79fc71f --- /dev/null +++ b/input/fsh/examples/encounterAmbulatory.fsh @@ -0,0 +1,16 @@ +Instance: EncounterAmbulatory +InstanceOf: FiBaseEncounter +Title: "Encounter - patient primary care visit" +Description: "An example of a FI Base encounter where a patient has completed a visit in primary care." +Usage: #example +* id = "id-for-visit" +* identifier.use = #usual +* identifier.value = "id-for-visit" +* status = #finished +* class.system = "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode" +* class.code = #AMB +* class.display = "ambulatory" +* subject.reference = "Patient/id-for-patient" +* period.start = "2022-02-28T15:03:00+02:00" +* period.end = "2022-02-28T15:33:00+02:00" +* serviceProvider.reference = "Organization/1.2.246.10.2085212.10.1314" \ No newline at end of file diff --git a/input/fsh/examples/encounterAtWardInProgress.fsh b/input/fsh/examples/encounterAtWardInProgress.fsh new file mode 100644 index 0000000..973aebc --- /dev/null +++ b/input/fsh/examples/encounterAtWardInProgress.fsh @@ -0,0 +1,18 @@ +Instance: EncounterAtWardInProgress +InstanceOf: FiBaseEncounter +Title: "Encounter - patient is currently receiving care at a ward treating surgical patients" +Description: "An example of a FI Base encounter where a patient is currently receiving care at a ward." +Usage: #example +* id = "id-for-ward-encounter" +* identifier.use = #usual +* identifier.value = "id-for-ward-encounter" +* status = #in-progress +* class.system = "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode" +* class.code = #IMP +* class.display = "inpatient encounter" +* subject.reference = "Patient/id-for-patient" +* period.start = "2022-02-27T01:03:00+02:00" +* serviceProvider.reference = "Organization/1.2.246.10.8286189.10.100012" +* location[0].status = #active +* location[0].period.start = "2022-02-27T01:03:00+02:00" +* location[0].location.reference = "Location/id-for-bed-3" \ No newline at end of file diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index 2453e9e..2a8bdc4 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -6,6 +6,41 @@ Many systems have a need to answer the question: "How to find patients/encounters that are at ward X at moment T?". +Here's an example encounter: + + ``` +{ + "resourceType": "Encounter", + "id": "id-for-encounter", + "status": "in-progress", + "class": { + "system": "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode", + "code": "IMP", + "display": "inpatient encounter" + }, + "subject": { + "reference": "Patient/id-for-patient" + }, + "period": { + "start": "2022-02-27T01:03:00+02:00" + }, + "serviceProvider": { + "reference": "Organization/id-for-ward" + }, + "location": [ + { + "status": "active", + "period": { + "start": "2022-02-27T01:03:00+02:00" + }, + "location": { + "reference": "Location/id-for-bed-3" + } + } + ] +} + ``` + 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`. From b4ef2f141cdfae1d7043156fb1b2296d2dd3d1c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Fri, 27 Jan 2023 15:09:16 +0200 Subject: [PATCH 5/8] Attempt moving patients in ward to example I can't get it to work. Is there an issue in sushi? --- .../examples/encounterAtWardInProgress.fsh | 43 +++++++++- ...ctureDefinition-fi-base-encounter-intro.md | 78 ++----------------- 2 files changed, 49 insertions(+), 72 deletions(-) diff --git a/input/fsh/examples/encounterAtWardInProgress.fsh b/input/fsh/examples/encounterAtWardInProgress.fsh index 973aebc..54d109e 100644 --- a/input/fsh/examples/encounterAtWardInProgress.fsh +++ b/input/fsh/examples/encounterAtWardInProgress.fsh @@ -1,7 +1,48 @@ Instance: EncounterAtWardInProgress InstanceOf: FiBaseEncounter Title: "Encounter - patient is currently receiving care at a ward treating surgical patients" -Description: "An example of a FI Base encounter where a patient is currently receiving care at a ward." +Description: """An example of a FI Base encounter where a patient is currently receiving care at a ward. + ### 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) + will describe the process. + """ Usage: #example * id = "id-for-ward-encounter" * identifier.use = #usual diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index 2a8bdc4..b8c1cd1 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -1,78 +1,14 @@ ### Scope and Usage +### Relation to Finnish Palvelutapahtuma -### How to find a patient in a ward? +TODO describe relation -Many systems have a need to answer the question: "How to find patients/encounters that are at ward -X at moment T?". +See the national spec https://www.kanta.fi/jarjestelmakehittajat/liite-2-palvelutapahtumien-esimerkkeja -Here's an example encounter: +### Organizational responsibility - ``` -{ - "resourceType": "Encounter", - "id": "id-for-encounter", - "status": "in-progress", - "class": { - "system": "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode", - "code": "IMP", - "display": "inpatient encounter" - }, - "subject": { - "reference": "Patient/id-for-patient" - }, - "period": { - "start": "2022-02-27T01:03:00+02:00" - }, - "serviceProvider": { - "reference": "Organization/id-for-ward" - }, - "location": [ - { - "status": "active", - "period": { - "start": "2022-02-27T01:03:00+02:00" - }, - "location": { - "reference": "Location/id-for-bed-3" - } - } - ] -} - ``` +The unit responsible for the encounter should be communicated using the `serviceProvider` property. -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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) -will describe the process. +For instance, there's a [detailed example with explanations](Encounter-id-for-ward-encounter.html) how to fetch patients +in a ward. From ad8f743e8d9b13e48501be293439b5330ef652b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Fri, 27 Jan 2023 16:02:37 +0200 Subject: [PATCH 6/8] Restore patients in ward text to encounter intro I couldn't get this text to fit nicely in the example. Putting it back to the main intro text. Added some stub paragraphs for other relvant parts, so that its clear that patients in a ward is not the only concern we are trying to adress. --- .../examples/encounterAtWardInProgress.fsh | 43 +----------------- ...ctureDefinition-fi-base-encounter-intro.md | 44 ++++++++++++++++++- 2 files changed, 43 insertions(+), 44 deletions(-) diff --git a/input/fsh/examples/encounterAtWardInProgress.fsh b/input/fsh/examples/encounterAtWardInProgress.fsh index 54d109e..973aebc 100644 --- a/input/fsh/examples/encounterAtWardInProgress.fsh +++ b/input/fsh/examples/encounterAtWardInProgress.fsh @@ -1,48 +1,7 @@ Instance: EncounterAtWardInProgress InstanceOf: FiBaseEncounter Title: "Encounter - patient is currently receiving care at a ward treating surgical patients" -Description: """An example of a FI Base encounter where a patient is currently receiving care at a ward. - ### 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) - will describe the process. - """ +Description: "An example of a FI Base encounter where a patient is currently receiving care at a ward." Usage: #example * id = "id-for-ward-encounter" * identifier.use = #usual diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index b8c1cd1..c8f84f3 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -10,5 +10,45 @@ See the national spec https://www.kanta.fi/jarjestelmakehittajat/liite-2-palvelu The unit responsible for the encounter should be communicated using the `serviceProvider` property. -For instance, there's a [detailed example with explanations](Encounter-id-for-ward-encounter.html) how to fetch patients -in a ward. +#### 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 (for context see [example encounter](Encounter-id-for-ward-encounter.html)): +* 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) will describe the process. + + +See [the guide](StructureDefinition-fi-base-encounter-patients-in-ward.html) for how to fetch patients in a ward. + From 66e7a93a07f87dd40022e92fdd0c0809f2c1c7e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Mon, 30 Jan 2023 18:13:34 +0200 Subject: [PATCH 7/8] Move encounter query text to example page --- .../Encounter-id-for-ward-encounter-intro.md | 41 +++++++++++++++++ ...ctureDefinition-fi-base-encounter-intro.md | 44 +------------------ 2 files changed, 43 insertions(+), 42 deletions(-) create mode 100644 input/pagecontent/Encounter-id-for-ward-encounter-intro.md diff --git a/input/pagecontent/Encounter-id-for-ward-encounter-intro.md b/input/pagecontent/Encounter-id-for-ward-encounter-intro.md new file mode 100644 index 0000000..e421f6b --- /dev/null +++ b/input/pagecontent/Encounter-id-for-ward-encounter-intro.md @@ -0,0 +1,41 @@ +#### 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) will describe the process. + + +See [the guide](StructureDefinition-fi-base-encounter-patients-in-ward.html) for how to fetch patients in a ward. \ No newline at end of file diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index c8f84f3..7532423 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -10,45 +10,5 @@ See the national spec https://www.kanta.fi/jarjestelmakehittajat/liite-2-palvelu The unit responsible for the encounter should be communicated using the `serviceProvider` property. -#### 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 (for context see [example encounter](Encounter-id-for-ward-encounter.html)): -* 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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) will describe the process. - - -See [the guide](StructureDefinition-fi-base-encounter-patients-in-ward.html) for how to fetch patients in a ward. - +For instance, there's a [detailed example with explanations](Encounter-id-for-ward-encounter.html) how to fetch patients +in a ward. \ No newline at end of file From f4e26afd6e5849ac5d0c191d76dd8c1f238d14fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mika=20Jylh=C3=A4?= Date: Tue, 31 Jan 2023 14:52:14 +0200 Subject: [PATCH 8/8] Fix style issues use SHOULD instead of weak should. Fix markdown issues. --- .../Encounter-id-for-ward-encounter-intro.md | 35 +++++++++++-------- ...ctureDefinition-fi-base-encounter-intro.md | 6 ++-- 2 files changed, 24 insertions(+), 17 deletions(-) diff --git a/input/pagecontent/Encounter-id-for-ward-encounter-intro.md b/input/pagecontent/Encounter-id-for-ward-encounter-intro.md index e421f6b..af7db48 100644 --- a/input/pagecontent/Encounter-id-for-ward-encounter-intro.md +++ b/input/pagecontent/Encounter-id-for-ward-encounter-intro.md @@ -1,41 +1,48 @@ #### 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?". +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. +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 +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 +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 +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 + +`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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) will describe the process. +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](https://fhirblog.com/2013/10/24/adventures-in-searching-getting-a-list-of-patients-in-a-ward/) +will describe the process. -See [the guide](StructureDefinition-fi-base-encounter-patients-in-ward.html) for how to fetch patients in a ward. \ No newline at end of file +See [the guide](StructureDefinition-fi-base-encounter-patients-in-ward.html) for how to fetch +patients in a ward. diff --git a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md index 7532423..7fe1d3a 100644 --- a/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md +++ b/input/pagecontent/StructureDefinition-fi-base-encounter-intro.md @@ -8,7 +8,7 @@ See the national spec https://www.kanta.fi/jarjestelmakehittajat/liite-2-palvelu ### Organizational responsibility -The unit responsible for the encounter should be communicated using the `serviceProvider` property. +The unit responsible for the encounter should be communicated using the `serviceProvider` property. -For instance, there's a [detailed example with explanations](Encounter-id-for-ward-encounter.html) how to fetch patients -in a ward. \ No newline at end of file +For instance, there's a [detailed example with explanations](Encounter-id-for-ward-encounter.html) +how to fetch patients in a ward.