Hi, I have a small question: if I need to record the specialty of an attending doctor:
Should I use the PARTICIPATION.function attribute?
Another option is to have that in the CAPABILITY.credentials from the demographic model.
And a third option I can think of is to use EVENT_CONTEXT.other_context structure.
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.
Did you have this requirement before? What’s the best solution that worked for you?
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.
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).
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.
This sounds important to me. There are a number of issues that come to mind:
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).
Different countries use the labels differently - e.g. Resident = Registrar in Primary Care training in the US and Canada
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.
Doctors may state where they are working (Paediatrics) rather than the level (Registrar) - both are important