IHE Security XDS as a case study - PowerPoint PPT Presentation

Loading...

PPT – IHE Security XDS as a case study PowerPoint presentation | free to download - id: 7bc58-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

IHE Security XDS as a case study

Description:

Register Document. Query Document. XDS Document Registry. ATNA Audit record repository ... Provide & Register Docs. XDS Document Repository. XDS. Document Repository ... – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 22
Provided by: johnf168
Learn more at: http://www.ihe.net
Category:
Tags: ihe | xds | case | security | study

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: IHE Security XDS as a case study


1
IHE Security XDS as a case study
  • ITI Technical Committee
  • Aug 3, 2006

2
What is a RHIO?
  • HIMSS RHIO A Regional Health Information
    Organization (RHIO) is a multi-stakeholder
    organization that enables the exchange and use of
    health information, in a secure manner, for the
    purpose of promoting the improvement of health
    quality, safety and efficiency.
  • Competing enterprises
  • Longitudinal view of the patients health history
  • Protect Privacy
  • Providing better care to patients
  • Promoting Safety and Quality

3
Privacy Needs
  • Protect against inappropriate disclosure
  • Provide an Accounting of Disclosures
  • Protect employee privacy
  • Resulting in compliance with Laws and Regulations
    by the Legal Entity
  • Assume Current EMR/EHR include Access Controls

4
XDS Security Use Cases
  • Prevent Indiscriminate attacks (worms, DOS)
  • Normal Patient that accepts XDS participation
  • Patient asks for Accounting of Disclosures
  • Protect against malicious neighbor doctor
  • Patient that retracts consent to publish
  • Provider Privacy
  • Malicious Data Mining
  • Access to Emergency data set
  • VIP (movie star, sports figure)
  • Domestic violence patient
  • Daughter with sensitive tests hidden from Parent
  • Sensitive topics mental health, sexual health
  • Legal Guardian (cooperative)
  • Care-Giver (assists w/ care)

5
Document Accessibility
Entries restricted to sexual health team
Private entries shared with GP
Entries accessible to administrative staff
Entries accessible to clinical in emergency
Entries accessible to direct care teams
Private entries shared with several named parties
Entries restricted to prison health service
Source Dipak Kalra prEN 13606-4
6
Security Models
  • Risk Assessment
  • Asset is the information in Registry all
    Repositories
  • Confidentiality, Integrity, and Availability
  • Patient Safety overrides privacy (most of the
    time)
  • Accountability
  • Access Control model -- Prevention
  • Audit Control model -- Reaction
  • Policy Enforcement
  • Mutually agree to enforce Policies
  • Enforcement of policies centrally

7
Affinity Domain Policy
  • Today there must be ONE policy
  • See IHE TF Volume 1 Appendix L XDS Affinity
    Domain Definition Checklist
  • IHE gives no direction on the content of this
    Policy
  • E.g. Patient allows general purpose healthcare
    information to be submitted, sensitive data will
    not be published. Only Healthcare Providers that
    are a member of that patients direct care team
    will be given access.
  • Policy must be enforceable by all the systems in
    the Affinity Domain
  • EHR RBAC capabilities must be considered
  • PHR portal must be able to enforce restrictions
  • Registry / Repositories must only talk to
    authorized systems

8
Classic n-Tier Security
Client / Browser
Application Server
Database
User Authentication User Interface
Business Logic Policy Enforcement
Data Index Data Values
9
Mapped to XDS
Registry
Repository A
Repository B
PIX Service
EHR- Workstation Browser
EHR System PHR Portal
PDQ Service
XDS Consumer
ATNA Service
Identity Svc
User Authentication User Interface
Business Logic Policy Enforcement
RBAC Svc
10
The Really Big Problem
  • The Registry is not the center, it is just a card
    catalogue to patient data.
  • Disclosure happens on Export
  • A Retrieve does result in a permanent copy of the
    Document.
  • The Document Consumer does agree to enforce
    policies forever

XDS Document Registry
XDS Document Repository
Register Document
Query Document
Retrieve Document
Provide Register Docs
PMS
11
Current Solution to Big Problem
  • Affinity Domain Policy (singular)
  • All actors that participate must agree to
    enforce these policies
  • XDS
  • Patient Centric Queries ? Queries result in ONE
    patient exposed
  • ATNA
  • Confidentiality, Integrity, Accountability
  • Accountability distributed
  • Access controls at point of care (sensitive to
    context)
  • Digital Signature Content Profile (DSIG)
  • Enhanced locally by
  • EUA
  • PWP
  • Application specific (Not IHE specified)
  • RBAC, PMAC

12
Accountability
PMS
ED Application
XDS Document Registry
PACS
Register Document
Query Document
EHR System
PACS
Retrieve Document
Provide Register Docs
Maintain Time
Lab Info. System
Maintain Time
Teaching Hospital
Maintain Time
Community Clinic
13
Accountability
Teaching Hospital
State run RHIO
PMS
ED Application
XDS Document Registry
PACS
Register Document
Query Document
EHR System
PACS
Retrieve Document
Provide Register Docs
Maintain Time
Lab Info. System
Maintain Time
Maintain Time
Community Clinic
14
Todays XDS Accountability
  • Mitigation against unauthorized use
  • Investigate Audit log for patterns and behavior
    outside policy. Enforce policy
  • Secure Node requires appropriate Access Controls
    to enforce at the enterprise by XDS Source and
    Consumers
  • Investigation of patient complaints
  • Investigate Audit log for specific evidence
  • ATNA Audit Repositories can filter and
    auto-forward
  • Support an Accounting of Disclosures
  • ATNA Report XDS-Export XDS-Import

15
XDS Security Use-Cases
  • Supported Today
  • Prevent Indiscriminate attacks (worms)
  • Normal Patient that accepts XDS participation
  • Patient asks for Accounting of Disclosures
  • Protect against malicious neighbor doctor
  • Patient that retracts consent to publish
  • Provider Privacy
  • Malicious Data Mining
  • Not directly supported with IHE technology
    (applications can provide this functionality in
    their feature e.g. Portals)
  • Access to Emergency data set ? all XDS open, or
    no access
  • VIP ? Dont publish, or use special domain
  • Domestic violence patient ? Dont publish any
  • Daughter with sensitive tests ? Dont publish,
    or use special domain
  • Sensitive topics ? Dont publish, or use
    special domain
  • Legal Guardian (cooperative) ? Local enforcement
  • Care Giver (assists w/ care) ? Local enforcement

16
Document Accessibility
Entries restricted to sexual health team
Private entries shared with GP
Entries accessible to administrative staff
Entries accessible to clinical in emergency
ü
Entries accessible to direct care teams
Private entries shared with several named parties
Entries restricted to prison health service
Source Dipak Kalra prEN 13606-4
17
XDR / XDM Key Technical Properties
  • Re-uses XDS approach for documents
  • SubmissionSet, DocumentEntry
  • XDS based XML meta-data w. limited extensions
  • XDR
  • Secure e-mail (ebMS over SMTP, S/MIME)
  • Optional on-line protocol (similar to XDS)
  • XDM
  • PDI like media profile with XDS meta-data
  • Potential association of XDS and PDI at the actor
    level (Document Source…)

18
Flexible Infrastructure Sharing, Sending and
Interchanging
Health Information Exchange or RHIO
XDS
Structured objects
Pull
Publish
Pull
XDR
XDM
19
Next Year Solution IHE-PCC
  • PCC Basic lists of Patient Consents
  • Small number of Basic Consents the patient could
    choose from (about 10)
  • Additive in nature, so it is clear which is most
    restrictive
  • Supporting Emergency Data Set, Clerical Data Set,
    Direct Caregiver Data Set.
  • Could include excluding/including organizations
    (enforced by Registry/Repository based on Node
    Certs)
  • Enables more than one Policy to be defined and
    claimed
  • Captured document with patient signature
  • FormatCode identifies the document that captures
    the event
  • Coded identifier to enable automated enforcement
  • Enables data to be marked as to be controlled by
    a specific policy (Confidentiality Code)
  • New XDS query can limit query results to those
    that match policy (Confidentiality Code) requested

20
Supported XDS Security Use-Cases
  • Prevent Indiscriminate attacks ? Mutual Auth TLS
  • Normal Patient that accepts XDS participation
  • Patient asks for Accounting of Disclosures ?
    informed by ATNA log
  • Protect against malicious neighbor doctor ?
    informed by ATNA log
  • Patient that retracts consent to publish ?
    Repository is local, manual
  • Provider Privacy ? User identity is not
    exposed
  • Malicious Data Mining ? queries are all patient
    based
  • Access to Emergency data set ? BPPC policy
  • VIP ? XDM, BPPC (Local enforcement)
  • Domestic violence patient ? BPPC policy (Local
    enforcement)
  • Daughter with sensitive tests ? XDM/XDP BPPC
    policy
  • Sensitive topics ? Dont publish, BPPC policy
  • Legal Guardian (cooperative) ? BPPC policy
    (Local enforcement)
  • Care Giver (assists w/ care) ? BPPC policy
    (Local enforcement)

21
Future possible topics
  • Federated User Identity (XUA)
  • Patient Access to
  • Sensitive health topics (you are going to die)
  • Low sensitivity (scheduling)
  • Self monitoring (blood sugar)
  • Authoritative updates / amendments / removal
  • Centralized Policy capabilities
  • Suggested Policies
  • Supporting Inclusion Lists
  • Supporting Exclusion Lists
  • Supporting functional role language
  • Central Policy Decision Point
  • Note Continued distributed Policy Enforcement
    Point near patient
  • Un-Safe Client machine (home-computer)

22
Conclusion
  • IHE provides the necessary basic security for XDS
    today
  • There is room for improvement
  • Roadmap includes prioritized list of use-cases
  • Continuous Risk Assessment is necessary at all
    levels
  • Product Design
  • Implementation
  • Organizational
  • Affinity Domain
  • TODO Include Risk Assessment Table and Map

23
More Information
  • IHE Web Site - http//www.ihe.net
  • Technical Frameworks
  • Technical Framework Supplements Trial
    Implementation
  • Calls for Participation
  • IHE Fact Sheet and FAQ
  • IHE Integration Profiles Guidelines for Buyers
  • IHE Connectathon Results
  • Vendors Product Integration Statements
  • Sponsors IHE sites
  • http//www.himss.org/IHE
  • http//www.rsna.org/IHE
  • http//www.acc.org/quality/ihe.htm
  • John Moehrke
  • John.Moehrke_at_med.ge.com
About PowerShow.com