Stream: implementers
Topic: Patient Request for Health Information
Grahame Grieve (Jul 31 2017 at 02:44):
An implementer organization has asked me about this form:
Grahame Grieve (Jul 31 2017 at 02:44):
Grahame Grieve (Jul 31 2017 at 02:44):
can we digitize this?
Grahame Grieve (Jul 31 2017 at 02:44):
the form would be a questionnaire? The output of the form would be a Consent statement?
Grahame Grieve (Jul 31 2017 at 02:46):
That raises something that's come up for me in a couple of contexts - the different between 'consent' and 'request'... I think the right way to think about it is 'I consent to this sharing', and 'now, please act on that consent' as a 2nd step
Grahame Grieve (Jul 31 2017 at 02:49):
I think the form needs to be a little tighter to make it worth digitizing.... but here's some candidate mappings to the Consent resource:
Dates of Service = Consent.provision.dataPeriod
DischargeSummary etc. = Consent.provison.code? or class? with a LOINC code?
Grahame Grieve (Jul 31 2017 at 02:49):
what to do about other?
Grahame Grieve (Jul 31 2017 at 02:50):
I think that the categories don't easily align with the information system architecture that we've laid out in Composition/DocumentReference/Content with the class/code heirarchy?
John Moehrke (Jul 31 2017 at 12:19):
I am working with Aaron on this mapping for connectathon as part of the Consumer Centered Data Exchange track. So far, much like what you mention. As you have described it, it could be a classic hospital organization presented form. The alternative is that there is a third party that presents the form to get 'desire', which is encoded in a Consent, which is sent within a request-for-data. The trust model is, why should the hospital organization trust the consent represents the desire of the patient, is going to be much harder.
John Moehrke (Jul 31 2017 at 12:22):
You hit upon a specifically difficult problem that we have not come up with a solution... That many Consent forms have kinds of choices of what kind of data to allow/forbid; but that these kinds of choices don't align well with the FHIR resource model. This AHIMA form is speaking more to the department from which they were authored, something that is not always possible to figure out. I suspect that these existing forms are more based on existing technology, but when looking at FHIR Resource layout, it is not a layout that helps with Privacy concerns.
Grahame Grieve (Jul 31 2017 at 13:13):
is it a FHIR problem? It's not really any different in v2 or CDA? I think it's more that they're just used to a manual process, and haven't really thought through the consequences of automating it?
John Moehrke (Jul 31 2017 at 14:07):
Yes it is a problem with v2 and v3... less so with CDA, because there are some 'types of documents' that have been defined. Such as those in C-CDA, or where an identified (unique id) document is known. The advantage CDA has is that there is a limit to the bunny-hole. That is when someone says the "Discharge Summary: for ativity in June 2017", this is a known and contained set. (Same will be true of FHIR Document), but with REST FHIR, one could navigate forward, up, over, down, left, right, etc... and essentially never know if you have found everything from June without exposing anything NOT from June.
John Moehrke (Jul 31 2017 at 14:08):
Encounter compartment does help, but is not a 'bright line', and is not mandated...
Grahame Grieve (Jul 31 2017 at 21:47):
the same logic that builds the document....
Aaron Seib (Aug 03 2017 at 19:08):
I've a suggestion - for the connectathon let's intentionally focus on a narrowly defined use case where an individual is asserting their individual right of access and authorizing the disclosure of their data to the client of their choice.
As you both point out it isn't a problem unique to FHIR but I think we can make significant progress at the connectathon in regards to a real world use. I'm specifically thinking about the P2C scenario - I think it is a fair assertion to state that most users will want all of their data shared with themselves - but for the purposes of the connectathon we'd be able to exercise most but not all of the relevant muscles in a P2P exchange using a share all as well.
I've been collaborating with AHIMA (Lauren Riplinger et al.) for a while on this topic. They are focused on content and process in the as is world that there members work in today. We've been communicating about the delta between their categories (that emerged from their member driven consensus based process)on the paper form and a computable mechanism that could be employed to delineate "categories" in a way that a consumer would find useful. I understand that Christine Bechtel is leading a project that includes a consumer focus group to figure out what the consumer's actually preferences, experiences, wants and\or expectations are in relation to being able to the constrain what is shared between two covered entities - so there is that influence as well as changing regs like Jesse's Law that we'll need to consider as well (https://www.congress.gov/bill/115th-congress/senate-bill/581/text).
Lauren and I are talking about how to collaborate to help mitigate the delta with the input of their membership, NATE's, et al. - and actually navigate and facilitate the process that will have to follow to truly address the problem. It isn't just a technical problem and to fix it we really need to bring multiple inputs together, right?
My thinking is we could prioritize figuring out an end to end with the share all choice at this connectathon and work with AHIMA et al. to educate everyone (including the ultimate end-user - the consumer) about what is reliable and what the risk may be if we don't come up with an unambiguous method to categorizing informed by the work of Christine, our experience at and subsequent to the connectathon.
Make sense?
John Moehrke (Aug 03 2017 at 21:04):
Yes, we should start with whatever is easy, move to that which is a bit harder, ..... It is likely when we get to the really hard stuff the solution will be more of a soft (policy) solution, than a technical solution.
Michael Hosking (Aug 14 2017 at 02:58):
Yes the form would be a questionnaire. eg. Patient completed pre-operative assessment or standardised patient completed assessment
The output of the form would be a range of patient responses regarding Observations (eg. Levels of pain, depression/motivation scale response)
Aaron Seib (Aug 14 2017 at 13:34):
Thanks Michael - I agree that the questionnaire is an appropriate way to implement the generation of the populated form with consumer input. The "consent" that we are talking about wouldn't be regarding their "observation" in this context but their "preferences" regarding what and with whom data may be shared. Does that make sense?
Sticking to the simple case of a consumer "authorizing" the sharing of data held by a resource server we're trying to find out from the consumer what they want to have shared with the consumer controlled app (CCA) of their choice. For the connectathon we're trying to explore what are the facile methods to approach this for the narrowly defined use case where the consumer is Authorizing the sharing of all of the data held by the FHIR server with their consumer controlled app.
At the connectathon we are leveraging the SMART on FHIR authentication method - so we know the Patient_ID of the user and we know what CCA the user has and started the interaction with (for the connectathon all CCAs will be registered with the source EMRs a priori).
The area that we are trying to vet out is how best to document the preferences of the consumer via a Consent Resource so that an access token can be generated and used by the CCA to get data from the source EMR subsequently.
One notion is to have SMART scopes defined that can be mapped to the preferences of the consumer. For the connectathon and for this very specific use case (where the consumer is authorizing the data holder to share data about themselves with the app of their choice) we'd start with a Scope which says share all of my data with this consumer controlled app.
An initial goal would be to stretch all the relevant muscles that would enable this in order to have a base-line to use for reference going forward as we attempt to expand this model to more challenging use cases in the future.
Welcome everyone's thoughts on this notion.
Last updated: Apr 12 2022 at 19:14 UTC
