-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting memos
When we have something to record from our weekly office hours meetings, we record the notes here.
No meeting. Project is on hold.
No meeting. Project is on hold.
No meeting. Project is on hold.
Mitkä kaikki laajennokset pidetään? Entä mitkä pidetään tässä oppaassa, mitkä siirretään kansallisten perusprofiilien puolelle? Mitkä pidetään vain Kanta-palveluiden soveltamisoppaissa?
- AdditionalInformationURLExtension (FinnishScheduling)
- AppointmentMutabilityExtension (FinnishAppointment)
- CareGuaranteeExtension (FinnishScheduling)
- CareplanIdentifierExtension (FinnishScheduling)
- ChildAppointment (FinnishAppointment)
- CustomerJourneyExtension (FinnishScheduling)
- HomeMunicipalityExtension (FinnishScheduling, FinnishAppointment): https://hl7.fi/fhir/finnish-base-profiles/StructureDefinition-municipality-code.html
- MiscAppointmentDataExtension (FinnishScheduling)
- NotificationInfoExtension (FinnishAppointment)
- NotificationMediumExtension (FinnishScheduling)
- ParentAppointment (FinnishScheduling, FinnishAppointment)
- PatientInstructionURLExtension (FinnishScheduling, FinnishAppointment)
- PractitionerGenderExtension (FinnishScheduling)
- QueueNoExtension (FinnishScheduling)
- ReferralIdExtension (FinnishScheduling)
- RequestedServiceExtension (FinnishScheduling): .serviceCategory, .serviceType, .specialty, .appointmentType, .reasonCode, .reasonReference, .description, .supportingInformation, .comment, ...
- ResourceCalendarExtension (FinnishScheduling)
- SelfServiceExtension (FinnishScheduling)
ServiceEventExtension (FinnishScheduling)- ServiceEvent: perusprofiileihin (X)
- TicketNoExtension (FinnishScheduling)
- TopicIdExtension (FinnishScheduling)
- VisibleToCustodianExtension (FinnishScheduling)
Kanta:
- AppointmentType
- DetailedContent
- Jatkohoidon tai palveluprosessin lisätiedot
- ReleaseDateForPatientViewing
- RemoteServiceURL
- RequestedService
- ResourceCalendar
- RestrictionParent
- ServiceNeed
CGI
- Last mutability date
- Cancellability
- Reschedulable
- SMS reminder
- SMS reminder phone number
- SMS reminder consent
- SMS reminder consent conditional
- Care evaluation result
Arto Huusko:
Periaatteessa ihan OK olla eri soveltamisoppaat Kanta-kontekstissa ja varsinaisessa aikojen varaamisessa.
CGI:llä cancelled, noshow, fulfilled, arrived, booked. Seurataanko tapaamisen alkamista ja päättymistä erikseen?
Mitkä kaikki laajennokset pidetään? Entä mitkä pidetään tässä oppaassa, mitkä siirretään kansallisten perusprofiilien puolelle? Mitkä pidetään vain Kanta-palveluiden soveltamisoppaissa?
Arja Pakari Kelalta asiantuntijana. Käytiin läpi laajennokset, joita Kanta-palveluissa käytetään ja myös ne, joita voitaisiin käyttää, jos kansallisiin määrityksiin tehtäisiin muutoksia.
MiscAppointmentDataExtension. Tämä on alunperin luotu tietoalkiolle, joka on sittemmin poistettu tietomallista. Kela on luonut oman laajennoksen uudelle tietoalkiolle lisätiedosta. Tätä voisi ehkä uudelleenkäyttää siihen. Olisiko ServiceAdditionalInformation kuitenkin parempi nimi? Ilman URL-osaa, koska saattaa olla muutakin kuin linkki?
RequestedServiceExtension. Tämän kontekstia pitäisi laajentaa. Käytetään viittaamaan HealthcareService-resurssiin.
Voisiko HealthcareService.type-kenttää käyttää "sisältötarkenteen" ilmaisemiseen?
ResourceCalendarExtension. Kela on muokannut tätä, lisännyt tuen ammatille.
ServiceEvent. Tämä on jo sovittu siirrettäväksi perusprofiilien puolelle, kontekstina kaikki resurssityypit, joissa ei ole Encounter-viittausta.
NotificationInfoExtension. Janne on kuullut, että tälle tarve on tullut CGI:ltä. Pyydetään Arto seuraavan viikon tapaamiseen.
Proposed on nyt Tilattu (ja toisin päin). Mutta Alkanut ja arrived eivät oikein sovi yhteen. Jos tavoitteena olisi tosiaan saada aikaan yksi-yhteen-vastaavuus koodien välille, taitaa mennä kohtuuttoman vaativaksi. Lähinnä koska FHIR käyttää tapaamisen aikaiseen seurantaan Encounter-resurssin tilaa. Onko parempi jättää sekä Ajanvarauksen tilan koodi 6 Alkanut että Appointment status arrived kokonaan mäppäämättä? Pitäsikö koodille Alkanut lisätä jokin laajennos?
Mikä on käsitteiden “tapahtuman alkaminen” ja “palvelun käynnistyminen” ero? Pitäisikö tätä selventää soveltamisoppaassa? (Alkanut: ajanvaraukseen liittyvä tapahtuma on alkanut ja on käynnissä parhaillaan. Toteutunut: ajanvarauksen kohteena ollut palvelu on käynnistynyt tai toteutunut.)
=> Tämänhetkinen tapa on väärä. Jätetään ennemmin mäppäämättä koodit, joille ei oikeaa sidosta löydy.
Paketoidaan keskustelu.
- Pelkkä oid-viittaus, ei resurssia. (Olisi myös mahdollista laittaa Encounter identifier...)
- Julkaistaan perusprofiilien puolella, niin on laajemminkin käytettävissä.
Pyritään paketoimaan keskustelu.
Napataan Kanta-speksien määrittelyistä olennaiset osat tähän soveltamisoppaaseen (tai perusprofiileihin)?
Mika Tuomainen:
Kannattaa huomata, että Kanta-kontekstissa asioita määritellään eri paikoissa (Appointment, Provenance, ...). Puolesta asiointi, alaikäisen tiedot, viivästetty näyttö, ...
Juha Mykkänen:
On myös kokonaan piilotettuja ammattilaisten välisiä asioita. Näitä ei olla huomioitu Kanta-kontekstissa, koska eivät liiku siellä.
On myös erityistapauksia, joissa potilaalle ei kerrota tietoja, mutta "saattajalle" kerrotaan.
Janne Heikkinen:
"Dokumentoivat ajanvaraukset" on tuttu konsepti.
Mikael Rinnetmäki:
Tarvitseeko tuoda tähän määrittelyyn?
Janne:
Voisi olla perusteltua, jos nuo muutkin tuodaan.
=> Janne tekee tästä ehdotuksen.
Mitkä kaikki laajennokset pidetään? Entä mitkä pidetään tässä oppaassa, mitkä siirretään kansallisten perusprofiilien puolelle? Mitkä pidetään vain Kanta-palveluiden soveltamisoppaissa?
- AdditionalInformationURLExtension (FinnishScheduling)
- AppointmentMutabilityExtension (FinnishAppointment)
- CareGuaranteeExtension (FinnishScheduling)
- CareplanIdentifierExtension (FinnishScheduling)
- ChildAppointment (FinnishAppointment)
- CustomerJourneyExtension (FinnishScheduling)
- HomeMunicipalityExtension (FinnishScheduling, FinnishAppointment): https://hl7.fi/fhir/finnish-base-profiles/StructureDefinition-municipality-code.html
- MiscAppointmentDataExtension (FinnishScheduling)
- NotificationInfoExtension (FinnishAppointment)
- NotificationMediumExtension (FinnishScheduling)
- ParentAppointment (FinnishScheduling, FinnishAppointment)
- PatientInstructionURLExtension (FinnishScheduling, FinnishAppointment)
- PractitionerGenderExtension (FinnishScheduling)
- QueueNoExtension (FinnishScheduling)
- ReferralIdExtension (FinnishScheduling)
- RequestedServiceExtension (FinnishScheduling): .serviceCategory, .serviceType, .specialty, .appointmentType, .reasonCode, .reasonReference, .description, .supportingInformation, .comment, ...
- ResourceCalendarExtension (FinnishScheduling)
- SelfServiceExtension (FinnishScheduling)
ServiceEventExtension (FinnishScheduling)- ServiceEvent: perusprofiileihin
- TicketNoExtension (FinnishScheduling)
- TopicIdExtension (FinnishScheduling)
- VisibleToCustodianExtension (FinnishScheduling)
Kanta:
- AppointmentType
- DetailedContent
- Jatkohoidon tai palveluprosessin lisätiedot
- ReleaseDateForPatientViewing
- RemoteServiceURL
- RequestedService
- ResourceCalendar
- RestrictionParent
- ServiceNeed
Mika Tuomainen:
Lähtökohtaisesti kaikki Kanta-soveltamisoppaasta löytyvät laajennokset ovat olleet tarpeen.
Mikael Rinnetmäki:
Ovatko kaikki oikeasti tarpeen?
Mika:
Kyllä on käyty läpi. Arja Pakari tietää paremmin.
Mikael:
ParentAppointment ja ChildAppointment?
Juha Mykkänen:
Vain pääajanvarauksesta aliajanvarauksiin päin. Eli ChildAppointment on relevantti, ParentAppointment ei.
Mikael:
Voiko Extension-päätteen ottaa pois?
Mika:
Voi olla työlästä. Toisaalta vielä voi olla mahdollista tehdä peliliikkeitä. Nimen voi muuttaa, urli ei mielellään.
Mikael:
Voiko esim. http-urlin vaihtaa https-urliksi?
Juha:
Tietysti yhtenäinen käytäntö HL7 Finlandin sisällä olisi kiva. Vähintäänkin saman soveltamisoppaan sisällä pitäisi olla johdonmukainen.
=> Keskustellaan ainakin vielä CGI:n kanssa kuinka työläiksi muutokset koetaan. Ja Arjan kanssa laajennosten tarpeellisuudesta.
Mistä kaikista käyttötapauksista kannattaisi luoda esimerkit? Vanhemmissa soveltamisoppaissa on eri käyttötapauksia. Pidetäänkö niistä kaikki mukana? Pitäisikö lisätä jotakin?
Juha Mykkänen:
Nopeasti katsottuna olennaiset käyttötapaukset näyttäisivät olevan kuvattuina.
Update/Reschedule on aiemmin herättänyt keskustelua.
Update on joka tapauksessa laajempi käyttötapaus. Ajanvaraus voi päivittyä muutenkin kuin siirtyä.
Tero Pekkola:
Ajanvarauksen "lukitseminen" on yksi mahdollisuus. Puolesta asioiminen toinen.
Janne Heikkinen:
Koodiesimerkit?
Mikael Rinnetmäki:
Ehkä http-kutsuina ja FHIR-resursseina, mutta ei välttämättä java- tai javascript-koodina?
Janne, Juha:
Samoilla linjoilla. Kielet ja kirjastot kehittyvät ja muuttuvat.
Janne:
Kannattaisiko kuvata joitakin järjestelmien erityispiirteitä?
Mikael:
Ehkä esimerkkien kautta?
**=> Janne työstää aiempien soveltamisoppaiden skenaarioiden mukaisesti. Ei oteta koodiesimerkkejä mukaan.
Juha Mykkänen:
Kansallisissa määrittelyissä vastaavuudet menevät eri tavoin. Ehdotettu ja Tilattu määritellään nyt samalla FHIR-koodilla. Olisi selkeämpää, jos olisi yksi yhteen.
Ehdotus: Proposed = Tilattu.
Mika Tuomainen:
Kanta ei juuri prosessoi tätä tietoa, vain siirtää.
=> Vaatii vielä laajempaa keskustelua.
Palvelutapahtumasta on nyt tuollainen laajennos: https://build.fhir.org/ig/fhir-fi/finnish-scheduling/StructureDefinition-fi-scheduling-service-event.html. Kommentteja tästä?
Mika Tuomainen:
Nyt tietotyypitetty
oid-muotoiseksi. Kanta-soveltamisoppaassa sallitaan muutkin muodot. Ei kuitenkaan mitään sitä vastaan, että tässä määrätään oid.
Janne Heikkinen:
Aiemmissa oli myös
oid. On tiedossa, että jotkut järjestelmät voivat sisäisesti käyttää jotakin muutakin tuossa (esimerkiksi jos oikea palvelutapahtumatunniste ei syystä tai toisesta ole tiedossa, mutta pitää silti niputtaa resursseja saman palvelutapahtuman alle). Noissa tapauksissa ei kuitenkaan tarvitse noudattaa tätä soveltamisopasta.
=> Pidetään oid.
Mika:
Kannattaisi varmaankin sallia myös muualla kuin ajanvarauksen yhteydessä. Siirretään perusprofiileihin?
Mikael Rinnetmäki, Janne:
Näin tehdään.
**=> Siirretään laajennos perusprofiileihin. ** ** Mikael antaa Jannelle riittävät oikeudet siihen repoon.
Ajanvarauksen tilasta on toteutettu sidonta (concept map) FHIR-standardin koodeihin ja takaisin. https://build.fhir.org/ig/fhir-fi/finnish-scheduling/ConceptMap-appointment-status-concept-map.html. Kommentteja tästä?
Mika Tuomainen:
Juha Mykkäsellä on myös ollut tästä esitys. (Ks. esitys PH SIG -työpajassa, alkaen kalvo 12.)
Mykkäsen esityksessä koodi
8 Ehdotettuvastaa yksiselitteisesti FHIR-koodiapending. Nyt annettu esitys on monimutkaisempi, koodille on ehdotettu vastaavuudeksipending-koodin lisäksi myös koodiaproposed. Tämä kannattaa käsitellä THL:n kanssa.
=> Varmistetaan THL:n kanta.
Tero Pekkola:
Eskolla on tällä hetkellä käytössä vain neljä koodia Appointment-resurssille:
- booked
- fulfilled
- cancel
- no-show
Muut koodistopalvelimen koodit käsitellään pitkälti Encounter-resurssin kautta.
Mika Tuomainen:
Kanta käyttää koodeja 3, 4, 6, 7, 8 ja 9.
Mikael Rinnetmäki:
Pitäisikö tässä soveltamisoppaassa kuvata myös tuo Eskon tapa, eli kuinka koodeja sovelletaan Appointment- ja Encounter-resurssien yhdistelmällä?
=> Tero Pekkola pyrkii toimittamaan joitakin esimerkkejä Eskolta.
Tero Pekkola:
Eskolla koodi
pendingon käytössä myös tilanteessa, jossa asiakas on saanut oikeuden varata ajan.
=> Tero Pekkola toimittaa tästäkin esimerkin ja kenties tekstikuvausta.
Mistä kaikista käyttötapauksista kannattaisi luoda esimerkit? Vanhemmissa soveltamisoppaissa on eri käyttötapauksia. Pidetäänkö niistä kaikki mukana? Pitäisikö lisätä jotakin?
=> Ei ehditty käsitellä kunnolla. Vanhasta taitaa puuttua vapaiden aikojen haku.
Otetaanko soveltamisoppaaseen mukaan eri skenaariot, joiden mukaan tietoa ei näytetä kansalaiselle?
=> Ei ehditty käsitellä kuin vähän.
- sekä tässä tiistaina että torstaisin, Kela/THL-asiat lähinnä tiistaisin, muut torstaisin
- vain tiistaisin, mukana myös muiden asiat
=> Pidetään tiistaisin virallisemmat työkokoukset, joille pyritään jakamaan esityslista ja joista pyritään kirjaamaan muistiot. Pidetään torstain tapaamiset vapaamuotoisempina.
Saadaanko lisää syötettä tähän?
Arja Pakari:
Ajanvarausta käsittelevä asioija voi olla
- ammattilainen
- potilas
- puolesta asioija
- sovellus
Puolesta asioijasta välitetään vain hetu ja nimi (RelatedPerson-resurssina).
Yhteyshenkilön nimi ja tyyppi kerrotaan Patient-resurssin
contact-kentässä.
Kanta-rajapinnoissa Appointment-resurssille on määritelty
.meta.security-tag, jolla voi kertoa ajanvarausjärjestelmälle, kenelle tiedon ajanvarauksesta voi näyttää. Ks. profiili AppointmentAppointment (ja sieltä .meta.security).
Tero Pekkola:
Pohteen OmaOys-palvelussa taitaa olla erikseen suostumus sähköiseen asiointiin ja tekstiviestilupa muistutusten lähettämiseen. Nämä ovat eri asioita joka tapauksessa.
Eskolla on Consent-resurssi käytössä ainakin joissakin luvitus-asioissa. Perttu Pöyhtäri on penkonut näitä asioita paljon.
Eskolla se, näytetäänkö ajanvarauksen tieto vanhemmalle, ei näy itse Appointment-resurssissa, vaan asia hoidetaan yleisemmin toisaalla, kaikkien resurssien osalta.
Arja:
Myös ajanvaraukselle voidaan antaa tieto siitä, onko jollakin taholla oikeus käsitellä ajanvaraustietoja. Palvelutapahtuman lisäksi. Ajanvarauskohtaisesti.
Kanta-rajapinnoissa on käytössä laajennos ajanvarauksille, https://simplifier.net/kanta-potilastiedon-arkiston-fhir-r4/restrictionparent.
Janne Heikkinen:
Voisi olla hyötyä ottaa tuollainen laajennos käyttöön yleisemminkin?
=> Ei.
Aiemmassa soveltamisoppaassa Appointment.status on määritelty koodeilla
suunniteltu | tilattu | varattu | peruttu | siirretty | alkanut | toteutunut | ehdotettu | saapumatta,
vaikka FHIR-määrittely vaatii käyttämään koodeja
proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error | checked-in | waitlist.
Ks. Appointment.status. Keskustellaan siitä, kuinka nämä koodistot sidotaan toisiinsa ja kuinka kuvataan siirretty aika.
Mika Tuomainen:
siirretty tilaa ei ole FHIR:ssa, sillä siellä sitä ei lueta ajanvarauksen tilaksi, siirtoon liittyvät asiat pitäisi hanskata ilmeisesti Task resurssin avulla!
Juha Mykkänen:
Jo viime vuoden HL7 PH SIG käsittelyjen ja alkuvuoden kommenttikierroksen osalta ajanvarauksen tila-koodisto on päivitetty niin että arvoihin löytyy FHIR-vastineet: https://koodistopalvelu.kanta.fi/codeserver/pages/classification-view-page.xhtml?classificationKey=1943&versionKey=2203
Erillinen siirretty tila on poistunut koska monissa järjestelmissä asia on toteutettu peruminen+varaus logiikalla ja siirretty on ”varattu, mutta toiseen ajankohtaan” (eikä ole myöskään FHIR koodistossa), tämä sai kannatusta PH SIGille ja Kela-toimittajayhteistyökokoukseen tehdyissä kyselyissä sekä kommentointikierroksella. Perumisen tai siirron syy on tärkeä tieto hoitoonpääsyn seurannassa, sen välittämiseen kannattaa varautua.
Mukaan kansalliseen koodistoon otettiin myös ”ilmoittautunut” (checked-in), kun kommenteissa sitä kaivattiin (vaikka Kanta-toteutuksissa sitä ei tarvita).
Vanhan FHIR-oppaan mukaista standardin kanssa epäyhteensopivaa koodistoa ei varmastikaan kannata enää käyttää.
Mikael Rinnetmäki:
Siirretty pitäisi siis olla peruttu, ja uudessa resurssissa .replaces. Tämä on vasta versiossa 5, mutta voisi käyttää laajennosta tässä. https://www.hl7.org/fhir/appointment-definitions.html#Appointment.replaces
Arto, Juha:
Aiemmin on myös esitetty vaatimuksia, että resurssin
idei saisi vaihtua, vaan samaa Appoinment-resurssia tulisi päivittää.
=> Ei ole selkeää kantaa siitä, kummalla tavalla ajanvarauksen siirto tulisi hoitaa. Kirjoitetaan soveltamisoppaaseen, että sovellusten tulee varautua molempiin tapoihin.
=> Muuten käytetään FHIR-standardin status-koodeja ja pyritään kirjaamaan soveltamisoppaaseen se, kuinka ne vastaavat Koodistopalvelimen koodeja.
=> Laitetaan esimerkki myös perumisen syystä.
Aiemmat soveltamisoppaat rajoittavat monien kenttien kardinaliteettia arvosta 0..* muotoon 1..1, eli sallivat vain yhden koodin käytön. Tämä estää monet fiksut käyttötapaukset.
Keskustellaan yleisestä lähestymistavasta ja yleisistä ratkaisumalleista, joilla saadaan hyvä yhteentoimivuus ja kuitenkin mahdollistetaan useat eri käyttötapaukset.
Arto Huusko:
ongelma on se, että ajanvarausta luokittelevat kentät on pakotettu käyttämään koodistopalvelun uudempia luokittelutietoja, sosiaali ja terveyspalvelujen luokitus, palvelunimikkeistö, asiointitapa mutta (meidän) käyttäjäorganisaatiot eivät noita koodistoja oikeasti hyödynnä toiminnassaan, vaan käyttävät pthavo / hilmo -koodistoja ja näissä kentissä ei sitten voi tuoda mitään muita tietoja, kun ne on rajattu 0..* -tyypisestä 1..1 -tyyppisiksi
Meidän toteutuksessa kenttien käyttöä on laajennettu takaisin alkuperäisen FHIR-pohjamäärittelyn suuntaan niin, että toistuvat luokittelukentät ovat toistuvia, ja niissä voi tulla päällekkäin uusia luokitteluita ja organisaation oikeasti käyttämiä tarkempia luokittelutietoja.
Juha Mykkänen:
Termeta-tietomallissa on myös kardinaliteettien viimeisimmät versiot ajanvarausasiakirjan näkökulmasta (en tiedä onko kaikki vielä täsmälleen samoin Kanta FHIR määrittelyssä): https://termeta.thl.fi/termeta/document-definitions/e797daf8-d74e-4249-9eea-332b590e8890/definition
Arto:
Hilmo ja avohilmo vaativat omien koodiensa käyttöä ja tätä vaaditaan. Kukaan ei varsinaisesti vaadi uusien koodien käyttöä. Tämän vuoksi erityisesti perusterveydenhuollossa käytetään vanhoja koodeja.
Juha:
Jotakin työtä näiden harmonisoimiseksi on jo tehty.
AP: Juha etsii oikean kontaktin, joka tästä tietää tarkemmin.
Mikael:
Kuuluuku tähän soveltamisoppaaseen, vai vain Kanta-spesifiseen?
Arto:
Tietoja liikutellaan myös esimerkiksi saman toimijan sisällä eri järjestelmien välillä. Näissäkin tapauksissa koodien oletetaan olevan kohdillaan.
=> Pidetään tässä soveltamisoppaassa sallivammat kardinaliteetit. Pyritään kuvaamaan eri koodien suhteet toisiinsa.
Jos ehditään, keskustellaan siitä, kuinka ajanvarauksesta viitataan palvelutapahtumaan.
Arto Huusko:
Viittaus palvelutapahtumaan (OID, ei resurssiviittaus) on tarpeen. Ratkaistu meillä extensionilla.
Juha Mykkänen:
Tämä on tärkeä asia pystyä välittämään myös aikojen varauspyyntöjen ja erityisesti varauspyyntöjen vastausten rajapinnoissa. Kanta-määrittelyssä tämä taitaa löytyä provenance resurssista (AppointmentProvenance.ServiceEvent), saattaa olla yksi asioista joihin Mika viittasi Kanta FHIR IG osalta. https://simplifier.net/kanta-potilastiedon-arkiston-fhir-r4/appointmentprovenance
Arto:
Kanta-kontekstissa, kun kuitenkin lähetetään kokonainen Bundle, Provenance-resurssin käyttö lienee OK. Joissakin muissa käyttötapauksissa Bundlen käyttö tuntuu kuitenkin liian raskaalta.
Ja tässäkin, tietoa liikuttelevat myös toimijan eri tietojärjestelmät keskenään ja tieto palvelutapahtumasta liikkuu järjestelmien välillä. Tämä ei ole ainoastaan Kanta-spesifi ominaisuus ja tämä kuuluu kuvata HL7 Finlandin soveltamisoppaassa.
Mikael Rinnetmäki:
Perusprofiileissa palvelutapahtuma kuvataan Encounter-resurssilla. Erottimena
use=official. Appointment-resurssista ei kyllä ole viittausta Encounter-resurssiin. Tästä on avoin tiketti 129.
Arto:
Meillä on myös käytetty Encounteria, mutta erottimena Identifierin
type.Tässä käyttötapauksessa laajennos olisi mieluisin ratkaisu.
=> Kerrotaan soveltamisoppaassa asia tyylillä "jos palvelutapahtumatunniste välitetään Appointment-resurssin osana, se tehdään näin." Mutta ei velvoiteta siihen, vaan sallitaan muutkin tavat, kuten Provenance-resurssin käyttö.
=> Harkitaan perusprofiilien kuvauksen tarkentamista tämän osalta.
Jos aikaa jää tähänkin, keskustellaan siitä, kuinka voidaan merkitä tekstiviestiasiointiin tarkoitettu puhelinnumero ja suostumus.
Arto Huusko:
Kansalaisten asiointia varten on lisätty extensioneita SMS-tietoja varten: puhelinnumero, suostumus. Mahdollistaa muistutuksiin liittyvän ohjauksen hallinnan portaalissa eikä potilastietojärjestelmässä.
Juha Mykkänen:
SMS on muistutuksen tapa kentässä (Viestintäkanava-koodisto) yhtenä vaihtoehtona (muistutustapana yleisiä myös esim. kirje, koodistossa muitakin joilla omia ”osoitemuotojaan”). Puhelinnumero tai muistutuksen postiosoite eivät ole mukana Kanta kautta välitettävissä tiedoissa, koska ei ole ajanvarausspesifiä vaan yleistä asiointiasiaa ja varauksia hallinnoivien järjestelmien vastuulla (jossa myös puolesta asiointien huomiointi tärkeää), samoin kuin monenkirjavat sähköisen asioinnin suostumukset (ei koske siis pelkästään sitä saako ajanvarausmuistutuksen lähettää tekstarina). Toki numeron tai muun muistutusosoitteen välittäminen voi olla ajanvarauspyyntöjen prosessissa tarpeen, kannattanee ehkä sijoittaa jonnekin missä liikkuu muitakin asiointitietoja (kannattaa huomioida että ei ole aina asiakkaan oma puhelinnumero tai osoite, myös turvakieltokoukerot jne.).
Arto:
Tällä hetkellä käytössä olevat järjestelmät käyttävät tuohon laajennuksia.
Mikael Rinnetmäki:
Voisiko olla pikemminkin contained Patient-resurssi?
Arto:
Kyllä varmaankin.
Juha:
Yhteystiedon haltija ei välttämättä ole Patient. Voi olla myös RelatedPerson.
=> Jatketaan keskustelua tästä.