Difference between revisions of "FHIR Encounter"
Rene spronk (talk | contribs) |
Ewoutkramer (talk | contribs) |
||
(6 intermediate revisions by the same user not shown) | |||
Line 36: | Line 36: | ||
[[User:Rene spronk|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. | [[User:Rene spronk|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'''<br/> | ||
+ | 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'''<br/> | ||
+ | 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'''<br/> | ||
+ | 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 == | == Encounter attributes == | ||
Line 106: | Line 140: | ||
* Location of valuables | * Location of valuables | ||
* Previous encounter | * Previous encounter | ||
+ | * Movement (between wards, leave of absence) | ||
+ | ** identifier | ||
+ | ** start/end | ||
+ | ** responsible ward |
Latest revision as of 13:41, 15 April 2013
Return to PA Resource Development
Contents
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