Labka

Fra DDHFwiki
Spring til navigationSpring til søgning

J. Uffe Christiansen (diskussion) 14. feb 2018, 14:04 (CET)


Labka

47 sygehuse i Danmark og 3 i Sverige
Labka produktion på de enkelte sygehuse, mindre sygehuse indgår i det større sygehus de er online forbundet til
Antal Labka Sygehus-Pakke brugere på de enkelte sygehuse, mindre sygehuse indgår i det større sygehus de er online forbundet til

Labka er navnet på et IT-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 2012to 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 HP1000.

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.


Indholdsfortegnelse

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.

OMR Læser. "Læse-fejl" fik blanketten til at køre baglæns,og fejlinformationen vistes på den lille "OMR status-skærm"
Rekvirering via LSP billede 1 af 2, "basis" oplysninger.
Labka OMR rekvistions-blanket (forsiden), med OMR-clock og kontrol-mærker for detektion af "skæv indlæsning"
Rekvirering via LSP billede 2 af 2, valg af analyser.
Labka OMR rekvistions-blanket side 2 (kopisiden), med prøverørs-etiketter med glasnummer-barkoder
Prøvetagningsblanketter LSP PTB’er. Til højre i billedet ses barkodeetiketter til mærkning af prøveglas. Personnummeret er et tilfældigt nummer
LSP søgning.
Kumuleret svarsudskrift fra 2001, som også kunne udskrives på den kliniske afdeling via LSP.


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.

Eksempel: På Labka i Aalborg (HP1000 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”.


Prøvefordeling

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.


Analysering

Maskinerne/apparaterne foretog 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

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.

Labka Mangel/Arbejdsliste skærmbillede

Å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).


Belastning
Belastning: Labmeter udskrift fra HP1000/Aalborg Sygehus:Antal inddaterede Rekvisitioner og "indlæste" Svar (dvs. online-opsamlet, godkendt, lagret til udskrift) per 1/2 time
Laboratoriets svartid: Expd. kode Haste(U) 89% under 60 min. Kode Rutine(R) 80% under 210 min.
HP1000/Labka svartid med ekstra LSP 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. NPU nummeret kunne på ”entydig vis” knyttes til 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.

Fx ligger der historiske svar fra patienter i Nordjyllands Amt, som kan fremsøges via personnummer tilbage til januar 1992.


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.

HP 1000 HP21MX installationen på Mikrolab


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.

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 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

De to mest i øjnefaldende årsager til Labka’s udbredelse og den lange levetid

De to mest i øjnefaldende årsager til Labka’s udbredelse og den lange levetid, var det kumulerede rapporteringssystem og Labka Sygehus-Pakken, første gang installeret i Århus Amt i 1998.

Kumuleret svarsudsrift fra 1988.


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. 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.

Labka Brugervejledninger

Disse relativt komplicerede systemer blev styret via tabeller og produktions/ Udvekslingssystemet.

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.

Labka's Arbejdsregister, det første: størrelsen på registret er som på ML. "DAY og MONTH - FILES" indeholdte hver en Index, Rekvisitions og en Resultat fil.

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.

Labka database "Design"
Labka DDL Muxpanel
Eks.på menu for behandling af online opsamlede analyseresultater i ”Result Raw file”
HP 1000 RTE A Manualer

”Bag Arbejdsregistret lå” netværksdatabasen HP IMAGE II.

IMAGE II's fordele var størrelsen, 3 mio. rekvisitioner og 20 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.

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 flotingpoint hardware. 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. Endvidere blev det muligt i Labka at indbygge avanceret fejlrapportering. Fx, gik et program ”ned”, var det muligt på en fejludskrift at spore kæden af kald fra hovedmodul gennem samtlige underrutiner, 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 og forbedringer af hardware og operativsystemet var meget begrænset efter år 2000.

Labka Skærmbillede menu, kom frem efter indlogning

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 HP1000 computer-serien, med tilhørende realtidssystemer, skred frem, samt hvilke applikationsområder HP1000 computer-systemet var særlig velegnet til.

LSP’s opbygning/ konstruktion
Labka LSP opbygning
Labka CSI 101 Highspeed- interface-controller

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.

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.

o: 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.

o: HP 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.

o: 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 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.

Nyt om Labka fra 1992
Nyt om Labka fra 1999 side 1 af 4
Labka's 23 års fødselsdag på Århus Amtssygehus. Til højre IBM/LSP-controller, Error-printer og Log printer, til venstre HP 1000 og CSI 101


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: 300
Labka HP 1000 assembler rutiner: 43
Labka skærmbilleder (F1000): 630

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.