Farvel til grøn kommandolinje på københavnske hospitaler

En gammel mainframe-brugergrænseflade er nu på vej ud fra det centrale it-system hos hospitalerne i Region Hovedstaden. Dermed er den største og vigtigste konsolideringsopgave efter sammenlægningen gennemført.

Da amter blev til regioner, var det også startskuddet til en kæmpe konsolideringsopgave på hospitaler landet over.

Hos Region Hovedstaden skulle it-systemerne fra tre forskellige amter samt Hovedstadens Sygehusfællesskab til at arbejde sammen og med tiden integreres fuldstændigt.

»Vi blev født med 400-500 forskellige systemer. Det antal måtte reduceres ganske væsentligt, hvis vi skulle have en chance,« siger Søren Zachariassen, sundheds-it-chef i Region Hovedstaden.

Og to år efter sammenlægningen er der kommet fuld gang i konsolideringen, efter at regionen først skulle vurdere, hvilke systemer, der var værd at satse på, og hvilke der skulle ud.

I sidste uge skiftede Hvidovre Hospital til det nye Opus patientadministrations-system, og dermed kører alle 13 hospitaler i regionen nu med samme software til den opgave. Det er det helt centrale it-system på hospitalerne, som alle de øvrige mere specifikke sundhedsfaglige systemer trækker data fra.

Dermed bliver det også langt lettere fremover at gå videre med konsolideringen af de øvrige systemer, når det er samme patientadministrationssystem, der er i brug på alle 13 hospitaler.

Rent praktisk betyder konsolideringen, at alle 13 hospitaler i regionen nu kan dele oplysninger om patienterne digitalt. Skulle en patient flyttes mellem to sygehuse, kunne den eneste mulighed før i tiden nogle gange være at sende en kopi af papirjournalen med.

Samtidigt kan patienterne nu selv følge med i, hvad der bliver noteret om dem. Efter 14 dage kan alle oplysningerne tjekkes via sundhed.dk.

Projektet har krævet op mod 90 mand fra regionens it-division, Koncern IT, og leverandøren CSC. I alt er der blevet konverteret på 11 ud af 13 hospitaler.

3270-brugergrænseflade med kommandolinje

Opgraderingen har været på ønskelisten længe, for brugergrænsefladen i det tidligere Grønt System, også kaldet GS Classic, var mildt sagt ikke moderne.

»Det foregik med kommandolinjer i en 3270-baseret brugergrænseflade,« forklarer it-chef på Bispebjerg Hospital, Martin Sølvkjær, med henvisning til IBM's klassiske mainframe-system 3270.

Resultatet af en brugergrænseflade, der bestod af grøn tekst, blev, at lægerne overlod det til sekretærerne at bruge systemet.

»Lægerne brugte aldrig Grønt System Classic ret meget, fordi det var svært at have med at gøre. Nu kan læger og sygeplejersker nemmere gå til det, fordi vi får den Windows-baserede brugergrænseflade Opus oven på, og det er vigtigt,« siger Martin Sølvkjær.

Nogle dele af systemet vil dog stadig bruge den gamle, grønne kommandolinje.

It-chefen er generelt ikke imponeret over de brugergrænseflader, som leverandørerne af sundheds-it har præsteret.

»Hvis systemerne er gode, så kan folk jo faktisk sagtens finde ud af at bruge dem, men leverandørerne leverer ikke specielt gode systemer. De er ikke altid så intuitive, som de burde være. Vi har for eksempel aldrig undervist folk i at bruge internettet, for det kan de godt finde ud af selv, mens det er nødvendigt med kurser i den software, vi bruger på hospitalerne,« siger Martin Sølvkjær.

Leverandør forsinkede projektet

På Bispebjerg Hospital blev skiftet forsinket, fordi en leverandør af røntgenbilledsoftware ikke var klar med integration til tiden. Hvis hospitalet var kørt videre, uden at vente, skulle dataudvekslingen mellem de to systemer gå over til manuelt papirarbejde, forklarer Martin Sølvkjær.

Og den slags afhængigheder er der utroligt mange af i Region Hovedstadens hospitaler, hvilket har gjort opgaven med at konsolidere til et stort, kompliceret projekt.

»Hvis vi skifter en brik ét sted, kan der være mange andre integrationer, vi skal tjekke,« siger Søren Zachariassen.

Samtidigt er der mange andre forhold, der spiller ind, når der skal ny software og nye systemer ind på hospitalerne. Tit er en ordre så stor, at den skal i EU-udbud hvert femte år, selvom det ville være bedre for regionen at vente længere.

»Der går to år med udrulning, så kan man bruge det i to år, og så skal det udbydes igen. Vi vil gerne have længere kontrakter, der kan løbe i 10-15 år,« siger Søren Zachariassen.

Samtidigt ligger der en række gamle kontrakter, som regionen skal tage hensyn til, når der skiftes ud. Og så er der også grænser for, hvor store omvæltninger der kan ske på et hospital på én gang. Man kan ikke lige lukke et hospital ned en weekend, og de ansatte skal kunne bruge systemerne uden at ryste på hånden, når det skal tages i brug.

Konsolideringsarbejdet fortsætter for fuld damp i Regionen både i år og i 2010. Og stadig vil der være mange store og små systemer rundt omkring, som vil være forskellige på hospitalerne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Henrik Søfren

I indledningen står der: "En gammel mainframe-brugergrænseflade er nu forsvundet fra det centrale it-system hos hospitalerne i Region Hovedstaden".

Mig bekendt indeholder OPUS Patient i OPUS Arbejdsplads kun ca. 50% af den samlede PAS-funktionalitet - resten, f.eks. booking, administration af henvisninger, listetræk osv. sker stadigvæk i 3270-miljøet i "grønne linier", selvom systemet nu hedder "GS!Åben" og ikke længere "GS".

En tur rundt i hospitalerne i Region Hovedstaden vil vise mange "grønne skærme" i brug.

Der er lidt for meget "Ekstrablads-nyhed" over denne artikel, uanset hvor overdrivelsen kommer fra - det bidrager ikke til at opfatte Version2 som en seriøs formidler af IT-nyheder.

  • 0
  • 0
Martin Sølvkjær

Jeg har ikke set første version, så måske er det ikke helt præcist, hvad jeg nu vil fortælle.
Der synes at være lidt sammenblanding af begreberne.
Citatet ovenfor kan jeg stå ved (måske bortset fra min dårlige formuleringsevne ..aldrig..ret meget...):

»Lægerne brugte aldrig Grønt System Classic ret meget.... Nu kan læger og sygeplejersker nemmere gå til det, fordi vi får den Windows-baserede brugergrænseflade Opus oven på, og det er vigtigt,« siger Martin Sølvkjær.
Nogle dele af systemet vil dog stadig bruge den gamle, grønne kommandolinje.

Citatet fortæller:
- Der vil være flere læger og sygeplejersker, der bruger OPUS, fordi det er mere indbydende.
- Der vil være nogle, der fortsat bruger den "grønne" kommandolinie.
Dvs jeg synes ikke man kan klandre Jesper for overdrevne ekstrablads-nyheder (hvad siger EB iøvrigt til det?). Den "grønne" er forsvundet for de fleste læger og sygeplejersker.
Men vores (ekstremt) dygtige, rutinerede sekretærer bruger fortsat den "grønne". Så den er stadig moderne - effektiv. Jeg beundrer vores sekretærer for deres indsats og professionalisme i forbindelse med at skifte fra et system, der lå på rygmarven til et system, hvor man - trods ligheder - skal genindlære rigtig meget. Og samtidig får de så meget fra hånden. Måske skulle man skrive en lille historie om dagligdagens helt, sekretæren, der trods de vanskeligheder, der altid er med at skulle tage et nyt system i brug, giver et ekstra nap og får tingene til at virke.
Faktisk havde vi tidligere en lille fiks overbygning, der viste journalnotaterne som de så ud på det udskrevne. Mange læger, der ikke brugte den "grønne" kommandolinie brugte vores lille dogme-journal, da det var det sted, journalnotaterne først var tilgængelig. Også selvom papir-journalen var væk.
Hvad er der iøvrigt galt med det grønne ? Alle vil for tiden være grønne og bæredygtige.
Velkommen til de grønne og bæredygtige hospitaler - ja undskyld, jeg blev vist grebet af forårsstemningen.

  • 0
  • 0
Jens Madsen

Den grønne kommandolinie, har mange fordele fremfor et windows baseret system:

1) Nemmere at udvikle. Det betyder mindre risiko for fejl.

2) Nemmere at teste. Til den grønne kommandolinie, er muligt at udføre testscripts hvis den designes korrekt. Det er både muligt med advancerede testscripts, der tager hensyn til svar, og simple testscripts, hvor der altid er et givet svar, til et bestemt input. Normalt, skal systemer helst udvikles så et givet input så vidt muligt har et enentydigt bestemt svar af hensyn til bedst mulig overskuelighed i testfasen.

3) Det er forholdsvis simpelt at specificere tekniske detaljer såsom svartider for en kommandobaseret løsning - og de kan nemt testes. Sendes en kommando af sted, vil et test script kunne tjekke, om svartiden opfyldes.

4) Logning. Ordrer, der udføres via den grønne kommandolinie er nemt at logge - og også at logge svaret. Det betyder, at der via loggen nemt kan ses, hvad der er gået galt. Selv en bruger, der kender syntaxen af den grønne kommandolinie, vil kunne debugge fejl.

5) Scripts løsninger. Den grønne kommandolinie, fungerer godt sammen med script løsninger. Du kan lave små "programmer" der løser besværlige opgaver i et script sprog, skrevet til kommandolinie løsningen.

6) Hurtig kommunikation via net baserede løsninger. Der skal kun få ASCII tegn til at lave en forespørgsel via kommandobaserede løsninger, og de belaster oftest netværket mindre end web baserede løsninger. Et enkelt bogstavs kode, kan nemt medfører hundrede eller tusinder af tegn i et web baseret system, hvor der i et kommando baseret system, kun optager et tegn.

7) Hurtigere svartid på software. En server, baseret på kommandoliniesystemet, kan koncenterere sig om det opgaven faktisk er - og det betyder, at den typisk vil have langt hurtigere svartid.

Ialt, vinder en kommandobaseret løsning på alt, undtagen brugervenligheden for nybegynderen. Selv den advancerede bruger, foretrækker ofte kommandobaserede løsninger. Som eksempel, bruger en kommandobaseret løsning ikke mus - og musen sløver oftest operationerne ned. Når jeg lukker windows ned, foretrækker jeg CTRL ALT DEL + ALT L + ENTER, fremtfor at skulle bruge musen til det samme. Det tager 3 gange så lang tid at bruge mus som taster, for den lidt øvede. I butikker, har man visse steder erstattet kasseterminalerne med windows baserede systemer, hvor ekspedienten bruger en mus, til at klikke tallene med. Det fungerer, mest fordi at næsten alt har stregkode på. Ellers, er det meget langsommere, end et traditionelt tastatur baseret system. Grunden til at mus og pege systemet er blevet så populært, er mest at mange ikke har lært at skrive på maskine, og måske endog har angst for det - fordi de ikke har lært det. En, der kan skrive på maskine, kan normalt fyre omtrent 10 - 20 tegn af i sekundt, og med øvelser, går det langt hurtigere end mus.

Da næsten alle fordele ligger i kommandoliniebaserede systemer, og at windows baserede systemer normalt huskes mest for problemerne, så er et kommandoliniebaseret system at foretrække i næsten alle tilfælde.

Ulempen er, at mange brugere ønsker et windows baseret system, hvor der bruges mus og pegeredskaber. Mest ideelt, er at bygge et sådant system ovenpå kommandoliniesystemet, således at dets fordele bevares. F.eks. testbarheden af det kommandobaserede system, mulighed for at skrive scripts, mulighed for de færre tegn der skal overføres osv. Har en grafisk brugergrænseflade et underlæggende kommandobaseret system, kan man logge alle ordrer fra brugergrænsefladen og anvende dette, hvis dele heraf skal anvendes i makroer, eller ved debugning.

Endeligt, deles opgaven i to naturlige dele, der kan testes uafhængigt, hvis der på et kommandobaseret system, klistres et web-baseret system ovenpå, eller en grafisk brugergrænseflade. Logningsmuligheden gør, at dem der har lavet kommandosystemet, nemt kan vise at det svarer korrekt, og at fejlen ligger i den grafiske brugergrænseflade - eller modsat, at fejlen er i kommandoliniedelen, og ikke i brugergrænseflade. Men ikke mindst muligheden for test scripts, og for at lave test-scripts, der har bestået testen med at "enhver linie og branch retning er berurt" i programmet, gør at der er større sandsynlighed for, at fejl opdages, når kode modificeres og test scriptene køres, som programmørerne har udviklet, efter enhver modifikation. Gør programmøren fejl, opdages de hurtigt. Fejl, på grund af rettelser i softwaren for kommandoliniedelen, kan derfor i høj grad udelukkes, da testvektorerne oftest opdager indførte fejl.

Brugergrænsefladen, kan også testes uafhængigt, ved at undersøge om den affyrer de rette kommandoer, og reagerer korrekt på svar.

Som jeg ser det, er kommandolinier på et højere videnskabeligt niveau end musebaseret grænseflade. Kommandolinier, består af strenge, der relativt nemt kan gennereres og behandles datalogisk, meddens museklik og musegrænseflade, er tæt på datalogisk udeffinerebare. Det betyder med andre ord, at det også langt nemmere opstår fejl i musedrevne grænseflader.

  • 0
  • 0
Jens Madsen

FTP er også "inderst inde" et kommandoliniebaseret system. Med telnet, kommer du ind i en FTP klient, med hjælp osv. Professionelt software, skrives normalt som kommandoliniesoftware, hvor programmet kan bruges med f.eks. en telnet klient manuelt, og testes ved hjælp af test software, og script moduler, der lægges ovenpå. Et standard script modul, kan også lægges ind mellem to tekstbaserede brugergrænseflader, så brugergrænsefladen får adgang til script facilitet. Faciliteter som "hjælp" er også vigtige, da brugergrænsefladen derved kan tjekke for funktionaliteter, og eventuelt grå ud manglende faciliteter, eller skifte til en mere "simpel mode", hvor kun basale funktioner bruges. Som regel, vil man vælge et system, der gør det er nemt at kode - men uden det går ud over brugervenligheden for den direkte telnet adgang.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize