Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-14157

Reorganize the elements of Encounter for better tracking ablitities

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • STU3
    • Patient Administration
    • Encounter
    • Hide

      A new resource will be created (EncounterHistory) which will include the following elements from Encounter:

      EncounterHistory

          .identifier
          .status
          .class
          .type

          .serviceType
          .subject
          .subjectStatus
          .period

          .plannedStartDate

          .plannedEndDate
          .length
          .location
          .partOf  reference(Encounter)

       

      EncounterHistory should:

      • Include narrative about the boundaries and relationships with Encounter/_history
      • Include discussion around how this relates to Encounter.

      The Encounter resource will be updated to remove these properties which can now be tracked in EncounterHistory:

          .statusHistory
          .statusHistory.status
          .statusHistory.period
          .classHistory
          .classHistory.class
          .classHistory.period

       

      Additionally, we make a few other updates to Encounter:

      • Move specialArrangement out of hospitalization to a top-level Encounter
      • Update special-arrangement search param to point of the new location of specialArragnement.
      • Move specialCourtesy out of hospitalization onto a top level Encounter property.  Update the specialCourtesy definition to differentiate from the security label tag that has a VIP value.  [https://build.fhir.org/valueset-security-labels.html]
      • Remove dietPreference from Encounter, create extension that is allowed on Encounter and Patient.  Discuss with Patient Care.
      Show
      A new resource will be created ( EncounterHistory ) which will include the following elements from Encounter: EncounterHistory     .identifier     .status     .class     .type     .serviceType     .subject     .subjectStatus     .period     .plannedStartDate     .plannedEndDate     .length     .location     .partOf  reference(Encounter)   EncounterHistory  should: Include narrative about the boundaries and relationships with Encounter/_history Include discussion around how this relates to Encounter. The Encounter resource will be updated to remove these properties which can now be tracked in EncounterHistory :     .statusHistory     .statusHistory.status     .statusHistory.period     .classHistory     .classHistory.class     .classHistory.period   Additionally, we make a few other updates to Encounter : Move specialArrangement out of hospitalization to a top-level Encounter Update special-arrangement search param to point of the new location of specialArragnement. Move specialCourtesy out of hospitalization onto a top level Encounter property.  Update the specialCourtesy definition to differentiate from the security label tag that has a VIP value.  [ https://build.fhir.org/valueset-security-labels.html ] Remove dietPreference from Encounter, create extension that is allowed on Encounter and Patient.  Discuss with Patient Care.
    • Brian Postlethwaite / Alex de Leon : 12-0-0
    • Enhancement
    • Non-compatible
    • R5

    Description

      In it's current state, Encounter has several issues:

      • the history of state class and location, although changing in parallel most of the times are kept seperate, making it hard to see the "whole picture" of what has chanded
        * the mechanisms of keeping history of class/status and location are different
        * it is currently very difficult to add extensions that need tracking, as this would require multiple or complex entensions to keep both the current value as well as the history

      We propose the following changes:

      group all elements of Encounter that are time dependent/ may change multiple times during the course of an encounter into a backbone element with an id and a period

      e.g. "encounterPhase"

      -id\\-period\\-status\\-class\\-location
      -extension

      and add an element that keeps the history of the backbone element, e.g.\\"encounterHistory"
      - encounterPhase 0..*

      If in certain usecases only a specific subset of these elements need to be tracked or the elements need to be tracked individually, this could easily be achieved by slicing and constraining the encounterHistory

      This would also make it easy for systems to decide whether they only care for the current phase of the encounter (which should be part of the summary) or if they want do process the full stack of historical phase-elements.

      Attachments

        Activity

          People

            brian.postlethwaite Brian Postlethwaite
            Simone Heckmann Simone Heckmann
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: