Overview

This page proposes a solution for representing Managed lists, such as Problem lists, Allergy lists, Medications lists etc. Refer to this Discourse post. The problem and any solution are likely to be strongly related to the Report concept.

NB: although we call these 'lists' in the abstract, they are structurally usually hierarchical heading structures containing content.

Requirements

The distinguishing qualities of such lists:

The above requirements have the following consequences:

Technical Requirements

The technical requirements are as follows:

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):

There is also the usual question of whether a Citation refers to the extant (today's) version of the target content, or always the most recent, whatever that may be. Most likely it should refer to the most recent, since if target Entries were reversioned, it was probably for correcting errors.

Archetyping

In this page, the changes needed to the AOM are not included, because they will be more or less the same in call cases - probably a variation on the slot concept.

Solution #1 - LINKs

To implement the above with LINKs, we need to:

The following UML shows a resolved field in a new LINK_2 class, but this could be added to LINK as well.

Features

In the LINK solution, representing a Problem or Allergy list will be a case of attaching LINK objects to SECTIONs.

Advantages

Disadvantages

Summary

It might make sense to implement something like the above in LINK anyway, not to solve Citations, but to solve Link-resolution for Links generally.

Solution #2 - Citation Entries - resolved native form

A model based on the addition of new Entry types is shown below. This also includes other kinds of View entry, to show in principle how the solution could be generalised.

Features

In this form of model, a CITATION is a new kind of ENTRY, which can be included in SECTION structures, and with primary ENTRYs in the usual way. It is generically typed to the reference target, i.e. concrete types are CITATION<OBSERVATION>, CITATION<EVALUATION>CITATION<COMPOSITION> etc. When a CITATION is persisted, its resolved field is always empty; when retrieved, the resolved field is populated.

It contains a field resolved which is of the native target type, e.g. EVALUATION etc. This might be more useful for immediate computational use on the client side.

The resulting instance structure of say a Problem List in a client is of the form such that CITATION Entries appear under SECTIONs , possibly with other inline Entries containing primary content within the List, and the target of the Citation, i.e. various Evaluations, generally, are one further step from the Citation object.

To define a Problem List as an archetype using this structure would require:

Advantages

Disadvantages

Solution #3 - Citation Entry - resolved serial form

The following model uses a serialised form of the resolved content.

Features

In this version of the model, CITATION is a wrapper for a reference and a serialised resolved form for the source information. This model works mostly in the same way as above, but the serial form representation of the cited content may be easier or safer to use on the client side.

The resolved form could be persisted, rather than computing it every time, since it won't get confused with real entries by the query service.

Advantages

Disadvantages

Solution #4 - Different Persistence and Retrieval Types

In some sense, the resolved field in all of the above solutions is an anomaly, because it requires different treatment for persistence and retrieval. On committal, it should always be empty; on retrieval, it should be populated - potentially this might be conditional on some request flags. Another approach is to define different types for storage and retrieval, as follows.

In the above, the persisted form of a Problem List consists of SECTIONsCITATIONs and possibly other primary ENTRYs, if needed within the list (i.e. orange and violet objects). The retrieved form consists of SECTIONsRESOLVED_ENTRY<CITATION> etc, each pointing to the original CITATION objects, the resolved target ENTRYs (or other content, e.g. RESULT_SET from a query), and any other primary ENTRYs (i.e. orange and yellow objects, each of which points to a purple object and a copied orange object).

The class RESOLVED_ENTRY doesn't need to be generic as above, this is just one way of doing it to make resolved Entries related to the type of view entry on which they are based.