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> 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>) 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@**plymouth.ac.uk<athanasios.anastasiou at >> plymouth.ac.uk> >> <mailto:athanasios.anastasiou@**plymouth.ac.uk<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@**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> >> <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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130704/75a0b764/attachment.html>
