OpenEMR CCHIT ToDo

This is an import of the working spreadsheet and table created by Visolve - I added columns for assignment and hours contributed.

<COLGROUP><COL WIDTH=259><COL WIDTH=75><COL WIDTH=559><COL WIDTH=75><COL WIDTH=88></COLGROUP> <TBODY>

<TD ST

OpenEMR Enhancement: CCHIT Certification 2009-10
Modularized failed criteria Vs What needs to be done in OpenEMR
Updated On: 9 July, 2009		Contact: vicare_engg@visolve.com
What needs to be done?	Criteria #	Criteria
Security Criteria			Assigned	Contributed
Authentication			Developer	Hours
First level of authentication is passed, but the scenario with network connectivity is yet to be done (at least displaying warning, if not connected)	SC 03.01	The system shall authenticate the user before any access to Protected Resources (e.g. PHI) is allowed, including when not connected to a network e.g. mobile devices.
Enforcing the strength of the password: (min chars & alphanumeric chars)	SC 03.02	When passwords are used, the system shall support password strength rules that allow for minimum number of characters, and inclusion of alpha-numeric complexity.
Enforcing Inactivity locks and resume with proper authentication	SC 03.03	The system upon detection of inactivity of an interactive session shall prevent further viewing and access to the system by that session by terminating the session, or by initiating a session lock that remains in effect until the user reestablishes access using appropriate identification and authentication procedures. The inactivity timeout shall be configurable.
Restricting the number of attempts tried to login & either lock account/delay next login	SC 03.04	The system shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The system shall protect against further, possibly malicious, user authentication attempts using an appropriate mechanism (e.g. locks the account/node until released by an administrator, locks the account/node for a configurable time period, or delays the next login prompt according to a configurable delay algorithm).
Administrative option to reset passwords	SC 03.05	When passwords are used, the system shall provide an administrative function that resets passwords.
Option to change the reseted passwords in the next login	SC 03.06	When passwords are used, user accounts that have been reset by an administrator shall require the user to change the password at next successful logon.
Authentication feedback information must be limited	SC 03.07	The system shall provide only limited feedback information to the user during the authentication.
Must support case-insensitive username while login	SC 03.08	The system shall support case-insensitive usernames that contain typeable alpha-numeric characters in support of ISO-646/ECMA-6 (aka US ASCII).
Allow user to change password after login and must comply with password strength rule	SC 03.09	When passwords are used, the system shall allow an authenticated user to change their password consistent with password strength rules (SC 03.02).
Encryption to be done in the DB side ( use AES/DES encryption alg to protect data)	SC 03.11	When passwords are used, the system shall use either standards-based encryption, e.g., 3DES, AES, or standards-based hashing, e.g., SHA1 to store or transport passwords.
System should have the ability to encrypt the data using 3AES/AES to store and send across the web	SC 03.11	When passwords are used, the system shall support the ability to protect passwords when transported or stored through the use of cryptographic-hashing with SHA1, SHA 256 or their successors and/or cryptographic-encryption with Triple Data Encryption Stand
Preventing the reuse of old password within the specified time frame	SC 03.12	When passwords are used, the system shall prevent the reuse of passwords previously used within a specific (configurable) timeframe (i.e., within the last X days, etc. - e.g. "last 180 days"), or shall prevent the reuse of a certain (configurable) number
Supporting 2-factor authentication	SC 03.13	The system shall support two-factor authentication in alignment with NIST 800-63 Level 3 Authentication. Note: This is to support the 21 CFR Parts 1300, 1304, et al. Electronic Prescriptions for Controlled Substances; Proposed Rule published on Friday, June 27, 2008, Federal Register / Vol. 73, No. 125.F11.
Backup/Recovery
Restore option – the system must restore to the previous state	SC 08.02	The system restore functionality shall result in a fully operational and secure state. This state shall include the restoration of the application data, security credentials, and log/audit files to their previous state.
Cron job : to take daily backup – for system availability	SC 08.03	If the system claims to be available 24x7 then the system shall have ability to run a backup concurrently with the operation of the application.
Documentation
Document regarding patches released, how to install etc should be present along with the product	SC 04.01	The system shall include documentation that describes the patch (hot-fix) handling process the vendor will use for EHR, operating system and underlying tools (e.g. a specific web site for notification of new patches, an approved patch list, special instru
Option to record system errors & its action and that document must be accessible to all users and administrators	SC 04.02	The system shall include documentation that explains system error or performance messages to users and administrators, with the actions required.
Document regarding the System capabilities ( no. of users, processors,no of records, network load etc) should be present	SC 04.03	The system shall include documentation of product capacities (e.g. number of users, number of transactions per second, number of records, network load, etc.) and the baseline representative configurations assumed for these capacities (e.g. number or type
Product installation and start-up document should be present along with the product	SC 04.04	The system shall include documented procedures for product installation, start-up and/or connection.
A document that shows minimum privileges for each role for each service and network protocols for each functionality	SC 04.05	The system shall include documentation of the minimal privileges necessary for each service and protocol necessary to provide EHR functionality and/or serviceability.
Document which states where there is any issues/conflicts in running security services and if so what should be done	SC 04.06	The system shall include documentation available to the customer stating whether or not there are known issues or conflicts with security services in at least the following service areas: antivirus, intrusion detection, malware eradication, host-based firewall and the resolution of that conflict (e.g. most systems should note that full virus scanning should be done outside of peak usage times and should exclude the databases.).
If the system requires any hardware, then that also should be documented	SC 04.07	If the system includes hardware, the system shall include documentation that covers the expected physical environment necessary for proper secure and reliable operation of the system including: electrical, HVAC, sterilization, and work area.
Document containing necessary software services, necessary protocols and it purposes, etc	SC 04.08	The system shall include documentation that itemizes the services (e.g. PHP, web services) and network protocols/ports (e.g. HL-7, HTTP, FTP) that are necessary for proper operation and servicing of the system, including justification of the need for that service and protocol. This information may be used by the healthcare facility to properly configure their network defenses (firewalls and routers).
Document that contains steps, which verifies that the product is properly installed	SC 04.09	The system shall include documentation that describes the steps needed to confirm that the system installation was properly completed and that the system is operational.
Document of guidelines for configuration, and use of security controls necessary to support secure & reliable operation	SC 04.10	The system shall include documentation available to the customer that provides guidelines for configuration and use of the security controls necessary to support secure and reliable operation of the system, including but not limited to: creation, modifica
Technical Services
The System should notice the user on installing any uncertified ( By free or commercial certification authority) software .	SC 05.01	The software used to install and update the system, independent of the mode or method of conveyance, shall be certified free of malevolent software (“malware”). Vendor may self-certify compliance with this standard through procedures that make use of compliance with this standard through procedures that make use of commercial malware scanning software.
System should have the option to integrate with UPS, etc. (to prevent corruption)	SC 05.02	The system shall be configurable to prevent corruption or loss of data already accepted into the system in the event of a system failure (e.g. integrating with a UPS, etc.).
System should protect the confidentiality of data transmitted (using 3AES, AES ency, through SSL,TLS etc)	SC 06.01	The system shall support protection of confidentiality of all Protected Health Information (PHI) delivered over the Internet or other known open networks via encryption using triple-DES (3DES) or the Advanced Encryption Standard (AES) and an open protocol such as TLS, SSL, IPSec, XML encryptions, or S/MIME or their successors.
There must be an option to encrypt the data and send through SSL	SC 06.03	For systems that provide access to PHI through a web browser interface (i.e. HTML over HTTP) shall include the capability to encrypt the data communicated over the network via SSL (HTML over HTTPS). Note: Web browser interfaces are often used beyond the perimeter of the protected enterprise network
There must be an option to protect the integrity of the data transmitted – implemented via hashing, open protocols like SSL,TLS or XML digital sign	SC 06.04	The system shall support protection of integrity of all Protected Health Information (PHI) delivered over the Internet or other known open networks via SHA1 hashing and an open protocol such as TLS, SSL, IPSec, XML digital signature, or S/MIME or their successors.
System must ensure the authenticity of the remote nodes	SC 06.05	The system shall support ensuring the authenticity of remote nodes (mutual node authentication) when communicating Protected Health Information (PHI) over the Internet or other known open networks using an open protocol (e.g. TLS, SSL, IPSec, XML sig, S/MIME).
System should encrypt the data using 3AES/AES while storing information in the removable devices	SC 06.06	The system, when storing PHI on any device intended to be portable/removable (e.g. thumb-drives, CD-ROM, PDA, Notebook), shall support use of a standards based encrypted format using triple-DES (3DES), or the Advanced Encryption Standard (AES), or their successors.
System should display a configurable warning message before accessing any health information.	SC 06.07	The system, prior to access to any PHI, shall display a configurable warning or login banner (e.g. "The system should only be accessed by authorized users"). In the event that a system does not support pre-login capabilities, the system shall display the banner immediately following authorization.
Access Control
The system should provide a control on innermost permission level like Read Write to each node of Acl	SC 01.01	The system shall enforce the most restrictive set of rights/privileges or accesses needed by users/groups (e.g. System Administration, Clerical, Nurse, Doctor, etc.), or processes acting on behalf of users, for the performance of specified tasks.
Ability of administrators to assign individual privileges to users	SC 01.02	The system shall provide the ability for authorized administrators to assign restrictions or privileges to users/groups.
Need to implement HL7 with role engineering models(Functional Roles,Structural Roles) to assist it in carrying out	SC 01.05	If role-based access control (RBAC) is supported, the system shall be able to support role based access control that is in compliance with the HL7 Permissions Catalog.
If RBAC is implemented it should satisfy the ANSI INCITS 359-2004.	SC 01.06	If role-based access control (RBAC) is supported, the system must be capable of operating within an RBAC infrastructure conforming to ANSI INCITS 359-2004, American National Standard for Information Technology – Role Based Access Control.
Audit
There must be an option for the administrator to add /remove the events log: 1. start/stop 2. user login/logout 3. session timeout+F10 4. account lockout 5. patient record created/viewed/updated/deleted 6. scheduling 7. query 8. order 9. node-authentication failure 10. signature create	SC 02.01	The system shall allow an authorized administrator to set the inclusion or exclusion of auditable events in SC 02.03 based on organizational policy & operating requirements/limits.
Definition of a logic to log all the events . Understanding the format of ATNA profile Transporting the logs stored either in text/in DB to the specified format	SC 02.02	The system shall support logging to a common audit engine using the schema and transports specified in the Audit Log specification of IHE Audit Trails and Node Authentication (ATNA) Profile.
Not all the events should be logged. Only the events which has some active role/causing/detective nature – Need to identify what are such events, and log it in the DB (need to create a schema) or in a text file	SC 02.03	The system shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed in the Appendix Audited Events. Note: The system is only responsible for auditing security events that it mediates. A mediated event is an event that the system has some active role in allowing or causing to happen or has opportunity to detect. The system is not expected to create audit logs entries for security events that it does not mediate.
Audited information log should contain date&time,component of the system,type of the event,who's identity,what is the result of the event.	SC 02.04	The system shall record within each audit record the following information when it is available: (1) date and time of the event; (2) the component of the system (e.g. software component, hardware component) where the event occurred; (3) type of event (including: data description and patient identifier when relevant); (4) subject identity (e.g. user identity); and (5) the outcome (success or failure) of the event.