Appointment extension for conferenceType
thomiz opened this issue · 51 comments
- Hva Extension gjør må dokumenteres som en del av StructureDifinition.description
- Oppmøtetype?
- @line sjekker hva slags kodeverk som eksisterer for dette (tror det er i bruk for Encounter)
- Eksisterer det kodeverk som uttrykker kontakt typer som kan benyttes
- conferenceType er feil navn, betyr at helsepersonell diskuterer noe uten pasienten tilstede
- er dette oppmøte type?
Hei,
Line sjekket, og Australia har utvidet value set på Location.type. Location type har et relativt stort value set, og Australia har tatt et subsett av disse + utvidet med virtuelt. Det vi kan gjøre er å ta et subsett (og gjerne mindre enn Australias), og extende med telefon og video.
http://hl7.org.au/fhir/2021Aug/ValueSet-au-location-physical-type-extended.html
Det som muligens er utforderingen med tanke på vår planlagte implementasjon er at vi allerede benytter Location.type med kode HU (Health Unit) til å sende over post/ poliklinikk med tilhørende avdeling. Appointment.participant.actor.Location.name (Location.type = HU). Uten denne får vi ikke samtidig overført RESH-id på post/ poliklinikk som utfører behandlingen.
@
Ved nærmere ettertanke er vel dette ikke et problem. Vi kan vel uansett bruke RESH-identifikator for post/ poliklinikk selv om Location.type er HU (fysisk oppmøte), VID - video eller TE - telephone. Ved video eller telefonkonsultasjoner kanskje vi kan beskrive telefonnummer/ video URL i stedet for detaljert beskrivelse av oppmøtested i Location.description.
Har luftet om disse kodene bør tas inn i det internasjonale kodeverket:
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Extending.20ServiceDeliveryLocationRoleType.20Value.20Set
Et par litt relaterte saker fra Jira:
https://jira.hl7.org/browse/FHIR-32974 - peker på behovet for å skille mellom sted og intensitet i ActEncounterCodes
https://jira.hl7.org/browse/FHIR-34380 - forslag om å legge til støtte mode of service til PractitionerRole
Use-casene må beskrives, hvorfor trenger vi vanligvis flere participant elementer i instansene.
Foreslår slice av participant som minst må inneholde :
- Locations
- Patient
- Practitioner
Jira issue til HL7 om at Appointment mangler støtte for virtuelle appointments @thomiz
TSK-møte 10.12 - kort oppsummering:
- forslag fra prosjekt. Utvide til et no-basis-Location.type (extensible) med to koder (video og telefon). Appointment..Location.Endpoint kan benyttes for virtuell oppkoblingsinformasjon. Location defineres da som et virtuelt rom - a la forslaget fra Australia.
- alternativt forslag - legge inn valuesett på Encounter.type / Appointment.appointmentType - ex kalt medium - for å tydeliggjøre at det er en type kontakt.
- alternativt forslag - extensjon på Appointment.endPoint for å definere virtuell oppkoblingskommunikasjon.
- alternativt forslag - slice på participant (Thomas - kan du presisere)
Slice på participant kan se slik ut @oaassv :
https://thomiz.github.io/fsh-no-basis/no-basis/CurrentBuild/StructureDefinition-no-basis-Appointment.html
For meg er "Appointment.participant:sted" en Kategorienfehler.
(cf. https://en.wikipedia.org/wiki/Category_mistake)
Dessuten skal man være konsistent i navnbruk: "sted" er ikke engelsk. Hva er det ment med? Location?
Location can not be a participant type: http://hl7.org/fhir/R4/valueset-encounter-participant-type.html
Alle koder der i hl7-ontologi har attributtet "human", tom det underspesifisert kode PART/Participation.
For meg er "Appointment.participant:sted" en Kategorienfehler. (cf. https://en.wikipedia.org/wiki/Category_mistake) Dessuten skal man være konsistent i navnbruk: "sted" er ikke engelsk. Hva er det ment med? Location? Location can not be a participant type: http://hl7.org/fhir/R4/valueset-encounter-participant-type.html Alle koder der i hl7-ontologi har attributtet "human", tom det underspesifisert kode PART/Participation.
Dette er en del av standarden. Appointment.participant kan inneholde HealthcareService og Location i tillegg til Practitioner og Patient, så du kan kanskje lage en jira issue til HL7 international? Isåfall må oppmøtested og eventuelt kontaktpunkt inn et annet sted i strukturen.
Jeg har fikset på språkbruken i siste build, men bare for slice navnene. Resten for HSØ ta seg av @oaassv
Ja, det er det som er kanskje litt bedre modellering. Takk for svaret.
@thomiz - begrenser vi ikke unødvendig ved å slice i References. Vi ønsker vel å holde basisprofilen åpen for også å kunne booke HealthCareServces, RelatedPersons etc i fremtiden?
@thomiz - begrenser vi ikke unødvendig ved å slice i References. Vi ønsker vel å holde basisprofilen åpen for også å kunne booke HealthCareServces, RelatedPersons etc i fremtiden?
@oaassv Det er ingenting i den forslaget til slice definisjon som tilsier at RelatedPerson og HealtcareService ikke kan benyttes i tillegg, slicen er åpen.
Definisjonen sier bare at avtalen bør inneholde informasjon om hvilke(n) helsearbeider, hvilke(n) pasient og hvor avtalen skal inntreffe. Det er heller ingen av disse som er påkrevde.
@thomiz Litt usikker på om jeg ser poenget med at basisprofilene skal differensiere mellom mulige referanser på denne måten, selv om det er de viktigste deltakerne i en Appointment. Deltakere vil vel uansett bli gitt av brukerbehovene i det enkelte case.
TSK stemte for å representerer virtuelle møter ved å legge til to koder for video og telefon i Location.type.
Ikke endelig konkludert på slicing, men det stilles spørsmål om det er nødvendig i no-basis som skal være genersisk og holde flest mulig dører åpne.
Ikke endelig konkludert på slicing, men det stilles spørsmål om det er nødvendig i no-basis som skal være genersisk og holde flest mulig dører åpne.
Husk at slicing ikke lukker noen dører. Det er to forutsetninger for å holde dørene åpne:
- så lenge slice definisjonen er open
- Det stilles ikke "harde" krav i forhold til kardinaliteten for noen av slicene ( slik som 1..1, 0..0 osv)
TSK stemte for å representerer virtuelle møter ved å legge til to koder for video og telefon i Location.type.
Betyr dette at også no-basis-Location profilen skal endres til å benytte det nye ValueSet'et?
Yep, endringen blir i no-basis-Location.
Engelsk?
| video | Video | Any two-way video+audio communication/conference system |
| telephone | Telephone | Telephone or other two-way audio communication |
Engelsk?
video Video Any two-way video+audio communication/conference system
telephone Telephone Telephone or other two-way audio communication
Bygger nytt forslag nå.
Flott,
jepp, synes det er gode definisjoner. Ut fra de andre kodene i kodeverket kan kanskje kodeverdiene avkortes til VID og TEL e.l.
Som jeg har alerede nevnt på webinar, werken "conferenceType" eller disse to verdier er riktige: begge er av samme type feil: https://en.wikipedia.org/wiki/Category_mistake.
Som jeg har alerede nevnt på webinar, werken "conferenceType" eller disse to verdier er riktige: begge er av samme type feil: https://en.wikipedia.org/wiki/Category_mistake.
Jeg er enig med @cgerno. Dette er feil sted å ha informasjon om virtuelle avtaler. En bedre løsning er å tilrettelegge for virtuelle avtaler vil være en extension mens vi venter på at R5 (forhåpentligvis) legger til rette for Endepunkter istedenfor Locations i Participant. Grunnen til at vi gjør dette slik nå er vel etter au-base eksempelet:
http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-location.html
Au base legger til koder for virtual i kodeverkene for Location.type og Location.physicalType.
Å skille mellom "Location.type" og "Locatinon.physicalType" er nonsense, alt location er enten physical ('locus' er latinsk for 'place') eller metaforisk når man snakker om tid (location in time).
Når man analysere Location.no-basis-type, ser men at det er ingenting av en pyttipanne av subkatogorier av physicalType og communicationChannel.
Som "bevis" på det: telephone can ikke våre både location og communicationChannel (= medium).
Men se her: HL7 har typisert telephone som channel:
https://www.hl7.org/fhir/communication.html
deretter
https://www.hl7.org/fhir/communication-definitions.html#Communication.medium
deretter
https://www.hl7.org/fhir/v3/ParticipationMode/vs.html
PHONE | telephone | Participation by voice communication where the voices of the communicating parties are transported over an electronic medium
Det er veldig viktig å kikke på andere land extensions, hvis det trengs, men man skal lære av demers feil òg.
Hvis vi, menesker som jobber med å modellere FHIR, ikke har en god felles semantisk forståelse, så kan man ikke forvente at systemene kommer til å kunne samhandle godt semantisk.
Faktisk, etter å ha lest dokumentasjonen på Endpoint og Location igjen, holder jeg en knapp på at australienerne har rett. Men at det kanskje mangler en mulighet til å uttrykke kommuniksajonskanal i Endpoint/Location. Synkrone kanaler er ihvertfall helt utelatt fra connectionType kodeverket
Vi må se på alternativene i litt større detalj før vi tar noen avgjørelser her tror jeg. Danskene har virtuelle appointment profil
Og Australienerne har også en annen måte å løse dette på med virtuelle lokasjonstyper.
Jeg tror vi bør holde oss til et av disse forslagene og uttrykke kommunikasjonskanal/modus et annet sted en i Location. Kanskje forsøke å koble på Jens og Grahame i diskusjonen på chatten
Synkrone kanaler er ihvertfall helt utelatt fra connectionType kodeverket
Når det gjelder REST-API så er en FHIR-referanse er et endpoint i seg selv, så i så tilfelle er det ikke nødvendig.
Jeg tror endpoint og connectionType er et sidespor for telefon/vide, det handler om data, ikke folk.
Enig med @rockphotog, veldig viktig å skillle mellom data og folk.
@thomiz, kan du sender URLen for dokumentasjonen av australsk modellering du snakker om?
Forresten @thomiz, alle har rett, det er ikke sånn at bare vi har rett men ikke dem i Australlia eller Danmark,
poenget er om man modellere verden på samme måte, eller for å snakke som min Informatikk-professor i gamle dager: Do we all commit to the same ontology? Det er mange måte å dele verden på. Igjen, hvis vi ikke gjør det så slår hele tiltaket med semantic interoperability between e-health systems klikk.
Det er ikke om hver har rett eller ikke, det er om vi klarer så vidt å få samme bild av verden vi prøver å modellere.
kan du sender URLen for dokumentasjonen av australsk modellering du snakker om?
Den skulle egentlig vært med i en av de forrige postene @cgerno au-location
Jeg tror endpoint og connectionType er et sidespor for telefon/vide, det handler om data, ikke folk.
Slik jeg tenker på det så er en virtuell lokasjon uten et angitt endepunkt helt ubrukelig for de som faktisk skal delta på avtalen og gjennomføre videosamtalen. En videosamtale er bare en annen kommunikasjonsform ved hjelp av data. Verken Location eller Endpoint handler om folk. Det ene er en lokasjon og det andre er et endepunkt for kommunikasjon. Men husk både endepunkt og lokasjoner skal BRUKES av folk og/eller systemer, enten til kommunikasjon via endepunktet, eller for å finne/angi en lokasjon. Det er godt mulig det mest presise er å angi en endepunkt knyttet til en lokasjon. Altså å angi endepunktet for videokonferansen i Location.endpoint.
Hvis jeg forstår dere rett så ønsker man benytte Location.endpoint for å angi URLen til videotjenesten. Det virker i så fall ikke være i henhold til hensikten til Endpoint.
An endpoint describes the technical details of a location that can be connected to for the delivery/retrieval of information.
Ser egentlig lite som klaffer av informasjon på Endpoint som er relevant for å koble seg opp til en videotjeneste eller annen type URL-basert tjeneste der en bruker initierer den ved å klikke på en lenke.
@thomiz, takk for URLen. Når du hevder at "Verken Location eller Endpoint handler om folk." det er ikke som jeg forstår verden. Alt fysiske har en Location. Er Address ikke en location for folk? Om nøyaktig (location of a patient in a hospital, which room, which bed) eller mindre nøyaktig (location of a hospital complex). Det handler om detaljnivåt (granularity) man trenger for beskrivelse. Virtual location er ubrukbart. Alt virtuelle/digitalt er avhengig av hardware, som igjen har en location.
Og jeg er enig med @kennethmyhra når han mener at Location.endpoint er ikke innlysende. På et sjenerelt nivå, betyr disse modellering at alle locations (eller locations of encounters) har eller kan ha endpoints.
@cgerno I forbindelse med en avtale (Appointment) er det like relevant for folk å kjenne til endepunktet de skal koble opp til som å vite at lokasjonen er virtuell (eller fysisk lokasjon for fysiske møter). Så slik sett er både lokasjon og endepunkt anvendelig for folk tenker jeg.
Jeg tror også en virtuell lokasjon er brukbar tilnærming, men at man finner endepunktet (url-adressen) man skal koble opp mot i location.endpoint er ikke helt innlysende som du skriver. Jeg er dessuten usikker på om det er meningen vi skal bruke Endpoint ressurser til denne typen kommunikasjon siden de ikke er med i [connectionType kodeverket](https://hl7.org/fhir/R4/valueset-endpoint-connection-type.html . Det var også derfor jeg spurte litt om det på chat'en.
@thomiz Da må man angi en definisjon av virtual location, for å forstå hva er ment med det.
Igjen, location av en avtale kan ikke være virtuell. Jeg venter på definisjonen for å prøve å forstå hva er ment med "virtual location".
Dette er PSEUDO-kode bare et illustrerende eksempel på hva jeg tenker rundt use case. Innbygger for informasjon om oppkobling som kan brukes av app, portal etc. - og med alternativ (hvis ikke video virker, ring dette nummeret).
{ "ring-opp!" :[
{ "type" = "videomøte"},
{ "app" = "Zoom"},
{ "oppkobling" = "https://helsesørøst-videotjeneste.no/123456780"},
{ "rangering" : 1 }
]},
{ "ring-opp!" :[
{ "type" = "telefon"},
{ "oppkobling" = "+4712345678"},
{ "rangering" : 2 }
]}
Ser jeg på Location tror jeg vi rett og slett kan bruke Location.telecom. Den kan kodes med ContactPoint / contact-point-system og url. Burde dekke alt over.
Så blir diskusjonen hvordan man koder er det er dette som er den faktiske "location" og ikke bare halv-implisitt ved at kun telecom er med i Location. En kode-utvidelse av Location.type virker fortsatt logisk.
Enig @rockphotog ContactPoint (Location.telecom) virker som et naturlig sted å legge kontaktinformasjonen for en videokonferanse. Dessverre virker ContactPoint.use valueset'et å være svært gammeldags og ikke egentlig egnet til å gjenspeile videokonferanse kontaktpunkter: home | work | temp | old | mobile - purpose of this contact point
url kan benyttes
A contact that is not a phone, fax, pager or email address and is expressed as a URL. This is intended for various institutional or personal contacts including web sites, blogs, Skype, Twitter, Facebook, etc. Do not use for email addresses.
Burde dekke oppkoblingslenker til videotjeneste, som vil ligge i ContactPoint.value.
EDIT: Blir veldig "langt"/mye ressurser for bare å lage en telefonavtale, men slik er FHIR. Mulig en områdeprofil for telefon/video-avtale for dette bør være contained så den kan bli så kompakt som mulig.
Er er ikke enig, igjen, man blander i hop location og channel/medium.
@rockphotog joda, en url vil løse problemet. Det jeg reagerte på spesielt var at ingen toveis kommunikasjonsformer var nevnt i forbindelse med url, og da blir ihvertfall jeg usikker på om det er noe de tenker skal ligge i forbindelse med den koden. Synes det er litt gammeldags å ikke tenke på toveis kommunikasjon via en oppkoblingslenke som en mulighet i forbindelse med kontaktpunkt, spesielt når både telefon og fax (huff) er med.
Danskene har foreløpig valgt å løse det med extensions (ikke contained) på selve Appointment ressursen: ehealth-videoappointment
Kanskje foreslå ContactPoint på selve appointment i WGM pluss noen utvidelser av appointmentType kodeverkene?
Danskene har en ren, fin modellering av virtual-appointment, som er kongrunet med min verdensbild.
Også HL7 Appointment er klar når det gjelder location.
The location of the appointment is to be defined by using a participant that references a Location or HealthcareService resource.
Helt tydelig, helt forståelig for meg.
Jeg ser et stort rødt flagg med alle extensions til danskene :-)
@cgerno Takk, jeg så det, så jeg slettet spørsmålet mitt fort, hehe.
Det er det som @thomiz har limt inn her.
Danskene har foreløpig valgt å løse det med extensions (ikke contained) på selve Appointment ressursen: ehealth-videoappointmen
@rockphotog helt enig med deg om extensions, men i alle fall er det rent modellert.
Jeg liker ikke extenstions i det hele tatt. Man må spøre seg, om man kenner FHIR så godt for å hevde at man trenger extensions. Jeg kan ikke si dette om meg.
Den danske profilen med så mange extensions ser ut som et forslag til en helt ny ressurs. Enten en ny ressurs VirtualAppointment, eller at extensionene inkluderes som nye attributter/elementer på Appointment i R5 eller R6. Det kan i så fall rettferdiggjøre den store bruken av extensions i R4.
Danskene burde, om det ikke allerede er gjort, ta disse utvidelsene opp med arbeidsgruppen Patient Administration som jeg antar eier ressursen.
For meg ser det ut som en del av ekstensjonene til danskene egentlig allerede er dekket av ressursen (responsible, performer, organization etc). Location.telecom ser ut til å fungere så lenge det vi trenger er en URL for video - noe som for nå er tilstrekkelig for kravene jeg har sett så langt mot innbyggere. Hvis vi greier oss med dette greier vi oss uten ekstensjoner - og kun ekstra kode for Location.type. Clean!
Danskene har med en del ekstra elementer for oppkobling som kan bli utfordrende å få inn i Location.telecom.
@cgerno - er du enig i at Location.type virtuell er ok så lenge vi ikke spesifiserer kanal (video/ telefon)?
@oaassv - nei, jeg er ikke enig med Location.type virtuell, selv men ikke spesifiserer kanal.
Det er helt tydelig i ressursbeskrivelse Appointment:
The location of the appointment is to be defined by using a participant that references a Location or HealthcareService resource.
Hvis man vil ha en Location.type=virtuell, betyr det at deltaker kan være virtuell. Som sagt, dokker kan modellere som dokker vil, men jeg kommer SIKKER ikke til å bruke slikt, i tilfellen det ble godkjent.
@kennethmyhra - for meg ser sånn ut, at danskene (og andere som bruker ekstensivt extensions) ikke kenner seg til alt detail om ressurser. Jeg er 80% sikker at man kan modellere dette uten extension.
I denne diskussionen savner jeg saklig argumentasion for alt man hveder. Why to do so? Hvorfor
trenger man extension dokker prøver å pusje. Har dokker prøvd å pytte inn alle infos som dokker tror man vil
ha dem i alt som alerede finnes?
Jeg husker at båder @thomiz og @oaassv har oftee vist slides med best practice, så mitt spm er:
kan folk som vil ha extensions først bevise at de trenger dem?
Altso:
(1) proof that there is NO place in ANY ressource for the very specific info
(2) proof that there is NO extension with the same purpos in the extension registry
(3) proof that there IS real need for the info in a specific country/domain/etc. (man må kartlegge dette med data fra legekontorer/sykehus/etc.)
Hvis man vil ha en Location.type=virtuell, betyr det at deltaker kan være virtuell. Som sagt, dokker kan modellere som dokker vil, men jeg kommer SIKKER ikke til å bruke slikt, i tilfellen det ble godkjent.
Hvis det blir vedtatt som no-basis, så blir det også nasjonal standard så da bør du jo absolutt benytte deg av de strukturene som blir vedtatt, selv om du personlig er uenig. Vi kommer ikke til å gjøre noe kontroversielt i no-basis uten å sjekke det nøye med det internasjonale miljøet. Og det kan jo være gode grunner til at Danskene og Australienerne har gjort som de gjør og da bør vi gjøre det på en lignende måte. Det er også slik at endel av disse ressursene er relativt umodne, og det virker ikke på meg som virtuelle møter er godt håndtert i strukturene, og det taler for at ressursene i standarden kanskje bør endres. Men det er en sak for WGM/HL7 International.
I denne diskussionen savner jeg saklig argumentasion for alt man hveder. Why to do so? Hvorfor trenger man extension dokker prøver å pusje. Har dokker prøvd å pytte inn alle infos som dokker tror man vil ha dem i alt som alerede finnes? Jeg husker at båder @thomiz og @oaassv har oftee vist slides med best practice, så mitt spm er: kan folk som vil ha extensions først bevise at de trenger dem? Altso: (1) proof that there is NO place in ANY ressource for the very specific info (2) proof that there is NO extension with the same purpos in the extension registry (3) proof that there IS real need for the info in a specific country/domain/etc. (man må kartlegge dette med data fra legekontorer/sykehus/etc.)
Aller først, det er ingen som pusher extensions. Det er foreslått noen extensions for informasjon som man tror mangler i ressursen i forhold til de behovene prosjektet har. Man skal alltid vurdere extensions nøye men i en god del sammenhenger blir man oppfordret til å lage nasjonale extensions for informasjon som faller utenfor den internasjonale standarden, siden use-caset bare gjelder et spesifikk nasjon/bruk.
Punkt 1 blir vel ikke helt riktig. Selv om man kan modellere noe i en eller annen ressurs, betyr ikke det at det er en god modell å legge ekstra ressurser inn som Bundle eller Contained, spesielt gjelder dette enkelt elementer hvor man ikke ønsker å knytte inn en hel ressurs for å få med et datapunkt (ett elemetn). Da vil extensions være løsningen.
Punkt 2 og 3 er vi helt enig i og det er også nedfelt i best-practice.
@cgerno - det ser ut som både Brian (co-chair Patient Administration) og Lloyd (FHIR Core Team) er ok med bruk av virtuell lokassjon (virtual room).
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Extending.20ServiceDeliveryLocationRoleType.20Value.20Set
Vil det ikke gi mer mening å inkludere informasjonen hvordan man kobler seg opp til et virtuelt møte direkte på Appointment. Svært ofte vil dette være engangsinformasjon som kun er relevant for akkurat dette møtet, et nytt møte med samme pasient (eller ny pasient) vil generere ny URL og PIN-kode (hvis tjenesten bruker PIN-kode).
Så dersom man reduserer det vi mener er overlappende informasjon i den danske ressursen, kanskje vi bare beholder URL til det virtuelle møtet og PIN-kode? Da mener jeg vi samtidig har et ansvar for å ta dette opp, enten på WGM nå i januar eller i telefonkonferanse med Patient Administration, så det kan vurderes som en del av R5 eller R6.
Saken om virtuelle Appointment og Location ressurser ble diskutert på WGM i går
Utgangspunktet var jira sak fra oss og Cooper Thompson:
- Jira 33341 - Virtual Location with extensions - update will go to this one - konklusjonene på saken blir implementert i R5
- Jira 34978 - Appointment should have better support for virtual appointments
Diskusjonen går videre i Jira saken (se over) og på denne tråden i chatten. Foreslår at de av oss som er interessert hekter seg på der. @kennethmyhra @cgerno @rockphotog @oaassv
Før saken ble diskutert så vi også såvidt på denne som er en relatert problemstilling rundt stor divergens i hvordan Scheduling implementeres med bruk av FHIR i sektoren internasjonalt:
- Recurring appointments - appointment scheduling industry divergence
Nedenfor følger mine ustrukturerte notater fra møtet i WGM i går:
Virtual appointments virtual locations, virtual appointments connection
-
Jira 34978 - Appointment should have better support for virtual appointments
-
Jira 33341 - Virtual Location with extensions - update this one
- Danish approach with extensions for contactpoints for videoconferencing
- Au approach with virtual locations - needs to broaden the scope of Location resource
- ContactPoint with videoconferencing
- Sidekick HealthcareService for virtual healthcareservices - not really a good idea
- Standard extensions for use either on Location or Appointment
- Endpoint, no
- new datatype VirtualServiceContactDetail? for listing contact options (Warning might look a lot like Endpoint)
- Brian proposes a virtual apptnmt flag to explain this is a virtual appointment, mode of attendance?(InPerson, Telehealth, VMR, Weblink) (might not be needed if you got the VirtualServiceContactDetail
-
Discussion
- Shared services, a device with a specific address,
- The virtual location makes handling virtual appointments and physical appointments equal.
- Endpoint to represent the virtual connection point?
- meeting url and guest-pin code as elements on Appointment
-
At least 3 different modes for virtual apptmnts
- Videoconference on video equipment or webex etc. that needs booking (same address/endpoint different timeslots/pincodes)
- Unique connection url for each meeting (Teams/Zoom etc)
- Service provider contacts the subject(s)
-
How do you understand that this is a virtual apptmnt
- Danish adds service types for this ehealth servicetype
-
Proposal: Appointment.virtualService 0..* VirtualServiceContactDetail
- And adding it to: Location.virtualService 0..* VirtualServiceContactDetail