Dear Antas and Tony Marston,
Thank you very much for your overview, but I would like to make some
comments and suggestions.
- "Role-Based-Access-Control":
- Permanent "Role" or "Profile":
- I agree with what you call "Role", although in our project we
call it "User-Profile". Anyhow we understand here that it define what
a user is allowed to do in general, at any time, for any patient.
- "Care-Team-Role-Based-Access-Control":
- In your project I am missing an aspect, which I believe to be
very important : the relation between the care provider and the
patient.
Indeed access to patient record information is exclusively justified
when the care provider is in charge of the particular patient. In
other word only when the user is necessary for the care of the
patient.
To be a doctor or any healthcare professional does not give
automatically access rights to any patient records, in case one is not
working for that patient. (For example healthcare professionals
themselves may ask a colleague an advice about their own health, but do
not like to share their own personal health record with the whole
healtcare community).
- In our "Virtual Care Team" project we maintain inside the
patient record a table of the users, who are currently in charge of the
patient, at least a Family Doctor, but more when necessary. In order
to get access to read and to write in a patient record, a user must be
a member of the Care Team:
- In most case the Care Team is usually managed by the GP.
The patient give a "mandate" to the GP of his choice in order to do
that.
- The patient himself may see his own Care Team list, and he
may ask extensions or sometimes a removal.
- It is necessary that an emergency department must be
allowed to declare himself as a new member of the Care Team, but they
are responsible to explain later why they did force the access.
- A membership in the Care Team has always a limited
duration, as far as normally necessary. For example an emergency
department do not need more then 3 days.
- One of the underlying aspects of the problem is also that we
have to take account of a kind of privacy between doctors, when they do
not have a common patient. Independent doctors do not like that other
competing colleagues could look how they work. In general they do not
say that, in that way, at day ligth, but this may be in fact a great
obstacle before a shared network will be accepted !
- Access rigths at Item level:
- Moreover we did create an additional access control at
document level, as optional attributes of the document. It is optional
and it make possible to restrict the access only to some members of the
Care Team, e.g. in order to share a report only between the GP and the
psychiater, but excluding the other members of the Care Team.
- Access rights may be given to individual users as well to small
groups of users. The notion of functional groups is useful because the
persons may change over time, e.g. the department of cardiology of an
hospital, having usually 5 cardiologists. The patient record is shared
with that department, even if next year one of the cardiologists would
have changed. The same for a team of nurses in which the persons may
change.
- A user may be member of more than one group. In contrast with
your approach memberships define here only positive accessrights and
may therefore be added.
- Permanent context:
- It is of course very useful that to have an object
"Current-User-Session" containing diverse informations about the
application environment (e.g. information about the current user, the
current patient, etc....). This information remain available when,
keeping the same patient, the user move to new pages in a new
application.
When I saw Care2X last year, my main concern was the lack of permanent
context. If I did good understand it was necesary to type the patient
identification again and again, when moving to other functionalities.
- Navigation and menus:
- In general I feel a trend toward a hypertext approach. Links
may be very useful directly inside structured documents. For ewample
if a screen is presented containind several Items, it is easy to find
small buttons inside every Item, in order to perform in one click, some
ation relevant to a particular Item.
- Menus may continue to exist, but be aware that they are just
one optional way to trigger related actions. At the end menus are just
a specific way to present links.
- In order to keep a generic approach, the access controls should
be associated with the content of "Actions" rather than only with
"Menu-Items".
- Of course links or buttons may only appear if they are allowed
in the context of the current user.
http://www.crisnet.be/index-uk.html
is a project in developement with an Open Source approach and using PHP
and Python.
A first version is already in production for 40 doctors.
We would like to share componets with other Open Source teams.
Etienne Saliez, MD
J. Antas wrote:
Joseph Dal
Molin wrote:
Does anyone know whether there is an open
source CCOW implementation similar to Sentillion?
Does a OSS PHP+MySQL routine like RBAC qualifies?
See more on:
"A Role-Based Access Control (RBAC) system for PHP"
http://www.tonymarston.net/php-mysql/role-based-access-control.html
Some time ago we looked at it as a possible candidate to inclusion in
the Care2x project. We could not find a well documented piece of
working
code for it.
J. Antas
|
