Regarding the use of the Demographics Package...

2013-07-04 Thread Heath Frankel
 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


Regarding the use of the Demographics Package...

2013-07-04 Thread Athanasios Anastasiou
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