Stream: smart/health-cards
Topic: QRcode document
Rob Resendez (Apr 29 2021 at 18:25):
Was kicking around the idea of using some endpoint in FHIR to generate the document we given to a patient which contains the QRcode for the VC... perhaps via $docref (https://www.hl7.org/fhir/us/core/OperationDefinition-docref.html)
General thoughts on that?
Assuming there arent' any big holes there, I'm kinda struggling w/ what the appropriate "type" parameter would be. Anyone know what c80-doc-type-codes would be appropriate here?
Josh Mandel (Apr 29 2021 at 18:29):
We define a FHIR operation today for issuing Health Cards; I think you're saying you'd also want a FHIR operation that retuned a QR image? Or A PDF?
Rob Resendez (Apr 29 2021 at 18:46):
Yes, the goal here is to create a document containing the qrcode(s) as needed
Probably pdf given that we must break up qrcodes into chunks, but could be html if the qrcode images used base64 data uris
Josh Mandel (Apr 29 2021 at 18:58):
Who would be the consumers of this API?
Rob Resendez (Apr 29 2021 at 19:10):
As it stands there seems to be an opportunity for some of our various applications or workflows (practitioner and patient facing) to make use of this so they don't all have to go through the effort of knowing how to chunk qr codes and what not... You have various tech stacks so sharing libraries isn't necessarily an option and an api seems like a good solution.
I have also been thinking that some automation that creates a docref record would be a good way to make this document available "for free" in patient portals that already read document reference / binary... So presumably a "system access" profile could be creating that document when immunization data is changed.
So, no real concrete cases as of yet... Just thinking there are some opportunities here. Was conducting a code review and noted that we have this chunk of code that I know we will need in other areas
_edit_ that chunk of code currently calls issuevc, and so the notion was that it could call something else in the fhir layer and save some subsequent steps
Josh Mandel (Apr 29 2021 at 19:40):
Makes sense; I might suggest pursuing this as an internal API and seeing if there are patterns worth generalizing across systems.
Shannon Locklear (Jun 30 2021 at 16:28):
Hello! I've been modeling the examples here https://github.com/smart-on-fhir/health-cards-designs/ to create a pdf of the SMART Health Card.
Currently, we are working on the COVID-19 Vaccination Record Card and also a Full Vaccination Record Card.
Should the example be followed for ALL different types of SMART Health Cards or is this example specific to COVID-19 or vaccinations?
Josh Mandel (Jun 30 2021 at 16:57):
Re: "Full Vaccination Record Card", our general advice is not to group records unless a use case requires it. So, general advice would be to have a card for each vaccine, since cards can only be shared wholesale. See https://spec.smarthealth.cards/#granular-sharing for background
Josh Mandel (Jun 30 2021 at 16:58):
On the reference designs: they should be a good starting point for any vaccine cards, though certainly there has been more attention/focus on COVID-19 specific issues. If you run into anything surprising or if questions come up, please raise them; we'd like these to be as generally useful as they can!
Josh Mandel (Jun 30 2021 at 16:58):
(Oh, and welcome @Shannon Locklear !)
Shannon Locklear (Jun 30 2021 at 17:02):
Josh Mandel said:
(Oh, and welcome Shannon Locklear !)
Thank you for the welcome! :)
Last updated: Apr 12 2022 at 19:14 UTC
