This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Encounter

From HL7Wiki
Jump to navigation Jump to search

Return to PA Resource Development

Encounter scope and definition

Overview of the definition

If we look up Encounter in a dictionary, we find something along these lines: A meeting with a person or thing, especially a casual, unexpected, or brief meeting: "Our running into each other was merely a chance encounter"

However, in the context of Healthcare IT, an Encounter is a mostly planned, non-casual, longer running event: Situation on the uninterrupted course of which one or more health care professionals delivers health care services to a subject of care (from: EN13940:2001, Health informatics -- System of concepts to support continuity of care)

The full scope of Encounter only becomes clear in the definition shared by CCDA and ASTM CCR:

An Encounter is an interaction, regardless of the setting, between a patient and a practitioner who is vested with primary responsibility for diagnosing, evaluating, or treating the patient's condition. It may include visits, appointments, as well as non face-to-face interactions. It is also a contact between a patient and a practitioner who has primary responsibility for assessing and treating the patient at a given contact, exercising independent judgment. (from CCDA, section 4.11).

The "regardless of the setting" is elaborated upon elsewhere in the ASTM CCR document:

An Encounter can be a hospitalization (acute, rehab, nursing facility, or longterm care), office or clinic visit, emergency room visit, home health visit, or any treatment or therapy (physical, occupational, respiratory, or other), or any interaction, even non face-toface, between the patient and the healthcare system or a healthcare provider.

and this is echoed by the current definition from the PA Wiki: An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.

These "settings" are not necessarily mutually exclusive and can take place at the same time: as an Encounter seems to include longer running hospitalizations, "treatment" settings and face-to-face interactions, multiple "encounters" may be active at the same time.

It should be clear that these are not the only possible definitions, take for example, this one from Microsoft's Connected Health Framework: A consultation, examination, or treatment provided by a care professional typically at a single session or appointment. (from Microsoft Connected Health Framework - Part 2 - Business Framework) or openEHR, where an Encounter is a kind of "Composition", a unit of modification of the EHR, more specifically described as a "record of encounter as a progress note", and "for use to record when a person and clinician interact".

Questions

  • The definitions found on Encounter define its scope as ranging from short home visits to long-term care. Most seem to agree that outpatient visits and inpatient stays are all Encouters. Do we retain this definition?
  • Is Encounter mainly a administrative or logistic concept, or does it include responsibility?
  • Encounters, according to this definition, overlap in time and scope. How do we relate them, e.g. Do we wish to see a doctor visiting an inpatient as an encounter within an encounter? Does moving a patient from a medium-care ward to an intensive-care ward start a new encounter? What about referring a patient to another specialty for consultation? What about an outpatient visiting multiple facilities?
  • CCDA and CCR limit Encounter to "events", the v3 Normative Edition under Patient Administration distinguishes between "Encounter" (=EVN mood) and Appointment (=APT mood). However, there's also scheduling (agenda's, slots, etc). Which of these are in scope?

--Lmckenzi 13:56, 11 March 2013 (UTC)Adding my thoughts here since I won't be on the call. Realistically, you need to support what existing systems do. Some systems will treat moving departments as distinct encounters, some won't. FHIR isn't going to force standardization of existing business practice (though in-so-far as you can standardize the semantics of distinct business practices while still being easy to implement, that'd be a good thing). I think scheduling should be handled as a distinct structure. Switching moods within a single FHIR resource instance should be done with considerable caution.

Rene spronk 15:27, 11 March 2013 (UTC) See Requirements for an Universal Encounter model. Encounter should be event mood only. The issues in my mind are a) how does one find the common attributes of encounters (at all hierarchical levels, all vuewpoints/countries); b) do we wish to express encounter hierarchies in the model, i.e. allow for the referencing of child/parent encounters in the resource, c) how to link an encounter to a clinical encounter grouper such as a concern. Please keep in mind that PV1/PV2, PID-18 (account number), CCDA/CCR are all US-oriented models. As such the v3 models are a much better starting point from a UV realm perspective.

Summary of the discussion and answers

Below is a summary of the findings based on the discussions on the PA mailinglist and PA teleconfs

Granularity of Visit
Most participants say that it is desirable to have as few resources as possible to cover "visits", "session", "hospitalizations" etc.

Comments in favor:

  • There's considerable overlap in attributes (although that would not be enough reason on its own to combine them)
  • We prefer having a single concept to use for tracking the administrative context of the clinical events, it's less relevent whether this is for an in- or outpatient
  • Recently, PA and PC have merged the different v3 models that existed for separate kinds of Encounters into one, based on community input
  • Gut feeling and experience with teaching shows its problematic to keep them separate

However:

  • Business rules about in- and outpatients (and other types) about the contents may differ
  • Systems may well keep different kind of visits in separate tables or they may be separate systems within the same organization

Consensus seems to be: make the Visit encounter cover a broad scope of meetings, from long-term care through single sessions.

Since Visits occur at different levels of granularity, Visit will have a broad range of attributes to cover "the 80%" need for all those levels. We cannot standardize business practices about which business event requires which level of Visit or which business rules apply at each level. This means we have to cater for varied use and so most attributes will be optional. Profiles should be used if it is necessary to limit the scope of Visit.

New question: When systems keep track of Visits at different levels of granularity, do most of them also keep track of the links between them, so, e.g. do systems keep track which doctor visits were done during which hospitalization?

Lifecycle of Visit
Almost everyone agrees that the systems they know have separate concepts for appointment and visit. However, some report that it is common for outpatient's to just have an appointment, while inpatients have a Visit, which includes some lifecycle state like "pending"/"scheduled", "admitted", "discharged". This can cause problems when defining an elements contents or business rules, since their use and meaning may differ over the lifetime.

The discussion seems to suggest that it is desirable to have two Resources. Even so, it seems possible that Visit has some basic planning attributes and lifecycle statuses. These would be applicable to the lifecycle of longer running visits like hospitalizations, and are separate from data related to making appointments and scheduling resources.


Naming it an Encounter or a Visit
Clearly, no name is to everyone's liking, but this is the same for almost all resources. That's why there is an Alias column present in the Excel modeling sheet. Encounter did not really fit the concept of a hospitalization, while a Visit seems a bad match for a virtual encounter. Encounter is more generic and has become more or less Health IT jargon for the concept. Googling 'Medical Encounter' or 'Medical Visit' gives a definition that refers more to a single session than to a hospitalization for both cases.

Conclusion: There's no single fitting name. However, as long as the scope is clear, a name change won't influence our work finding the relevant models or use. Renaming a Resource in FHIR is not trivial, but no rocket science either. Let us discuss the name during the WGM.

Encounter attributes

Overview of possible attributes

To sketch the contents of the Encounter resource, below is an unordered and possibly inconsistent list of attributes found in CCR, openEHR and HL7v3 RIM for Encounter:

--Lmckenzi 13:58, 11 March 2013 (UTC)Might want to check out PV1/PV2 in v2 as well, seeing as they're the primary mechanism for tracing inpatient encounters most places. (Will definitely want mappings to v2 for this.)

  • Identifier
  • Status
  • Type (in-, outpatient, home, telephone etc.)
  • Admit datetime (effectiveTime)
  • Performer [0..*]
  • Location (Bed/Room/Ward/Unit) / Accomodation
  • Facility (Organization)
  • LocationType
    • Clinic [*]
    • Home [*]
    • Department [*]
    • Nursing unit [*]
    • Provider's office [*]
  • Duration, Frequency
  • Participant [0..*] / Practitioner
  • Indication
  • Description
  • Instructions
  • Consent
  • PatientClass (openEHR) - intended mode of treatment -
    • Inpatient/overnight patient [Inpatient/overnight patient]
    • Same day patient [Same day patient]
    • Outpatient [Outpatient]
    • Emergency patient [Emergency patient]
    • Community client [Community client]
    • Pre-admit [Pre-admit]
    • Commercial account [Commercial account]
    • Not-applicable [Not-applicable]
    • Unknown [Unknown]
  • AdmissionType
    • Accident [Accident]
    • Emergency [Emergency]
    • Labour & Delivery [Labour & Delivery]
    • Routine [Routine]
    • Newborn [Newborn]
    • Urgent [Urgent]
    • Elective [Elective]
    • Geriatric respite admission [Geriatric respite admission]
    • Statistical admission [Statistical admission]
    • Hospitalization
    • Rehabilitation
    • Nursing Facility
    • Emergency Room
    • Clinic Visit
  • PriorLocation (before admission = Organization part + bed/room/ward/unit)
  • AttendingDoctor
  • ReferringDoctor
  • ConsultingDoctor
  • AdmittingDoctor
  • AdmitSource (mode of admission nhdd 000385)
  • DischargeDisposition
  • PreAdmitTest
  • SpecialCourtesies (vip,...)
  • SpecialArrangements (wheelchair, stretcher, interpreter, ...)
  • ResponsibleParty
  • Discharger
  • Transportations (within an organization, or between them)
  • Fullfilled appointment
  • Notification contact
  • Devices (reusable)
  • Location of valuables
  • Previous encounter
  • Movement (between wards, leave of absence)
    • identifier
    • start/end
    • responsible ward