Stream: patient empowerment
Topic: Patient Choice
Tom Jones (Apr 20 2020 at 22:40):
Is anyone anywhere working on a list of medical data categories that can be presented to a user to get their consent to share that data?
Lloyd McKenzie (Apr 21 2020 at 04:40):
Yes. The most active discussion has been in the #smart on FHIR stream where they're talking about coming up with appropriate patient-friendly scopes for granting apps permission to access data. However, the principles are the same for patients consenting to data access for other purposes.
John Moehrke (Apr 21 2020 at 12:35):
There is also robust discussion around the Consent resource .
John Moehrke (Apr 21 2020 at 12:36):
The specific ask "presented to the user to get their consent" is both a User Interface function and a Policy ... Neither of these are the scope of an "Interoperability" standards organization. We touch on them only as much as we need to in order to define the interoperability needs, which we then focus our standards efforts upon.
Vassil Peytchev (Apr 21 2020 at 12:42):
A list of medical data categories
sounds (at least somewhat) like a terminology/vocab question
John Moehrke (Apr 21 2020 at 12:59):
we do have a huge number of vocabularies... These are engaged in Consent resource use of Permit vs Deny rules.
- Categories of sensitive health information http://build.fhir.org/v3/ActCode/cs.html#v3-ActCode-_ActInformationSensitivityPolicy
- categories of data that have a personal sensitivity http://build.fhir.org/v3/ActCode/cs.html#v3-ActCode-_EntitySensitivityPolicyType
- categories of data relationships that have a sensitivity http://build.fhir.org/v3/ActCode/cs.html#v3-ActCode-_RoleInformationSensitivityPolicy
- risk classification of sensitive health information http://build.fhir.org/v3/ConfidentialityClassification/vs.html
- reason categories for intended data use http://build.fhir.org/v3/PurposeOfUse/vs.html
These are the topic of some efforts to make their use more clear. This clarity is not necessarily specific to Consent, but certainly the clarity is helpful in consent. -- see the currently open ballot for public comment on FHIR DS4P
In the FHIR core this all is covered under security labels - http://build.fhir.org/security-labels.html
Which is linked to from things like Consent.provision[*].securityLabel
John Moehrke (Apr 21 2020 at 13:09):
That said... Consent has other vocabulary based vectors
- class -- typically based on LOINC or SNOMED ontology
- code -- specific codes from medical terminology
- data period -- some date/time start-stop that the patient wants to include (Permit) or exclude (Deny)
- Individual -- indicator of organization, careteam, group, practitioner, related person --- that the patient wants to include (Permit) or exclude (Deny)
John Moehrke (Apr 21 2020 at 13:11):
All on a infinitely recursive rules language.
E.g. Permit Treatment, but not Dr Bob, unless Dr Bob is the last person on earth he can see the medication list, but not my alcohol abuse related meds.
Tom Jones (Apr 21 2020 at 18:16):
So, if patient empowerment is not interested in presenting a list of what information the patient is agreeing to release, what exactly is this group doing? (BTW - i have seen the list @John Moehrke presented and have already begun the process. Who would like to join in making that list, irrespective of whether it gets posted on HL7?
Jose Costa Teixeira (Apr 21 2020 at 18:21):
I believe the role of patient empowerment is to frame this problem also considering consent fatigue and those cases where consent is irrelevant.
As a patient, I like to think that this group helps us focus on the right stuff
Tom Jones (Apr 21 2020 at 18:24):
@Jose Costa Teixeira - yes right - again i need to show the purpose of the grant - my question was more related to whether the discussion of user experience belongs here, or if i should go elsewhere?
Jose Costa Teixeira (Apr 21 2020 at 18:27):
I think here (patient empowerment) and here https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy
Lloyd McKenzie (Apr 21 2020 at 18:27):
Discussion of user experience is perfectly appropriate here, but decision on what codes/values will be supported will likely be made in other technical groups - taking into account our recommendations but also system capabilities and requirements.
Tom Jones (Apr 21 2020 at 19:49):
OK - so i will generate codes somewhere else and drop the results here from time to time as we are ready
John Moehrke (Apr 22 2020 at 12:51):
I suspect much is being lost in the communication medium of zulip. This should be a verbal conversation.
John Moehrke (Apr 22 2020 at 12:52):
Bringing the perspective of the User Experience (UX) is clearly a role that the patient empowerment group brings. But defining User Interface (UI) is not the role of HL7. User Experience is distinct from User Experience.
Lloyd McKenzie (Apr 22 2020 at 13:58):
I think you meant UI is distinct from UX?
John Moehrke (Apr 22 2020 at 13:59):
yup. stumbled over my own clarification
John Moehrke (Apr 22 2020 at 13:59):
maybe I could blame autocorrect? nope...
Dave deBronkart (Apr 24 2020 at 15:19):
Again pardon my being late to this thread.
Tom Jones said:
So, if patient empowerment is not interested in presenting a list of what information the patient is agreeing to release,
Who said the group's "not interested"? :-)
Tom Jones said:
what exactly is this group doing?
Patient Empowerment is a new WG, just getting started. Like all HL7 groups, our mission, charter, and priorities (and everything else) are publicly posted on Confluence. Mission and charter are on the home page, and Priorities is a recently approved document under the Documents sidebar link.
Tom Jones (May 01 2020 at 18:16):
This is an attempt to frame some questions that occured in threads on consent etc. The idea of patient choice (using US as a federated use case, clearly the EU or CA would be other use cases) was presented to the ONC by two working groups of the Kantara Initiative. One of the primary points of the submission is that the protection of PHI needs to be extended to data in the patient's possession. Here is a link to the web page that is an ongoing update of the submission to the ONC. https://wiki.idesg.org/wiki/index.php/Patient_Choice Comments to the doc are appreciated from any and all who are interested, here if appropriate, or directly if you are not sure.
Michele Mottini (May 01 2020 at 19:01):
Seems in direct contrast with what the regulation says: 'the patient must be limited to the use of secure sites and applications' (that document) vs 'patient can access data with an app of their choice' (the regulation)
Michele Mottini (May 01 2020 at 19:02):
(meaning the US regulation)
Tom Jones (May 01 2020 at 19:32):
I guess i read that differently than you do. There are always limitations to apps on phones. Carin has already established a code of conduct. Our one difference is that the code should be mandatory. BTW - do not interpret this proposal to prevent the user from extracting health data. The patient app certainly could allow that. But that the patient would always to told the cost of that in terms of their privacy.
Michele Mottini (May 01 2020 at 20:14):
the code should be mandatory
Yes - but US regulation prohibit that. Providers cannot deny app access based on app conformance or not to some condition
Tom Jones (May 01 2020 at 20:42):
please point me to that regulation
Jenni Syed (May 01 2020 at 20:45):
It's 1200 or so pages of pure joy :)
Jenni Syed (May 01 2020 at 20:46):
https://www.healthit.gov/curesrule/
Tom Jones (May 01 2020 at 20:46):
if its online i can search it - as an aside what is the relationship between this and 45 cfr? could it override the cfr or is it a part of the cfr or now possibly the entire cfr - i guess we will need to wait for 45 cfr to be republished to see a unified view?
Jenni Syed (May 01 2020 at 20:52):
that's the newest version that will replace "meaningful use" or "promoting interoperability" regulations that are in effect today. The information blocking aspect has been clarified much more, but there are some timelines required on how fast you accept a developer as a provider or a vendor and how fast you connect them. You can confirm the company/developer is who they say they are, but you don't have the ability to do a deep review of each app for (as an example) security practices and threat models
Jenni Syed (May 01 2020 at 20:53):
The fact sheets are usually the most consumable overviews of the regulations
Jenni Syed (May 01 2020 at 20:54):
eg: https://www.healthit.gov/cures/sites/default/files/cures/2020-03/TheONCCuresActFinalRule.pdf
Tom Jones (May 01 2020 at 23:37):
Well i searched for the specific comment - there were some that were close, but it seems like a selective reading. In the future it would be helpful if any quoted section had the section # listed. First the FDA part is interesting because upload of data to the EHR would probably trigger section 618 of FDASIA. SO - here are the sections i find relevant - III Application registration = We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server. - - - However, implementers of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion.
Tom Jones (May 01 2020 at 23:56):
but i admit it seems like a very expensive lawyer would require many hours to answer any open questions. Since Kantara has already submitted comments to the strategic plan that addresses these issue we may need to ask for guidance from ONC yet again.
Last updated: Apr 12 2022 at 19:14 UTC
