FHIR Chat · Patient Subscriptions in a PHR · Subscription (retired)

Stream: Subscription (retired)

Topic: Patient Subscriptions in a PHR


view this post on Zulip Andy Kendall (Mar 20 2018 at 16:09):

Hi - looking for any advice or insight people may have regarding the ability to allow Patients to subscribe to changes in their own FHIR based Personal Health Record.

For example; a patient wants to be informed by SMS when an appointment is created in their record. The subscription resource at first glance seems to be appropriate - the parameters specified include one for subject=patient. We can ensure that parameter must be specified through API access control so that patients only get notifications of their own appointment. The only problem is that they also need to be able to manage the subscriptions they have created - but subscription has no concept of 'owner' or subject - so how would it be possible to query all the subscriptions that a given Patient has created?

I also considered CommunicationRequest - this does have recipient but seems to be more about a request to send a piece of information rather than a request to receive a notification when information is added to the PHR.

Any suggestions on how this can be implemented are appreciated.

Regards,

Andy

view this post on Zulip Grahame Grieve (Mar 20 2018 at 19:09):

have you looked at provenance?

view this post on Zulip John Moehrke (Mar 20 2018 at 19:48):

Would seem to be a useful kind of Subscription... I guess generically it would be a Subscription to a compartment? Where you have a specific instance of a subject compartment.

view this post on Zulip Andy Kendall (Mar 21 2018 at 08:58):

Yes I think that's it - although I would say it is already possible to create a subscription to a compartment by specifying the correct criteria e.g. Appointment?patient={patient id}. What would be useful is to be able to create the Subscription within a compartment - one way would be to add a new data element "Subscriber" which is a reference of type Patient, Practitioner, Device etc.

view this post on Zulip Andy Kendall (Mar 21 2018 at 09:03):

have you looked at provenance?

Thanks Graheme - yes I guess Provenance could be used for this - and perhaps that is the answer for our purposes today. Although it seems a little like a workaround - would the addition of a "Subscriber" element as I have described in response to John be worth consideration?

view this post on Zulip Grahame Grieve (Mar 21 2018 at 11:42):

you could certainly create a task for that. I'm interested to see other comments here about the idea... would it be linked to access control?

view this post on Zulip Andy Kendall (Mar 21 2018 at 13:17):

For us it would be linked to access control in that users would only be able to perform CRUD operations on Subscription resources within the compartment(s) that they have access to. I'll wait a day or two for any further opinions and then add a task on gforge.

view this post on Zulip John Moehrke (Mar 21 2018 at 16:04):

It might seem logical to an app to be able to just ask a Server to notify it when ever anything that the app has rights to is available... however this is a very difficult thing to do in practice. In other threads this kind of asking for everything the app has rights to is seem as a shortcut to the app design being done following privacy-by-design, security-by-design, and overall having a clear scope of what the app really needs.


Last updated: Apr 12 2022 at 19:14 UTC