Hi,

Tnx. for the tips. 

Another thing, I thing doctor should be able to see
previous encounters of the patient, not the data only the clinic, or dpt.
so he can estimate is his problem related with his previous problems, 
and that doctor should be able to ask for authorisation from the phisician,
or a head of dpt. for wieving those records. 

Those priviledges should be 
generated dynamicaly and valid only for one paitent run through the hospital.

Also if patient is transfered from one clinic to another, priviledges should
be transfered to the doctor who takes in the paitent.

On Mon, 21 Feb 2005 10:34:58 +0000, J. Antas wrote 
> Mladen Novosel wrote: 
> 
> > I'll look into it. Is anyone else interested in developing access 
> > control for care2x? 
> 
> Anyone developing for USA or EU should be interested because it already 
> is a major legal requisite of any Healthcare Information System. 
> 
> > I'll try to get some funding from my ministry 
> > of health for developement so I can emply another php/mysql developer. 
> 
> That is a good start. 
> 
> > I;m starting a wishlist for this feature. Any proposition is welcome. 
> > Since I'm in health bussiness just for a year and a halph I'll definetly 
> > need some help. 
> 
> Keep it simple. 
> 
> > Firs part of project is planning. We need to define objects and permissions 
> > and a workfow. ex. object-groups: departements, user-groups, document-types 
> >                     permissions: read, write, modify, delete, transfer 
> >                                 departements: ENT, Internal MEdicine,... 
> >                                 user-groups:  admins, headOFdpt, 
> > doctors,... 
> >                                 document-types: radIMG, diag,
therapy,labres... 
> 
> Before starting UML'ing keep in mind these 3 golden pre-requisites: 
> 1. It should be small, simple and unobtrusive for the day-to-day user. 
> 2. It should result from the successful marriage of a regular user 
> authentication (login/password) with a role/context definition 
> 3. The user should be the validator of the role/context circumstance. 
> 
> A quick justification: 
> 
> 1. It should result from a quick browser downloaded small piece of code 
> (cryptographic secure authentication code) with the needed business 
> logic to authenticate and keep a logic key defining the role/context. 
> While, for security reasons, not being a cookie it would act much like 
> that. It should exist an option to limit the validation it in time. For 
> instance, to avoid cases like the user that goes for a long lunch and 
> leaves the terminal alone and the the patient record widely available to 
> everybody, the application should have a timer that after 5 minutes of 
> inactivity just logs off that frivolous user. 
> 
> 2. For the need for user~role/context pair authentication, just think in 
> this examples: 
> a) Being a physician, or even the patient oftalmologist, does not 
> necessarily warrant such a doctor the right to see the psychiatric or 
> dental record of his patient. Think, for instance, in a known politician 
> and on devastating effects on his career from the knowledge obtained 
> from a less then ethical perfect doctor non directly related with the 
> patient. 
> b) Context is important in several other situations, for instance, 
> patient changed doctor or health provider and does not want them to 
> access his records anymore, he may be temporarily inconscient and not 
> willing his wife to know some facts of his medical history, etc. 
> 
> 3. At any given moment the patient is the sole judge of the extent of 
> information that he should allow others to see and to which persons he 
> is willing to give it to. 
> 
> So, do yourself a favor, just ask some doctors to typify some typical 
> situation cases, like those in the examples that I gave before, and then 
> model your code to validate those cases. If you are able to do that, you 
> will have a very successful and secure role role/context medical 
> authentication and a very complaint application with current law. 
> 
> Best regards, 
> J. Antas 
> 
> ------------------------------------------------------- 
> SF email is sponsored by - The IT Product Guide 
> Read honest & candid reviews on hundreds of IT Products from real users. 
> Discover which products truly live up to the hype. Start reading now. 
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click 
> _______________________________________________ 
> Care2002-developers mailing list 
> [email protected] 
> https://lists.sourceforge.net/lists/listinfo/care2002-developers

------------------------- 
 Mladen Novosel, dipl.ing. 
 KBC Zagreb 
 Šalata 2



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Care2002-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/care2002-developers

Reply via email to