Seminar achtergrond IHE - 19 juli 2013

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-2820099RijnmondNet 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.

Welkom

• Waarom deze sessie?

• Even voorstellen…

• Vragen: ja graag!

• Mobieltjes stil

• Presentaties & documenten op

www.rijnmondnet.nl

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

Introductie IHE

Vincent van Pelt, Nictiz

IHE – integrating the Healthcare Enterprise

Vincent van Pelt, Nictiz

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

[email protected]

mailto:[email protected]

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

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

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

IHE - werkwijze

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

IHE - historie

Pathology2006

Radiation Oncology2004

Radiology1998

Cardiology2004

Patient Care Devices2005

Patient Care Coordination2004

Eye Care2006

QualityResearch & Public Health

2006

Laboratory2004

(Healthcare)IT Infrastructure

since 2003

Pharmacy2009

IHE profielen - ITI

IHE profielen - PCC

IHE profielen – en nog veel meer

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

Inzicht in het zorgproces

Beschikbaarheid van relevante medische informatie

Applicaties en Infrastructuur voor opslag en uitwisseling

Zorgproces

Beleid

Informatie

Applicaties

Infrastructuur

Interoperabiliteitsniveaus

XDW

IHE ContentModules

XDS

IHE - interoperabiliteit op meerdere niveaus

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

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

Foundation ServicesWorkflow 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 …

Foundation Service GroupsWorkflow Services


Data Entry 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 …

Workflow Services


Data Entry Services





Cross-community Services Inter-community Services Content-specific Services

Foundation Services

Workflow Services


Data Entry 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.

Workflow Services


Data Entry Services






Use Case A: Sharing of Medical Summary







XDS Document Sharing



HPD HCP Discovery







PRE

XBeR-WD

XPHR

XDS-MS




CHA HRN, LAN/PAN


Workflow Services


Data Entry Services






Use Case B: Patient Telehome Monitoring







XDS Document Sharing



HPD HCP Discovery







PRE

XBeR-WD

XPHR

XDS-MS




CHA HRN, LAN/PAN


Zorgproces

Beleid

Informatie

Applicaties

Infrastructuur

Vragen?







• 12:30 Lunch




IHE profielen voor Stichting RijnmondNet

Hans Mekenkamp, MedicalPHIT

IHE Academy

29

Cursusdata

31

Introductie Medical Phit32

//localhost/Users/hans TM/Dropbox/Rijnmondnet Seminar/Presentaties/XDS-I en XCA.pptx

Onderwerpen• ITI Domain

• XDS

– What is XDS?

– XDS affinity domains

– Use cases

– Actors & Transactions

– Document content types

• XCA

IT-I Domain (Version 9) Integration Profiles Overview

IT-I Domain (Version 9) Integration Profiles Overview

XDS-SDCross-enterprise Document

Sharing of

Scanned Documents

XDMCross-enterprise Document

Media Exchange

ATNA

XUACross-enterprise

User Assertion

XDS

BPPCBasic Patient

Privacy Consent

37

//localhost/Users/hans TM/Dropbox/Rijnmondnet Seminar/Handout docs/IHE_ITI_TF_Vol1.pdf

IT-I DomainIntegration 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

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


• 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


• 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)

XDS: Cross-enterprise document sharing

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

XDS Affinity DomainsGroup 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

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

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):

ClassPatient IdAuthorFacilityDate of Service…

Source of Documents

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

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

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 ConsumerBasic 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

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

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

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

2. Voorbeeld

Documenten worden niet gevonden

Echo onderbuik

US Abdomen

XDS

Voorbeeld

Informatie is niet begrijpbaar

Lokaal patiëntnummer

Poortnummer

Omschrijving

Voorbeeld

Documenten zijn niet te herleiden naar

beroepsgroep

Elk document behoort toe aan de radiologie afdeling?

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

Dataset voor XDS metadata

Modaliteiten

Rolcode

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

IHE XDS-I

Images and Image Reports

XDS-I sharing images andreports

• 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

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

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

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

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

BSN in DICOM

XCA – Cross Community Acces

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

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.

XCA Actors and transactions

Responding Community Initiating 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

XCA in a picture

Introductie MedicalPHIT

Initiating

Gateway

A

Registry A

Source RepositoryRepository

RepositorySource

Source

ConsumerConsumer

Consumer

Registry B

SourceRepositoryRepository

Repository Source

Consumer

Consumer

XCA

Responding

Gateway

B

XDS Domain A

XDS Domain B

XCA in a picture

Introductie MedicalPHIT74

Initiating

Gateway

A

XDS Domain Amsterdam

XDS Domain Rotterdam

XCA

Responding

Gateway

B

XCA

The bigger picture

XCA: set-up for multiple XDS Affinity

domains

Doc.

Consmer

Initiating

Gateway

Responding

Gateway

Responding

Gateway

Responding

GatewayLocal

Registry

Doc.

Consmer

Initiating

Gateway

Responding

Gateway

Responding

Gateway

Responding

Gateway

Local

Registry

Bovenregionale onderwerpenWaarom 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 caseWat 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?

Keuze voor model

80

Keuze voor model

81

Technisch afspraken

RollenIncl. 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

Patientconsent

Autorisatie

Metadataset, semantiek

Vertrouwens-model

Logging

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

http://www.nictiz.nl/

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++

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)

National solution ???

86

ATNA

Audit Trail and Node

Authentification

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

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

XUA

Cross-Enterprise User Assertion

90

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

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

ITI-40 Provide X-User Assertions

93

XUA++

Attribute Extension

Proposal, 2012

94

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

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

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

IHE BPPC

Basic Patient Privacy Consent

(XDS Content Profile)

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.

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.

Actors and Transactions BPPC

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.

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

Verklarende woordenlijst

Richtlijn Nictiz

Onmogelijkheden BPPC1. 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).

BPPC policies Richtlijn document BPPC binnen XDS-netwerken

Policies BPPC EZDA

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

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

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







• 12:30 Lunch




Zorgportaal Rijnmond en XDS

Wijnand Weerdenburg

Wat staat er nu…

Programma ZPR 2013

Programma Zorgportaal Rijnmond

Project Zorgportaal Rijnmond

2013

ProjectOuderen langer thuis

(AAL)

Instandhouding ZPR

Medicatie-overzicht

LabuitslagenBeelden

Documenten

Generieke viewer

ReAAL TAMBOERIJN

Secure Email

2013: “Jaar van de concreetheid”

TAMBOERIJN

•

Zorgportaal Rijnmond: TAMBOERIJN

• Doel: Beeldverbinding in de zorg gebruiken

• Hardware

• Cursus

• Infrastructuur

Partijen

• Lelie Zorggroep

• Sonneburgh

• Gemeente Rotterdam

• Stichting RijnmondNet/Zorgportaal Rijnmond

Programma ZPR 2013



2013


(AAL)

Instandhouding ZPR

Medicatie-overzicht

LabuitslagenBeelden

Documenten

Generieke viewer

ReAAL TAMBOERIJN

Secure Email


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!

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

ReAAL: algemene doelstelling

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:

ReAAL: Toepassingen

• NetMedical: monitoring gezondheid in thuissituatie:

– Bloeddruk

– Bloed glucose

– Gewicht

ReAAL: Toepassingen

• MindDistrict: Helpen/preventie van specifieke

problematiek

– Beter slapen

– Depressie

– Alcoholisme

ReAAL: Toepassingen

• Almende: Veilig leven mbv de smartphone

– Algemeen gevoel van welzijn

– Gebruik van 30 sensoren in

smartphone

– Alcohol/depressie

127

ReAAL: Toepassingen

• Curavista: Monitoring van (chronische) ziekten in de

thuissituatie met behulp van dagboeken, bijvoorbeeld:

– Pijn bij kanker

– Alzheimer

– Diabetes

ReAAL: Toepassingen

• MiBida: Interactie met ouderen

– Screen to screen communicatie

129

ReAAL: Toepassingen

• Kwa+ch: Gezondheidsmanagement met smart watch

technologie

– Medicatie management met intelligente horloges

Programma ZPR 2013



2013


(AAL)

Instandhouding ZPR

Medicatie-overzicht

LabuitslagenBeelden

Documenten

Generieke viewer

ReAAL TAMBOERIJN

Secure Email


Project official public presentation 132

Connection to universAAL

April 25, 2013







• 12:30 Lunch




Demonstratie XDS Viewer

Sven Pippel







• 12:30 Lunch




Aansluitdocument in de praktijk

Arne Freriks

Aansluitdocument in praktijk

• Stappen om aan te sluiten

• Uitgangspunten XDS Stichting

RijnmondNet

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

Testen

• Check Connectathon resultaten

• Technische testen bij participant door

leverancier

• Functionele testen door participant

• Acceptatietest in de keten (projectgroep)

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

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

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)







• 12:30 Lunch




Vragensessie, discussie

• Introductie IHE

• IHE profielen

• Zorgportaal Rijnmond

• Demo Viewer

• Aansluitdocument en Uitgangspunten







• 12:30 Lunch




Afsluiting

• Dank voor uw aandacht

• Presentaties en documenten komen op

www.rijnmondnet.nl

Seminar achtergrond IHE - 19 juli 2013

Health & Medicine

Transcript of Seminar achtergrond IHE - 19 juli 2013