...
- are curated, i.e. manually managed (i.e. not query results)
- have content consisting of ‘focal’ and ‘related’ data - ‘focal’ meaning the thematically central data i.e. problems, allergies, medications etc; ‘related’ meaning anything else;
- are not the primary structure in which the thematically focal data (Dxs and the like) are originally recorded
- have their own documentary structure, i.e. something like Section/heading structure
- the focal content is citations of previously recorded diagnoses and/or other ‘problems’
- may have citations of other related previous content, e.g. important observations, past procedures etc
- ?could have have internal de novo content, i.e. not just own Sections, but Entries (probably Evaluations?) created within the List to represent notes? summaries? thoughts about care planning?
- are managed over time by the usual means, with each modification creating a new version.
The above requirements have the following consequences:
- Logical list content, i.e. allergy Dx, other Dx, Medications etc always have their primary representations elsewhere in the EHR; i.e. the cited form in the List is always a reference to something else, regardless of how it is displayed.
- Deleting an allergy from an Allergy list, or a Problem from a problem list doesn't delete the original Allergy or Problem Entry; it deletes the citation from the list. This is very important for the referential integrity of the EHR.
Technical Requirements
The technical requirements are as follows:
- The list should be retrievable as a single entity, i.e. Citation targets should be resolved to their content
- Cited contents should not be counted twice in querying
- A Managed List is a persistent Composition
Design Considerations
To achieve the result that the full List, including all cited contents, is returned through the API on request requires a solution to either persisting or computing the full contents of what the citations point to. The options include (with some obvious dangers listed):
...
- The main disadvantage with the LINK solution is that LINKs are attached to other LOCATABLEs, and are not themselves primary content objects (i.e. they are not LOCATABLEs themselves).
- Due to not being LOCATABLE, LINKs do not carry archetype node codes from archetypes, and LINKs acting as Citations cannot be individually identified in the data via archetype codes.
- 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).
- LINK citations cannot themselves have other LINKs pointing at them (they are not LOCATABLEs);
- if we routinely archetype LINKs within archetypes, it will be harder to distinguish Citations from other LINKs that might be archetyped.
...