Unauthorized changes past encounters

markleeds wrote on Friday, March 10, 2006:

I have been going through my encounters for the last 2 months and cleaning up some of the information, especially in the early visits.  There were missing codes, wrong codes, etc…

I realize that when this is done that the deletions and additions of codes are logged, but I don’t like the idea of unauthorized employees going back and making changes on old encounters.

The problem I had coming up with a check to compare the current date with the encounter date is that all of the fancy date comparison MySQL functions are post-version 4.0.

I came up with this which works because it uses PHP to do the comparison.  This could be used to do an acl check to only allow authorized users to make changes to encounters before the current date.

$query = “select date_format(date,’%Y’) as y1, date_format(date,’%m’) as m1, date_format(date,’%d’) as d1, date_format(now(),’%Y’) as y2, date_format(now(),’%m’) as m2, date_format(now(),’%d’) as d2 from form_encounter where encounter=”.$encounter;
  $statement = sqlStatement($query);
  $date_diff = -1;
  $d1 = 0;
  $d2 = 0;
  if ($result = sqlFetchArray($statement)) {
    $d1 = mktime(0,0,0,$result[‘m1’],$result[‘d1’],$result[‘y1’]);
    $d2 = mktime(0,0,0,$result[‘m2’],$result[‘d2’],$result[‘y2’]);
    $date_diff = $d2-$d1;
  }

Now you just have to check that $date_diff is between 0 and 86400 (1 day in seconds).

It might be good to put this kind of check on adding encounters on other dates too.

Let me know if this makes sense to protect changes to encounters and billing data from earlier dates.

sunsetsystems wrote on Monday, March 13, 2006:

When an encounter is billed, I believe the billing codes become read-only.  So this becomes less of a problem if you are using the billing features.  Of course there is room for improvement here, and your idea seems headed in the right direction.

– Rod
www.sunsetsystems.com