[Op-torch-general] Audit Trails etc.

[Tim C. <ti...@op...>]

Hi All,

Great discussion regarding auditing, backup and security in general.

Let's talk about the processes used in TORCH 1.3.x as they are very good
and they transfer well to TORCH2 in theory, they just haven't all been
implemented as yet.

The underlying engines creates a log of EVERY access to every object. 
All create, view, edit, delete actions are logged with a date/time
stamp, the userid, the IP address, the action performed and the complete
URL of the object accessed.  This is very robust logging if you do your
backups to CDR on a scheduled basis (daily) and only trim the log on a
monthly basis you have a huge number of copies that will corroborate
each other.  These logs are only on the file system and cannot (should
not) be accessible by application users.  This is simply good security
policy.  In a case where you are the server admin
and the physician (most of the people here but no the general physician
population) then you do not have that particular fact to fall back on.  

Encounters are signed off and a simple MD5 check sum is generated on
various system components. This is easily found in the source code and
COULD be compromised by modifying the encounter, editing the audit logs
exactly as needed and regenerating the check sum. There are still other
things I will leave unsaid in a public forum that leave "evidence of
tampering tracks" in TORCH.

In general though, a tampered Encounter will identify itself to anyone
else that looks at it with a message tht says it has been changed after
it was signed off.

When things are completed in TORCH the user interface doesn't allow the
user to edit that item again.  There are ways around it if you have
access to the database and know where to find things.  Again, this is
not within the ability of the common user.  

In TORCH2, the Archetype definitions (as Michael pointed out) give us
the flexibility to turn off editing or do something else (via a python
script call) anytime we access an object.  What this functionality gives
the TORCH community is the ability to change the workflow and behavior
of individual components at each installation and still maintain a core
release version. It is the ultimate in customization capability.  This
is simply not possible with a relational based system.

As we move to bring TORCH2 into reality I want to ask that the
community, especially physicians, concentrate on the knowledge portion. 
If you can learn how to create Archetypes that capture the data you need
captured in various situations, then the backend and the UI will get
taken care of for you. <g>  Think along the lines of 'when a CHF patient
comes in for a visit what kinds of questions do I ask and what things do
I do"?

Cheers,
Tim