Hello Heath & Sam Thank you very much for the helpful replies, it was good to see i am somewhat on the right track too.
All the best Athanasios Anastasiou On 02/07/2013 00:43, Heath Frankel wrote: > Hi Athanasios, > As Sam said, the Ocean Multiprac application suite (www.multiprac.com > <http://www.multiprac.com>) does this. I have a > PERSON.person-individual_provider that has a ROLE.user as well as a > ROLE.healthcare_provider, so your user who is a provider has both user > roles and healthcare roles. > Similarly I have a PARTY_IDENTITY.user_identity that has the username. > I store the credentials in a separate enterprise directory service such > as active directory. > So to login to our system you need to be authenticated in active > directory and have a person in the demographics with the matching > user_identity. > Our consumer portal works in the same manner. > Heath > > On Jul 1, 2013 8:59 PM, "Athanasios Anastasiou" > <athanasios.anastasiou at plymouth.ac.uk > <mailto:athanasios.anastasiou at plymouth.ac.uk>> wrote: > > Hello everyone > > Would it be good practice to use the demographics package to describe > both the patients for which data are available in a system but also the > users of the system? > > As far as the first part is concerned, the demographics package provides > a very good level of detail for describing the parties that could be > involved in healthcare provision for some event. > > However, was / is there also the intention of using the same demographic > entities "data store" to perform authentication / access control too? > > (I am thinking of: > a) A pre-condition for an operation to be carried out on the > existence > of specific PERSON.roles or membership of a PERSON into some GROUP > (which is straightforward); and > > b) Providing something like a ROLE(meaning="canLogin") with an > associated CAPABILITY.credentials Archetype that could be used to > perform authentication...Besides the trivial example of having a CLUSTER > with clear text username / password, there could be an Archetype with > just enough information to authenticate a user against an external > service (e.g. an LDAP directory) In this case, the Archetype would not > store username / passwords, just enough information required to connect > to the component that will be performing the authentication to retrieve > a simple yes/no answer at the time of logging in) ) > > Looking forward to hearing from you > Athanasios Anastasiou > > > > > This email and any files with it are confidential and intended > solely for the use of the recipient to whom it is addressed. If you > are not the intended recipient then copying, distribution or other > use of the information contained is strictly prohibited and you > should not rely on it. If you have received this email in error > please let the sender know immediately and delete it from your > system(s). Internet emails are not necessarily secure. While we take > every care, Plymouth University accepts no responsibility for > viruses and it is your responsibility to scan emails and their > attachments. Plymouth University does not accept responsibility for > any changes made after it was sent. Nothing in this email or its > attachments constitutes an order for goods or services unless > accompanied by an official order form. > > _________________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.__openehr.org > <mailto:openEHR-technical at lists.openehr.org> > > http://lists.openehr.org/__mailman/listinfo/openehr-__technical_lists.openehr.org > > <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
