PUBLICX NOTAT / LPR udtræk til opsamling af behandlingsrelationer AF / Ole Bak Jensen Indhold 1 Indledning... 2 2 LPR behandlingsrelationer... 2 3 Oprettelse og sletning af data... 3 4 Krav... 4 5 Kravsbesvarelse... 4 5.1 Datastruktur (Krav 1)... 4 5.2 Forretningslogik (Krav 2)... 5 5.3 Verifikation af behandlingsrelationer (Krav 4)... 6 5.4 Afvikling af udtræk (Krav 3 + 5)... 6 5.5 Overførsel af data (Krav 6)... 8 6 Løsningens komponenter... 8 7 Projektforløb... 9 7.1 Leverance af testdata... 9 7.2 Fremdrift (Krav 7)... 9 7.3 Tidsplan (Krav 8)... 9 8 Referencer... 9 Version Dato Initialer Beskrivelse 1.0 27-04-2011 jensenob Første version (draft) 2.0 02-05-2011 jensenob Tilrettet i henhold til resultat af møde d. 29/4 3.0 05-05-2011 jensenob Kontaktperson i afsnit 7.2 præciseret, samt tilføjelse af afsnit 7.1 om leverance af testdata. 4.0 01-09-2011 jensenob Længde på SHA1-hash tilrettet, samt opbygning af reference. Præcisering af FTP konti. 01.09.2011 A400.330.4 Released Logica Side 1 af 9
1 Indledning Dette notat indeholder en løsningsbeskrivelse for, hvordan der fra LPR kan udtrækkes behandlingsrelationer i form af en række perioder med forskellige typer af relationer medlem patienter og behandlende enheder. Dataudtræk overføres løbende til NSI, og indgår som en del af datagrundlaget for Behandlingsrelationsservice på NSP. Der henvises til dokumentet [BR-KAT] for yderligere information vedr. anvendelse af data. 2 LPR behandlingsrelationer Der findes i LPR følgende typer data, der kan danne baggrund for en behandlerrelation: Stamafdeling Stamafdelingen for en kontakt angiver, hvilken afdeling en patient er indlagt eller indskrevet på i en periode. Dette udgør således en behandlerrelation. En kontakt kan være indberettet inden den er afsluttet, hvilket betyder at perioden kan være åben, dvs. uden sluttidspunkt. Producerende afdeling For en kontakt kan indberettes et antal procedurer, der er udført i løbet af pågældende kontakt. Blandt de indgående oplysninger er producerende afdeling. Denne er ikke angivet for alle procedurer, men skal angives for operationer. I de tilfælde hvor den producerende afdeling afviger fra stamafdelingen, er der tale om en behandlerrelation, som ikke kendes i forvejen. For procedurer kendes kun proceduretidspunkt, og altså ikke noget sluttidspunkt. Dette tidspunkt vil blive anvendt som relationens starttidspunkt, og kontaktens sluttidspunkt som relationens sluttidspunkt. Udskrevet til sgh/afd Når en kontakt afsluttes, dvs. når patienten udskrives, angives afslutningsmåde. Der er forskellige typer koder, eksempelvis kan patienten være udeblevet, eller kontakten kan være endt med dødsfald. I mange tilfælde afsluttes en kontakt til et andet sygehus, en afdeling på et andet sygehus, eller en anden afdeling på eget sygehus (dvs. kontaktens stamsygehus). I så fald fortsætter behandlingen på pågældende enhed, og på et senere tidspunkt indberetter denne enhed formodentlig sin egen kontakt til LPR. Indtil der indberettes en selvstændig kontakt fra den afdeling, der udskrives til, må det formodes at der eksisterer en behandlerrelation for patienten til pågældende afdeling, gældende fra udskrivningstidspunktet. Det er dog ikke en stærk relation, som de 2 foregående, da det jo ikke er sikkert at kontakten bliver til noget i praksis. Relationen vil derfor skulle verificeres. Henvist fra sgh/afd Når en kontakt startes, dvs. når patienten indlægges/indskrives, angives henvisningsoplysninger. Disse rummer en sygehus/afdelingskode, såfremt patienten er henvist fra en anden afdeling. Det må derfor formodes at der eksisterer en behandlerrelation for patienten til pågældende afdeling, maksimalt gældende indtil henvisningstidspunktet. Samtidig må det dog også formodes, at pågældende afdeling på dette 01.09.2011 A400.330.4 Released Logica Side 2 af 9
tidspunkt har indberettet en selvstændig kontakt, og at denne udgør en stærkere relation end den der kan afgøres ud fra henvisningsafdelingen. Der ses derfor bort fra denne oplysning i LPR. Ydernummer (DUSAS) En særlig type kontakter i LPR er DUSAS speciallæge. Disse findes der ikke ret mange af, men for dem der findes, skal der angives ydernummer i stedet for stamafdeling. Der kan således siges at være en behandlerrelation imellem patienten og pågældende yder/speciallæge fra kontakt start til kontakt slut. Bemærk: Brugerne taster ydernummeret ind i LPR s brugergrænseflade. Værdien lagres, men valideres ikke i LPR. 3 Oprettelse og sletning af data Til LPR kan indberettes kontakter omfattende de data, der er beskrevet i foregående afsnit, men der kan også indberettes sletninger af kontakter. Dette benyttes hvis der har været indberettet forkerte data, eksempelvis hvis indlæggelsestidspunktet skal være et andet. Da indlæggelsestidspunktet indgår i kontaktens nøgleoplysninger, er det nødvendigt at slette den gamle kontakt og indberette en ny for at få det rigtige datagrundlag i LPR. Såfremt en kontakt er blevet indberettet, og behandlerrelationen derefter er udtrukket og overført til NSP, hvorefter der indberettes en sletning af kontakten, så er det nødvendigt at slette behandlerrelationen i NSP. Dette synes enkelt, men det er faktisk mere komplekst end det lyder. Følgende redegør for kompleksiteten, og beskriver en løsning på, hvorledes den håndteres. En kontakt kan give anledning til mange behandlerrelationer. Hvis der f.eks. indgår 3 forskellige producerende afdelinger i en kontakt, så er der 4 behandlerrelationer for samme patient, som er udledt af én kontakt: 1. Stamafdeling 2. producerende afdeling 1 3. producerende afdeling 2 4. producerende afdeling 3 Når der indberettes en sletning, indberettes kun kontaktens nøgleoplysninger. Blandt disse indgår stamafdeling, ud fra hvilken behandlerrelation nr. 1 i listen ovenfor kan slettes i NSP. Men det er ikke muligt at slette relationerne 2, 3 og 4 i NSP. Sletning af disse vil kræve yderligere data fra LPR, f.eks. at der i LPR fremsøges den udgave af samme kontakt, der sidst blev udtrukket behandlerrelationer for, så det kan afgøres hvad der skal slettes. Dette er en kompleksitet, der ikke ønskes indført i LPR. Derfor vil det være relevant at indberette en reference til NSP, som NSP kan opbevare. Dette er en værdi, som entydigt identificerer en kontakt. Alle behandlerrelationer, som udledes af en kontakt, skal i NSP være stemplet med pågældende kontakts reference. Når en kontakt slettes i LPR, vil det være muligt at identificere de behandlerrelationer i NSP, der skal slettes, ved at overføre kontaktens reference i sletningen, som udtrækkes til NSP. NSP skal blot slette de relationer, der har den samme referenceværdi. Det samme gør sig i virkeligheden gældende når en givet kontakt overføres til NSP mere end én gang. En kontakt kan indberettes mange gange til LPR i løbet af sin levetid. Dette betyder at behandlerrelationerne ikke nødvendigvis er ens fra gang til gang. Derfor skal NSP slette de gamle behandlingsrelationer og oprette nye når en kontakt indberettes, som allerede har været indberettet én gang (eller alternativt foretage en mere intelligent opdatering med samme slutresultat). Dette kan ligeledes foregå vha. kontakt-referencen. 01.09.2011 A400.330.4 Released Logica Side 3 af 9
Bemærk: Denne reference er en værdi, som er nødvendig for rent teknisk at holde data i NSP korrekt synkroniserede med data i LPR. I [KRAVSPEC] er der også beskrevet en reference-værdi, ikke af tekniske årsager, men for at kunne spore data tilbage til LPR i forbindelse med evt. audit. Der anvendes derfor en reference bestående af en tekststreng sammensat af kontaktens nøgleoplysninger. Dermed kan referencen opfylde begge formål. 4 Krav Følgende krav er beskrevet af NSI: Krav 1 Krav 2 Krav 3 Krav 4 Krav 5 Krav 6 Krav 7 Krav 8 Dataformat af behandlingsrelation: Der ønskes en simpel datastruktur, hvor behandlingsrelationer repræsenteres som uafhængige sæt af informationer. Specifikation af forretningslogik: For hver type behandlingsrelation beskrives kriterier som giver anledning til pågældende relation. Udtræk af data skal ske i en automatiseret proces. Det skal også være muligt at bestille et manuelt udtræk for en givet periode. Der ønskes tolkningsvejledning for verifikation af behandlingsrelationer. Udtræksfrekvens skal kunne konfigureres. Data persisteres i kommasepareret fil, som overføres til NSP via FTP. Projektforløb Der skal fremstilles løsningsbeskrivelse, estimater og tidsplan. Der henvises til dokumentet [KRAVSPEC] for detaljerede beskrivelser af kravene. 5 Kravsbesvarelse Løsning, som opfylder NSI s krav til dataudtrækket, beskrives i det følgende. 5.1 Datastruktur (Krav 1) Behandlingsrelationer repræsenteres i følgende datastruktur anvendes Kategori Felt Kommentar Sted Ydernummer (6 ch) Ydernummer fra DUSAS speciallæge kontakter Skskode (4-7 ch) Kode fra Sundhedsstyrelsens sygehus/afdelingsklassifikation (SHAK). Patient Cprnr (40 ch) SHA1-hashværdi for cprnr. 20 karakterer repræsenteret ved deres 2-tegns hex-værdi. Interval Starttidspunkt Dato for behandlerrelationens starttidspunkt. (dd-mm-yyyy hh:mi) Sluttidspunkt (dd-mm-yyyy hh:mi) Dato for behandlerrelationens sluttidspunkt. Bemærk, denne kan være blank Type Type (1 ch) Relationstype, jf. afsnit 2 og 3: S Stamafdeling. Skskode er udfyldt med 7 karakterer. P Producerende afdeling. Skskode er udfyldt med 7 karakterer. Starttidspunkt er proceduretidspunktet, og sluttidspunkt er kontaktens sluttidspunkt, blank for uafsluttede kontakter. 01.09.2011 A400.330.4 Released Logica Side 4 af 9
U Udskrevet til sgh/afd. Skskode er udfyldt med 4 eller 7 karakterer, afhængigt af om der blot kendes sygehus eller også afdeling. Både start- og sluttidspunkt er udfyldt med LPR kontaktens sluttidspunkt. Y X Dusas speciallæge-kontakt. Ydernummer er udfyldt, skskode er blank. Sletning. Her er ydernummer eller skskode samt starttidspunkt udfyldt. Sluttidspunkt er blankt. Reference Reference (60 ch) Reference-værdi, som entydigt identificerer kontakten. Denne er sammensat af værdierne: Sygehus/afdelingskode (7 karakterer) Patienttype: Indlæggelse, ambulant eller skade, jf. [SST-FIH] (1 karakter) Eller, for DUSAS speciallæge kontakter: Ydernr (6 karakterer) Specialekode (2 karakterer) Dvs. altid 8 indledende karakterer. Dertil kommer SHA1-hashværdi for cprnr (40 karakterer) Kontakt start (12 karakterer). 5.2 Forretningslogik (Krav 2) For hver kontakt, som ikke er en sletning, genereres: 1. En type S behandlingsrelation til stamafdelingen, for almindelige LPR kontakter. Datointervallet er kontaktens startdato og slutdato. Slutdato er blank for uafsluttede kontakter. eller - 2. En Y behandlingsrelation til ydernummer, for DUSAS Speciallæge kontakter. Datointervallet er kontaktens startdato og slutdato. Slutdato er blank for uafsluttede kontakter samt - 3. En U behandlingsrelation for kontakter, hvis kontakten er afsluttet, og der er angivet en sygehus/afdelingskode i afsluttet til. Datointervallet er udfyldt med kontaktens sluttidspunkt som både start- og sluttidspunkt. 4. En P behandlingsrelation for hver producerende afdeling i kontakten, som ikke er identisk med stamafdelingen. Hvis den samme producerende afdeling optræder mere end én gang dannes der kun én relation for pågældende afdeling, med den tidligste dato som startdato. For hver slettekontakt genereres: 5. En type X behandlingsrelation. 01.09.2011 A400.330.4 Released Logica Side 5 af 9
5.3 Verifikation af behandlingsrelationer (Krav 4) I dette afsnit redegøres for, hvilken kategori de hvilke typer af behandlingsrelationer udledt fra LPR tilhører, jf. definitionen af kategorierne A-E i dokumentet [BR-KAT]. En sygehusafdeling har en behandlingsrelation af Kategori A, såfremt der eksisterer en S, P eller U-relation, som er gyldig på det forespurgte tidspunkt, da der her er tale om samme sted, samme tidspunkt. En sygehusafdeling har en behandlingsrelation af Kategori C, såfremt der eksisterer en S, P eller U-relation, som var gyldig før det forespurgte tidspunkt, da dette er en historisk betinget relation. En yder har en behandlingsrelation af kategori A, såfremt der eksisterer en Y relation 1, som er gyldig på det forespurgte tidspunkt, da der her er tale om samme sted, samme tidspunkt. En yder har en behandlingsrelation af Kategori C, såfremt der eksisterer en Y relation, som var gyldig før det forespurgte tidspunkt, da dette er en historisk betinget relation. 5.4 Afvikling af udtræk (Krav 3 + 5) LPR indeholder en scheduler-komponent, som anvendes til planlægning af jobs, samt automatiseret afvikling disse. Som eksempler på eksisterende jobs kan nævnes: Natligt udtræk af lister til regionerne med kontakter som i øjeblikket omfatter valideringsfejl. Månedlig samkørsel med forsikringsdata vedr. kritisk sygdom. Generelle eksportjobs. Jobs kan planlægges med en funktion, som er tilgængelig fra LPR brugerfladen. Følgende viser et eksempel på planlægning af job: Eksempel på konfiguration af jobparametre 1 Der kan ikke angives producerende enhed for procedurer i DUSAS speciallæge kontakter, så for disse findes ingen P relationer. 01.09.2011 A400.330.4 Released Logica Side 6 af 9
Eksempel på planlægning af afviklingstidspunkt Udtræk af data vedr. behandlingsrelationer etableres som et job, som kan konfigureres og afvikles af den eksisterende scheduler. Dette giver mulighed for: Konfiguration af afviklingsinterval, eksempelvis daglig afvikling på et fast tidspunkt. Konfiguration af jobparametre, eksempelvis datointerval for indlæggelse. Manuel afvikling af jobs kan foretages fra listen over planlagte jobs. Bemærk: Scheduleren giver i øjeblikket kun mulighed for daglig afvikling som hyppigste afvikling. Det er muligt at konfigurere sjældnere afvikling, eksempelvis hver anden dag, bestemte ugedage mv. Såfremt der ønskes hyppigere afvikling end dagligt (jf. bemærkning til krav 5) kan dette i øjeblikket gøres ved at oprette flere ens jobs, som afvikles på forskellige tidspunkter på dagen. Udtræksjobbet skal have følgende parametre, som kan angives: Kontakt modtaget tidspunkt minimum. Kontakt modtaget tidspunkt maksimum. Der kan med den eksisterende funktionalitet i schedulerens brugerflade specificeres både absolutte og relative datoer. Eksempelvis kunne det være relevant at angive -1 dag som fratidspunkt og nu som til-tidspunkt for jobbet som automatisk afvikles dagligt. For manuelle afviklinger vil det være relevant at angive præcise datoer. 01.09.2011 A400.330.4 Released Logica Side 7 af 9
Bemærk: I [KRAVSPEC] omtales ønske om udtræk af data med udgangspunkt i kontakt start tidspunkt (dvs. indlæggelsestidspunkt eller tidspunkt for ambulant indskrivning). Udgangspunkt i tidspunkt for modtagelse af kontaktdata i LPR i stedet vil resultere i at et dagligt udtræk omfat- startdato ter den naturlige tilvækst i data, uanset om indberettede kontakter har tilbagedateret eller ej. 5.5 Overførsel af data (Krav 6) Når data er udtrukket på en LPR server i form af en zippet kommasepareret datafil, vil filen automatisk blive flyttet til en FTP server, som er tilgængelig via FTP (på port 21) på Sundhedsdata- server en ny FTP nettet. Der er i LPR etableret en FTP server til lignende formål. Der oprettes på denne konto, som er dedikeret til NSP udtræk. FTP kontoen vil have et separat brugernavn og pass- word, og er således beskyttet mod uautoriseret adgang. Transmission af datafiler fra LPR til NSP FTP løsningen muliggør at NSP s løsning kan polle for nye datafiler med jævne mellemrum, og indlæse disse efterfølgende. Der vil blive oprettet følgende FTP konti: Drift: Adresse: lpradm.sundhedsstyrelsen.dsdn.dk Konto: behrelation Password: udleveres senere Test: Adresse: lpradm-test.sundhedsstyrelsen.dsdn.dk Konto: behrelation Password: udleveres senere Password til hhv. test og drift bliver forskellige. 6 Løsningens komponenter Løsningen omfatter følgende tilføjelser til LPR: Oprettelse af LPR funktionalitet, som implementerer udtræksjobbet. Definition af ny scheduler jobtype inkl. jobparametre. Oprettelse af konto på FTP server. Synkronisering af datafiler til FTP server. 01.09.2011 A400.330.4 Released Logica Side 8 af 9
7 Projektforløb 7.1 Leverance af testdata På et passende tidspunkt under projektforløbet leveres en fil med testudtræk af behandlingsrelationer, som Trifork kan anvende i forbindelse med test af import af udtrukne data. Der leveres ligeledes en udgave af filen med uhashede CPR-numre, som anvendes i test-øjemed. 7.2 Fremdrift (Krav 7) Der rapporteres løbende om fremdrift og designbeslutninger til NSI v/christian Ernstsen (Lakeside). 7.3 Tidsplan (Krav 8) Fremdriften evalueres i forhold til en overordnet tidsplan som udarbejdes separat. 8 Referencer KRAVSPEC Kravspecifikation: Service til opsamling af behandlingsrelationer, version 1.02. (NSI). BR-KAT SST-FIH Behandlingsrelationsservice: Vejledning til brug af registre, version 1.01. (NSI). Fællesindhold for basisregistrering af sygehuspatienter (Sundhedsstyrelsen) 01.09.2011 A400.330.4 Released Logica Side 9 af 9