201709 Patient Reported Observations

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:

• Last N Observation Query (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 )

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.