...
- 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 just takes it out of the list.
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):
...