There are a number of situations in which content ‘referencing’ aka ‘citation’ is needed in the health record, including:
authored document, e.g. discharge summary, that need to reference prior content e.g. Hx, Dx, Rx, but also need to be representable as a standalone document both for signing purposes and for sharing beyond the EHR system boundary;
these seem to be mainly ‘citing’ pre-existing data,
but also need to be converted to a standalone (serialised) document (e.g. XML, JSON etc) that includes (some of) the cited material as if it were inline, e.g. primary Dx, labs.
managed lists, e.g. Rx list, Problem list, whose contents (prescriptions, diagnoses) will generally have been created at a prior time in the EHR, e.g. in an encounter, and may or may not be required in the managed list. E.g. ‘current master problem list’ doesn’t need to indicate resolved childhood bronchitis Dx, etc; Medications list only needs currently active prescriptions;
not all ‘managed lists' are the same: medications list is theoretically a true digital twin of the patient - i.e. a faithful description of the true state of medications / treatments being taken by the patient; ‘problem list’ on the other hand might have a true digital twin version representing processes in the body, but there are also other 'problem lists’ e.g. for nursing, pregnancy etc that are partial / subjective, and may include things that are not technically illnesses (e.g. inability to get up stairs on a nursing problem list).
care plans: similar to managed lists, contain references to previously created content, probably including content within managed lists (Discourse discussion w/ diags);
composite clinical data: data like BMI that consists of component elements previously and/or independently added to EHR, such as weight, height for BMI (Discourse discussion w/ diags)
snapshot of query result: it would be useful to be able to capture the result of a query, e.g. ‘blood glucose over the last month’, ‘migraines over last year’ as a static data item within a note / summary / report;
generated report: a report consisting of content created by AQL queries, which will include cited content inline [more precision needed here].
In addition, the following needs appear likely in all of the above situations:
added annotations / meta-data: likely to be a need for adding annotations or other meta-data to the reference or citation within any of the above content types.
owning context: access to the owning context(s) of the cited content item(s), e.g. an Observation for an Element, and the Composition, providing the event context.
Further, there is a need to be able to ‘see’ and specify content inclusion / citation / linking in archetypes and templates, which is not possible today.
https://discourse.openehr.org/t/linking-in-openehr-goals-and-problems/1032
https://discourse.openehr.org/t/care-plans-in-the-real-world/2601/5
https://discourse.openehr.org/t/cross-reference-citations-and-a-solution-for-managed-lists/1355
There appear to be the following kinds of logical referencing needed:
virtual content: the user wants to include some pre-existing content within a new Composition, instead of creating the content from scratch;
the ‘virtual content’ item(s) fit inline in the RM structures.
e.g. BMI height and weight ELEMENTs virtually included in BMI data structure
e.g. prescription INSTRUCTIONs included in Care Plan, Medication list
the virtual content should appear inline for the purposes of querying execution
the virtual content should be included (somehow) when the data are shared outside the EHR, i.e. in serialised / transmitted form;
citation: a ‘see’ reference is made to some previous content, from within newly authored content, e.g. a reference to previous lab result Compositions are included within an Evaluation representing an assessment or plan;
the cited content is never included inline in the citing location
the cited content is not included when querying the citing content;
however the content should potentially be resolved when sharing the citing content e.g. in an EHR Extract or as a document or report;
resolve just the cited items, or the whole containing Compositions?
query result snapshot: possibly represented as a list of citation references pointing to the query result; needs to be inside some special container that includes query-related meta-data (e.g. query, date-time executed etc)
TBD
It seems fairly clear that one technical representation will not cater for both virtual content and citations - they are semantically different. We therefore treat virtual content and citation as separate design questions.
It is also clear that a ‘document’ as a signable artifact is not the same as primary structured content, nor report results or EHR Extracts.
This recapitulates some of the issues listed in the above-linked discussions and wiki pages.
Persistence: virtual content should be persisted in a form distinguishable from standard content, and with references included
Q: is resolved form persisted as well?
Content resolution: virtual content targets are resolved at retrieval time
Q: in what form: original computable? Serialised / renderable form?
Querying: AQL querying can be performed with an ‘include virtual’ switch on, that has the effect of following and resolving virtual content refs prior to executing the query logic; in this mode, query results will include resolved virtual content
With ‘include virtual’ off, querying will work as it does today, and will not treat virtual content targets as being part of the data
Reports and Documents:
TBD
TBD
TBD