It is good conversation but is probably mixing up the tech and the clinical semantics/governance. The tech that is not quite right for me is a simpler approach to references between Entry objects that allows
Nesting of Entries including inside the same composition.
Making Entries more Restful from a ‘Get’ point of view - i.e. it is easier to consume their parent composition metadata, when querying
Querying across references (simple use-cases only for now)
Standardise use of Entry Ids (sub-items like events, activities etc) esp to line up with FHIR. Can these be an alternative to aql paths (or at least hidden from 3rd party devs by the CDR)
Figure out how best to express these in ADL and tooling - I’m thinking LINK might be sufficient, with some tweaks e.g make target etc optional but add the ability to provide a uid at run-time rather than a formal AQL path (to be resolved by the CDR).
I think that gives us the playpark we need to start to give solid advice for the kind of questions that Joost is asking. I know various vendors are doing some of this already but it would be good to bring it into the standards space so we can give general advice on ‘how to do’ care-plans or allergies list etc, with some confidence that the optimal approaches do involve references. You can make that work right now but it is harder to do than it ought to be.
Can we clarify the sense in which you mean ‘nesting’ … do you mean:
A: an Entry (primarily an Evaluation?) can refer to other previously recorded Entries, and the linked structure is visualised as a hierarchy?
B: a managed list can define a hierarchical (i.e. heading) structure under which citations to previous Entries occur, and this is to be visualised according to the hierarchy in the citing list?
C: something else?
A) is already supported by LINK, but archetyping would be better if we could constrain the target of LINKs - the addition to AOM/ADL to do this is not complicated. Probably most current solutions don’t have a hierarchical visualisation of this kind of LINKed chain/tree structure. Querying would also be better if we could follow LINKs (e.g. to a max depth) and pull back the whole pile of LINKed items in one hit.
B) is what the current discussion thread was about.
Your 2. was what I was talking about in terms of ‘wrapped’ or ‘flattened’ Entries. Wrapped would be: you get (a copy of) the enclosing Version, wrapping the enclosing Composition, and inside, just the Entry you want, i.e. all other contents of that Composition are removed. Technically, this might be termed a ‘wrapped projection’. The attraction of this is that no new implementations structures are needed to deal with it.
A ‘flattened’ Entry would be the same content but more flattened, e.g. a structure like:
FLAT_ENTRY
entry: ENTRY[1] – original Entry, i.e. Eval, Obs etc
context: EVENT_CONTEXT [0…1] – context from owning Composition
commit_audit: AUDIT_DETAILS[0.1] – audit from owning Version
attestations: ATTESTATION[*] – any attestations
version_uid: OBJECT_VERSION_ID – uid of owning VERSION
This requires new modelling and new implementation in the server, APIs and applications, but might be a bit easier to deal with in apps.
I’ll add my technical 2 cents here, and let the others figure out the medico-legal and otherwise content-related aspects, and I’ll also send @borut.fabjan and @vanessap this way for that reason.
From technical POV, I would only like to see a persisted copy of the data within those lists if there is a non-technical reasoning (e.g. legal) behind it. Otherwise I would very much prefer those lists would be compositions containing only the links, and that is what would also be retrieved in the usual ways (requesting a composition via API or AQL query).
As there would probably be a widespread interest in having the CDR handle the assembly of the actual list (with contents, not just links), that should be handled in another way, e.g. another API endpoint, and a server-side function or similar for AQL. Then it would be up to implementation to provide this content in a timely manner and the specifications committee should abstain from giving instructions or even advice to implementors.
Right. But we need to work out what model changes are required to support this - that’s the SEC’s responsibility. E.g. the addition of at least a Citation class or similar appears likely, as per this early model UML for some initial ideas (‘view Entries’).
The question is whether the other requirements described above / emerging will require some more support in the models.
I’m starting to think that Citation may not be needed, with a little bit of work on the LINK class.
What are people’s views on making more use of uids vs. full AQL paths, at least at runtime, and emulating the CDA/FHIR approach of allowing in-composition local references?
To my understanding, we would have to do this anyway if we need to link to a specific entry inside compositions with repeating paths. I gave it some thought that this should be a configuration of EHRbase to automatically create uids if an entry’s path inside a particular composition is not unique.
@matijap - sorry - I was being a bit confusing. Fir ‘id’ I was raising the issue that I see increasing use of the ENTRY.uid or sometimes ENTRY.event.uid, either for internal references or to identify the ENTRY or (sub-ENTRY like event) to line-up with FHIR. e.g how do you gnerate a FHIR.id for an OBSERVATION?
I also sense that 3rd-party devs can get their heads around uids much more easily than formal AQL paths. Birger adds the further issue about uniquely identifying cloned paths.
I guess I am arguing that we should try to standardise the use of uids, or at least share experience, of how and where they are being used. I assume that internally a uid reference would be resolved to a specific path?
The issue about ‘local references’ is that FHIR and CDA allow the modeller to indicate that a link /reference to an ENTRY is to be stored inside the same composition.
I think eventually mandating or strongly recommending UIDs in ENTRY root points (and maybe in event root points) is uncontroversial, but not because it ‘lines up with FHIR’. If it does, that’s good, but we can go back to 13606 (not sure about today’s version) which demanded UIDs on every single node, which creates a massive impost on source systems to manufacture (easy) and record forever (costly) ids that they have no use for, but some interop standard (that will be replaced one day) requires. I actually calculated out the space cost of this on a representative CDR and the extra useless ids constituted a substantial fraction of the data volume. This matters when you are buying RAID 10 Tb of storage for real systems. It also added significant complexity.
Always be careful what you wish for with interop standards… Having said that, I’ve always believed we should have UIDs in Entry root points since they are independent clinical statements.
Not sure if I get this one: a LINK from some EVAL1 (say) inside COMP1, to OBS2 in some COMP2, is part of EVAL1, and is inside COMP1. Why should the modeller have to say anything about where the LINK goes?
The changes that we would need to propose on LINK would be the same ones that CITATION brings - primarily an attribute containing the resolved target of the LINK on retrieval but not persisting it. There might be advantages, and avoiding entirely new classes like CITATION also has the obvious attractions of reducing downstream implementation work. I will think more on what we can do with LINK.
Just to provide a counter-argument… If we use LINKs to implement Citations, then it is likely that at runtime, a Problem or other list will contain the ‘first class’ Citation LINKs (pointing to the primary data of the list, i.e. problems, Dxs etc from past Compositions) and also other LINKs. If we want to treat Citation LINKs as special, e.g. always ‘follow and resolve’, they will need to be marked as Citations or similar, to distinguish them from other LINKs that are not automatically resolved on retrieved (e.g. some sort of ‘see also xyz’ link, or order tracking Links).
So to implement what we think we want with LINKs, we need to:
designate some specific values for LINK.type (and maybe LINK.meaning) - see spec here.
add at a new field that contains the resolved value on retrieve;
possibly some other meta-data fields;
add something to the AOM to enable link targets to be constrained in a similar way to slot constraints (we need to do this in any case).
I’m not sure if this is any less work than adding a CITATION class and VIEW_ENTRY (my original idea), but it could go either way.
Something else potentially in favour of the VIEW_ENTRY approach: I believe we may want to be able to add something similar to a Citation, but where the resolved result is an AQL query result, e.g. last 10 BPs or a list of medications matching some criterion. If we did want that, it would probably be another child of VIEW_ENTRY, i.e. we might have this model:
VIEW_ENTRY (abstract)
CITATION
QUERY_RESULT
A further reason to consider this approach is that these special new ENTRYs can have LINKs attached to or pointing to them, just like any other ENTRY today, but ‘LINK citations’ cannot.
Some of these other kinds of quoted / cited Entry are described in the top bit of this old wiki post.
One more possible reason in favour of a CITATION (and related) classes: if we can routinely archetype LINKs within archetypes, it will be harder to distinguish Citations from other LINKs that might be archetyped, if they are implemented as LINKs.
I suggest we could discuss these options (and any other bright ideas people have) on Monday’s call.
I’ve added in the beginnings of a Citation Entry approach (explanation to be added), and also Ian’s suggested LINK-based approach. If others have a different idea, please add it as another Solution.
I know I’m a bit late to this party, but what’s the plan with this implementation of unique UIDs for every LOCATABLE in EHRbase? Last time I checked, UIDs are not being generated for every archetype in a composition automatically while creating.
@birger.haarbrandt and @ian.mcnicoll completely agreed.
The use case for uids extends way beyond linking. Having a unique stable pointer to LOCATABLES seems to be invaluable for external systems that need to keep track of and reference archetypes in compositions.
We were trying to build a billing system that needs to keep track of which INSTRUCTION orders and ACTIONs already got invoiced and which ones didn’t. It’s almost impossible to do without a unique identifier for the archetypes - especially when there are multiple instances of the same archetype in the same AQL path.
Apart from saving on storage space, what other reasons are there for not populating locatable with unique uids? Should we be considering making this part of the spec? And making uid under LOCATABLE class as 1..1 instead of 0..1 ?
It will create a lot of work for external systems to record and track GUIDs on every node, and they will never use 99% of them. Tracking just Compositions and Entries is the 1%, but it’s mostly useful.
The better way to do this in my view is to record order ids in a standard place in the RM, e.g. on ENTRY. Then you just have the correct kinds of ids (not GUIDs) for order tracking.
The order ids will normally be set outside the system, and assigned to anything ordered, which could be any of the openEHR Entry types (probably not EVALUATION, but it wouldn’t matter too much if it were available on that). At the moment, some openEHR archetypes have a place for these kinds of ids in the /protocol section but that’s not a great solution long term.
Could you elaborate?