Auditing Changes

Changes to the electronic health information need to be audited.

Audited Events:

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 created/validated
11. PHI export (e.g. print)
12. PHI import
13. security administration events
14. backup and restore

In 2010 the following events will be added to this list:

15. installing new versions, upgrades and changes to the system (PHR 17.01)
16. loading new versions of codes and knowledge bases (PHR 17.02)
17. changes to system date and time (PHR 17.03)
18. backup and restore (PHR 17.04)
19. archival of data (PHR 17.05)
20. restoration of data from archival (PHR 17.06)
21. beginning and ending of system maintenance session (PHR 17.07).

Fred Trotter: This is a very complicated topic and I would encourage you to look at ClearHealth here, they have a robust object-modification logging system that they have been working on.

Sam Bowen: Clearly, our logging needs serious improvement. That is what started the security discussion with Justin Doiel and Fred Trotter. Justin and I were discussing using an md5 digest in the log to prove that encounter had not been tampered with. We wanted to sign the md5sum, and date time stamp with a CACert.org public key which could be verified in court that the record has not been altered. Or conversely, in Justin's case, to prove that the record had been altered intentionally. (Not all of his practitioners are as honest as we all assume). The practitioners are not very good at cheating the system. When audited the entire group receives sever legal attention from their state regulators. He wants a tool to be able to keep his practitioners honest in a proactive way.

VISOLVE>> Agreed and thanks for your views here.