Presentation on theme: "IHE Security XDS as a case study"— Presentation transcript:
1IHE Security XDS as a case study John MoehrkeGE HealthcareIHE ITI Technical Committee MemberHITSP Co-Chair - Security Privacy and Infrastructure CommitteeJuly 15, 2008
2AgendaWho is IHEOverall Security ModelDeep diveGapsConclusion
3What Is IHE?IHE is a collaborative response to healthcare IT market requirements for system integration.Develop standards-based implementation specifications called profiles.Useful subsets of one or more standardsTested at ConnectathonsDemonstrated at HIMSS, RSNA, and ACC showsCorrect known integration problems.Intra-enterprise and multi-enterprise scopeSatisfy emerging market needs & prevent new problems.EHR & government drivenRegional and national scopeBuild trust, collegiality, effectiveness among vendors, providers, and other stakeholders.
4What 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 enterprisesLongitudinal view of the patient’s health historyProtect PrivacyProviding better care to patientsPromoting Safety and QualityAka: SNO, HIN, HIE,IHE: Affinity Domain
5Affinity Domain -- Policies International PoliciesCountry-Specific PoliciesHorizontal Industry PoliciesEnterprise PoliciesIHE – leverages/profilesOECD GuidelinesOn TransborderFlowsUS-HIPAAEU-EC95/46JP-ActMedical ProfessionalSocietiesBackup &RecoveryExamples
6RHIO: Document based Persistence, Stewardship, Captures the conclusion / summary of an episodeStewardship,Long term maintenance (patients life 100+ years)Potential for Authentication, andWhich Doctor’s conclusion or opinionWhat predicate data or knowledgeWholeness.Integrity, completeness, inclusive,
7XDS Security Use Cases Prevent Indiscriminate attacks (worms, DOS) Normal Patient that accepts XDS participationPatient asks for Accounting of DisclosuresProtect against malicious neighbor doctorPatient that retracts consent to publishProvider PrivacyMalicious Data MiningAccess to Emergency data setVIP (movie star, sports figure)Domestic violence victimDaughter with sensitive tests hidden from ParentSensitive topics: mental health, sexual healthLegal Guardian (cooperative)Care-Giver (assists w/ care)
8Document Accessibility Entries restricted to prison health serviceEntries restricted to sexual health teamEntries accessible to administrative staffEntries accessible to clinical in emergencyPrivate entries shared with GPPrivate entries shared with several named partiesEntries accessible to direct care teamsSource: Dipak Kalra & prEN
9RBAC table Sensitivity Functional Role Billing Information Administrative InformationDietary RestrictionsGeneral Clinical InformationSensitive Clinical InformationResearch InformationMediated by Direct Care ProviderAdministrative StaffXDietary StaffGeneral Care ProviderDirect Care ProviderEmergency Care ProviderResearcherPatient or Legal Representative
10Document Accessibility Inside EntIn HIEThere are many different possible ways to layout the RBAC permissions across data. Including different views based on if the data is being accessed wholely inside an enterprise or across a HIE.
12Basic Patient Privacy Consents Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to:Record the patient privacy consent(s),Mark documents published to XDS with the choice of patient privacy consent that was used to authorize the publication,Enforce the privacy consent appropriate to the use.Builds upon the ATNA security infrastructure
13Basic Patient Privacy Consents Value Proposition an Affinity Domain candevelop privacy policies,and implement them with role-based or other access control mechanisms supported by edge/EHR systems.A patient canBe made aware of an institution privacy policies.Have an opportunity to selectively control access to their healthcare information.
14Basic Patient Privacy Consents Standards and Profiles Used Key PropertiesHuman Readable ConsentsMachine ProcessableSupport for standards-based Role-Based Access ControlStandardsCDA Release 2.0XDS Scanned DocumentsDocument Digital SignatureCross Enterprise Document Sharing (XDS.a, XDS.b, XDR, and XDM)
18Basic Consent – Publication controls Previous slides presumed publication was allowed, here we show that Basic consent could be used to prevent publicationConsents can control what gets published, and what is too sensitive to publishConsents can also enable PHR access to the HIEOther examples would be to identify VIP patient’s data to not automatically publish
19Document Level controls ‘confidentialityCode’ Must get explicit per-use consentDuring publication the documents can be labeled with appropriate uses using the confidentialityCode.This is informed by resulting RBAC policies and consents.
21XDS Scenario + use of ATNA & CT Physician OfficeEHR SystemTeaching HospitalPACSED ApplicationEHR SystemPMSXDS Document RepositoryCommunity ClinicLab Info. SystemPACSXDS Document RegistryQuery DocumentRegister DocumentSecured MessagingLets lift the cover and get a peek into some of the details that enable secured sharing of health records.Animated, but automatic, only two clicks:First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate securitySecond Click: serach documents, retrieve them and impoirt them into the community clinic EMR.Retrieve DocumentProvide & Register DocsMaintain TimeATNA Audit record repositoryCT Time serverMaintainTimeRecord AuditEventMaintainTimeRecord AuditEventRecord AuditEvent
22ATNA Security Model(1) Dual Authenticated Links Secured Node Physician OfficeEHR SystemTeaching HospitalPACSED ApplicationEHR SystemDual Authenticated LinksPMSXDS Document RepositoryCommunity ClinicLab Info. SystemPACSXDS Document RegistryXDS Document RepositoryLets lift the cover and get a peek into some of the details that enable secured sharing of health records.Animated, but automatic, only two clicks:First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate securitySecond Click: serach documents, retrieve them and impoirt them into the community clinic EMR.XDS Document RepositoryProvide & Register Docs
23IHE RHIO Solution RHIO boundary Teaching Hospital State run RHIO Physician OfficeEHR SystemTeaching HospitalState run RHIOPatientIDX-refPMSED ApplicationXDS Document RepositoryXDS Document RegistryPACSQuery DocumentRegister DocumentExplain the link between audit logs and accountability.EHR SystemPACSRetrieve DocumentProvide & Register DocsATNA Audit record repositoryLab Info. SystemATNA Audit record repositoryCT Time serverATNA Audit record repositoryCommunity Clinic
24Security Models Risk Assessment Accountability Policy Enforcement Asset is the information in Registry & all RepositoriesConfidentiality, Integrity, and AvailabilityPatient Safety overrides privacy (most of the time)AccountabilityAccess Control model -- PreventionAudit Control model -- ReactionPolicy EnforcementMutually agree to enforce PoliciesEnforcement of policies centrally
25RHIO Domain Policy XDS Affinity Domain Definition Checklist See Template for XDS Affinity Domain Deployment PlanningIHE gives no direction on the content of this PolicyE.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 RHIO DomainEHR RBAC capabilities must be consideredPHR portal must be able to enforce restrictionsRegistry / Repositories must only talk to authorized systemsAppendix L: XDS Affinity Domain Definition ChecklistThe concept of an XDS Affinity Domain is defined in ITI TF-1:10 and Appendix K. This informative appendix summarizes the key policies that need to be agreed to in order to deploy a EHR-LR document sharing environment.L.1 Configuration of an XDS Affinity DomainA number of systems implementing IHE Actors defined in the XDS Integration Profile need to be identified and configured to communicate. This includes defining addressing information and ATNA Secured Node certificate:1. Identify the system that will support the Document Registry Actor.2. Identify the systems that will support the Document Repository Actors.3. Identify the systems that will support Document Source and/or Document Consumer Actors.L.2 Patient IdentificationInitialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper patient identification information:1. Assign an Assigning Authority (OID) for the XDS Affinity Domain Patient Id Domain.2. Assign an Assigning Authorities (OID) for the each one the Local Patient Id Domains in which the EHR-CR Document Source and/or Document Consumer operate.3. Identify the system that will support the Patient Identity Source and if some of the systems that support Document Source and/or Document Consumer Actors also support a Patient Identity Cross-reference Manager (needs to receive a patient identity feed Transaction).L.3 XDS Registry Related VocabulariesInitialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper vocabulary information:1. Select and initialize the XDS Document Registry as well as the Document Sources and/or Document Consumers with the vocabulary definitions specified in Registry Enforcement (ITI TF-2: ) where either the Coding Scheme or the Coding Scheme/Code Values are enforced.L.4 Document Sharing Practice Policies1. Define the care events and the corresponding expected level of information that is expected to be shared within the EHR-LR.2. Define the usage policies for XDS Folder (creation and update) in the selected care pathways supported.L.5 XDS Document Content1. For each Document Format Code Value, establish the necessary interoperability agreements (e.g. by selecting IHE Document Content Profiles) to ensure that the Document Consumers may find (e.g. Document UniqueId structure) and process the XDS Documents content (e.g. MIME type, template definitions, archetypes, etc.) they retrieve from the XDS Repositories of the XDS Affinity Domain.L.6 Document Update and Maintenance PoliciesDocument Sources are responsible for the on-going accuracy (custodianship) of the XDS Documents they have elected to shared in the EHR-LR supported by the Affinity Domain. This includes:1. Replacement of documents in the EHR-LR2. Cases and means to possibly delete documents in the EHR-LRL.7 Security and Privacy Policies1. Establish agreed policies and procedures among care delivery organizations in the Affinity Domain. In particular address security considerations in ITI TF-2:Appendix K.2. Establish operational security infrastructure, including certificate exchange.3. Maintain operational security infrastructure, configuration management, audit management, periodic inspections, etc.
26IHE-XDS Infrastructure Components Document Registry (XDS) – Queryable index of metadata and references to all documents shared within a connected community (XDS Affinity Domain)Document Repository (XDS) – Supports storage and retrieval of clinical information (as documents). May be centralized or distributed.Patient Identifier Cross Reference Manager (PIX) – Reconciles information on patients from multiple domains to a single, cross referenced set of IDs for each given patient.Patient Demographics Supplier (PDQ) – Returns demographic information and identifiers for patients based on specified demographic criteria.Audit Record Repository (ATNA) – Receive audit records from other actors and securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt communications.Cross Enterprise User Assertion (XUA) – Mechanism for User Identity federationBasic Patient Privacy Consents (BPPC) – Providing for Patient Privacy dimension of Access control including Capturing Patient Consent including support for Opt-In and Opt-OutTime Server (CT) – Provides consistent definition of date/time enabling time synchronization across multiple systems. Enables events associated with patients to be sorted reliably in chronological order.
27Security & Privacy Controls IHE ProfileAccountabilityIdentification and AuthenticationData AccessConfidentialityData IntegrityNon-RepudiationPatient PrivacyAvailabilityAudit Trails and Node AuthenticationDBasic Patient Privacy ConsentsIConsistent TimeEnterprise User AuthenticationCross-Enterprise User AssertionDocument Digital SignatureCross-Enterprise Document SharingCross-Enterprise Document Reliable MessagingCross-Enterprise Document exchange on MediaPersonnel White Pages
29Cross-Enterprise User Assertion Value Proposition Extend User Identity to Affinity DomainUsers include Providers, Patients, Clerical, etcMust supports cross-enterprise transactions, can be used inside enterpriseDistributed or Centralized Identity management (Directories)Provide information necessary so that receiving actors can make Access Control decisionsAuthentication mechanism usedAttributes about the user (roles)Does not include Access Control mechanismProvide information necessary so that receiving actors can produce detailed and accurate Security Audit Trail
30Cross-Enterprise User Assertion Technical Solution Initial scope to XDS.b Stored Query and RetrieveRelies on Web-ServicesEasily extended to any Web-Services transactionsLeverage WS-I Basic Security Profile 1.1Use SAML 2.0 Identity AssertionsDoes not constrain ‘how’ the Assertion was obtainedSupporting Liberty Alliance, WS-Trust, and SAMLDefine grouping behavior with EUA and ATNA
31Four Identity Assurance Levels OMB E-Authentication Guidance establishesfour assurance levels forconsistent application of E-Authenticationacross gov’tLevel 4Level 3Level 2Level 1Little 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 levelNIST SP800-63ElectronicAuthenticationtechnical guidancematches technologyto each assurance levelSlide c/o David Temoshok and GSA
32Security Considerations: Four Identity Assurance Levels Increased $ CostMulti-Factor TokenPKI/ Digital SignatureKnowledge-BasedVeryStrong PasswordHigh-HighPIN/User IDMediumLowSlide c/o David Temoshok and GSAAccess toSummary ofClinical researchAccess toLocalEHR/EMRVerificationOf DataTranscriptionRemoteClinicalEntryIncreased Need for Identity Assurance
33Cross-Enterprise User Assertion Implementation Example EHR(ATNA Secure Node)XDS RegistryXDS Consumer(ATNA Secure Node)PatientDataX-ServiceUserX-IdentityProviderXUA =Web-Services Security+ SAML AssertionsXUA AssertionAudituser authproviderAuditLogUserAuthKey:Original TransactionTLS Protections
34Distributed Access Control – enabled by XUA XDS DocumentConsumerXDS RegistryAccessControlBXDS DocumentConsumerXDS RegistryAccessControlAccessControlCXDS DocumentConsumerXDS RegistryAccessControlAccessControlAccessControl
36Today’s XDS Accountability Mitigation against unauthorized useInvestigate Audit log for patterns and behavior outside policy. Enforce policySecure Node requires appropriate Access Controls to enforce at the enterprise by XDS Source and ConsumersInvestigation of patient complaintsInvestigate Audit log for specific evidenceATNA Audit Repositories can filter and auto-forwardSupport an Accounting of DisclosuresATNA Report: XDS-Export + XDS-ImportThe ATNA audit log includes enough information to detect a potential problem. Where enough information is not available in ATNA, the results can be used to enable forensic logs if they are available.The ATNA Audit Repository must protect the audit log appropriately, and provide the necessary tools to enable the necessary functionality and reporting.
37Centralized Accountability RHIO boundaryPhysician OfficeEHR SystemPMSED ApplicationXDS Document RepositoryXDS Document RegistryPACSQuery DocumentRegister DocumentExplain the link between audit logs and accountability.EHR SystemPACSRetrieve DocumentProvide & Register DocsMaintain TimeLab Info. SystemATNA Audit record repositoryCT Time serverMaintainTimeTeaching HospitalMaintainTimeCommunity Clinic
38Distributed Accountability RHIO boundaryPhysician OfficeEHR SystemTeaching HospitalState run RHIOPMSED ApplicationXDS Document RepositoryXDS Document RegistryPACSQuery DocumentRegister DocumentExplain the link between audit logs and accountability.EHR SystemPACSRetrieve DocumentProvide & Register DocsATNA Audit record repositoryMaintain TimeLab Info. SystemATNA Audit record repositoryCT Time serverMaintainTimeMaintainTimeATNA Audit record repositoryCommunity Clinic
44Supported XDS Security Use-Cases Prevent Indiscriminate attacks Mutual Auth TLSNormal Patient that accepts XDS participationPatient asks for Accounting of Disclosures informed by ATNA logProtect against malicious neighbor doctor informed by ATNA logPatient that retracts consent to publish Repository is local, manualProvider Privacy User identity is not exposedMalicious Data Mining queries are all patient basedAccess to Emergency data set BPPC policyVIP XDR/M, BPPC (Local enforcement)Domestic violence victim BPPC policy (Local enforcement)Daughter with sensitive tests XDR/M BPPC policySensitive topics Don’t publish, BPPC policyLegal Guardian (cooperative) BPPC policy (Local enforcement)Care Giver (assists w/ care) BPPC policy (Local enforcement)
45Document Accessibility Entries restricted to sexual health teamPrivate entries shared with GPEntries accessible to administrative staffEntries accessible to clinical in emergencyüEntries accessible to direct care teamsPrivate entries shared with several named partiesEntries restricted to prison health serviceSource: Dipak Kalra & prEN
46Gaps for potential future development Better coded vocabulary for confidentiality codesComplex policies on a document by document basisExtension to objects other than XDS (e.g. DICOM)Patient Access toSensitive health topics (you are going to die)Low sensitivity (scheduling)Self monitoring (blood sugar)Authoritative updates / amendments / removalComplex Privacy ‘consent’ Policy capabilitiesSupporting Inclusion ListsSupporting Exclusion ListsExceptions, and ObligationsSupporting functional role languageAccess Control ServiceCentralized PoliciesPolicy Decision Point / Policy Enforcement PointsAccounting of Disclosures reports, alerts, messagingTo support reporting to the ‘consumer’ when their data is accessedUn-Safe Client machine (home-computer)
47Conclusion IHE provides the necessary basic security for XDS today There is room for improvementRoadmap includes prioritized list of use-casesContinuous Risk Assessment is necessary at all levelsProduct DesignImplementationOrganizationalRHIO Domain
48More Information IHE Web Site - http://www.ihe.net Sponsors’ IHE sites Technical FrameworksTechnical Framework Supplements – Trial ImplementationCalls for ParticipationIHE Fact Sheet and FAQIHE Integration Profiles: Guidelines for BuyersIHE Connectathon ResultsVendors’ Product Integration StatementsSponsors’ IHE sitesJohn Moehrke