Stream: implementers
Topic: Extending ServiceDeliveryLocationRoleType Value Set
Øyvind Aassve (Nov 29 2021 at 07:30):
We need to notify the patient that an appointment might be by video or telephone. The proposal is to use Appointment.participant.actor.Location.type and extend the value set ServiceDeliveryLocationRoleType with values for video and telephone. Australia has already made an extension for virtual http://hl7.org.au/fhir/2021Aug/CodeSystem-au-location-type.html. Could these values be added to the HL7 value set? If so, is this an issue for PA or Vocab? @Brian Postlethwaite @Rob Hausam
René Spronk (Nov 29 2021 at 07:38):
Have you looked at the Danish guide? What are they doing? https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-videoappointment.html
Øyvind Aassve (Nov 29 2021 at 09:28):
@René Spronk - have looked at it. For now we think it would suffice with communicating the fact that it is video or phone in structured format. Would prefer to do that in Location.type to avoid extensions (hence proposal to include codes in ServiceDeliveryLocationRoleType). Might be need for a broader set of structured data in the future - the danish work would be a good foundation then.
René Spronk (Nov 29 2021 at 10:19):
OK. the proposed Australian value certainly makes sense.
Lloyd McKenzie (Nov 29 2021 at 23:20):
I don't understand putting the extension on Location. A Location's involvement in an appointment is to say "this appointment will occur in this room". If you want to capture that certain participants will be remote (by web-meeting, phone, etc.), I would think that would be an extension on Appointment.participant, not Location. @Brian Postlethwaite?
Brian Postlethwaite (Nov 29 2021 at 23:48):
I think the intension is that it is a virtual room. So seems ok to me. And often the details of that shared virtual room need to be managed/scheduled, and location fits that bill too.
Lloyd McKenzie (Nov 30 2021 at 02:14):
Ah. If that's the intent, then that makes sense.
Øyvind Aassve (Nov 30 2021 at 08:54):
Our intent is as Brian says to indicate that the location is in a virtual space. I see that there is a slight difference in the our proposal in that we were thinking to add coding values to Location.type instead of Location.physicalType as Australia has used. @Brian Postlethwaite
Brian Postlethwaite (Nov 30 2021 at 08:59):
I thought I had a tracker for the core spec too, I'll have to check.
Øyvind Aassve (Dec 17 2021 at 11:00):
FYI @Brian Postlethwaite - HL7 Norway TSC ended on extending the ServiceDeliveryLocationRoleType Value set with two codes for video and telephone in the no-basis-Location-profile.
Thomas Tveit Rosenlund (Dec 18 2021 at 10:15):
Øyvind Aassve said:
FYI Brian Postlethwaite - HL7 Norway TSC ended on extending the ServiceDeliveryLocationRoleType Value set with two codes for video and telephone in the no-basis-Location-profile.
I think we should stick with the australian model, and have only one kind of location (virtual) for virtual locations. Endpoints and communication channel types should be handled elsewhere in my opinion.
Thomas Tveit Rosenlund (Dec 18 2021 at 10:24):
You have chosen different approaches in Australia @Grahame Grieve , care to elaborate?
@Jens Villadsen you have created the virtual appointment and might have some input as well?
The current proposal for the no-basis-Location draftet here: https://thomiz.github.io/fsh-no-basis/no-basis/CurrentBuild/StructureDefinition-no-basis-Location.html
The only real change is the extension of the LocationType CodeSystem.
Jens Villadsen (Dec 18 2021 at 10:56):
@Thomas Tveit Rosenlund - in our defacto national DK telemedicine solution we have taken a bit of a different approach. We have 4 different profiles due to four different business cases:
https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-group-appointment.html https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-group-videoappointment.html https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-videoappointment.html https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-appointment.html
@Brian Postlethwaite - how can a location be virtual if the following is stated on Location:
image.png
http://hl7.org/fhir/R4/location.html does not mention the word 'virtual' at all.
In our setup, the location resource plays a minor role, hence it is not profiled at all and used only as a contained resource for now. The 'location' of eg. the video appointments are contained within the appointment as extension as the 'location' is of paramount importance for the video appointments.
@Thomas Tveit Rosenlund @Øyvind Aassve - your two extra values in your valueset are described as 'two-way' stream. I get the intention, but technically what if multiple attendees are present during a video conference is it then still a 'two-way' stream or a multistream/something else?
Brian Postlethwaite (Dec 18 2021 at 11:20):
We would like to also have this discussion at the WGM if there are enough folks interested to pick it up there too?
Øyvind Aassve (Dec 18 2021 at 15:29):
@Brian Postlethwaite - WGM-topic on this would be appreciated. Would be good with some clarifications and agreements around how to best represent different kinds of virtual appointments (video, phone etc) and their connection details.
Øyvind Aassve (Dec 18 2021 at 16:22):
@Jens Villadsen - good point. Two-way is anyway implicit in video/telephone communication.
Thomas Tveit Rosenlund (Dec 19 2021 at 09:17):
Jens Villadsen said:
Thomas Tveit Rosenlund Øyvind Aassve - your two extra values in your valueset are described as 'two-way' stream. I get the intention, but technically what if multiple attendees are present during a video conference is it then still a 'two-way' stream or a multistream/something else?
Good point.
You did not consider using Endpoint to model the information conserning the url's and metadata for the virtual meetings @Jens Villadsen ?
Thomas Tveit Rosenlund (Dec 19 2021 at 09:20):
Deleted message
Jens Villadsen (Dec 19 2021 at 09:28):
We didn't. To me it seems a bit convoluted to add a reference to a location that references and endpoint, just to hold a url - but I'll throw in some reconsideration
Jens Villadsen (Dec 19 2021 at 09:29):
it makes it way harder to enforce business constraints not having the values in the extension
Brian Postlethwaite (Jan 20 2022 at 19:12):
This is the tracker that we're following this topic with
https://jira.hl7.org/browse/FHIR-33341
Brian Postlethwaite (Jan 20 2022 at 19:14):
And over lunch I've had more thinking on this, and I'm leaning away from a common datatype between them, and instead having a similar (but not the same) backbone element on both Appointment and Location.
(which also makes the including a location reference on the part in appointment more sensible, as having it on a datatype in location means pointing to itself, or wanting to exclude it)
I also think that the likes of the guest pin or session ID/key property wouldn't belong on the location backbone, but instead on the appt backbone.
Brian Postlethwaite (Jan 20 2022 at 19:15):
@Øyvind Aassve @Thomas Tveit Rosenlund @Cooper Thompson @Sonja Ziegler thoughts?
I was about to draft some of this up into a local build of the core R5 spec to visualize
Øyvind Aassve (Jan 20 2022 at 20:59):
@Brian Postlethwaite - I like the idea to bundle the data in a datatype. I didnt get the main argument for including the datatype both in Appointment and Location. As Location is an integrated part of Appointment it could be perceived as somewhat confusing for implementers where to put virtual telecon data and implementations will vary. Why not try to force a common place (Location :smile: ) for the information (I think most people do not pay attention to wheter a conference service has a fixed url or not .......)
Thomas Tveit Rosenlund (Jan 21 2022 at 07:37):
@Øyvind Aassve The logic for including this in the Location in addition to having it in the Appointment is for different needs.
Booking of teleconference equipment or static communication channels vs virtual meetings where every url are unique and you don't have to book it, just include information about how to connect to the meeting (like the danish solution).
@Brian Postlethwaite
I really liked the idea of a common datatype, but you might not want to use that for the Location resource, but I believe it might be useful for other resources where information concerning virtual connection details could be useful. I am quite shure it is not only relevant for Appointments?
Last updated: Apr 12 2022 at 19:14 UTC
