Seminar achtergrond IHE en aansluiten verwijsindex Stichting Rijnmondnet

Transcriptie

1 Seminar achtergrond IHE en aansluiten verwijsindex Stichting Rijnmondnet Technische kennissessie Stichting RijnmondNet Rivium Westlaan LD Capelle aan den IJssel Tel: Fax: RijnmondNet is een Stichting die de zorg in de regio Rijnmond wil verbeteren. Dit doet zij door de communicatie tussen zorgleveranciers te faciliteren. RijnmondNet zorgt voor een beveiligde, gegarandeerde en gestandaardiseerde communicatie-omgeving. RijnmondNet is een Stichting en wordt mogelijk gemaakt door de zorgpartners in de regio Rijnmond.

2 Welkom Waarom deze sessie? Even voorstellen Vragen: ja graag! Mobieltjes stil Presentaties & documenten op

3 Agenda 9:00 Opening» Monique Mulder, Stichting Rijnmondnet 9:15 Introductie IHE» Vincent van Pelt, Nictiz 10:15 Belangrijkste IHE-profielen regio» Hans Mekenkamp, MedicalPHIT 11:45 Zorgportaal Rijnmond en XDS» Wijnand Weerdenburg, Zorgportaal Rijnmond 12:00 Demonstratie XDS Viewer» Sven Pippel, Forcare 12:30 Lunch 13:00 Aansluitdocument in de praktijk» Arne Freriks, Stichting RijnmondNet 13:20 Vragensessie, discussie» Hans Mekenkamp (en andere sprekers) 14:00 Afsluiting» Monique Mulder, Stichting Rijnmondnet

4 Introductie IHE Vincent van Pelt, Nictiz

5 IHE integrating the Healthcare Enterprise Vincent van Pelt, Nictiz

6 Introductie Mini-cv Nictiz Topicus isoft Programmeur / analist Adviseur informatievoorziening AMC Basisarts IHE-NL Lid stuurgroep Voorzitter werkgroep Patient Care Coordination Lid werkgroep Architectuur vanpelt@nictiz.nl IHE-international. Lid Technical Committee Patient Care Coordination Auteur IHE profiel XTB-WD en BSR-WD

7 IHE - initiatief Opgericht in 1997 door radiologen en software-leveranciers Sponsors: HIMSS, RSNA, ACC Samenwerking tussen eindgebruikers, leveranciers en architecten op basis van vrijwillige inspanning Doel: interoperabiliteitsprobleem oplossen: changing the way the healthcare connects Uitgangspunten: Standaardiseer alleen de transacties tussen systemen, niet de systemen zelf Maak gebruik van bestaande standaards en definieer het gebruik ervan Applicatie-onafhankelijk Zorg voor commitment Praktische Use Cases en probleemstelling Testen van de werking door middel van Connectathons Minstens 3 leveranciers testen onderling de interoperabiliteit Connectathon voorwaarde voor inzet IHE compliance

8 IHE wereldwijd IHE (International) Strategic Development Committee Regional Deployment IHE North America IHE Asia/Oceania Global Development active domains Canada USA China Korea Taiwan Japan Australia Radiology IT Infrastructure Laboratory Cardiology Patient Care Coordination Quality, Research Public Health France Germany IHE Europe Italy Netherlands Radiation Oncology Patient Care Devices Eye Care Norway Israel Spain Denmark UK Austria Suisse Turkey Belgium Professional Societies / Sponsors ACC ACP HIMSS RSNA GMSIH SFR SFIL Nictiz COCIR EAR-ECR DRG SIRM BIR EuroRec ESC JAHIS JIRA JRS METI-MLHW MEDIS-DC JAMI Contributing & Participating Vendors 8

9 IHE - werkwijze Beschrijf een (real world) interoperabiliteits Use Case Identificeer de Actoren en Transacties tussen systemen die bij het proces zijn betrokken Actoren: computersystemen / software Transacties: zenden en ontvangen van gegevens Standaardiseer de transacties tussen de systemen (de stekkers) Gebruik proven standards zoals HL7 CDA, SNOMED-CT, LOINC, ebxml, Oasis, etc., en definieer constraints om deze implementeerbaar te maken NB: Transacties bestaan uit twee processen: een request en een response Publiceeer het Profiel Document bestaat uit een algemeen, een technisch deel, en eventuele opties (localisatie bijzondere gevallen) Fasen: Public Comment, Trial implementation, Connectathon Profiel wordt opgenomen in het grote boek

10 IHE - werkwijze

11 IHE - domeinen Algemeen: ITI IT Infrastructure technische infrastructuur PCC Patient Care Coordination workflow and content QRPH Quality, Research an Public Health onderzoek, registraties PCD Patient Care Devices devices, sensoren Aandachtsgebieden: Pathologische anatomie Cardiologie Oogheelkunde Laboratorium Radiologie Radiotherapie

12 IHE - historie Pharmacy 2009 Radiology 1998 Cardiology 2004 Pathology 2006 Eye Care 2006 Quality Research & Public Health 2006 (Healthcare) IT Infrastructure since 2003 Laboratory 2004 Radiation Oncology 2004 Patient Care Devices 2005 Patient Care Coordination 2004

13 IHE profielen - ITI

14 IHE profielen - PCC

15 IHE profielen en nog veel meer

16 IHE - interoperabiliteit op meerdere niveaus Interoperabiliteitsniveaus Inzicht in het zorgproces Beschikbaarheid van relevante medische informatie Applicaties en Infrastructuur voor opslag en uitwisseling Beleid Zorgproces Informatie Applicaties Infrastructuur

17 IHE - interoperabiliteit op meerdere niveaus Interoperabiliteitsniveaus Beleid Inzicht in het zorgproces Zorgproces XDW Beschikbaarheid van relevante medische informatie Informatie IHE Content Modules Applicaties en Infrastructuur voor opslag en uitwisseling Applicaties Infrastructuur XDS

18 IHE toepassen in de praktijk Als leverancier Implementeer IHE Integratieprofielen Test systemen in Connectathons Stel testopstellingen via internet beschikbaar Publiceer Integratieverklaring van producten Als zorginstelling Gebruik IHE Integratieprofielen om een integratiestrategie te ontwikkelen Gebruik Connectathon resultaten en Integratieverklaringen om leveranciers te evalueren Eis IHE Integratieprofiel ondersteuning in RfP s

19 IHE waar te beginnen? Opslag, overzicht en delen van documenten: XDS Inter-regionale uitwisseling: XCA Standaardisatie van gegevens-bouwstenen: IHE Content Modules Uitwisselbare workflow: XDW

20 Antilope Use Cases decomposition Antilope Use Cases Radiology workflow Medication Medical Summary Sharing Patient Summaries Telehome monitoring Laboratory workflow Foundation Services Medical Board Review Make use of Data Entry Services Patient Data Entry Workflow Services Localization Services Document Services Terminology Services HCP Identification Services Access Control Services Patient Identification Services Cross-community Services Document Sharing Services Content-specific Services Make use of Profiles and IHE Continua Standards HL7 IHTSDO LOINC ISO IETF CEN

21 Antilope Use Cases high-level Foundation Services Antilope Use Cases Radiology workflow Medication Medical Summary Sharing Patient Summaries Telehome monitoring Laboratory workflow Foundation Service Groups Medical Board Review Make use of Data Entry Services Patient Data Entry Workflow Services Localization Services Document Services Terminology Services HCP Identification Services Access Control Services Patient Identification Services Cross-community Services Document Sharing Services Content-specific Services Make use of Profiles and IHE Continua Standards HL7 IHTSDO LOINC ISO IETF CEN

22 Foundation Services Data Entry Services Workflow Services Localization Services Document Services Terminology Services HCP Identification Services Access Control Services Patient Identification Services Cross-community Services Inter-community Services Content-specific Services

23 Mapping IHE Profiles to Foundation Services Data Entry Services RFD Form Data Capture DEC Device Enterprise Comm. CHA HRN, LAN/PAN Workflow Services XDW Workflow Tracking DSUB Document Notification Localization Services Calendar and Scheduling Free Text Translation Document Services DEN Document Encryption DSG Document Signature Terminology Services SVS Shared Value Sets RTM Rosetta Terminol. Mapping HCP Identification Services HPD HCP Discovery XUA HCP Authentication Access Control Services XUA++ Rights and Authorization BPPC Patient Consent Patient Identification Services PIX/PDQ Patient Discovery XUA Patient Authentication PAM Patient Administr. Mgt Cross-community Services Inter-community Services Content-specific Services XCA Cross-community Access XDS, XD.. Document Sharing XTB-WD XPHR ATNA Audit Trailing & NA XBeR-WD BSR-WD CT Consistent Time CPMD XD-LAB

24 Use Case A: Sharing of Medical Summary Data Entry Services RFD Form Data Capture DEC Device Enterprise Comm. CHA HRN, LAN/PAN Workflow Services XDW Workflow Tracking DSUB Document Notification Localization Services Calendar and Scheduling Free Text Translation Document Services DEN Document Encryption DSG Document Signature Terminology Services SVS Shared Value Sets RTM Rosetta Terminol. Mapping HCP Identification Services HPD HCP Discovery XUA HCP Authentication Access Control Services XUA++ Rights and Authorization BPPC Patient Consent Patient Identification Services PIX/PDQ Patient Discovery XUA Patient Authentication PAM Patient Administr. Mgt Cross-community Services Inter-community Services Content-specific Services XCA Cross-community Access XDS Document Sharing PRE XPHR ATNA Audit Trailing & NA XBeR-WD XDS-MS CT Consistent Time CPMD XD-LAB

25 Use Case B: Patient Telehome Monitoring Data Entry Services RFD Form Data Capture DEC Device Enterprise Comm. CHA HRN, LAN/PAN Workflow Services XDW Workflow Tracking DSUB Document Notification Localization Services Calendar and Scheduling Free Text Translation Document Services DEN Document Encryption DSG Document Signature Terminology Services SVS Shared Value Sets RTM Rosetta Terminol. Mapping HCP Identification Services HPD HCP Discovery XUA HCP Authentication Access Control Services XUA++ Rights and Authorization BPPC Patient Consent Patient Identification Services PIX/PDQ Patient Discovery XUA Patient Authentication PAM Patient Administr. Mgt Cross-community Services Inter-community Services Content-specific Services XCA Cross-community Access XDS Document Sharing PRE XPHR ATNA Audit Trailing & NA XBeR-WD XDS-MS CT Consistent Time CPMD XD-LAB

26 Vragen? Beleid Zorgproces Informatie Applicaties Infrastructuur

28 IHE profielen voor Stichting RijnmondNet Hans Mekenkamp, MedicalPHIT

29 29 IHE Academy

30 30

31 31 Cursusdata

32 32 Introductie Medical Phit

33 Onderwerpen ITI Domain XDS What is XDS? XDS affinity domains Use cases Actors & Transactions Document content types XCA

34 IT-I Domain (Version 9) Integration Profiles Overview

35 IT-I Domain (Version 9) Integration Profiles Overview XDS-SD Cross-enterprise Document Sharing of Scanned Documents BPPC Basic Patient Privacy Consent XDM Cross-enterprise Document Media Exchange XDS XUA Cross-enterprise User Assertion ATNA

36 36

37 IT-I Domain Integration Profiles Overview Cross-Enterprise Sharing of Documents (XDS) Sharing clinical documents between healthcare IT systems Depends on ATNA and CT Patient Information Cross-Referencing (PIX) Mapping multiple patient identities to the same patient Intra- and cross-enterprise use-case Patient Demographics Query (PDQ) Exchange patient and visit information between information systems

38 IT-I Domain Integration Profiles Overview Audit Trail and Node Authentication (ATNA) Providing/exchanging system identities Defining secure nodes and secure applications Defining encrypted information exchange Consistent Time (CT) Synchronized computer clocks

39 IT-I Domain Integration Profiles Overview Retrieve Information for Display (RID) Defining simple way for information discovery Exchange of information in presentation format CDA, PDF, JPG Patient Synchronized Applications (PSA) Desktop synchronization of application (HL7 CCOW) Maintaining user and patient context across applications Enterprise User Authentication (EUA) Providing ways to exchange user names and logon information Key to single sign on functionality

40 IT-I Domain Integration Profiles Overview Basic Patient Privacy Consent (BPPC) Capture patient consent electronically Exchange patient consent between XIS Cross-enterprise Document Media Exchange (XDM) off-line exchange of document using media Cross-enterprise User Assertion (XUA) Exchange of user identities between XIS connected in an XDS infrastructure (UZI-pas nummer)

41 XDS: Cross-enterprise document sharing

42 What is XDS? Cross-Enterprise Document Sharing (XDS) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records It provides a standards-based specification for managing the sharing of documents between any healthcare enterprise

43 XDS Affinity Domains Group of healthcare enterprises that have agreed to work together using a common set of policies and XDS-based infrastructures for sharing patient clinical documents. Some examples are: Regional community of care Nationwide EHR Specialized or disease-oriented (cardio, diabetes, oncology) Insurance provider supported communities Aansluitdocument AD XDS profile is designed to accommodate a wide range of policies on: Patient identification and consent Controlling access to information Format, content, structure, and representation of clinical information

44 Use Cases Patient Care Summary (e.g. within a region) Publishing of Care Summaries by providers Access to patient s Care Summary in an emergency ereferral between primary and secondary care providers Sharing of radiology reports and images between facilities Sharing of laboratory reports by clinical laboratories with ordering physicians and other care providers epharmacy between community pharmacy and ambulatory physicians

45 XDS Flow and interactions XDS Document (Metadata): Class Patient Id Author Facility Date of Service Source of Documents 2. Repository registers the documents metadata and pointer with the Registry 1. Sources post document packages to the Repository Registry Repository 3. Consumers search for documents with specific information 4. Consumers retrieve selected documents from Repository (-ies) Consumer

46 XDS Actors and Transactions Patient Identity Source Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 [ITI-44] Registry Stored Query [ITI-18] Document Registry Document Consumer Register Document Set-b [ITI-42] Document Source Provide&Register Document Set-b [ITI-41] Integrated Document Source/Repository Document Repository Retrieve Document Set [ITI-43]

47 XDS Document content types XDS profile is content agnostic it can be used with a variety of document types, including: XDS-SD: Scanned document, plain text or PDF/A, in HL7 CDA R2 format XDS-MS: Medical summary in HL7 CDA format XDS-I: Radiology report in plain text of PDF format, or reference to a collection of DICOM SOP Instances in a manifest document in the DICOM Key Object Selection format CCR/CCD Also supported are many other document content profiles specified by the IHE Patient Care Coordination, Laboratory, Cardiology, Pharmacy Technical Frameworks

48 XDS: Actors and Options Actors Options Reference Document Source Document Repository Document Registry Patient Identity Source Document Consumer Document Replacement ITI TF-1: Document Addendum ITI TF-1: Document Transformation ITI TF-1: Folder Management ITI TF-1: Basic Patient Privacy Enforcement ITI TF-2b: Patient Identity Feed ITI TF-2a: 3.8 Patient Identity Feed HL7v3 ITI TF-2b: 3.44 Basic Patient Privacy Enforcement ITI TF-2a: ITI TF-2b: Basic Patient Privacy Proof ITI TF-2a:

49 XDS Standards used Business standards ebxml, SOAP, MTOM WWW standaarden Internet standards HTML, ISO, PDF, JPEG, HTTP(S) Healthcare standards HL7 CDA, DICOM, CEN EHR, ASTM CCR

50 XDS Document Entry Metadata Document Author Available Status Service Start and Stop Time Document Creation Time Legal Authenticator Title, comments Identifiers Kind of Document Event Code Healthcare Facility Type Practice Setting Type Confidentiality Code Technical Details Patient Demographics Person, role, specialty (Available, Deprecated) Start and end time of clinical encounter Date/time document was (originally) created Author that approved the document Free text Patient ID, Unique ID, entryuuid Class Code (e.g Prescription, Discharge Summary, Report), Type Code (more detail) Main clinical event (e.g. colonoscopy, appendectomy) Healthcare Facility Type Code and Display Name Practice Setting Code and Display Name e.g. VIP, Restricted Access, etc. MIME Type; Format Code (e.g. CDA); Size; Hash; URI; Language Original patient demographics

51 XDS Document Entry Metadata Document Author Available Status Service Start and Stop Time Document Creation Time Legal Authenticator Title, comments Identifiers Kind of Document Event Code Healthcare Facility Type Practice Setting Type Confidentiality Code Technical Details Patient Demographics Person, role, specialty (Available, Deprecated) Start and end time of clinical encounter Date/time document was (originally) created Author that approved the document Free text Patient ID, Unique ID, entryuuid Class Code (e.g Prescription, Discharge Summary, Report), Type Code (more detail) Main clinical event (e.g. colonoscopy, appendectomy) Healthcare Facility Type Code and Display Name Practice Setting Code and Display Name e.g. VIP, Restricted Access, etc. MIME Type; Format Code (e.g. CDA); Size; Hash; URI; Language Original patient demographics

52 1. Probleem Op zichzelf staande ontwikkelingen leiden tot volgende communicatie problemen: Documenten worden niet gevonden Informatie is niet begrijpbaar Documenten zijn niet te herleiden naar beroepsgroepen

53 2. Voorbeeld Documenten worden niet gevonden Echo onderbuik US Abdomen XDS

54 Voorbeeld Informatie is niet begrijpbaar Lokaal patiëntnummer Poortnummer Omschrijving

55 Voorbeeld Documenten zijn niet te herleiden naar beroepsgroep Elk document behoort toe aan de radiologie afdeling?

56 3. Oplossing Meta dataset Standaard gebruiken om ontwikkelingen te versnellen Gebaseerd op internationale afspraken Nederlandse situatie (samenwerking IHE, NICTIZ, NVvR) Flexibel voor alle medische domeinen

57 Dataset voor XDS metadata

58 Modaliteiten

59 Rolcode

60 Security and Privacy considerations within XDS All actors be grouped with a ATNA Secure Node Actor or Secure Application Actor resulting in each node (systems supporting XDS actors) of the XDS Affinity Domain should have audit and security mechanisms in place Transactions between different secure nodes that use ATNA are encrypted Each XDS Transaction will result in an audit event record sent to an ATNA Audit Record Repository Actor from each XDS actor Timestamp consistency is provided by Consistent Time (CT) profile

61 IHE XDS-I Images and Image Reports

62 XDS-I sharing images and reports Increasing need for sharing between PACS systems Patient Mobility Specialization; Imaging Centers Improve situation with CD exchange High percentage of PACS in hospitals build on existing infrastructure Images are (by volume) largest data prevent duplication

63 XDS-I Scope of Information Imaging Information includes extensive sets of DICOM instances including images, evidence documents and presentation states diagnostic reports provided in a "for display" form (PDF) selection of diagnostically significant images associated with the report content

64 XDS-I - Outline Like XDS but based on: DICOM (data format) WADO or native DICOM (retrieval mechanisms) Uses the same registry A submission set is a DICOM Key Object Selection (manifest) object May include representative sub-sets Use of WADO permits retrieval either as JPEGs for simpler browsers or full DICOM images Slide: David Harvey, IHE UK

65 XDS-I Actors/Transactions Patient Identity Source Imaging Document Source Provide & Register Imaging Doc Set Patient Identity Feed Document Registry Document Repository Register Document Set Query Registry Retrieve Document Document Consumer Document Consumer Imaging Document Consumer Retrieve Imgs, SRs ((DICOM C- MOVE) WADO Retrieve Webservices Retrieve

66 XDS-I Metadata Radiology specific requirements Acquisition Modality (e.g. CT, MR) Anatomic Region (e.g. Arm, Elbow, Hand) Requested procedure (e.g. MRI Knee with contrast) Query example find all CT of the Head of patient John Doe for the last 2 years

67 BSN in DICOM

68 XCA Cross Community Acces

69 XCA Introduction The Cross-Community Access (XCA) profile supports: the means to query and retrieve patient relevant medical data held by other communities. Guiding principles and scope: Sharing of documents across communities Re-use of XDS.b transactions. Document Consumer consistency Requirements of Document Consumer are the same as for local document query and retrieval Out of scope: How to identify which communities to interact with How to identify the patient id to use when interacting XCPD supplies solutions to both of the above

70 XCA use cases Multiple primary residences patients sometimes maintain more than one primary residence and may get care in more than one community. To delivery quality care the communities will need to exchange data about this type of patient. Patient Move patients move from one community to another and healthcare data needs to be exchanged. Vacationer patients travel away from their primary location for vacation and business reasons. Care may be necessary in another community and healthcare data must be exchanged to facilitate that care.

71 XCA Actors and transactions Document Registry Document Repository Initiating Community Document Consumer Registry Stored Query Registry Stored Query Retrieve Document Set Retrieve Document Set Initiating Gateway Cross Gateway Query Cross Gateway Retrieve Responding Community Registry Stored Query Responding Gateway Retrieve Document Set Document Registry Document Repository

72 XCA in a picture Responding Gateway B Registry B Consumer Consumer XDS Domain A XCA Repository Repository Repository Source Source Consumer Consumer Consumer Registry A Initiating Gateway A XDS Domain B Source Source Source Repository Repository Repository Introductie MedicalPHIT

73 XCA in a picture Responding Gateway B XDS Domain Amsterdam XCA Initiating Gateway A XDS Domain Rotterdam 73 Introductie MedicalPHIT

74 XCA The bigger picture

75 XCA: set-up for multiple XDS Affinity domains Responding Gateway Doc. Consmer Responding Gateway Doc. Consmer Initiating Gateway Responding Gateway Initiating Gateway Responding Gateway Local Registry Responding Gateway Local Registry Responding Gateway

76 Bovenregionale onderwerpen Waarom uitwisseling van informatie (beelden) tussen affinity domeinen? geografische scheiding functionele scheiding Beelduitwisseling Affinity domein affinity domein Wat is de use case Wat is het bijbehorende proces? Wie zijn de actoren? Wat moet je daarvoor regelen? Thema s waarvoor het wenselijk kan zijn om gezamenlijke oplossingen te kiezen om uitwisseling tussen domeinen mogelijk te maken het wiel niet elke keer opnieuw uit te vinden kennis en capaciteit te delen het voor de patiënt vriendelijker te maken te voldoen aan eisen voor privacy & security Thema s Patient consent Autorisatie Identificatie & authenticatie Rollen Privacy & security Logging Vertrouwensmodel Wat houdt het in? Waarom zou je er wat voor regelen? Wat kun je er voor regelen?

77 Keuze voor model 79

78 Keuze voor model 80

79 Thema s cross-affinity domein Technisch afspraken Vertrouwensmodel Metadataset, semantiek Patient consent Identificatie & authenticatie Rollen Incl. RBAC Autorisatie Logging Deze thema s hebben met uitwisseling tussen affinity domeinen te maken, maar zijn meestal ook relevant binnen een affinity domein Ze staan relatief willekeurig gegroepeerd Bepaalde thema s hebben een sterke relatie met andere thema s In hoeverre voor deze thema s afspraken / standaarden / profielen beschikbaar moeten komen is vooral afhankelijk van de vraag uit het veld

80 Metadataset en semantiek Noodzakelijk voor uitwisseling Binnen affinity domeinen Tussen affinity domeinen (nog niet beschikbaar) Metadataset XDS en semantiek Zie Handleiding bij Dataset XDS Via Uniforme codering van onderzoeken Work in progress Uitbreiding naar andere domeinen dan radiologie Work in progress Moet binnen domeinen geregeld worden maar wordt zo geregeld dat het voor NL ok is

81 Identificatie en authenticatie Onderdeel van het vertrouwensmodel Voor cross affinity domein uitwisseling is het handig om dit landelijk af te stemmen Middelen Patiënt - BSN Zorgverlener UZI Zorginstelling HL7 OID Affinity Domain HL7 OID? XUA++

82 Autorisatie Is een hele complexe materie Staat nog in de kinderschoenen Belangrijk concept: Role Based Access (RBAC) Hoe kunnen we dat regelen? Authenticatie moet geregeld zijn (UZI pas) XUA ondersteunen (gegevens meegeven) Check op de toestemmingsregels in de registry (BPPC regels)

83 85 National solution???

84 ATNA Audit Trail and Node Authentification

85 ATNA - Purpose Purpose of ATNA is twofold: 1. Node to node authentication : Host authentication as a basis for access controls 2. Centralized privacy audit trail: Secure node is responsible for secure audit logging 87

86 ATNA - Integrating Trusted Nodes Local access control (authentication of user,) Strong authentication of remote node (digital certificates) network traffic encryption is not required, it is optional Audit trail with: Real-time access Time synchronization Secured System Secure network Secured System System A System B Central Audit Trail Repository

87 XUA Cross-Enterprise User Assertion 89

88 XUA: Value Proposition Extend User Identity to Affinity Domain Users include Providers, Patients, Clerical, etc Must supports cross-enterprise transactions, can be used inside enterprise Distributed or Centralized Identity management (Directories) Provide information necessary so that receiving actors can make Access Control decisions Authentication mechanism used Attributes about the user (roles) Does not include Access Control mechanism 90

89 Standards Used WS-I Basic Security Profile 1.1 SAML 2.0 Token Profile and the various profiles from W3C, and OASIS to support identity federation Does not constrain how the Assertion was obtained If XUA is used compliant IHE Web-Services transactions will additionally use the Web- Services Security header with a SAML 2.0 Token containing the identity Assertion. 91

90 ITI-40 Provide X-User Assertions 92

91 XUA++ Attribute Extension Proposal,

92 Purpose: Enable Access Control This supplement extends the Cross- Enterprise User Assertion (XUA) profile with Options that will enable access controls on the service side. Note: the current XUA profile allows attributes but does not require any specific attributes beyond the user identity that is used for audit logging. 94

93 Actors, new Options Subject-Role: RBAC Consent/Authorization evidence As known by requester, meant to enable the transaction Purpose of Use Care provision, research, population health,.. 95

94 Additional Standard Used XSPA-SAMLv1.0 OASIS Standard, Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of the Security Assertion Markup Language (SAML) for Healthcare v1.0, November

95 IHE BPPC Basic Patient Privacy Consent (XDS Content Profile)

96 BPPC: Purpose The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Mark documents published to XDS (within an affinity domain) with the patient privacy consent that was used to authorize the publication, Enforce the privacy consent appropriate to the use.

97 BPPC: Essentials an Affinity Domain can develop privacy policies, and implement them with role-based or other access control mechanisms supported by EHR systems. A patient can Be made aware of an institutions privacy policies. Have an opportunity to selectively control access to their healthcare information.

98 Actors and Transactions BPPC

99 Workflow: Capturing Patient Store human readable consent as a CDA R2 document in the XDS Repository. Identifies the specific policy or policies. Scanned document option. Digital signature of patient can be associated with the consent document by means of a Signs association. Consent

100 Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Mark documents published to XDS/XDR/XDM with the patient privacy consent(s) that was used to authorize the publication, Enforce the

101 Verklarende woordenlijst

102 Richtlijn Nictiz

103

104 Onmogelijkheden BPPC 1. Patiënt identificeert individuele zorgverleners die toestemming krijgen. 2. Patiënt identificeert individuele zorgverleners die uitgesloten worden. 3. Elke opvraging van een document wordt geautoriseerd door de patiënt 4. Een document met een mix van meer of minder sensitieve informatie, dus het hebben van meerdere beveiligingsniveaus. 5. Notificatie aan de zorgverleners die een document gebruiken om het consent te herroepen. 6. Terugtrekken van documenten die gebruikt zijn waarbij in een later stadium het consent is herroepen. (Het betekent feitelijk dat je niet kunt wissen uit geheugen van mensen of machines als er ooit inzage is geweest).

105 BPPC policies Richtlijn document BPPC binnen XDS-netwerken Nr OID Omschrijving BPPC-policies BPPC-policy 1: "Uitdrukkelijk toestemming voor het affinity domain" BPPC-policy 1: "Uitdrukkelijk toestemming voor het affinity domain" Bevolkingsonderzoek Borstkanker Nederland BPPC-policy 1: "Uitdrukkelijk toestemming voor het affinity domain" EZDA Amsterdam BPPC-policy 2: "Uitdrukkelijk toestemming voor Nederland" BPPC-policy 3: "Breaking glass voor noodsituaties" BPPC-policy 4: "Generiek bezwaar"

106 Policies BPPC EZDA Policy Omschrijving I. Uitdrukkelijk toestemming voor het Affinity Domain (hier EZDA) II. Uitdrukkelijke toestemming voor Nederland III. Break glass (noodsituaties) IV. Patiënt geeft toestemming voor beschikbaarheid van de medische gegeven binnen de andere gespecificeerde instelling V. Patiënt schermt gevoelige informatie af voor gebruik VI. Patiënt geeft toestemming voor inzage, afhankelijk van de rolcode van de opvrager VII. Patiënt geeft toestemming voor inzage medische gegevens mits dit binnen de door de patiënt aangegeven tijd plaatsvindt VIII. Generiek bezwaar

107 Consent afspraken Sleutelnet Per patiënt één consent Er is één brondossierhouder Aan het consent wordt een periode (ingangsdatum/ einddatum) meegegeven De policy levels zijn: Sleutelnet Nederland Break-the-glass Geen fysieke handtekening vereist, checkbox

108 Uitgangspunten De te maken policies moeten ondersteund worden door XDS-Metadata. Toestemming patiënt moet ten allen tijden vooraf aan de publicatie van documenten. BPPC is basis en nog niet uitontwikkeld. Check van patiënt toestemming ligt bij de consumer, bij het systeem van de opvrager dus. Elke affinity domain heeft een generiek policy document

109 Affinity Domain Stichting Rijnmondnet Time serve r ITI-1: Maintain time ITI-20: Record audit event XCA Audit Repository Registry ITI-1: Maintain time ITI-42: Register Document Set-b ITI-18: Registry Stored Query Repository ITI-41: Provide and Register Document Set-b BPPC: share content Consumer ITI-43:Retrieve Document Set ITI-19: Authenticate Node ITI-40: Provide X-User Assertion Repository Consumer Source XDSi-b (Imaging document source & consumer): RAD-68: Provide and Register Imaging Document Set RAD-16: Retrieve Images RAD-17: Retrieve Presentation States RAD-27: Retrieve Reports RAD-31: Retrieve Key Image Note RAD-45: Retrieve Evidence Documents RAD-55: WADO Retrieve RAD-69: Retrieve Imaging Document Set Source Ziekenhuis 1 Ziekenhuis 2

110

112 Zorgportaal Rijnmond en XDS Wijnand Weerdenburg

113 Wat staat er nu

114 Programma ZPR 2013 Programma Zorgportaal Rijnmond Project Zorgportaal Rijnmond 2013 Project Ouderen langer thuis (AAL) Secure Instandhouding ZPR Medicatieoverzicht Labuitslagen Beelden Documenten ReAAL TAMBOERIJN Generieke viewer 2013: Jaar van de concreetheid

115 TAMBOERIJN

116 Zorgportaal Rijnmond: TAMBOERIJN Doel: Beeldverbinding in de zorg gebruiken Hardware Cursus Infrastructuur Partijen Lelie Zorggroep Sonneburgh Gemeente Rotterdam Stichting RijnmondNet/Zorgportaal Rijnmond

118 ReAAL: introductie EU project met focus op efficiënte zorg Gebruik makend van AAL toepassingen AAL: Ambient Assisted Living > langer zelfstandig thuis wonen Ehealth Telemedicine Telehealth Domotica Zorg op Afstand Beeldverbinding Let s make it ReAAL!

119 ReAAL: algemene doelstelling 7000 gebruikers verdeeld over 7 landen Gebaseerd op universaal platform Looptijd van 36 maanden vanaf januari 2013 tot 2016 Algemeen: bouwen van ecosysteem voor AAL toepassingen om vendor lock-in te voorkomen

120 ReAAL: algemene doelstelling

121 ReAAL: ZPR doelstellingen Ontsluiten van 1700 gebruikers Gebruikers zijn verdeeld over verschillende toepassingen (hoe en welke verdeling is niet vastgesteld) Evaluatie over de 7 landen door Erasmus Universiteit Rotterdam De volgende toepassingen zijn geselecteerd voor Nederland:

122 ReAAL: Toepassingen NetMedical: monitoring gezondheid in thuissituatie: Bloeddruk Bloed glucose Gewicht

123 ReAAL: Toepassingen MindDistrict: Helpen/preventie van specifieke problematiek Beter slapen Depressie Alcoholisme

124 ReAAL: Toepassingen Almende: Veilig leven mbv de smartphone Algemeen gevoel van welzijn Gebruik van 30 sensoren in smartphone Alcohol/depressie 126

125 ReAAL: Toepassingen Curavista: Monitoring van (chronische) ziekten in de thuissituatie met behulp van dagboeken, bijvoorbeeld: Pijn bij kanker Alzheimer Diabetes

126 ReAAL: Toepassingen MiBida: Interactie met ouderen Screen to screen communicatie 128

127 ReAAL: Toepassingen Kwa+ch: Gezondheidsmanagement met smart watch technologie Medicatie management met intelligente horloges