Your point about cost is well taken, and
it is true that not every organization can implement it. What I was
trying to illustrate were some of the arguments which should be considered, and
often are not, in trying to make the business case for logging or not logging.
It is important to have dollars and cents issues if you are trying to explain
to your management why you should consider spending the money to do this.
As an example related to your own example,
in the case of firing employees who are caught browsing for their neighbors'
records, just how would you go to court to prove they had in fact done this
infraction? Worse yet, since they could easily claim that other employees
had done this and not been sanctioned, how would you prove, to a legal standard
of proof, that no other employees had done so, and that the organization had
made a legally reasonable effort to prevent such an infraction? And, how
do you document that it was reasonable to give that category of employee access
to that data in the first place? Saying, "Well, we thought they
needed it to do their jobs..." just may not be enough to convince a
court that every customer service representative needed complete access to
every member and/or patient record (which is, in fact, not likely to be true at
all...do you give every CSR access to HIV data?) Otherwise, how are
you going to pay for the large settlement the terminated employee is going to
get when they sue you for firing them unjustly? Disk and processor are
much cheaper than lawsuits.
As the Wicked Witch of the West said, "These
things must be done carefully..." Or as Phil Crosby said, "If
you think good quality is too expensive, you don't know how much poor
quality is costing you." Potential liability is a very real
cost which your policy makers should be considering. Every single
transaction you conduct is a potential source of liability, and logging is one
technique for partially mitigating that liability. Potential downtime is
another danger logging helps to mitigate. If your hypothetical
organization doesn't have the resources to do the job well then they
should consider something other than trying to build their business functions
in house.
To look to your other example, if one of
the business services you provided was transporting critically ill patients,
and one of them died on the way, would you rather go to court saying you were
driving a Mercedes S500, or a Trabi? It might cost less to buy the Trabi
up front, but the lifetime cost of operation may be much greater, and that is
what system design is all about.
Gary Lee
Senior Architect
ACS State Healthcare
Suite 300
860 Blue Gentian Road
Eagan MN 55121
651-686-0015 ext. 240
(v)
651-686-0016 (f)
[EMAIL PROTECTED]
-----Original Message-----
From: Martin Scholl
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 09, 2002 12:43
PM
To: [EMAIL PROTECTED]
Subject: Re: Logging Record Access
in Transaction Systems
There are many good reasons to do
logging. There are also many good reasons to drive a Mercedes S500.
My objection to logging is only its
cost. While a large organizations with a well trained ( and paid) IT
staff can do all the necessary infra structure for logging the reality is that
a lot of organizations just don't have the resources. Neither in
personnel nor in funds. And I think it is important to point out that a
covered entity can forego the access logging if its privacy and security
policies are well written. Those rules have to assign a specific role
to everyone that comes in contact with PMI , defining the level of access and
also training the personnel in their obligations regarding the privacy and
security. Any tightly run healthcare enterprise should be close to
compliance by adhering to common sense guidelines.
For example: your customer
service representatives have access to the complete member or patient records.
You have to put in place a strict
code of conduct and enforce it too. Even fire employees who are caught
browsing for their neighbor's records. But beyond that you don't have to
change your system, you don't have to create a log of anybody who accessed the
records. The key word is "reasonable". A covered entity has to
undertake every resonable step to insure the PMI. We don't have to do an
access log that rivals those for national security documents.
If you can afford logging, great. If
you can't, don't sweat it.
----- Original Message -----
Sent: Tuesday,
July 09, 2002 11:40 AM
Subject: RE: Logging
Record Access in Transaction Systems
We have found that the
issue of whether to log or not to log in our Medicaid management systems is
generally driven by two things. First, every single RFP we get includes
full logging of all updates to the key transaction files/tables as a
requirement, so we have no choice there. Secondly, there are particular
regulations which cover Medicaid which require update logging outside of HIPAA,
so again HIPAA is not the driving factor. The logging we do is for both
batch and online access. For those reasons, I qualify that we may not be
the most objective source of opinion on this.
That said, logging, while
an 'expensive' operation in terms of coding and machine resource, is generally
necessary from a simple operational point of view for various recovery
options. In other words, it is generally a good design idea for any transaction
system using very large data stores with transaction updates to log in order to
be able to recover transaction processing after errors. Whether you are
talking automated logging from something like an RDBMS of transaction monitor,
or hand written code you can add a great deal of recoverability to your system,
which is a significant quality issue. That operational requirement is
enough to justify full logging for updates to your key datasets by
itself. Logging records are also then available to feed into such things
as fraud and abuse detection, and various statistical routines for capacity
planning, budgeting and so forth, to name just two uses. If you look at
the various uses you can make of the log data you find that there are many
benefits to offset parts of the expense of implementing it.
Full logging of inquiry
access would be much more expensive in terms of machine resource, but if you
are looking for an accurate analysis of costs and benefits you should consider
the same types of outside uses for the logging records.
Gary
Lee
Senior
Architect
ACS
State Healthcare
Suite
300
860
Blue Gentian Road
Eagan
MN 55121
651-686-0015
ext. 240 (v)
651-686-0016
(f)
[EMAIL PROTECTED]
-----Original Message-----
From: James Kelly
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 09, 2002 8:30
AM
To: [EMAIL PROTECTED]
Subject: Re: Logging Record Access
in Transaction Systems
While I agree with you that the law
does not seem to require full logging for TPO operations, I as a vendor
of payer software, feel that I must add it in to my system. If an
unauthorized access is made by a user, the only way to detect that would be a
review of the audit logs. In addition, once it was determined that a user
was in violation of policies and procedures, having the ability to query all
accesses made by that user would be extremely beneficial.
In terms of Kris' questions regarding justification, I
do not see how you can justify not turning it on. I interpret the spirit
of the law as giving patients the abilty to go to their insurer and ask
"who has had access to my PHI and why?". Without full logging,
that question will be impossible to answer.
----- Original Message -----
Sent: Monday,
July 08, 2002 5:03 PM
Subject: Re: Logging
Record Access in Transaction Systems
I am not logging at this
point. Though I keep it in mind in product design, I am way to busy with
transaction sets. I think logging is fine but a luxury I can't afford at
this time. Also logging can get very involved. Full logging, as you
describe it, is a database task in itself. Develop reports, screens, access
schemas and so forth.
It is also my interpretation that
you don't need logging within TPO (Treatment, Payment and Operations).
Only when access to PMI is outside of TPO, do you need to create a record.
I think that for the majority of
HIPAA covered entities full logging is overkill and not affordable. We
shouldn't overlook the fact that healthcare costs in the US are
unaffordable as it is. Logging does not add anything to the delivery of healthcare.
----- Original Message -----
Sent: Monday,
July 08, 2002 1:04 PM
Subject: Logging
Record Access in Transaction Systems
In our regional SNIP organization we are having a
discussion about the logging of user's access to records in transaction systems
and I would like to ask other organizations around the country what their plans
are. I appreciate your feedback.
Definition:
Full Logging: This is when a computer application (like a physician
billing or claims processing system) writes a record to a separate log or
audit file every time a user adds, changes, deletes, or inquires a
record. The user access could occur either on-line using a screen, or
through a batch process. Generally, log records include, the operator id
of the person that accessed the record, date and time the record was accessed,
and a before and after image of the record, or the fields that were
changed. Full Logging is not
when an application stamps a
record with Operator ID, date and time each time it is added, changed or
deleted.
Questions:
1. Are your systems capable of doing "full
logging"?
2. Does your
organization currently have "full logging" turned on? For adds,
changes, deletes and inquires? Batch, on-line or both?
3. What has been the impact to your overall
system, has it impacted response time, disk resources etc?
4. If you have logging turned on, do you have
someone monitoring the log file? Is this a full time job? How are
you using the log data?
5. If your organization doesn't have full
logging turned on do you plan on turning it on? When?
6. Will you have to upgrade your current
system, customize it, or buy an additional product to get full logging
capability? Do you plan to?
7. If you are currently doing full logging, or
plan on doing it in the future, what is your justification for doing full
logging? What are your anticipated outcomes?
8. If you are
not doing
full logging and do not plan on doing it in the future, what is your
justification for not doing full logging?
Kris Owens
Senior
IS Project Manager - HIPAA Project
Presbyterian
Healthcare Services
Albuquerque,
NM
505.923.8108
[EMAIL PROTECTED]
"There is no meaning in
isolation"
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
==================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.
--- PRESBYTERIAN HEALTHCARE SERVICES DISCLAIMER ---
This message originates from Presbyterian Healthcare Services or one of its
affiliated organizations. It contains information, which may be confidential or
privileged, and is intended only for the individual or entity named above. It
is prohibited for anyone else to disclose, copy, distribute or use the contents
of this message. All personal messages express views solely of the sender,
which are not to be attributed to Presbyterian Healthcare Services or any of
its affiliated organizations, and may not be distributed without this
disclaimer. If you received this message in error, please notify us immediately
at [EMAIL PROTECTED]
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is specifically
prohibited.
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
=====================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP. If you wish to receive an official opinion, post your
question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.
**********************************************************************
To be removed from this list, send a message to: [EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
======================================================
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is specifically prohibited.
|
