Difference between revisions of "MU-Security"
Anthracite (talk | contribs) |
(Added a glossary link to treatment~) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 17: | Line 17: | ||
=== 5. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in Table 2B row 2. === | === 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. | + | 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 | + | === 6. [[Record~|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 [[record~|Record]]ed information upon request or at a set period of time. === |
| − | Everything that | + | 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 "atomic 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. |
| + | |||
| + | Everything that is requested to be printed in VistA can be audited. There is no ability to guarantee that it always was printed. | ||
| + | |||
| + | === 7. Verify that electronic health information has not been altered in transit and detect the alteration and deletion of electronic health information and audit logs in accordance with the standard specified in Table 2B row 4. === | ||
| − | |||
| − | |||
=== 8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information. === | === 8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information. === | ||
| + | |||
| + | This is impossible. It is possible to limit those who are authorized and give them a way to authenticate in the system. It is not possible to verify that the person or entity that seeks access is the one who was given the authentication information, nor to verify that they are the only person/entity who has the authentication information. There is certainly no way to verify that those seeking access are those that they claim to be. | ||
=== 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. === | === 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. === | + | === 10. [[Record~|Record]] disclosures made for [[treatment~|Treatment]], payment, and health care operations in accordance with the standard specified in Table 2B row 6. === |
Latest revision as of 11:53, 24 April 2012
Contents
- 1 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.
- 2 2. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency.
- 3 3. Terminate an electronic session after a predetermined time of inactivity.
- 4 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.
- 5 5. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in Table 2B row 2.
- 6 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.
- 7 7. Verify that electronic health information has not been altered in transit and detect the alteration and deletion of electronic health information and audit logs in accordance with the standard specified in Table 2B row 4.
- 8 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 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 10. Record disclosures made for Treatment, payment, and health care operations in accordance with the standard specified in Table 2B row 6.
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.
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 "atomic 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.
Everything that is requested to be printed in VistA can be audited. There is no ability to guarantee that it always was printed.
7. Verify that electronic health information has not been altered in transit and detect the alteration and deletion of electronic health information and audit logs in accordance with the standard specified in Table 2B row 4.
8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.
This is impossible. It is possible to limit those who are authorized and give them a way to authenticate in the system. It is not possible to verify that the person or entity that seeks access is the one who was given the authentication information, nor to verify that they are the only person/entity who has the authentication information. There is certainly no way to verify that those seeking access are those that they claim to be.
