I got a question regarding instructions and actions. My understanding is, that we can use clusters to provide a formal description of the order, i.e. in the case of medication, we can provide clusters with details about the dosage. However, if we want to order the measurement using the blood pressure archetype and with defined details (position, pulse pressure), this does not work because of the entry class. It would be great to learn how you are dealing with this in practice. I’m still sensing that it should become possible to switch the entry type at design time to also address these cases without duplicating all the bp data in a specific cluster.
This is an interesting question, and this is the first time I hear it. I don’t believe we have a way of specifying this in a structured way in INSTRUCTIONs right now, without making specific CLUSTER archetypes as you point out.
Well you are talking about an order, not an observation. So maybe you are asking for PP and position to be recorded; how this is represented will not be the same as it is in the BP archetype, which describes the measurement result structure (including timing etc). I would expect to see a description structure just asking for the things you want, in a list, maybe coded, if it’s possible. But it needs to be an Instruction, so that it can be followed with an Action that indicates it was performed (and linked to that will presumably be an Observation with the data).
the difference between an observation and an instruction is perfectly clear to me. However, I normally would like to describe how an action (edit: in the sense of what I can expect to document as observation as outcome of the action) should be performed. From my perspective, it appears to be more elegant and logical if I could re-use data fields from the possible set of elements that are available for documenting the observation. If I need to duplicate this inside clusters (position, tilt, PP etc.), I will have way more archetype pairs that need to be kept in sync. In theory, we could (maybe even should?) extract the data fields from the observation archetypes, replace them with slots and put them in clusters but this would break current patterns and make handling cumbersome.
Hope this helps to understand my point of view. I guess this discussion has been there when this part of the RM was developed but I hope it helps others as well to better understand how this should work.
What I think you want is something like a ‘prototype’ of a BP Observation, to use as a specification of what you would like the eventual Observation to look like.
However, we could potentially think about the same kind of idea in the RM, i.e. defining a prototype attribute on Instruction that could point to one or more partially populated Action or Observation structures.
I’m not convinced that is how orders are placed right now, at least for observations but we do have sort of similar construct on the Goal archetype where you can ‘refer’ to particular paths in an Observation archetype e.g Target systolic BP < 110.
Tiëto use a concept where a phycisian can add orders (and other archetypes) on the fly to a template. I don’t know how they practically and technically do this, but it ensures that an order can be done in context of the the recorded observation and perhaps other details like an encounter report.
I think that it a pretty cool and natural way the put orders to a record.
This use-case was the reason for implementing Taskplan. It is not covered well with “old” RM classes IMHO opinion. You might need timing, protocol, concurrency, repeatable tasks and so on.
I would like to note that we find the prototype on defined actions rather useless, because you cannot commit the damned thing without a template anyway, so we just use capture datasets that are linked to forms.
I hear you. I have to admit that part of the model is not as well developed as it should be. The original idea (here’s the relevant point in the spec just for reference) was that the prototype structure would be a legal instance of an ENTRY, e.g. a partially populated BP measurement OBSERVATION structure. The idea was that at design time, the Plan author would (somehow) build that partial data structure, and it would be saved in such a way that it could be used to pre-populate the relevant form (i.e. template) at execution time.
So if you agree with that general premise, I would be very happy to discuss ways we can upgrade that part of the spec to enable that kind of workflow.
That seems like a sensible approach that is currently solved only by setting default values on forms (which we can do, but that could probably result in an inflation of number of nearly identical forms). One of the problems I foresee is that, I suppose, often the ENTRY would not be legal because some mandatory attributes would be left empty in the prototype.
Trying to remember back to when I specified this… at the moment, what you see is prototype is an RM instance in the model.
I remember one idea that the pre-populated values could be represented as an archetype(s) with either default values (we don’t yet have them in ADL specs, but I have the design for that) or by using ‘point’ or at least narrow ranges for the main constraint values of those data items we want to specify. Since archetypes, unlike templates, are 90% optional fields, we won’t hit the problem you mention.
On the other hand, the data structure that will be in use at runtime will always be a template, so the question is whether the above can be used conveniently as a ‘pre-fill’ specification for the template at runtime.
A better idea might be to consider specifying the pre-fill values as a path/value set - something very close to the Marand web template that we are starting to standardise. In theory we could run into the mandatory problem again, but… anyway, worth thinking about?
Well, that would not hit the problem about fields being mandatory, because it would be just key/value pairs and would later need to be processed by the “form renderer” or whatever software would deal with dataset capture, and no validation needs to occur there before the user declares intention of posting the data to CDR. So yes, it sounds like a good idea to me, despite being a bit less “shiny” than simply having a (somehow non-validated) ENTRY instance there. (Then again, a form/template might contain multiple entries, and the key/value approach can even handle that, being more flexible.)