This sounds important to me. There are a number of issues that come to mind:
1. There a number of levels that doctors function (Australian label) - Resident (no specialty expertise), Registrar (training in this speciality) and Consultant (Qualified in this speciality). 2. Different countries use the labels differently - e.g. Resident = Registrar in Primary Care training in the US and Canada 3. Health Professionals moving between countries may function at one level (say consultant) in one country and another level in another country (say registrar). People may be acting as the consultant while someone is away...or head of department or whatever. 4. Doctors may state where they are working (Paediatrics) rather than the level (Registrar) - both are important Cheers, Sam Sent from Windows Mail From: Heath Frankel<mailto:[email protected]> Sent: ?Friday?, ?7? ?November? ?2014 ?6?:?29? ?PM To: For openEHR technical discussions<mailto:openehr-technical at lists.openehr.org> Cc: For openEHR technical discussions<mailto:openehr-technical at lists.openehr.org> Hi Pablo, I too have this requirement but more specifically I need the speciality of the composer that he was performing at the time of writing the composition. Therefore option 2 is not viable as this may change over time and the clinician may have multiple specialities and they may not even be applicable to the one he was performing at the time of being the composer. I am not keen on option 1 as you need to somehow correlate a participation with the composer and we have to replicate what is already specified in the composer just to specify the function. Ideally a speciality attribute should be provided on the composer but that would be a RM change. I think your other_context option is the best available option, but in the interest of alignment I would like to get agreement on this, perhaps by collaborating on a cluster archetype for author details to be used in the other context structure and make this available on CKM. I actually have some other othercontext archetypes that maybe useful to others but unfortunately I don't understand the process on how a techie like me can contribute archetypes to CKM that I use in real project because I am not a "clinical" modeller. Regards Heath On 7 Nov 2014, at 1:54 pm, "pablo pazos" <pazospablo at hotmail.com<mailto:pazospablo at hotmail.com>> wrote: Thanks Thomas, For this requirement I need to query documents by attending physician specialty, so in the 2nd option I'll need to query the demographic server to get the ids of the physicians with specialty X, then find the records for patient Y with composer contained in that list of physicians. Of course this is a pretty naive implementation, in this case I would have indexes of compositions by specialty, something I can create when the composition is committed to the EHR server, then this kind of query will use those indexes to avoid the "manual" join between demographic and ehr models. Yep, the 3rd will need archetyped other_context. Thinking out loud, this kind of solution can help on enabling this kind of query by specialty to be implemented as AQL, so there will be no need to add another service endpoint to the API (thinking of my implementation). Thanks again! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos> ________________________________ Date: Thu, 6 Nov 2014 16:08:01 +0000 From: thomas.beale at oceaninformatics.com<mailto:[email protected]> To: openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org> Subject: Re: Doctor specialty in the IM 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. _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141109/933f879b/attachment.html>
