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 April 7, 2008 April 7, 2008
39
Embed
IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
April 7, 2008April 7, 2008
2
AgendaAgenda
Who is IHEWho is IHE
Overall Security ModelOverall Security Model
Deep diveDeep dive
HITSP HITSP
GapsGaps
Conclusion Conclusion
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.
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
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
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.
8
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
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
14
RHIO Domain PolicyRHIO Domain PolicyToday there must be ONE set of policiesToday there must be ONE set of policies
XDS Affinity Domain Definition Checklist XDS Affinity Domain Definition Checklist 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
15
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
Identity and AccountabilityIdentity and Accountability
19
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
20
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
21
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
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
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
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.
31
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
Care Giver (assists w/ care) Care Giver (assists w/ care) BPPC policy (Local enforcement) BPPC policy (Local enforcement)
38
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
39
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
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
41
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