Vejledning til kald af Sundhedsjournalen Version udgivet

Transkript

1 Vejledning til kald af Sundhedsjournalen Version udgivet

2 Indhold Revisioner... 3 Kendte udfordringer... 4 Anvendte forkortelser... 5 Tekniske forkortelser Introduktion Startpakken Kildekode Sikkerhedskonceptet Overblik SamlResponse PatientCpr Adgang til Sundhedsjournalen SOSI-ID kort SAML:Assertion SAML:Issuer SAML:Subject SAML:Conditions SAML:AttributeStatement Oplysninger om id-kortet IDCardData Oplysninger om brugeren UserLog Oplysninger om organisationen SystemLog XML er på XSD og XML gennemgang Forklaring af formatet for parameterbeskrivelser Forklaring af format for skemagrafer Sdk EpJournal FMK BRS LabBank Noter

3 Revisioner Version Dato Ansvarlig Noter /4-13 Første version 1.1 2/5-13 Afsnit om XML uddybet, syntaks for enkelte parametre er ændret. Det gælder: OrgUsingId, OrganisationIdentifier og QueryableCvrList draft 17/5-13 -felt for hver parameter i XML tilføjet. Uddybende forklaringer tilføjet på ExternalSystemSessionId, OrgResponibleName, NegativeConsentType, AuthorisationIdentifier, RelationLookupTimeInterval. Der er spørgsmål på et par felter mere, som pt. ikke er afklaret /6-13 tho@sundhed.dk Skema og skemabrudstykker indsat i forklaring XML Data og XML databrudstykker indsat i forklaring Sdk.ExternalSystemSessionId udgår Sdk.ExternalSystemUserId udgår Sdk.ExternalSystemType udgår /6-13 tho@sundhed.dk LabBank.TimeOfFirstSample ikke længere obligatorisk LabBank.TimeOfLastSample ikke længere obligatorisk LabBank.RequestTime ikke længere obligatorisk Fmk.OnBehalfOf tilføjet Brs.ExternalreferenceID beskrivelse opdateret Sdk.LogReference tilføjet Sdk.LogTime tilføjet feltets indhold opdateret til at indeholde XML eksempler Inkomplet afsnit om SOSI-ID kort tilføjet /6-13 tho@sundhed.dk Mindre fejl i beskrivelsen af ændringer for version 1.3 rettet. Beskrivelsen af parametre i afsnittet parametergennemgang opdateret. XSD opdateret. på parameterxml for Thomas Larsen opdateret. på parameterxml for Lægens Medhjælp tilføjet. på parameterxml for Sekretær tilføjet. Afsnit om adgang til Sundhed.dk tilføjet. Tomme tags tillades ikke længere i parameter XML. QueryableCVR format ændret 1.5 2/7-13 heso@sundhed.dk Tilføjet attributten type= FMK til elementet QueryableCvr under BRS i hvert af eksemplerne 3

4 1.6 12/7-13 beskrevet på hver parameter. Komplette XDS og XML filer flyttet ud af dokumentet over i separate filer. Der er foretaget ændringer på en række felter. Se revisionsnumre på hvert felt / / tja@sundhed.dk tho@sundhed.dk Tho@sundhed.dk Mindre layoutmæssige opdateringer og konsekvensrettelser. Tilføjelse af oversigt over forkortelser. Liste over forkortelser udviddet. Afsnit 1.4 Sikkerhedskonceptet tilføjet. Kapitel 6 SOSI-ID kort er omskrevet. Bemærk at medcom:usergivenname, og medcom:usersurname medcom:useroccupation skal udfyldes. XSD og XML eksemplet er flyttet ud af dokumentet. XSD for hverenkelt parameter findes dig stadig. Diagram for XSD struktur introduceret i stedet. Afsnit Forklaring af grafformat tilføjet. XDS: En række parametre skal nu indeholde mindst et tegn i værdifeltet. Tom værdi i obligatorisk felt giver ikke mening. XDS: Navngivning i skema ændret for flere undertyper eksempler er revideret, så de er blevet mere meningsfyldte. Sdk.landingpage: ny mulighed sj:support tilføjet. Sdk.Loglocation tilføjet. SdkLogSystem tilføjet. Sdk.LogTime er nu obligatorisk og skal være datetime format. EPJournal.Usertype beskrivelse ændret EPJournal.ExtendedLoggin tilføjet. EPJournal.Consent tilføjet som obligatorisk. FMK.NegativeConsentType er udgået. BRS.AuthorizationIdentifyer er udgået. Informationen trækkes i stedet fra SOSI-ID kortet. BRS.Externalreference erstattes af BRS.ExternalreferenceID Labbank.Consent er eneste labbank parameter, de øvrige er udgået. Brs.AcceptableRelations parameteren beskrivelse, der var glemt, er nu tilføjet. Kendte udfordringer Version Noter Sektion om SOSI-Id kort er inkomplet. Afventer gennemarbejdning fra sdk. 2. LandingPage mangler indstilling til driftside (eller hvad den nu kommer til at hedde). Afventer specikation in sdk. 3. FMK.OrgResponibleName afklaring af organization udestår. Afventer nspop/fmk-teknik. 4

5 4. Labbank.UserConsent præcis afklaring omkring hvad der skal håndteres omkring samtykke til labbank udeståer. Afventer Sdk. 5. E-jounal: afklaring omkring parametre i kald til IBM s webservice. 6. Gennemskrivning af dokumentet, hvor skema info flyttes til hver enkelt parameter, som i de første LandingPage mangler indstilling til driftside (eller hvad den nu kommer til at hedde). Afventer specikation i sdk. 2. FMK.OrgResponibleName afklaring af organization udestår. Afventer nspop/fmk-teknik. 3. E-jounal: afklaring omkring parametre i kald til IBM s webservice FMK.OrgResponibleName afklaring af organization udestår. Afventer nspop/fmk-teknik. 2. E-jounal: afklaring omkring parametre i kald til IBM s webservice. Disse udeståender forventes ikke at påvirke grænsefladen. Anvendte forkortelser Forkortelse BRS EPJ LPS NSP sdk SJ SSI SKS SHAK Forklaring Behandlingsrelationservice på NSP (samt evt. tilknyttede services som f.eks. Notifikationsservice) Elektronisk Patientjournal (anvendes på hospitaler) Læge-praksissystem (anvendes af praktiserende læger, speciallæger og privathospitaler) Den Nationale Serviceplatform (udbydes af National Sundheds-It under Statens Seruminstitut) Sundhed.dk, der udvikler og drifter Sundhedsjournalen Sundhedsjournalen Statens Serum Institut Sygehusvæsenets KlassifikationsSystem SygeHusAfdelingsKlassifikation Tekniske forkortelser Forkortelse Forklaring XML extensible Markup Language ( XSD Xml Skema Definition ( HTTP HyperText Transfer Protocol ( POST En af de otte metoder HTTP protokollen definerer. SOSI ServiceOrienteret Systemintegration ( ) SOSI-Id kort Metafor for identifikationsoplysninger i SOSI ( OCES Offentlige Certifikater til Elektronisk Service ( MOCES VOCES FOCES POCES Medarbejder-OCES, signatur for medarbejdere ( Virksomheds-OCES, signatur for virsomheder Funktions-OCES, signatur for funktioner Personlig-OCES, signatur for personer SAML Security Assertion markup Language ( ) 5

6 XHTML MVC extensible HyperText MarkupLanguage ( Model-View-Controller coding pattern Diagrammer i dokumentet er genereret med Altova XML Spy

7 1. Introduktion 1.1 Startpakken Dette dokument er en del af startpakken som EPJ og LPS leverandører tager udgangspunkt i. Pakken indeholder: 1. Nærværende dokument 2. Sekvensdiagram for systemet 3. Komplet XSD fil 4. XML eksempler 5. Kildekoden til Sundhed.dk testknap 6. Liste med kontaktpersoner 1.2 et med dette dokument er at forklare, hvordan Elektroniske Patientjournalsystemer (EPJ) og Læge- Praksissystemer (LPS) kan få adgang til Sundhedsjournalen (SJ). Dokumentet forklarer hvilke parametre, der skal overføres for at åbne SJ i en browser og hvordan. 1.3 Kildekode Med til denne dokumentation følger en zip fil med c# kildekode til den testknap Sundhed.dk har benyttet internt. Kildekoden indeholder en lang række kommentarer og dataeksempler som i høj grad kan bidrage til forståelsen af løsningen. Start med filen EpjWebTestClient\Controllers\HomeController.cs i metoden PerformLogin(string patientcpr, string selectedprincipal), hvor opbygningen af SAML Responset begynder. 1.4 Sikkerhedskonceptet En række parametre skal overføres fra EPJ/LPS til sundhedsjournalen. Svaret er en webside med fortrolige helbredsoplysninger. Transaktioner af denne art skal følge persondataloven og sundhedsloven. Det skal sikres at der ikke gives uretmæssig adgang til fortrolig information, samt at al adgang til informationen kan spores. Forsimplet gøres dette ved at en bruger fremsætter en påstand (et claim) om hvem han er. Denne påstand sendes til en identitetsudbyder (en IdP) som bekræfter at påstanden er korrekt. Den bekræftede påstand sendes, sammen med et ønske om at se data for en borger, til sundhed.dk. Sundhed.dk kalder videre til de underliggende datakilder (via sundhedsdatanettet), og indhenter de ønskede informationer, der præsenteres for brugeren. Alle led i operationen logges, så brugeren senere kan stå til regnskab for sine handlinger. n at certifikater(krypetering) og sundhedsdatanettet sikrer datatransporten mellem brugeren, sundhed.dk og kildesystemerne. 2 Overblik Når Sundhedsjournalen skal åbnes i en browser, skal sundhed.dk kaldes med et HTTP POST kald. Indholdet i dette kald kan eksempelvis oprettes ved at kalde en XHTML side, som den, der vises i Figur 1 XHTML skabelon herunder. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " <html xmlns=" xml:lang="en"> <head></head> <body onload="document.forms[0].submit()"> <noscript> <p> <strong>note:</strong> Since your browser does not support vascript, you must press the Continue button once to proceed. C#.Net MVC Razor view code Razor koden er en skabelon hvori data indsættes i felterne markeret Der er felter i skabelonen; 7

8 </p> </noscript> <form method="post"> <div> <input type="hidden" name="samlresponse" /> <input type="hidden" name="patientcpr" /> <input type="hidden" name="xml" /> </div> <noscript> <div> <input type="submit" value="continue" /> </div> </noscript> </form> </body> </html> Figur 1 som i kode erstattes med værdier. Den resulterende XHTML side kan kaldes med HTTP GET og den submitter sig selv onload. Derved rettes et post kald til den url der er angivet parameteren. Post-kaldet indeholder yderligere tre Heri lægges en base64-encoded XML SAML2 Response. Hvordan den er opbygget beskrives i Her ligger patientens cpr-nummer i klar tekst. Se afsnittet PatientCpr for For at Sundhed.dk kan hente data fra de underliggende services, er en række parametre nødvendige. Disse parametre ligger i en base-64 encoded XML her. Se afsnittet XML for detaljer. 3 SamlResponse SAML response er den sikkerhedsbærende del af postrequesten. Se OASIS SAML 2.0 dokumentationen, afsnit for standarden for opbygningen af kaldet. Første niveau er base 64 encoded; HTTP POST SAML Response Base 64 encoding Encrypted Assertion STS Signed Sealcard PatientCPR XML Base 64 encoding For at kunne opbygge SAML Response er der brug for følgende: Et Signeret SOSI-ID kort (aka sealcard) Sundhedspersonens MOCES certifikat Endpoint hos serviceprovider Endpoint hos Identity provider 8

9 4 PatientCpr Patientens cprnummer uden bindestreg (10 tegn). 5 Adgang til Sundhedsjournalen Sundhed.dk kræver at alle CVR-numre (fra certifikatet), der tilgår sosi.sundhed.dk, er oprettet i Sundhed.dk s rettighedssystem som sygehuse. Sundhed.dk forventer at alle sygehuse tilgår løsningen med et certifikat fra en af de 5 regioner. 9

10 6 SOSI-ID kort SOSI-ID-kortet indeholder en række oplysninger om brugerens identitet, som STS en garanterer, er ægte (autentiske). I dette afsnit beskrives kravene til hvilke af disse oplysninger, der skal forefindes i SOSI-ID kortet, samt hvad konsekvenserne er, i fald de mangler. I Den Gode Webservices requestbeskeder og i visse responsebeskeder findes oplysninger om bruger og system, herunder sikkerhedsoplysninger. Oplysningerne indlejres i en såkaldt SAML Assertion, der standardiserer denne type information. Denne SAML Assertion kaldes i DGWS for beskedens id-kort, fordi det angiver afsenderens identitet i bred forstand. Id-kortet er en pendant til det fysiske id-kort, man anvender i mange virksomheder, og som dels identificerer indehaveren, dels giver dennes adgang til forskellige afdelinger. Ud over oplysninger om brugeren og systemet indeholder id-kortet akkreditiver, der bruges til autentifikation. Et akkreditiv kan være enten et brugernavn og password, eller en OCES digital signatur. Figuren nedenfor viser et id-kort udstedt af et lokalt system SOSI-GW Region Østdanmark på vegne af et it-system EMJ 2.3. Id-kortet identificerer en slutbruger, Ole H. Berggren med CPR-nummer , som er autoriseret læge. Id-kortet i eksemplet er blevet verificeret af en betroet 3.part, SOSI-STS, der har verificeret den digitale medarbejdersignatur som id-kortet var signeret med. Kortet er gyldigt fra det tidspunkt det blev skabt af SOSI-GW Region Østdanmark, dvs. fra den 25/ kl. 12:23:09 zulu tid (13:23:09 dansk sommertid) til 24 timer efter den 26/ kl. 12:23:09 zulu tid. Id-kortets akkreditiver er ikke vist i detaljer. Id-kortet består af følgende overordnede afsnit: 1. saml:assertion er det XML element, der samler hele id-kortet og angiver hvilken version af SAML der anvendes. 2. saml:issuer angiver hvem der har dannet id-kortet. 3. saml:subject er SAML s måde at angive den bruger eller det system, som idkortets andre attributter henfører til. 10

11 4. saml:conditions benyttes i Den Gode Webservice til at angive id-kortets gyldighed, som er 24 timer efter det tidspunkt kortet blev dannet på. Gyldigheden kan benyttes af webserviceudbydere, når det skal afgøres, om de kan have tillid til id-kortet. 5. saml:attributestatement angiver attributter om den identitet der angives ved idkortet herunder oplysninger om kortet selv, brugeroplysninger, organisationsdata, mm. SAML:Assertion Det samlende element, der angiver hele id-kortet har følgende umiddelbare elementer: Element Beskrivelse for SJ Det tidspunkt, hvor id-kortet blev skabt. Hvis idkortet indeholder en digital signatur, angiver IssueInstant det tidspunkt, hvor beskeden blev underskrevet (dvs. lige inden) datetime, f.eks T07:53:00Z Beskrivelse SAML versions-id. DGWS benytter p.t for SJ Element Beskrivelse for SJ Den del af DGWS, der indeholder oplysninger om afsenderen og bevis for dennes identitet (bruger, system, signatur, username/password etc.) IDCard Altid 11

12 SAML:Issuer Angiver hvem der har dannet id-kortet. Dette er typisk det afsendende it-system eller en proxy / gateway. Element Beskrivelse for SJ saml:issuer Navn på den organisation, der har udstedt idkortet (eller underskrevet det) String Altid 12

13 SAML:Subject I klassiske autentifikationsscenarier sendes akkreditiverne kun, når der skal logges på, og der sendes ikke egentlige oplysninger om brugeren og systemet, som det er tilfældet i Den Gode Webservice. Den part, der foretager autentifikationen, kan så selv associere aftageren med flere oplysninger, f.eks. baseret på et bagvedliggende brugerkatalog eller lignende. I Den Gode Webservice er den gængse autentifikationsmodel udvidet en anelse, idet der sammen med akkreditiver også sendes egentlige oplysninger om slutbrugeren, og det system vedkommende kom fra. Det er så op til webserviceudbyderen og/eller identitetsservicen at validere disse påstande eller at stole på dem. Modellen gør det muligt at kommunikere et fælles sæt oplysninger med 3 forskellige grader af autentifikationsniveau. I det mest pålidelige scenario har en klient eller en identitetsservice tjekket digitalt signerede brugerinformationer mod bagvedliggende centrale registre. I det mindst pålidelige scenario er der ingen akkreditiver, og modtageren må stole blindt på afsenderens oplysninger i id-kortet. Det er dette niveau 3 Sundhedsjournalen benytter. Element Beskrivelse for SJ Element./NameID Identifikation af person. CPRnummer for person. String Altid./NameID@ Beskrivelse Hvilket format indhold er angivet i. medcom:cprnumber for SJ Element Altid Beskrivelse for SJ Element /ConfirmationMethod Angiver, hvordan oplysningerne kan godtgøres, f.eks. ved at indehaveren fremviser en nøgle (brugernavn/password, signatur). DGWS bruger kun "urn:oasis:names:tc:saml:2.0:cm:holder-ofkey" urn:oasis:names:tc: SAML:2.0:cm:holder-ofkey Altid /KeyName 13

14 Beskrivelse Angiver en reference til den nøgle der identificerer brugeren Reference til det id, som idkortets digitale signatur har. Altid på niveau 3 og 4. for SJ SAML:Conditions Benyttes til at angive hvor længe id-kortet er gyldigt. Et id-kort er gyldigt i 24 timer regnet fra det tidspunkt id-kortet dannes. I single-signon betyder det, at det er tidligere end det tidspunkt hvor STS en verificerer signaturen. Element Beskrivelse for SJ Tidspunkt for id-kortets oprettelse. Id-kortet er ugyldigt før dette tidspunkt. Dette tidspunkt benyttes af webservicen ved beregning af timeout datetime Altid Beskrivelse for Tidspunkt for id-kortets udløb. Sættes til NotBefore + 24 timer. Efter dette tidspunkt er idkortet ugyldigt datetime Altid SAML:AttributeStatement I id-kortets AttributeStatement lagres oplysninger om brugeren og dennes kontekst, samt yderligere information om kortet. De informationer der findes her kan inddeles i 3 grupper: 1. oplysninger om id-kortet, 2. oplysninger om brugeren, 3. samt oplysninger om organisationen. Nedenfor listes de oplysninger der vedrører id-kortet. Oplysninger om id-kortet IDCardData Ethvert id-kort har et unikt id. Det angives som et løbenummer i attributten IDCardID og benytter en bestemt version af specifikationen, der angives i IDCardVersion. Versionsnummeret gør det muligt at udvide id-kortets datasæt i en senere udgave af Den Gode Webservice. Id-kortet kan være udstedt til en medarbejder eller et system. Det angives i IDCardType som enten user eller system. 14

15 Afhængig af hvor stærke akkreditiver der blev anvendt, da id-kortet blev udstedt, kan dets AuthenticationLevel være fra 1 til 4, hvor 4 er stærkest. Hvis der blev anvendt et OCEScertifikat til autentifikation, indeholder OCESCertHash en hashværdi af det certifikat, der lå til grund. Beskrivelse for SJ sosi:idcardid Et unikt id for dette id-kort. To id-kort må aldrig anvende samme id String Altid Beskrivelse sosi:idcardversion Angiver den version af id-kort-formatet, som dette id-kort er lavet ud fra. String. Værdi skal være 1.01 for SJ Altid Beskrivelse for SJ sosi:idcardtype Angiver om dette id-kort identificerer en bruger ( user ) eller et it-system ( system ) String. Værdi: user eller system. For SJ anvendes user altid. Altid sosi:authenticationlevel Beskrivelse Det sikkerhedsniveau, som dette id-kort blev udstedt til. Lovlige værdier er 1 = ingen autentifikation, 2 = brugernavn/password, 3 = VOCES-signatur, 4 = MOCESsignatur. DGWS tillader også niveau 5 med digital signatur på hele kuverten, men dette angives IKKE i id-kortet kun i medcom:securitylevel feltet.. for SJ String. For SJ anvendes 4 altid. Altid sosi: OCESCertHash 15

16 Beskrivelse for SJ SHA-1 hashværdi af det certifikat, der blev anvendt til autentifikation. base64binary Altid Oplysninger om brugeren UserLog Et id-korts vigtigste funktion er at levere oplysninger om dets indehaver ved identifikation, adgangskontrol, logning mv. Den sektion af id-kortet, der indeholder information om medarbejderen, findes i UserLogelementet. I UserLog findes oplysninger om personens navn, CPR-nummer og -adresse. Desuden indeholder elementet en rolle, der på sigt forventes at komme fra en national klassifikation. Brugeren er sundhedsfaglig (og har som sådan en autorisationskode fra Sundhedsstyrelsen) og kommer fra en sundhedsfaglig organisation, der angives med navn og en CareProviderID -kode. Koden kan være et CVRnummer, et P-nummer, en SKSkode, et ydernummer, kommunenummer, lokationsnummer eller andet, som angivet i attributtens type. Beskrivelse for SJ medcom:usercivilregistrationnumber Brugers CPR-nummer eller et erstatnings-cprnummer String. Altid. Beskrivelse for SJ, erstatnings CPRnumre fungerer ikke i SJ. medcom:usergivenname Fornavn på brugeren String. Optionel. Beskrivelse for SJ medcom:usersurname Efternavn på brugeren String. Optionel. 16

17 Beskrivelse for SJ medcom:user address adresse på brugeren String. Optionel. Nej Beskrivelse for SJ medcom:userrole Brugers rolle (Fx "læge" eller "Ansat på OUH") i forbindelse med rettighedstildeling. En bruger kan have flere roller. String. Altid. Beskrivelse for SJ medcom:useroccupation Brugers stilling, f.eks. overlæge. String. Optionel. Beskrivelse for SJ medcom:userauthorizationcode Autorisationskode fra Sundhedsstyrelsens Autorisationsregister. Integer(5) Optionel når IDCardType = user, aldrig ellers. Nej, men nødvendigt for at få adgang til FMK Oplysninger om organisationen SystemLog Alle id-kort, uanset om de gælder for en medarbejder eller en applikation, skal anvendes gennem et klientsystem, som en evt. medarbejder så benytter. Oplysninger om dette system findes i SystemLog: medcom:careproviderid 17

18 Beskrivelse for SJ Id for organisation, der driver IT systemet, i form af CVR-nummer, skal matche nummeret i certifikatet.( SOSI-STS-teknisk-beskrivelse-v1.0.1.pdf ) 1. urn:medcom:names:careprovider:ynumber - Feltet indeholder et unikt idnummer af anden type end de ovennævnte 2. urn:medcom:names:careprovider:pnumber - Feltet indeholder et P- nummer, der er produktionsenhedsnummer fra CVR-registeret, der tildeles et CVR-nummer for hver fysisk 3. urn:medcom:names:careprovider:skscode - Feltet indeholder en SKSsygehusafdelingskode 4. urn:medcom:names:careprovider:cvrnumber - Feltet indeholder et CVRnummer Integer Altid, I kald til SJ skal CareProviderID være et CVR nummer. Det bemækes at CVR nummeret skal være whitelistet hos sundhed.dk. medcom:careprovidername Beskrivelse Navn på den organisation, der driver it-systemet. String Optionel for SJ 18

19 7 XML Xml feltet indeholder en række data, der er nødvendige for at Sundhedsjournalen kan hente data fra de underliggende kilder og for at der kan rapporteres til Behandlingsrelationsservicen. Xml feltet bygges som vist i eksemplet herunder, og indsættes base 64 encoded i POST kaldet til Sundhed.dk. 7.1 er på XSD og XML Den komplette XSD fil og XML eksempler er en del af startpakken. 7.2 gennemgang XML består af 5 hovedgrupper: 1. Sdk sundhed.dk-specifikke parametre 2. EpJournal parametre der anvendes i kald til E- Journal og P-Journal 3. FMK parametre der anvendes ikald til Fælles Medicin Kort 4. Brs parametre der anvendes i kald til Behandlingsrelationservice 5. LabBank parametre der anvendes i kald til LabBank og LabPortal Alle 5 hovedgrupper er obligatoriske (som den fuldt optrukne kant på billedet viser). 19

20 7.2.1 Forklaring af formatet for parameterbeskrivelser Revisioner Relevant skema Noter ens navn Et versionsnummer for parameteren Hvad bruges parameteren til. En tekstuel forklaring af parameteren En forklaring af format of syntax. Streng angiver en streng af ubegrænset længde. Angiver om feltet skal udfyldes. Udfyldes et obligatorisk felt ikke, afvises henvendelsen. Her vises den del af XSD filen som vedrører feltet. Her vises et eksempel på en værdi for feltet Eventuelle noter om feltet som ikke passer andre steder Forklaring af format for skemagrafer De væsentligste dele af notationen for grafterne gengives her. Et fuldt optrukket element er obligatorisk, et stiblet er valgfrit. Et databærende element er markeret ved tre små linier Kan der optræde flere ens elementer efter hinanden markeres det således Et element med flere underelementer er marketet med en underelement boks 20

21 7.2.2 Sdk Data til anvendelse i sundhed.dk LandingPage Revisioner 1.0, 1.2, 1.6, 1.7 Relevant skema At give det kaldende system mulighed for at vælge hvilken af Sundhedsjournalens faner der åbnes. En tekst fra journalsystemet som anvendes i Sundhed.dk til at bestemme hvilken URL brugeren re-dirigeres til efter login. Den angivne tekst er en del af et sæt af fast definerede muligheder. sj:overblik, sj:journal, sj:medicin, sj:laboratorie, sj:kontakt, sj:link, sj:support. EPJ systemer skal anvende sj:overblik. LPS-systemer skal vælge sj:overblik eller et af de øvrige mulige formater. <xs:element minoccurs="1" maxoccurs="1" name="landingpage" type="landingpagetype" /> <xs:simpletype name="landingpagetype"> <xs:restriction base="xs:string"> <xs:enumeration value="sj:overblik" /> <xs:enumeration value="sj:journal" /> <xs:enumeration value="sj:medicin" /> <xs:enumeration value="sj:laboratorie" /> <xs:enumeration value="sj:kontakt" /> <xs:enumeration value="sj:link" /> <xs:enumeration value="sj:support" /> </xs:restriction> </xs:simpletype> 21

22 <LandingPage>sj:overblik</LandingPage> Revisioner 1.6, 1.7 Relevant skema LogLocation At etablere et audit-spor fra det kaldende systems log til Sundhedsjournalens log. Indeholder et entyding id for den organisation, hvor i brugeren aktuelt befinder sig når webservice-kaldet udføres. Attributten Name angiver hvilket format organisationen identificeres ved. Der er følgende muligheder. 1. medcom:sor : SOR kode [SOR], 2. medcom:communalnumber : Kommunekode [KOMMKODE], 3. medcom:cvrnumber : CVR nummer [CVR], 4. medcom:skscode : SHAK kode [SKS], alle SHAK koder skal angives på afdelingsniveau. 5. medcom:pnumber : CVR-P [CVR], 6. medcom:ynumber : Yderregisteret [YDER]. Værdien i tagget angiver et ID i det valgte format. Revisioner 1.6, 1.7 <xs:element minoccurs="1" maxoccurs="1" name="loglocation" type="loglocationext" /> <xs:simpletype name="loglocationextenum"> <xs:restriction base="xs:string"> <xs:enumeration value="medcom:ynumber" /> <xs:enumeration value="medcom:pnumber" /> <xs:enumeration value="medcom:skscode" /> <xs:enumeration value="medcom:cvrnumber" /> <xs:enumeration value="medcom:communalnumber" /> <xs:enumeration value="medcom:sor" /> </xs:restriction> </xs:simpletype> <xs:complextype name="loglocationext"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="loglocationextenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <LogLocation type="medcom:ynumber">2393</loglocation> LogSystem At etablere et audit-spor fra det kaldende systems log til Sundhedsjournalens log. LogSystem forstås som en angivelse af det system hvortil LogReference peger En XML struktur med tre underfelter, hver med en streng. Name angiver navnet på produktet, Vendor angiver hvem der har fremstillet produktet Version angiver produktets versionsnummer 22

23 Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="logsystem" type="logsystemseq" /> <xs:complextype name="logsystemseq"> <xs:sequence> <xs:element minoccurs="1" maxoccurs="1" name="name" type="string1" /> <xs:element minoccurs="1" maxoccurs="1" name="vendor" type="string1" /> <xs:element minoccurs="1" maxoccurs="1" name="version" type="string1" /> </xs:sequence> </xs:complextype> <xs:simpletype name="string1"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> </xs:restriction> </xs:simpletype> <LogSystem> <Name>Æskulab Almen</Name> <Vendor>Ascott software A/S</Vendor> <Version>8.0</Version> </LogSystem > <LogSystem> <Name>Columna EPJ</Name> <Vendor>Systematic</Vendor> <Version>6.0</Version> </LogSystem > LogReference Revisioner 1.3, 1.4, 1.6, 1.7 Relevant skema At etablere et audit-spor fra af det kaldende systems log til Sundhedsjournalens log. En reference, der kan bruges til at binde audit loggen i det kaldende system sammen med audit loggen hos Sundhed.dk. Referencen skal være unik i det angivne LogSystem. String <xs:element minoccurs="1" maxoccurs="1" name="logreference" type="string1" /> <xs:simpletype name="string1"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> </xs:restriction> </xs:simpletype> <LogReference>F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4</LogReference> LogTime Revisioner 1.3, 1.4, 1.6, 1.7 At etablere et audit-spor fra det kaldende systems log til Sundhedsjournalens log. LogTime angiver det tidspunkt som logges i det kaldende system. 23

24 datetime Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="logtime" type="xs:datetime" /> <LogTime> T15:07: :00</LogTime> 24

25 7.4.1 EpJournal Kald til E-Journal og P-Journal hos MedCom. E- og P-Journal dokumentation: UserId Revisioner 1.0, 1.2, 1.6 At etablere et audit-spor fra det kaldende systems log til e/p-journalens log. Angiver ID for brugeren fra det kaldende system. ID et skal være unikt i det kaldende system. String en anvendes uændret i kaldet til E/P-journal. Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="userid" type="string1" /> <UserId>12</UserId> UserType Revisioner 1.0, 1.2, 1.6, 1.7 Relevant skema Hjælp til audit i e-journal og p-journal. en er relateret til skærpet logning. Værdien sendes til e-journal i omskrevet form. String med værdien PracticePhysician, Specialist eller Other. <xs:element minoccurs="1" maxoccurs="1" name="usertype" type="usertypeenum" /> <xs:simpletype name="usertypeenum"> 25

26 <xs:restriction base="xs:string"> <xs:enumeration value="practicephysician" /> <xs:enumeration value="specialist" /> <xs:enumeration value="other" /> </xs:restriction> </xs:simpletype> <UserType>Specialist</UserType> Revisioner 1.6 ExtendedLogging At kunne logge skærpet i de tilfælde hvor det er påkrævet. Skærpet logning foretages hvis: 1. En patient tilses af en anden praktiserende læge end patientens egen (opklares vha sikrede data) eller 2. En patient behandles af en speciallæge uden henvisning (opklares via henvisningshotellet) en angiver om der skal logges skærpet. Extended logging sættes altid false hvis UserType er sundhedsfaglig. I dag anvender sundhed.dk skærpet logning: 1. når en læge tilgår en borgers data uden at være borgerens egen læge (via sikrede data i yderregisteret), eller 2. når en speciallæge tilgår en borgers data uden at der findes en henvisning( i henvisningshotellet / refhost). True eller false Nej Relevant skema <xs:element minoccurs="0" maxoccurs="1" name="extendedlogging" type="xs:boolean" /> <ExtendedLogging>true</ExtendedLogging > Region Revisioner 1.0, 1.2 Ukendt. En tekst der navngiver den region journalsystemet betjenes fra. en har endnu ingen effekt så den skal altid kaldes med værdien 'Alle'. String indeholdende Alle en anvendes uændret i kaldet til E/P-journal. Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="region" type="xs:string" /> <Region>Alle</Region> Hospital 26

27 Revisioner 1.0, 1.2, 1.6 Angiver navnet på stedet hvorfra opslaget udføres, til audit. Navnet på det hospital journalsystemet betjenes fra. For praksis udfyldes klinik navn. String en anvendes uændret i kaldet til E/P-journal. Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="hospital" type="xs:string" /> <Hospital>Hillerød</Hospital> <Hospital>Hjørring Lægehus</Hospital> Department Revisioner 1.0, 1.2, 1.6 Angiver navnet på stedet hvorfra opslaget udføres, til audit. Navnet på den afdeling journalsystemet betjenes fra. Udfyldes ikke for praksissektoren (element uden indhold). String en anvendes uændret i kaldet til E/P-journal. Nej Relevant skema <xs:element minoccurs="0" maxoccurs="1" name="department" type="xs:string" /> <Department>Kirurisk Afdeling</Department> SksCode Revisioner 1.0, 1.2 Angiver stedet hvorfra opslaget udføres, til audit. Koden angiver stedet journalsystemet betjenes fra. SKS kode jf. Sygehus-afdelingsklassifikation også kaldet SHAK. Se evt. String en anvendes uændret i kaldet til E/P-journal. Udfyldes ikke for praksissektoren (element uden indhold). Nej Relevant skema <xs:element minoccurs="0" maxoccurs="1" name="skscode" type="xs:string" /> <SksCode>130149</SksCode> Consent Revisioner 1.6,

28 At angive om patienten har afgivet samtykke til at sundhedspersoner må se patientens data. Logges i e-journal og p-journal. Samtykke type angives med værdi Patienten har givet samtykke til at jeg indhenter oplysninger 2. Patienten er bevidstløs og ude af stand til at give samtykke til at indhente oplysninger. 3. Indhentning af oplysninger sker af hensyn til andet aktuelt behandlingsforløb, hvor patienten er ude af stand til at give samtykke (angiv grund nedenfor): String. Typen angives som en string med værdien 1, 2 eller 3. Samtykke type angives med værdi 1-3. I fald type 3 angives, skal der også udfyldes en forklaring Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="consent" type="consentext" /> <xs:simpletype name="consentextenum"> <xs:restriction base="xs:string"> <xs:enumeration value="1" /> <xs:enumeration value="2" /> <xs:enumeration value="3" /> </xs:restriction> </xs:simpletype> <xs:complextype name="consentext"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="consentextenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <Consent type="3">patienten er bevistløs</consent> 28

29 7.4.2 FMK Kald til det fælles medicinkort hos SSI. beskrivelserne stammer fra det Fælles Medicinkort, Snitfladebeskrivelse Version som kan hentes fra og fra et uddybende spørgsmål på Revisioner 1.0, 1.1 Relevant skema OrgUsingId Entydigt at kunne identificere den organisation, hvor brugeren aktuelt befinder sig når webservice kaldet udføres, sammen med OrgUsingName. Indeholder det entydige id på den organisation, hvor brugeren aktuelt befinder sig når webservice kaldet udføres. en anvendes uændret i kaldet til FMK. Attributten Name angiver hvilket format organisationen identificeres ved. Der er følgende muligheder. 1. medcom:sor : SOR kode [SOR], 2. medcom:communalnumber : Kommunekode [KOMMKODE], 3. medcom:cvrnumber : CVR nummer [CVR], 4. medcom:skscode : SHAK kode [SKS], alle SHAK koder skal angives på afdelingsniveau. 5. medcom:pnumber : CVR-P [CVR], 6. medcom:ynumber : Yderregisteret [YDER]. Værdien i tagget angiver et ID i det valgte format (1-200 tegn langt). <xs:element minoccurs="1" maxoccurs="1" name="orgusingid" type="orgusingidext" /> <xs:simpletype name="nameenum"> <xs:restriction base="xs:string"> <xs:enumeration value="medcom:ynumber" /> <xs:enumeration value="medcom:pnumber" /> <xs:enumeration value="medcom:skscode" /> 29

30 <xs:enumeration value="medcom:cvrnumber" /> <xs:enumeration value="medcom:communalnumber" /> <xs:enumeration value="medcom:sor" /> </xs:restriction> </xs:simpletype> <xs:complextype name="orgusingidext"> <xs:simplecontent> <xs:extension base="string200"> <xs:attribute name="name" type="nameenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <OrgUsingId Name="medcom:pnumber">16af2393</OrgUsingId> OrgUsingName Revisioner 1.0 Entydigt at kunne identificere den organisation, hvor brugeren aktuelt befinder sig når webservice kaldet udføres, sammen med OrgUsingID. Indeholder det entydige navn på den organisation, hvor brugeren aktuelt befinder sig når webservice kaldet udføres. Navnet på organisationen modsvarer det id der findes i attributten OrgUsingId. en anvendes uændret i kaldet til FMK. String Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="orgusingname" type="string1" /> <OrgUsingName>Rigshospitalet</OrgUsingName> Revisioner 1.0, 1.2 Relevant skema OrgResponibleName Entydigt at kunne identificere den organisation, der har ansvaret for it-systemet. Indeholder det entydige navn på den organisation, der har ansvaret for it-systemet. Det bemærkes, at organisationen meget vel kan være en ikke-sundhedsfaglig organisation, der måske ikke engang kan identificeres via en klassifikation som CVR, som i tilfældet en driftsafdeling i en region. Derfor anvendes der ikke klassifikationer for denne attribut. OrgResponsibleName er entydig. en anvendes uændret i kaldet til FMK. string <xs:element minoccurs="1" maxoccurs="1" name="orgresponiblename" type="string1" /> <OrgResponcibleName>IBM</OrgRespocnibleName> 30

31 Revisioner 1.0, 1.2 Relevant skema er på værdi RequestedRole At kunne validere at adgang til FMK er legal. Indeholder den rolle som brugeren ønsker at kalde FMK med. Da flere roller kan være tilknyttet et enkelt MOCES certifikat, skal den valgte rolle udpeges. String Muligheder for sundhedsfaglige roller er følgende. I parentes angives hvilke kriterier der er grundlag for validering af rollen i FMK. Læge (Autorisationsregister) Tandlæge (Autorisationsregister) Jordemoder (Autorisationsregister) Sygeplejerske (Autorisationsregister) Social- og sundhedsassistent (Autorisationsregister) Social- og sundhedshjælper (Trust) Farmaceut (Trust) Farmakonom (Trust) Assistent for Læge (Bemyndigelsesregister, Autorisationsregister) Assistent for Tandlæge (Bemyndigelsesregister, Autorisationsregister) Assistent for Sygeplejerske (Bemyndigelsesregister, Autorisationsregister) Assistent for Jordemoder (Bemyndigelsesregister, Autorisationsregister) Assistent for Social- og sundhedsassistent (Bemyndigelsesregister, Autorisationsregister) en anvendes uændret i kaldet til FMK. Bemyndigelsesregisteret findes hos NSI. <xs:element minoccurs="1" maxoccurs="1" name="requestedrole" type="string1" /> <RequestedRole>Læge</RequestedRole> <RequestedRole>Assistent for Læge</RequestedRole> <RequestedRole>Tandlæge</RequestedRole> <RequestedRole>Farmaceut</RequestedRole> Revisioner 1.3 OnBehalfOf At kunne trække FMK data på vegne af en anden. Medhjælp for sundhedsfaglig baseret på bemyndigelse. Under normal anvendelse af FMK vil det være den sundhedsfaglige som udfører opdateringer og opslag med sin digitale signatur. vis læger har ofte en lægesekretær til at foretage selve tastearbejdet, hvorfor der er et teknisk behov for at medhjælperen kan lave opslag og opdateringer på vegne af den sundhedsfaglige person. For at løfte denne opgave er der i FMK implementeret et bemyndigelsesregister hvor den sundhedsfaglige kan oprette de personer der bemyndiges til at agere på 31

32 vegne af den sundhedsfaglige. Registeret kan vedligeholdes af den sundhedfaglige via fmk-online.dk. Adgang som medhjælp for en sundhedsfaglig person, kræver at der angives en MOCES signatur, samt at strukturen OnBehalfOf sættes i SOAP headeren med den sundhedsfagliges autorisationskode. Følgende regler gælder for medhjælp for sundhedsfaglig: At medhjælpen er oprettet som medhjælper for den sundhedsfaglige i FMKs bemyndigelsesregister. Medhjælperen benytter sin egen digitale medarbejder signatur, idet SOSI ID kortet bliver signeret med medhjælperens signatur. Medhjælperen angiver autorisationsnummeret på den sundhedsfaglige person som der handles på vegne af. Autorisationsnummeret skrives ind i OnBehalfOf SOAP headeren. At RequestedRole er sat til den korrekte assistent rolle i hvert kald til FMK. String ens værdi anvendes uændret i kaldet til FMK, hvor XML en er lidt anderledes. Nej. Relevant skema <xs:element minoccurs="0" maxoccurs="1" name="onbehalfof" type="string1" /> <OnBehalfOf>BR56T</OnBehalfOf> 32

33 7.2.5 BRS BRS er en national service, der skal lette opgaven med audit. Ideen er at hver gang en sundhedsperson tilgår en borgers data fra en datakilde, så logges denne handling. Ved at sammenholde disse logninger med andre registres logninger er det muligt at beregne en sandsynlighed (kategoriseres A+, A, B, C, D eller E) for at der har været en behandlingsrelation på opslagstidspunktet. Datatilsynet har krævet at Sundhedsjournalen benytter BRS. Dokumentationen er baseret på 33

34 OrganisationIdentifier Revisioner 1.0, 1.1, 1.7 At identificere den kaldende organisation. Organisationen inden for hvilken relationen skal findes. Feltet er struktureret og kan indeholde et sks, ydernummer eller EAN-nummer. I attributten type angives DoctorOrganisationIdentifier (værdi: streng, 1-17 tegn) HospitalOrganisationIdentifier (værdi: streng, 1-17 tegn) EAN (værdi: streng tegn) en anvendes uændret i kaldet til BRS Relevant skema Note <xs:element minoccurs="1" maxoccurs="1" name="organisationidentifier" type="organisationidentifierext" /> <xs:simpletype name="organisationidentifierextenum"> <xs:restriction base="xs:string"> <xs:enumeration value="doctororganisationidentifier" /> <xs:enumeration value="hospitalorganisationidentifier" /> <xs:enumeration value="ean" /> </xs:restriction> </xs:simpletype> <xs:complextype name="organisationidentifierext"> <xs:simplecontent> <xs:extension base="string200"> <xs:attribute name="type" type="organisationidentifierextenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <OrganisationIdentifier type="ean">243546</organisationidentifier> Idelt set burde denne information trækkes fra SOSI-ID kortet, men her gives der ikke mulighed for at anvende EAN numre. TimeLimit Revisioner 1.0, 1.7 Angiver udløbsperiode for opfølgningen efter hvilket der skal rejses en alarm. Kan eksempelvis sættes til 60 (dage fra dags dato). Integer, målt i hele dage en anvendes uændret i kaldet til BRS Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="timelimit" type="xs:int" /> <TimeLimit>60</TimeLimit> ExternalReferenceId Revisioner 1.6 At kunne finde et auditspor fra BRS log tilbage til kildesystemets log. Et id der vil blive brugt ved returnering af en eventuel alarm. Hvis ikke feltet udfyldes, genererer BRS automatisk en værdi i svaret (se tabellen nedenfor). et med feltet er at give det kaldende system mulighed for at lave egne referencer til eventuelle afklaringer af hændelsesforløb på et senere tidspunkt. Feltets indhold kan opbygges frit. 34

35 Relevant skema Streng (0-50 tegn) <xs:element minoccurs="1" maxoccurs="1" name="externalreferenceid" type="string50" /> <ExternalReferenceId>6669</ExternalReferenceId> QueryableCvrList Revisioner 1.0, 1.1, 1.4 CVR numre der skal have adgang til en eventuel efterfølgende alarm. Eventuelle notifikationer kan alene hentes af organisationer, hvor et af de angivne CVR numre i dette felt matcher CVR nummeret i organisationens certifikat. Relevant skema I eksemplet nedenfor vil sundhed.dk foretage 4 kald til BRS. Et på vegne af hver af de dataansvarlige for: FMK-data, hvor et certifikat med CVR nummer skal benyttes for at hente den endelige behandlingsrelation. E-Journal-data, hvor et certifikat med CVR nummer skal benyttes for at hente den endelige behandlingsrelation P-Journal-data, hvor et certifikat med CVR nummer skal benyttes for at hente den endelige behandlingsrelation Labbank-data, hvor et certifikat med CVR nummer skal benyttes for at hente den endelige behandlingsrelation Den endelige behandlingsrelation hentes fra notifikationsservicen. Ved at opmærke hvert CVR nummer med en type vil Sundhed.dk let kunne holde op med at kalde på vegne af en bestemt dataansvarlig, hvis den dataansvarlige selv overtager at kalde BRS. Yderligere typer kan aftales med Sundhed.dk. Feltet indeholder en XML struktur med et vilkårligt antal underfelter. Listen skal indeholde mindst et CVR nummer. I praksis vil BRS blive kaldt en gang med hvert CVR nummer, der oplyses i listen. Attributten type angiver med en kort tekst en tekniske type for data. Type skal antage en af følgende værdier: FMK, EJournal, PJournal, Labbank, DR, Other. <xs:element minoccurs="1" maxoccurs="1" name="queryablecvrlist" type="queryablecvrseq" /> <xs:complextype name="queryablecvrseq"> <xs:sequence> <xs:element minoccurs="1" maxoccurs="unbounded" name="queryablecvr" type="queryablecvrext" /> </xs:sequence> </xs:complextype> <xs:simpletype name="queryablecvrextenum"> <xs:restriction base="xs:string"> <xs:enumeration value="fmk" /> <xs:enumeration value="ejournal" /> <xs:enumeration value="pjournal" /> <xs:enumeration value="labbank" /> <xs:enumeration value="dr" /> </xs:restriction> </xs:simpletype> 35

36 <xs:complextype name="queryablecvrext"> <xs:simplecontent> <xs:extension base="string20"> <xs:attribute name="type" type="queryablecvrextenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <QueryableCvrList> <QueryableCvr type="fmk"> </queryablecvr> <QueryableCvr type="ejournal"> </queryablecvr> <QueryableCvr type="pjournal"> </queryablecvr> <QueryableCvr type="labbank"> </queryablecvr> </QueryableCvrList> ServiceProvider Revisioner 1.0 Serviceudbyder (f.eks. FMK). Bruges til logformål. Service Provider forstås som firmaet eller organisationen der har udviklet EPJ eller LPS. en anvendes uændret i kaldet til BRS Relevant skema <xs:element minoccurs="1" maxoccurs="1" name="serviceprovider" type="serviceproviderseq" /> <xs:complextype name="serviceproviderseq"> <xs:sequence> <xs:element minoccurs="1" maxoccurs="1" name="name" type="string1" /> <xs:element minoccurs="1" maxoccurs="1" name="vendor" type="string1" /> <xs:element minoccurs="1" maxoccurs="1" name="version" type="string1" /> </xs:sequence> </xs:complextype> <ServiceProvider> <Name>Columna</Name> <Vendor>Systematic A/S</Vendor> <Version>15.0</Version> </ServiceProvider> RelationLookupTimeInterval Revisioner 1.0 Tidsinterval inden for hvilket behandleren har foretaget opslaget. Kan f.eks. være validetsperioden for behandlerens ID-kort. Forklaring fra Lakeside (che), der har udviklet FMK: RelationLookupTimeInterval kan godt udfyldes med kaldetidspunktet som endepunkter i tidsintervallet, og dermed i praksis reduceres fra et interval til et tidspunkt. Grunden til at man kan angive et interval er hvis man ønsker at sikre sig mod falske positiver hvis BRS har mere upræcise angivelser fra kilden - BRS undersøger om der er overlappende tidsintervaller, og hvis nu CSC angiver kaldstidspunktet 13:24 (for nu at vælge et tilfældigt klokkeslæt), men der hos kilden pga. registreringspraksis eller unøjagtige serverure eller noget helt tredje er registreret et andet nøjagtigt tidspunkt, f.eks. kl 13:15, så risikerer man at få en alarm, selvom der faktisk er en reel behandlingsrelation. Det er derfor vi anbefaler en bredere tidsangivelse, og et rigtig godt bud er 36

37 Relevant skema gyldighedsperioden af det anvendte ID-kort - men det kunne også have været hele kalenderdøgnet, eller klokkeslættet +- 4 timer, eller noget helt fjerde. Det er den part, der skal modtage notifikationerne, der bestemmer intervalangivelserne, for det er med disse angivelser i hånden, at man skal overbevise datatilsynet om at man har styr på sikkerheden. en anvendes uændret i kaldet til BRS <xs:element minoccurs="1" maxoccurs="1" name="relationlookuptimeinterval" type="relationlookuptimeinterval" /> <xs:complextype name="relationlookuptimeinterval"> <xs:sequence> <xs:element minoccurs="1" maxoccurs="1" name="start" type="xs:datetime" /> <xs:element minoccurs="1" maxoccurs="1" name="end" type="xs:datetime" /> </xs:sequence> </xs:complextype> <RelationLookupTimeInterval> <Start> T12:57: :00</Start> <End> T12:57: :00</End> </RelationLookupTimeInterval> AcceptableRelations.1 At annullere opfølgninger på relationer der er tilstrækkeligt gode. En liste af acceptable relationer (f.eks. A, B ). en anvendes uændret i kaldet til BRS. Udelades parameteren sendes en tom liste til BRS. Nej Relevant skema <xs:element name="acceptablerelations" type="arrayofstring" minoccurs="0" maxoccurs="1"/> <xs:complextype name="arrayofstring"> <xs:sequence> <xs:element name="string" type="xs:string" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <AcceptableRelations> <string>a</string> </AcceptableRelations> 37

38 7.2.6 LabBank Labbank er en national sammenstilling af klinisk biologiske prøvesvar. Revisioner 1.6 Consent At angive om patienten har afgivet samtykke til at sundhedspersoner må se patientens data. Logges i e-journal og p-journal. Samtykke type angives med værdi Patienten har givet samtykke til at jeg indhenter oplysninger 2. Patienten er bevidstløs og ude af stand til at give samtykke til at indhente oplysninger. 3. Indhentning af oplysninger sker af hensyn til andet aktuelt behandlingsforløb, hvor patienten er ude af stand til at give samtykke (angiv grund nedenfor): String. Typen angives som en string med værdien 1, 2 eller 3. Samtykke type angives med værdi 1-3. I fald type 3 angives, skal der også udfyldes en forklaring Nej, men i fald den ikke angives vil labbank framen selv afkræve samtykket. Relevant skema <xs:element minoccurs="0" maxoccurs="1" name="consent" type="consentext" /> <xs:simpletype name="consentextenum"> <xs:restriction base="xs:string"> <xs:enumeration value="1" /> <xs:enumeration value="2" /> <xs:enumeration value="3" /> </xs:restriction> </xs:simpletype> <xs:complextype name="consentext"> <xs:simplecontent> <xs:extension base="string1"> <xs:attribute name="type" type="consentextenum" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> Noter <Consent type="3">patienten er bevistløs</consent> Feltet introduceret som valgfrit inden release 38

39 8 Noter I skrivende stund har Sundhed.dk har udfordringer med seal.net implementationen i.net 3.5 versionen. Af denne grund har Sundhed.dk foretaget et mindre indgreb, og rettet seal dll en til, så den virker. Når den officielle version er rettet, kan Sundhed.dk versionen kasseres, men indtil da kan den med fordel benyttes. Sundhed.dk benytter seal for.net