Referring to the enclosing composition from ACTION.instruction_details?

Specifications
10

Hi again,

Last week I created an issue on EHRbase’s repo that is related to this: Get linked ACTIONs and latest state for INSTRUCTIONs/ACTIVITYs · Issue #1386 · ehrbase/ehrbase · GitHub

Basically with EHRbase up to v2.6.0 it is not possible to directly fetch or filter anything under an ACTIONs instruction_details using AQL (you get HTTP 400 with “Not implemented” as a response) so it does not seem easily possible to get an Instruction/Activity’s current state with EHRbase unless you 1) execute multiple different queries and then perform some kind of matching operation to get only the ones that should then be matched together or 2) use something else in the composition to match on (e.g. add some identifiers to the template and then populate them just for the purpose of matching our Actions to their Activities in AQL?).

But in my mind it goes back to some of the original questions in this thread, and thus the following 4 “gaps” (or at least “unclear things”?) that do not seem to exist anywhere in the specification that create challenges when trying to use and link INSTRUCTION + ACTIVITY + ACTIONs in practice:

  1. Standardized (exists in the specification somehow?) ability to create a composition with a UID determined by the client (POST or PUT? with a client-specified composition/_uid) - works with EHRbase, but not others?
  2. Some kind of standard (again, exists in the specification somehow?) “helper variable” when needing to refer back to the same composition as it is created/updated - Better EHR Server has $selfComposition that can be used but does not exist in EHRbase and unclear if any other implementation has similar?
  3. Standardized (again, exists in the specification somehow?) way to retrieve current state of a given Activity and aggregate state of a given Instruction based on all of the possible linked actions - Better EHR Server has some help functions you can use in AQL for this such as current_state, instruction_aggregate_state, etc but not aware of any similar solution from other implementation?
  4. Standardized (in the specification… ?) format for what should actually be saved in the different fields that exist under an ACTIONs instruction_details, specifically for things like composition_uid and if it should be with or without version and/or any other anomalies that can exist here? And namely so that it works correctly with whatever solution would exist from # 3 above - Better’s solution and above functions seems to work “out of the box” with full version-based IDs but again as there does not seem to be any other standard functions then it is unclear how this would be interpreted by any other implementation?

I am not really sure how to take this further but it feels like it needs a bit of a broader engagement if it is something which should include some design decisions and additions/changes to the actual specification(s)?

3 Likes