Stream: implementers
Topic: tumor conference
Patrick Werner (Jun 12 2019 at 12:28):
continuation of this thread: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/FHIR.20Community.20navigation.20help
(opened new one for a proper topic heading)
Does your tumor conference software represent regular encounters as well?
not right now, but will possibly handle chemotherapy encounters in the future
Certainly we'll need a computable means of distinguishing the patient-centric from non-patient-centric events if we do decide to use a single resource for both concepts.
I see multiple caradinalities in tumor boards: the appointment for the conference itself (invitation to participating physicians), the appointment for every patient (to track which patients will be discussed).
For the resulting encounters this could be the same, one Encounter for the whole conference and one encounter for every patient discussed.
Patrick Werner (Jun 12 2019 at 12:38):
The linkage between the higher level encounter and the patient specific encounter could be made trough part-of. For Appointments there is no part-of so we would need an extension.
Stefan Lang (Jun 12 2019 at 12:50):
Would an Appointment for each Patient make sense?
Usually the patients do not participate in "their" tumor conference, so would they even be a "participant" in such an Appointment resource?
Or, if it is agreed that they are "participants": why not put all patients into the single Appointment instance?
It's still the same 5 doctors talking about 10 patients in the same room and timespan.
I would tend to represent the patient specific "Appointment" (i.e. "we plan to talk about Patient X during that conference") as an Encounter of status=planned, but I suspect that might not be the way to go from the FHIR workflow perspective.
Patrick Werner (Jun 18 2019 at 10:49):
To us the patients are participants, as we need to track which patient will be discussed in which conference meeting.
Also we can't use one Appointment for all participants/ the whole conference as we want to support external patients/physicians which are only allowed to see the data of their own patient (captured in the appointment).
So our current working theory is:
- One parent Appointment for the conference itself (can be set to weekly)
- multiple sub Appointments (one for each patient) pointing to the parent
- same for Encounter
Open questions:
- How to link Appointments together
- Appointment has no repeating/scheduling options. We want to capture things like: Appointment occurs every week
Lloyd McKenzie (Jun 18 2019 at 16:53):
@Brian Postlethwaite
John Moehrke (Jun 19 2019 at 16:35):
The security constraint you are trying to enforce -- a participant in an appointment can't see who else is in that same appointment -- seems unusual. Your solution (cascade of appointments) is logical potential solution. However do you really need the sub appointments to be full appointments? Does this security constraint need to be enforced at the interop layer, or can it be a business-rule enforced in the application? I guess it could be implemented much like BCC field in e-mail in that when the appointment notification is sent, each copy is targeted but doesn't include the other BCC identifiers, and thus only the original author has the full BCC.
Last updated: Apr 12 2022 at 19:14 UTC
