Labka
J. Uffe Christiansen (diskussion) 14. feb 2018, 14:04 (CET)
Labka LIS system
Labka er navnet på et Laboratorie Informations System til sygehus-Laboratorier, Klinisk Biokemiske Afdelinger.
Labka var et dansk udviklet IT-system, som kørte i 33 år, i perioden 1979 til 1988 på Rigshospitalet i København (RH) og i perioden 1984 til 2012 på to tredjedele af sygehusene i Danmark. Navnet Labka fik IT-systemet i 1984. Labka-systemerne understøttede i alt en produktion på ca. 50 millioner analysesvar årligt (2004).
Labka systemerne var implementeret på minidatamaten fra Hewlett Packard HP 1000.
I 1997 blev Labka udvidet med Labka Sygehus-Pakken (LSP) , som gjorde det muligt at få direkte tilgang til Labka fra sygehusenes kliniske afdelinger. I 2006 var der 37.600 brugere.
Labka-systemerne var, på nær tidsmæssige forskydninger grundet løbende opdateringer, ”ens” på de forskellige laboratorier, men blev tilpasset individuelt via ”konfigurationsparametre”.
'''Labka II''', som beskrivelsen IKKE omfatter, blev introduceret ca. 2005, herefter blev Labka undertiden, (men IKKE i denne beskrivelse), benævnt Labka I. Labka II erstattede efterhånden Labka på sygehusene i de tidligere Nordjyllands og Midtjyllands amter og enkelte andre sygehuse. Ligeledes blev Labka II, efter udbud, leveret til hele Region Hovedstaden. Labka II er baseret på ”ideer” fra Labka, men fra starten baseret på ny teknologi som relationsdatabase, Unix, Java, objektorienteret tilgang, grafisk brugergrænsesnit, Windows-instrument server og for integration med de kliniske afdelingers terminaler HTML. Ligeledes var diskkapaciteten/ydelsen og den centrale processorkraft af en anden størrelsesorden. Driften af systemet var helt anderledes. Udviklingen af Labka II varetoges i CSC regi.
Udover beskrivelsen jævnfør nedenstående indholdsbetegnelse er HP 1000, Labka og Labka Sygehus(Hospital)-pakken også lagt som 2 Playlister/videoer på engelsk på YouTube. Den løbende udvikling af HP 1000 og RTE A ’s udvikling og faciliteter og modulopbygning af Labka software mm. er her illustreret med eksempler på et kørende HP1000 A990 system.
Kort om klinisk biokemiske afdelinger (1979-2011)
Den Klinisk BioKemiske Afdeling (KBA), blev tidligere kaldt den Klinisk Kemiske Afdeling og endnu tidligere Centrallaboratoriet. Afdelingen analyserede prøver for hele sygehuset, også ofte for amtets praktiserende læger, på prøvemateriale som blod, urin, spinalvæske mm. KBA fungerede, på næsten alle sygehuse, alle årets dage, hele døgnet.
Analysearbejdet blev udført af KBA’s laboranter, senere ”benævnt” bioanalytikere, lige som de allerfleste prøvetagninger i ambulatorier og på de kliniske afdelinger/ sengeafdelinger foretoges af laboranter. Prøvetagning kunne også foretages af den kliniske afdelings personale eller hos den praktiserende læge eller i sjældne tilfælde i patientens hjem. I Sverige foretoges prøvetagning hovedsagelig af de kliniske afdelingers personale.
Laboratoriernes størrelse varierede, målt på en årlig ”produktion” af analysesvar fra 50.000 til over 6 millioner. Personalet udgjorde tilsvarende fra 10 til op mod 100 laboranter.
På KBA udførtes endvidere forskning, og på de større sygehuse var der på KBA ”forsker-grupper”.
Ledelsen på de enkelte laboratorier (rutine-delen) var oftest en klinisk biokemisk speciallæge/ overlæge, samt en ledende laborant/ bioanalytiker. Flere laboratorier havde endvidere kemiske specialister (fx cand. scient’er/ ingeniører) ansat.
Listen over analyser som laboratoriet kunne udføre, kunne indeholde mere end 800 analyse ”typer”
En analyse blev ”identificeret” ved: System-komponent-kvantitetsart, enhed,(dvs. "Navnet" på analysen). Til analysen knyttedes endvidere en patient via personnummer, et prøvetagnings-tidspunkt, prøveglasidentifikation via glasnummer, analyse-tidspunkt, en prøvetagnings og en analyse prioritet, et alders/ køns /graviditets afhængigt referenceinterval, svar adresser, samt flere administrative oplysninger.
Visse analyser var gruppe-analyser, som fx en differentialtælling (antal celler fordelt på de enkelte celletyper i blodet ), glukosebelastning, dvs. en analyse af glukose med flere prøvetagninger på patienten på flere forskellige fastlagte tidspunkter. Endvidere ”rekvisitionsgrupper” som fx væsketal mm.
I 1979 blev der udgivet et dansk Klinisk Kemisk Kompendium (F.A.D.L.s forlag 500 sider, Henrik Olesen, Knud Kjeldsen, Inge Ibsen). Et værk indeholdende specifikationer, ” vejledninger” mm. vedrørende kliniske kemiske analyser.
På KBA var der installeret adskillige mindre og større maskiner/analyse-apparater af forskellig type. Den største del af maskinerne kunne udføre adskillige forskellige typer af analyser. De større maskiner kunne ud over selve analyseenheden, fx fotometre, tællere, elektroder mm., indeholde mange forskellige reagenser, samt pipetterings enheder, transport bånd samt ”små” dataanlæg. Senere tilkom indbyggede enheder til afmontering af prøveglaslåg, centrifuger med automatisk tarering mm.
Næsten alle nyere maskiner kunne sende svar til et IT-lab system (seriel kommunikation, RS232C) og de større maskiner kunne ligeledes modtage analyse-bestillinger, (prøveidentifikation plus relevante rekvisitionsinformationer).
Kort om Labka’s funktion på sygehusene, i store træk (1979-2011)
Groft kan procedurerne opdeles i: Rekvirering, Prøvetagning, Prøvefordeling og præparation, Analysering, Kvalitetskontrol, Lagring, Rapportering, Rettelser, og Opfølgning.
Rekvirering
Foretoges tidligt på fortrykte prøvetagningsblanketter med vedhæftede glasnummeretiketter. Indtastning af rekvisitionsinformationer samt rettelse af samme, kunne foretages fra laboratoriets skærmterminaler.
Tidligt anvendtes, på de fleste sygehuse, fortrykte blanketter, som kunne læses optisk via Optical Mark Readers (OMR) , forbundet til Labka, jævnfør billedet. De fortrykte blanketter havde undertiden de ”vedhæftede” etiketter til mærkning af prøveglas i et 2. lag med gennemslagspapir, som vist i eksemplet. Etiketterne var ”fordelt” på blanketten svarende til den type prøveglas og antal, som skulle anvendes, samt opdelt svarende til de pågældende sektioner i laboratoriet, dvs. også under hensyn til de analysemaskiner, som prøveglassene skulle fordeles til.
Den indlæste information fra OMR læseren kunne (via glasnummeret, læst ved brug af barkode pen, fra en ”omr-fil”) hentes op på skærmterminalen, som på denne måde blev forudfyldt med de rekvirerede analyser, ekspeditionskoder og rekvirerende afdeling. Dernæst kunne skærmbilledet suppleres med yderligere informationer, før rekvisitionen blev lagret i Labka's "Arbejdsregister".
Navnet på patienten indtastedes i de første Labka systemer, men Labka ”huskede” navnet til brug ved senere rekvirering. Senere etableredes en ”Labka-Navnedatabase”.
Rekvisitioner kunne ligeledes modtages via EDI fra praktiserende læger.
Metoden indebar, at rekvisitions- og prøvetagningsblanket blev dannet i én arbejdsgang, med få stregmarkeringer, samt at OMR læsning nedsatte arbejdsbelastningen og øgede rekvisitions-inddateringshastigheden. Rekvisitioner skulle være indlæst før ”automatisk” analysering af prøver kunne udføres.
Analysering af prøver kunne dog igangsættes og resultatet modtages/godkendes i Labka, før rekvisitionsinformationerne var inddateret (fx ved ”særlige haste-prøver”), men sammenkobling med rekvisitionsinformationerne skete først automatisk eller halvautomatisk når disse var inddateret.
Eksempel: På Labka i Aalborg (HP 1000 Computeren på Aalborg Syd, som også understøttede sygehusene i Aalborg Nord, Farsø, Hobro samt Psykiatrisk afd.) blev der, via 7 OMR læsere og op til 64 skærmterminaler (juni 1997 før LSP) inddateret op mod 1.400 rekvisitioner i døgnet, heraf ca. 800 i morgen/ formiddagsperioden. Yderligere EDI rekvisitioner fra praktiserende læger, som blev godkendt/ kvitteret op mod 800 per døgn, i alt 2.200 rekvisitioner og 22.000 rekvirerede analyser.
Med indførelse af Labka Sygehus-Pakken(LSP), første gang 1998 i Århus Amt, kunne personalet på sygehusenes kliniske afdelinger indtaste rekvisitionsinformationer/ ønskede analyser, og prøvetagnings blanketter PTB’er kunne udskrives på KBA, ambulatorier eller på de kliniske afdelinger.
Prøvetagning
Blev oftest foretaget på grundlag af fortrykte PTB’er. Efter LSP på basis af de udskrevne PTB’er. Glasnummeret på rekvisitionen, som var indeholdt i barkoderne på etiketterne, identificerede prøveglassene. Dette var normalt på 8 cifre, inkl. checkciffer. Undertiden kunne nummeret indeholde en ”extension” på 2 cifre fx til identifikation af specielle glas/prøvemateriale. Prøveglassene kunne være af meget forskellig type, ofte mærket med forskelligt farvet ”prop/låg”.
Udskrift af PTB’en kunne foretages hel eller halvautomatisk, fx til en prøvetagningsrunde eller enkeltvis. I forbindelse med udskrift af PTB’en kunne laboranten/klinikeren (fx i et ambulatorium) få en oversigt over alle patientens rekvisitioner i LSP, herunder forudbestillinger, og dermed sikre sig, at alle relevante prøver blev taget på den pågældende patient.
Patientens ”senge-adresse” informationer kunne umiddelbart ”flyttes”, således at laboranten gik til den afdeling patienten ”nu” lå på, og således at analysesvar også kom til denne ”nye” afdeling.
Indtil udskrift af PTB’en kunne Rekvistionen/PTB’en umiddelbart rettes, også fra klinikernes terminaler. Idet øjeblik PTB blev udskrevet, blev PTB’en mærket i LSP, hvilket indebar at klinikerne på de kliniske afdelingers terminaler kunne se, at nu var den pågældende prøvetagningsproces på patienten i gang. Den kliniske afdeling fik hermed mulighed for at tage kontakt til laboranten og få taget en ekstra prøve/analyse på patienten på dette senere tidspunkt. I denne forbindelse kunne den ekstra ”tomme” PTB-etiket benyttes.
Typer af PBT-labels, arbejdsgange mm. fremgår af LSP- videoen kapitlerne: LSP- Rekvisition Grundigere/Flyt Patientens Rekvisitioner/ Prøvetagnings-blanketter (PTB).
Prøvemateriale, modtagelse, registrering og fordeling
Når prøven ankom til laboratoriet og var registreret, blev den fordelt. Til hjælp for fordelingen var, fx udover farven på ”låget”, også informationerne på barkode-etiketten. Visse prøver skulle forbehandles, fx centrifugeres. Rekvisitionsinformationer blev sendt online til de respektive analysemaskiner, hvor dette var muligt. Rekvisitionsinformationer sendtes også automatisk online via Labka’s ”Udvekslingssystem” til andre Labka sygehuselaboratorier i amtet, såfremt analysen ikke udførtes på eget laboratorie, og resultater sendtes ligeledes retur automatisk til eget laboratorium. Sendelister også for fremmede laboratorier, fx Seruminstituttet, kunne ligeledes udskrives.
I forbindelse med at laboranten kvitterede for prøvematerialet, kunne rekvisitionsinformationerne opdateres inden de førtes videre til Labka’s Arbejdsregister, hvor rekvisitionsinformationerne var tilgængelige for overførsel til analyseinstrument mm. Hermed var det muligt, på dette senere tidspunkt, at rette på rekvisitionen, fx at bestille yderligere analyser. Rekvisitionen i Arbejdsregistret kunne ligeledes endnu senere rettes/opdateres, men kun fra Labka-terminaler.
Realtidsopdatering af Arbejdsregistret indebar, at klinikerne på afdelingernes terminaler nu også kunne følge analyseprocessen, dvs. både se færdige analyseresultater og hvilke analyser som var i proces/ restordre.
Analysering
Maskinerne/apparaterne foretog, på baggrund af rekvisitionsinformationerne, hovedsageligt overført online fra Labka, analysering af prøverne og sendte analyseresultaterne sammen med glasnummeret til Labka's "online kommunikations og behandlings systemer". Analyse resultatinddatering samt rettelser af samme kunne ligeledes foretages fra laboratoriets terminaler.
Kvalitetskontrol
Kunne foretages på analyseapparaturet eller på Labka. I forbindelse med analysering /kontrol kørtes ofte forskellige ”kontroller” med ”kendt resultat”. På Labka foretoges hovedsagelig en kontrol for ”drift” samt en test for ”randomiserede fejl”, samt ”grænse/interval test”, endvidere undertiden test for afvigelser ved ”dobbelt bestemmelser” mm. metoder inspireret af Westgard and Groot.
Lagring
Efter kvalitetskontrol, og undertiden manuel godkendelse, lagredes resultater og disse knyttedes via glasnummeret og personnummeret til patienten. Rekvisition og svarinformation lagredes i det første system i et mindre register, et (specielt) ”fil-system”, som kun kunne indeholde ca. 5.000 rekvisitioner og ca. 23.000 svar. Senere blev fil-systemet udvidet til mere end det 3-dobbelte og en netværksdatabase (HP-IMAGE II) blev tilføjet. Dette øgede lagringskapaciteten op til 20 millioner svar, ligesom systemet kunne indeholde en personnummer/navnedatabase over samtlige indbyggere i amtet. Efter udbygning med LSP voksede kapaciteten yderligere.
Rapportering
Udskrifter kunne foretages enten rekvisitionsorienteret, dvs. rekvisitionsinformation med tilhørende svar, hvilket var metoden i den tidlige fase, eller kumuleret på laserskrivere fra 1988. Efter 1998 hvor LSP blev introduceret, kunne kumulerede svar udskrives på de kliniske afdelingers laserprintere.
Udskrifter kunne foretages løbende samtidig med de øvrige processer, som rekvirering, indrapportering osv. Udskrivning foretoges normalt adskillige gange dagligt, med forskellige selekteringskriterier, fx kun prioritet haste, fremskyndede og "komplette" svar. Restordre, dvs. endnu ikke ”færdige svar”, blev markeret.
Svar blev efter 1992, Odder-Lab Kommunikations projektet, også sendt som EDI automatisk til praktiserende læger.
Svar kunne opsøges både som rekvisitionsorienteret og kumuleret på laboratoriets skærmterminaler. Efter 1998 kunne kumulerede svar søges via LSP fra de kliniske afdelingers skærmterminaler/pc’er. Svar fra alle laboratorierne i amtet fremstod, som om de var lagret i en stor database.
Rettelse af rekvisitionsinformationer eller analysesvar fremgik af svarrapporteringen.
Fra ca. 2001 kunne Labka /LSP- systemet i Vejle Amt også indeholde svar fra Mikrobiologisk afd., ligesom Mikrobiologiske svar også kunne opsøges separat, således at disse få svar ikke ”druknede i mængden” af andre svar, hvilket især var væsentligt, grundet en større udbredelse af multiresistente bakterier.
Rettelser Ændringer
Rettelses/opdaterings- muligheder i forbindelse med næsten alle data og processer: Rekvirering/ PTB’er/ prøvemateriale-kvittering/ Kumulerede svar osv. var særligt vigtige, da patienternes tilstande og behandlinger ændres løbende og informationerne kom asynkront, med meget varierende tidsintervaller.
Rettelser var den ”vanskeligste” IT-proces, idet den involverede mange af de øvrige processer. Hertil kom problematikker som samtidighed, låsning, mærkning og særlige rapporteringsforhold. Både rekvisitionsinformationer og svarinformationer kunne rettes via to tilsvarende Labka-skærmbilleder.
Opfølgning, produktion, svartider og udtræk
Mangel-/arbejdslister
Et hyppigt anvendt modul til løbende kontrol og sikring af, at alle rekvirerede analyser blev udført betids eller alternativt, at analyseresultaterne blev mærket som mislykket/annulleret.
Årsager til manglende (godkendte) analyseresultater kunne være mange: Fx problemer med et instruments analysekanal, prøvematerialet, resultatet uden for måleområdet, utilsigtet drift af analyse-processen eller andet fanget af kontrolsystemet, centrifugen, transportbånd, sendeprøve-resultater ikke kommet retur fra eksterne laboratorier, lang analysetid, gemmeprøve-problematik eller forglemmelse.
Laboranterne, som havde ansvaret for de pågældende sektioner i laboratoriet, anvendte især proceduren nær ”dag-arbejdsdagens” slutning. Forskellige delmængder kunne vælges (billedet).
LSP PTB/Prøvetagningsregistret kunne ligeledes overvåges, til sikring mod glemte prøvetagninger eller registrering/kvittering for afleveret prøvemateriale.
Belastning
Belastning af HP 1000 og personalet kunne visualiseres ved hjælp af målinger via programmet Labmeter.
Laboratoriets svartider
Laboratoriets ”svartider” giver et indtryk af, hvorledes "arbejdsgangen" i laboratoriet fungerede i samspil med Labka systemet. Denne svartid måltes fx fra prøvetagning eller inddatering af rekvisition (billedet) til godkend svar var lagret, fordelt på forskellige ekspeditionskoder, fx haste(U), fremskyndet(F), rutine(R) mm. Udtrækket kunne foretages ved hjælp af programmet Labmeter.
HP1000/ Labka (LSP) svartider
Svartiderne blev målt på HP 1000 på Aalborg Sygehus Syd, som også understøttede sygehusene i Aalborg Nord, Brovst og Farsø, med henblik på at undersøge, om HP1000-Labka systemet kunne udvides med LSP (mere end 1000 terminaler på de kliniske afdelinger) og stadig fungere med rimelige svartider. (Belastningstest og måling tirsdag 19. april 1998) Svartiden blev målt for en inddatering af en rekvisition. Metoden var at indlægge ekstra programmer, svarende til den fremtidige LSP belastning, oveni den almindelige rutineproduktion i dagarbejdstiden på en travl dag (2.187 rekvisitioner og 19.040 svar i døgnet). Programmerne emulerede den ekstra CPU og diskbelastning/semaforlåsning mm. Disse ekstra programmer målte endvidere CPU-tid og total-tid, disk-tid og schedulerings-tid (jævnfør billedet).
Produktionsmængder
Data til administrative formål blev løbende udtrukket, fx måneds- og årsoversigter over udførte analyser med arbejdspoint/ ”priser” fordelt på ekspeditionskoder og rekvirenter, til brug ved styring af driften. Opgørelserne blev ofte også anvendt til sammenligning med andre sygehuslaboratorier.
Udtræk fra databasen til videnskabelige formål mm.
Via HP QUERY højniveau ”kommandoer” kunne udtræk og rapportering fra HP IMAGE databasen foretages.
Labka databasen var designet til produktionsformål. Løbende direkte udtræk til andre formål belastede produktionen (for) meget, idet en lang kæde ”ofte” skulle læses igennem. Med LSP og ”parallel” og eksterne relationsdatabaser, etableret på selvstændige systemer, ændredes mulighederne radikalt.
I 1960’erne var der af klinisk kemikere i Danmark udarbejdet :”Et rationelt, logisk terminologisystem for laboratorieundersøgelser og deres resultater”. Modellen ledte til internationale standarder for dette område i den følgende 10-årige periode. Data i Labka blev fra begyndelsen (1979) behandlet og lagret i henhold til disse principper.
Langt senere blev der til disse målte/ lagrede data ”knyttet” det såkaldte NPU nummer, inplementeret i Danmark 2001. NPU nummeret kunne på ”entydig vis” knyttes til (næsten alle) de målte/ lagrede Labka resultater.
Det har således været muligt senere, at opbygge fx ”LABKA database for research projects” med ældre Labka resultater, som kan ”samkøres” med andre ”sundhedsdatabaser” til forskningsformål.
En Manual som vejledning for forskere til brug af databasen er udarbejdet i 2016.
I en oversigt over brug af Medical Databases fra Aarhus Universitet, findes Labka Research databasen og dens indhold/ datatyper mm. beskrevet, ( side 13).
Det fremgår heraf, at fra henholdsvis Nordjyllands og Aarhus amt findes (for ”nuværende”, 2009) ”komplette analysesvar” for perioderne
fra 1. januar 1997--- 31. marts 2005 og 1. januar 1995--- 31. december 2006.
Der blev også udtrukket data til andre databaser, således blev mere end 300 millioner analysesvar flyttet fra Labka-paralleldatabaserne i de tidligere Frederiksborg og Nordjyllands amter mm. til Laboratoriesvar Portalen.
Årsagerne til lagring af større datamængder/ analysesvar, (også før 1992) samt metoderne hertil, fremgår af afsnittene,
Grundsystemet – basiskonstruktionen/ IMAGE II – Labka databasens struktur og størrelse/ betydning.
LABKA forskningsdatabasen år 2020 og RLRR databasen
LABKA forskningsdatabasen (LABKA-fdb) og Register of Laboratory Results for Research (RLRR) er to fungerende forskningsdatabaser beskrevet i Existing Data Sources in Clinical Epidemiology: Laboratory Information System Databases in Denmark (Dove Press journal: Clinical Epidemiology). Jævnfør artiklen er RLRR etableret/ påbegyndt ca. 2013, medens LABKA-fdb indeholder komplette data fra Nordjyllands Amt tilbage fra 1997 og for andre områder endnu tidligere. Labka-fdb indeholder patientdata for mere end 2,4 millioner patienter og mere end 1 million patienter fra 1999 til 2007.
Databasen opdateres ca. hver 18. måned, medens RLRR Databasen opdateres hver måned. RLRR er først åbnet for forskere i 2018. En del videnskabelige arbejder og kurser, er blandt andet derfor, baseret på Labka-data fra LABKA-fdb, samt det danske Cancerregisteret (DCR) og det danske nationale register af patienter (DNRP), fx kohorte relaterede undersøgelser, som Forhøjede plasmavitamin B12-niveauer og kræftprognose: Et befolkningsbaseret kohortestudie
Om begyndelsen
”Labka’s” opstart/ drift på Rigshospitalet 1979-1988
På Rigshospitalet (RH) var der i 1979 et stort laboratorium kaldet Centrallaboratoriet (CL 3011) og et mindre laboratorium kaldet Mikrolab (ML 4051).
Mikrolab havde omkring 1979 en årlig produktion på ca. 200.000 analysesvar, medens produktionen på CL var flere gange større. Mikrolab betjente hovedsagelig RH’s sydfløj, blandt andet føde- og børneafdelinger, herunder afdelingen for fortidligt fødte børn. Analyser på meget små børn krævede særlige forhold omkring blodtagning, små prøvemængder mm., samt specielt analyseapparatur. CL og Mikrolab samarbejdede, men havde hver sin ledelse.
Labka blev udviklet til og i samarbejde med Mikrolab, af RH’s Ingeniørafdeling , senere ”kaldt” Medicoteknisk afdeling. CL havde et ”eget” IT-laboratoriesystem, implementeret på en ældre series CDC 3300 mainframe, som blev understøttet af RH’s dataafdeling. I CL’s IT-system indgik hulkort med påklistrede ”glasnummer-etiketter”. CL IT-systemet havde i 1979 ingen online forbundne analysemaskiner til CDC 3300. CDC 3300 blev senere erstattet med en IBM mainframe, adskillige kalkulatorer HP 9915A, ligesom RH’s dataafdeling blev oprustet, herunder fik ny ledelse.
Minidatamater med realtids operativsystem kunne i 1978 fås til en ”overkommelig pris”. Minidatamat systemet kunne således anskaffes i stedet for 3 større kalkulatorer, som var afsat på budgettet til ML, i forbindelse med bygning af RH’s sydfløj. Dette gav mulighed for anskaffelse af et mindre minidatamat realtids system og etablere online forbindelser til analysemaskiner.
Hardware konfiguration for ML’s minidatamat 1978
- En HP1000 21MX CPU, 500.000 instruktioner/sekund
- Hukommelse: 160 KB
- Diske: 2,5 MB fast pladelager samt 2,5 MB udskifteligt pladelager HP 7900
- 1 stk. multiplekser med 16 serielle (RS232) indgange
- 3 stk. HP skærmterminaler HP 2640, den ene med 2 kassette båndstationer
- 1 Konsolterminal 30 ch/ sek. Silent 700
- 1 stk. HP 2607A linjeprinter (brugt), 200 linier/min.
Realtids operativsystemet :HP RTE III. Programmeringssprog: Fortran-IV og HP Assembler
IT-lab systemet på ML blev sat i drift i 1979 og kørte i 9 år med 2 stop. (2 disk single-track errors, tracks spared)
IT-systemet håndterede basisfunktioner som: ’’Rekvirering, svar-indrapportering, rettelser af rekvisitions- og svarinformationer, mangellister, (valgbar selektiv /”hyppig”) udskrivning/ rapportering, sammenkobling af rekvisitions- og svarinformationer (forbytningstest), kvalitetskontrol, søgning samt online kommunikation af rekvisitioner og analyseresultater til Greiner Selektive Analyser GSA II, som analyserede hovedparten af laboratoriets kemiske analyser.
Linjeprinteren havde 132 char. per linje. Ved at udskrive i to baner á 66 karakterer og klippe bunken over på midten, ”fungerede printeren” næsten som en 400 linje/min printer. En væsentlig detalje, da rutinesvar skulle ud inden aftenstuegang.
Driften af IT-systemet blev varetaget af ML’s personale.
Konstruktionen af systemet på ML medførte, at alle procedurer kunne udføres i realtid. Det medførte i praksis , at laboratoriets svartid, ”fra rekvirering til svarrapportering” blev reduceret, hvilket igen førte til, at antallet af hasteprøver faldt med 50% på ML, grundet den generelle svartid for ”rutine og fremskyndede analyser” var reduceret.
En hasteprøve/analyse antoges i gennemsnit at koste ca. det dobbelte af en rutineprøve/analyse.
Fordelene ved de korte svartider, bedre oversigt mm. indebar, at man midlertidigt fraveg ”data-planer”, dvs. RH’s Ingeniørafdeling, trak et data-kabel direkte på ”langs” i RH Sydkomplekset, til afdelingen for præmature børn, så denne afdeling fik sin egen skærmterminal til ”Labka”.
Ca. 1982 blev systemet opgraderet med en HP 1000 A600 CPU, (med dobbelt CPU-kapacitet) større hukommelse, større disk, samt en magtape enhed. RTE-A, Fortran 77 og senere HP netværksdatabasen IMAGE-II.
Det første ”eksterne” sygehus, Århus Amtssygehus(AAS) i 1984
Et halvdags ”seminar”/demo blev holdt hos HP Birkerød og på AAS i 1983. KBA’s ledelse på AAS besluttede at købe et sådant system, dog under forudsætning af, at såfremt IT-systemet ikke blev understøttet i rimeligt omfang, skulle kildeteksten være frit tilgængelig til brug på AAS. Medvirkende, og en væsentlig årsag var, at AAS/ KBA havde en kemiker (cand.scient.) ansat, som havde erfaring med IT og HP 1000, og som i nødstilfælde kunne tage over.
Dette blev starten til et ”kommercielt understøttet” Labka, og virksomheden Dansk Datalab ApS. samt et samarbejde med RH-ML, AAS-KBA, og få år senere KBA på Slagelse Centralygehus og Karlskrona Centrallasarett. I 1986 var bemandingen i alt 3 ”IT-personer” samt en ½ tids sekretær. Den ene IT-medarbejder var også uddannet som laborant.
Årsager til Labka’s store udbredelse og lange levetid
Fra 1979 og 10 år frem var Labka kendt for sin brugervenlighed/ fleksibilitet, underbygget af realtidsfunktioner. Beskrevet i artiklen fra 1989, LABKA. ”A real-time computer system for the clinical laboratory"
De to mest i øjnefaldende årsager til Labka’s udbredelse og den lange levetid
Fra 1989 var de to mest i øjnefaldende årsager til Labka’s udbredelse og den lange levetid, det kumulerede rapporteringssystem (1987) og Labka Sygehus-Pakken, første gang installeret i Århus Amt i 1998.
Det kumulerede rapporteringssystem (1987)
Det kumulerede svar-system var et modul, som fik væsentlig indflydelse på patientsikkerheden samt for sygehusenes behandlinger og besparelser.
Før 1987 overførtes svar, på de allerfleste sygehuses kliniske afdelinger manuelt fra de udskrevne sedler til laboratorieskemaer, således at lægen umiddelbart kunne aflæse patientens analyseresultater som ”funktion af tiden”. Fejl ved denne overførsel (forkerte tal, kommaer, tal ud for forkerte analyser, forkerte kolonner, forkerte ark osv.), var adskillige. Fejlhyppighed på op mod 13 % var ikke ualmindeligt.
Antallet af udskrevne kumulerede Labka-svar androg ca. 25 millioner ”nye” svar per år, 2004.
(Selve udskriftsmængden var ca.100 millioner, da samme svar forekom flere gange. Op mod 50% blev sendt via EDI).
Eliminering af det manuelle arbejde med overførsel af svar til laboratorieskemaer indebar ligeledes store direkte besparelser.
Fremkomsten af Labka’s kumulerede svarsystem var en væsentlig årsag til levering af Labka til sygehusene til hele Vejle amt i 1988-89, og påvirkede forholdene væsentligt i den følgende periode.
Systemet havde den ”feature”, at den sidste side altid blev fyldt op med 10 kolonner, således at lægen normalt kun behøvede at se på sidste side og det medførte også at de relevante analysesvar på siden altid stod i samme række. Nye (dvs. siden sidste udskrift) svar og rettelser blev vist fremhævet i fed skrift , (billede, Kumuleret svarsudskrift 1988)
Data blev ny-sorteret, om nødvendigt, ved hver udskrift, således at kom der en ”ældre” rekvisition med analysesvar, som skulle ind på en ældre side, således at kolonner skulle ”bytte” plads på siderne, blev de relevante sider automatisk genudskrevet. En relativ sjælden hændelse, men som fx kunne opstå, hvis en ældre rekvisition med svar, kom ”dumpende” fra et ekstern laboratorie/ praksislæge, vedrørende en patient, som var ankommet til sygehuset dagen før og behandlet akut på intensiv afdelingen. Rettede rekvisitionsinformationer eller svar blev markeret.
Udskiftning af sider var enkel: Se på sidenummeret og dato-tid, er sidenummeret det samme som den forrige side, ”smid den gamle side ud”.
Ved udskrift blev der valgt en font (karaktersæt) for hvert enkelt felt på siden, således at analysenavnet kunne skrives korrekt (ikke kun som forkortelse). Bemærkninger/markeringer til fodnoter i resultatfeltet kunne indskrives osv.
Kumulerede udskrifter indebar, at udskriftsmængden, målt som antal svar næsten 10-dobledes. I Arbejdsregistret krævede det kun få opslag for at hente de relevante data, ligeledes i netværksdatabasen IMAGE II, idet data kunne nedlægges i databasen sorteret efter prøvedatoen. Det indebar, at når data blev hentet fra databasen fik man automatisk kun de data, som skulle bruges og i den ønskede rækkefølge (kæde), de yngste data først. De relative få antal diskopslag medførte, at Labka kunne udskrive med høj hastighed, således trække flere laserprintere i parallel og rutine kumulerede svar kunne komme ud til de kliniske afdelinger inden ”aftenstuegang”. Med indførelsen af LSP kunne svar skrives ud på de kliniske afdelingers laserprintere.
Labka Sygehus-Pakken (LSP) 1997
Med LSP fik de kliniske afdelinger på sygehusene direkte adgang til Labka. Herunder: rekvirering, søgning, udskrift af PTB’er og udskrift af kumulerede svar samt flere hjælpefunktioner. LSP kørte under Windows, pc’erne kommunikerede med en Labka Sygehus-controller , som igen kommunikerede med HP 1000 Labka-systemet.
Labka Sygehus-Pakken og dens funktionalitet er set fra de kliniske afdelingers side beskrevet i demo-video sekvenser (via en playliste på YouTube).
Kort om LSP
Rekvirering: Til understøttelse af rekvirering kunne brugeren oprette/ anvende profiler, som passede til afdelingens arbejdsgange. Således kunne en bruger fx rekvirere levertal (5 enkelt analyser) eller en glukosebelastning (5 enkelte prøvetagninger/analyseringer) med et enkelt klik. Den enkelte kliniske afdeling kunne også have sin egen analyseliste, ud over den generelle analyseliste.
Brugere kunne således rekvirere adskillige analyser med få klik i løbet af få sekunder.
Udskrift af prøvetagningsblanketter (PTB’er) foretoges i overvejende grad på KBA eller i ambulatoriet, men kunne også via LSP udskrives på den kliniske afdeling, fx til haste-prøvetagning.
Brugerne kunne endvidere se hvorledes ”prøvetagning /analyseringen” skred frem, fx om PTB var udskrevet (prøveprocessen var sat igang), om prøven var ankommet til laboratoriet (men analysering endnu ikke var foretaget), og endeligt at resultatet forelå. Hermed kunne brugerne gribe ind i processen, fx anmode om en ekstra prøvetagning eller analyse på prøven i tilfælde af at patientens tilstand var ændret, eller at patienten netop var ankommet til afdelingen. Hermed opnåedes en fleksibel ”integration” med laboratoriet, også uden for den ”normale” arbejdstid.
Søgning:
Ved søgning fik brugeren i løbet af få sekunder adgang til samtlige patientens analysedata, uanset på hvilket laboratorium i amtet analyseringen var foretaget. Søgning kunne foretages enten Rekvisitionsorienteret eller kumuleret. Brugeren/ lægen kunne ikke kvitterere for at have set analyseresultatet. Udskrift kunne foretages. Hvis en rekvisition eller resultat var rettet, fremgik det af de viste informationer.
Labka Sygehus-Pakken blev installeret på de fleste ”Labka installationer” i løbet af relativ kort tid, hvilket bidrog til god økonomi i CSC Datalab A/S i 1997-99.
De ”bagved liggende IT-tekniske” årsager, nok så vigtige
HP 1000 var en 16 bit ords minidatamat, tilhørende en ”mindre klasse ” af maskiner” end fx IBM 1800 eller VAX (32 bit ords) maskine, som blev benyttet på andre ”tilsvarende større” systemer fra 1979...
På basis af HP 1000 systemet blev det, ved forskellige "tilgange", trods ”størrelsen” muligt at udvikle/ videreudvikle og understøtte systemer som Labka og LSP.
Labka applikationsprogrammelet blev løbende videreudviklet inden for områder som:
- Omkobling til nyt analyseapparatur og behandling af data fra disse
- Udbygning af tabelsystemer
- Gennemgang af ældre rutiner og modifikation og forbedring af disse
- Procedurer til versionsstyring og online-opdatering af installationer på de enkelte sygehuse
- Omlægning og udvidelse af databaser
- EDI og produktions udvekslingssystemer
- Automatisk generering af skærmbilleder/ analyse indrapportering/ beregningsprogrammer/ ”Rucat”.
- Fakturerings- og postsystemer osv. osv.
Til vedligeholdelse og udvikling blev der endvidere udviklet adskillige utility programmoduler, ligesom HP 1000 bruger-klub programmer blev benyttet.
Fem delsystemer kan fremhæves, Multi-lab, Grundsystemet (1979..), Online kommunikation/integration med analysemaskiner, HP1000 hardware operativsystem og database samt LSP opbygning/ konstruktion.
Multilab
I mange amter var der flere større eller mindre sygehuse og disse var undertiden under samme øvre ledelse eller samarbejdede, især om ”special-analyser”, som kun visse sygehuse udførte. Ud fra et styrings/ ledelsesmæssigt, driftsmæssigt og økonomisk synspunkt var det ofte ikke hensigtsmæssigt at installere et selvstændigt HP 1000 system på alle sygehuse, men i stedet koble KBA på HP 1000 installationen på et større sygehus.
Fx understøttede HP1000-Labka systemet i Vejle via online forbindelse Give Sygehus og Sct. Maria Hospital, HP1000-Labka systemet i Horsens tilsvarende Brædstrup Sygehus, medens Kolding og Fredericia Sygehus hver havde deres eget HP1000-Labka system. Alle systemerne i amtet var ”forbundet produktionsmæssigt” via Labka- Udvekslingssystemet.
Disse relativt komplicerede systemer blev styret via tabeller og produktions/ Udvekslingssystemet, som automatisk overførte rekvisitions og svarinformationer mellem systemerne i amtet.
Tabellerne var opdelt i et mindre antal ”centrale” tabeller, som blev opdateret af Labka-personalet og grupper af mindre tabeller (ca. 400), som via skærmbilleder også kunne opdateres af Labka-superbrugere på KBA.
Multilab var således ikke et enkelt modul, men var funktioner indbygget i en stor del af Labka- programmellet. Det fungerede programmæssigt ved at programmerne via konfigurationsparametre fik nye eller modificerede funktioner, bl.a. afhængig af hvor systemet var placeret. Multilab var også udover tabelsystemerne i praksis afhængigt af en opdateret bruger-dokumentation og uddanelse af Labka-superbrugere.
”IT-teknisk” blev systemet udformet således at de enkelte programmer ved indlæsning af tabeller ved opstart, ikke foretog belastende disk-læsninger, men udnyttede RTE-A’s program-program kommunikations feature.
Grundsystemet - basiskonstruktionen
Konstruktionen i 1978 var præget af den begrænsede CPU kapacitet, den "lille disk” samt især den begrænsede størrelse af det enkelte program, især dataområdets plads til variable. Hastigheden var dog i begyndelsen ikke et problem, grundet den relative lille produktion på ML.
HP RTE III og senere RTE-A gav gode muligheder for at opbygge et modul baseret realtids system med fleksibel program til program kommunikation og med en speciel filstruktur ”Arbejdsregistret”, baseret på RTE IV/ RTE-A’s filsystem.
Arbejdsregistrets fordele var, at de processer som var at de hyppigst anvendte, fx lagring af dagens analyseresultater, kun brugte få fysiske diskopslag, ligeledes for læsning af de hyppigst anvendte data. . Det lokalt designede register havde redundante informationer indbygget i index /rekvisitions / svar - records til løbende sikring af pointervaliditet.
Arbejdsregistrets ulemper var den begrænsede størrelse: 15.000 rekvisitioner og 100.000 analysesvar, samt at det krævede en daglig/natlig oprydning/sortering, med lukket system.
”Bag Arbejdsregistret lå” netværksdatabasen HP IMAGE II.
IMAGE II's fordele var størrelsen, 3 mio. rekvisitioner og 21 mio. analysesvar, samt at det kun krævede relativt ’’få fysiske diskopslag’’ at hente data, under forudsætning af at man tilgik data via én ”bestemt” søgenøgle (personnummeret) ”koblet” med én sorterings søgenøgle (prøvedato). Endvidere at databasen ikke krævede megen hukommelsesplads (memory), hvilket der ikke var til rådighed. Databasen var konfigureret med adskillige søgenøgler, som kunne anvendes til forskellige andre former for udtræk af data, fx fødselsdato eller analysenavn.
IMAGE II's ulemper var at lagring af data og sletning af data krævede mange fysiske diskopslag, nærmest proportionalt med antallet af søgenøgler.
De to registeregenskaber blev udnyttet på den måde, at de hyppigste/seneste tilkomne data var i Arbejdsregistret. Når data ikke længere var så ”aktuelle” (fx at alle svar var indgået til rekvisitionen), blev disse data, som en baggrunds/natkørsel (med åbent system), overført fra Arbejdsregistret til databasen.
Konstruktionen indebar fx, at når der blev søgt eller der skulle skrives kumulerede svar ud, blev data hentet fra begge registre.
Når data i databasen skulle rettes, blev rekvisitionen med samhørende svarinformationer udtaget af databasen og overført til Arbejdsregistret, hvor de mere komplicerede retteprocedurer blev aktiveret. Data blev senere tilbageført til databasen ved de rutinemæssige baggrunds/natkørsler.
IMAGE II – Labka databasens størrelse og struktur/ betydning
Omkring 1996-97 var flere IMAGE II-Labka databaser blev udvidet til 7 millioner analysesvar og i 1999 blev databaserne på de større systemer fx i Aalborg og Aarhus (Nyt om Labka nr. 10 og 11) udvidet til 21 mill. analysesvar.
I HP 1000 fil-disk systemet var der en begrænsning på den logiske diskstørrelse og dermed på databasens størrelse. For at få en database større end begrænsningen på 7 mill. analysesvar, blev data delt i 3 ”ens” databaser, liggende på hver sin logiske disk. Opsplitning af data foregik ved, i en algoritme at opdele personnummeret i 3 tilhørende intervaller ved opdatering/læsning. Udadtil fungerede databasen som én database.
I forbindelse med udvidelsen blev gamle data, fra DAT–tape, overført til den nu nye større 21 mill. analysesvars database. I Aarhus svarede dette til ca. 7 års produktion (Billedet ”Labka produktion på de enkelte sygehuse”).
Struktur
IMAGE II- Labka Databasens struktur (for rekvisitioner og svar) fremgår af Labka database ”Design” billedet, svarende til ” Labka Database Status” skærmbilledet (et eksempel, fra en mindre Labka, tom test database).
Af billederne fremgår at der fandtes i alt 8 (automatisk opdaterede) Hash-indexfiler, Type(A) ”søgenøgler”.
Databasens ”egentlige data” lå i 2 (3) datafiler Type (D). I disse var data/records med samme nøgle-item (type) med samme værdi ”trådet” sammen. Fx var (jævnfør Design billedet) alle Rekvistionsrecords i REKVIF, (og alle svarrecords i RESULF) med samme personnummer (via DPERSN) trådet sammen.
Bemærk endvidere, at Rekvisitionerne i REKVIF blev lagret sorteret i prøve-dato-orden, (”indeni” den pågældende ”link-samme-værdi-kæde”.) Sort item DKUMDI.
Således fik man ved søgning via Hash- indexet DPERSN, direkte adgang til den yngste Rekvisition i den ”sorterede tråd”, og dernæst til den næstyngste osv. Ligeledes var alle svarrecords i RESULF (og alle rekvisitionsrecords i REKVIF) med samme Glasnummer (DATGLA, sammensat inddateringsdagnummer-Glasnummer) ” trådet” sammen.
Af Design billedet ses endvidere, at der er henholdsvis 6 og 4 forskellige ”typer” af tråde i REKVIF og RESULF. De mange records i de forskellige tråde indebar, at databasen krævede mange ”Read/Write’s” ved opdatering/ sletning i databasen; men et minimum af opslag, især fysiske diskopslag, ved søgning og acces til rekvisitioner via personnummer og tilhørende svar via glasnummer.
Udover disse filer fandtes (ikke vist) en rod/status-fil, samt en ”Before-image-file”. Sidstnævnte fil blev benyttet ved hver ”update-transaction” til sikring mod uhensigtsmæssige afbrydelsers indflydelse.
Betydning
Udvidelsen af databaserne indebar, at patientdata kunne fremfindes langt tilbage i tiden, både på Labka og senere via LSP. Særlig vigtigt var det for en ”sammenhængende/kontinuert” udskrift af det kumulerede svar for patienter, som kun fik udført analyser med meget lange mellemrum (måneder/år). Endvidere gav udvidelsen af databaserne grundlag for (senere) videnskabelige undersøgelser.
Online kommunikation/integration med analysemaskiner
Skete via multipleksere HP12040D (med FIFO og DMA), seriel kommunikation, via DDL(aktive) Muxpaneler som understøttede/ transmission til lokale enheder via RS232C, HP skærmterminaler via RS423 og analyseinstrumenter via RS422, som tæt ved instrumentet var tilsluttet en ”Optoisoleret RS422-RS232C konverter”, således at analyseinstrumenterne var galvanisk isoleret fra HP 1000 systemet.
Til hver enkelt analysemaskine, hvoraf der typisk var ca. 5 til 12 maskiner per laboratorium, var der tilknyttet en ”Result Raw file”, hvor dagens resultater fra analysemaskinen blev lagret sekventielt. Til hver enkelt analysemaskine var der udviklet/tilpasset en
”Driver”. Driveren, et memory resident højprioriteret program med tilhørende tabel, kunne udover kommunikation med analysemaskinen foretage en simpel beregning, kontrol og lagring af resultatinformationer i Result Raw filen. Endvidere fx ved modtagelse af forespørgsler fra analysemaskinen, indeholdende prøveidentifikation (glasnummer), overføre rekvisitionsdata fra Arbejdsregistret til analysemaskinen.
Til hver Result Raw file var tilknyttet et skærmprogram, tilpasset arbejdsproceduren, fra hvilken laboranten kunne overse samtlige opsamlede resultater, status, blokke og aktivere en kvalitetskontrol og godkendelse/ overførsel af resultaterne mm. Kvittering/status for overførslen til Arbejdsregistret blev indskrevet ved resultatet i Result Raw filen og vist på skærmterminalen. En Laborant arbejdede typisk med blokke, hvor en blok kunne bestå af adskillige resultater mellem et sæt kontroller eller blok-markører. Resultater kunne også godkendes uden laborant indgriben, men funktioner status/tilbagemeldinger mm. var de samme.
Til et glasnummer var der i middel ca. 7 resultater. Den blokvise overførsel indebar, at antallet af fysiske disk accesser ved overførslen blev væsentligt reduceret, da resultatrekords for samme glasnummer i Arbejdsregisteret også lå fysisk samlet på disken.
Raw Result filerne var jævnfør ovenstående adskilt fra det egentlige Arbejdsregister. Sammenkobling mellem de to register systemer, varetoges af de pågældende drivere og de tilhørende skærmprogrammer. Adskillelsen var hensigtsmæssig, da der jævnligt kom nye analysemaskiner til. Realtidsfunktionen (i RTE-A) var vigtig, da nogle analysemaskiner krævede en kort svartid, endvidere var det vigtigt, at procestiden for den enkelte driver var kort og ikke var væsentlig afhængig af andre processor eller ”tids-låse” i systemet.
Hardware, operativsystemet og databasen
HP 1000 og RTE-A var konstrueret til industristyring og havde mange muligheder for forskellige prioriteringer, låsning og program til program kommunikation mm. Dokumentationen fyldet mere end 20 ringbind. Udvikling på HP 1000 krævede, grundet de mange muligheder, teknisk ”IT/ ingeniør” indsigt.
HP 1000 hardware blev løbende opdateret: Allerede det første system til AAS fik i 1984 en HP 1000 A600, som var dobbelt så hurtig som ML’s første HP 1000. I 1991 kom HP 1000 A990, som var 6 gange hurtigere end A600, samt havde mikrokode til hyppigt anvendte Fortran rutiner, samt floating point hardware. A990 kunne udføre 15 millioner instruktioner per sekund og 1.1 millioner Floating point operationer per sekund. Hukommelsen var dog stadig begrænset til max 32 MB.
Der kom også nye større og væsentligt hurtige diske (pladelagre), ca. 8 gange hurtige end ML’s første disk, samt nye båndstationer (DAT) til backup. Endvidere nyt fermware til multipleksere, som lettede dataopsamling og kommunikationsmulighederne.
Operativsystemet RTE-A blev væsentligt udvidet og forbedret. Programmeringssproget var Fortran 77.
Ændringerne i operativsystem medførte fx, at man kunne etablere 112 indgange 14 multipleksere med hver 8 indgange (12040D) til brug for skærmterminaler, printere, omr-læsere og analysemaskiner.
Væsentligt var indførelsen af CDS (Code and Data Separation), hvilket medførte at koden ikke, ved en fejl, kunne overskrives, samt at de enkelte programmer (kodedelen) kunne blive væsentligt større. CDS indebar ligeledes at koden ikke ændredes under eksekvering, dvs. at et program kunne aktiveres i flere instanser, (fx ”køre” fra mange skærmterminaler samtidig), kodedelen kunne deles og tog kun plads op i memory én gang, ligesom ”kopier” af programmet ikke skulle hentes fra disk når programmet blev startet op. Endvidere blev det muligt i Labka at indbygge avanceret fejlrapportering. Fx, gik et program ”ned”, var det muligt på en fejludskrift, indeholdende den relevante Fortran kildekode, at spore kæden af kald fra hovedmodul gennem samtlige underrutiner, også på systemerne i rutinedrift, hvilket gav betydeligt nemmere og hurtigere fejlfinding og medførte et mere pålideligt system.
Databasen IMAGE II fik kun få opdateringer.
Efter 1991 kom der ingen ny HP 1000 (CPU) og forbedringer af hardware og operativsystemet var meget begrænset efter år 2000.
Når en mindre minidatamat som HP1000 kunne håndtere mange skærmterminaler samtidigt, var en væsentlig årsag, at HP skærmterminalerne kunne fungere i ”side blok mode”, dvs. skærmsiden (kun inddaterings felterne), først blev sendt ved tryk på ”Send”, og ”skærmsiden” blev modtaget/lagret i den tilhørende en multiplekser-kanal og overført til det relevante program via en DMA (Direket Memory Acces) transfer. Hermed blev CPU-systemet ikke belastet (interrupted/ afbrudt) hver gang brugeren brugte tastaturet. Den samme multiplekser feature (FIFO buffer) blev anvendt ved online instrument opkobling og Labka-Labka kummunikation (udvekslings systemet).
Omkring 2002 blev der installeret disk-spejling på Labka-systemerne , også kaldet Datapair eller Raid 1.
Af en beskrivelse på dansk, om ”HP1000-familien”, fremgår det hvorledes udvikling af HP 1000 computer-serien, med tilhørende realtidssystemer, skred frem, samt hvilke applikationsområder HP1000 computer-systemet var særlig velegnet til.
LSP’s opbygning/ konstruktion
LSP bestod hardwaremæssigt af: et I/O parallel interface kort med DMA, HP12006A i HP 1000, en LSP-controller (IBM PS2/OS2) server med 8 bit parallel kommunikationsport til CSC 101, en Labka Highspeed-Interface Controller (CSI 101), som forbandt LSP controlleren med HP parallel interfacen.
HP Parallel interface kortet havde 8 unidirektionelle I/O, dvs. 8 datalinjer for input og 8 andre datalinjer for output, medens PS2 parallel udgangen havde bidirektionelle I/O, dvs. 8 datainput og output skiftevis på de samme datalinjer. CSI 101 håndterede omskiftningen og sørgede for hardware ”handshaking” kontrolsignaler til begge sider.
CSI 101 hardware controlleren blev ligesom Labka og LSP programmel udviklet i Dansk Datalab ApS (senere CSC Datalab A/S).Endvidere en såkaldt bootbox styret af HP 1000, som kunne afbryde 220V forsyningen, dvs. koldstarte serveren. Servicering af LSP-controlleren skete via modem og et ”sikkerhedssystem”.
Softwaren bestod af relativt få programmer, tilføjet til Labka, et stort programkompleks, skrevet i C og afviklet på LSP controlleren, en stor Windows klient, skrevet i C++, lagret/hentet fra en program-server og afviklet på klienten.
Et robust ”IT pakke-transmissionssystem” blev udviklet til kommunikation med alle sygehusets Windows-klinter samt til LSP-controller- HP1000 forbindelsen.
Et eksempel på en LSP-funktion; Ved søgning på Vejle Sygehus, udløstes parallelle/simultane søgninger på LSP controllerne i Kolding, Horsens og Fredericia. Data blev samlet, dubletter, stammende fra Udvekslingssystemet, fjernet, data ”flettet” og data sendt til klienten og resultatet præsenteret for klinikeren på klienten på Vejle Sygehus.
LSP controlleren blev senere også anvendt til EDI-transmission, og en realtids opdateret DB2 ”parallel/spejl-database” blev ligeledes oprettet på LSP controlleren, dels til aflastning for Labka dels til brug for udtræk til videnskabelige undersøgelser. Senere blev der udtrukket til andre databaser, således blev mere end 300 millioner analysesvar flyttet fra paralleldatabaserne i de tidligere Frederiksborg og Nordjyllands amter til Laboratoriesvar Portalen.
Det modulære koncept
3 årsager til det modulære design af Labka systemet.
m1: Programmernes størrelse, variabel området og i begyndelsen også området for kode og biblioteksrutiner mm., var begrænset til mindre end 32K 16 bit ord.
m2: HP RTE III/ RTE IV og RTE-A var velegnet til opbygning af et modulært system idet, de ”selvstændige” Programmer (Fx et Program, som kun kunne hente eller lagre en rekvisition med tilhørende svar-records), kunne ”stoppe” og gå
” Dormant, Save Resources”. Fx når Programmet startede op/ blev scheduleret, kunne det modtage data og processe (fx låse sig i memory og åbne relevante filer), og dernæst gå i stå/ suspende sig selv, men bibeholde sine data og status.
Ved følgende schedulering igen af et andet program, modtage data fra dette, udføre ”sine funktioner” (uden denne gang først at åbne filer mm.), returnere data til det kaldende program og suspende sig selv igen. Blive scheduleret igen, nu af næste program,som kunne stå i kø osv.
Antallet af samtidige aktive programmer kunne i RTE- A være op til 183.
m3: Opdeling af koden i hensigtsmæssigt funktionelle, adskilte, mindre moduler gjorde systemet nemmere at udvikle, videreudvikle og understøtte. Manglende plads i programmer til variable var dog undertiden en væsentlig ulempe.
Hvad kendetegnede et IT-KBA system belastningsmæssigt / design / konstruktion
Et KBA IT-system var belastningsmæssigt kendetegnet ved, at man fra ”mange sider samtidig”, i relativt korte perioder hentede eller indrapporterede ”mange” svar, (i mere end ca. 90 % af tilfældene), til det samme lille register, indeholdende dags-produktionen. Se ”Belastning: Labmeter udskriften fra HP 1000”.
Labka Arbejds-registret var designet/ optimeret til dette formål. Fx med et lille indeks-register, indeholdende både Personnummer, Glasnummer og Pointer til rekvisitionen, 3.400 rekords, (kun 850 records i begyndelsen, se Billedet ML-filesystem) komprimeret så hver rekord kun fyldte 12 byte i alt 20.400 16 bit ord, og kunne således lagres i én sammenhængende fil, og derfor læses i op i kun eet diskopslag.
Således kunne der ved personnummer søgning eller indrapportering af 50 svar (fx fra et online modul) finde alle pointerne til rekvisitionerne via eet diskopslag. I rekvisitionsrekorden var der en pointer til alle de tilhørende svar-rekords, som lå fysisk samlet på disken, og således at de alle til rekvisitions-rekorden hørende svar-rekords, igen kunne tilgås via eet (read/write) fysisk diskopslag.
Responsetiden for det samlede system kan ”opleves” ved at klikke på Labka Sygehus-Pakken nr. 3 LSP Søgning, sidste del kumuleret søgning. Demoen er optaget på et ”levende” system, og indeholder således også proces-tiden for kommunikation, via Labka Highspeed-Interface Controller, og proces i LSP-controler og klient.
Drift /fejl /drift understøttelse og vedligeholdelsesaftaler
Hardware, operativsystemet, applikationsprogrammellet var i daglig rutine-drift særdeles pålidelig. Dette var særlig vigtigt, for selv ”små” fejl kunne få fatale konsekvenser, og systemet skulle køre alle dage døgnet rundt.
KBA havde i deres supportaftaler (UTS, Update og Tilkalde Service), kun krav på support inden for almindelig arbejdstid (7:00 til16:00). Men support blev ydet, uden beregning, alle dage hele døgnet rundt, per telefon og via modem.
Om kontakt mellem Labkas og sygehusenes personale
Kontakten til brugerne blev højt prioriteret. To af personalet havde udover IT-uddannelsen en mangeårig erfaring som hospitalslaboranter, det lettede brugerkontakten, ligesom de øvrige IT-personer fik en bedre forståelse af Labka-systemets funktioner/ ”forretnings-logikken”. Kunder havde ofte direkte kontakt med den medarbejder, som havde udviklet det aktuelle IT modul, som skulle tilrettes eller fejlede. Labka (super)bruger dokumentation, 5 ringbind blev opdateret ved hver opdatering af Labka. Ca. hvert andet år afholdtes et brugermøde, med middag/overnatning, undertiden underholdning mm. forskellige steder i Danmark, oftest med op mod 150 deltagere.
Et skrift: Nyt om Labka blev med mellemrum udsendt til KBA på de forskellige sygehuse.
Interface med Kommunedatas Grønne System (GS)
GS hospitals informations system, som var installeret i flere Amter.
Omkring 1989 var det ved levering til Vejle Amt, 1990 Roskilde Amt og senere Amager Hospital en betingelse, at Labka kunne opkobles til GS, således at ”færdige” rekvisitionsinformationer og analysesvar kunne overføres. Dette skulle ske efter en såkaldt IBM LU 6.2 ”protokol”, hvilket ikke var muligt på HP 1000. Opgaven blev løst ved at købe et specielt ” LU6.2 emuleringkort” i USA, som kunne installeres i en IBM PC (under DOS), yderligere tilkoble en IBM pc under OS2 og lade programmer på de 2 pc’er kommunikere mod IBM mainframe ”som LU6.2” mod HP 1000 serielt. Løsningen blev kun anvendt i Roskilde Amt og på Amager Hospital.
Om disk (pladelager) fejl, rettidig omhu, IT-Guden
Med hensyn til stabilitet, for stort set ethvert mindre IT-system i perioden 1979 til omkring år 2000 var akilleshælen, udover alvorlige fejl i programmel, diskfejl/ disk crash.
En elektronik fejl på HP 1000A serien kunne repareres på få minutter ved at skifte et kort i CPU kabinettet, selv power supply kunne udskiftes på minutter. Men alvorlige diskfejl kunne medføre tab af store vigtige datamængder. Der foretoges tape-backup hver nat på Labka systemerne, men de data, som kom ind samme dag før backup, ville være tabt ved en alvorlig diskfejl. Endvidere kunne en større ” restore af backup” fra tape tage op mod 7 timer, så næste dags produktion ville rammes. Værst var det, at der var risiko for at ”backup-data” ikke stemte overens med andre data. Disk crash var frygtet blandt Labka IT-folk. Hertil kom at de nye billigere SCSI diske (pc-diske) ikke var så pålidelige som de ”gamle" såkaldte HB-IB diske.
Når en disk begyndte ”at gå ned”, var det stort set altid med intermitterende fejl. Disse blev rapporteret på HP1000 konsollen,og laboratoriepersonalet rapporterede omgående fejlen til Datalab. Det var derfor som regel muligt for Labka-personalet, uden ophold, via modem-forbindelse, at flytte data, helst til et andet område på disken, om muligt til en anden disk (disk-drive). Blev fejlen hyppigere/alvorligere, da uden ophold, som regel af Datalab selv, at ”redde data” og udskifte disk-driven, oftest som natarbejde.
Med indførelse af diskspejling (HP Data-Pair/1000) på Labka-systemerne omkring år 2002, elimineredes ”problemet”. Derefter var der ingen, selv midlertidige stop, grundet diskfejl.
Ovennævnte metode indebar, at ingen data gik tabt på de 21 HP1000 anlæg i 33 år. ”Rettidig omhu” eller holdt IT-Guden hånden under Labka?
Om Labkas udfasning
Produktionen på KBA steg mere end 5% per år. Omkring 2008 var Labkas svartider på de store KBA’er undertiden lovlig lang, selvom systemet fungerede. LSP havde fortsat korte svartider, men HP 1000 havde under belastning ”CPU-mæssigt” svært ved at ”følge” med. Der var ikke kommet CPU-forbedringer siden HP 1000 A990 i 1991. Endvidere havde HP opsagt vedligeholdelsen fra 1. november 2005. HP 1000 hardware og RTE-A support blev efter 2004 varetaget af CSC og via JUC Consulting. Supporten kørte uden problemer til det sidste Labka-system stoppede i november 2011. Labka II havde da længe været igang.
Fakta box
Antal personer i Labka-gruppen: 1986: 3 ½, 1990: 5 ½, 1996: 14
Hardware
- Antal understøttede sygehuse: 50
- Antal HP 1000 maskiner/installationer: 21
- Max hukommelse i HP 1000: 32 MB
- Max antal indgange (RS 232, 423, 422) i en HP 1000: 112
- Max plads på ét disk drive (ca. år 2005) 18 GB
- Labka Sygehus-Pakke (LSP) controller: IBM PS2 server med 8 bit parallelport, interface mod CSI 101.
- Interface enhed mellem HP 1000 og LSP IBM server: Dansk Datalab ApS- CSI 101, hardware controller.
Systemprogrammel
- HP (RTE III), RTE-A Realtids operativsystemer
- HP F1000, HP skærmbilled "programpakke"
- IMAGE II, HP 1000 netværksdatabase
- På IBM ”Server” LSP-controller, OS/2 og DB/2
Labka programmel
Antal:
- Max samtidige programmer afviklet på HP 1000 / RTE-A: 183
- Labka programmer: 726
- Labka utility (hjælpe) programmer: 161
- Labka Fortran rutiner: 6.700
- Labka Fortran utility (hjælpe) rutiner: 420
- Labka HP 1000 assembler rutiner: 43
- Labka skærmbilleder (F1000): 345
- Utility (hjælpe) rutiner : 298
Labka LSP software: Ikke optalt
Produktion og brugere
- Samlet analyse produktion 1/2-2004 til 1/2-2005: 48.406.027
- Antal LSP brugere i 2006: 37.683
- Antal LSP klienter (pc-er) i 2006: 14.815
- Aalborg Syd HP 1000/A990 Installationen (det største system i 1998), understøttede også sygehusene i Aalborg Nord, Brovst og Farsø.
- HP 1000 systemet havde;
- 32 MB memory, 3 disk controllere, 7 disk drives i alt ca. 11 GB,
- 112 asynkrone indgange, 64 skærme, 10 printere, 7 OMR læsere og 20 analyseinstrumenter.
- Antal analyser/"produktion" 3,5 millioner/år, og 7,3 millioner analyseresultater i databasen.
- Svartid målt via belastnings-test 21/4-98, (med henblik på en fremtidig implementering af LSP) for inddatering af: en rekvisition (7:30-16:30), med ekstra simuleret "fremtidig" belastning,
- svarende til et "kommende" LSP., tilføjet "oven i normal" rutinedrift (på 2.187 rekvisitioner og 19.040 svar i døgnet), 91% < 1,4 sek., 95 % < 1,7 sek.
- Antal analyser/”produktion” (2005) 6 millioner/år, og 21 millioner analyseresultater i databasen.
Nyt om Labka fra 1992 til 1999
Nyt om Labka skrifterne belyser Labka-udviklingen gennem 8 år, herunder sammenhænge mellem applikation-, hardware-, operativsystem-, program-udvikling, samt personale resurser.
I 1992 var 20 laboratorier understøttet af Labka, med en samlet produktion på 12 mio analyser årligt.
”Labka personalet” blev primo 1992 udvidet fra 5 til 7 personer, og skriftet Nyt om Labka blev påbegyndt. Frem til september 1999 blev der med mellemrum sendt et Nyt om Labka til Laboratorie-ledelserne, Labka-superbrugerne og IT- afdelingerne, i alt op til 125 modtagere.
Skriftet var på 1 til 4 sider, i alt 11 årgange, jævnfør billederne af Nyt om Labka (for at læse, klik én gang og dernæst én gang til på billedet). En svensk version af Nyt om Labka blev ligeledes udsendt.
Nyt om Labka omhandlede hvilke ny brugere/sygehuse, der havde bestilt eller havde fået et Labka- eller LSP- system. Hvilke nye applikationer og features Labka var blevet udvidet med, herunder hvilke nye instrument online moduler, der var udviklet. Frem til 1999 var der udviklet ca. 90 forskellige instrument-online moduler.
Endvidere hvor og hvornår nyt hardware og /eller operativsystem skulle installeres, og ikke mindst hvor og hvornår den næste såkaldte Standard Update kunne finde eller havde fundet sted.
Andre forhold som udvidelser af databaserne, Labka-systemernes kommunikation med omverdenen, nyt personale og hvad de forskellige udviklere i hovedsagen var beskæftiget med mm., blev ligeledes omtalt.
Ny udviklede applikationer eller større ændringer krævede undertiden en Standard Update, medens mindre forbedringer, udvidelser af hardware eller nye instrumenter online-moduler kunne foretages uden en Standard Update. Ved en Standard Update udskiftedes næsten alt Labka software. Den nye Labka kildetekst blev lagret på sygehus-laboratoriets HP 1000 system.
Standard Update, som var forberedt/gennemarbejdet ”hjemmefra”, var med hensyn til betaling, indeholdt i support aftalerne, medens selve installations-arbejdet på sygehusets HP 1000, som normalt varede et døgn, med et skift om natten, og undertiden en ekstra dag og rejseudgifter, betaltes separat. Operativsystem opdateringsarbejdet på stedet (på HP1000), herunder fx installation af disk-spejling mm. blev ligeledes konteret separat.
Mange forbedringer var indeholdt i support aftalen, medens store ændringer/ tilføjelser, som fx LSP, faktura-modulet, samt nye online-instrument moduler betaltes separat.
