IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP...

46
IHE Security IHE Security XDS as a case study XDS as a case study John Moehrke John Moehrke GE Healthcare GE Healthcare IHE ITI Technical Committee Member IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure HITSP Co-Chair - Security Privacy and Infrastructure Committee Committee July 15, 2008 July 15, 2008

Transcript of IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP...

Page 1: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

IHE SecurityIHE SecurityXDS as a case studyXDS as a case study

John MoehrkeJohn Moehrke

GE HealthcareGE Healthcare

IHE ITI Technical Committee MemberIHE ITI Technical Committee Member

HITSP Co-Chair - Security Privacy and Infrastructure CommitteeHITSP Co-Chair - Security Privacy and Infrastructure Committee

July 15, 2008July 15, 2008

Page 2: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

2

AgendaAgenda

Who is IHEWho is IHE

Overall Security ModelOverall Security Model

Deep diveDeep dive

GapsGaps

Conclusion Conclusion

Page 3: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

3

What Is IHE?What Is IHE?

IHE is a IHE is a collaborative responsecollaborative response to healthcare IT to healthcare IT market requirements for system integration.market requirements for system integration.

Develop standards-based implementation specifications Develop standards-based implementation specifications called called profilesprofiles..

• Useful subsets of one or more standardsUseful subsets of one or more standards• Tested at Tested at ConnectathonsConnectathons• Demonstrated at Demonstrated at HIMSS, RSNAHIMSS, RSNA, and , and ACCACC shows shows

Correct known integration problems.Correct known integration problems.• Intra-enterprise and multi-enterprise scopeIntra-enterprise and multi-enterprise scope

Satisfy emerging market needs & prevent new problems.Satisfy emerging market needs & prevent new problems.• EHR & government drivenEHR & government driven• Regional and national scopeRegional and national scope

Build Build trust, collegiality, effectiveness trust, collegiality, effectiveness amongamong v vendors, endors, providers, and other stakeholders.providers, and other stakeholders.

Page 4: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

4

What is a RHIO?What is a RHIO?HIMSS: RHIO – A Regional Health Information HIMSS: RHIO – A Regional Health Information Organization (RHIO) is a multi-stakeholder Organization (RHIO) is a multi-stakeholder organization that enables the exchange and use of organization that enables the exchange and use of health information, in a secure manner, for the health information, in a secure manner, for the purpose of promoting the improvement of health purpose of promoting the improvement of health quality, safety and efficiency. quality, safety and efficiency.

Competing enterprisesCompeting enterprises

Longitudinal view of the patient’s health historyLongitudinal view of the patient’s health history

Protect Privacy Protect Privacy

Providing better care to patientsProviding better care to patients

Promoting Safety and QualityPromoting Safety and Quality

Aka: SNO, HIN, HIE,

IHE: Affinity Domain

Page 5: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

5

Affinity Domain -- PoliciesAffinity Domain -- Policies

International Policies

Country-Specific Policies

Horizontal Industry Policies

Enterprise Policies

IHE – leverages/profiles

OECD GuidelinesOn Transborder

Flows

US-HIPAAEU-EC95/46

JP-Act 57 - 2003

Medical ProfessionalSocieties

Backup &Recovery

Examples

Page 6: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

6

RHIO: Document basedRHIO: Document based

Persistence, Persistence, Captures the conclusion / summary of an episodeCaptures the conclusion / summary of an episode

Stewardship, Stewardship, Long term maintenance (patients life 100+ years)Long term maintenance (patients life 100+ years)

Potential for Authentication, andPotential for Authentication, and Which Doctor’s conclusion or opinion Which Doctor’s conclusion or opinion What predicate data or knowledgeWhat predicate data or knowledge

Wholeness. Wholeness. Integrity, completeness, inclusive, Integrity, completeness, inclusive,

Page 7: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

7

XDS Security Use CasesXDS Security Use CasesPrevent Indiscriminate attacks (worms, DOS)Prevent Indiscriminate attacks (worms, DOS)

Normal Patient that accepts XDS participationNormal Patient that accepts XDS participation

Patient asks for Accounting of DisclosuresPatient asks for Accounting of Disclosures

Protect against malicious neighbor doctorProtect against malicious neighbor doctor

Patient that retracts consent to publishPatient that retracts consent to publish

Provider PrivacyProvider Privacy

Malicious Data MiningMalicious Data Mining

Access to Emergency data setAccess to Emergency data set

VIP (movie star, sports figure)VIP (movie star, sports figure)

Domestic violence victimDomestic violence victim

Daughter with sensitive tests hidden from ParentDaughter with sensitive tests hidden from Parent

Sensitive topics: mental health, sexual healthSensitive topics: mental health, sexual health

Legal Guardian (cooperative)Legal Guardian (cooperative)

Care-Giver (assists w/ care)Care-Giver (assists w/ care)

Page 8: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

8

Entries accessible toadministrative staff

Entries accessible toclinical in emergency

Entries accessible todirect care teams

Entries restricted toprison health service

Entries restricted tosexual health teamPrivate entries

shared with GP

Private entriesshared with severalnamed parties

Document AccessibilityDocument Accessibility

Source: Dipak Kalra & prEN 13606-4

Page 9: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

9

RBAC tableRBAC table

SensitivityFunctional Role

Billin

g In

form

ation

Ad

min

istrativ

e In

form

ation

Die

tary Re

strictio

ns

Ge

ne

ral Clin

ica

l Info

rma

tion

Se

ns

itive C

linic

al In

form

atio

n

Re

sea

rch

Info

rmatio

n

Me

diate

d b

yD

irec

t Care

Pro

vide

r

Administrative Staff X X          

Dietary Staff   X X        

General Care Provider   X X X      

Direct Care Provider   X X X X   X

Emergency Care Provider   X X X X   X

Researcher           X  

Patient or Legal Representative X X X X X    

Page 10: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

10

Document AccessibilityDocument AccessibilityInside Ent In HIE

Page 11: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

Privacy ControlsPrivacy Controls

Page 12: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

12

Basic Patient Privacy ConsentsBasic Patient Privacy ConsentsAbstractAbstract

The Basic Patient Privacy Consents The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to:(BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Record the patient privacy consent(s), Mark documents published to XDS with the choice Mark documents published to XDS with the choice

of patient privacy consent that was used to of patient privacy consent that was used to authorize the publication, authorize the publication,

Enforce the privacy consent appropriate to the Enforce the privacy consent appropriate to the use.use.

Builds upon the ATNA security infrastructureBuilds upon the ATNA security infrastructure

Page 13: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

13

Basic Patient Privacy ConsentsBasic Patient Privacy ConsentsValue PropositionValue Proposition

an Affinity Domain can an Affinity Domain can develop privacy policies, develop privacy policies, and implement them with role-based or other and implement them with role-based or other

access control mechanisms supported by access control mechanisms supported by edge/EHR systems.edge/EHR systems.

A patient canA patient can Be made aware of an institution privacy policies. Be made aware of an institution privacy policies. Have an opportunity to selectively control access Have an opportunity to selectively control access

to their healthcare information.to their healthcare information.

Page 14: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

14

Basic Patient Privacy ConsentsBasic Patient Privacy ConsentsStandards and Profiles UsedStandards and Profiles Used

Key PropertiesKey Properties Human Readable ConsentsHuman Readable Consents Machine ProcessableMachine Processable Support for standards-based Role-Based Access ControlSupport for standards-based Role-Based Access Control

StandardsStandards CDA Release 2.0CDA Release 2.0 XDS Scanned DocumentsXDS Scanned Documents Document Digital SignatureDocument Digital Signature Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR, Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR,

and XDM)and XDM)

Page 15: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

15

RBAC with Basic ConsentRBAC with Basic Consent

Page 16: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

16

Basic Consent on an episode basisBasic Consent on an episode basis

Page 17: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

17

Basic Consent – Extended to HIEBasic Consent – Extended to HIE

Page 18: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

18

Basic Consent – Publication controlsBasic Consent – Publication controls

Page 20: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

Security ControlsSecurity Controls

Page 21: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

21

Community Clinic

Lab Info. System

PACS

Teaching Hospital

PACS

ED Application

EHR System

Physician Office

EHR System

XDS Scenario + use of ATNA & CTXDS Scenario + use of ATNA & CT

PMS

Retrieve DocumentRetrieve Document

Register DocumentRegister DocumentQuery DocumentQuery Document

XDS Document Registry

ATNA Audit record repository CT Time server

Record AuditRecord AuditEventEvent

MaintainMaintainTimeTime

MaintainMaintainTimeTimeRecord AuditRecord Audit

EventEvent

Maintain TimeMaintain TimeProvide & Register Docs

Record AuditRecord AuditEventEvent

XDS Document Repository

XDSDocumen

t Reposito

rySecured MessagingSecured Messaging

Page 22: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

22

Community Clinic

Lab Info. System

PACS

Teaching Hospital

PACS

ED Application

EHR System

Physician Office

EHR System

ATNA Security Model(1)ATNA Security Model(1)

PMS

XDS Document Registry

Provide & Register Docs

XDS Document Repository

XDSDocumen

t Reposito

ry

Secured NodeSecured Node

Secured NodeSecured NodeSecured NodeSecured Node

Secured NodeSecured Node

XDS Document Repository

Dual Authenticated LinksDual Authenticated Links

Page 23: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

23RHIO boundary

Community Clinic

Lab Info. System

PACS

Teaching Hospital

PACS

ED Application

EHR System

Physician Office

EHR System

IHE RHIO SolutionIHE RHIO Solution

PMS

Retrieve DocumentRetrieve Document

Register DocumentRegister DocumentQuery DocumentQuery Document

XDS Document Registry

ATNA Audit ATNA Audit record repositoryrecord repository CT Time serverCT Time server

Provide & Register Docs

XDS Document Repository

XDSDocumen

t Reposito

ry

ATNA Audit ATNA Audit record repositoryrecord repository

State run RHIO

ATNA Audit ATNA Audit record repositoryrecord repository

PatientIDX-ref

Page 24: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

24

Security ModelsSecurity Models

Risk AssessmentRisk Assessment Asset is the information in Registry & all RepositoriesAsset is the information in Registry & all Repositories Confidentiality, Integrity, and AvailabilityConfidentiality, Integrity, and Availability Patient Safety overrides privacy (most of the time)Patient Safety overrides privacy (most of the time)

AccountabilityAccountability Access Control model -- PreventionAccess Control model -- Prevention Audit Control model -- ReactionAudit Control model -- Reaction

Policy EnforcementPolicy Enforcement Mutually agree to enforce Policies Mutually agree to enforce Policies Enforcement of policies centrallyEnforcement of policies centrally

Page 25: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

25

RHIO Domain PolicyRHIO Domain PolicyXDS Affinity Domain Definition Checklist XDS Affinity Domain Definition Checklist See See Template for XDS Affinity Domain Deployment Planning Template for XDS Affinity Domain Deployment Planning

IHE gives no direction on the content of this Policy IHE gives no direction on the content of this Policy E.g. Patient allows general purpose healthcare information E.g. Patient allows general purpose healthcare information

to be submitted, sensitive data will not be published. Only to be submitted, sensitive data will not be published. Only Healthcare Providers that are a member of that patients Healthcare Providers that are a member of that patients direct care team will be given access. direct care team will be given access.

Policy must be enforceable by all the systems in Policy must be enforceable by all the systems in the RHIO Domainthe RHIO Domain EHR RBAC capabilities must be consideredEHR RBAC capabilities must be considered PHR portal must be able to enforce restrictionsPHR portal must be able to enforce restrictions Registry / Repositories must only talk to authorized systemsRegistry / Repositories must only talk to authorized systems

Page 26: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

26

IHE-XDS Infrastructure ComponentsIHE-XDS Infrastructure ComponentsDocument Registry (XDS)Document Registry (XDS) – – Queryable index of metadata and references to all Queryable index of metadata and references to all documents shared within a connected community (XDS Affinity Domain)documents shared within a connected community (XDS Affinity Domain)

Document Repository (XDS)Document Repository (XDS) – – Supports storage and retrieval of clinical Supports storage and retrieval of clinical information (as documents). May be centralized or distributed.information (as documents). May be centralized or distributed.

Patient Identifier Cross Reference Manager (PIX)Patient Identifier Cross Reference Manager (PIX) – – Reconciles information on Reconciles information on patients from multiple domains to a single, cross referenced set of IDs for each given patients from multiple domains to a single, cross referenced set of IDs for each given patient.patient.

Patient Demographics Supplier (PDQ)Patient Demographics Supplier (PDQ) – – Returns demographic information and Returns demographic information and identifiers for patients based on specified demographic criteria. identifiers for patients based on specified demographic criteria.

Audit Record Repository (ATNA)Audit Record Repository (ATNA) – – Receive audit records from other actors and Receive audit records from other actors and securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt communications.communications.

Cross Enterprise User Assertion (XUA)Cross Enterprise User Assertion (XUA) – Mechanism for User Identity federation – Mechanism for User Identity federation

Basic Patient Privacy Consents (BPPC)Basic Patient Privacy Consents (BPPC) – Providing for Patient Privacy – Providing for Patient Privacy dimension of Access control including Capturing Patient Consent including support dimension of Access control including Capturing Patient Consent including support for Opt-In and Opt-Outfor Opt-In and Opt-Out

Time Server (CT)Time Server (CT) – – Provides consistent definition of date/time enabling time Provides consistent definition of date/time enabling time synchronization across multiple systems. Enables events associated with patients to synchronization across multiple systems. Enables events associated with patients to be sorted reliably in chronological order.be sorted reliably in chronological order.

Page 27: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

27

Security & Privacy ControlsIHE Profile

Ac

co

un

tab

ility

Ide

ntific

atio

n a

nd

A

uth

en

tica

tion

Da

ta A

cc

es

s

Co

nfid

en

tiality

Da

ta In

teg

rity

No

n-R

ep

ud

iatio

n

Pa

tien

t Priv

ac

y

Av

aila

bility

Audit Trails and Node Authentication D D D D D D D

Basic Patient Privacy Consents I D

Consistent Time D I D

Enterprise User Authentication I D I I I I

Cross-Enterprise User Assertion I D I I I I

Document Digital Signature D D D D

Cross-Enterprise Document Sharing D D I D

Cross-Enterprise Document Reliable Messaging D D I D

Cross-Enterprise Document exchange on Media I D D I D

Personnel White Pages I D D I

Page 28: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

Identity and Access ControlIdentity and Access Control

Page 29: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

29

Cross-Enterprise User AssertionCross-Enterprise User Assertion

Value PropositionValue Proposition

Extend User Identity to Affinity DomainExtend User Identity to Affinity Domain Users include Providers, Patients, Clerical, etc Users include Providers, Patients, Clerical, etc Must supports cross-enterprise transactions, can be used inside Must supports cross-enterprise transactions, can be used inside

enterpriseenterprise Distributed or Centralized Identity management (Directories)Distributed or Centralized Identity management (Directories)

Provide information necessary so that receiving actors Provide information necessary so that receiving actors can make Access Control decisionscan make Access Control decisions Authentication mechanism usedAuthentication mechanism used Attributes about the user (roles)Attributes about the user (roles) Does not include Access Control mechanismDoes not include Access Control mechanism

Provide information necessary so that receiving actors Provide information necessary so that receiving actors can produce detailed and accurate Security Audit Trailcan produce detailed and accurate Security Audit Trail

Page 30: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

30

Cross-Enterprise User AssertionCross-Enterprise User Assertion

Technical SolutionTechnical Solution

Initial scope to XDS.b Stored Query and Retrieve Initial scope to XDS.b Stored Query and Retrieve Relies on Web-Services Relies on Web-Services Easily extended to any Web-Services transactionsEasily extended to any Web-Services transactions Leverage WS-I Basic Security Profile 1.1Leverage WS-I Basic Security Profile 1.1

Use SAML 2.0 Identity AssertionsUse SAML 2.0 Identity Assertions Does not constrain ‘how’ the Assertion was obtainedDoes not constrain ‘how’ the Assertion was obtained Supporting Liberty Alliance, WS-Trust, and SAMLSupporting Liberty Alliance, WS-Trust, and SAML

Define grouping behavior with EUA and ATNADefine grouping behavior with EUA and ATNA

Page 31: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

31

Four Identity Assurance LevelsFour Identity Assurance Levels

NIST SP800-63 Electronic

Authentication technical guidance

matches technology to each assurance level

OMB E-Authentication Guidance establishes four assurance levels for

consistent application of E-Authenticationacross gov’t

Level 4Level 3Level 2Level 1

Little or no confidence in

asserted identity (e.g. self identified

user/password)

Some confidence in asserted

identity (e.g. PIN/Password)

High confidence in asserted

identity (e.g. digital cert)

Very high confidence in the asserted identity (e.g. Smart Card)

E-RA tool assists agencies in defining authentication

requirements & mapping them to the appropriate

assurance level

Page 32: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

32

Factor Token

Very High

High

Medium

Low

RemoteClinical Entry

VerificationOf DataTranscription

Access toLocal EHR/EMR

Access toSummary ofClinical research

PIN/User ID-

Knowledge

Strong Password

-Based

PKI/ Digital Signature

Multi-

Incre

ase

d $

Cost

Increased Need for Identity Assurance

Security Considerations:Security Considerations:Four Identity Assurance LevelsFour Identity Assurance Levels

Page 33: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

33

Key:

Original Transaction

TLS Protections

EHR

PatientData

XDS Consumer XDS Registry

user auth provider

Cross-Enterprise User AssertionCross-Enterprise User Assertion

Implementation ExampleImplementation Example

UserAuth

(ATNA Secure Node)

(ATNA Secure Node)

AuditLog

X-Service User

X-Identity Provider XUA =

Web-Services Security + SAML Assertions

XUA Assertion

AuditAudit

Page 34: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

34

Distributed Access Control – Distributed Access Control – enabled by XUAenabled by XUA

XDS RegistryXDS Document ConsumerAccess

Control

XDS RegistryXDS Document ConsumerAccess

ControlAccessControl

XDS RegistryXDS Document ConsumerAccess

ControlAccessControl

AccessControl

Page 35: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

AccountabilityAccountability

Page 36: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

36

Today’s XDS AccountabilityToday’s XDS Accountability

Mitigation against unauthorized useMitigation against unauthorized use Investigate Audit log for patterns and behavior outside Investigate Audit log for patterns and behavior outside

policy. Enforce policypolicy. Enforce policy Secure Node requires appropriate Access Controls to Secure Node requires appropriate Access Controls to

enforce at the enterprise by XDS Source and Consumersenforce at the enterprise by XDS Source and Consumers

Investigation of patient complaintsInvestigation of patient complaints Investigate Audit log for specific evidenceInvestigate Audit log for specific evidence ATNA Audit Repositories can filter and auto-forwardATNA Audit Repositories can filter and auto-forward

Support an Accounting of DisclosuresSupport an Accounting of Disclosures ATNA Report: XDS-Export + XDS-Import ATNA Report: XDS-Export + XDS-Import

Page 37: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

37RHIO boundary

Community Clinic

Lab Info. System

PACS

Teaching Hospital

PACS

ED Application

EHR System

Physician Office

EHR System

Centralized AccountabilityCentralized Accountability

PMS

Retrieve DocumentRetrieve Document

Register DocumentRegister DocumentQuery DocumentQuery Document

XDS Document Registry

ATNA Audit ATNA Audit record repositoryrecord repository CT Time serverCT Time server

MaintainMaintainTimeTime

MaintainMaintainTimeTime

Maintain TimeMaintain TimeProvide & Register Docs

XDS Document Repository

XDSDocumen

t Reposito

ry

Page 38: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

38RHIO boundary

Community Clinic

Lab Info. System

PACS

Teaching Hospital

PACS

ED Application

EHR System

Physician Office

EHR System

Distributed AccountabilityDistributed Accountability

PMS

Retrieve DocumentRetrieve Document

Register DocumentRegister DocumentQuery DocumentQuery Document

XDS Document Registry

ATNA Audit ATNA Audit record repositoryrecord repository CT Time serverCT Time server

MaintainMaintainTimeTime

MaintainMaintainTimeTime

Maintain TimeMaintain TimeProvide & Register Docs

XDS Document Repository

XDSDocumen

t Reposito

ry

ATNA Audit ATNA Audit record repositoryrecord repository

State run RHIO

ATNA Audit ATNA Audit record repositoryrecord repository

Page 39: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

39

Sjfldjlsdj aKdjldsjLsjldjljfjfjlslkjlnLslasdjj;ask;slsSflksdjfl;safSalasaskaFaslskf;sfSlsjlsdjlsdjfLsjflsdjldsjfsSlkfjsdlfjldsflsjfldsjfldsfj

Sjfldjlsdj aLslasdjj;ask;slsFaslskf;sflsjfldsjfldsfj

Clinic A

HIE InfrastructureAudit

Audit

EMR

Example: Audit Log CascadeExample: Audit Log Cascade

Inform Disclosure ReportsInform Disclosure Reports

Detect unusual behavior Detect unusual behavior Follow chain back Follow chain back

Page 40: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

40

Flexible Infrastructure: Flexible Infrastructure: Sharing, Sending and InterchangingSharing, Sending and Interchanging

Health Information Exchange or RHIOHealth Information Exchange or RHIO

PublishPublish

PullPullStructuredStructuredobjectsobjects

PullPull

TransactionsTransactionsWorkflowWorkflow

MgrMgrWorkflowWorkflow

MgrMgr

Send toSend to SwitchSwitch Send toSend to

WriteWrite ReadReadInterchangeInterchange

MediaMedia

XDSXDS

XDRXDR

XDMXDM

Page 41: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

ConclusionConclusion

Page 42: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

44

Supported XDS Security Use-CasesSupported XDS Security Use-Cases

Prevent Indiscriminate attacksPrevent Indiscriminate attacks Mutual Auth TLS Mutual Auth TLS

Normal Patient that accepts XDS participationNormal Patient that accepts XDS participation

Patient asks for Accounting of Disclosures Patient asks for Accounting of Disclosures informed by ATNA log informed by ATNA log

Protect against malicious neighbor doctorProtect against malicious neighbor doctor informed by ATNA log informed by ATNA log

Patient that retracts consent to publish Patient that retracts consent to publish Repository is local, manual Repository is local, manual

Provider Privacy Provider Privacy User identity is not exposed User identity is not exposed

Malicious Data MiningMalicious Data Mining queries are all patient based queries are all patient based

Access to Emergency data set Access to Emergency data set BPPC policy BPPC policy

VIP VIP XDR/M, BPPC (Local XDR/M, BPPC (Local enforcement)enforcement)

Domestic violence victim Domestic violence victim BPPC policy (Local BPPC policy (Local enforcement)enforcement)

Daughter with sensitive tests Daughter with sensitive tests XDR/M BPPC policy XDR/M BPPC policy

Sensitive topicsSensitive topics Don’t publish, BPPC policy Don’t publish, BPPC policy

Legal Guardian (cooperative) Legal Guardian (cooperative) BPPC policy (Local enforcement) BPPC policy (Local enforcement)

Care Giver (assists w/ care) Care Giver (assists w/ care) BPPC policy (Local enforcement) BPPC policy (Local enforcement)

Page 43: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

45

Private entriesshared with GP

Private entriesshared with severalnamed parties

Entries restricted tosexual health team

Entries restricted toprison health service

Entries accessible toadministrative staff

Entries accessible toclinical in emergency

Entries accessible todirect care teams

Document AccessibilityDocument Accessibility

Source: Dipak Kalra & prEN 13606-4

Page 44: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

46

Gaps for potential future developmentGaps for potential future developmentBetter coded vocabulary for confidentiality codesBetter coded vocabulary for confidentiality codes Complex policies on a document by document basisComplex policies on a document by document basis Extension to objects other than XDS (e.g. DICOM)Extension to objects other than XDS (e.g. DICOM)

Patient Access toPatient Access to Sensitive health topics (you are going to die)Sensitive health topics (you are going to die) Low sensitivity (scheduling)Low sensitivity (scheduling) Self monitoring (blood sugar)Self monitoring (blood sugar) Authoritative updates / amendments / removalAuthoritative updates / amendments / removal

Complex Privacy ‘consent’ Policy capabilitiesComplex Privacy ‘consent’ Policy capabilities Supporting Inclusion ListsSupporting Inclusion Lists Supporting Exclusion ListsSupporting Exclusion Lists Exceptions, and ObligationsExceptions, and Obligations Supporting functional role languageSupporting functional role language

Access Control ServiceAccess Control Service Centralized PoliciesCentralized Policies Policy Decision Point / Policy Enforcement PointsPolicy Decision Point / Policy Enforcement Points

Accounting of Disclosures reports, alerts, messagingAccounting of Disclosures reports, alerts, messaging To support reporting to the ‘consumer’ when their data is accessedTo support reporting to the ‘consumer’ when their data is accessed

Un-Safe Client machine (home-computer)Un-Safe Client machine (home-computer)

Page 45: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

47

ConclusionConclusion

IHE provides the necessary basic security for IHE provides the necessary basic security for XDS todayXDS today

There is room for improvementThere is room for improvement

Roadmap includes prioritized list of use-casesRoadmap includes prioritized list of use-cases

Continuous Risk Assessment is necessary at all Continuous Risk Assessment is necessary at all levelslevels Product DesignProduct Design Implementation Implementation OrganizationalOrganizational RHIO DomainRHIO Domain

Page 46: IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

48

IHE Web Site - http://www.ihe.netIHE Web Site - http://www.ihe.net Technical FrameworksTechnical Frameworks Technical Framework Supplements – Trial ImplementationTechnical Framework Supplements – Trial Implementation Calls for ParticipationCalls for Participation IHE Fact Sheet and FAQIHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for BuyersIHE Integration Profiles: Guidelines for Buyers IHE Connectathon ResultsIHE Connectathon Results Vendors’ Product Integration StatementsVendors’ Product Integration Statements

Sponsors’ IHE sitesSponsors’ IHE sites http://www.himss.org/IHE http://www.himss.org/IHE http://www.rsna.org/IHEhttp://www.rsna.org/IHE

John MoehrkeJohn Moehrke [email protected]@med.ge.com

More InformationMore Information