CHOS-WG Scenario: User Session

• The scope of this scenario is limited to the opening of a user session.  The typical very first step when a user arrive at morning and want to become ready to work.  A kind of basic framework on top of which more specialized things will be associated a few second later.
  
• Every medical project needs to deal with these very common issues, regardless the kind of application.  And in fact even not specific o a medical context.
  
• Many such basic frameworks are already in use with some particular flavors. The purpose of this note is to summarize the most essential concepts, as required in most projects and without going to deep in the details of presentation on screen.
   
  
• Description:
• Workstation activation:
• If not yet running set the power "on" in order to start the local workstation.
  
• Result:  an initial default screen containing a large picture presenting the project and including a frame asking for the identification of the user, the next step.
  
• Identification of the user:
• Objective:
• The user must declare who he is.  A personal identification is always required.  Only one user at a time will be active on a machine. 
• Procedure:
• The basic way is to type the "user name", usually an abbreviation of the full name, as having previously be defined by the administrator of the network.
  
• Authentication:
• Objective:
• To verify if the user is indeed who he pretend to be.
• Medical application require to known exactly who is responsible of the session.
  
• Procedure:
• The basic way to achieve this control is to ask the secret "password" of the user.  More advanced methods could be considered too.
  
• If not OK, the user may retry a few times, however a limited number of trials after longer and longer delays, in order to prevent random attacks.  If necessary the network manager could reset a new password.
  
• If OK, the user session proceed to the next steps.
• User Authorization Profile:
• When the user is authenticated, the associated authorization profile becomes available. 
  
• A user profile is a set of rules defining what the current user is allowed to do or not.  Normally most user have only one profile.
  
• The main administrator of the project can create and maintain profiles, i.e. he is delegating authorizations to other users.
• User preferences:
• In the same way personal user preference become available:
• Preferences are options which can be taken in account by subsequent modules, for example preferred spoken language, preferred mode of presentations of some view in the patient record, current preferred phone number, ...
• The user, using his authentication, can register himself his preferences.  To make it easy some likely preferences should be available in advance by default, for the local environment.
• Network:
• Introduction:
• Several approaches could be considered, but today the trend is to move from isolated and autonomous computers toward a network philosophy.  Indeed many applications require the possibility to share information with other users and the most efficient way to do that is to be on-line around a common database.
  This is why workstations will often be used in connection with a server.  However in case any communication would be not available, the system must be able to work as stand alone, although with more limited functionalities.
• In order to keep things simple, most software applications should be based on the same technology, i.e. nowadays internet technology, since most network activities are based on web technologies. 
  
• Considered architecture:
• ( I )  User interface:
• Normally a web browser connected to a server.  The advantage is to avoid to require specific software installation by partners in other environments. Indeed all kinds of computers can support internet access according to standard browser specifications.
  
• ( II )  Server:
• It does not much matter where the servers are installed:
  
• ( A )  Maybe only inside the local machine as "localhost", not depending on any communication means.
  Here of course only some local copies of data are available and sharing information with other users would be difficult.
  
• ( B )  In most situations the server is in a nearby Local Area Network, in the same building.  For example all the staff of a lab or of an hospital can share information about common patients.
  
• ( C )  Or even at a second level a server at a very remote location, trough internet infrastructures and using encrypted communications, i.e. the "Virtual Care Team" principle across organization boundaries, allowing to ask advices to remote specialists even as intercontinental telemedicine.
  
• The startup procedure can be configured to go directly to the preferred server of the user.
• The user must always provide his authentication at least once.  A server require always an authentication, but a server could be configured as accepting identification's coming from an other server in the net work.
• Security:
• In all situations where a server has to be connected to the external public internet infrastructure:
• The server must be protected against risks of intrusion.
• Confidential patient record information as well some other types of information, must go through encrypted communications.
• Security according to the the "current rules of the art", requite a set of measures in several ways and in the future the requirements could probably increase.
  Current accepted solutions are often based on "https://..." communications.
• Context:
• A user session keep a context, i.e. some temporary information related to the recent activities of the user and helping to integrate the diverse software components.
• Content:
• User identification.
• Link to the current authorization profile and to the user preferences.
• Network connection status.
• Current patient, if any:
• For example when the user is going to an other task based on an independent software component, the patient identification should not be asked again.
  
• ....
  
• Results:
• If everything is OK, the user see the main session screen, containing the following:
  
• The user:
  
• A confirmation of the identification of the current user.
• A kind of main menu representing diverse available actions:
• The idea is here to have a central and integrated page, from which the user can go to a wide range of activities.  However these menu items can be simply an entry point to more or less autonomous software components.
• Only the activities the current user is currently allowed to do.
  
• If possible, some hints about the status of the activities behind the button. 
  
• For example a button going to incoming messages and already showing if any or how many messages are waiting, and if some notifications are urgent.
• Types of presentation:
• Initially all the screen space is available to present the user and his related information in details.
• Later on, much screen space will be required for several applications, but a small part of the screen should remain permanently visible, with a short summary of the user and the most important buttons of his main menu.
  
• Main menu:
• See an overview of the most usual main menu in the next page.
• Closing the session:
  
• At the end the user must close the session.  When the user will finish to work, he must close the session,  in order to prevent other unauthorized people to make use of the session when the responsible user would already be away.
• Moreover an automatic closure is recommended and could be activated.  If no activity during a predefine delay, the user will be assumed to have quit.
• Coming back later to he next day the user will have to authenticate again.
• Considered philosophy of the human interface:
• The initial page shows some information about the user and about the menu he is allowed to get.
• The idea is that when the user will click on a button or a small fifed representing some object, the screen will zoom in the details related to this object.  A very natural human behavior, a 3 years old child can already understand.
  This zoom will bring a new frame inside the parent window or new depending windows.  Remark: maybe movable sub windows.
  
• The zooming process is recursive, i.e. the new pages may contain small fields allowing to zoom again to even more detailed views, maybe several times.
• Coming back can be achieved in 2 ways:
• Coming back one level at a time.
• Coming back directly to upper menus:
• Normally when most of the screen space is occupied by these larges zoomed frames, a few data should remain permanently visible:
• A minimum identification of the current user.
• The most important commands of the main menu, if necessary ending by a "more" button.
• The current patient record, if any.
• Required resources:
• Classes:
• Item
• Session
• Agent and User
• ...