Hi Pablo, the first is as good as any. Normally PARTICIPATION.function is intended to capture the function of the physician in the activity, which could be general or specific. It might not be the same as the specialty of the doc, especially if that specialsiation is not implicated in this activity.
It makes sense to do 2 if you are already using openEHR demographics, because then you can use PARTY_PROXY.external_ref to point to the PARTY in the provider DB, and that will have the specialty, and then the participation can be something more specific. E.g. a senior surgeon might be an 'assisting physician' at a difficult birth being managed by the primary Obstetrician of the patient. I don't think you need to query the demographic DB, just refer to the object, unless you actually need to have the specialty in the EHR data. Option 3 is probably only sensible if it is archetyped that way - otherwise noone will expect that info in the context object. But you need to look at how clinical people are using the context structure (i.e. look at some Composition archetypes) - maybe they are putting this sort of information in there. - thomas On 06/11/2014 15:50, pablo pazos wrote: > Hi, I have a small question: if I need to record the specialty of an > attending doctor: > > 1. Should I use the PARTICIPATION.function attribute? > 2. Another option is to have that in the CAPABILITY.credentials from > the demographic model. > 3. And a third option I can think of is to use > EVENT_CONTEXT.other_context structure. > 4. Other? > > My idea is to let users to find records by the specialty of the composer. > > In the 1st option I need to create a PARTICIPATION for the composer so > I can use the "function" attr. > In the 2nd option, the problem is I need to query the demographic > server to get the specialty. > In the 3rd option I need to create a custom archetype to give > structure to the generic "other_context" ITEM_STRUCTURE. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141106/33432ea4/attachment.html>
