#193 Automatic UI generation: order of CTEs, scaling, labels, etc.

[Björn Andersen]

Presently, the order of containment tree elements corresponds to the "clinical relevance" of the CTEs. This, however, is within the responsibility of the service provider and not defined properly. The consumer can therefore not deduce much if anything from the order of CTEs.

Different stakeholders have voiced the desire for providers to express an order that a consumer can use for the automatic generation of remote user interfaces. This is what the current order of containment tree elements has been (ab)used for in some implementations. Other present uses of the order are not known to the author of this ticket.

There should be a broad discussion as to whether this shall be explicitly facilitated, e.g.in a way similar to pm:AlertConditionState/@Rank. It should also be discussed, which other information for UI generation would have to be included (size, spatial orientation, colour, ...). The colleagues at mediTEC (RWTH Aachen) may have suggestions derived from previous research.

The results do not necessarily have to become part of an amended BICEPS standard. A (standardised?) extension or even a separate compatible UI description model are conceivable.

2021-01-19: To add to the list of desired features: Scaling (suggestion) for the remote display of a waveform.

2021-02-04: Another important issue is how to label CTEs when displayed to the USER by a remote consumer. Currently, most of the responsibility is with the consumer because providers do not provide designated labels (e.g. those that are used at the UI of the provider). Providing objective evidence that users can understand these, no matter where and how they are displayed, would be extremely challenging for a provider. Therefore it is currently not easily possible for a consumer to display e.g. measurements from a provider if the consumer is unable to interpret their type without ambiguity.

[Björn Andersen]

@codimon wrote in [p11073-10700-pre-ballot:#26]:

The order is important, if a node contains child nodes which are identical from a Descriptor perspective (type, unit e.g for metrics). An SDC Consumer needs some way of dealing with that situation, especially for mapping to something displayed/given to a user.
Therefore, the order within children must be absolute and static. Without that, SDC Consumers cannot deal with SDC Provides that do not make elements uniquely identifiable by their Descriptor element values. As long as in SDC it is allowed to have Descriptors with same values, the only way around that would be that the provider defines and assures additional order information. It is just a hint to the client what to display first e.g. the order of the tabs in the setting dialogue.
In BICEPS the order of entries is related to the sequence the elements appear in the XML representation of the tree. This order is total. However, this can be expressed without referring to clinical relevance. Clinical relevance is not fixed and can differ and therefore should not asked for by PKP.

[Stefan Schlichting]

From my perspective there should be a clear distinction between the relevance/rank, the unqiue identification, the user perceived identification and the display of elements on a UI.

Rank:
The rank is an optional ATTRIBUTE allowing finer distinction of ALERT CONDITION priorities where a relationship between ranks exists.

Clinical Relevance:
Clinical Relevance is somewhat similar to similar, but for other elements of the containment tree.
Clinical Releance is used in lists (e.g. of Channels, Metrics) where the ELEMENT with a lower list index has a higher clinical relevance than any entry with a higher list index.
During the creation of clinical relevance it was discussed that the relevance is either defined by the user or automatically by the defined for its intended use. Typical is a combination of both where the device has a default relevance order and the user can change the order based on its specific clinical needs. It was also discussed to introduce a specific attribut for clinical relevance similar to Rank, but it resulted in the decision to not change the model as this the clinical relevance is "more static" in contrast to the rank.
Moreover, it is " typical" that an element that is more clinically relevant is indicated to the user instead of a less relevant element if there is a conflict of using the display real estate. So a Service Consumer can decide to use the clinical relevance order as a start UI configuration, but may a allow a local reorganization.

Physical Connector
User Perceived identification was requested in BICEPS balloting: [p11073-10207:#189]
The physical connector can be used to uniquely identify a metric or device component if the elements are otherwise not distinguishable.

The requested function in this ticket is only partly related to the generation of an automatic UI, but seem to be related to duplicate the UI of the Medical Device represented by the SDC Service Consumer. For this a solution based on a dedicated VMD/Channel might be appropriate.