Kommentit ajanvarauksen FHIR soveltamisoppaasta 1/2021

Kommentit ajanvarauksen FHIR soveltamisoppaasta 1/2021

Soveltamisopas https://simplifier.net/finnishappointment

Tausta: Ajanvarauksen ja FHIR-profilointien kokonaisuutta työstettiin vuonna 2019 yhdistyksen projektissa, missä paikallistettiin ajanvarauskontekstin tiedonvaihtoa – välituotokset olivat toukokuussa 2020 kommentointikierroksella.  Työtä jatkettiin 2020 yhdistyksen Solitan kanssa toteutetussa projektissa , jonka tuotokseen pyydämme nyt vapaamuotoisesti kommentteja sekä kehitysehdotuksia. Lisätietoja profilointi- ja FHIR-rajapinta-aiheista on tulossa myös 2021 alun uutiskirjeissä.

Kommentoineet: Mediconsult, Tieto, HUS, Kela ja THL

Yleiset kommentit:

1. Onko tarkoituksena rakentaa HL7-rajapintaan sama pakollinen tietosisältö mitä THLn ajanvarausasiakirjalle on asetettu? Ajanvarausasiakirjalta vaaditaan esimerkiksi hoitoprosessin vaiheen tiedot, rekisterinpitäjän tiedot, ajanvaraukseen liittyvän palvelutapahtuman tiedot, ajanvarausasiakirjan korjauksen ja mitätöinnin syy. Näille tiedoille ei ole paikkaa HL7-esimerkissä.
2. Esimerkki-interaktioissa tarvittaisiin myös paluuarvoja; nyt on esitetty ainoastaan
   palvelimelle lähetettäviä tietoja.
   o Esim. varattavissa olevien aikojen haun (Search available slots) täytyy
   palauttaa Slot-resursseja, joihin ajanvarausviestin Appointment.slot voi viitata.
   No, tavallaan tämä kyllä sisältyy FHIR search -semantiikkaan.
3. Kaipaisin kuvauksia siitä, mitä tietoja ajanvaraus-flowssa tarvitaan kuljettaa, tai mitä
   niistä kuvattujen profiilien mukaisten resurssien kentät palvelevat.
   o Mitä tietoja eri vaiheissa tarvitaan ja kulkee tuettavaksi kaavailluissa
   interaktioissa ja mihin suuntaan?
   o Tällaisten pohjalta ajanvarausskenaarioita pystyisi pöytätestaamaan ja
   arvioimaan esitettyjen profiilien toimivuutta suhteessa niihin.
   o Tällaista voisin ajatella sisältyvän ‘Scenario – Patient driven scheduling’-
   osioon.
4. Pitäisikö ottaa kantaa virhetilanteisiin?
   o Esim ajanvarauksen epäonnistuminen. (HTTP status ‘Unprocessable Entity’ +
   selittävä OperationOutcome vastauksena POST Appointment -kutsuun?)
5. Ajanvarausviestin Appointment-resurssissa asiakas näyttäisi kertovan palvelimelle
   ollaanko tekemässä peruttavissa tai siirrettävissä olevaa ajanvarausta.
   o Näiden toiminnallisuuksien tukeminen riippuu palvelimesta ja sen
   ajanvarausjärjestelmästä. Sikäli voisi ajatella, että palvelin asettaisi
   palauttamaansa Appointmentiin näille arvot. Tai ehkä palvelin vastaa
   ‘Unprocessable Entity’ jos se ei pysty lupaamaan peruttavuutta tai
   siirrettävyyttä.

FinnishAppointmentAppointment

Appointment.extension:ParentAppointment

=> Ehdotetaan lisättäväksi ChildAppointment. Vastaava rakenne tarvitaan moniajanvarauksen käsittelyyn myös KanTa-integraatiossa. Esimerkki: pääajanvarausta ei voi poistaa jos sillä on aliajanvarauksia.

Appointment.status

=> Miksi tätä ei ole yhdistetty ja suomennettu THL koodiston Ajanvaraus – Ajanvarauksen tila -koodiston (1.2.246.537.6.881) kanssa?

• Yhdistämisessä huomioitava että FHIR-mallissa Arrived vastaa tilannetta jossa potilas on ilmoittautunut luukulla tai itseilmoittautumisen kautta, ja on odotushuoneessa (tilaa ’Ilmoittautunut’ ei mainita THL:n koodistossa). Checked-in vastaa tilannetta jossa kaikki osapuolet ovat paikalla, eli vastaanotto alkaa (vastaa tilaa ’Alkanut’).
• FHIR ei tunne tilaa ’Siirretty’. Tila on mielestämme tarpeeton, koska käytännössä ’Siirretty’ on sama kuin ’Varattu’. Koska ajanvarausta on voitu siirtää useaan kertaan eri syistä johtuen, tieto on kuitenkin tallennettava versiohistoriaan (ajanvarausasiakirjojen versioilla tai FHIR-rakenteessa ’resource’:n versiotietoa hyödyntäen).

FinnishAppointmentHealthcareService

HealthcareService.category.coding.system

Short description: AR/YDIN – Palvelutapahtumaluokitus

=> Millä perusteella healthcareservice kytkeytyisi vain yhteen palvelutapahtumaluokkaan? Varattava palvelu voi olla tarjolla sekä käyntinä vastaanotolla, sarjahoitona, etävastaanottona jne. Yksittäinen ajanvaraus voi olla jotakin näistä, mutta ei koko palvelu.

FinnishAppointmentPatient

Patient.identifier:sliceIdentifierTemp.use

-> suomenkielinen kuvaus puuttuu, vrt. sliceIdentifierOfficial

=> miten käsitellään henkilötunnuksen vaihto virallisesta viralliseen (esim. sukupuolen vaihto) jos sallitaan vain 1 tilapäinen ja 1 virallinen hetu?

FinnishAppointmentSchedule ja FinnishAppointmentSlot

=> oliko näissä tarkoitus olla jotain muutoksia? Ei näyttäisi olevan mitään eroa FHIR-rakenteisiin. Sinänsä nämäkin rakenteet täyttävät paikkansa hyvin.

https://simplifier.net/guide/FinnishAppointmentIG/Overview

“Both specialty/specialist (private) and services need assessment (public primary care) driven
scheduling system may be developed upon the profiles.”

• Saisiko tätä selkeytettyä: Mitä tai mikä voidaan kehittää näiden profiilien varassa?
  (Onko yritetty kääntää suomalaisen terveydenhuollon termejä suorasanaisesti? Mitä
  tässä sanottaisiin suomeksi?)
• Schedule viittaa resursseihin Practitioner ja Location, mutta nämä yhteydet puuttuvat
  kuvasta. Aikaa varaavalle clientille kuitenkin vastaanottopaikan ja vastaanottavan
  ammattilaisen tiedot lienevät usein tärkeitä, ja ne voisi saada Schedulen kautta.

https://simplifier.net/guide/FinnishAppointmentIG/Scenario-Patientdrivenscheduling

• “The result set is based on the search criteria set on: available times practitioner
  location (either as a resource reference or a string) specialty healthcare service type
  (based on Finnish codesystem THL – Sosiaali- ja terveysalan palvelunimikkeistö
  [1.2.246.537.6.49.201501])”
• Y.o. listaa kannattaa selkeyttää vähintäänkin välimerkein.

https://simplifier.net/guide/FinnishAppointmentIG/Searchavailableslots

• ‘Implemantation notes’ -> ‘Implementation notes’
• Implementation examples: Näissä voisi näyttää, että execute()-metodin tulos
  saadaan Bundle-tyyppiseen muuttujaan.
• Pelkkien Slotien sisältämä tieto on ajanvarausasiakkaan tarpeisiin niukka; usein
  haluttaneen tietää myös vastaanottava ammattilainen ja/tai vastaanottopaikka. Nämä
  olisivat saatavilla Schedulen viittaamien Practitioner- ja Location-resurssien kautta, ja
  siksi ne tarvinnee mukaan tulos-bundleen esim. tähän tapaan:&_include=Slot:schedule
  &_include:recurse=Schedule:actor:Practitioner
  &_include:recurse=Schedule:actor:Location

https://simplifier.net/guide/FinnishAppointmentIG/Searchscheduledappointments

• Onko patient.urn:oid:1.2.246.21|010101-123N=value oikea hakuehdon ilmaus?
  ‘=value’ ei taida viitata mihinkään,eikä Patient.resurssilla ole hakuparametria ‘urn’.
  Pitäisikö olla esim. patient.identifier=urn:oid:1.2.246.21|010101-123N?
• Implementation example: Tulos-bundlen voisi ottaa talteen (samoin kuten
  varattavissa olevien slotien hakuesimerkeissä).

https://simplifier.net/guide/FinnishAppointmentIG/Bookanappointment2

• ‘The appointment is posted without ID’ -> ‘The appointment is posted without an ID’. Voisi ehkä avata enemmänkin, esim.”In order to book an appointment, a new Appointment resource is posted to the server to be created there. ….”
• Olisiko Appointment.created-aikaleiman arvossa aiheellista olla myös kellonaika
  mukana?
• Potilas-participantilla pitäisi ehkä olla type, muutenhan kyseessä voisi olla
  Practitioner tai RelatedPerson. Esim. näin:”type”: [ {
  “coding”: [ {
  “system”: “http://terminology.hl7.org/CodeSystem/v3-
  ParticipationType”,
  “code”: “SBJ”,
  “display”: “subject”
  } ] } ]Vai onko taustalla mahdollisesti rajaus että ainoastaan potilas välitetään
  henkilötunnuksen kera? Se, että kyseessä on Patient voisi olla pääteltävissä siitä, että
  tältä puuttuu identifier.use=official, joka on Practitionerilla vaadittu. Onko Patient- ja
  Practitioner-tietomallien ero tältä osin kuitenkaan tarkoituksellinen? Elementtien
  roolin läpinäkyvyys olisi parempi kuin sen päättely näkymättömistä taustaoletuksista
  tai profiilien detaljeista.
• Mihin ParentAppointment-ekstension valueIdentifier viittaa kun vielä ei ole luotu
  Appointment-resurssia jolla olisi tunnus?
• Miten palvelin palauttaa luomansa Appointment-resurssin ID:n? Fhir-speksin mukaan palvelimen pitää palauttaa sama resurssi, jolle se on lisännyt ID:n; OK
• NotificationInfoExtensionin system-urliin mieluummin hl7.fi kuin example.org; Sama
  profiiliin https://simplifier.net/finnishappointment/notificationinfoextension.

https://simplifier.net/guide/FinnishAppointmentIG/Readappoinment

(ei kommentteja)

https://simplifier.net/guide/FinnishAppointmentIG/UpdateRescheduleanappointment

• “=>”-muistiinpanomerkintöjä olisi syytä avata sanallisesti, tyyliin “Re-scheduling an
  appointment takes place byupdating an Appointment resource at the server with a new
  Slot reference together with new start and end times for it” tms.
• Flow:ta voisi selventää: tarkoitus varmaan, että uusi Slot on haettu kuten kohdassa
  ‘Search available slots’, ja ‘example’ on aiemman ajanvarauksen Appointmentille
  palauttama ID.

https://simplifier.net/guide/FinnishAppointmentIG/Cancelanappointment

• Lyhennysmerkintöjen sanallinen avaaminen paikallaan tässäkin. Idea siis että
  tunnuksella viitattavissa olevaa Appointment-resurssia päivitetään asettamalla sille
  cancelled-status ja potilaan tilaksi ‘declined’.
• Potilas-participantin tyypittämiseen tässä sama kommentti kuin ajanvarausviestin
  yhteydessä: pitäisikö tyypittää että on varmasti potilas? Toteutusesimerkissä
  näyttäisikin olevan participant.actorin Patient-tyyppi tiedossa.

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentAppointment

• ParentAppointment-ekstension rooli ja ajateltu käyttö?
• o Onko yleinen “There can be no stigma associated with the use of extensions…” kommentti hyödyllinen tai tarpeellinen?
• o Viittaako 12 Pääajanvaraus -requirement johonkin?
• AppointmentMutability on jossain määrin arvattavissa, mutta onko siitä kerrottu
  mitään?
• NotificationInfoExtension: Esimerkin perusteella esimerkiksi potilaan
  tekstiviestiyhteys välitetään tässä. OK? Onko jotain muuta käyttöä suunniteltu tälle?
  serviceType on pakollinen. OK? Mahtaako olla tuettavissa kaikissa
  ajanvarausjärjestelmissä? Mäppäytyykö esim. Lifecaren function-kentäksi?
• Onko 1.2.246.537.6.884.2015 OK system-arvo appointmentType.codingille, vai
  pitäisikö tässäkin olla urn:oid? Kansallisten koodisysteemien kiinnittäminen vaikuttaa näissä hyvältä ja
  oikealta tavalta.
• Tarvitseeko tekstikenttä patientInstruction ekstensioita?

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentSlot

• serviceType ei ole pakollinen. OK? Miten varattavalle Appointmentille saadaan vaadittu serviceType jos varattavana olevalla Slotilla sitä ei ole?

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentSchedule

(ei kommentteja)

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentHealthcareService

• Mihinkä tätä tarvitaan ajanvaraus-flowssa?
• Ajanvarausviestin Appointment.participant:HealthcareService, OK.
• Onko sitä tarpeen kertoa palvelimelle ajanvarausviestissä? Ehkä, jos useampi HCS tarjoaisi samaa slotia, mutta onko tällaista asetelmaa?

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentLocation

(ei kommentteja)

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentPractitioner

• Tällä sivulla näkyy virheellisesti FinnishAppointmenPatient-sisältömalli mutta linkki
  https://simplifier.net/finnishappointment/finnishappointmentpractitioner on
  oikein
• Identifier-tyypit (hetu, terhikki, vrk) vaikuttaa hyvältä.
• Onko tarkoituksellista että identifier voi myös puuttua? Ehkä on tilanteita, joissa on tarve viitata ammattilaiseem ilman tarkkaa identiriointia, esim. anonyymi koronatestaaja?

https://simplifier.net/guide/FinnishAppointmentIG/FinnishAppointmentPatient

• Potilaalla täytyy olla nimi ja joko hetu tai muu tunnus; OK.

Yleiset kommentit:

1. Etusivulla korostetaan ”example project” – voisiko suoraan pyrkiä siihen että määrittely olisi ”specification” eikä ”example”; tavoite siis tarkempi kuin pelkkä ”esimerkki”, jos tavoitteena kuitenkin (kuten kaikissa rajapintamäärittelyissä) on parantaa yhteensopivuutta. Myös jos kyseessä olisi esimerkki, pitäisi se olla selkeästi kuvattu (ks. myöhemmät kommentit).
2. Kriittinen puute. Soveltamisoppaassa / paketissa ei ole tai helposti löydy lukijaa ohjaavaa sisältöä joka olisi tarpeen paketin ymmärtämiseksi, resurssien ja laajennusten käyttämiseksi ja kokonaisuuden hahmottamiseksi. Esimerkiksi on vaikea löytää minne on dokumentoitu 05/2020 kyselyn mukaiset kommunikointiparadigma-asiat tässä kuvatun soveltamistavan kannalta, yleiskuvaus siitä mitä soveltamisoppaalla tavoitellaan ja mitkä ovat siihen mukaan / pois rajatut asiat, projektin aikana esitellyt käyttötapausasiat joita myös kommentoitu matkan varrella, teknisen komitean esitysmateriaaleissa kuvatut käyttötapaus- ja linjausasiat jne. Perusdokumentaatiota tarvitaan lisää tai löydettävämmäksi – kokonaisuuden ymmärtämiseen tarvitaan edes jonkinlaista yleiskuvaa, dokumentaatiota ja jäsennystä vaikkei tarvitsekaan mennä yhtä pitkälle kuin esim. https://simplifier.net/guide/finnishphrimplemetationguide/finnishphrimplementationguidehomepage2
3. Kriittinen puute. Etusivu vie resursseihin / profiileihin, joissa ei ole kaikkia tarvittavia tietoja. Esim. Appointment menee osoitteeseen https://simplifier.net/finnishappointment/finnishappointmentappointment, kun tarvittavat tiedot paremmin sisältävä profiili (erityisesti ja mm. palvelutapahtuman tunniste ym., joita on vaadittu / ehdotettu mukaan projektin alusta lähtien ja joka on kansallinen perusvaatimus asiointipalvelujen ja perusjärjestelmien välisille integraatioille), on samassa simplifier-tilassa osoitteessa https://simplifier.net/finnishschedulingr4/finnishschedulingappointment). Vähimmäistason yhteentoimivuuteen tarvittavia tietoja ja asioita määriteltiin 2019 projektissa ja sen yhteistyötyöpajoissa joissa tehtiin päätöksiä mukaan otettavista asioista, ml. mäppäystaulukot. Pääosa tai kriittisiä tällaisia näyttää puuttuvan ainakin nyt viitatusta Appointment profiilista. Onko kyseessä virheellinen linkitys vai onko tietoisesti jätetty pois paljon tarvittavia tietoja / elementtejä joita näkyy esim. jälkimmäisessä osoitteessa ja jotka olivat pohjana käytetyn projektin keskeisiä tuloksia?
4. Kriittinen puute. Appointment profiiliin (ja mahdollisesti muihin profiileihin) pitää saada (takaisin?, olleet ainakin joissakin aiemmissa versioissa) ainakin ne välttämättömät sisällöt joita on todettu ja ohjattu mukaan tarvittavaksi ja joilla voidaan täyttää edes kansallisesti määritellyt vähimmäisvaatimukset  asiointijärjestelmien, perusjärjestelmien ja Kanta-palvelujen yhteentoimivuuden näkökulmasta. Näihin vähimmäisvaatimuksiin linkit ja jopa yksilöidyt tarkat vaatimukset on projektin ja pohjana käytetyn projektin aikana selvästi lähetetty huomioitavaksi, useita toistuvasti *.
5. Edellisten kohtien epäselvyyksien vuoksi ei vaikuta siltä että kannattaisi kommentoida yksityiskohtaisesti mukana olevia profiileja ja laajennuksia. Paketti ei vaikuta julkaisukelpoiselta eikä käyttökelpoiselta. Jos simplifierissa nyt olevan dokumentaation tavoitteena on hyödyntämiskelpoiset määrittelyt, aiempien versioiden tarkentaminen tai tekeminen käyttökelpoisemmaksi, tai ymmärrettävän esimerkin kokoaminen, vaikuttaa siltä että toukokuussa pohjana ollut paketti täyttää näitä tavoitteita paremmin kuin nyt kommentoitavana ollut paketti, vaikka olisikin ”work in progress”.

Yleiset kommentit:

Viittaus määrittelyyn, johon tämä FHIR määrittely pohjautuu:

• Tämä ei oikein selviä mistään kohdin määrittelyä. Pohjautuuko määrittely THL Ajanvarausasiakirjan tietosisältömäärittelyyn vai aiempaan HL7 Finland FHIR ajanvaraustyöhön? Vai molempiin? Suomenkielisissä elementtien kuvauksissa on numeroita alussa, jotka varmaan viittaavat tietosisältöön. Osalle tämä voi olla selvää, osalle ei.
• Olisi ehkä hyvä kuvata tämä täällä: https://simplifier.net/guide/FinnishAppointmentIG/Overview
• Nyt ainoa maininta asiasta FinnishAppointmentAppointment profiilin descriptionin ylimalkaisessa viittauksessa: ”The contents is based on the scheduling appointment spefication.”

Viittaukset profiileista toisiin resursseihin, jotka on profiloituja

• esim. Appointment.slot.reference (slot)
  • -> pitäisikö olla FinnishAppointmentSlot vai saako käyttää myös FHIR pohja Slot-resurssia
  • vai eikö näihin oteta tietoisesti lainkaan kantaa, jotain mainintaa tästäkin voisi ehkä kuitenkin olla (aiemmassa HL7 Finland FHIR ajanvaraustyössä ei myöskään oltu tehty näin viittauksia)
• tämä sama kommentti kaikkiin viittauksiin profiilista toisiin resursseihin, jotka ovat profiloituja
• samalla tulisi miettiä, miten noiden toisistaan riippuvien profiilien versiointi on tarkoitus hoitaa (jos muutetaan yhtä profiilia johon viitataan, miten versiointi ylipäätään huomioidaan)

“Other base resources related to the scheduling scenarios: Organization, Practitioner Role, ServiceRequest etc.. may be used as such.”

• käytetään
  • kuten FHIR pohja resurssit
  • vai kuten HL7 Finland FHIR ajanvaraustyössä aiemmin profiloitu
  • vai molemmin tavoin

FinnishAppointmentPatient

• Patient.identifier 1..2: 51 Asiakkaan tunniste, virallinen henkilötunnus tai tilapäinen yksilöintitunnus
• Voiko olla molemmat, tekninen määritys sallii, tekstissä ei mainintaa
• tämä periytynee aiemmasta HL7 Finland FHIR ajanvaraustyöstä

https://simplifier.net/guide/FinnishAppointmentIG/Searchscheduledappointments (IG esimerkkiskenaario Search scheduled appointments)

• tässä kutsussa taitaa olla parametrien esittäminen pielessä: GET [base]/Appointment?patient.urn:oid:1.2.246.21|010101-123N=value&status=booked, tai ainakin HAPI noista herjailee
• oikea muoto lienee esim.: GET [base]/Appointment?patient.identifier=urn:oid:1.2.246.21|010101-123N&status=booked
• ja sama kommentti POST esimerkkiin patient.urn:oid:1.2.246.21|010101-123N=value&status=booked -> patient.identifier=urn:oid:1.2.246.21|010101-123N&status=booked

Yleiset kommentit:

• Olemme HUS Tietohallinnossa tutustuneet allamainittuihin ajanvarauksen FHIR-määrityksiin.  Emme havainneet selviä puutteita tai virheitä näissä määrityksissä.  Jonkin verran määrityksiin syvällisemmin tutustumista helpottaisi, jos ne olisivat saatavissa myös suomeksi.  Tämä tässä samalla jatkotoiveena.
• “Hei ja kiitos perehtymisestä ja kommentistanne! Kielipohdintana toteuttajia lähellä olevia & kv-yhteentoimuutta painottavin osin yhdistyksen projekteissa ko. soveltamisoppaita on alettu tekemään suoraan englanniksi. Resurssien tietojen kuvauksissa on seassa suomea jonkun verran kohdissa, missä silattu suomalaisiin tietosisältöihin – resurssien teknisluonteiset kuvaukset valuvat suoraan kv-resurssikuvauksista, joten kaksikielisyys noissa käytännössä kannattaa sallia.  Paljon tekstiähän noihin soveltamisoppaan puolelle lopulta ei tule, joten kääntäminenkin on suoraviivainen. Työkaluissa voisi olla suoraviivaista myös tehdä siten, että joka paikassa vaikka ensin kappale englanniksi ja sitten suomeksi, ne tulisi sitten pakotettuna pidettyä ajantasalla – muuten tälläisessä kehittyvässä kohteessa erillisen kielikäännöksen ajantasaisena pitäminen on haastavaa.   “