HIPAA Guidance API Security Task Force February 22, 2016 Office for Civil Rights 1

HIPAA Access Guidance Marissa Gordon-Nguyen February 22, 2016

Fact Sheet Scope FAQs Form and Format and Manner of Access FAQs Timeliness FAQs Other FAQs In Development More on fees and directing access to 3 rd parties Components 3

Access/copy upon request – By individual or personal representative Designated record set(s) – Group of records maintained by or for covered entity FACT SHEET General Right 4

EHR and/or paper medical record Other medical, billing, payment, enrollment, claims records Clinical laboratory test reports X-rays, other images Wellness and disease management program information Clinical case notes Old/archived PHI Designated record set(s) held by Business Associates SCOPE FAQs Examples of information subject to access 5

– Quality assessment or improvement records – Patient safety activity records – Business planning – Provider performance evaluations – Psychotherapy notes – Information compiled for civil, criminal, or administrative action or proceeding BUT Included: Underlying PHI relied on in developing such records FACT SHEET Examples of excluded information: 6

Requiring a written request – CE may require requests in writing, including on CE’s form – Must inform individuals of the requirement – CE may offer option of electronic request – Cannot create a barrier to or unreasonably delay access Verification – Reasonable steps to verify identity – Oral or written verification; authentication controls if electronic – Cannot create a barrier to or unreasonably delay access FACT SHEET Requests for Access 7

Unreasonable measures – Requiring individuals to go to office – Requiring individuals to use web portal – Requiring individuals to mail an access request FACT SHEET Requests for Access, continued 8

Timeliness – No later than within 30 days from when request was received, either by the CE or its BA – If unable to meet 30 days, CE may extend to 60 days Must notify individual within initial 30 days Only one extension per access request FACT SHEET Providing Access 9

Form and Format and Manner of Access – Provide in form and format requested if readily producible – Requests for paper copies Provide paper copy – Requests for electronic copies If PHI maintained only on paper, provide electronic copy if readily producible. If not, in readable hard copy or other form and format per agreement with individual. If requested PHI maintained electronically, must provide access in electronic form and format requested, if readily producible. If not, in agreed upon alternative electronic format. If individual refuses every offered electronic format, provide paper. FACT SHEET Providing Access 10

If CE uses Certified EHR Technology, electronic PHI is readily producible CEs can use View, Download, Transmit mechanisms to fulfill access requests if individual requests or accepts Individual always retains right to access PHI in a DRS that is not available through CEHRT FORM & FORMAT & MANNER FAQs Access and Certified EHR Technology 11

FACT SHEET Fees for copies – Reasonable, cost-based Labor for copying PHI Supplies for creating copy Postage, if mailed Preparation of explanation or summary, if individual agrees – Does not include* Verification Documentation Search/retrieval Maintaining systems Recouping capital Other costs * Even if authorized by state law Providing Access, continued 12

Questions? 13 More Information

HIPAA Guidance for Health App Developers Linda Sanches February 22, 2016

Available on OCR’s portal for engaging app developers, To help app developers understand when they may be acting as a business associate of a covered entity, the guidance offers 6 scenarios, describing a range of relationships between the developer and the covered entity Offers key questions for an API vendor and other HIT organization to consider Three sample scenarios follow Health app developer guidance OCR Health App Developer Guidance 15

These scenarios address two questions under the Health Information Portability and Accountability Act (HIPAA): How does HIPAA apply to health information that a patient creates, manages or organizes through the use of a health app? When might an app developer need to comply with the HIPAA Rules? Health app developer guidance Health App Use Scenarios & HIPAA 16

Scenarios address the application of HIPAA to the app developer. In all cases in which a covered entity is transmitting PHI, either itself or using a business associate, it must apply reasonable safeguards to protect the information and nothing in the analyses below relieves covered entities (e.g., providers) of their own, independent obligation to comply with HIPAA (for example, to execute BAAs, Privacy Rule use & disclosure limitations, transmission security) Health app developer guidance Covered entity obligations 17

if the developer is creating or offering the app on behalf of a covered entity (or one of the covered entity’s contractors) – and in that case the developer is required to comply with certain provisions of the HIPAA Rules, including entering into a business associate agreement with the covered entity. In general, a business associate is a person [or entity] who creates, receives, maintains or transmits protected health information (PHI) on behalf of a covered entity or another business associate. Health app developer guidance An app developer may be a business associate 18

So, most vendors or contractors (including subcontractors) that provide services to or perform functions for covered entities that involve access to PHI are business associates. A company that has access to PHI through a covered entity to provide and manage a personal health record or patient portal offered by the covered entity to its patients or enrollees is a business associate. Health app developer guidance Vendors and ePHI 19

Scenario Based on the Facts Presented in the Scenario, Is App Developer a HIPAA Business Associate? Consumer downloads a health app to her smartphone. She populates it with her own information. For example, the consumer inputs blood glucose levels and blood pressure readings she obtained herself using home health equipment. No. Developer is not creating, receiving, maintaining or transmitting protected health information (PHI) on behalf of a covered entity or another business associate. The consumer is using the developer’s app to help her manage and organize her information without any involvement of her health care providers. Health app developer guidance Sample Scenario 1 20

Scenario Based on the Facts Presented in the Scenario, Is App Developer a HIPAA Business Associate? Consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor’s EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app. No. Developer is not creating, receiving, maintaining or transmitting protected health information (PHI) on behalf of a covered entity or another business associate. Instead, the consumer obtains health information from her provider, combines it with health information she inputs, and uses the app to organize and manage that information for her own purposes. There is no indication the provider or a business associate of the provider hired the app developer to provide or facilitate this service. Health app developer guidance Sample Scenario 2 21

Scenario Based on the Facts Presented in the Scenario, Is App Developer a HIPAA Business Associate? At direction of her provider, patient downloads a health app to her smart phone. Provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information the patient inputs is automatically incorporated into provider EHR. Yes, the developer is a business associate of the provider, because it is creating, receiving, maintaining and transmitting protected health information (PHI) on behalf of a covered entity. In this case, the provider contracts with the app developer for patient management services that involve creating, receiving, maintaining and transmitting PHI, and the app is a means for providing those services. Health app developer guidance Scenario 3 22

Does your health app create, receive, maintain, or transmit identifiable information? Who are your clients? How are you funded? – Are your clients covered entities? e.g., – hospitals, doctor’s offices, clinics, pharmacies, or other health care providers who conduct electronic transactions; – health insurance issuers; health or wellness program related to a health plan offered by an employer Were you hired by, or are you paid for your service or product by, a covered entity? Or another business contracted to a covered entity? Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain or disclose information related to a patient or health plan member? Health app developer guidance Guidance provides key questions, including: 23

HIPAA Security Rule and Application Programming Interfaces Nicholas Heesters February 22, 2016

Ensure the confidentiality, integrity, and availability of all ePHI the CE or BA creates, receives, maintains, or transmits. Protect against reasonably anticipated threats or hazards to the security and integrity of ePHI. Protect against any reasonably anticipated uses or disclosures of ePHI not permitted or required by the Privacy Rule. Ensure compliance with the Security Rule by the workforce. Security Rule and APIs Security Rule General Requirements 25

(d)(1): Authentication, Access Control and Authorization -> (a)(1): Access Controls and (d): Person or Entity Authentication (d)(9): Trusted Connection -> (c): Integrity and (e)(2)(ii): Encryption (d)(10): Auditing Actions or (d)(2): Auditable Events -> (b) Audit Controls Security Rule and APIs Technical Safeguards Mapping to API Certification Criteria 26

Implement technical procedures to allow access to ePHI only to those persons or software programs granted access rights. Addressable Implementation Specifications Unique User IDs Emergency Access Automatic Logoff Encryption and Decryption Security Rule and APIs (a)(1): Access Controls 27

Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. Security Rule NPRM would have required use of at least one of: biometric, password, PIN, telephone callback or use of a physical token. These requirements were removed in recognition that many mechanisms available for authentication such that entities could use whatever mechanism they determined was reasonable and appropriate. Security Rule and APIs (d): Person or Entity Authentication 28

Implement procedures to protect ePHI from improper alteration or destruction. Addressable Specification: Authenticate ePHI: Could be accomplished via hashing mechanism (i.e., HMAC) Security Rule and APIs (c): Integrity 29

Implement a mechanism to encrypt ePHI whenever deemed appropriate. Guidance on rendering electronic transmissions of PHI unusable, unreadable, or indecipherable include the use of appropriate TLS/SSL solutions (should comply with applicable NIST special publication guidance) or an encryption solution which is FIPS verified. Security Rule and APIs (e)(2)(ii): Encryption 30

Implement a mechanism to encrypt ePHI whenever deemed appropriate. Guidance on rendering electronic transmissions of PHI unusable, unreadable, or indecipherable include the use of appropriate TLS/SSL solutions (should comply with applicable NIST special publication guidance) or an encryption solution which is FIPS verified. Security Rule and APIs (e)(2)(ii): Encryption 31

Implement hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Security Rule and APIs (b) Audit Controls 32