Connecticut Ave NW, Washington, DC HISP Policy “HP” 1.0 Overview Policy Document available at DirectTrust.Org Presented by: Luis C. Maas III, MD, PhD Direct Project Connect-a-thon January 16, 2014

Connecticut Ave NW, Washington, DC Why DirectTrust Accreditation? Direct Messaging depends on trusted counterparties – By design, can only exchange with trusted Direct addresses – Market demands accredited HISPs, for confidence in exchange – Building pairwise contracts will not scale: a common set of requirements, signified by inclusion in a bundle of trusted anchors, is the most efficient way to grow interoperability  DirectTrust Network 2

Connecticut Ave NW, Washington, DC DirectTrust Accreditation: What is it? HISP accreditation demonstrates compliance with: – Direct Project Applicability Statement – HIPAA and HITECH, and all other federal and state laws Software management practices of HIPAA/HITECH apply to every HISP How PHI may be used is specified in every HISP’s own legal agreements with end users – Secure management of customers’ personal information For Certificate Authority and Registration Authority accreditation, existing active versions of DirectTrust Certificate Policy demand secure, industry standard practices of CAs/RAs 3

Connecticut Ave NW, Washington, DC Purpose of DirectTrust HISP Accreditation Set the minimum bar for HISP privacy and security, for the benefit of HISP end users + data exchange partners The added confidence in Direct exchange is expected to allow for rapid network growth from today’s DirectTrust Network of 14 HISPs: 4

Connecticut Ave NW, Washington, DC To The Nearly-Doubled DirectTrust Network expected in Q2, 2014: 5

Connecticut Ave NW, Washington, DC & Likely DirectTrust Network in 2015: 6

Connecticut Ave NW, Washington, DC Goals of the HP Clearly define the systems within a business constituting HISP services Establish the “measuring stick”: minimum administrative & technical requirements for Health Information Service Providers (HISPs) with regard to message and credential management and authentication to the system v1.0 of HP = current accreditation requirements (one exception noted later) 7

Connecticut Ave NW, Washington, DC HISP Definition-1 Direct Services cannot exist without a HISP ALWAYS part of HISP: – STA functions – Trust management – Certificate discovery – S/MIME interfaces – HISP side of edge protocol – End User private key stores – End User authentication – Maintain integrity of framework, ISSO functions 8

Connecticut Ave NW, Washington, DC HISP Definition-2 SOMETIMES part of HISP: – Provision Direct Addresses – Generate End User private keys – Operate SMTP server and/or POP/IMAP server – Operate DNS and/or LDAP for certificate discovery – Maintain End User message queues/mailboxes – Tools to create Direct message – Technical support 9

Connecticut Ave NW, Washington, DC HISP Definition-3 OUTSIDE the HISP/not in scope of HP: – CA and RA roles (covered in DirectTrust Certificate Policy) – Store/analyze EHR/PHR data – Other EHR functions – CDA processing/validation – Provider Directory – Use of Direct credentials for other purposes 10

Connecticut Ave NW, Washington, DC Classification of Direct Entities Covered Entity (CE) Business Associate (BA) Healthcare Entity (HE) Patient All four entities adhere to same HISP requirements, except Patient HISPs write data privacy policies rather than using BAA terms 11

Connecticut Ave NW, Washington, DC Privacy & Security Summary 1.HIPAA/HITECH (& other laws’) compliance by Direct entities governs privacy and security outside HISP boundary; this is outside the scope of DirectTrust 2.DirectTrust HISP Policy sets privacy and security requirements at edge and for access to user mailboxes via HIPAA/HITECH and other requirements – BAA in each HISP’s agreement describes HISP’s permitted use of PHI – Privacy Policies describe each Patient HISP’s permitted use of PHI – One of the above is required by DirectTrust, as appropriate 3.DirectTrust HISP Policy sets privacy and security requirements of message data via Direct Project and other requirements 1 2 HISP, Edge & User Mailboxes 3 Direct Messages Outside HISP Boundary Direct Exchange Counterparties, via SMTP 12

Connecticut Ave NW, Washington, DC Privacy & Security Summary Other data usage & processing outside scope of DirectTrust policies, but policy opinions are under development relating to: – Directories & Personal Information (Direct Directory Policy WG) – Patient HISPs (Patient & Consumer Participation WG) 13

Connecticut Ave NW, Washington, DC HISP Policy Requirements: Overview Infrastructure Data Privacy Policies Certificates Private Keys Physical Controls Software Controls & Processes Software Development Process Direct Project 14

Connecticut Ave NW, Washington, DC There’s More… Today’s overview covers the “MUST” requirements of the HISP Policy Many additional “SHOULDs”, recommendations, and Practice Notes not covered today 15

Connecticut Ave NW, Washington, DC Requirements: Infrastructure System diagram of essential HISP sites List of all hardware and software used w/ PHI Possess adequate physical resources Effective controls and procedures against malicious software Protection of internal databases, web servers Access controls on repositories 16

Connecticut Ave NW, Washington, DC Requirements: Data Privacy Policies Have contracts with customers that contain terms of BAAs when required by law, e.g. for every organization bound by HIPAA For non-Covered Entity customers, publish a privacy policy regarding authorized and unauthorized use of customer PHI, subcontractor terms, and PHI disposition on termination 17

Connecticut Ave NW, Washington, DC Requirements: Certificates Certificates conform to DirectTrust CP Ensure certificates in DNS or LDAP for discovery Protect private keys and use as certificate permits Guidelines for determining certificate revocation status—CRL required, OCSP optional HISP must request revocation if compromise of End User keys suspected Perform CA and RA roles or use an accredited CA and RA 18

Connecticut Ave NW, Washington, DC Requirements: Private Keys Perform private key risk assessment & mitigation ISSO ensures protection of keys & access lists Document how different LoAs supported; operate all infrastructure at highest LoA supported Hardware & software storing end user private keys must be well protected 19

Connecticut Ave NW, Washington, DC Requirements: Physical Controls Protect equipment from unauthorized access Only authorized HISP personnel may access equipment Implement & document procedures limiting access to facilities, including role-based access to software Document physical modifications to facilities that impact security Audit trail on equipment containing PHI Policies & procedures for final disposition of PHI and hardware/media/paper on which stored 20

Connecticut Ave NW, Washington, DC Multiple roles are defined so that malicious activity requires multiple parties’ involvement; must have staff to fill all roles and ensure relevant training—at minimum annually for those with access to PHI Maintain user access list to PHI Policies & procedures ensuring HIPAA compliance, federal, & state laws, archived 6 years Authenticate End Users and intermediate systems at LoA of HISP infrastructure Policies restricting personal, unlicensed, unapproved software Documented policies for workstations that may access PHI Requirements: Software Controls & Processes-1 21

Connecticut Ave NW, Washington, DC HISP employees, persons, software programs may access PHI only as needed, based on procedure used to determine initiation & termination of this purpose; policies must prevent unauthorized access by those without purpose Procedures to document, review, modify user access to workstation, transaction, program, or process Unique user identities for system access Inactivity timeouts Requirements: Software Controls & Processes-2 22

Connecticut Ave NW, Washington, DC Hybrid entities must protect PHI in healthcare component from other components of org. Hybrid entities must document healthcare component Sanctions within HISP for non-compliance with security policies BAAs are required of HISP contractors handling PHI; several specific stipulations Requirements: Software Controls & Processes-3 23

Connecticut Ave NW, Washington, DC Audit logs relating to security of HISP are made available during compliance audits PHI risk assessment must be performed Quarterly internal vulnerability assessment with improvement process; annually by 3 rd party Maintain written records of actions required by law for 6 years Procedures to respond to & document actual or suspected security issues Written disaster recovery policy Annual criticality analysis of contingency plan Requirements: Software Controls & Processes-4 24

Connecticut Ave NW, Washington, DC Security & breach notification procedures Procedure for secure facility access for data restoration & access to PHI during emergency PHI backup, if PHI is stored; additionally before equipment moved Configuration standards of systems involving PHI & workstations that access those systems No unencrypted PHI on PCs, consumer devices, or removable media Appropriate security for wireless networks Firewall configured to protect system integrity Monitored/blocked & alarmed intrusion detection Requirements: Software Controls & Processes-5 25

Connecticut Ave NW, Washington, DC Requirements: Software Development Process Documented software development policies Formal change management framework Have a process to evaluate and respond to new state and federal regulations 26

Connecticut Ave NW, Washington, DC HISP Policy Requirements: Direct-1 Message integrity checking Messages protected by HIPAA privacy rules SSL/TLS or equivalent edge encryption Documentation of message access methods Deliver messages without diverting or redistributing except for backup or as required by regulations Handling of untrusted messages 27

Connecticut Ave NW, Washington, DC HISP Policy Requirements: Direct-2 Document how trust can be configured for customers Perform authentication, encryption, trust verification, and acknowledgement of responsibility to deliver messages using SMTP as in the Applicability Statement Support DNS and LDAP for certificate discovery Perform STA functions per Applicability Statement and Certificate Discovery for Direct Project IG If one way trust is enabled for send or receive, must be able to receive or transmit MDNs with counterparty Counterparty HISPs may not be charged to exchange messages with end users 28

Connecticut Ave NW, Washington, DC HISP Policy Requirements: Direct-3 MDNs: – 1 hour response time for Processed/Dispatched else Fail recommended – Interoperability Note: Dispatched New requirement not in v 1.0 DTAAP criteria and not in 2014 MU2 criteria: – Messages must be sent wrapped and HISPs must be capable of receiving wrapped messages 29

Connecticut Ave NW, Washington, DC HISP Policy Q&A DirectTrust Security & Trust Compliance workgroup meets on Wednesdays at Noon PST 30