Hi Athanasios, As Sam said, the Ocean Multiprac application suite (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> 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<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> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130702/d5190373/attachment.html>
