Chair: Debi Willis Virginia Lorenzi
Scribe: Dave deBronkart
|Terrie Reed||Terrie Reed|
|Jose Costa Teixeira|
Meeting Minutes from Discussion
|Approval of this Agenda||yes|
|Prior call Minutes approval||yes|
|co-chair nominations and elections||Send nominations to: Linda@HL7.org by June 15.|
|CARIN "My Health Application" project announcement (all FHIR using apps)|
Jan: CARIN has published a curated list of patient facing apps that have attested to the CARIN Code of Conduct.
Here's Virginia's Zulip post with the following links:
Note: ALL APPS IN THE GALLERY SUPPORT FHIR, according to Ryan in that thread.
|PE WG projects|
Patient Corrections project
|Patient-Contributed Data project |
Leads: Maria D. Moen and Jan Oldenburg
For more efficient layout I'm moving these lengthy notes to below this table.
|Our projects||Future call: |
John to present CBCP for Consents
or Lisa to present Care Planning
|John will present on Consents 6/4/2020|
|Other WGs' project proposals that we might follow|
DID NOT GET TO THIS - carry it forward:
Others' project proposals: example from Debi - "Account, Payments, and Statements" -
See heading 2a, "Primary/Sponsor WG"
Note, this is a project SCOPE statement, not the brief Project Proposal
Which should we be following?
How do we spot them and what do we do?
How do you-all do this in other groups?
Discussion of Patient-Contributed Data
Now we need to create something similar for Patient-Contributed Data. Starter text from our Priorities document:
- "This is intentionally distinct from existing terms such as PGHD (patient-generated health data). Patient-contributed data can include observations, preferences, goals, anything that comes from the patient side of the clinical relationship."
- We had quite a lively discussion but were unable to determine what the project scope statement should contain or what the project would consist of. Will continue to work on determining the project purpose. See discussion details below:
Maria: Jan & she (co-leads) suggest starting with the existing ONC definition of PGHD, and adding the other use cases we're talking about. It seems as though we build upon, and expand the existing standards to accommodate the use cases our group is focused on rather than potentially creating redundancy or re-inventing the wheel.
Lloyd: Hm. CDA documents too often get accepted and set aside, rather than being put where they need to be in the EHR so they'll be seen by the HCP. In the FHIR world we're trying to get away from a "document" paradigm to a standard that isn't so rigidly structured.
(Dave needs a summary of this from someone (Maria? Jan? anyone?) more knowledgeable about the particulars, e.g. CDA-vs-FHIR and Lloyd prefers to "avoid documents," etc. What do these minutes need to say for future others to read, to understand what discussed?)
Lloyd re prior art: "Don't be bound by what exists, but do be informed by it."
Lloyd: appeared to recommend a generic specification that focused on those requirements that apply to all patient contributed data. Mentioned clinician "distrust".
Virginia: It seems that maybe two projects are needed:
- a white paper which defines the concept and provides an environmental scan of all HL7 related patient contributed data specifications so we understand what is out there and what is not (gaps).
- a FHIR IG that constrains/defines requirements common to all patient contributed data. For example, it might clearly define and constrain "provenance data"
Mikael in chat:
- Patient-generated health data does have some FHIR implementation guides too, right? Like http://hl7.org/fhir/uv/phd/2019May/.
- And there's an IHE profile https://wiki.ihe.net/index.php/Personal_Health_Device_Observation_Upload
Debi in chat: FHIR IG for PRO's (patient reported outcomes): http://www.hl7.org/fhir/us/patient-reported-outcomes/2018Sep/
Jan: We want to move away somehow (to the extent a standard can do this) from the paradigm that data is only legit when it's been validated by a physician. Lloyd: "validity" is a cultural thing ... there will always be a need to know "where did this come from?" (provenance)
(Note that aside from writing specs, HL7 can write position papers etc on items like the paradigm of physician approval. HL7 can remove the technical barriers to doing what needs to be done. Getting it so such things can get in there is the first step.)
Debi: get anything from a pt and into an EHR. Lloyd: yes but in a way that they can get integrated into the EHR. Jan: Not all genuinely useful data may exist in forms that may not exist in discrete elements in EHRs. e.g. for her own asthma, her peak flow readings aren't that useful but the trends are.
Note again that the enabling specification is a separate issue from the change-management process. HL7 position papers as above may be ONE source of encouraging change but is not sufficient.
Mikael in chat:
Jan, I think so. And that was justified before, and that's why we want a broader term.
Regarding what we want to achieve:
If I’d have the magic wand, I’d swing it at least twice:
1. EHR’s and clinicians are somewhat reluctant to take in patient provided data. This may be due to policies of organizations and risk/liability for information that is in their EHR (which they are responsible for) and how to reflect patient-sourced information. However, having a spec for this might encourage adoption. Setting clear compartments in EHR’s would be a step forward. I know clinicians do have the need for the data in some use cases.
2. Also, patient-facilitated transfer of official clinical data. How it should be signed by a healthcare org in order to be accepted by another system? I could imagine a technical approach for this. Would there still be interest? Would it be adopted?