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

Difference between revisions of "201709 Patient Reported Observations"

From HL7Wiki
Jump to navigation Jump to search
 
(29 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
__NOTOC__
 
__NOTOC__
 
=Patient Reported Observations=
 
=Patient Reported Observations=
 +
 +
[http://bit.ly/FHIR_Sleep_Obx Connectathon_Presentation]
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
Line 11: Line 13:
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
  
The Orders and Observation Work Group is interested in the readiness of the Observation resources to progress to a normative [http://build.fhir.org/versions.html#maturity Maturity level]. This tract is specifically focused on readiness of Observation to handle Patient reported data - in other words, observations that are reported directly by the patient. In many cases patients are asked to record and report clinical and nutritional data for example using an app on a smart phone. ('gateway'). The goal of this tract is to identify any potential issues and gaps in the Observation resource by stepping through a couple of simple scenarios [[#Scenarios|described below]].  For example, we discovered that constraining the timing of event to only dateTimes did not account for patient's oftentimes reporting the events as occurring relative to another event - e.g., "before breakfast".
+
The HL7 Orders and Observation Work Group is interested in the readiness of the Observation resources to progress to a normative [http://build.fhir.org/versions.html#maturity Maturity level]. This tract is specifically focused on readiness of Observation to handle Patient reported data - in other words, observations that are reported directly by the patient. In many cases patients are asked to record and report clinical and nutritional data for example using an app on a smart phone. ('gateway'). The goal of this tract is to identify any potential issues and gaps in the Observation resource by stepping through a couple of simple scenarios [[#Scenarios|described below]].  For example, we discovered that constraining the timing of events to only dateTimes did not account for patient's oftentimes reporting the events as occurring relative to another event - e.g., "before breakfast".
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
Line 21: Line 23:
 
* [http://www.openmhealth.org/ Open mHealth]
 
* [http://www.openmhealth.org/ Open mHealth]
 
* Epic
 
* Epic
 +
* FHIR Test Server
 
* (Soliciting participation on Zulip)
 
* (Soliciting participation on Zulip)
  
 
==Roles==
 
==Roles==
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
(Todo:Please include information here regarding how much advance preparation will be required if creating a client and/or server.)
 +
 
 +
'''Servers'''
 +
 
 +
The FHIR servers need to support the Observation resource and the standard extensions for Observation listed below. In adddition they should support the standard operations for Observations listed below as well.  The FHIR test servers listed [http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing here] can all be used for this track.
 +
 
 +
[http://build.fhir.org/observation-profiles.html#extensions Standard extensions for Observation]:
 +
 
 +
* event-reasonCode reasonCode for Event Pattern HL7 Extensions
 +
* event-reasonReference reasonReference for Event Pattern HL7 Extensions
 +
* observation-bodyPosition bodyPosition for Observation HL7 Extensions
 +
* observation-eventTiming eventTiming for Observation HL7 Extensions
 +
* observation-focal-subject focal-subject for Observation HL7 Extensions
 +
 
 +
[http://build.fhir.org/observation-profiles.html#operations Standard operations for Observation]:
 +
 
 +
* Last N Observation Query ([[201709_LastN_Query_Track|see the LastN connectathon track]])
 +
* Observation Statistics
 +
 
 +
'''Clients'''
 +
 
 +
Clients should provide capability for manually entered patient data.  ( i.e. having a patient take and report his/her own pulse , diet, exercise, etc.  Alternatively, a patient takes a measurement with a medical device but record the results manually since the device has no direct communication capability )
 +
 
 +
 
  
 
[[File:Screen_Shot_2017-06-21_at_11.11.09_AM.png]]
 
[[File:Screen_Shot_2017-06-21_at_11.11.09_AM.png]]
Line 31: Line 57:
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
=== Scenario  1: Diet  ===
+
'''Below are two Sample Scenarios,  Participant can elect to use these or choose another Scenarios within the scope of this tract'''
 +
 
 +
=== Sample Scenario  1: Diet  ===
 +
 
 +
Patient reports what they ate via their Iphone using a nutrition app or some other application.
 +
 
 +
=== Sample Scenario  2: Home Blood Glucose Monitoring  ===
 +
 
 +
Patient reports the measurements from there home glucometer via their Iphone using some application supplied by there healthcare provider.
 +
 
 +
=== Sample Scenario  3: Patient Reported Outcomes  ===
 +
 
 +
* “standard” PROs, e.g., [http://www.cqaimh.org/pdf/tool_phq9.pdf PHQ-9, PROMIS instruments]. These are questionnaires with a stem question, a prompt, and a Likert-like scale.  (assuming Observations are used instead the QuestionnaireResponse resource.)
 +
* “non-standard” PROs, e.g., Photographic Affect Meter (PAM) that aren’t the standard questionnaire or hybrid PROs that combine self-report (e.g., degree of pain) with passive sensing (e.g., mobility patterns).
 +
 
 +
===Bonus ===
  
Patient reports what they ate via their Iphone using a nutrition or some other application
+
- Send source of data ( Gataway information, who recorded etc) using the [http://build.fhir.org/provenance.html Provenance] resource as well:  Patient generated data needs good Provenance. And clients that utilize the Observation might want to look to Provenance to understand the source of the data. The server would be required to support Provenance as well.
  
=== Scenario 1: Home Blood Glucose Monitoring  ===
+
- After providing the FHIR server with patient reported data, fetch the last n observation using the ''lastn query'' as described in the [[201709_LastN_Query_Track|LastN Query ConnectathonTrack]]
  
Patient reports the measurements from there home glucometer via their Iphone using some application supplied by there healthcare provider
+
- After providing the FHIR server with patient reported data, fetch some statistics about the data using the [http://build.fhir.org/observation-operations.html#stats Observation Statistics operation].
  
 
==TestScript(s)==
 
==TestScript(s)==

Latest revision as of 19:57, 10 September 2017


Patient Reported Observations

Connectathon_Presentation

Submitting WG/Project/Implementer Group

Orders and Observations

Justification

The HL7 Orders and Observation Work Group is interested in the readiness of the Observation resources to progress to a normative Maturity level. This tract is specifically focused on readiness of Observation to handle Patient reported data - in other words, observations that are reported directly by the patient. In many cases patients are asked to record and report clinical and nutritional data for example using an app on a smart phone. ('gateway'). The goal of this tract is to identify any potential issues and gaps in the Observation resource by stepping through a couple of simple scenarios described below. For example, we discovered that constraining the timing of events to only dateTimes did not account for patient's oftentimes reporting the events as occurring relative to another event - e.g., "before breakfast".

Proposed Track Lead

Eric Haas

Expected participants

  • Open mHealth
  • Epic
  • FHIR Test Server
  • (Soliciting participation on Zulip)

Roles

(Todo:Please include information here regarding how much advance preparation will be required if creating a client and/or server.)

Servers

The FHIR servers need to support the Observation resource and the standard extensions for Observation listed below. In adddition they should support the standard operations for Observations listed below as well. The FHIR test servers listed here can all be used for this track.

Standard extensions for Observation:

  • event-reasonCode reasonCode for Event Pattern HL7 Extensions
  • event-reasonReference reasonReference for Event Pattern HL7 Extensions
  • observation-bodyPosition bodyPosition for Observation HL7 Extensions
  • observation-eventTiming eventTiming for Observation HL7 Extensions
  • observation-focal-subject focal-subject for Observation HL7 Extensions

Standard operations for Observation:

Clients

Clients should provide capability for manually entered patient data. ( i.e. having a patient take and report his/her own pulse , diet, exercise, etc. Alternatively, a patient takes a measurement with a medical device but record the results manually since the device has no direct communication capability )


Screen Shot 2017-06-21 at 11.11.09 AM.png

Scenarios

Below are two Sample Scenarios, Participant can elect to use these or choose another Scenarios within the scope of this tract

Sample Scenario 1: Diet

Patient reports what they ate via their Iphone using a nutrition app or some other application.

Sample Scenario 2: Home Blood Glucose Monitoring

Patient reports the measurements from there home glucometer via their Iphone using some application supplied by there healthcare provider.

Sample Scenario 3: Patient Reported Outcomes

  • “standard” PROs, e.g., PHQ-9, PROMIS instruments. These are questionnaires with a stem question, a prompt, and a Likert-like scale. (assuming Observations are used instead the QuestionnaireResponse resource.)
  • “non-standard” PROs, e.g., Photographic Affect Meter (PAM) that aren’t the standard questionnaire or hybrid PROs that combine self-report (e.g., degree of pain) with passive sensing (e.g., mobility patterns).

Bonus

- Send source of data ( Gataway information, who recorded etc) using the Provenance resource as well: Patient generated data needs good Provenance. And clients that utilize the Observation might want to look to Provenance to understand the source of the data. The server would be required to support Provenance as well.

- After providing the FHIR server with patient reported data, fetch the last n observation using the lastn query as described in the LastN Query ConnectathonTrack

- After providing the FHIR server with patient reported data, fetch some statistics about the data using the Observation Statistics operation.

TestScript(s)

Security and Privacy Considerations