Stream: smart/health-cards
Topic: SHC: QR Links
Josh Mandel (Sep 24 2021 at 16:56):
I'd like to explore a general pattern of creating "SMART Health Card Links", so QRs can link to bundles of data when the data are too big to fit in a SMART Health Card directly. Given #smart/health-cards > Digital Insurance Card discussion, CARIN's digital insurance card use case may be a good first target for this technique.
Adam Culbertson (Sep 24 2021 at 17:38):
@Grahame Grieve I am not sure if we should abandon the idea or trim the data payload. @Josh Mandel yes would be great to explore this. So basically there are two options with the QR code either embed the data directly in QR which is 7089 characters or link to a bundle of data. The latter option may be ideal. For the use case of vaccines or lab tests, the results don't change. Insurance cards on the other hand can change and so this functionality would be a value add to the digital version of the card.
Adam Culbertson (Sep 24 2021 at 17:44):
@Amy Ballard curious to get your take on this?
Isaac Vetter (Sep 24 2021 at 19:35):
yeah, the QR code containing a link really does seem to be the best option. Unlike COVID/clinical data use-cases, there's not a goal of minimizing the amount of data in the card, right? Further, the privacy concerns of a server knowing when you used your card are lessoned as well. Josh, how would a "SHC Link" differ from a normal QR card with an https url in it? Or do you mean that you'd just profile the Bundle? or authnz?
Josh Mandel (Sep 24 2021 at 20:25):
7089 characters
This is beyond the usable range that you'll get out of QRs. I'd stick to V22 or lower.
Grahame Grieve (Sep 24 2021 at 20:28):
the workflow is a whole lot simpler if you don't need links. But I suspected that you would get there... I was leading towards that conclusion slower than Josh went there.
Grahame Grieve (Sep 24 2021 at 20:30):
if it's a QR code link... it's just a URL? A quick assessment in my head says that there's not really a need to sign the URL, since it's the integrity of the target that matters. You just need to wrap it with an identifying protocol so it gets handled right?
Grahame Grieve (Sep 24 2021 at 20:31):
@Josh Mandel still would use shc:/ for the protocol benefits?
Josh Mandel (Sep 24 2021 at 20:39):
Just a URL is not great unless you have a good process for managing expirations -- and those goal of de-activating the URL can conflict with the goal of allowing long-term access to the data for some recipeints. I have a bunch of thoughts here, all 10% baked. (For background, we considered some options for links back before we launched the SHC 1.0 spec, and ultimately decided against it, which was absolutely the right call given our 1.0 focus.)
Josh Mandel (Sep 24 2021 at 20:40):
My update recent thoughts (from, like... this week) are at https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q?both (you should probably just squint at and ignore the GNAP stuff in there -- this was mainly an excuse for me to take a closer look at how GNAP is coming along, and I like what I see but it's early days.)
Josh Mandel (Sep 24 2021 at 20:41):
This kind of thing will need a lot focus and scoping, and some reference implementations to give us a feel for it. So I'm definitely not proposing anything at this stage, just noodling (and now... noodling out in the open).
JP Pollak (Sep 24 2021 at 20:43):
are there cases where it would be useful to put some of the clinical data along with the URL in the QR? for partial offline support, for example?
Josh Mandel (Sep 24 2021 at 20:45):
Yes, I think if we have a way of doing "persistent links" on their own, then having a way to stick such links into a "regular 1.0" health card alongside the fhirBundle makes good sense.
Isaac Vetter (Sep 24 2021 at 22:01):
Josh, the "claiming" of a link to enable single or limited uses is really neat. The AS encrypts and generates the QR with the decryption key, right? Is it therefore able to decrypt the file?
Josh Mandel (Sep 24 2021 at 23:55):
The AS encrypts and generates the QR with the decryption key, right
Not quite -- whoever uploads the file to the server would (could) encrypt it prior to upload. If you want your AS to handle this, then sure it'd have access to the raw data. But the proposed design allows for separation.
Josh Mandel (Sep 25 2021 at 00:15):
I see how my write-up is confused on this point though; the (minimally scoped) authorization server would only provide part of the data for the QR code and not actually generate the full thing. Client would insert any description key
Josh Mandel (Oct 08 2021 at 22:42):
Figured I'd record a quick video sketching out this design space as I see it. I think there could be tie-ins with projects like CARIN's digital insurance card, HL7 advance directives, and other patient access initiatives. Would love to get feedback or questions on the concept.
From the YouTube description...
This is a quick design sketch for a data sharing concept I'm calling (for now) 'SMART Health Links". It's intended as the starting point for a broader conversation; my goal is to provide a few specific examples while leaving the concept open-ended so we can explore where else it might fit, or how it might morph into something different.
Design goals: https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q
API sketch: https://hackmd.io/qx2capMpSTSz488f8juf_A
Prototype: https://github.com/jmandel/shclinks
Last updated: Apr 12 2022 at 19:14 UTC
