LLMCMSS.02 - LLM LUI Functional Specification

The LLM system Local User Interface - LLM LUI - is the central entry point for the local user access to the LLM system.

In other parts of this document it will be referenced as LLMLUI or LLMCMSS.02.

LLMCMSS.02.00 Document Control

LLMCMSS.02.01 General

1. The LLMLUI shall be based on the LLF - LLM LUI Framework
2. Access to any function shall be controlled by the rights a user has by their credentials

LLMCMSS.02.02 Usage Scenarios

LLMCMSS.02.02.01 System Start / Shutown /Session housekeeping

1. When switching on the LLM local terminal, the LLMLUI login screen shall be presented
2. It shall be kept in mind to enable a future enhancement: When switching off the LLM local terminal, the user's session shall be locked and cancelled (timeout logout) after a configurable amount of minutes. Additionally, switching off or loss of power of the local terminal shall be reported as an alarm condition.
3. Inactivity/Logout timeout shall be configurable as a system item overridable by a user item
4. Inactivity timeout shall be made variable depending on the active screen(s)/window(s)
5. An application shall be able to "re-arm" the inactivity timeout (in case a longer activity does not require user LUI activity)
6. Sessions shall be saveable and recall-able, also from other local terminals in the same LLM system. However, no additional functionality shall be developed, only the method of handling sessions shall allow this "transportability"
7. Sessions shall have unique IDs identifying one sesion uniquely in activiity logs and for audit purposes

LLMCMSS.02.02.02 Logging in

1. Login shall grant user access to the system and authenticate them by various credentials:
   1. enter username and password onscreen
   2. provide ID by contactless smart card (smarcard reader required on local terminal)
   3. provide ID from Wii-Controller or similar non-standard device by opened library API
2. It shall be possible to log into one of more LLM system instances
3. Alternatively, a user having rights in more than one LLM system instance may be automatically logged into all of them
4. Login screen shall be able to be pre-populated when provided with data from ILC or a trainer/care-person
5. ILC or other application shall be able to initiate logout upon movement detection or patient change situations. Provisions shall be made as in LLMCMSS.02.01.02.01 above, but no real implementation, as automatic logout has still to be defined not to do more harm than being useful.

LLMCMSS.02.02.03 User Administration

As of LLMCMSS Issue 0.8 and newer, there is no administration task to be handled using the LUI. All administration is to be handled via RUI. Therefore, the requirements in this section are moved to LLMCMSS.04.05.01, leaving this section here only as a forward pointer.

1. LLMLUI shall allow to create a user account, provided creating user has appropriate rights
   1. new user account shall be pre-filled from a template, template shall be selectable at creation time
2. LLMLUI shall allow user account deletion, provided user has appropriate rights
3. user accounts shall have arbitrary number of attributes, LLMLUI shall take account for this fact:
   1. UserCategory: Senior, User
   2. UserRole: Relative, Therapist, Administrator, Unknown
   3. All attributes assigned by LLMDB web service interface
   4. Additional Attributes as seen fit to fulfil additional features:
      1. Multi-Tenancy
      2. Sub-Grouping
      3. Privacy Attributes
      4. Judisdiction imposed properties
4. unique user ID shall be constant across database versions and shall allow
   1. moving a user across database instances
   2. exporting / importing single or multiple users
   3. merging and splitting of LLMDB instances during re-organization
   4. manipulation of users on database level without breaking validity on web service level

LLMCMSS.02.02.04 Invoking xTC and other subsystems, switching LUIs

1. LLMLUI and all subsystem LUIs shall have a set of controls to switch to another subsystem (for this part, LLMLUI is assumed to be just another subsystem LUI to be switched to, which will hopefully prove as the intuitives way also for the user).
2. If the subsystem to be switched to is not already started, it shall be started when switching to it, creating a look-and-feel of "always there" which may be more convenient for the user perception.
3. each subsystem shall have its own window. Usually, only one subsystem (the one called to be "in front") will be visible at a given time. However, on larger screens more than one subsystem LUI will be visible with possible overlap, but with a clear notion of one being "in front". Thgis shall be implemented by means of LLF, LLF using the appropriate OS library functions available in all target OSs for the local terminal platform.
4. subsystem LUI processes shall be able to request to be put "in front " in case of important information to be displayed.
5. Apart from being "in front", LUI windows shall be able to request attention by drawing on their windows anyway (also if not "in front", screen display may find another way) and by generating audible output, which shall be possible also for not-"in front" LUI windows. Audible prompts may be a convenient way anyway for appointments or schedules without any need to put the generating window it front if the sound messages contains the appointment or schedule information (text-to-speech).

LLMCMSS.02.02.05 Scheduling and appointments

1. The LLM and CMS LUI shall allow to view scheduled appointments on request by providing a "calendar" button on each menu screen.
2. The scheduler-LUI shall show a day/month/week/list view with appointments marked.
3. If an appointment is due, the schedule-LUI shall be able to transfer control to the LUI the appointment is for:
   1. CTC and PTC for a scheduled training session, passing training schedule information to the respective xTC to automatically start with exercises and instructions
   2. ILC with additional information for invoking phone or video conversations for trainer's or doctor's appointments or to start conversations with relatives on their birthdays
   3. simply displaying a message or playing an audible or video announcment for general reminders
4. Editing schedules and appointments shall be done with the CMS and CMS RUI by therapist, relative, trainer etc..
5. Schedules shall be stored in the LLMDB associated to their "owner" user account
6. Schedules shall be able to trigger workflows of activities to be executed in sequence. Such chains shall be implemented as chains of scheduled acticvities.
7. To enable chains of activities, there shall be a number of special "trigger" conditions apart from a certain one-time or repeating interval:
   1. At logon. Most probably linked to a specific local terminal or group of terminals. Also shall be qualifyable by the logon method, i.e. using an ID card or one of a set of  ID cards.
   2. After completion of another activity, with optional time delay.

LLMCMSS.02.02.06 OPTIONAL: Remote Control and Remote Assistance

This section is optional and shall be implemented if provided by underlying technologies as the windows terminal server or remote access functionalities. Further added functionalities must be re-evaluated during operation of LLM system V 1 to assess more detail support requirements.

1. A support person shall be able to share user's local terminal view or at least a set of windows and their state.
2. The support person shall be able to assist the user and perform actions on the LUI on their behalf in parallel with a audio or video conversation.
3. This remote support scenario shall help in implementing use cases like trainer-assisted PTC and CTC usage.
4. In a usage scenario of workflow and remote control the support-person's local terminal shall have a pop-up with the user's local terminal address and shall be able to connect to the local terminal by clicking on a control in the pop-up.
5. Seeing the user's local terminal window, the support person shall also be enabled to know the cause for support by seeing the appointment pop-up.
6. Alternatively, provisions shall be developed to have cross-terminal and cross-session workflows