Jotta Suomi toimisi yhteen.

Avoimempi, sujuvampi, luotettavampi. Sellainen terveystietojen maailman kuuluisi mielestämme olla.

FHIR Ajanvaraus paikallistaminen työtila

Työryhmä:

<mauno.ronkko@mediconsult.fi>; <mika.tuomainen@kela.fi>; <arto.huusko@cgi.com>; jani.harju@sotedigi.fi; pekka.lukkari@2m-it.fi; Mikael Rinnetmäki <mikael@sensotrend.com>; <Pauli.Koskinen@fi.fujitsu.com>;  <jarkko.narvanen@salivirta.fi>; <juha.mykkanen@thl.fi>; <Janne.Kaartinen@solita.fi>;  <Hannu.Penttinen@solita.fi>; <jari.lehtonen@thl.fi>; jari.vuonos@apotti.fi; timo.kaskinen@salivirta.fi; Pekka Kilpeläinen Mediconsult; marko.suhonen@thl.fi; risto.juntunen@mediconsult.fi; marko.jalonen@salivirta.fi; jarkko.narvanen@salivirta.fi

Tavoite:

  • Toimintasuunnittelmassa kirjattu ” Ajanvarauspyyntöjen ja -kyselyjen FHIR määrittelyt -projekti vastaa resurssienhallinnanjärjestelmän FHIR-rajapinta- ja profiilimäärittelyistä. Rajapintojen avulla voidaan tehdä ajanvarauskyselyitä ja -pyyntöjä resursseja hallinnoiviin perusjärjestelmiin. Projekti tukee asiointipalvelujen integrointia taustajärjestelmiin, nojautuen mm. FHIR-standardiin, ajanvarausasiakirjan kansallisiin määrittelyihin sekä sisällöllisesti aiempiin HL7 versio 3 – ajanvarausrajapintoihin (SAV). Projektin tehtävänä on huolehtia rajapintamäärittelyn edistämisestä ja hyväksyttämisestä kommentointien ja äänestysten kautta, koota aiheesta kiinnostuneiden osapuolten ehdotukset ja kommentit määrittelyihin, sekä tarkentaa mitä FHIR release-versiota rajapinnoissa hyödynnetään.”
  • Rajaudutaan FHIR tässä
  • Toimijoilla on jo FHIR ajanvaraustoteutuksia, tavoitteena että seuraavat kehitysversiot olisivat tämän määrittelytyön myötä yhtenevämpiä

Mikä FHIR versio:

R3 vai R4? R3:sta ei enää kehitetä. R4:seen teknisen komitean ja Ajanvarauksen 1/2019 työpajojen keskustelun pohjalta focusoidaan. Standardissa on valmiit vertailut DSTU3 ja R4 välillä -> ei erityisesti huomioida työssä muita kuin R4.

Mitkä sisällöt tarkemmin paikallistamistyön kohteena:

  • Resurssit:
  • Appointment
  • Slot
  • Schedule
  • Patient
  • Practitioner
  • PractitionerRole
  • HealthcareService
  • Poistettu: Endpoint
  • Location
  • Organization
  • Provenance Puolesta asioija
  • kannattaa pohtia sitä, mistä syystä halutaan niputtaa eri FHIR-resursseja yhteen. Jos esimerkiksi halutaan välittää joukko FHIR-resursseja REST-rajapinnan yli, yksi suositeltu keino on niputtaa resurssit Parameters-resurssiin http://hl7.org/fhir/STU3/parameters.html . Jos taas halutaan palauttaa itsenäisiä yhteenkuuluvia resursseja, olisi hyvä niputtaa ne  Bundle-resurssin sisään http://hl7.org/fhir/bundle.html . Jos halutaan luoda oikea dokumentti, joka koostuu FHIR-resursseista, voisi siihen harkita Composition-resurssia http://hl7.org/fhir/composition.html . Nämä siis vaihtoehtoina contained-tyyppiselle resurssien aggregoinnille. Muitakin toki vielä löytyy.
  • “FHIR supports a variety of interoperability paradigms and most of them (REST, Messaging and Services) provide support for driving workflow execution. ” -> REST rajaus päätettiin tässä työssä
  • Miten huomioidaanko workflow asioita? Vai profiloidaanko ensin resurssit/tietosisällöt ja jätetään enemmän avoimeksi tätä vuorovaikutusta?:”In deciding how best to interoperate around workflow with FHIR, there are several considerations:
    • Is sharing of the state of the workflow necessary among the participants?
    • Which paradigm do you want to use (REST, messaging, services, a mix)?
    • Who owns/manages the various resources involved in the workflow (placer, filler, another participant)?
    • Is there infrastructure in place to support polling, push notifications via subscriptions or both?
    • Is there a need for confirmation that the desired performer agrees to act, or can that be presumed?
    • Is there a need to negotiate whether/how the requested action will be performed?
    • Can the requesting and performing system communicate directly? Are they able to post to each other’s servers (if using REST)?
    • Is there an ability/need to have a queue server to facilitate workflow execution?
    • How many potential actors are involved?
    • Will the workflow always be directed or is there a pool of potential performers who could choose to perform the requested action?”

Profiloidaanko vai ei?

  • keskusteltiin ajanvaraustyöpajassa sekä TC:ssä: “Kansallisesti on järkevää rajata = profiloida, ettei tule tietoa liian paljon kerralla (=vaikea rakentaa vastaanottavalle järjestelmälle tukea kaikkeen ko aihepiirin resurssien mahdollistamaan tiedonvaihtoon)” Samoin profiloinnilla saadaan kiinnitettyä kansallisesti luokitukset
  • Tiukka profilointi mahdollistaa sisältöjen tarkistuksen/validoinnin
  • Vaihtoehtoinen lähestyminen on “must support” kuvaukset
  • -> lähdetään tiukalla profiloinnilla liikkeelle, ajanvarauksen tietosisältöjä on laajalti käyty kansallisissa toteutuksissa ja ajanvarausasiakirjassa läpi – sisältö on jo lähtökohtaisesti laaja
  • profiloidaan myös yleisisiä resursseja (patient, organization jne) ajanvarauksen hyödyntämisen näkökulmasta

Mitkä interaktiot / käyttötapaukset:

  • Basic workflow for appointment – steppien kuvaukset. Huom. keskusteltiin, että tästä puuttuu suoraviivainen varaus julkaistuun kalenteriin ilman vahvistuksia. Sinänsä emme voi kuitenkaan R4 standardia muuttaa, rajoittaa hyödyäntämistä kylläkin.
  • Ajanvarauspalvelun ja resursseja hallinnoivan järjestelmän välillä tarvitaan seuraavat interaktiot:
    1. Vapaiden aikojen kysely ja vapaiden aikojen kyselyn vastaus
    2. Ajanvarauspyyntö: ajan varaaminen ja ajanvarauspyynnön vastaukset
    3. Ajanvarauspyyntö: ajan peruminen ja ajan perumispyynnön vastaukset
    4.  Ajanvarauspyyntö: ajan siirto ja ajan siirtopyynnön vastaukset
    5. Varattujen aikojen kysely ja varattujen aikojen kyselyn vastaus
    6.  Ajanvarauspyyntö: ajanvaraustietojen muokkaaminen ja ajanvaraustietojen muokkaamispyynnön
    vastaukset.
    7. Notifikaatiot
  • Tietosisällöissä huomioidaan ajanvarausasiakirjan tietosisältö kokonaisuudessaan sekä nykytoteutuksissa siirrettävät tiedot.
  • Keskusteltiin periaatetasolla, viedäänkö kattavasti tiedot resursseihin vai jätetäänkö osa metatiedoista esim http headerissa välitettäväksi. Tarkempi linja muotoutunee työn edetessä
  • Miten huomioidaan käyttäjäauktorisointi? Oletetaan, että kutsut tulevat luotun kumppanijärjestelmän kautta, joka tietoliikennetasolla tunnistetaan luotettavasti. Ei siis työstetä näitä tässä projektissa?
  • –> Huomioidaan työssä kaikki em interaktiot, mutta lähdetään liikkeelle kahdesta ensimmäisestä.

Työkalut:

  • Julkaisu: Simplifier osalta selvitän, olisiko yhdistyksellä mahdollista hankkia Proferssional lisenssi -> yhdistykselle paikka julkaista jatkossakin profiloituja sisältöjä
  • Forge R4 Release
  • Excelillä tietosisältö-resurssimäppäyksillä sekä Forgella profilointi – simlpifier julkaisu

Referenssimatskua:

Esittely 10.2.2020 tekninen komitea:

Profiloinnit ja implementointiopas:

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

 

Ajanvaraus skenaariot/poweroint: 

Mäppäysexcel: 
Rakennemäärittelyt: