Privacy - hvem skal have adgang til hvilke data?

Transkript

1 Privacy - hvem skal have adgang til hvilke data? Herbert L Jessen, Partner Devoteam Consulting & Morten Thomsen, Seniorkonsulent Devoteam Consulting C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

2 Indhold 2 1. Erfaringer med Service Orienteret Arkitektur i sundhedssektoren 2. Krav og behov for at opnå privacy 3. Eksisterende og mulige sikkerhedsmæssige tiltag i en Service Orienteret Arkitektur

3 Sammenhængende patient behandling og privacy 3 For at skabe en effektiv sammenhængende patient behandling mellem forskellige sundhedsaktører (f.eks. mellem et sygehus og en praktiserende læge), vil det være en klar fordel med en sammenhængende it understøttelse. En af de mulige veje til at skabe sammenhængende it understøttelse er at anvende en Service Orienteret Arkitektur (SOA) i sundhedssektoren. En En af af de de store store udfordringer udfordringer ved ved at at benytte benytte SOA SOA i i sundhedssektoren sundhedssektoren er er at at bibeholde/opnå bibeholde/opnå privacy. privacy.

4 SOA i sundhedssektoren - med udgangspunkt i udviklingen indenfor medicinområdet 4 SOA-løsninger udviklet af Lægemiddelstyrelsen i samarbejde med en række aktører og leverandører indenfor sundhedsområdet (LMS, Regionsforeningen, KL, Acure, IBM, BoSoft, Apoteksdata, DataPharm, Apotekerforeningen, TriFork, CSC, Rambøll Informatik, Zealand Care, A-Data, EG-Data, Ascott, Region Syd, Region Hovedstaden, MedCom) Udvikling er foregået over en årrække siden I 2000 introduceredes første centrale service (CTR) baseret på XML og HTTP/ SOAP transaktioner fra apotekernes kasseterminaler alle ekspeditioner af receptpligtig medicin skulle on-line opdatere centralt register I det følgende skitseres de væsentligste karakteristika af SOA løsningerne.

5 Lidt historik Lovændring forbrugsafhængigt tilskud til receptpligtig medicin Kasseterminal på apoteker Læge EDIFACT recepter 2003 Lov om Personlig Elektronisk Medicinprofil PEM Kasseterminal på apoteker Læge EDIFACT recepter 2005 Lov om Receptserver og hjemmesygeplejens adgang til PEM Kasseterminal på apoteker Læger On-line Transaktioner med beløb svartider < 2 s On-line Transaktioner med beløb Og udleveret medicin svartider < 2 s On-line EDIFACT recepter Centralt Tilskudsregister CTR CTR PEM CTR PEM Receptserver Medicinkort Lægemiddelstyrelsen Læger og lægens medhjælp Borgeren Læger og lægens medhjælp Borgeren Kommunal hjemmesygepleje

6 Lidt historik PEM loven (L171), bemærkninger: I første omgang 1999alene blive baseret på, at apotekerne under ekspeditionen indlægger oplysninger om patienternes lægemiddelkøb i medicinprofilen. Lovændring Medicinprofilen forbrugsafhængigt bliver en tidstro og udvidet version af Lægemiddelstyrelsens tilskud til receptpligtig Lægemiddelstatistikregister medicin for den enkelte patient. Kasseterminal Efterfølgende på udbygning apoteker(fase 2) af medicinprofilerne vil sygehusene tillige Læge skulle indlægge EDIFACT tilsvarende recepter oplysninger Der kan åbnes op for, at de behandlende læger kan indlægge yderligere relevante oplysninger i medicinprofilerne On-line (fase 2). Der skabes Transaktioner mulighed for, med at patienterne beløb selv kan indlægge oplysninger svartider < i 2 et s særligt elektronisk medicinskab. Centralt Tilskudsregister CTR Lov om Receptserver og hjemmesygeplejens adgang til 2003 PEM Mulighed Lov omfor øget receptkvalitet Samlet Personlig overblik over ordineret medicin Elektronisk Stort Medicinprofil gevinstpotentiale for hjemmesygeplejen PEM med hjemmesygeplejens Kasseterminal medicinkort Øget på apoteker datakvalitet i medicineringsgrundlaget Læge for hjemmesygeplejen EDIFACT recepter On-line Transaktioner med beløb Og udleveret medicin svartider < 2 s CTR PEM CTR PEM 2005 Lov om Receptserver og hjemmesygeplejens adgang til PEM Kasseterminal på apoteker On-line EDIFACT recepter 6 Læger Receptserver Medicinkort Lægemiddelstyrelsen Læger og lægens medhjælp Borgeren Læger og lægens medhjælp Borgeren Kommunal hjemmesygepleje

7 Receptserveren og dens nærmeste omgivelser i dag 7 CTR Medicinprofilen Apoteker Læger Fremførsel af EDIFACT/XML recepter WS opkobling via IP net VANS Net Progrator/Gatetrade EDICAT/XML Database WebServices Privat IP-net VANS net KMD GW Receptserver framing sundhed.dk Fremførsel af recepter Ekspedition af recepter

8 Aktuel status (november 2007) 8 I drift Under test Under udvikling Lov om Receptserver og hjemmesygeplejens adgang til PEM Kasseterminal på apoteker Læger Hjemmesygeplejens Fælles Medicinkort (FMK) Det fælles fælles medicinkort Klinikernes ønske om ajourførte Medicinkort og komplette (FMK) (HJFMK) medicineringsinformationer Håndtering af overgangssituationer mellem lægepraksis, sygehus og Kasseterminal Læger Kasseterminal hjemmesygeplejen Sygehusenes indberetningspligt Læger på apoteker på apoteker til PEM A-Data EG-Data Ascott On-line EDIFACT recepter On-line EDIFACT recepter On-line Webservice Receptserver CTR PEM Receptserver CTR PEM Receptserver Hjemmesyge-plejens medicinkort CTR PEM Fælles medicinkort Sundhed.dk Sundhed.dk Webservice Sundhed.dk Webservice Læger og lægens medhjælp Borgeren CSC Vitae Rambøll Care Zeeland Uniq Lyngsøe Region H Region Syd

9 Fælles Medicinkort 9 Medicinprofil Receptserver Borger sundhed.dk OIOXML specificeret snitflade Det fælles nationale medicinkort Praktiserende læger Kommunal hjemme-sygepleje Sygehuse Det fælles medicinkort fungerer som master medicinkort, som: - Kan anvendes direkte via GUI snitflade (SOSI Web browser), - Lokale systemer kan integrere via Web services, og dermed replikere data - Tilbyder advis funktioner, så parterne kan kommunikere med hinanden via det fælles medicinkort. Identificeret som et centralt initiativ i regeringens kvalitetsreform

10 Sammenhængende infrastruktur nødvendig ved SOA baseret systemsystem integration 10 Kommunikation mellem brugermodul og national service involverer brugermodulet, den nationale service, gateway og to uafhængige infrastrukturer. Lev. modul EPJ modul EPJ delsystem Myndigheds modul Kommunale infrastrukturer EOJ infrastruktur & platform GW EPJ infrastruktur & platform GW Regionale infrastrukturer Læge praksis system GW National on-line infrastruktur Private platforme GW Nationale services fx PEM, LPR GW Fælles services fx sundhed.dk SUP

11 Den regionale arkitektur kan med fordel også være SOA baseret 11 Klinikerens (brugerens) begrebs- og procesmodel Modul 1 Modul 2 EPJ delsystem A EPJ delsystem B klinisk portal connector connector connector EPJ udvekslings semantik (systemer) Connector bus Enterprise Service Bus Gateway til eksterne services EPJ data repository Stamdata mv. Regional service X Integration til lokale systemer Sikkerheds -løsning Identity Provider National online infrastruktur Sundhedsdatanet II National udvekslings semantik (systemer)

12 Indhold Erfaringer med Service Orienteret Arkitektur i sundhedssektoren 2. Krav og behov for at opnå privacy 3. Eksisterende og mulige sikkerhedsmæssige tiltag i en Service Orienteret Arkitektur

13 Hvad er privacy? 13 [Gyldendals røde ordbog] Privacy: Uforstyrrethed, privatliv, hemmelighed. [wikipedia.org] Privacy is the ability of an individual or group to seclude (udelukke, isolere) information about themselves and thereby reveal themselves selectively [Morten [Morten Thomsen Thomsen indenfor indenfor sundhedssektoren] Privacy Privacy er er retten retten til til at at bestemme bestemme over over egne egne personlige personlige data: data: Hvem Hvem har har adgang adgang til til hvad hvad hvornår hvornår (og (og hvorfor hvorfor har har de de haft haft adgang). adgang).

14 Eksisterende it-løsninger => modsatrettede krav/behov 14 Borgernes behov for privacy Patientsikkerhed og kvalitet i behandlinger Effektiv sundhedssektor

15 Privacy er bygget ind i lovgivningen 15 Persondataloven Sundhedsloven Lovgivningen udtrykker en afvejning mellem behovet for at beskytte følsomme oplysninger og behovet for at forbedre patientsikkerhed og kvalitet i behandlingen. [Esben Dalsgaard & Pia Jespersen, SDSD, SundhedsITnet møde dec. 2007]. Ny lov om it-anvendelse i sundhedsvæsnet og elektroniske helbredsoplysninger er et godt udgangspunkt (trådte i kraft 1. oktober 2007)

16 Forudsætninger for adgang 16 ID 42a stk 1 42a stk 6 42a stk 2 42a stk 4 Grupper af brugere Læger Læger med samtykke Andre sundhedspersoner Andre sundhedspersoner med ledelses tilladelse Bemyndigelse Kan i fornødent omfang indhente oplysninger i forbindelse med aktuel behandling af patient. Kan indhente oplysninger i forbindelse med aktuel behandling af patient Kan i fornødent omfang indhente oplysninger i forbindelse med aktuel behandling af patient. Kan i fornødent omfang indhente oplysninger i forbindelse med aktuel behandling af patient. Krav Patienten ikke har frabedt sig at der indhentes oplysninger ( negativ samtykke ) Patientens samtykke Adgangen skal være teknisk begrænset til de patienter, der er i behandling på samme behandlingsenhed, som personen er tilknyttet. Kravet om teknisk begrænsning kan bortfalde, hvis ledelsen på et behandlingssted giver tilladelse til det og dette gøres offentligt tilgængeligt. 42a stk 8 42a stk 9 Medicin-studerende Sekretærer Det lægen selv har adgang til Det sundhedspersonen selv har adgang til Person skal være ansat på behandlingsstedet. Bemyndiges af Læge. Bemyndiges af sundhedsperson. Skal ske under lægers ansvar.

17 Den dataansvarlige skal sikre sig at lovgivning overholdes (og herved at privacy bibeholdes) 17 Lægepraksis Sygehus? Det dataansvarlige har behov for at vide noget om medarbejderen, før der kan gives adgang.

18 Hvilke attributter har den dataansvarlige i sundhedssektoren behov for at kende? Sikker identifikation af sundhedspersonen 2. Sundhedspersons autorisation 3. Behandlingssted, hvor patient er i aktuel behandling 4. Behandlingssted, som medarbejder er knyttet til 5. Bemyndigelse/fuldmagt 6. Samtykke/negativ samtykke

19 Indhold Erfaringer med Service Orienteret Arkitektur i sundhedssektoren 2. Krav og behov for at opnå privacy 3. Eksisterende og mulige sikkerhedsmæssige tiltag i en Service Orienteret Arkitektur

20 Analogi: Musikfestival 20 Alle skal have et armbånd for overhovedet at blive lukket ind på festival pladsen Forskellige scener kræver forskelligt farvet armbånd som checkes af vagter inden man får adgang Hvis man skal backstage, fx som journalist, har man af den centrale festival myndighed fået udstedt et kort til at hænge om halsen, hvoraf det fremgår at man er journalist og har adgang backstage. Ligeledes gælder hvis man skal have adgang til musiker VIP området, har man af den centrale festival myndighed fået udsted et kort. Eksempler på attributter der giver forskellig adgang: Festival deltager, journalist, musiker, festival medarbejder. Festival pladsen VIP musiker område Backstage Backstage Backstage Grøn scene Gul scene Rød scene

21 Hvordan overføres attributter? 21 Service Orienteret System Integration" (SOSI) Autorisationsservice. Et system, der kan udlevere oplysninger om en bruger, f.eks. dennes organisatoriske tilhørsforhold, offentlige autorisationskode, etc. Bruges til at hente oplysninger der skal påtrykkes et ID-kort. SOSI: Attributter verificeret af godkendt udsteder i sundhedssektoren [Figur fra: sosi.dk]

22 1&2 Identifikation af sundhedsperson og sundhedspersons autorisation 22 Ved at bruge OCES certifikater til autentificering, har man Certifikatudstederens (CA) garanti for at personen er den han/hun giver sig ud for at være. I sundhedssektoren kan man få udstedt OCES certifikater til medarbejdere, som deres cpr-nummer knyttes til Når en sundhedsperson autentificerer sig med OCES certifikat, kan offentlige organisationer hos CA få oplyst cpr-nummer På baggrund af cpr-nummer kan der slås op i Autorisationsregisteret og få oplyst gældende sundhedsfaglig autorisation.

23 1&2 Identifikation af sundhedsperson og sundhedspersons autorisation 23 Praktiserende læge Hansen Sygehus Alpha 7 8 Identifikation Autorisation Aktuel behandling 1 6 Fuldmagt Samtykke 2 IDP cpr Læge Aut. id cpr Autorisations CA registeret

24 3 Behandlingssted, hvor patient er i aktuel behandling 24 Forslag til en central service: Patient i aktuel behandling - CVR - evt. sygehusafdeling - SOR En borgers praktiserende læge bør som default være et sted, hvor man er i aktuel behandling: - Alle borgere under sygesikrings gruppe 1 er tilknyttet en lægepraksis, dette kan slås op i yderregisteret. Når en patient indlægges (eller ambulant) på et sygehus, skal et uafhængigt system - f.eks. det Patient Administrative System (PAS) rapporterer dette ind til den centrale service. - Systemet skal sikre, at det ikke er den samme medarbejder, der indlægger en patient, som også søger oplysninger på patienten (Separation of Duties SoD-princippet). Når en kommune får ansvaret for behandlingen af en patient, skal den rapporterer hvilke behandlingssteder patienten er knyttet til - Efter SoD-princippet

25 4 Behandlingssted, som medarbejder er knyttet til 25 Af et OCES certifikat, udstedt til medarbejdere i sundhedssektoren, fremgår hvilken virksomhed de er tilknyttet d.v.s. CVR-nummeret For at have en løsning der bedre kan tage højde for mobiliteten i sundhedssektoren, bør man arbejde hen imod en løsning, der ikke er afhængig af at CVR-nummeret fremgår af OCES certifikatet: - I system til system kommunikation, kan man få systemet til at fortælle fra hvilken virksomhed medarbejderen laver et opkald. - I det tilfælde en forespørgsel sker fra et sygehus skal systemet påtrykke afdelings ID (SOR) således opslag vil kunne begrænses til patienter tilknyttet den pågældende afdeling.

26 3&4 Behandlingssted patient og medarbejder 26 Praktiserende læge Hansen CVR Sygehus Alpha Identifikation Autorisation Aktuel behandling cpr-patient 4 Fuldmagt Samtykke cpr-patient 2 IDP 3 CVR Patient i aktuel behandling

27 5 Bemyndigelse/fuldmagt 27 Hvis en medarbejder der ikke er sundhedsfaglig autoriseret laver et opslag (fx medicinstuderende, sekretær, hjemmehjælp), kan det kun ske hvis en sundhedsfaglig autoriseret medarbejder har givet fuldmagt til det. Forslag til en central service: Fuldmagts register - Autoriserede sundhedsfaglige medarbejdere bemyndiger andre medarbejdere med fuldmagt.

28 5 Bemyndigelse/fuldmagt 28 Lægesekretær Christensen CVR Sygehus Alpha Identifikation Autorisation Aktuel behandling cpr-patient Aut. ID 4 Fuldmagt Samtykke 2 IDP 3 Aut. ID Fuldmagts register

29 6 Samtykke/negativ samtykke 29 I dag afgives et samtykke typisk mundtligt til en behandlende læge, som skriver det ind i journalen (papir/elektronisk) I en fremtid med sammenhængende it-systemer, bør dette kunne ske elektronisk Forslag til en central service: Samtykke register Ideelt set burde et samtykke register give en borger mulighed for at bestemme hvem må se hvad og hvornår - dette kunne meget hurtigt gå hen og blive en uoverskuelig opgave for den enkelte Første trin kunne være, negativ samtykke: - Borgere kan vælge at blokere for bestemte grupper af sundhedspersoner ikke må lave opslag på deres patientdata. Eksempler på kategorier: Praktiserende læge, bemyndigede af praktiserende læge, sygehusansatte læger, sygehusansatte sundhedspersoner, bemyndigede af sygehusansatte sundhedspersoner. Næste trin kunne være: - Borgere skal kunne se hvem, der har registreret borgerens samtykke Fremtidige trin kunne være at borgere får mulighed for, at - klassificere egen patientdata - give samtykke på baggrund af lokalitet (fx lægepraksis, sygehus, kommune) - give samtykke på baggrund af sundhedsperson (interaktivt under en konsultation) Bemærk negativ samtykke bør altid kunne tilsidesættes i tilfælde af et akut ekstraordinært opslag

30 6 Samtykke/negativ samtykke 30 Praktiserende læge Hansen CVR Sygehus Alpha Identifikation Autorisation Aktuel behandling cpr-patient 4 Fuldmagt Samtykke 2 IDP 3 cpr-patient Aut. ID Samtykke register

31 Andre privacy fremmende tiltag 31 Forslag til central service: Anonymitet/pseudonym register Borgeren får mulighed for at vælge, hvordan borgeren skal identificeres hos forskellige sundhedsaktører, ved at: - borgeren selv vælger et pseudonym, fx Jens Jensen - borgeren fra systemet rekvirere koder, fx 983wdew9ud. - Koderne kan skiftes efter borgerens eget ønske. - Systemet sørger for at koderne er unikke (således man ikke risikerer at to personer indlagt på samme sygehus optræder under samme kode). Når en borger skal i behandling hos en sundhedsaktør, medbringer borgeren et mobilt OCES certifikat. OCES certifikatet læses af sundhedsaktørens system Sundhedsaktørens system slår op i pseudonym registeret og henter borgerens id, fx Navn: Jens Jensen, unik id: 983wdew9ud.

32 Spørgsmål og afrunding 32

33 Referencer 33 Lov nr 431 af 08/05/2007, Lov om ændring af sundhedsloven, (It-anvendelse i sundhedsvæsnet og elektroniske helbredsoplysninger) Oversigt over de juridiske rammer for adgangen til EPJ og IT-anvendelse i sundhedsvæsnet, notat fra Indenrigs- og Sundhedsministeriet, 22. juni Svar fra Datatilsynet til Amtsrådsforeningen, 22/09/2006, vedrørende privatpraktiserende lægers adgang til e-journal. Lov nr 546 af 24/06/2005, Sundhedsloven. Lov nr 429 af 31/05/2000, Persondataloven. SOSI beskrivelse: