IHE-profiler innenfor IT infrastruktur

Transkript

1 Integrating the Healthcare Enterprise Norge IHE-profiler innenfor IT infrastruktur Status pr IHE-arbeidsutvalg IHE Norge v Utarbeidet av: Edgar Glück (KITH) 1

2 Innhold 1. Introduksjon Om IHE og standarder Om IHE-profiler for IT-infrastruktur IHE-profiler innenfor IT infrastruktur Sammenheng mellom ulike IHE-profiler Aktører Bruk av de ulike aktørene i de enkelte integrasjonsprofilene Transaksjoner Bruk av transaksjoner i ulike integrasjonsprofiler Beskrivelse av profilene for IT infrastruktur Fremhenting av opplysninger for presentasjon (RID) Merknader Refererte standarder Aktører Transaksjoner Informasjonsflyt Autentisering av brukere innenfor et foretak (EUA) Refererte standarder Merknader Aktører Transaksjoner Informasjonsflyt Kryssidentifisering av pasienter (PIX) Refererte standarder Merknader Aktører Transaksjoner Informasjonsflyt Desktopsynkronisering (PSA) Refererte standarder Merknader

3 Aktører Transaksjoner Informasjonsflyt Tidssynkronisering (CT) Refererte standarder Aktører Transaksjoner Informasjonsflyt Bruk av sentralt pasientregister (PDQ) Refererte standarder Merknad Aktører Transaksjoner Informasjonsflyt Etablering av en sikker node (ATNA) Autentisering ved tilkopling Logging Refererte standarder Aktører Transaksjoner Informasjonsflyt Utveksling av dokumenter mellom foretak (XDS) Refererte standarder Aktører Transaksjoner Informasjonsflyt Datastruktur Merknader Helsetjenestepersonellregister (PWP) Refererte standarder: Merknader Aktører Transaksjoner

4 Informasjonsflyt IT infrastruktur-profiler for uttesting (Tillegg ) Digital signering av dokumenter (DSG) Refererte standarder Varsling av tilgjengelig dokument (NAV) Refererte standarder Aktører Transaksjoner Informasjonsflyt Utveksling av pasientadministrative opplysninger (PAM) Refererte standarder Aktører Transaksjoner Informasjonsflyt IT infrastruktur-profiler for utprøving (Tillegg ) Cross-enterprise Document Media Interchange (XDM) Refererte standarder Aktører Transaksjoner Informasjonsflyt Datastruktur Forskjellen mellom XDM og XDR Cross-enterprise Document Reliable Interchange (XDR) Refererte standarder Aktører Transaksjoner Informasjonsflyt Overføringsmekanismer Forholdet mellom XDR og XDS Utveksling av innskannede dokumenter mellom foretak (XDS-SD) Refererte standarder Patient Identifier Cross-Reference and Patient Demographic Query HL7 V3 (PIX/PDQ V3)

5 Refererte standarder Aktører Transaksjoner Informasjonsflyt Datastruktur Lagret forespørselsmelding for XDS-profilen Refererte standarder Aktører Transaksjoner Informasjonsflyt Definerte forespørsler Bruk av skjema for datafangst (RFD) Refererte standarder Aktører Transaksjoner Informasjonsflyt IT infrastruktur-profiler for kommentering (Tillegg ) Autentisering av brukere mellom foretak (XUA) Refererte standarder Aktører Transaksjoner (antydet) Informasjonsflyt Informasjonsutveksling på tvers av foretak eller XDS-område Informasjonsflyt White paper on Cookbook for the Security Section of IHE Profiles Definisjoner og forkortelser Referanser

6 1. Introduksjon 1.1. Om IHE og standarder Håndtering av informasjon innebærer at data overføres mellom ulike parter (aktører) og lagres for senere fremhenting. For de ulike trinn i denne prosessen baseres løsningene på internasjonale standarder. Slike standarder kan definere hvordan informasjonen skal struktureres og overføres og hvordan samhandlingen skal være mellom de ulike aktørene. De fleste standarder dekker ofte flere bruksområder hvor ikke alle krav i standarden er like aktuelle for alle områdene. Når en standard skal anvendes for et konkret formål vil det derfor være nødvendig å definere mer detaljert hvilke deler av en gitt standard som skal benyttes. For å få til den nødvendige samhandling (interoperabilitet) må alle involverte aktører benytte de valgte standardene på samme måte. IHE Integrating the Healthcare Enterprise er en organisasjon som definerer hvordan slik samhandling skal foregå ved å definere en IHE-profil for en gitt arbeidsoppgave. En IHE-profil definerer vanligvis hvordan et sett av aktører samhandler ved å utføre et sett av transaksjoner i en innbyrdes fastsatt rekkefølge. For hver transaksjon defineres informasjonsinnholdet som utveksles og det gis spesifikke opplysninger om hvilke standarder som skal benyttes til dette formålet og nøyaktig hvordan disse standardene skal benyttes. IHE samler et sett av IHE-profiler for et anvendelsesområde og publisere disse som et teknisk rammeverk. Noen IHE-profiler er mer generelle og kan være aktuelle innenfor mange anvendelsesområder disse publiseres som et teknisk rammeverk for IT infrastruktur. Andre IHE-profiler er spesifikke for et gitt anvendelsesområde og publiseres separat for hvert anvendelsesområde (radiologi, laboratorieområdet osv.). IHE internasjonalt er sterkt influert av store internasjonale leverandører som benytter IHE-profilene som referanse for sine produkters egenskaper og deres evne til å kunne samhandle med utstyr fra andre leverandører. Samhandlingen testes gjennom praktisk utprøvning under IHE's årlige Connectathon i USA og Europa. Her testes leverandørenes produkter mot produkter fra andre leverandører og det utstedes sertifikat som bekrefter at en leverandør har produkter i samsvar med gitte IHE-profiler. IHE har sitt utgangspunkt fra USA og løsningene er ikke alltid tilpasset behovene i andre land. Av denne grunn er det mulighet for å definere nasjonale tilpassinger som publiseres som tillegg til det tekniske rammeverket. Slike nasjonale tillegg er blant annet publisert for England, Frankrike, Italia og Tyskland Om IHE-profiler for IT-infrastruktur IHE har tradisjonelt vært forbundet først og fremst med radiologi og dernest med andre bildedannende undersøkelser. Det har imidlertid blitt klart at mange sentrale IHEprofiler berører forhold som er mer generelt anvendbare og som ikke bare berører radiologi og andre bildedannende undersøkelser. 6

7 Dette dokumentet gir en oversikt over eksisterende IHE-profiler for generell bruk i helsesektoren. Dokumentet er en kortfattet presentasjon på norsk av det tekniske rammeverket for IT infrastruktur. Dokumentet er ment å gi brukere, leverandører og andre interesserte en førstehånds oversikt over foreliggende IHE-profiler innenfor dette området og hvilke arbeidsoppgaver den enkelte profilen ivaretar. Dokumentet gir vanligvis ikke opplysninger om tekniske detaljer. Brukere og leverandører som ønsker å implementere konkrete IHE-profiler må benytte det originale tekniske rammeverket for IT infrastruktur som er fritt tilgjengelig fra sammen med eventuelle nasjonale tilpassinger. Det foreligger foreløpig ikke noen norske tilpassinger, men IHE-rammeverket er ikke uten videre anvendbart for norske forhold. Noen nasjonale forhold er kortfattet nevnt i dette dokumentet. 2. IHE-profiler innenfor IT infrastruktur Siste versjon av rammeverket for IT infrastruktur (pr ) er v2.0 Final Text av I tillegg er det publisert 56 endringsforslag for som skal inkluderes i teksten og som er tatt med i beskrivelsene nedenfor. Dette dokumentet beskriver følgende integrasjonsprofiler: 1. Retrieve Information for Display (RID) Fremhenting av opplysninger for presentasjon 2. Enterprise User Authentication (EUA) Autentisering av brukere innenfor et foretak 3. Patient Identifier Cross-referencing (PIX) Kryssidentifisering av pasienter 4. Patient Synchronized Applications (PSA) Desktopsynkronisering 5. Consistent Time (CT) Tidssynkronisering 6. Patient Demographics Query (PDQ) Bruk av sentralt pasientregister 7. Audit Trail and Node Authentication (ATNA) Etablering av en sikker node 8. Cross-Enterprise Document Sharing (XDS) Utveksling av dokumenter mellom foretak 9. Personnel White Pages (PWP) Helsetjenestepersonellregister Tillegg for for uttesting: 1. Document Digital Signature (DSG) Digital signering av dokumenter 2. Notification of Document Availebility (NAV) Varsling av tilgjengelig dokument 3. Patient Administration Management (PAM) Utveksling av pasientadministrative opplysninger Tillegg for for utprøving. 1. Cross-enterprise Document Media Interchange (XDM) 2. Cross-enterprise Document Reliable Interchange (XDR) 7

8 3. Cross-enterprise Sharing of Scanned Documents (XDS-SD) 4. Patient Identifier Cross-Reference and Patient Demographic Query HL7 V3 (PIX/PDQ V3) 5. Registry Stored Query Transaction for Cross-enterprise Document Sharing Profile 6. Retrieve Form for Data Capture (RFD) Tillegg for for kommentering (innen ): 1. White paper on Cross-enterprise User Authentication (XUA) Autentisering av brukere mellom foretak 2. White paper on Cross Community Information Exchange Including Federation of XDS Affinity Domains 3. White paper on Cookbook for the Security Section of IHE Profiles 2.1. Sammenheng mellom ulike IHE-profiler Figur 1 Sammenheng mellom de ulike IHE-profilene innenfor IT infrastruktur Figuren viser ikke profilene som er definert i senere tillegg. 8

9 Integration Profile Retrieve Information for Display Integration Enterprise User Authentication Patient Identifier Cross-referencing Patient Synchronized Applications Depends on Dependency Type Purpose None None - Consistent Time Consistent Time Each actor implementing EUA shall be grouped with the Time Client Actor Each actor implementing PIX shall be grouped with the Time Client Actor None None - Consistent Time None None - Patient Demographics Query Personnel White Pages Audit trail and Node Authentication Cross-Enterprise Document Sharing Notification of Document Availability Patient Administration Management None None - None None - Consistent Time Audit Trail and Node Authentication Cross Enterprise Document Sharing Each actor implementing ATNA shall be grouped with the Time Client Actor Each XDS Actor must be grouped with the Secure Node Actor. An XDS Actor must be grouped with the initiating NAV Notification Sender and the final NAV Notification Receiver. None None - Required to manage expirations of authentication tickets Required to manage and resolve conflicts in multiple updates. Required for consistent time in audit logs. Required to manage audit trail of exported PHI, node authentication and transport encryption. Required to initiate the first transaction, and to perform any useful work as a result. Cross Enterprise Document Media Interchange Audit Trail and Node Authentication Requires secure communication and audit trails. - Cross Enterprise Document Reliable Interchange Audit Trail and Node Authentication Requires secure communication and audit trails. - Retrieve Form for Data Capture Audit Trail and Node Authentication Aktører Aktører er informasjonssystem eller applikasjoner som genererer, håndterer eller reagerer på informasjon i forbindelse med operasjonelle aktiviteter. Aktørene er beskrevet i forbindelse med den enkelte integrasjonsprofil hvor de opptrer. 9

10 2.3. Bruk av de ulike aktørene i de enkelte integrasjonsprofilene Ikke beskrevet for IT infrastruktur Transaksjoner En transaksjon er en informasjonsutveksling mellom to aktører. Transaksjonene er beskrevet i forbindelse med den enkelte integrasjonsprofil hvor de opptrer Bruk av transaksjoner i ulike integrasjonsprofiler Ikke beskrevet for IT infrastruktur. 10

11 3. Beskrivelse av profilene for IT infrastruktur 3.1. Fremhenting av opplysninger for presentasjon (RID) Retrieve Information for Display Denne profilen definerer fremhenting av pasientopplysninger som finnes i et annet informasjonssystem enn brukerens aktuelle system, men hvor tilgang til opplysningene er vesentlige for bedre pasientbehandling (for eksempel tilgang til laboratorieresultater fra radiologisk avdeling). Profilen støtter tilgang til uforanderlige dokumenter i vanlige presentasjonsformater som PDF, JPEG, CDA (Level 1) osv. samt tilgang til spesifikke typer av dynamiske pasientopplysninger ved bruk av XHTML / web services. Profilen skiller mellom fremhenting av dokumenter og spesifikke pasientopplysninger. Slike spesifikke pasientopplysninger kan være av følgende typer: Fullstendig pasientsammendrag (Summary of All Reports) Sammendrag av laboratoriesvar (Summary of Laboratory Reports) Sammendrag av radiologisvar (Summary of Radiology Reports) Sammendrag av cardiologirapport (Summary of Cardiology Reports) Sammendrag av operasjonsbeskrivelser (Summary of Surgery Reports) Sammendrag av intensivjournal (Summary of Intensive Care Reports) Sammendrag av øyeblikkelig hjelp rapport (Summary of Emergency Reports) Sammendrag av epikriser (Summary of Discharge Reports) Sammendrag av medikamentordinasjoner (Summary of Prescriptions) CAVE-opplysninger (List of Allergies and Adverse Reactions) Medisinliste (List of Medications) Den viktigste forskjellen mellom de to transaksjonstypene er at et dokument antas å være entydig identifisert og uforanderlig over tid mens de spesifikke opplysningene er mer dynamiske og vil kunne endre seg over tid Merknader Listen over spesifikke pasientopplysninger synes ikke å være i samsvar med norske behov. De refererte standardene refererer kun til overføringsformatet Refererte standarder Benyttede standarder er HTTP, XML, WSDL og XHTML Aktører Denne profilen definerer følgende aktører: 11

12 Presentatør (Display): Et applikasjonssystem som ber om opplysninger og som presenterer disse opplysningene. Opplysningskilde (Information Source): Et applikasjonssystem som gir spesifikke opplysninger på forespørsel fra en presentatør aktør i et format som er klart for presentasjon Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-11: Hent opplysninger for presentasjon (Retrieve Specific Info for Display): Denne transaksjonen benyttes av en presentatør for å etterspørre opplysninger hos en opplysningskilde samt å overføre opplysningene tilbake til presentatøren. ITI-12: Hent dokument for presentasjon (Retrieve Document for Display): Denne transaksjonen benyttes av en presentatør for å etterspørre et konkret dokument hos en opplysningskilde samt å overføre dokumentet tilbake til presentatøren Informasjonsflyt 3.2. Autentisering av brukere innenfor et foretak (EUA) Enterprise User Authentication Denne profilen autentiserer brukere innenfor et foretak for tilgang til alle applikasjoner og utstyrsenheter innenfor et foretak med en enkelt brukeridentitet (Single Sign-On) Refererte standarder Løsningen er basert på Kerberos v5 og HL7 CCOW. 12

13 Merknader Verken CCOW eller Kerberos er foreløpig i utstrakt bruk i norsk helsevesen i dag, men Kerberos er implementert i senere utgaver av MS Windows Aktører Denne profilen definerer følgende aktører: Autentiseringsklient (Client Authentication Agent): Formidler autentiseringsopplysninger til Kerberos autentiseringsserver, mottar en tjenestetillatelse (TGT) 1 og ivaretar intern håndtering av tjenestetillatelser. Kerberos autentiseringsserver (Kerberos Authentication Server) 2 : Verifiserer autentiseringsopplysningene og utsteder tjenestetillatelse som sendes til autentiseringsklienten. Kontrollert server (Kerberized Server): Mottar og verifiserer tjenestetillatelsen. Formidler av brukerkontekst (Context Manager): Aktør som formidler opplysninger om brukerkontekst mellom brukere som har felles kontekst for sitt arbeide. Opplysninger kan gjelde både pålogget bruker og aktuell pasient. Brukerkontekstdeltaker (User Context Participant): Aktør som får opplysninger om endringer i brukerkontekst og gjør disse gjeldene for sitt applikasjonssystem Transaksjoner Transaksjonene i denne IHE-profilen er i samsvar med Kerberos v5 standarden og inneholder følgende transaksjoner: ITI-2: Hent brukerautentisering (Get User Authentication): Denne transaksjonen benyttes for å hente en brukeridentitet innenfor et foretak. ITI-3: ITI-4: ITI-5: ITI-6: Hent tjenestetillatelse (Get Service Ticket): Denne transaksjonen benyttes for å hente en tjenestetillatelse som autentiserer brukeren ovenfor en kontrollert server. Kontrollert kommunikasjon (Kerberized Communication): Kommunikasjon mellom en lokal klient og en kontrollert server. Start synkronisering (Join Context): Lar en applikasjon knytte seg til en konkret pasient. Endre brukerkontekst (Change Context): Lar en applikasjon knytte seg til en annen pasient. 1 TGT: Ticket Granting Ticket 2 Også betegnet Key Distribution Center (KDC) i RFC

14 ITI-7: ITI-13: Avslutt synkronisering (Leave Context): Lar en applikasjon frigjøre seg fra aktuelle pasient. Synkronisering (Follow Context): Tvinger en applikasjon til å følge aktuelle pasient Informasjonsflyt Figur 2 - Basic Process Flow in Enterprise User Authentication Profile 14

15 Figur 3 - Process Flow with User Synchronized Applications 3.3. Kryssidentifisering av pasienter (PIX) Patient Identifier Cross-referencing Denne profilen støtter kryss-referering av ulike pasientidentifikatorer som måtte være benyttet i ulike system. En bruker kan etterspørre ulike pasientidentifikatorer som den aktuelle pasienten måtte ha Refererte standarder Benyttet standard er HL7 v Merknader Denne integrasjonsprofilen synes å være mindre aktuell i Norge siden de fleste pasienter er identifisert ved bruk av fødselsnummer Aktører Denne profilen definerer følgende aktører: Pasientidentitetskilde (Patient Identity Source): Sentralt pasientregister eller annen kilde som vedlikeholder pasientidentifikasjonene. Pasientidentitetshåndterer (Patient Identifier Cross-reference Manager): Applikasjonssystem som vedlikeholde ulike identiteter for en person. 15

16 Pasientidentitetsbruker (Patient Identifier Cross-reference Consumer): Applikasjonssystem som benytter pasientidentitet for å sikre at opplysninger er registrert på riktig person Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-8: Demografiske pasientopplysninger (Patient Identity Feed): Denne transaksjonen overfører demografiske pasientopplysninger etter at en pasient er identifisert samt når identitet eller andre sentrale demografiske opplysninger er endret. ITI-9: ITI-10: Pasientidentitetsforespørsel (PIX Query): Forespørsel etter alternative pasientidentiteter for en gitt person. Varsel om oppdatert pasientidentitet (PIX Update Notification): Transaksjon for å varsle interesserte parter om at en pasients identifikatorer eller andre sentrale demografiske personopplysninger er endret Informasjonsflyt Figur 4 Flytdiagram ved kryssidentifisering av pasienter 16

17 3.4. Desktopsynkronisering (PSA) Patient Synchronized Applications Denne profilen sikrer at pasientidentitet beholdes ved overgang fra én pasientrettet applikasjon til en annen Refererte standarder Løsningen er basert på HL7 CCOW versjon Merknader Denne type funksjonalitet er høyst vanlig i applikasjoner som benyttes innenfor helsevesenet i Norge, men så vidt vites er løsningene vanligvis ikke basert på HL7 CCOW Aktører Denne profilen definerer følgende aktører: Formidler av brukerkontekst (Context Manager): Aktør som formidler opplysninger om brukerkontekst mellom brukere som har felles kontekst for sitt arbeide. Brukerkontekstdeltaker (Patient Context Participant): Aktør som får opplysninger om endringer i brukerkontekst og gjør disse gjeldene for sitt applikasjonssystem Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-5: Start synkronisering (Join Context): Lar en applikasjon knytte seg til en konkret pasient. ITI-6: ITI-7: Endre brukerkontekst (Change Context): Lar en applikasjon knytte seg til en annen pasient. Avslutt synkronisering (Leave Context): Lar en applikasjon frigjøre seg fra aktuelle pasient. 17

18 ITI-13: Synkronisering (Follow Context): Tvinger en applikasjon til å følge aktuelle pasient Informasjonsflyt 18

19 3.5. Tidssynkronisering (CT) Consistent Time Denne profilen definerer hvordan ulike system skal synkronisere sine klokker Refererte standarder Løsningen er basert på Network Time Protocol (NTP) fra RFC Aktører Denne profilen definerer følgende aktører: Tidserver (Time Server): Aktør som svarer på forespørsler om tid. Tidsklient (Time Client): Aktør som synkroniserer sin lokale klokke mot en tidsserver Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-1: Ajourfør klokke (Maintain Time): Klienten synkroniseres i tid mot en tidsserver Informasjonsflyt 3.6. Bruk av sentralt pasientregister (PDQ) Patient Demographics Query Denne profilen definere samhandling mellom en applikasjon og et sentralt personregister, eventuelt et register med opplysninger over tidligere pasientkontakter Refererte standarder Løsningen er basert på bruk av HL7 v

20 Merknad Det sentrale personregisteret kan være et (lokalt) folkeregister Aktører Denne profilen definerer følgende aktører: Aktør som etterspør pasientopplysninger (Patient Demographics Consumer): Aktør som har behov for pasientopplysninger Aktør som har pasientopplysninger (Patient Demographics Supplier): Aktør som svarer på forespørsler etter pasientopplysninger Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-21: Spørring etter pasientopplysninger (Patient Demographics Query): Forespørsel etter demografiske og evt. pasientadministrative opplysninger. Spørringen kan gjelde kun faste pasientopplysninger eller også opplysninger om opphold/besøk. ITI-22: Pasientopplysninger (Patient Demographics Response): Svar på forespørsel etter pasientopplysninger Informasjonsflyt 20

21 3.7. Etablering av en sikker node (ATNA) Audit Trail and Node Authentication Profilen beskriver et sett av sikkerhetskrav som sammen med foretakets sikkerhetsrutiner og andre interne rutiner skal ivareta behovene for konfidensialitet, data integritet og logging. Formålet med denne profilen er å håndtere: Logging Tilgangskontroll (ovenfor andre noder) Sentral katalog for logger Ivareta håndtering av sensitive pasientopplysninger De viktigste egenskapene er: Autentisering av brukere Logging Autentisering av en node ved datautveksling Autentisering ved tilkopling Profilen krever bruk av sertifikatbasert autentifisering av de kommuniserende partene for å kunne håndtere personsensitive opplysninger. Alternativt skal nettverket være fysisk sikret. Ved overføring av personsensitive opplysninger benyttes TLS både i forbindelse med DICOM, HL7 og HTTP Logging Det skal være mulig å logge hva som foregår og hvem som er involvert. Profilen angir bruk av RFC-3381 (Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications). Profilen angir bruk av RFC-3195 (Reliable Syslog Cooked Profile, Section 4) for overføring av log-recorder til en sentral katalog. 21

22 Refererte standarder DICOM 2003 PS 3.15: Security Profiles. Annex B1: The Basic TLS Secure Transport Connection profile. Transport Layer Security (TLS) 1.0 (RFC 2246) ITU-T Recommendation X.509 (03/00). Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks" The BSD Syslog Protocol. (RFC 3164); Reliable Delivery for Syslog (RFC 3195); Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881). DICOM Supplement 95 ASTM E Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems. Extensible Markup Language (XML) Aktører Denne profilen definerer følgende aktører: Sikker node (Secure Node): Identifiserer brukeren og autoriserer tilgang til pasientopplysninger og applikasjoner i noden. Sentral logg (Audit record Repository): Register over loggede aktiviter. 22

23 Bruker (User): Bruker som ønsker tilgang til opplysninger og applikasjoner hos noden Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-1: Ajourfør klokke (Maintain Time): Klienten synkroniseres i tid mot en tidsserver. ITI-19: ITI-20: Autentiser node (Authenticate Node): Den lokale og den fjerne noden autentiserer hverandre gjensidig og etablerer en sikker forbindelse. Logget aktivitet (Record Audit Event): En aktør utfører en aktivitet som gir opphav til en oppføring i den sentrale loggen Informasjonsflyt 3.8. Utveksling av dokumenter mellom foretak (XDS) Cross-Enterprise Document Sharing XDS beskriver hvordan opplysninger om en pasient kan gjøres tilgjengelig for andre autoriserte brukere (eller pasienten selv). XDS er i prinsippet et generelt konsept som kan håndtere enhver form for dokumenter, men en forutsetter at disse dokumentene er basert på vanlig forekommende standarder. XDS beskriver et XDS-område. Et slikt område kan være et geografisk område (for eksempel en helseregion), et sett av samarbeidende institusjoner eller et annet geografisk eller organisatorisk område. 23

24 Refererte standarder Løsningen baserer seg på følgende standarder: OASIS/ebXML Registry Information Model v2.0 (ebrim) OASIS/ebXML Registry Services Specifications v2.0 (ebrs) OASIS/ebXML Messaging Services Specifications v2.0 (ebms) HTTP HyperText Transfer Protocol v1.1 (IETF RFC2616) MIME Multipurpose Internet Message Extensions (RFC 2045 to RFC 2049) The MIME Multipart/Related Content-type (RFC2387) SMTP Simple Mail Transfer Protocol (RFC2821) HL7 Clinical Document Architecture (ANSI/HL7 CDA R1-2000) HL7 Version 2.5 ISO/IEC 9075 Database Language SQL Aktører XDS-profilen definerer følgende aktører: Dokumentbruker (Document Consumer): Et applikasjonssystem opptrer i denne rollen når det etterspør eksisterende dokumenter. Pasientidentifikasjonskilde (Patient Identity Source): Dette applikasjonssystemet sørger for at enhver pasient blir tildelt en entydig personidentifikator, for eksempel ved bruk av et lokalt, regionalt eller landsomfattende befolkningsregister. Dokumentarkiv (Document Repository): Denne aktøren lagrer de ulike dokumentene over tid og gjør dem tilgjengelig for uthenting ved forespørsler fra autoriserte brukere. Denne aktøren representerer sålede direkte eller indirekte de ulike databasene hvor slik informasjon oppbevares. Dokumentregister (Document Registry): Dokumentregisteret er en lokal eller regional database som inneholder opplysninger om alle arkiverte dokumenter i det XDS-området som dette dokumentregisteret betjener (metadata). Ett XDS-område betjenes alltid av kun ett dokumentregister Transaksjoner Denne IHE-profilen inneholder følgende transaksjoner: ITI-14: Registreringsmelding (Register Document Set): Denne meldingen benyttes for å sende opplysninger om nye dokumenter i et dokumentarkiv fra dette dokumentarkivet til et dokumentregister som dekker det aktuelle området. ITI-15: Lagringsmelding (Provide and Register Document Set): Denne meldingen benyttes for å sende relevante dokumenter fra en dokumentkilde til et dokumentarkiv. 24

25 ITI-16: ITI-17: ITI-8: Forespørselsmelding (Query Registry): Denne meldingen benyttes i en dialog mellom dokumentbruker og dokumentregisteret for å spørre etter dokumenter med bestemte egenskaper og å få svar på hvilke dokumenter som finnes samt hvor det enkelte dokument befinner seg. Hentemelding (Retrieve Document): Denne meldingen benyttes av en dokumentbruker for å få overført ett eller flere konkrete dokumenter fra et dokumentarkiv. En forespørsel med spesifikke dokumentidentifikatorer sendes fra en dokumentbruker til et konkret dokumentarkiv som er oppgitt å skulle ha de etterspurte dokumentene. Dokumentarkivet sender de etterspurte dokumenter tilbake til dokumentbrukeren. Demografiske pasientopplysninger (Patient Identity Feed): Denne meldingen benyttes i en dialog mellom dokumentregisteret og pasientidentitetskilden for å utveksle informasjon om benyttet pasientidentifikator Informasjonsflyt Patient Identity Source Patient Identity Feed Document Registry Query Documents Register Document Set Document Consumer Document Source Document Repository Retrieve Document Provide and Register Document Set Datastruktur Figur 5 - ebxml klassediagram tilsvarende XDS klasser av metadata 25

26 Merknader Figur 6 Datastruktur for XDS dokumentregister IHE-Norge har beskrevet denne profilen mer utførlig i et separat dokument Helsetjenestepersonellregister (PWP) Personnel White Pages Denne profilen definerer en katalog over helsetjenestearbeidere og bruken av denne. Profilen anviser hvor LDAP kan benyttes Refererte standarder: IETF RFC-2181 Clarifications to the DNS Specification IETF RFC-2219 Use of DNS Aliases for Network Services IETF RFC-2782 A DNS RR for specifying the location of services (DNS SRV) IETF RFC Definition of the inetorgperson LDAP Object Class IETF RFC 2829 Authentication Methods for LDAP IETF RFC 2830 LDAPv3: Extension for Transport Layer Security DICOM Supplement 67 Configuration Management, January 14, ISO/TS directory standard for healthcare identity management 26