RE: Logging Record Access in Transaction Systems

[Lee, Gary]

Title: 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   Martin,   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.   My two cents....     ----- Original Message ----- From: Martin Scholl To: [EMAIL PROTECTED] 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.   Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com ----- Original Message ----- From: Owens, Kris To: [EMAIL PROTECTED] ; '[EMAIL PROTECTED]' 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.