Seminar achtergrond IHE - 19 juli 2013

1,029 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,029
On SlideShare
0
From Embeds
0
Number of Embeds
251
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Seminar achtergrond IHE - 19 juli 2013

  1. 1. Seminar achtergrond IHE en aansluiten verwijsindex Stichting Rijnmondnet Technische kennissessie Stichting RijnmondNet • Rivium Westlaan 13 • 2909 LD Capelle aan den IJssel • Tel: 088-2820010 • Fax: 088-2820099 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. 2. Welkom • Waarom deze sessie? • Even voorstellen… • Vragen: ja graag! • Mobieltjes stil • Presentaties & documenten op www.rijnmondnet.nl
  3. 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. 4. Introductie IHE Vincent van Pelt, Nictiz
  5. 5. IHE – integrating the Healthcare Enterprise Vincent van Pelt, Nictiz
  6. 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 IHE-international. • Lid Technical Committee Patient Care Coordination • Auteur IHE profiel XTB-WD en BSR-WD vanpelt@nictiz.nl
  7. 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. 8. 8 IHE wereldwijd ACC ACP HIMSS RSNA JAHIS JIRA JRS METI-MLHW MEDIS-DC JAMI GMSIH SFR SFIL Nictiz SIRM BIR EuroRec COCIR EAR-ECR DRG ESC Professional Societies / Sponsors Contributing & Participating Vendors IHE (International) Strategic Development Committee Global Development active domains Radiology Cardiology IT Infrastructure Patient Care Coordination Patient Care Devices Laboratory Quality, Research Public Health Eye CareRadiation Oncology IHE Europe IHE North America France USA Canada IHE Asia/Oceania Japan Australia Netherlands Turkey Denmark UK ItalyGermany Israel Regional Deployment China Taiwan Norway Spain Austria Suisse Korea Belgium
  9. 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. 10. IHE - werkwijze
  11. 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. 12. IHE - historie Pathology 2006 Radiation Oncology 2004 Radiology 1998 Cardiology 2004 Patient Care Devices 2005 Patient Care Coordination 2004 Eye Care 2006 Quality Research & Public Health 2006 Laboratory 2004 (Healthcare) IT Infrastructure since 2003 Pharmacy 2009
  13. 13. IHE profielen - ITI
  14. 14. IHE profielen - PCC
  15. 15. IHE profielen – en nog veel meer
  16. 16. IHE - interoperabiliteit op meerdere niveaus  Inzicht in het zorgproces  Beschikbaarheid van relevante medische informatie  Applicaties en Infrastructuur voor opslag en uitwisseling Zorgproces Beleid Informatie Applicaties Infrastructuur Interoperabiliteitsniveaus
  17. 17.  Inzicht in het zorgproces  Beschikbaarheid van relevante medische informatie  Applicaties en Infrastructuur voor opslag en uitwisseling Zorgproces Beleid Informatie Applicaties Infrastructuur Interoperabiliteitsniveaus XDW IHE Content Modules XDS IHE - interoperabiliteit op meerdere niveaus
  18. 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. 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. 20. Foundation Services Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Antilope Use Cases Cross-community Services Document Sharing Services Medication Radiology workflow Laboratory workflow Patient Summaries Medical Summary Sharing Patient Data EntryMedical Board Review Content-specific Services Telehome monitoring Make use of Antilope Use Cases decomposition Make use of IHE Continua HL7 IHTSDO LOINC CENIETF Profiles and Standards ISO …
  21. 21. Foundation Service Groups Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Antilope Use Cases Cross-community Services Document Sharing Services Medication Radiology workflow Laboratory workflow Patient Summaries Medical Summary Sharing Patient Data EntryMedical Board Review Content-specific Services Telehome monitoring Make use of Antilope Use Cases high-level Foundation Services Make use of IHE Continua HL7 IHTSDO LOINC CENIETF Profiles and Standards ISO …
  22. 22. Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Cross-community Services Inter-community Services Content-specific Services Foundation Services
  23. 23. Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Cross-community Services Inter-community Services Content-specific Services Mapping IHE Profiles to Foundation Services SVS Shared Value Sets XUA HCP Authentication BPPC Patient Consent ATNA Audit Trailing & NA XUA Patient Authentication PIX/PDQ Patient Discovery RFD Form Data Capture XDS, XD.. Document Sharing DEN Document Encryption DSG Document Signature HPD HCP Discovery XCA Cross-community Access Calendar and Scheduling Free Text Translation XUA++ Rights and Authorization DSUB Document Notification XDW Workflow Tracking XTB-WD XBeR-WD XPHR BSR-WD CT Consistent Time CPMD XD-LAB PAM Patient Administr. Mgt CHA HRN, LAN/PAN RTM Rosetta Terminol. Mapping DEC Device Enterprise Comm.
  24. 24. Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Cross-community Services Inter-community Services Content-specific Services Use Case A: Sharing of Medical Summary SVS Shared Value Sets XUA HCP Authentication BPPC Patient Consent ATNA Audit Trailing & NA XUA Patient Authentication PIX/PDQ Patient Discovery RFD Form Data Capture XDS Document Sharing DEN Document Encryption DSG Document Signature HPD HCP Discovery XCA Cross-community Access Calendar and Scheduling Free Text Translation XUA++ Rights and Authorization DSUB Document Notification XDW Workflow Tracking PRE XBeR-WD XPHR XDS-MS CT Consistent Time CPMD XD-LAB PAM Patient Administr. Mgt RTM Rosetta Terminol. Mapping CHA HRN, LAN/PAN DEC Device Enterprise Comm.
  25. 25. Workflow Services Patient Identification Services Data Entry Services Terminology Services Access Control Services Document ServicesLocalization Services HCP Identification Services Cross-community Services Inter-community Services Content-specific Services Use Case B: Patient Telehome Monitoring SVS Shared Value Sets XUA HCP Authentication BPPC Patient Consent ATNA Audit Trailing & NA XUA Patient Authentication PIX/PDQ Patient Discovery RFD Form Data Capture XDS Document Sharing DEN Document Encryption DSG Document Signature HPD HCP Discovery XCA Cross-community Access Calendar and Scheduling Free Text Translation XUA++ Rights and Authorization DSUB Document Notification XDW Workflow Tracking PRE XBeR-WD XPHR XDS-MS CT Consistent Time CPMD XD-LAB PAM Patient Administr. Mgt RTM Rosetta Terminol. Mapping CHA HRN, LAN/PAN DEC Device Enterprise Comm.
  26. 26. Zorgproces Beleid Informatie Applicaties Infrastructuur Vragen?
  27. 27. 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
  28. 28. IHE profielen voor Stichting RijnmondNet Hans Mekenkamp, MedicalPHIT
  29. 29. IHE Academy 29
  30. 30. 30
  31. 31. Cursusdata 31
  32. 32. Introductie Medical Phit32
  33. 33. Onderwerpen • ITI Domain • XDS – What is XDS? – XDS affinity domains – Use cases – Actors & Transactions – Document content types • XCA
  34. 34. IT-I Domain (Version 9) Integration Profiles Overview
  35. 35. IT-I Domain (Version 9) Integration Profiles Overview XDS-SD Cross-enterprise Document Sharing of Scanned Documents XDM Cross-enterprise Document Media Exchange ATNA XUA Cross-enterprise User Assertion XDS BPPC Basic Patient Privacy Consent
  36. 36. 36
  37. 37. 37
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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)
  42. 42. XDS: Cross-enterprise document sharing
  43. 43. 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
  44. 44. 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 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 Aansluitdocu- ment AD
  45. 45. 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
  46. 46. XDS Flow and interactions ConsumerRegistry Repository 1. Sources post document packages to the Repository 2. Repository registers the documents metadata and pointer with the Registry 3. Consumers search for documents with specific information 4. Consumers retrieve selected documents from Repository (-ies) XDS Document (Metadata): Class Patient Id Author Facility Date of Service … Source of Documents
  47. 47. XDS Actors and Transactions Patient Identity Source Document Registry Document Repository Document Source Document Consumer Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 [ITI-44] Provide&Register Document Set-b [ITI-41] Retrieve Document Set [ITI-43] Registry Stored Query [ITI-18] Register Document Set-b [ITI-42] Integrated Document Source/Repository
  48. 48. 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 Also supported are many other document content profiles specified by the IHE Patient Care Coordination, Laboratory, Cardiology, Pharmacy Technical Frameworks CCR/CCD
  49. 49. XDS: Actors and Options Actors Options Reference Document Source Document Replacement ITI TF-1: 10.2.1 Document Addendum ITI TF-1: 10.2.2 Document Transformation ITI TF-1: 10.2.3 Folder Management ITI TF-1: 10.2.4 Basic Patient Privacy Enforcement ITI TF-2b:3.41.4.1.3.1 Document Repository Document Registry Patient Identity Source Patient Identity Feed ITI TF-2a: 3.8 Patient Identity Feed HL7v3 ITI TF-2b: 3.44 Document Consumer Basic Patient Privacy Enforcement ITI TF-2a: 3.18.4.1.3.5 ITI TF-2b: 3.43.4.1.3.1 Basic Patient Privacy Proof ITI TF-2a: 3.18.4.1.3.6
  50. 50. XDS Standards used • Business standards – ebXML, SOAP, MTOM • Internet standards – HTML, ISO, PDF, JPEG, HTTP(S) • Healthcare standards – HL7 CDA, DICOM, CEN EHR, ASTM CCR WWW standaarden
  51. 51. XDS Document Entry Metadata Document Author Person, role, specialty Available Status (Available, Deprecated) Service Start and Stop Time Start and end time of clinical encounter Document Creation Time Date/time document was (originally) created Legal Authenticator Author that approved the document Title, comments Free text Identifiers Patient ID, Unique ID, entryUUID Kind of Document Class Code (e.g Prescription, Discharge Summary, Report), Type Code (more detail) Event Code Main clinical event (e.g. colonoscopy, appendectomy) Healthcare Facility Type Healthcare Facility Type Code and Display Name Practice Setting Type Practice Setting Code and Display Name Confidentiality Code e.g. VIP, Restricted Access, etc. Technical Details MIME Type; Format Code (e.g. CDA); Size; Hash; URI; Language Patient Demographics Original patient demographics
  52. 52. XDS Document Entry Metadata Document Author Person, role, specialty Available Status (Available, Deprecated) Service Start and Stop Time Start and end time of clinical encounter Document Creation Time Date/time document was (originally) created Legal Authenticator Author that approved the document Title, comments Free text Identifiers Patient ID, Unique ID, entryUUID Kind of Document Class Code (e.g Prescription, Discharge Summary, Report), Type Code (more detail) Event Code Main clinical event (e.g. colonoscopy, appendectomy) Healthcare Facility Type Healthcare Facility Type Code and Display Name Practice Setting Type Practice Setting Code and Display Name Confidentiality Code e.g. VIP, Restricted Access, etc. Technical Details MIME Type; Format Code (e.g. CDA); Size; Hash; URI; Language Patient Demographics Original patient demographics
  53. 53. 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
  54. 54. 2. Voorbeeld Documenten worden niet gevonden Echo onderbuik US Abdomen XDS
  55. 55. Voorbeeld Informatie is niet begrijpbaar Lokaal patiëntnummer Poortnummer Omschrijving
  56. 56. Voorbeeld Documenten zijn niet te herleiden naar beroepsgroep Elk document behoort toe aan de radiologie afdeling?
  57. 57. 3. Oplossing Meta dataset • Gebaseerd op internationale afspraken • Nederlandse situatie (samenwerking IHE, NICTIZ, NVvR) • Flexibel voor alle medische domeinen Standaard gebruiken om ontwikkelingen te versnellen
  58. 58. Dataset voor XDS metadata
  59. 59. Modaliteiten
  60. 60. Rolcode
  61. 61. 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
  62. 62. IHE XDS-I Images and Image Reports
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. Document Consumer Document Consumer Patient Identity Source Patient Identity Feed Imaging Document Source Document Registry Document Repository Provide & Register Imaging Doc Set Register Document Set Imaging Document Consumer Retrieve Imgs, SRs…((DICOM C- MOVE) WADO Retrieve Webservices Retrieve Retrieve Document Query Registry XDS-I Actors/Transactions
  67. 67. 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
  68. 68. BSN in DICOM
  69. 69. XCA – Cross Community Acces
  70. 70. 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
  71. 71. 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.
  72. 72. XCA Actors and transactions Responding CommunityInitiating Community Initiating Gateway Registry Stored Query  Document Consumer Retrieve Document Set   Registry Stored Query  Retrieve Document Set Responding Gateway Document Registry Document Repository  Registry Stored Query  Retrieve Document Set Cross Gateway Query  Cross Gateway Retrieve  Document Registry Document Repository
  73. 73. XCA in a picture Introductie MedicalPHIT Initiating Gateway A Registry A Source Repository Repository Repository Source Source Consumer Consumer Consumer Registry B SourceRepository Repository Repository Source Consumer Consumer XCA Responding Gateway B XDS Domain A XDS Domain B
  74. 74. XCA in a picture Introductie MedicalPHIT74 Initiating Gateway A XDS Domain Amsterdam XDS Domain Rotterdam XCA Responding Gateway B
  75. 75. XCA The bigger picture
  76. 76. XCA: set-up for multiple XDS Affinity domains Doc. Consmer Initiating Gateway Responding Gateway Responding Gateway Responding Gateway Local Registry Doc. Consmer Initiating Gateway Responding Gateway Responding Gateway Responding Gateway Local Registry
  77. 77. Bovenregionale onderwerpen Waarom uitwisseling van informatie (beelden) tussen affinity domeinen? • geografische scheiding • functionele scheiding 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 Beelduitwisseling • Affinity domein – affinity domein Thema’s • Patient consent • Autorisatie • Identificatie & authenticatie • Rollen • Privacy & security • Logging • Vertrouwensmodel Wat is de use case Wat is het bijbehorende proces? Wie zijn de actoren? Wat moet je daarvoor regelen? Wat houdt het in? Waarom zou je er wat voor regelen? Wat kun je er voor regelen?
  78. 78. Keuze voor model 80
  79. 79. Keuze voor model 81
  80. 80. Technisch afspraken Rollen Incl. RBACIdentificatie & authenticatie Thema’s cross-affinity domein • 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 Patient consent Autorisatie Metadataset, semantiek Vertrouwens- model Logging
  81. 81. 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 www.nictiz.nl • 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
  82. 82. 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++
  83. 83. 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)
  84. 84. National solution ??? 86
  85. 85. ATNA Audit Trail and Node Authentification
  86. 86. 88 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. 87. ATNA - Integrating Trusted Nodes System A System B Secured System Secure network • Strong authentication of remote node (digital certificates) • network traffic encryption is not required, it is optional Secured System • Local access control (authentication of user,) • Audit trail with: • Real-time access • Time synchronization Central Audit Trail Repository
  88. 88. XUA Cross-Enterprise User Assertion 90
  89. 89. 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 91
  90. 90. 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. 92
  91. 91. ITI-40 Provide X-User Assertions 93
  92. 92. XUA++ Attribute Extension Proposal, 2012 94
  93. 93. 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. 95
  94. 94. 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, .. 96
  95. 95. 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 2009 97
  96. 96. IHE BPPC Basic Patient Privacy Consent (XDS Content Profile)
  97. 97. 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.
  98. 98. 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.
  99. 99. Actors and Transactions BPPC
  100. 100. Workflow: Capturing Patient Consent • 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.
  101. 101. 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
  102. 102. Verklarende woordenlijst
  103. 103. Richtlijn Nictiz
  104. 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. 105. BPPC policies Richtlijn document BPPC binnen XDS-netwerken
  106. 106. Policies BPPC EZDA
  107. 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. 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. 109. Audit Repository Ziekenhuis 1 Ziekenhuis 2 Affinity Domain Stichting Rijnmondnet Registry XCA Repository Consumer Source Time serve r Repository Consumer Source ITI-1: Maintain time ITI-1: Maintain time 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 ITI-42: Register Document Set-b ITI-18: Registry Stored Query ITI-43:Retrieve Document Set ITI-19: Authenticate Node ITI-40: Provide X-User Assertion ITI-41: Provide and Register Document Set-b BPPC: share content ITI-20: Record audit event
  110. 110. 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
  111. 111. Zorgportaal Rijnmond en XDS Wijnand Weerdenburg
  112. 112. Wat staat er nu…
  113. 113. Programma ZPR 2013 Programma Zorgportaal Rijnmond Project Zorgportaal Rijnmond 2013 Project Ouderen langer thuis (AAL) Instandhouding ZPR Medicatie- overzicht Labuitslagen Beelden Documenten Generieke viewer ReAAL TAMBOERIJN Secure Email 2013: “Jaar van de concreetheid”
  114. 114. TAMBOERIJN •
  115. 115. Zorgportaal Rijnmond: TAMBOERIJN • Doel: Beeldverbinding in de zorg gebruiken • Hardware • Cursus • Infrastructuur Partijen • Lelie Zorggroep • Sonneburgh • Gemeente Rotterdam • Stichting RijnmondNet/Zorgportaal Rijnmond
  116. 116. Programma ZPR 2013 Programma Zorgportaal Rijnmond Project Zorgportaal Rijnmond 2013 Project Ouderen langer thuis (AAL) Instandhouding ZPR Medicatie- overzicht Labuitslagen Beelden Documenten Generieke viewer ReAAL TAMBOERIJN Secure Email 2013: “Jaar van de concreetheid”
  117. 117. 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!
  118. 118. 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
  119. 119. ReAAL: algemene doelstelling
  120. 120. 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:
  121. 121. ReAAL: Toepassingen • NetMedical: monitoring gezondheid in thuissituatie: – Bloeddruk – Bloed glucose – Gewicht
  122. 122. ReAAL: Toepassingen • MindDistrict: Helpen/preventie van specifieke problematiek – Beter slapen – Depressie – Alcoholisme
  123. 123. ReAAL: Toepassingen • Almende: Veilig leven mbv de smartphone – Algemeen gevoel van welzijn – Gebruik van 30 sensoren in smartphone – Alcohol/depressie 127
  124. 124. ReAAL: Toepassingen • Curavista: Monitoring van (chronische) ziekten in de thuissituatie met behulp van dagboeken, bijvoorbeeld: – Pijn bij kanker – Alzheimer – Diabetes
  125. 125. ReAAL: Toepassingen • MiBida: Interactie met ouderen – Screen to screen communicatie 129
  126. 126. ReAAL: Toepassingen • Kwa+ch: Gezondheidsmanagement met smart watch technologie – Medicatie management met intelligente horloges
  127. 127. Programma ZPR 2013 Programma Zorgportaal Rijnmond Project Zorgportaal Rijnmond 2013 Project Ouderen langer thuis (AAL) Instandhouding ZPR Medicatie- overzicht Labuitslagen Beelden Documenten Generieke viewer ReAAL TAMBOERIJN Secure Email 2013: “Jaar van de concreetheid”
  128. 128. Project official public presentation 132 Connection to universAAL April 25, 2013
  129. 129. 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
  130. 130. Demonstratie XDS Viewer Sven Pippel
  131. 131. 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
  132. 132. Lunch
  133. 133. 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
  134. 134. Aansluitdocument in de praktijk Arne Freriks
  135. 135. Aansluitdocument in praktijk • Stappen om aan te sluiten • Uitgangspunten XDS Stichting RijnmondNet
  136. 136. Stappen om aan te sluiten • Randvoorwaarde: XDS actoren in huis • Opstarten projectteam XDS • Projectplan – Aansluiten op infrastructuur – Convenant, bewerkersovereenkomst – Testplan en testen (ketentest) – Operationalisatie • Beheer – Helpdesk – Beheerders
  137. 137. Testen • Check Connectathon resultaten • Technische testen bij participant door leverancier • Functionele testen door participant • Acceptatietest in de keten (projectgroep)
  138. 138. Uitgangspunten (1) • Gedragscode EGiZ • IHE profielen en landelijke metadata set leidend • Stichting RijnmondNet beheert centrale omgeving (T/P) • Patiëntinformatie blijft bij de bron: geen centrale repository • Beveiligde verbindingen naar de index van Stichting RijnmondNet via ZSP • UZI server-certificaten • GBZ eisen voor de aangesloten partijen
  139. 139. Uitgangspunten (2) • BSN voor identificatie patiënt • UZI-pas inlog voor identificatie/authenticatie zorgverlener • Geen groepsaccounts • Convenant tussen aangesloten partijen binnen AD (regio) van Stichting RijnmondNet • Volgen Nictiz richtlijn rondom gebruik BPPC
  140. 140. Uitgangspunten (3) • Centrale logging (ATNA) door Stichting RijnmondNet • Lokale logging door participant • Service monitoring logging • Opsporing misbruik verantwoordelijkheid participant, Stichting RijnmondNet ondersteunt (kan logging beschikbaar stellen)
  141. 141. 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
  142. 142. Vragensessie, discussie • Introductie IHE • IHE profielen • Zorgportaal Rijnmond • Demo Viewer • Aansluitdocument en Uitgangspunten
  143. 143. 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
  144. 144. Afsluiting • Dank voor uw aandacht • Presentaties en documenten komen op www.rijnmondnet.nl

×