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

Difference between revisions of "Encounter (QDM)"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 3: Line 3:
  
 
__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. Note: Encounter, Performed; Encounter, Order; and Encounter, Recommended do not include a clear mechanism to address urgent, emergent or routine (scheduled) encounters. QDM is evaluating the possibility of adding Encounter,priority to address these issues. See the QDM Known Issues site to review the request and to link to the ONC Jira QDM Issues page to join in the discussion in consideration of the next version of QDM (5.5) [https://github.com/esacinc/CQL-Formatting-and-Usage-Wiki/wiki/eCQM-Known-Issues#differentiating-elective-vs-emergent-or-urgent-encounters-or-procedures].
  
  
Line 19: Line 19:
 
|-
 
|-
 
| row2cell1 | FacilityLocation
 
| row2cell1 | FacilityLocation
| row2cell2 | ReferralRequest.context - FHIR STU 4.0 updating to ServiceRequest.context
+
| row2cell2 | ReferralRequest.context
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
Line 27: Line 27:
 
|-
 
|-
 
| row2cell1 | Reason
 
| row2cell1 | Reason
| row2cell2 | ReferralRequest.reasonCode - FHIR STU 4.0 updating to ServiceRequest.reasonCode
+
| row2cell2 | ReferralRequest.reasonCode
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Author dateTime
 
| row2cell1 | Author dateTime
| row2cell2 | ReferralRequest.AuthoredOn - FHIR STU 4.0 updating to ServiceRequest.AuthoredOn
+
| row2cell2 | ReferralRequest.authoredOn
| row2cell3 | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
+
| row2cell3 | Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
 
|-
 
|-
 
| row2cell1 | Code
 
| row2cell1 | Code
| row2cell2 | ReferralRequest.type - FHIR STU 4.0 updating to ServiceRequest.type
+
| row2cell2 | ReferralRequest.type
 
| row2cell3 | See also, Observation.category
 
| row2cell3 | See also, Observation.category
 
|-
 
|-
 
| row2cell1 | id
 
| row2cell1 | id
| row2cell2 | ReferralRequest.id - FHIR 4.0 updating to ServiceRequest.id
+
| row2cell2 | ReferralRequest.id
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Source
 
| row2cell1 | Source
| row2cell2 | ReferralRequest.requester - FHIR 4.0 updating to ServiceRequest.requester
+
| row2cell2 | ReferralRequest.requester
 
| row2cell3 | 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
 
| row2cell3 | 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
 
|}
 
|}
Line 56: Line 56:
  
 
| row1cell1 | Encounter, Recommended
 
| row1cell1 | Encounter, Recommended
| row1cell2 | ReferralRequest.intent - FHIR STU 4.0 updating to ServiceRequest.intent
+
| row1cell2 | ReferralRequest.intent
 
| row1cell3 | 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"
 
| row1cell3 | 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"
 
|-
 
|-
 
| row2cell1 | FacilityLocation
 
| row2cell1 | FacilityLocation
| row2cell2 | ReferralRequest.context - FHIR STU 4.0 updating to ServiceRequest.context
+
| row2cell2 | ReferralRequest.context
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
Line 68: Line 68:
 
|-
 
|-
 
| row2cell1 | Reason
 
| row2cell1 | Reason
| row2cell2 | ReferralRequest.reasonCode - FHIR STU 4.0 updating to ServiceRequest.reasonCode
+
| row2cell2 | ReferralRequest.reasonCode
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Author dateTime
 
| row2cell1 | Author dateTime
| row2cell2 | ReferralRequest.AuthoredOn - FHIR STU 4.0 updating to ServiceRequest.AuthoredOn
+
| row2cell2 | ReferralRequest.authoredOn
| row2cell3 | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM
+
| row2cell3 | Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
 
|-
 
|-
 
| row2cell1 | Code
 
| row2cell1 | Code
| row2cell2 | ReferralRequest.type - FHIR STU 4.0 updating to ServiceRequest.type
+
| row2cell2 | ReferralRequest.type
 
| row2cell3 | See also, Observation.category
 
| row2cell3 | See also, Observation.category
 
|-
 
|-
 
| row2cell1 | id
 
| row2cell1 | id
| row2cell2 | ReferralRequest.id - FHIR 4.0 updating to ServiceRequest.id
+
| row2cell2 | ReferralRequest.id
 
| row2cell3 | QDM matched to QI Core / FHIR
 
| row2cell3 | QDM matched to QI Core / FHIR
 
|-
 
|-
 
| row2cell1 | Source
 
| row2cell1 | Source
| row2cell2 | ReferralRequest.requester - FHIR 4.0 updating to ServiceRequest.requester
+
| row2cell2 | ReferralRequest.requester
 
| row2cell3 | 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
 
| row2cell3 | 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
 
|}
 
|}
Line 131: Line 131:
 
| row3cell1 | Author dateTime
 
| row3cell1 | Author dateTime
 
| row3cell2 | FHIR.provenance.recorded
 
| row3cell2 | FHIR.provenance.recorded
| row3cell3 | FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype?
+
| row3cell3 | FHIR references authorDatetime as part of the provenance resource for all resources. Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html). The FHIR Encounter resource does not reference an author dateTime; hence the QDM mapping references FHIR.provenance.
 
|-
 
|-
 
| row8cell1 | Code
 
| row8cell1 | Code
| row8cell2 | Encounter.class
+
| row8cell2 | Encounter.type
| row8cell3 | 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.
+
| row8cell3 | Encounter.type fits best with the type of encounter. The Encounter.type value set includes codes from SNOMED CT decending from 308335008 patient encounter procedure (procedure) and codes from the Current Procedure and Terminology designated for Evaluation and Management (99200 – 99607) (subscription to AMA Required). Code systems included:
 +
http://snomed.info/sct
 +
http://www.ama-assn.org/go/cpt<br>
 +
[http://build.fhir.org/ig/cqframework/qi-core/StructureDefinition-qicore-encounter-definitions.html#Encounter.type Encounter.type] indicates: The codes SHALL be taken from US Core Encounter Type; other codes may be used where these codes are not suitable
 
|-
 
|-
 
| row8cell1 | FacilityLocations
 
| row8cell1 | FacilityLocations

Latest revision as of 19:05, 20 December 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. Note: Encounter, Performed; Encounter, Order; and Encounter, Recommended do not include a clear mechanism to address urgent, emergent or routine (scheduled) encounters. QDM is evaluating the possibility of adding Encounter,priority to address these issues. See the QDM Known Issues site to review the request and to link to the ONC Jira QDM Issues page to join in the discussion in consideration of the next version of QDM (5.5) [1].


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 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 QDM matched to QI Core / FHIR
Author dateTime ReferralRequest.authoredOn Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code ReferralRequest.type See also, Observation.category
id ReferralRequest.id QDM matched to QI Core / FHIR
Source ReferralRequest.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
Encounter, Recommended ReferralRequest.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 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 QDM matched to QI Core / FHIR
Author dateTime ReferralRequest.authoredOn Note - ProcedureRequest.occurrence[x] defines a dateTime when the event should occur - not addressed in QDM
Code ReferralRequest.type See also, Observation.category
id ReferralRequest.id QDM matched to QI Core / FHIR
Source ReferralRequest.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. Note: FHIR Provenance generally addresses the author of the message; the identifier/source of the original resource element is defined by the resource. Individual resource element provenance is summarized in the FHIR W5 Report (http://hl7.org/fhir/w5.html). The FHIR Encounter resource does not reference an author dateTime; hence the QDM mapping references FHIR.provenance.
Code Encounter.type Encounter.type fits best with the type of encounter. The Encounter.type value set includes codes from SNOMED CT decending from 308335008 patient encounter procedure (procedure) and codes from the Current Procedure and Terminology designated for Evaluation and Management (99200 – 99607) (subscription to AMA Required). Code systems included:

http://snomed.info/sct http://www.ama-assn.org/go/cpt
Encounter.type indicates: The codes SHALL be taken from US Core Encounter Type; other codes may be used where these codes are not suitable

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