Difference between revisions of "MU-Security"

Revision as of 03:28, 23 February 2010

1. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information.

VistA does this using the new person file and that same number is tracked through the use of VistA as the DUZ and it is used for both permitting access and auditing.

2. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency.

All access to electronic health information is under system administration control and can be dynamically allocated to users on an emergency basis.

3. Terminate an electronic session after a predetermined time of inactivity.

There are multiple levels of timeout. Time out can be set on a per user basis and is honored throughout VistA in file 200. It also can be set for the whole system and there are other options such as setting it for devices.

4. Encrypt and decrypt electronic health information according to user-defined preferences (e.g., backups, removable media, at log-on/off) in accordance with the standard specified in Table 2B row 1.

There are multiple levels of encryption available at both the operating system level and the MUMPS language implementation level as well as the VistA level and higher including email. We have requested formal statements from Intersystems and Fidelity that the encryption in the M implementations meets the requirements in Table 2b row 1.

5. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in Table 2B row 2.

We do not feel confident that we understand exactly what they are asking for, i.e., is only IPSec acceptable, etc., but we do believe this would be implemented at the operating system or hardware level. This happens at the level of the interaction between the MUMPS implementation and the operating system. This needs to be clarified because even the NHIN is not using IPSec for transmission security. NHIN is using HTTPS and tunneling which are encrypted and secure integrity protected links.

6. Record actions (e.g., deletion) related to electronic health information in accordance with the standard specified in Table 2B row 3 (i.e., audit log), provide alerts based on user-defined events, and electronically display and print all or a specified set of recorded information upon request or at a set period of time.

Everything that can be printed in VistA that is

7. Verify that electronic health information has not been altered in transit and detect the alter- ation and deletion of electronic health information and audit logs in accordance with the standard specified in Table 2B row 4.

Anything that uses Fileman as the database manager can be audited. The use of any option can be audited including all options that print (ie, options in the roll and scroll portions of VistA.) The request for capturing everything that has been printed may not be possible because of the use of the print screen option in at the operating system level. Also printing from CPRS is not an "automic operation" that can necessarily be monitored, i.e., it is a multiple step process and is difficult to audit and it would be difficult to do for any system to audit. WorldVistA will be submitting the latter as a comment to the office of the National Coordinator for Health IT.

8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.

9. Verify that a person or entity seeking access to electronic health information across a net- work is the one claimed and is authorized to access such information in accordance with the standard specified in Table 2B row 5.

10. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in Table 2B row 6.