This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Physical Exam (QDM)"
Jump to navigation
Jump to search
FEisenberg (talk | contribs) (Created page with "[http://wiki.hl7.org/index.php?title=Harmonization_of_Health_Quality_Information_models Back to Harmonization of Health Quality Information Models Page]<br> __FORCETOC__ QDM d...") |
FEisenberg (talk | contribs) |
||
Line 134: | Line 134: | ||
| row3cell3 | QDM matched to QI Core / FHIR | | row3cell3 | QDM matched to QI Core / FHIR | ||
|- | |- | ||
− | | | + | | row8cell1 | Components |
− | | | + | | row8cell2 | Observation.component |
− | | | + | | row8cell3 | QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code. |
|- | |- | ||
− | | | + | | row8cell1 | Component Code |
− | | | + | | row8cell2 | Observation.component.code |
− | | | + | | row8cell3 | See "Component" - Content-specific |
+ | |- | ||
+ | | row8cell1 | Component Result | ||
+ | | row8cell2 | Observation.component.value(x) | ||
+ | | row8cell3 | See "Component" - Content-specific | ||
|- | |- | ||
| row8cell1 | Code | | row8cell1 | Code |
Revision as of 16:58, 6 April 2018
Back to Harmonization of Health Quality Information Models Page
QDM defines Physical Exam as the evaluation of the patient's body and/or mental status exam to determine its state of health. The techniques of examination can include palpation (feeling with the hands or fingers), percussion (tapping with the fingers), auscultation (listening), visual inspection or observation, inquisition and smell. Measurements may include vital signs (blood pressure, pulse, respiration) as well as other clinical measures (such as expiratory flow rate and size of lesion). Physical exam includes psychiatric examinations. QDM defines three contexts for Physical Exam: Physical Exam, Order; Physical Exam, Performed; Physical Exam, Recommended.
Physical Exam, Order
QDM Attribute | QI Core Metadata Element | Comment |
Physical Exam, Order | ProcedureRequest.intent | Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context. |
Anatomical Location Site | ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-approachBodySite) | Note QI Core ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-appropriatenessScore) - not included in QDM but may potentially apply to Appropriate Use Criteria |
Method | Not addressed in QI Core | |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) | QDM matched to QI Core / FHIR |
Reason | ProcedureRequest.reasonCode | QDM matched to QI Core / FHIR |
Author dateTime | ProcedureRequest.AuthoredOn | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM |
Code | ProcedureRequest.code | QDM matched to QI Core / FHIR |
id | ProcedureRequest.id | QDM matched to QI Core / FHIR |
Source | ProcedureRequest.requester | Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of |
Physical Exam, Recommended
QDM Attribute | QI Core Metadata Element | Comment |
Physical Exam, Recommended | ProcedureRequest.intent | Procedure Request intent uses the concepts proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option. Constrain to "order" from the intent value set for QDM datatypes with the order context. |
Anatomical Location Site | ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-approachBodySite) | Note QI Core ProcedureRequest.extension (http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-procedurerequest-appropriatenessScore) - not included in QDM but may potentially apply to Appropriate Use Criteria |
Method | Not addressed in QI Core | |
Negation Rationale | ProcedureRequest.extension (http://hl7.org/fhir/StructureDefinition/procedurerequest-reasonRefused) | QDM matched to QI Core / FHIR |
Reason | ProcedureRequest.reasonCode | QDM matched to QI Core / FHIR |
Author dateTime | ProcedureRequest.AuthoredOn | Note - ProcedureRequest.occurrence(x) defines a dateTime when the event should occur - not addressed in QDM |
Code | ProcedureRequest.code | QDM matched to QI Core / FHIR |
id | ProcedureRequest.id | QDM matched to QI Core / FHIR |
Source | ProcedureRequest.requester | Author, orderer - note also, ProcedureRequest.requester.agent for device, practitioner or organization who initiated the request; or ProcedureRequest.requester.onBehalfOf - the organization the device or practitioner was acting on behalf of |
Physical Exam, Performed
QDM Attribute | QI Core Metadata Element | Comment |
Physical Exam, Performed | Observation (the .status metadata allows conformance to the specific QDM datatype context) | QDM matched to QI Core / FHIR |
Anatomical Location Site | Observation.bodySite | QDM matched to QI Core / FHIR |
Method | Observaton.method | QDM matched to QI Core / FHIR |
Relevant Period | observation.effective.x | QDM matched to QI Core / FHIR |
Negation Rationale | Observation.dataAbsentReason | The value set is required. Many eCQMs use a measure developer-specific value set. Note, component also has a Observation.component.dataAbsentReason in QI Core. |
Reason | Observaton.basedOn | QDM matched to QI Core / FHIR |
Result | Observation.value(x) | Note - QI Core also includes Observation.interpretation and Observation.comment - eCQMs have addressed interpretation as an implementation issue. Perhaps that approach should be reconsidered. |
Author dateTime | FHIR.provenance.recorded | FHIR references authorDatetime as part of the provenance resource for all resources. Is authorDatetime still appropriate for this datatype? |
Status | Procedure.status | QDM matched to QI Core / FHIR |
Components | Observation.component | QDM uses components to combine related observations to each other, e.g., a set of independent observations performed within an admission assessment for an inpatient admission. Each observation is unique (e.g., questions about tobacco usage, other substance usage, blood pressure, pulse, skin turgor, etc., etc.) but they are captured during the same patient-provider interaction. Such QDM components should map directly to QI Core / FHIR observations that can be linked to other observations. Other QDM component examples include multiple questions that are part of a validated evaluation tool (e.g., a Braden skin assessment scale). This latter example indicates individual questions that are inherently tied to the Braden scale instrument and the questions and answers do not have inherent value without being part of the instrument. QI Core / FHIR considers each such question as an Observation.component. A general rule of thumb is QI Core / FHIR components apply only when the inherent value of the observation is defined by the parent observation. The result is that the content will determine if a QDM component maps to Observation.code or to Observation.component.code. |
Component Code | Observation.component.code | See "Component" - Content-specific |
Component Result | Observation.component.value(x) | See "Component" - Content-specific |
Code | Observation.code | QDM matched to QI Core / FHIR |
id | Observation.id | QDM matched to QI Core / FHIR |
Source | Observation.performer | QDM matched to QI Core / FHIR |