Stream: implementers
Topic: Appointment hidden for patient
Allan Bro Hansen (Oct 09 2018 at 15:42):
I would like some input for this business scenario:
A doctor examines the results (X-rays, lab results) for a patient and determines that the patient has cancer, and that treatment is needed.
The patient already has an appointment for a follow-up consultation tomorrow, but the Doctor determines that quick treatment is important and therefore:
a) books an appointment for the patient in 2 days to perform the first chemotherapy; and thereby making a reservation for the needed devices, location and personal.
The chemotherapy-appointment is of course highly sensitive and should not be exposed to patient before the patient has been informed (exposure could e.g. happen via a "Show my Appointments"-app).
How to handle this "do not expose" at the FHIR-appointment-resource?
Is this best modeled via security labels (https://www.hl7.org/fhir/security-labels.html) and the confidentiality codes?
(One could also argue that the chemotherapy-appointment is just in status proposed since the patient has not accepted the appointment, as he hasn't even been informed. The normal procedure here in Denmark is however just to book the appointment as patients are in general expected to show up and a patient acceptance is not needed)
(I have however been considering the appointment patient participation status needsAction - but needsAction is just not the same as patientNotInformed)
b) After the consultation the patient is informed (and gives his consent to the treatment)
Now the appointment can safely be exposed to the patient.
Handling of this at the FHIR-appointment-resource?
- change of the security labels and a subsequent appointment update or ... ?
Any input/thoughts?
Lloyd McKenzie (Oct 09 2018 at 17:36):
The confidentiality codes would be the only mechanism that would stop a patient from seeing the appointment . 'proposed' appointments might still be visible
Brian Postlethwaite (Oct 09 2018 at 21:07):
Yes, confidentiality or security. I would personally use security tags.
John Moehrke (Oct 09 2018 at 22:44):
This is a case of a Medical Safety or Medical Professional practice to not expose the patient to specifically traumatic information prior to having a face-to-face meeting. One could use security tags, but I would indicate that this is more of a workflow than a security/privacy factor. The FHIR specification enables many possible methods and policies, so you need to define the policy and method within your domain.
- One could use the Confidentiality code of "V" to prevent exposure, however one must be careful that the patient themselves doesn't have access to "V". And one must assure that the code eventually gets removed, like after a timeout or after a workflow event of the face-to-face meeting.
- One could define your own meta.tag value. This might be the safest as it present the best chance to fully manage expectations, prolicy, and method.
- One could manage this with a task resource and business logic that forbids the patient access (rather than security policy, using business logic).
- Lastly, given that FHIR is presenting more than just an Interoperability Interface, there will be more use-cases that need to be addressed within the specification than would normally be addressed in purely an Interoperability specification. Thus it might be best to bring this use-case up for specific standards creation.
Allan Bro Hansen (Oct 10 2018 at 14:58):
Thank you for the inputs,
I did not mention this but in fact the appointment is delivered to an external system which can expose data both to the patient and other clinicians. So security policies should also be adapted by the external system.
Right now I am thinking security labels.
Last updated: Apr 12 2022 at 19:14 UTC
