Silje,

It may be true that it is sufficient for your use case.

In principle there are two methods to deal with information in the EHR:
-1- In the COMPOSITION the data is referenced by a code/url because it is in a 
shared Repository
-2- In the COMPOSITION all data needs to be made available explicitly, when 
used in a message/document where the receiver has no access to the shared 
Repository.

This means that the generic Archetype needs to support these two possibilities 
where in the Template for a particukar use case one of the methods is 
implemented

Gerard

> On 24 Nov 2016, at 10:35, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Hi, thanks for your replies everyone! I think the function attribute is 
> sufficient for our use case, as the focus is on what the person did. Their 
> profession/credentials can be provided by an external knowledge base. <>
>  
> BTW, I tried looking this up using the UML link from the CKM, which led me 
> here: 
> http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html
>  
> <http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html>.
>  I then tried to follow the List<PARTICIPATION> link to 
> http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html
>  
> <http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html>,
>  which gave me a 404.
>  
> Mvh.
> Silje
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> <mailto:openehr-technical-boun...@lists.openehr.org>] On Behalf Of Ian 
> McNicoll
> Sent: Thursday, November 24, 2016 9:49 AM
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org 
> <mailto:openehr-technical@lists.openehr.org>>
> Subject: Re: RM Participations name/role?
>  
> Hi David, 
> 
> I think your approach is perfectly valid but I suspect would impose an 
> overhead of complexity that is not always justified or necessary. 
> 
> In the original lab system the kind of individual entry tracking you suggest 
> is probably required to facilitate workflow but by the time it hits the ehr, 
> that level of granularity is not needed IMO.
> 
> Another good example of the way the health data is summarised and compressed 
> as it passes through the system.
> 
> Both approaches are valid IMO. 
> 
> Ian
> On Thu, 24 Nov 2016 at 08:18, David Moner <dam...@gmail.com 
> <mailto:dam...@gmail.com>> wrote:
> Hi,
>  
> I'm not sure if this is a correct approach. What in the example you call a 
> function can be in fact a full Action that is being done. That is, if the 
> function is so relevant that you can even assign a dedicated participant to 
> it, it should be also enough important to be represented and documented as an 
> individual entry of the EHR: coded, with start and end times, etc. If the 
> case is that a complex procedure is composed by other simpler procedures, 
> then we should document and link all of them.
>  
> I see the case of Silje from a different perspective. What she is asking is 
> if we can document the participants of each Element inside the Entry. So far 
> this is not possible, as Entries have been always seen as a whole clinical 
> statement, with all participants assigned to that level.
>  
> 2016-11-23 20:47 GMT+01:00 Ian McNicoll <i...@freshehr.com 
> <mailto:i...@freshehr.com>>:
> Hi both
> 
> Agreed. 
> 
> Role = pathologist
> Function = macroscopic histopath examination. 
> 
> Ian. 
> On Wed, 23 Nov 2016 at 17:32, Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>> wrote:
> Hi Silje,
> 
> The PARTICIPATION class 
> <http://www.openehr.org/releases/RM/latest/docs/common/common.html#_overview_3>
>  has a codable attribute 'function' for this purpose (calling it 'function' 
> rather than 'role' came from 13606). It may be that you want to state a 
> 'role' as well, i.e. to say that a certain kind of person is required, and 
> then use function to state the actual function that person is supposed to do 
> in the particular activity in question.
> 
> I would have expected 'function' to be sufficient for your example - just use 
> 2 x other_participations on the OBSERVATION.
> 
> An example of needing both could be something like:
> role = nurse
> function = foley catheterisation
> Currently 'role' is only known in the demographic model, i.e. on the other 
> side of the PARTY_PROXY.external_ref link. It may make sense to add a role 
> attribute to PARTICIPATION at some point if we need to distinguish the type 
> of person (qualification) from what they do in the activity.
> 
> - thomas
> 
>  
> On 23/11/2016 06:29, Bakke, Silje Ljosland wrote:
> Hi,
>  
> We’re wondering if it’s possible to specify what the role was of each 
> instance of Participation in an OBSERVATION archetype? For instance in a 
> histopathology result the macroscopic description will often be performed by 
> a different person from the microscopic description. We’re thinking both will 
> be listed using participation, but we need to be able to document which 
> person did what.
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
> 
> Tel. +47 40203298 <tel:%2B47%2040203298>
> Web: http://arketyper.no <http://arketyper.no/> / Twitter: @arketyper_no 
> <https://twitter.com/arketyper_no>
>  
>  
> 
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto: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>
>  
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto: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>
> 
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto: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>
> 
> 
>  
> -- 
> David Moner Cano
> Grupo de Informática Biomédica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es <http://www.ibime.upv.es/>
> http://www.linkedin.com/in/davidmoner <http://www.linkedin.com/in/davidmoner>
> 
> Universidad Politécnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
> Valencia – 46022 (España)
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto: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>_______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto: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>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to