Bruger:J. Uffe Christiansen/Labka
J. Uffe Christiansen (diskussion) 14. feb 2018, 14:04 (CET)
Denne blok skal kun være på min brugerside
Nu må artiklen gerne "rigtig offentliggøres", (jeg har formentlig ikke mange rettelser mere.)
Denne brugerside skulle, efter hjælp udefra, fungerer som MIN Sandkasse, så jeg kan "offentliggøre", dvs. GEMME , (jeg har ca. 13 sider og 17 billeder, link mm) og vende tilbage, og så først rigtig offentliggøre, når jeg er rimelig færdig ( det er vanskeligt at gøre alt i en "proces").
.
Kommentar til tilladelse til fremvisning af billeder på Wiki:
Billederne har jeg selv taget, også skærmbillederne; indholdet på billederne har jeg fået skriftlig tilladelse til at fremvise på Wiki af DXC, dvs. mail korrespondance med DXC-Technology Peter Hecht/ Marketing & Communication North & Central Europe . den 12. februar 2018.
DXC "tidligere CSC (og del af HP) og (CSC)-Datalab
.
Liste over billeder:
Fil:Labka_reference.jpg, Fil:Labka_produktion.jpg, Fil:LSP_brugere.jpg, FIL:LSP_rek_1.png, FIL_LSP_rek_2.png, LSP_ptb.jpg,
LSP_søg_1.png (der er noget med fejl i HTLM delen "ø"), Fil:Labka_kum_1998.jpg (desværre fejl i navnet burde have været 1988),FIL:Laka_arbejdsregister.jpg (fejl i navnet burde være Labka). (osv flere billeder)
.
Disse 7 billeder vil jeg gerne have fjernet fra Commons, de er næsten lige lagt ind, for begrundelse se nedenstående
LSP_?_rek_2.png fejl?
FIL:LSP_rek_1.png, FIL:Labka_rek_2.png, FIL:LSP_ptb.jpg, FIL:LSP_søg_1.png, FIL:LSP_søg_2.png, Fil:Labka_kum_1998.jpg, Fil:Labka_kum_2001.jpg
.
Jeg har ovenstående 7 billeder, hvor der er et kunstigt personnummer, fødselsdato + initialer (eller kunstigt nr.), så det er ikke rigtige personnumre (og det fremgår også af navnet), men ved nærmere eftertanke, kan det måske alligevel give problemer med registertilsynet/lovgivningen, så for en sikkerheds skyld bør de slettes. Jeg vil lægge billederne ind igen (må navnet være det samme?), men denne gang med overstreget personnummer-felt. Er der nogen som vil hjælpe mig med sletningen?, jeg er nybegynder. Nu var jeg ellers ved at være færdig med artiklen.
Labka
Labka er navnet på et IT-system til sygehus-Laboratorier, Klinisk Biokemiske Afdelinger.
Labka, undertiden benævnt Labka I, blev fra ca. 2007 erstattet af Labka II på nogle sygehuse, og blev i 2009 taget i brug i HS.
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å mere end halvdelen 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).
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”.
Kort om klinisk biokemiske afdelinger (1979-2011) redigér
Den Klinisk BioKemiske Afdeling (KBA), tidligere ofte kaldt den Klinisk Kemiske Afdeling eller Centrallaboratoriet, 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 forskellige analyse ”typer”
En analyse blev ”identificeret” ved: System-komponent-kvantitetsart, enhed. 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) redigér
Groft kan procedurerne opdeles i: Rekvisition, Prøvetagning, Prøvefordeling og præparation, Analysering, Kvalitetskontrol, Lagring, Rapportering og Rettelser.
Rekvirering redigér
Foretoges tidligt på fortrykte papirblanketter, senere via blanketter som kunne læses optisk af Optical Mark Readers (OMR) læsere forbundet til Labka. De fortrykte blanketter havde ”vedhæftet” etiketter til mærkning af prøveglas. Etiketterne var ”fordelt” på blanketten svarende til den type prøveglas og antal prøveglas mm., som skulle anvendes, samt opdeling i de pågældende laboratorier, dvs. også under hensyn til de analysemaskiner, som prøveglassene skulle fordeles til.
Rekvisitioner kunne ligeledes modtages via EDI fra praktiserende læger. Indtastning af rekvisitionsinformationer samt rettelse af samme, kunne ligeledes foretages fra laboratoriets terminaler. Navnet på patienten indtastedes i de første Labka systemer, men Labka ”huskede” navnet til brug ved senere rekvirering. 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 redigér
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 redigér
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 redigér
Maskinerne/apparaterne foretog analysering af prøverne og sendte analyseresultaterne sammen med glasnummeret til Labka online. Analyse resultatinddatering samt rettelser af samme kunne ligeledes foretages fra laboratoriets terminaler.
Kvalitetskontrol redigér
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 redigér
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 redigér
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. (Komplette; dvs. hvor alle de rekvirerede svar på rekvisitionen var indgået).
Restordre, dvs. endnu ikke ”færdige svar”, blev markeret. Svar blev efter 1992 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 redigér
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.
Om begyndelsen redigér
”Labka’s” opstart/ drift på Rigshospitalet 1979-1988 redigér
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 9915, 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
- 1 stk. multiplekser med 16 serielle (RS232) indgange
- 3 stk. HP skærmterminaler, den ene med 2 kassette båndstationer
- 1 konsolterminal 30 ch/ sek.
- 1 stk. HP 2607A linjeprinter (brugt), 200 linier/min.
Realtids operativsystemet : HP RTE IV. 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 redigér
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 redigér
De to mest i øjnefaldende årsager til Labka’s udbredelse og den lange levetid redigér
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.
Det kumulerede rapporteringssystem (1987) redigér
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. Rygterne forlød, at der kunne være op til '''5% fejl'''
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.
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 redigér
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.
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 igen), 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 redigér
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.
Fire delsystemer kan fremhæves, Multi-lab, Grundsystemet (1979..), HP1000 hardware operativsystem og database samt LSP opbygning/ konstruktion.
Multilab redigér
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.
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 redigér
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 IV 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 82.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 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.
Hardware, operativsystemet og databasen redigér
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 16 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 mutipleksere á 8 indgange) til brug for af 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.
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.
Omkring 2002 blev der installeret disk-spejling på Labka-systemerne , også kaldet Datapair eller Raid 1.
LSP’s opbygning/ konstruktion redigér
LSP bestod hardwaremæssigt af: et I/O parallel interface kort med DMA (HP 12006A 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 udtrukket til andre databaser
Drift /fejl /drift understøttelse og vedligeholdelsesaftaler redigér
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 redigér
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) redigér
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 redigér
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 redigér
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 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 redigér
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 IV), 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 klinter (pc-er) i 2006: 14.815
- Max antal analyser/”produktion” på én HP 1000 installation: ca. 6 millioner/år
- (HP 1000 Installationen Ålborg Syd, forbindelse til Ålborg Nord, Brovst og Farsø)
[kategori:sundhedsteknologi]