Access Control patient centric selective sharing Emergency Access Information Exchange

Transcription

1 Electronic Health Record Software Required Security Features and Recommendations for Technical Specifications of Single Source Contracts and RFI for the Behavioral Health Information Technology Grant Scope: the scope of this summary is the technical security features of the electronic health record itself, including anonymity, data encryption and integrity, authentication, access control, emergency access, information exchange, audit logging, non-repudiation, cyber-attacks, including denial of service and hacking through ransomware, worms, and viruses. These apply to all platforms on which EHR/EBS may be installed including servers, desktops, mobile devices, and on the web, and related cloud services. Out of scope: the summary does not include provider required information security planning including physical and buildings security, employee responsibilities, HIPAA/HITECH training, telecommunication systems, employee background checks, incident response, and breach notification. ISO is a security standard specifically tailored to healthcare and health informatics systems. There are many online references which can provide a very deep level of detail with regard to each of the following parameters which we recommend for inclusion in the technical specifications for single source contracts and the RFI for BHIT. 1. Anonymity and Pseudo-Anonymity Techniques-this refers to a general class of techniques to separate patient identifiers from the actual content of the health record which are joined through an identifier to protect patient anonymity. Typically a hash table and/or hash function is used along with a digital credentialing scheme to join tables of patient identifiers with patients personal health information in the provision of care. Optimal methods of K- anonymization are usually used. Anonymity and pseudo-anonymity techniques are useful when third parties (non-providers) must access de-identified patient information for purposes such as quality and financial reporting and research. These techniques are also particularly useful for dealing with CFR 42 covered information for mental health, substance use disorder, and HIV services. Overall, these techniques provide very strong protections but are not commonly implemented. 2. Data Encryption-the 128 or 256 bit encryption of electronic health record data to ensure security is common. In addition to PHI, identifiers, database primary keys, and metadata are also typically encrypted. Encryption methodologies typically utilize both symmetric keys and public key schemes to store data. Another important symmetric key scheme is AES, an algorithm adopted by the US government. Communications arising from electronic health records also must be securely encrypted, along with server authentication using a mutually trusted certification authority which is achieved through SSL (secure sockets layer), secure TSL (transport layer security), and other protocols. For cloud-based technologies the use of ciphertext policy attribute-based encryption (cp-abe) is implemented to assure security, for example, assuring that the cloud-based vendor cannot see or copy PHI. 3. Authentication Systems-digital signature schemes based on public key infrastructure (PKI) are ubiquitous in the field of electronic health record security. The use of digital rights management to control EHRs by licenses incorporates the use of two security certificates 1) the processor

2 security certificate that ensures cryptographic authentication to the machine and its unique hardware features and 2) the rights management account certificate which contains information related to the authentication of the user, bound to their unique identifiers for certain roles on the EHR system. Typical authentication schemes involve login/password combined with digital certificate, password and pin, smart card, token (RSA), fingerprint scanning, or other biometric methods. Other methodologies utilize physical location and the use of a web-based security certificate of a trusted organization. The use of digital certificates in healthcare clouds should be specified and presents additional challenges. 4. Access Control-most electronic health record systems utilize role-based access control (RBAC), which ensures that personal health information is only disclosed on a need to know basis by and to providers, administrators, billers, and third-party recipients. RBAC is a schema that assigns permissions and restrictions, which result in a complex, matrixed set of authorizations for individuals to operate on the electronic health record. The question of who decides user access roles is critical and has typically been left to the provider. However current movement in the field is for patients to decide which users (providers) have specific access. We ve codified this in our privacy policies which have enormous technical implications for security. In our many discussions about HCBS/HARP, DSRIP, Health Home, and RHIO PHI security, we ve identified the need for unified access control scheme that supports patient centric selective sharing, in the context of multiple EHRs and health information exchange. This is an enormous challenge. We should determine if our potentially preferred vendors have capabilities and are making progress in this area. 5. Emergency Access-if the patient s life is in danger, or they are unconscious, or the context of other well-defined safety risks, emergency access policies known as breaking the glass must be implemented. These must be technically specified at the hardware and software level in terms of near instantaneous adjustment of user roles and permissions. This is known as exception-based access control. Emergency access may be assigned to potential emergency practitioners/users as a role, or they may carry a second smart card, or be able to implement an overriding access control feature of the system. This may be credential based, or align with scopes of work and provided services such as involvement in crisis management. 6. Information Exchange-health information exchange is becoming more commonplace through cloud, web, or other dedicated transmission services such as use by our RIOS in New York State. Information is typically interchanged using the script language, XML, HL7, or shared database connections. It is essential at these have strong technical security features. Typical interface engines include InterSystems Health Share and Rhapsody which are configurable on our RHIOs. Standardization of security measures across larger systems of care has been a major challenge requiring global definitions a professional roles, patient consents, and critically semantic interoperable audit logs. Audit logs are covered in greater detail in the next section. Finegrained access control through a global delegation mechanism and an on-demand revocation system triggered by patients is essential in the near future for participation in HARP/HCBS Health Homes and DSRIP PPS. Distributed databases using anonymity features can help ensure

3 that patients can be treated by different providers without confidentiality breaches as defined by their preferences. 7. Audit Logs-audit logs have been required under HIPAA legislation since 1996 for all electronic systems containing PHI for the provision of care and billing. These logs include information regarding who accessed the EHR, what they created, edited, or modified, for what purpose, who received PHI, along with time stamping functions and security features that protect the audit logs themselves. For example, within OMH we have utilized a special Oracle table with PL-SQL triggers on the MHARS electronic health record system. These audit logs create tremendous processor overhead and storage requirements. It is necessary to audit access when break the glass procedures are implemented. Many investigations of medical practice and EHR security compromise analyze audit logs. Audit logging supports the concept of non-repudiation of actions taken by provider staff on a system containing PHI. All requests and systems responses for personal health information are also logged. An audit trail must capture authentication, access, delegation, proxy signing, searchable public and symmetric key encryption and retrieval, and access control related events such as revocation of privileges to the electronic health record. The need for audit logging extends to all devices on which PHI is present including those that a cloud-based. 8. Cyber-attacks-electronic health record and billing systems must have protections against cyberattacks, including hacking leading to denial of service and insertion of ransomware, worms, and viruses on EHR/EBS systems. These may be generally conceptualized as security features at each of the layers of the OSI seven layer model, which is a networking framework for implementing protocols. The seven layers include the physical, data link, network, transport, session, presentation, and application layers. On networks including clouds, and in the context of interoperability, these layers incorporate mobile features and additional concerns.

4 Dear software vendor, Security is a critical element for the HCBS Program. Please read the attached document Security Parameters BHIT Technical Specifications.docx received from the New York State Office of Mental Health (NYS-OMH) and respond the following questions which explore the security features currently present in your software 1. Anonymity and Pseudo-Anonymity Techniques a) List the Anonymity and Pseudo-Anonymity Techniques already incorporated into your software b) List the Anonymity and Pseudo-Anonymity Techniques your company is planning to incorporate within the next two year 2. Data Encryption a) List which types of Data Encryption are currently incorporated in your software At the server level At the client level b) Which security protocols (SSL, TSL, other) are being used for communication c) If your solution operates as cloud-based are you using cp-abe encryption? If not, how is your company securing the data? 3. Authentication Systems a) Which types of authentication systems are currently using in your solution? Please explain. 4. Access Control a) Does your software allow a patient centric selective option to choose which providers have access to their Personal Health Information Records? b) Does your software have the capacity to assign access control at the field level? For example, some fields with highly sensitive information (such as the associated with the CFR 42, Part 2) can be only be seen by a limited providers? c) The above question also applies when exchanging information with RHIOs, Health Homes or other Qualified Entities. 5. Emergency Access a) Has your software incorporated a Break-the-Glass security feature? b) If so, describe which is the procedure for emergency access? 6. Information Exchange a) Describe how your software ensures secure information exchange b) List which interface engines your software have interfaced with c) Does your software allow granularity on the global delegation as well as on-demand consent revocation by patients when exchanging information with RHIOs, Health Homes and/or DSRIP PPS entities? Questionnaire: Security Parameters and Technical Specifications for the BHIT Program Page 1

5 7. Audit Logs a) Describe the schemes used by your software in regards to audit logs b) Identify which schemes are enforced to each type of device used to access the solution c) What is the procedure for audit logs? Please explain. 8. Cyber-attacks a) Please detail how does your company implement security features to protect your software and data of your customer from cyber-attacks considering the following scenarios: a. Customers whose solutions are hosted at the customer s facilities b. Customers whose solution is hosted as a Software as a Service (SaaS) but in facilities that are not controlled and/or administered by your company c. Customers whose solution is hosted in facilities in which your company is directly responsible. b) How your software is protected against cyber-attacks when users access your solution using mobile devices such as laptops, tablets and smart phones? Please explain. Questionnaire: Security Parameters and Technical Specifications for the BHIT Program Page 2