aperezcrespo wrote on Tuesday, June 23, 2009:
Hi
I see that via GACL oemr provides a Write and an Addonly return value. Does it have a Read only function? I might be useful to have Read-only access for some accounts.
Thanks
aperezcrespo wrote on Tuesday, June 23, 2009:
Hi
I see that via GACL oemr provides a Write and an Addonly return value. Does it have a Read only function? I might be useful to have Read-only access for some accounts.
Thanks
bradymiller wrote on Tuesday, June 23, 2009:
hey,
Haven’t yet encountered a situation in the access controls where this is warranted. Using the access controls takes awhile to digest; let us know of any specific instances in code or acos where this may be warranted.
-brady
aperezcrespo wrote on Tuesday, June 23, 2009:
Hi
As an example, A coder may need to View an encounter (read only) to properly code it.
We may not want coders to be able to modify/alter an encounter but we do need them to update the patient demos/insurance data.
Thanks
sunsetsystems wrote on Tuesday, June 23, 2009:
Where it matters, any non-empty and non-zero return value other than "write" or "wsome" or "addonly" is treated as read-only. From acl.inc:
// acl_check should return 0 if access is denied. Otherwise it may
// return anything that evaluates to true. In addition if any of the
// following types of access are applicable, then the corresponding value
// must be returned if and only if such access is granted (only one may
// be specified):
//
// * write - the user may add or modify the ACO
// * wsome - the user has limited add/modify access to the ACO
// * addonly - the user may view and add but not modify entries
aperezcrespo wrote on Tuesday, June 23, 2009:
I looked at that and was confused by the
//wsome - limited add/modify
//addonly - view and add
It seemed to imply that in both instances they could add and with wsome modify.
sunsetsystems wrote on Tuesday, June 23, 2009:
Actually "wsome" seems to be obsolete. In any case, the "special" values (write and addonly) are meaningful for only certain ACOs, and for the rest are treated as "access is granted" just like any other nonzero/nonempty value.
sunsetsystems wrote on Tuesday, June 23, 2009:
Here are some more practical implementation guidelines:
1. If the intent is to grant full access, it is always safe to return "write".
2. If you have a situation where read-only access makes sense, then that is probably supported, and if that is what you want then return "1". If it does not have the desired effect, then this should be considered a bug that needs to be fixed.
3. If you have a situation where add-only access makes sense, then that is probably supported, and if that is what you want then return "addonly". If it does not have the desired effect, then this should be considered a bug that needs to be fixed.
aperezcrespo wrote on Tuesday, June 23, 2009:
Thanks…
FY: Here is why this all came about.
In current release of OEMR if I add Notes any encounter to the accounting group, the coders can see the encounter for proper coding.
But in CVS this does not seem to work.
Trying to figure it out.