Moderne leger - folket er ganske avanserte for å fullt ut innse betydningen av å introdusere informasjonssystemer til arbeidssykehus. Men deres forventninger fra automatisering er ikke alltid tilstrekkelig - godkjenne forfatterne av artikkelen. Les mer om dette nedenfor.
Innhold
Før du snakker om skuffelser, er det verdt å si noen få slags ord om betydelige fremskritt i forholdene til lederne av medisinske organisasjoner og leger med informasjonsteknologier de siste fem til syv årene. Nå er opprettelsen av hver ny klinikk allerede vanskelig å sende uten IT-komponent. Dette er en slags standard. Betydningen av automatisering er allerede realisert i mange medisinske og forebyggende institusjoner.
Spesielt merkbar anerkjennelse av behovet for automatisering når du lager kommersielle medisinske sentre. Enhver privat investor, som planlegger etableringen av en egen klinikk og enda mer, så legger nettverket av medisinske institusjoner, umiddelbart utstyret til investeringsbudsjettet.
På den annen side er det overveldende flertallet av regjeringens medisinske institusjoner enten ikke automatisert, eller praktisert patchwork, eller heller fragmentarisk automatisering. Og dette er til tross for at mange leger har lenge vært «ingen misters» Datamaskin og privatordre Bruk aktivt programmer og Internett.
Til tross for det lave nivået av automatisering i gjennomsnitt i helsevesenet, er det ganske mulig at det psykologisk medisinske samfunnet er klar for masseinnføring av informasjonsteknologi. Dette kan ses spesielt av nivået av bevissthet om leger. I motsetning til en situasjon på fem til syv år siden, hvis en samtale om medisinske systemer kommer, må legene som regel ikke klargjøre hva et e-medisinsk kort er en integrert del av ethvert industrielt medisinsk informasjonssystem.
Hvor leger og ledere faktisk ble kjent med fordelene med datateknologi, blir ensartede informasjonssystemer i økende grad infrastrukturen til hele sykehuset og profylaktisk institusjon - gjennom integrering med utstyr, gjennom informasjonsutveksling med andre klinikker og forsikringsselskaper.
Vanskeligheter med å introdusere informasjonssystemer til arbeidet med medisinske institusjoner
Dessverre går introduksjonen av informasjonssystemer ikke alltid jevnt. I denne forbindelse er medisin ikke noe unntak. Og i andre næringer er det mange eksempler på mislykkede eller alvorlige redskaper som ikke gir de ønskede resultatene av kjøpere av systemet. Vanskelige implementeringer skyldes en rekke årsaker. Her vil vi bare stoppe noen av dem. Hovedsakelig på vanskelighetene knyttet til feil forventninger til medisinske organisasjoner når du kjøper et informasjonssystem.
Selvfølgelig er det alltid et gap mellom de objektive resultatene av implementeringen og egenskapene til komplekse programvareprodukter, på den ene side og subjektiv vurdering av disse resultatene av deltakerne i implementeringen, på den andre. Men det virker som en av hovedårsakene til vanskelige implementeringer er feil ideer og forventninger til kunder når de kjøper IT-løsninger.
For eksempel innser ikke alle ledere klart forskjellen mellom et enkelt Office-applikasjon og et multiplayer-system. Men hvis vi i det første tilfellet snakker om et verktøy for en egen funksjon utført av en ansatt, så i det andre - om instrumentet som støtter arbeidet til en hel organisasjon med dusinvis eller hundrevis av brukere. Samtidig, ofte er forretningsprosessene i denne organisasjonen ikke formalisert, det vil si ikke dokumentert og stort sett er ukjente i alle detaljer.
Det skjer at ledelsen av medisinske institusjoner, som allerede vedtar en beslutning om kjøp av et programvareprodukt, har ingen anelse om ordinære implacing vanskeligheter. Slik, for eksempel, som uunngåelig stress for personell, smertefullt brudd på stereotyper og som et resultat, sabotasje av den nye teknologien.
Når i løpet av prosjektet, blir alle disse problemene åpenbare, administrasjonen av en medisinsk og profylaktisk institusjon gjør noen hastige konklusjoner og forsøker å begrense omfanget av informasjonsteknologi betydelig. Dette kan for eksempel være et nektet å obligatorisk bruk av systemet av leger og innføring av implementering av regnskap og regnskapsføring av tjenester til automatisering.
Slike avgjørelser kan begrunnes av det faktum at leger må bruke mer tid til å motta pasienten hvis de aktiverer data i systemet. Praksis viser at i de første stadiene kan små forsinkelser virkelig finne sted - folk lærer, bli vant til, master nye muligheter. Men da, som systemet blir mestret, vokser produktiviteten til legene i forhold til «Papir» Teknologi.
HESTED Avvisning av systemfunksjonene begrenser ikke bare individuelle evner, men reduserer effektiviteten av implementeringen generelt. Faktisk, i komplekse medisinske systemer, er det kompleksiteten som gir betydelige fordeler i forhold til patchwork automatisering. Dermed er hastige løsninger forbundet med moralsk unawareness og uvitenhet mer ødeleggende enn de naturlige vanskelighetene med å utvikle ny teknologi.
En annen typisk misforståelse - holdningen til akkompagnementet av informasjonssystemer. Årsaken i samme uvitenhet og misforståelse av hvordan ulike vanskelighetsgrader har stasjonære programmer og omfattende informasjonssystemer. Det skjer at administrasjonen av en medisinsk og profylaktisk institusjon ikke bare ikke gjenkjenner behovet og betydningen av teknisk støtte til systemet av utviklere, men gjenkjenner heller ikke nytte av den interne IT-tjenesten. Selv om enda en kompetent spesialist i klassistens tilstand kan fjerne mange problemer med drift av systemet og stabilisere vilkårene for normale brukere.
Den interne IT-tjenesten til kunden er ikke en luksus, men en garanti for stabilitet og utvikling. Tenker ved automatisering, ikke alle medisinske fasiliteter ser på fremtiden. Ikke alle er klar over at etter introduksjonen av systemet, når folk føler seg nye muligheter, lyser livet ikke på plass, men vil fortsette. Utvikle behovene til brukerne og organisasjonen som helhet.
En annen ekstreme er et forsøk av noen medisinske og forebyggende institusjoner å gjøre et omfattende system på egenhånd. Ledere som har bestemt seg for å gå på denne måten, vanligvis føre to enkle argumenter. Først at vår egen utvikling vil tillate deg å automatisere viktige funksjoner, konkurransefortrinn av klinikken. For det andre vil programmørene gjøre alt mye billigere enn den eksterne entreprenøren.
Selv om du gjenkjenner at disse hensynene kan være berettiget, er det viktig å forstå de tilknyttede begrensningene og, viktigst, den endelige prisen på avgjørelsen. Automatisering av konkurransefortrinn, selvfølgelig en verdig oppgave. Men hvilken andel gjør spesifikke forretningsprosesser i det totale volumet av medisinske institusjonsfunksjoner? Det kan være 5, 10, i ekstreme tilfeller 20%, neppe mer. I mellomtiden, hvis det er besluttet å gjøre de resterende 80-95% hjemme, vil alle funksjonene i intern utvikling gjelde for dem.
Hva er disse funksjonene? De er spesielt uttalt med den meget akselererte utviklingen som tilhenger «hjem» Programvare fører som et annet argument «per» hjemmelaget system. Dette er hastighet og lav pris. Ønsket om å gjøre alt så raskt kan nesten alltid bli til et brudd på systemets arkitektoniske integritet og avslaget av planlegging og dokumentasjon. Og det viser seg ikke bare egendefinert, men også teknisk dokumentasjon.
Er det verdt å forklare hva det vender seg når nye krav til systemet og behovet for å gjøre endringer! Universelt hjemmelagde systemer opplever også alvorlige vanskeligheter med å koble komplisert medisinsk utstyr. Som et resultat er det ikke sikret hastighet, men illusjonen av utviklingshastigheten. Siden fragmentariske suksesser skal som regel, perioden for faktisk negativ ytelse i utviklingen. Figurativt snakket «rave». På prosjektledelsen av prosjektledelsen er denne situasjonen beskrevet som en kombinasjon av høye risikoer og høye kostnader for eierskap av systemet.
Vanligvis er medisinske institusjoner bare tilbøyelige til en av to ekstremer. Enten leve i det hele tatt uten det service eller prøv å skrive sitt system. Men det er slike tilfeller når en avgjørelser først tas, og deretter diametralt motsatt. Organisasjonen gjør to, tre forsøk på å starte om igjen, etterlater den ferdige beslutningen til sin egen utvikling og returnerer deretter tilbake.
Det er umulig å si at uavhengige utviklere ikke er vant til disse dramatiske historiene. Dessverre har kunden svært alvorlig grunnlag for å erstatte det en gang valgt programvareprodukt. Ofte skjer det på grunn av overdreven produktstivhet, dets manglende evne til å følge endringer i organisasjonen. En annen typisk synd av utviklere er den utilfredsstillende formuleringen av implementeringsprosessen, som imidlertid er et problem for hele russisk marked for integrerte informasjonssystemer.
Utilstrekkelig og overveldet forventninger forbundet med utilstrekkelig bevissthet manifesteres ikke bare i undervurderingen av vanskelighetene med å introdusere eller en overvurdert vurdering av interne utviklingsutsikter. En annen vanlig feil - noen overdrivelse av automatiseringsmuligheter som sådan. La oss si, på dagens utviklingsstadium, er det ennå ikke nødvendig å snakke om fullverdige beslutningssystemer som vil levere leger med nyttige intellektuelle meldinger for alle anledninger. Selv om i fremtiden, kanskje i nær fremtid, vil slike funksjoner sikkert vises. I det minste i alvorlige industrisystemer.
I utgangspunktet er de to vanligste misforståelsene overveldede forventninger i form og ide om implementeringen av systemet som en endelig prosess. Noen ganger forventer leverandører at introduksjonen vil være rask, nesten øyeblikkelig. Det er også underforstått at med installasjonen av systemet alle problemene forblir bak. Om hvor vanskelig installasjonen av systemer er tilkoblet, har vi allerede sagt ovenfor. Vellykket overvinne av disse vanskelighetene er kun mulig med en edru beregning av midlertidige og personellressurser: uten varm og klekking.
Når det gjelder gjennomføring av implementering, er det heller ikke overflødig å gjenta ideen om den kontinuerlige utviklingen av systemkravene. Selvfølgelig, i hver introduksjon må du tegne en linje. Settet av funksjoner som leveres av leverandøren, må implementeres. Men da, når eksperter er klar over alle forstyrrende muligheter, vokser brukerens appetitt og jobber med utviklingen av produktet fortsetter. Og dette betyr nye implementeringer, nye problemer og nye prestasjoner.
