Writing audit trail

[kailangyu]

I an writing an auto-confirmation code for our practice that integrates with opendental. The integration is limited. We only want to do two things.

1. write commlog entries (e.g., when messages are sent out, when messages confirm)
2. modify appointment entries - i.e. change status (e.g. email sent, confirmed-) and change appointment note (e.g., put a brief text that it was automatically confirmed on xx/xx/xx date.)

The code works now for version 13.2.37 but reading the release notes, it seems like audit trail will be taken even more seriously from 13.3 on. Before I actually release the code for the practice to use, I'd like to find out what is the best practice for modifying these entries. Are there (best practice) codes for modifying securitylog and securityloghash that opendental could share with developers? Or should modifications to commlog and appointments just be made without touching any other tables such as securitylog and securityloghash?

Any help / guidance would be much appreciated!

Allen

[jsalmon]

I an writing an auto-confirmation code for our practice that integrates with opendental. The integration is limited. We only want to do two things.

So I'm not sure how you are "integrating" so that might be helpful to know. For example, my answer if you were integrating with a plugin would simply be to use SecurityLogs.MakeLogEntry() and then we take care of everything for you.

Are there (best practice) codes for modifying securitylog and securityloghash that opendental could share with developers?

Our hashing algorithm can be found in SecurityLogHashes.GetHashString()

Or should modifications to commlog and appointments just be made without touching any other tables such as securitylog and securityloghash?

I like the idea of logging that you are the one that edited / created these commlog / appointments. So I'd recommend calling our method if possible. If that is not possible (e.g. you are not using a plugin but something else) you can try to mimic what our hashing algorithm does OR you can simply enter a row into the securitylog table. Keep in mind that this will make the row highlight in red and to the user it will seem like the securitylog entry that you created is no longer valid or has been altered by a third party source. It might desensitize the office to red entries in the log which is a bad thing but you could do something like start the log with the name of your program or something so that they stand out.

[kailangyu]

Yikes, I am a newbie ... so please bear with me. I am using php code that currently directly access /modify the mysql database. When patients confirm, or when messages are sent out - appointments, commlog entries are automatically added / modified.

I assume I can call SecurityLogs.MakeLogEntry() by calling some sort of dll? Are there APIs for modifying appointments (i.e. changing appointment status and modifying note texts) and adding commlog entries? Would they call SecurityLogs.MakeLogEntry() in turn? Are these meant to be called only by opendental "plugins" or also outside programs?

Back to my code: the code I have written functions sort of like demandforce and or lighthouse (which is "integrated" with opendental per http://www.lh360.com/support/supported-platforms) - it retrieves needed info from the opendental database, generally does not modify the database, but at very specific points of the software (i.e. patients confirm, messages sent), does write back to the opendental database. Should I do things correctly with security logs? Or just ignore it?

[jsalmon]

Are these meant to be called only by opendental "plugins" or also outside programs?

They are really meant to be called by plugins. However you could in theory call them from external programs because you are right, it is simply a dll. The MakeLogEntry method resides inside the OpenDentBusiness.dll

Should I do things correctly with security logs? Or just ignore it?

Personally, I think it would be a big pain for you to have to figure out how to call a method from our dll from within php (I've never tried it before so I'd imagine it's not fun) and I don't think it will benefit you or the office all that much. HOWEVER, please do NOT ignore it. I am ecstatic that you came here to ask because you making a manual entry into the securitylog table (only) will save our techs here at Open Dental an astronomical amount of time. The hardest thing about our job is when people manually manipulate the database and the office thinks it was us and then we no way to prove it one way or the other to the customer.

I personally feel it will best use your time and will help us (HQ) out the most in the long run if you simply add an entry in the securitylog table using the closest PermType for what you are doing.
E.g. Editing a commlog uses PermType "CommlogEdit". This new entry being made should set the UserNum to 0 (which will display to the users as "unknown") and then should really either set the CompName or start the LogText with something unique about your software so that you can easily identify your entries. This greatly helps us know what is going with the database without having to get you involved (most times).

Ultimately it is up to you. Please ask me any specific questions that you have and I'll do my best to help you out.

[kailangyu]

Jason, thanks for the very helpful responses!

Are these meant to be called only by opendental "plugins" or also outside programs?

They are really meant to be called by plugins. However you could in theory call them from external programs because you are right, it is simply a dll. The MakeLogEntry method resides inside the OpenDentBusiness.dll

I can probably get php to call dll with some effort, but I was wondering about the security context (the "user" that would be calling the dll). When a plugin calls, I presume the security context is automatically inferred. But when calling from outside a plugin, I wonder if that will work (e.g. are there apis to authenticate the "user"?)

Should I do things correctly with security logs? Or just ignore it?

Personally, I think it would be a big pain for you to have to figure out how to call a method from our dll from within php (I've never tried it before so I'd imagine it's not fun) and I don't think it will benefit you or the office all that much. HOWEVER, please do NOT ignore it. I am ecstatic that you came here to ask because you making a manual entry into the securitylog table (only) will save our techs here at Open Dental an astronomical amount of time. The hardest thing about our job is when people manually manipulate the database and the office thinks it was us and then we no way to prove it one way or the other to the customer.

Got it. I can readily enter something in the logs. It won't have the right hash though ... so it will appear "red" in the audit trail ... but based on what you said, that's "ok" (i.e. won't adversely affect opendental, assuming of course my code doesn't mess up the database) - maybe even "good" (since it would identify that opendental didn't make the changes)?

[jsalmon]

When a plugin calls, I presume the security context is automatically inferred. But when calling from outside a plugin, I wonder if that will work (e.g. are there apis to authenticate the "user"?)

Correct, plugins get lucky and don't have to worry about much. Calling the dll from the outside introduces lots of variables and I might not even be able to theorize every scenario so that alone makes me want to lean away from this path. Also, how is the dll going to be present to all users? Will they always talk to your web service to access the dll on the server? Are you going to require the client computer to have Open Dental installed to use your services? We don't have an API. I can point you around to some methods to call that reside in the OpenDentBusiness.dll to authenticate an "Open Dental" user if you like. But now your service will need some sort of log in section thus more time and money.

so it will appear "red" in the audit trail ... but based on what you said, that's "ok"

Yes, in newer versions the row will show red (or some color, I'm pretty sure red) and I feel this is acceptable as long as you brand it somehow. Without the branding, it will look like we made it and the office might get antsy that their database is being manipulated somehow without their knowledge.