Examples - HospInfo case study
HospInfo - a Hospital Information System (HIS) prototype
This example was modelled with UWE Profile - v2.1 defined in the Magic Draw 16.8 CASE tool and is available as mdzip and emf.
It is divided in three parts:
Design considerations and requirements
General
For our case study we consider administrators, physicians, nurses and receptionists as the most important user groups, which are represented as actors in the use case diagram shown in Figure 1. The following functionality is required for HospInfo: Staff members should be able to register by providing a forename and a surname, a well-formed email address and a password, which has at least the length of five characters and which has to be entered twice to avoid spelling mistakes. The roles of the staff members are set later by an administrator, who also chooses the ward (or main workspace).
Consequently, registered visitors initially have no special permissions, except editing their profile, e.g. changing their name in case of marriage or spelling mistakes and their email address. They can also set a new password (which requires entering the previous one first). Furthermore, a logout option is required. If someone forgets his password he should enter his email address to receive a new one. Logged in or not, the home page and a page with general information, such as useful links and phone numbers should be accessible for everyone, as depicted in Figure 1, the UML use case diagram of HospInfo.
Physicians need the permission to create new patient records or change information of patients. The patient information can be read in a list of all patients. This would not be convenient for normal sized hospital, therefore a search function is necessary. Each patient record should comprise name, gender, date of birth, address, blood group (A, B, AB or 0), the affiliation to a ward and medical information, given by diagnosis-related group (DRG) codes or free text.
Nursing staff should be able to read the information about patients from their ward and access the health records of the patients from other wards in emergency (which differs in the fact that the access is logged). For this purpose, two lists of patients should be presented: one for the patients of the same ward as the nurse and one for other patients (cf. use cases ShowOwnPatientInformation and ShowOtherPatientInformation in Figure 1).
It should not be the task of physicians to enter organizational patient data, usually this is done by receptionists who can read all information (or at least accounting relevant parts), but cannot change health related data, because they normally have no medical education.
Use Case Model
Figure 1 shows the use case diagram of HospInfo
In Figure 1 it can be seen that use cases like EditPatient and
DeletePatient are stereotyped by «processing» (
), whereas
use cases that do not change the state of the application are annotated
with «browsing» (
).
Additionally, stereotypes can be omitted, if they are
assigned to a parental package, which in this case is used for the
UserManagement package.
HospInfo should become a prototype to demonstrate the model and implementation of security features (see next section). An application for a real world scenario would include more features, the patient registration would be separated from the admission and the former visits would be saved together with the medical report as well as the treatment, e.g. medication or surgery and the linked resources, e.g. blood values or diagnostic images. Usually there is a calendar and there are dedicated views for each section, e.g. for radiology, pharmacy and for laboratories. Every staff member also has an own calendar and some entries have to be synchronized, e.g. appointments should allocate time in the calendar of a patient as well as in the one of the attending physician.
Security Features
We have chosen our case study with regard to the manifold security aspects that are important for a HIS:
- A secure user management ensures that no credential theft occurs. In HospInfo, the password should be entered into an HTML password field (the characters are not shown) and the credentials should always be transmitted in a secure way.
- Therefore, secure transmission is required not only for sending the credentials, but also for retrieving medical data. Thus, freshness, confidentiality and integrity are crucial for a HIS, as it is easy to be liable to prosecution, when confidential data gets into the wrong hands. Consequently, Figure 1 shows the tag {transmissionType='cif'} for the «webUseCase» package to specify this requirement.
- The login session should provide a session timeout so that the users have to re-authenticate themselves after a certain amount of time. This is necessary, because medical staff is often called off in an emergency without having the time to log out.
- Access control should be available, as described above. RBAC supports the following roles that correspond to actors in the use case diagram: admins (full access), physicians (read and write access to all patient data), receptionists (can read all patient information, but are just allowed to edit non health related entries), nurses (read access regarding patient records). As depicted in Figure 1, the break glass policy is used to allow logged access for nurses in case of emergency, e.g. if a nurse is called to help a patient from another ward and it is required to access the patient record. Access control does not only refer to the access the users have on objects, but also to the web pages they are allowed to see in their role. This is tackled in two ways: on the one hand, unavailable options should not be shown; on the other hand, an access denied error message should indicate that the user has to login with the appropriate permissions to display the requested page. This happens especially, if the user tries to access parts of the application directly, using a URL. An example would be a nurse trying to access the patient creation form, using the URL https://host/createPatient. In this way HospInfo demonstrates typical secure workflows: user registration, authentication and authorization, password recovery (or change) and session or error handling are addressed.
Further UWE models
UWE specifies Web applications following the separation of concerns, i.e. modelling the following views separately:
Content Model
When the modellers know the main concept of the future application, they usually start with the content model to capture the involved elements as UML classes. In HospInfo the focus of interest is on the Patients with some attributes as name, address, ward or gender (see Figure 2). If the item administrative is chosen for the patient's ward from the Ward enumeration, it means that a patient has been created for the purpose of software testing.
Figure 2 shows the content model of HospInfo
The associations to User and Role are shown in the content model even if both classes are located in the user model as described in the next section.
User Model and Role Model
In the user model the class User is accompanied by the enumeration Role. We have chosen an enumeration with regard to the future implementation with the web framework Lift.
Figure 3 shows the role model of HospInfo
The user model includes the almost self-explanatory role model that is depicted in Figure 3. The UML association role inheritsRightsFrom is not shown in the enumeration items, because MagicDraw does only support the link presentation between those items.
Basic Rights Model
Figure 4 depicts the basic rights model of HospInfo with access specifications for the classes User and Patient.
Figure 4 shows the basic rights model of HospInfo
The rule that admins cannot change their own user account is depicted with the «authorizationConstraint» in the centre of the diagram. Thereby the 'variable' currentUser stands for the operating administrator. The {except=healthStatus, blood} tag on the «updateAll» dependency between the receptionist and the Patient specifies that the updates on all other attributes of the class Patient are permitted. By contrast physicians can «updateAll» Patient attributes without any {except} restrictions. For nurses, the Break-Glass Policy (BGP) for patients of other wards is captured in a rather informal «authorizationConstraint» (see bottom of Figure 4).
Navigation States Model
The UWE navigation states model consists of a set of menus
(see Figure 5) that are connected with the state machines. Abstract
menu classes as DefaultMenu (
) cannot stand for themselves.
That means there is no menu that only presents those five
menu entries. HospInfo offers eight menu entries to an external
visitor: the five ones from the DefaultMenu and three additional
ones that belong to the Visitor class.
Figure 5 shows the navigation menus of HospInfo
The names of the menu classes give a clue where they are
finally used, but the concrete connection is set up in the
navigational «session» (
) states. Figure 6 shows the
main navigation state diagram for HospInfo. At the bottom of that
diagram some external links can be found (
). They correspond
to the links that are always displayed in the footer of the application.
The whole application HospInfo transmits all information in
a confidential way and cares for the integrity and the freshness of
the data (denoted by the tag «session» {transmissionType='cif'}).
Basically HospInfo consists of two navigation areas that are
depicted in Figure 6: a visitor area (in the diagram on the left)
and an internal area (on the right), which is guarded according
to the existing roles. The guards on the transitions are needed to
specify the available menus and the «session» {roles} tag allows
the modeller to define a set of roles that each can access the state.
In the visitor area the UWE patterns are used as substate
machines e.g. for the secure login via password form and for
the password recovery. The triggers of the transitions from the
visitor session to substates are linked with operations from the
«navigationMenu» classes.
Figure 6 shows the visitors navigation diagram of HospInfo
After the successful login, the menus that should be available for the user are constructed with guards and the «integratedMenu» stereotype. In case of unauthorized access the AccessDenied state is activated. If the user is logged in, an internal error node becomes active, if not an external message is displayed, which differs from the navigational perspective at least in the navigation menu that is available.
An example for an actual internal node for receptionists or physicians is depicted in Figure 7. Because of the integrated menus, the three triggers createPatient(), showPatients() and searchPatients(...) are removed from the inner transitions and combined with the first transition in the MultipleRolesArea state. After applying the transformation according to the specification (see thesis, chapter 4, specification 13), three transitions connect the MultipleRolesArea state with three new entry points of the topmost substate machine.
Figure 7 shows the Navigation diagram of receptionist / physician area of HospInfo
Another feature of the diagram in Figure 7 is the use of
the «target» (
) stereotype. It makes sure that after canceling
the creation of a new patient HospInfo navigates back to the
previous page of the application (or to the MultipleRolesArea,
if the patient creation had been accessed directly).
Furthermore, the ShowPatient state is a «collection» (
) of
Patients and due to no outgoing transition is stereotyped by
«allItems» all trigger methods refer to a patient element, e.g. the
edit(_) method stands for edit(p:Patient).
Navigation Class Model
To be able to draw a comparison between the new navigation state diagram and the traditional navigation class diagram for HospInfo, the latter is depicted in Figure 8. The modelling of authentication issues is not provided, but menus as the ExternalMenu, AdminMenu etc. allow to draw conclusions to the substate session areas that are depicted in Figure 6.
Figure 8 shows the traditional navigation model for HospInfo
An advantage of the navigation class model is the clarity of the diagram that is supported by the division in several packages, in this case in UserManagement and PatientManagement. But security features and sessions have no representation in this traditional navigation model.
Presentation Model
This subsection gives an example of the abstract presentational
view that is modelled with UWE, wheras the concrete layout of
HospInfo is presented in the next chapter.
Figure 9 depicts the default page layout: a Headline «text»
(
) on top, a Footer at the bottom of the page and on the left
a NavigationMenu with anchors (
) that determine the body
of the ContentArea, «presentationAlternative» (
) class, which
means that exactly one of the included «presentationGroup» (
)
properties can be displayed simultaneously.
Figure 9 shows a template of the presentation model of HospInfo
The diagram in Figure 10 shows the concrete classes for the
nurse area. The classes NavigationMenu and ContentArea are the
same as in Figure 9, but different properties are modelled.
On the left of Figure 10 the menu is depicted that can be
unfolded so that AllCategories «presentationGroup» () i.e.
all submenus are displayed. Again dependencies are added to
understand the effect of a link. For example the ContentArea
shows the patients of the same ward after the according anchor
in the menu had been activated.
Figure 10 shows a part of the presentation model of HospInfo. All other presentation diagrams can be found in the MagicDraw project.
Process Model
The UWE process model is used to present detailed workflows. For HospInfo example diagrams are introduced for the process of creating a patient and for the process of editing user properties by an administrator.
Figure 11 depicts the first case and the UWE stereotypes «userAction» (
)
and «systemAction» (
) are used to draw a distinction
between actions that are carried out by the user or by the
system. Thus the user edits a new patient (EditNewPatient), but
the validation of the data is done by the system. It is noticeable
that we do not model any distinction between system actions that
are executed on the server and those which are processed by the
client.
Figure 11 shows an example for a process of HospInfo
Figure 12 shows a similar activity diagram for the process of editing user properties. The difference to Figure 11 is that if the administrator e.g. wants to remove the 'registeredVisitor' role for a user, HospInfo corrects this value and generates a hint. It is a bit unusual to implement the registered visitors as a role, because all users that are available in the system are of course 'registered', but we wanted to stick closely to the model in this case study. Due to the lack of space, not all diagrams could be depicted in this chapter. The interested reader may refer to the attached MagicDraw project on CD.
Figure 12 shows another example for a process of HospInfo
Implementation of a HospInfo prototype
An implementation in Scala/Lift is available and described in further detail in thesis, chapter 7.
Figure 13 depicts the SSL connection in the browser Firefox. In the page properties it can be seen that HospInfo establishes a secure Advanced Encryption Standard (AES) connection with 128 bit. This is the implementation of the «session» {transmission- Type='cif'} tag of our UWE navigation state model.
Figure 13 Implementation - Login.
For the implementation of the logging functionality, the log4j24 library is used and referenced in our pom.xml. We particularly need the logging to realize the BGP concerning nurses. This means nurses are allowed to access patients of other wards in case of emergency, as depicted in Figure 14, but the access is logged. In addition, all changes of electronic patient records (EPRs) are recorded as well.
Figure 14 Implementation - Nurse area.
More information is available in thesis, chapters 6 and 7 and further diagrams can be found in the project file.