...
- 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 just takes it out of the listdeletes 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 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.
...