Jaa


Hoidon hallinnan suunnittelun parhaat käytännöt ja huomioon otettavat seikat

Yleiskuvaus

Microsoft Cloud for Healthcare sisältää ratkaisuja, kuten hoidon hallintasovellus, jotka perustuvat Microsoft Dynamics 365:n, Microsoft 365:n, Microsoft Azuren ja Microsoft Power Platformin ominaisuuksiin.

Ratkaisuun sisältyvä potilasprofiili edellyttää huolellista suunnittelua ja strategista toteutusta. Tässä oppaassa käsitellään vakaan potilasprofiilin suunnittelun parhaita käytäntöjä ja keskeisiä huomioonotettavia seikkoja. Toteuttajat voivat hyödyntää näiden ohjeiden avulla Microsoft Cloud for Healthcareia tehokkaasti sekä vähentää virheiden ja huolimattomuuden esiintymistä suunnittelu- ja kehitysprosessin aikana, sillä käytettävissä on selkeät noudatettavat ohjeet.

Potilasprofiilien, hoitosuunnitelmien ja hoitoryhmien suunnittelussa huomioitavaa

Microsoft Cloud for Healthcaren yhtenäinen potilasprofiili antaa sairaaloille kokonaisvaltaisen kuvan potilaasta, mikä mahdollistaa paremman vuorovaikutuksen hoitosuunnitelmien ja hoitoryhmien avulla. Ratkaisun osia ovat hallinto, henkilöt (potilaat ja ammatinharjoittajat), organisaatiot ja sijainnit, hoitosuunnitelmat, hoitosuunnitelman aktiviteetit, hoitosuunnitelman tavoitteet sekä mallit. Tässä käsitellään kunkin välilehden suunnittelussa huomioon otettavia seikkoja.

Henkilöiden (potilaiden ja ammatinharjoittajien) määrittäminen

Potilasprosessi on perusta prosessissa, jossa määritetään ja tarkistetaan kaikki suunnitelmat ja käytettävät toimenpiteet. Tarkistaminen voidaan tehdä eri tavoin hoidon hallintasovelluksessa tai yhtenäisessä potilasnäkymässä. Esimerkiksi seuraavat ovat alueita, joissa potilastietoja voidaan tarkistaa tai muokata:

Hoitosuunnitelmien, hoitosuunnitelmien tavoitteiden ja mallien määrittäminen

Hoidon hallintasovelluksen laajentaminen

Jos toiminnallisia tarpeita ei voi täyttää käyttämällä menetelmänä määritystä ensin ja vähäkoodista menetelmää, kutakin ratkaisuarkkitehtuurin kerroksen muodostavaa osakerrosta voidaan laajentaa hyödyntämällä seuraavia suunnittelun huomioon otettavia seikkoja ja suosituksia.

Tietomallin laajennus

  • Hallitut ratkaisut: Microsoft Cloud for Healthcare -tietomalli asennetaan hallittuna ratkaisuna. Tuleva yhteensopivuus voidaan varmistaa ja ratkaisun segmentointiongelmat välttää seuraavien käsiteltävien ehdotusten avulla.
  • Uusien tietoelementtien luominen, kun aiemmin luotuja hallittuja tietoelementtejä on muutettava.
  • Vain uusien tai muutettujen ratkaisun osien lisääminen. Kaikkien objektien lisäämistä ei kannata valita, kun aiemmin luotu entiteetti lisätään mukautettuun ratkaisuun.
  • Uudet tietoelementit: Uusia kenttiä voidaan lisätä aiemmin luotuihin taulukkoihin ja tietomallia voidaan laajentaa luomalla uusia taulukoita. Vaikka aiemmin luotujen kenttien tietotyyppejä ei ehkä kannata muuttaa, uusia vaihtoehtoja voidaan silti lisätä asetusjoukkoihin, kuten luokkiin ja tyyppeihin, tai tekstikenttien pituutta voidaan lisätä. Tietomallin tietoja voidaan käyttää täällä.
  • Polymorfiset suhteet: Toimialakohtainen tietomalli sisältää polymorfisia suhteita, kuten Ryhmät-taulukossa olevat suhteet, joihin liittyy useita hakuja. Tällä hetkellä mitkään rajoitukset eivät rajoita näiden polymorfisten suhteiden laajentamista. On kuitenkin tärkeää huomata, että kyseiset laajennukset voivat vaikuttaa päivitettävyyteen, eikä niiden käyttöä suositella.
  • Integrointiavain: integroinnin avainkenttien käyttö taulukoissa mahdollistaa jäljittämisen ja yhdistämisen pääjärjestelmiin.
  • Viitetaulukot: Viitetiedoilla tarkoitetaan muiden tietojen luokitettuun käytettyjä tietoja. Tyypillisesti ne ovat staattisia tai muuttuvat hitaasti ajan kuluessa.

Käyttöliittymän laajentaminen

Terveydenhuoltolaitokset haluavat ehkä tuoda nykyisen pääjärjestelmän reaaliaikaiset tietoelementit ja ilmoitukset, joiden avulla voidaan laajentaa nykyinen potilasprofiili antamaan kokonaisvaltainen näkymä potilaaseen. Näitä käyttöliittymälaajennuksia voidaan kehittää PowerAppsin määritys- ja mukauttamisominaisuuksien avulla.

Uudet Dynamics 365 -lomakkeet ja -näkymät

Jos kyse on aiemmin luodun lomakkeen tai näkymän muutoksista, niitä ei ehkä kannata muuttaa suoraan. Sen sijaan kannattaa harkita aiemmin luodun lomakkeen tai näkymän kloonaamista ja muutosten tekemistä vasta sitten, sillä tämän vähentää segmentointiongelmien esiintymisen riskiä ratkaisussa.

PCF-ohjausobjektit

PowerApps Component Framework antaa kehittäjille mahdollisuuden luoda koodikomponentteja, jotka voidaan upottaa sekä mallipohjaisiin sovelluksiin että pohjaan perustuviin sovelluksiin. Se hyödyntää tietojen käyttämisessä TypeScriptiä ja muotoilussa CSS-tyylisivua. Tätä kehikkoa voidaan käyttää myös esittämään taloudelliset tiedot asiakkaille potilasprofiililiittymässä. Tämä menetelmä on kätevä käyttäjille, joiden yhteys perustuu toimialueeseen liitettyihin laitteisiin ja yritysverkkoihin, sillä se mahdollistaa integroinnin Enterprise-ohjelmointirajapintoihin ilman altistumista julkisille pilvipalveluille. Se poistaa myös tarpeen monistaa tiedot Microsoft Cloud for Healthcare -tietomalliin.

Tietojen kopioimatta jättäminen tietomalliin rajoittaa kuitenkin tiettyjen valmiiden ohjausobjektien ja asiakasanalytiikan ennustemallien käyttöä. Tämän rajoituksen voi ratkaista harkitsemalla yhdistelmämenetelmää, jossa reaaliaikainen käyttö mahdollistetaan PCF-ohjausobjektien avulla samalla, kun tietojen synkronointitoimenpiteet replikoivat tiedot edelleen tietomalliin muiden skenaarioiden osalta.

Suojauksen laajennus

Microsoft Cloud for Healthcare käyttää täällä käsiteltäviä Dataversen omia suojausominaisuuksia. Suosituksena on käyttää kuvan mukaisesti määritystä ensin käyttävää menetelmää, kun suunnitellaan tietomallia, jossa oikeussääntöjä käytetään näiden alkuperäisten suojausosien avulla.

Kaaviossa näkyy suojausominaisuusluokkia

Dynamics 365:n toteutusoppaassa jaettuja suojauksen parhaita käytäntöjä ja seuraavia lisäkäytäntöjä voidaan hyödyntää:

  • Dataversen suojaus on suunniteltu omistuksen perusteella, minkä vuoksi tietueita ei ehkä kannata määrittää yksittäisille käyttäjille ja jakaa heidän kanssaan. Sen sijaan tietueet kannattaa määrittää ja jakaa ryhmille.
  • Jos jokin tietuejärjestelmää toimii näiden käyttöoikeussääntöjen isäntänä, kannattaa harkita omistusmallin muuntamista eräsynkronointiprosessina Dataversen suojausmalliksi.
  • Suojausmallin suorituskykyä voidaan tehostaa harkitsemalla omistajaryhmien käyttöä käyttöoikeusryhmien sijaan sekä poistamalla tarve tietueiden jakamiseen eri ryhmille tai ainakin optimoimalla se.

Tietojen peittäminen ja kenttätason suojaustarpeet

Terveydenhuoltolaitokset turvaavat usein arkaluonteiset tiedot, kuten henkilötunnukset ja potilastiedot, sekä joskus puhelinnumeroiden ja sähköpostiosoitteiden kaltaiset henkilötiedot, käyttämällä ylimääräisiä suojaustoimia. Nämä suojaustoimet sisältävät usein käyttöoikeuden rajoittamisen tietyille henkilöille ja jopa arkaluonteisten tietojen peittämisen, kun ne ovat näkyvissä.

Nämä suojaustarpeet voidaan toteuttaa luomalla uusia kenttätason suojausprofiileja, jotka määrittää tiettyjen kenttien luku-, päivitys- ja luontioikeudet. Nämä profiilit voidaan sitten määrittää käyttäjille tai ryhmille, jotka saavat tällä tavoin arkaluonteisten tietojen hallitun käyttöoikeuden.

Jos lisäksi muut vaatimustenmukaisuustarpeet edellyttävät tietojen peittämistä, se voidaan toteuttaa luomalla uusi PowerFX-sarake (esiversio) tai laskennallinen sarake. Uusi sarake luo alkuperäisistä tiedoista peitetyn version, mikä muodostaa ylimääräisten tietosuojakerroksen.

Suojauksen automaatiotarpeet

Suojausautomaatio on olennainen huomioonotettava seikka nykymaailman organisaatioissa, etenkin jos on kyse suuresta käyttäjämäärästä ja monimutkaisista skenaarioista. Käyttäjäkunnan laajentuessa ja organisaatiodynamiikan kehittyessä, vakaiden suojaustoimien varmistaminen muuttuu entistä haastavammaksi. Olipa kyse sitten uusien käyttäjien lisäämistä tai roolien, tiimien ja liiketoimintayksiköiden muutosten käsittelemistä taikka uusien ympäristöjen valmistelemisesta ja järjestelmänvalvojien tunnistamisesta, kukin skenaario edellyttää, että arkaluonteisten tietojen ja keskeisten järjestelmien suojaaminen otetaan huolellisesti huomioon. Tässä yhteydessä automaattisten suojausprotokollien toteuttaminen on olennaista, sillä se mahdollistaa prosessien sujuvoittamisen, riskien lieventämisen ja organisaation suojautumisen mahdollisista uhilta entistä tehokkaammin. Suojausautomaatiota hyödyntämällä yritykset voivat mukautua tehokkaasti dynaamiseen käyttäjäympäristöihin sekä ylläpitää ketterää ja suojattua ympäristöä, joka turvaa sekä arvokkaat resurssit että käyttäjien yksityisyyden.

Seuraavassa taulukossa on skenaarioita sekä valtuutuksen ja tehtäväautomaation suojauksen toteutusmenetelmiä.

Skenaario Suojauksen toteuttamistapa
Suojausmallissa otetaan käyttöön uusia henkilöhahmoja Dynamicsissa käyttöoikeusrooli ja soveltuvat toimintaoikeudet ilmaisevat kunkin henkilöhahmon. Kullekin henkilöhahmolle määritetään Dataversessa ryhmän tiimi ja kyseiselle henkilöhahmolle määritetään käyttöoikeusrooli. Ryhmät tiimit määritetään henkilöhahmojen Active Directoryssä. Käyttäjän jäsenyyksiä Dataversen ryhmään tiimeissä hallitaan käyttövalmiin integraation avulla. Käyttöoikeusroolin määrittämisestä yksittäisille henkilöille ei tehdä tai se pidetään mahdollisimman vähäisenä. Käyttöoikeusroolin jäsenen oikeuden perimisparametri muutetaan vain tiimin oikeuksiksi, jolloin käyttäjät voivat luoda tietueita vain siten, että tiimi on omistaja – ei siis yksittäisinä henkilöinä.
Uusien ympäristöjen valmisteleminen Kullekin Dataverse-ympäristöille on luotava uusi käyttöoikeusryhmä, jolla hallitaan ja rajoitetaan käyttäjien käyttöoikeudet tiettyyn ympäristöön. Muussa tapauksessa kuka tahansa, jolla on Dataverse-käyttöoikeus, luodaan ympäristössä käyttäjäksi.
Sovelluksen lisätään uusia käyttäjiä tai käyttäjiä on poistettava sovelluksesta Sen sijaan että käyttäjiä lisättäisiin kuhunkin ympäristöön tai poistettaisiin siitä, sisäkkäistä ryhmämenetelmää käyttämällä ryhmän tiimit (eli suhde-esihenkilö-ryhmä) lisätään alielementtinä ympäristön käyttöoikeusryhmään (ucp-tuotanto). Kun käyttäjiä lisätään tällä tavoin tietyn roolin ryhmän tiimiin, heidät lisätään automaattisesti ympäristöön käyttäjänä ja heille määritetään rooli. Kun käyttäjiä vastaavasti poistetaan ryhmän tiimistä, heidät poistetaan myös ympäristöstä, jos he eivät ole jonkin muun ryhmän tiimin osa.
Aiemmin luotujen käyttäjien muuttaessa nimikettä, roolia tai sijaintia henkilöhahmo voi muuttua. Dynaaminen jäsenyystyyppi Microsoft Entra ID hyödyntää liiketoimintasääntöjä ryhmän jäsenyyden dynaamiseen hallintaan. Tämän dynaamisen jäsenyystyypin avulla voidaan määrittää liiketoimintasäännöt määrittämään, ketkä käyttäjät lisätään tietylle henkilöhahmolle luotuun ryhmään tiimiin ja ketkä poistetaan siitä. Koska Dataverse nyt tukee dynaamista jäsenyystyyppiä, nämä uudet tai poistetut jäsenet synkronoidaan automaattisesti Dataversen ryhmän tiimeihin, ja käyttäjä saa käyttöoikeudelle määritetyn uusimman käyttöoikeusrooliin.
Käyttäjien poistaminen käytöstä Dynaamisen jäsenyystyypin avulla voi lisätä aktiivisia käyttäjiä ryhmiin samoin kuin edellä. Jos käyttäjä ei ole aktiivinen, käyttäjä poistetaan automaattisesti. Käytöstäpoistamiseen voidaan käyttää elinkaarityönkulkuja, jotka voidaan päivittää tai käynnistää Azure-portaalista tai Microsoft Graph -ohjelmointirajapinnasta.
Organisaatiorakenne muuttuu Kaikki organisaatiorakenteen muutokset eivät ehkä vaikuta sovelluksen suojaukseen. Tietojen omistuksen muuttumisen pohtiminen liiketoimintayksikön omistushierarkian perusteella ja kyseisten muutosten toisintaminen ympäristössä päivitetyn liiketoimintayksikön määrityksen avulla.
Käyttäjien työssään käyttämien tiimien tai liiketoimintayksikön muuttuminen Ehdotuksena on dynaamisen jäsenyystyypin ja ryhmän tiimien käyttäminen käyttöoikeusroolien määrittämiseen tiimeille, minkä lisäksi ei suositella käyttöoikeusroolien määrittämistä suoraan käyttäjille. Tässä suojausmallissa käyttäjän tiimin vaihtaminen ei edellytä automaatiota muutosten toisintamiseen, sillä todennus perustuu ryhmän tiimien jäsenyyteen. Jos liiketoimintayksikköä on muutettava käyttäjäprofiilissa, Power Automate -työnkulku voidaan luoda käynnistymään, kun liiketoimintayksikkö muuttuu pää järjestelmissä. Käyttäjä voidaan sitten siirtää toiseen liiketoimintayksikköön käyttämällä SetBusinessSystemUser-toimintoa.
Käyttäjien toimi tai esihenkilö muuttuu Hierarkian suojausmalli on aiemmin luotujen suojausmallien laajennus, jossa käytetään liiketoimintayksiköitä, käyttöoikeusrooleja, jakamista ja tiimejä. Jos tämä määritetään suojausmallissa, on varmistettava että käyttäjätietueen toimi- ja esihenkilötiedot päivittyvät.

Analytiikan laajennus

Analytiikkaa voidaan laajentaa analyysiä luomalla mukautettuja Dynamics 365:n koontinäyttöjä, kaavioita ja potilaskannan koontinäytön kaltaisia Power BI Embedded -koontinäyttöjä.

Lisäohjeita analytiikan ominaisuuksien laajentamisesta on artikkelissa Toiminnallisten analytiikkatietojen tietopääoma.

Yhteistyön laajentaminen

Yhteiskäyttöobjektit (esiversio) auttavat muodostamaan mukautettuja yhteistyökokemuksia, jotka voidaan näyttää suoraan Teamsissa. Vierailuun voi liittyä useilla eri tavoilla hoitajan mieltymysten mukaan. Koontinäytössä ja tapaamistietueissa on painikkeita, joiden avulla hoitaja voi liittyvä tapaamiseen. Lisätietoja on kohdassa Virtuaalisen tapaamisen liittymiskokemus.

Kaaviossa näkyvissä M365:n yhteyskäyttöohjausobjekteja

Nämä ohjausobjektit mahdollistavat Microsoft 365:n ja Microsoft Teamsin käytön hyväksynnöissä, tiedostoissa, kokouksissa, muistiinpanoissa ja tehtävissä, ja niiden avulla voidaan ottaa kontekstiin perustuva yhteistyö käyttöön liiketoimintaprosesseissa.

Seuraavat vaiheet

Hoidon hallinnan suunnittelun tarkistusluettelo