Stream: implementers
Topic: Patient Reported Observations Connectathon
Eric Haas (Jun 07 2017 at 21:09):
We are considering potential HL7 Connectathon track in San Diego surrounding Patient Reported Observations (e.g., collecting nutrition data or BGs using there Iphone). My particular interest in bringing this up is to uncover any issues with the Observation resource as it relates to Patient Reported Observations. Things like vague or relative timing of events.. ( e.g., before breakfast) and other things I am not aware of. If you are interested in participating as either a client (app) or server or both, can suggest a scenario or two and can pull yourself away from the beach while in San Diego Let me know and I will consider putting together a Connectathon track together.
Brian Reinhold (Jun 07 2017 at 21:11):
Eric,
By patient reported observations do you mean having a patient take and report his/her own pulse and things like that? Or even take a measurement with a medical device but record the results manually since the device has no communication capability?
Danielle Friend (Jun 07 2017 at 23:03):
I'd like to participate in such a track, by both device and manually. In general, I think there could be quite a few helpful tracks that cover "Patient entered data", not just in regards to Observation - vitals.
Besides some of the basic workflows I can think of, it'd be interesting to have a scenario surround the full workflow - first entering the data, then retrieving the data and how that data is presented if a practitioner has or has not verified it's accuracy. I.e. should the status of a hand entered, maybe misspelled, allergy be shown as "active and confirmed" or "active but unconfirmed".
Eric Haas (Jun 08 2017 at 00:02):
@Brian Reinhold yes to both. and @Danielle Friend my interest is specifically in the Observation resource maturity but those are things that could be explored in this context an applied to other resources.
Brian Reinhold (Jun 08 2017 at 09:46):
Well we certainly make extensive use of the Observation resource in PHD/PoCD mapping. As you know we have two requests for updates on the Observation; addition of PINF and NINF as well as NAN for consistency with V2 messaging in the dataAbsentReason and the addition of the DeviceComponent as well as Device and DeviceMetric for the Observation.device element.
John Moehrke (Jun 08 2017 at 12:52):
Provenance would be critical to give attribution to the Patient. I understand Observation includes a performer which can be Patient. At least we should consider requiring Provenance so that all patient attributed data can be easily discovered, not just Observations.
John Moehrke (Jun 08 2017 at 12:54):
May be also useful to look at using the security-label of PATAST http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html
Eric Haas (Jun 08 2017 at 14:49):
@Brian Reinhold re those trackers need to schedule when you can be on an OO call - Next Week perhaps. The first is unlikely and the second likely ( but would like Healthcare Devices input on it ). see the followups in the tracker.
Grahame Grieve (Jun 08 2017 at 21:01):
There's a reasonable prospect of being joined by openMHealth for this. And there's another related stream I'll be proposing that will bring participants interested in this subject as well
Eric Haas (Jun 08 2017 at 21:14):
OK so it sound like a tract then. I will be the titular lead but welcome other candidates. @John Moehrke would like to see Prov used too but category could be used for filtering and searching too.
John Moehrke (Jun 09 2017 at 12:25):
Yes. I can work with you on getting Prov in there.
Eric Haas (Jun 21 2017 at 18:45):
I have just only started work on the Patient Reported Observations Connectathon track and before I go much further in fleshing out the details, I would really like to get some feedback and suggestion from you all specifically regarding the Scenarios: Are these 2 scenarios appropriate use cases. In regards to self reporting of observations What are the specific "pain points" and other issues that you would like to focus on when interacting. Issues we have identified are fuzzy times and ambiguous responses. In addition I had assumed that there is typically a gateway device rather than a directly link to a Personal HealthCare Device. Should we include both "architectures"?
Eric Haas (Jun 21 2017 at 18:46):
Remember the focus of the track is on how well Observation can handle this data.
Eric Haas (Jun 21 2017 at 23:40):
Also what servers would be up for participating in this tract?
Grahame Grieve (Jun 22 2017 at 01:53):
would work with any of the generic servers? I don't think I need to do anything?
Eric Haas (Jun 22 2017 at 04:43):
I don't think so either. Maybe handle the standard extensions.
Grahame Grieve (Jun 22 2017 at 06:23):
think you should add that - just work with the generic servers . Does this link with the lastN stream?
Christiaan Knaap (Jun 22 2017 at 11:03):
You could add what you expect from the FHIR server. Should it validate incoming Observations (and reject invalid ones) for example?
John Moehrke (Jun 22 2017 at 12:38):
I think it would require that the server is one that supports Provenance. 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.
Eric Haas (Jun 22 2017 at 15:05):
@GG the lastN is a different stream and i'd rather keep them separate. I have a full plate with two streams plus the argonaut scheduling.
Grahame Grieve (Jun 22 2017 at 20:24):
perhaps you should cross-reference the streams in the doco? they seem somewhat related. Appreciate the load problem ;-)
Last updated: Apr 12 2022 at 19:14 UTC
