Regarding this particular example, in this case we were thinking to create the INSTRUCTION+ACTIVITY plus its initial status (“scheduled”) in the same composition, since these effectively happen “at the same time” in the actual healthcare process of this case, and then all subsequent updates (ACTIONS to the same INSTRUCTION+ACTIVITY with other status) will come in new (separate) compositions.
By always ensuring that we create an initial ACTION for every ACTIVITY, then we can try to standardize how we will query/evaluate the status: there will always be at least one ACTION for the Activity, and we should always just read the latest one to get the current status, no matter what (even if the latest one is still just this initial “Created/Scheduled” kind of status).
To create this initial “Created/Scheduled” status ACTION in the same composition vs a separate composition felt a bit like a question of taste/preference, but we were thinking to put it in the same initial composition just to make it easier for the creation process, and give the whole thing a nice “packaged” feel… but of course, open for feedback!
Having said all of that I do feel that the 2 main questions posed by @Ann-Sofie.Stolperud are very relevant:
- should the
composition_uidgiven for a specificinstruction_detailsbe the fully versioned object ID or just the UUID itself (so that “latest” version of that UUID should always be assumed) - how should one set the
composition_uidwhen creating ACTIONS in the same composition? In some (but not all) implementations there are special variables/expressions that take care of this resolution for you (very nice!) but it feels like it would be much better if this were standardized
Regarding “what the composition_uid should look like,” I personally feel that this depends on how this will be read when later trying to query/evaluate the current / latest state, so IMO that is maybe an even bigger question. From my perspective, that is the key question I would also like to add here 
I feel that the design of this is explained quite well in the specification (see EHR Information Model specification sections 8.2.5.5, 8.2.5.6, and 8.2.5.7 ) but that the implementation of how to acheive/execute this kind of logic does not seem to exist anywhere in the specification??
And again here in some (but not all) implementations we have seen the addition of custom functions you can execute in AQL to get the current state of a given ACTIVITY or even the aggregate state of all activities within an INSTRUCTION but this is not part of the specification either. IMO it is here that the format of the various linking identifiers really matters (full object id with version suffix vs just the UUID without the version suffix, for example).
I can see how you might be able to “roll your own” and write an AQL expression to fetch the status in a “semi” generic way, but it feels like you will potentially need to recreate this kind of logic over and over again; it would be nice if there was a more standardized/non-proprietary/non-custom-AQL-query-every-time way to fetch the current/latest state of ACTIVITIES and INSTRUCTIONS based on how the design of these relationships is specified per the above-linked EHR Information Model sections. Perhaps within this is where the nuances between specific version vs “latest” could be taken care of, as well (or at least explained a bit more so the ramifications are clear)?