Vastaukset kommentointipyyntöön ajanvarauksen FHIR soveltamisoppaan jatkotyöstöstä 2020/5
Vastanneet: SoteDigi Oy, THL
Hyvä että FHIR-profilointiin on alkanut muodostua järjestelmällisen näköinen malli. En käynyt yksityiskohtaisesti tarkistaen läpi koko ajanvaraus-FHIR-määrittelypakettia koska uskon että kyselyvastauksissa ja varauspyynnöissä pystytään välittämään mm. tarvittavat palvelutapahtumatiedot. Kohdat joita katsoin eivät aiheuttaneet kommentointitarvetta. Yhteenvetoa kaipaisi siitä, onko speksi jo miten ”tuotantovalmis”. Kommentti: To-be-developed sivun tekstit ovat edelleen hieman epäselviä: mitä luetelluista Operations asioista on mukana tai puuttuu ja millä tavoin?
FinnishScheduling R4 Implementation Guide
=========================================
Overview
========
‘Finnish*’ -> ‘FinnishScheduling…’
Hankalasti jäsentyvä lause:
‘Both specialty/specialist (private) and services need assessment (public primary care) driven scheduling system may be developed upon the profiles’. Mitä siinä yritetään sanoa?
Esim. “Scheduling systems driven by service needs of both private sector (specialty/specialist) or of public primary care may be developed upon these profiles” tai jotain sinnepäin? Seuraavakaan lause ei avaudu helposti.
Scope and basic scenario
========================
‘No specific instructions given for narrative’ -> ‘No specific instructions are given for the narrative’.
FinnishSchedulingAppointment
============================
Kardinaliteetti 0..* resurssin päätasolla? (sama kaikissa FinnishScheduling-resurssityypeissä)
CustomerJourneyExtensionilla pitäisi voida olla arvo? Kiinteällä urlilla ei voi paljon esittää. Vai onko tämä vain 0/1-flagi?
SelfServiceExtension vastaavasti.
Miksi Appointment.specialty on suljettu pois? En huomannut sitä vastaavaa ekstensiota. Muillekin poissulkemisille kaipailisin syitä; sinällään voi karsia mutta en huomannut perusteluja.
Appointmentin participantien tyyppien olisi kai tarkoitus viitata FHIR-resurssityyppien FinnishScheduling-variaatioihin.
FinnishSchedulingPractitioner
=============================
Sallitaan täsmälleen yksi tunnus, joka on joko virallinen, terhikki tai vrk. Olisiko tarpeen sallia lisäksi vaihtoehtoisia?
FinnishSchedulingHealthcareService
==================================
Pitäisikö locationin tyyppi olla Reference(FinnishSchedulingLocation)?
Operations
==========
HL7fiSched_REQ1: Query for free appointments
——————————————–
Parametrit start ja end on tarkkaan ottaen _Start_ (resp. _End_) of the period of time etc.
Varmaan kaikilla 0..* IN-parametreilla XXX semantiikka on että “response will contain appointments with any of given XXX”?
OK, tämä logical-OR-semantiikka selitetäänkin lopussa; hyvä.
“See” rivillä -4 näyttää keskeneräiseltä.
HL7fiSched_REQ2: Book an appointment
————————————
‘This operation documentation’ -> ‘The documentation of this operation’ tai ‘This documentation’.
“The primary usage pattern is 1 after …”: tuo ykkönen on tässä vähän kumma. Aha, tarkoittaa että ‘to provide an appointment id’. Myös ‘may support either or both’ voisi selventää esim. ‘either of the above, or both’.
Onko cancelled-appt-id tarkoituksella 0..*, eli tuettaisiin useankin ajanvarauksen vaihtamista yhdeksi? Miksipä ei? Argo-Scheduling IG:ssä tämä on 0..1.
Onko “cancelled” hyvä kuvaamaan hylättyä (rejected)? Sekoittunee asiakkaan perumaan. Parempi olisi luullakseni viestiä operaation status muutoin.
HL7fiSched_REQ3: View previous appointments
——————————————-
patient-id-parametrin selitys puhuu useista, mutta kardinaliteetti on 0..1. OK??
Parametrien start ja end kuvaus vrt. edellä.
HL7fiSched_REQ4: Cancel appointment
———————————–
appt-id-parametri on kardinaliteetiltään optionaalinen ja dokumentaatio sanoo, että joko se tai appt-resource täytyy antaa, mutta jälkimmäinen puuttuu. Joko se lisättävä tai appt-id laitettava pakolliseksi (1..1).
(appt-resource-parametria ei ole alarivin HTTP-syntaksiesimerkeissä myöskään.)