Difference between revisions of "Encounter (QDM)"
FEisenberg (talk | contribs) |
FEisenberg (talk | contribs) |
||
Line 1: | Line 1: | ||
[http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br> | [http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br> | ||
− | The HL7 CQI Workgroup reviewed the content on this page in April 2018 referencing QDM version 5.3. There are no changes to the QDM Encounter category in QDM 5.4. | + | The HL7 CQI Workgroup reviewed the content on this page in April 2018 referencing QDM version 5.3. There are no changes to the QDM Encounter category in QDM 5.4.<br> |
+ | |||
__FORCETOC__ | __FORCETOC__ | ||
QDM defines Encounter as an identifiable grouping of healthcare-related activities characterized by the entity relationship between the subject of care and a healthcare provider; such a grouping is determined by the healthcare provider. A patient encounter represents interaction between a healthcare provider and a patient with a face-to-face patient visit to a clinician’s office, or any electronically remote interaction with a clinician for any form of diagnostic treatment or therapeutic event. Encounters can be billable events but are not limited to billable interactions. Each encounter has an associated location or modality within which it occurred (such as an office, home, electronic methods, phone encounter, or telemedicine methods). The encounter location is the patient’s location at the time of measurement. Different levels of interaction can be specified in the value associated with the element while modes of interaction (e.g., telephone) may be modeled using the data flow attribute. QDM defines three contexts for Encounter: Encounter, Order; Encounter, Performed; Encounter, Recommended. | QDM defines Encounter as an identifiable grouping of healthcare-related activities characterized by the entity relationship between the subject of care and a healthcare provider; such a grouping is determined by the healthcare provider. A patient encounter represents interaction between a healthcare provider and a patient with a face-to-face patient visit to a clinician’s office, or any electronically remote interaction with a clinician for any form of diagnostic treatment or therapeutic event. Encounters can be billable events but are not limited to billable interactions. Each encounter has an associated location or modality within which it occurred (such as an office, home, electronic methods, phone encounter, or telemedicine methods). The encounter location is the patient’s location at the time of measurement. Different levels of interaction can be specified in the value associated with the element while modes of interaction (e.g., telephone) may be modeled using the data flow attribute. QDM defines three contexts for Encounter: Encounter, Order; Encounter, Performed; Encounter, Recommended. |
Revision as of 19:19, 7 June 2018
Back to Harmonization of Health Quality Information Models Page
The HL7 CQI Workgroup reviewed the content on this page in April 2018 referencing QDM version 5.3. There are no changes to the QDM Encounter category in QDM 5.4.
QDM defines Encounter as an identifiable grouping of healthcare-related activities characterized by the entity relationship between the subject of care and a healthcare provider; such a grouping is determined by the healthcare provider. A patient encounter represents interaction between a healthcare provider and a patient with a face-to-face patient visit to a clinician’s office, or any electronically remote interaction with a clinician for any form of diagnostic treatment or therapeutic event. Encounters can be billable events but are not limited to billable interactions. Each encounter has an associated location or modality within which it occurred (such as an office, home, electronic methods, phone encounter, or telemedicine methods). The encounter location is the patient’s location at the time of measurement. Different levels of interaction can be specified in the value associated with the element while modes of interaction (e.g., telephone) may be modeled using the data flow attribute. QDM defines three contexts for Encounter: Encounter, Order; Encounter, Performed; Encounter, Recommended.
Encounter, Order
QDM Attribute | QI Core Metadata Element | Comment |
Encounter, Order | ReferralRequest.intent - FHIR STU 4.0 updating to ServiceRequest.intent | Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. For QDM datatypes with the context "order" the ReferralRequest.intent value shall be constrained to "order" |
FacilityLocation | ReferralRequest.context - FHIR STU 4.0 updating to ServiceRequest.context | QDM matched to QI Core / FHIR |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) | Modeled as a procedure request - there is no Encounter request in QI Core. Note FHIR STU 4.0 is updating ReferralRequest to Service.Request. See FHIR Tracker Item 15940 for negation rationale for ServiceRequest. |
Reason | ReferralRequest.reasonCode - FHIR STU 4.0 updating to ServiceRequest.reasonCode | QDM matched to QI Core / FHIR |
Author dateTime | ReferralRequest.AuthoredOn - FHIR STU 4.0 updating to ServiceRequest.AuthoredOn | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM |
Code | ReferralRequest.type - FHIR STU 4.0 updating to ServiceRequest.type | See also, Observation.category |
id | ReferralRequest.id - FHIR 4.0 updating to ServiceRequest.id | QDM matched to QI Core / FHIR |
Source | ReferralRequest.requester - FHIR 4.0 updating to ServiceRequest.requester | Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization on whose behalf the device or practitioner was acting |
Encounter, Recommended
QDM Attribute | QI Core Metadata Element | Comment |
QDM Attribute | QI Core Metadata Element | Comment |
Encounter, Recommended | ReferralRequest.intent - FHIR STU 4.0 updating to ServiceRequest.intent | Referral Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. For QDM datatypes with the context "recommended" the ReferralRequest.intent value shall be constrained to "order" |
FacilityLocation | ReferralRequest.context - FHIR STU 4.0 updating to ServiceRequest.context | QDM matched to QI Core / FHIR |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) | Modeled as a procedure request - there is no Encounter request in QI Core. Note FHIR STU 4.0 is updating ReferralRequest to Service.Request. See FHIR Tracker Item 15940 for negation rationale for ServiceRequest. |
Reason | ReferralRequest.reasonCode - FHIR STU 4.0 updating to ServiceRequest.reasonCode | QDM matched to QI Core / FHIR |
Author dateTime | ReferralRequest.AuthoredOn - FHIR STU 4.0 updating to ServiceRequest.AuthoredOn | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM |
Code | ReferralRequest.type - FHIR STU 4.0 updating to ServiceRequest.type | See also, Observation.category |
id | ReferralRequest.id - FHIR 4.0 updating to ServiceRequest.id | QDM matched to QI Core / FHIR |
Source | ReferralRequest.requester - FHIR 4.0 updating to ServiceRequest.requester | Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization on whose behalf the device or practitioner was acting |
Encounter, Performed
QDM Attribute | QI Core Metadata Element | Comment |
Encounter, Performed | Encounter (the .status metadata allows conformance to the specific QDM datatype context) | Constrained to status consistent with in-progress or finished. |
Relevant Period | Encounter.period | QDM matched to QI Core / FHIR |
Admission Source | Encounter.hospitalization.admitSource | QDM matched to QI Core / FHIR |
Diagnosis | Encounter.diagnosis | QDM matched to QI Core / FHIR |
Discharge Disposition | Encounter.hospitalization.dischargeDisposition | QDM matched to QI Core / FHIR |
Length of Stay | Encounter.length | QDM matched to QI Core / FHIR |
Negation Rationale | Encounter.extension (http://hl7.org/fhir/StructureDefinition/encounter-reasonCancelled) | Only applies to an encounter that was cancelled, not an encounter that was never planned for a specific reason. |
Principal Diagnosis | Encounter.diagnosis.role Encounter.diagnosis.rank |
Constrain Encounter.diagnosis.role to "Billing Diagnosis" and require Encounter.diagnosis.rank =1. See FHIR Tracker Request 15944 requesting addition of Principal Diagnosis reference in US Core that is consistent with this QDM to QI Core mapping |
Author dateTime | FHIR.provenance.recorded | FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype? |
Code | Encounter.class | Encounter.class fits best with the type of encounter. Measure developers create their own values and might need to constrain the use to the suggested value set. The previous Encounter.class value set included OBS - observation defined as "Provision of care of women during pregnancy, childbirth and immediate postpartum period. Also known as Maternity." The updated value set includes OBSENC for "observation encounter" approved in the November 2017 Harmonization cycle. |
FacilityLocations | Encounter.location | QDM matched to QI Core / FHIR |
FacilityLocations code | Location.type | QDM matched to QI Core / FHIR |
FacilityLocations location period | Location.period | QDM matched to QI Core / FHIR |
id | Encounter.id | QDM matched to QI Core / FHIR |