Hello Heath Thank you very much, it would perhaps be good to have it as an example...At the moment i am more interested in the technique. I would have to add quite a few things to what i have implemented so far before i can make full use of such an Archetype.
All the best Athanasios Anastasiou On 03/07/2013 23:12, Heath Frankel wrote: > Should we consider user_identity archetype into ckm so you can reuse? > Heath > > On Jul 3, 2013 8:10 PM, "Athanasios Anastasiou" > <athanasios.anastasiou at plymouth.ac.uk > <mailto:athanasios.anastasiou at plymouth.ac.uk>> wrote: > > 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> > <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> > <mailto: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.__open__ehr.org <http://openehr.org> > <mailto: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> > > > <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. > 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.
