Keywords

1 Introduction

The Italian Ministry of Education, Research and University funded the project Toward new methods for early diagnosis and screening of genetic ocular diseases in childhood (PRIN 2015), aiming to detect new methods for the study of Inherited Retinal Diseases (IRDs). Chromatic pupillometry is the method used to study and evaluate the cones and rods functionality. Its application in paediatric ophthalmology represents a pioneering approach for IRDs diagnosing and monitoring. A pilot study has been designed to evaluate the clinical feasibility of the pupillometric protocol and the usefulness of chromatic pupillometry. The study is multicentric: 60 cases and 20 controls have been recruited and examined by the project clinical partners. The cases are IRD-affected children, while controls consist in healthy subjects. The age range spans between 8 and 16 years [1]. The Department of Information Engineering (DINFO), University of Florence, has been involved in the project because of his previous experiences in developing RESTful web applications and Clinical Decision Support Systems (CDSS) [2,3,4]. An Electronic Medical Record (EMR) has been designed and realized to collect examination data of cases and controls both from the recruiting centres of Milan and Naples.

In this paper ORÁO,Footnote 1 the EMR realized for the above-mentioned project, is presented. A particular attention has been posed in describing the interfaces of the platform and the features that make them usable and reduce safety issues.

2 Platform Project

The EMR has been deployed as an .NET application, with Model View Controller (MVC) architectural code pattern. This cloud-based platform is hosted on the server farm of the DINFO, one of the project partners. A key design requirement for this platform is to have a cloud-based application, because of the multicentricity of the study. Data recorded by physicians are stored in a database which provides query functionalities for clinical evaluations concerning the pupillometric protocol and the pilot study itself.

The design of the platform is described in the following sections.

2.1 User Interface Design

The platform, named ORÁO, has been designed to facilitate the implementation of the visit workflow, specifically designed for this project, minimizing the overall impact on the staff. The healthcare providers must perceive it as a way to improve the quality of their work, instead of one more technology solution they are forced to deal with.

The platform must have a dedicated web page for every stage of the visit, from collecting patient personal data to single exams and procedures. The examination data collecting form has been designed starting from the specifications given by the clinical partners who participated in conceiving the pilot study. A list of input fields that every examination page should contain, as well as the type of each input field (short or long text, date, file, multiple choice, boolean, decimal or integer), has been implemented including potential maximum values that cannot be overstepped.

Usability is defined as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use” [5]. It means that it is possible to reduce safety risks with an usability-oriented design of the interfaces in the platform. Thus, techniques and standards for ensuring high levels of usability must be adopted to provide an optimal user-interface experience by the physicians [6, 7].

2.2 Pilot Study Design

The pilot study establishes a baseline visit and a 28 ± 7 days follow-up. Examinations consist of participant’s personal data collection, registration of ophthalmologic clinical and instrumental data and pupillometry. The pupillometric protocol designed in the pilot study is performed by multi-chromatic pupillometer DP-2000 by NeurOptics (see Figs. 1 and 2). It is able to stimulate one or both eyes with different user-selected light intensities and colors. Then the pupil profile and light stimulus characteristics are transferred from the device to a data file with extension .DAT for external analysis. The pupillometer works at a sampling frequency of 30 Hz. Light stimulation has four different chromatic options: red (622 nm), green (528 nm), blue (463 nm) and white.

Fig. 1
figure 1

DP-2000 multi-chromatic pupillometer, by NeurOptics

Full size image
Fig. 2
figure 2

A particular of the pupillometer DP-2000, showing the camera and its support arm

Full size image

After an initial period of ten minutes of dark-adaptation, the patient is stimulated under three different conditions: low intensity stimulus with dark background, high intensity stimulus with dark background and high intensity stimulus with blue background, the latter is performed after 3 min for eyes adaptation to light. Every stimulus is repeated three times for light colors of red and blue, for a total of eighteen stimuli (see Table 1).

Table 1 Pupillometric protocol
Full size table

Different light color, intensities and background color stimulate the various light-sensitive retinal cells. These cells respond to the light stimulation by changing the pupil diameter. Physicians must analyze pupil time trend to evaluate the function of the retinal cells. The pupillometer measures and records the pupil response to the light stimulations expected by the pupillometric protocol. The output of the pupillometer DP-2000 is, as stated above, a .DAT file composed by various sections. Section <merged-pupil-data> contains data regarding the pupil diameter response; in particular, columns 2, 4 and 8 respectively collect time, right-diameter and left-diameter sampled values of all the acquisitions, according to the pupillometric protocol of the pilot study. This values must be properly elaborated to be presented to the physicians in a suitable way: when the specialist studies the pupil response, he/she must choose the stimulus index and view the relative graph of right and left pupil diameter time trend. Moreover, in another section of the .DAT file, there are parameters of medical interest, collected in a table. This information must be extracted and made available in the platform interface for the end-users.

2.3 RESTful Cloud-Based Platform

Since the pilot study is multicentric, ORÁO must be remotely reachable via web. For the same reason, the platform must be provided with a central database for clinical data storage and data must be available and visible by all scholars involved in the study. A Virtual Machine (VM) has been created on the above cited server farm at the DINFO in order to respond to the previous characteristics. The VM hosts the web server running the application as well as the database engine.

The user, after a login step, must be able to view data stored in the database using the platform interface, edit the existing records and input new information. The physicians of the recruiting centres of Naples and Milan involved in the study must be provided with the possibility to export a .CSV file containing pupillometric data, in order to evaluate the progression of the pilot study. The platform must be implemented with a RESTful architecture. It facilitates data exchange between server and clients. It also permits an easy future integration of third-party applications with the developed Application Programming Interfaces (APIs).

3 Results

The web application has been realized in MS Visual Studio 2017Footnote 2 using Visual Basic .NET (VB.NET) and ASP.NET framework 4.5.2. The pages have been implemented using Twitter Bootstrap v.3.3.7Footnote 3 framework, an open source toolkit for web development with HTML 5.0, CSS 3, and Javascript (JS). The database is realized using the Relational Database Management System (RDBMS) engine Microsoft SQL Server Express 2008 R2. APIs have been implemented in .NET.

At their first use of the EMR, physicians are requested to sign up by choosing an email address and a password. Then the access has to be approved by the administrator of the platform. Once the user is allowed to access, he/she is able to log in and use the EMR to register, modify and examine patients’ data. From the homepage of the platform (see Fig. 3), users are able to enter personal data of a new patient or to access to clinical data of patients already registered in the database. The top navigation menu, displayed in every page of the application, gives the user the possibility to:

Fig. 3
figure 3

ORÁO homepage

Full size image

  • Register personal data of a new patient coming for the baseline examination, by clicking on the button New patient;

  • Select an already registered patient from the Patients list, which contains name, last name, birth date, fiscal code and gender;

  • Search patients by name, last name, birth date, fiscal code or any combination of them.

When a physician selects a patient, he/she is redirected to a page showing all the patient follow-ups identified by the date of their registration. Each one of them is also associated to a green or white background color (see Fig. 4): if follow-up date has a green background, it means that it is consolidated and no more editable, but only viewable. Once the user has selected the date of the follow-up he wants to open, he is redirected to a page where he can choose the ophthalmologic examination he desires to register, edit or view.

Fig. 4
figure 4

Example of the list of follow-ups registered for the selected patient. It is possible to notice the difference between consolidated and editable follow-up dates

Full size image

There are two types of examinations: binocular and monocular examinations. In the monocular examinations interface, input fields are layered on two columns. The right column’s input fields are intended to collect data about left eye. As it is possible to see in Fig. 5, on the upper level of the column it is clearly indicated the corresponding eye (right and left). This is the typical approach used by ophthalmologists and it is also adopted here as a mean for risk reduction. Monocular examinations can be clinical and instrumental. For binocular examinations (see Fig. 6), anamnesis, binocular investigation and genetic report can be saved inside each follow-up.

Fig. 5
figure 5

Example of the interface of a monocular examination page

Full size image
Fig. 6
figure 6

Example of the interface of a binocular examination page

Full size image

Both monocular and binocular views have on the left side a menu containing personal data of the patient being examined. Furthermore, on the top of the examination form the follow-up date is shown and patient’s name and last name are repeated and highlighted.

Pupillometry interface The pupillometry interface (see Fig. 7) has been designed to properly show the pupil diameter response to each stimulus, as stated by the pupillometric protocol. In this page, users are requested to upload the .DAT file containing the pupillometric output of the examined patient. Then the file is read and data are elaborated in order to present clinical information in a way that is suitable to physicians’ studies. Users must also choose the index of the stimulus they need to view.

Fig. 7
figure 7

Pupillometry page: the graphic of pupil diameter time trend and the table with the parameters measured during the stimulations

Full size image

Afterwards, the graphic of the right and left pupil stimulus response is shown as a function of time. Moreover a table containing parameters of interest, measured during the stimulation, is provided. Moving the mouse pointer over the graphic, the user is able to read both the right and left pupil diameter values. Furthermore, a summary of technical characteristics for every stimulus is shown: stimulated eye (right, left or both), stimulus color, light intensity and background color.

Pupillometric data elaboration In the .DAT file of the pupillometer, there are two sections data are read from. In one section all the acquired values are collected together, belonging to the various stimulations expected by the pupillometric protocol; in the other section, every stimulus index (from 0 to 19) is associated to the first and last sample acquisition index (see Fig. 8).

Fig. 8
figure 8

Figure shows how every stimulus index is associated to the corresponding start and end sample in the .DAT file, output of the DP-2000 pupillometer. The first column contains stimulus indexes, while the third and fourth columns collect respectively the first and last acquisition index

Full size image
  1. 1.

    The user uploads the .DAT file he/she wants to study and chooses the stimulus index (from 1 to 20) from a menu in the pupillometry interface (see Fig. 9).

    Fig. 9
    figure 9

    Figure shows how user is expected to choose stimulus index from the drop down menu in the interface

    Full size image
  2. 2.

    The index chosen by the user is read from the interface (client-side) and used to extract the corresponding first and last sample numbers from the .DAT file (server-side).

  3. 3.

    Once the first and last sample numbers are identified, all the values in between are stored inside a matrix. They correspond to time, right and left pupil diameter acquired by the pupillometer during the stimulation.

  4. 4.

    The matrix is elaborated thanks to the JS library D3Footnote 4 (Data Driven Document). The D3 library allows to create the final graph presented in the pupillometry application interface.

In the x-axis, time is measured in seconds while diameters values are expressed in millimetres. Dynamic labels have been created with D3 aiming to make the graph as readable as possible: while user moves the mouse pointer over the figure, punctual values of right and left pupil diameter are shown.

4 Discussion

In this paper, ORÁO, a cloud-based EMR for ophthalmologic examinations, has been presented. It has been designed to match the characteristics of the pupillometric protocol as well as the specifications given by the physicians involved in the pilot study. High attention has been given to the usability of interfaces, introducing elements and redundancies with the aim of reducing safety issues, originated by the use of the platform.

As described above, in the top area of all the platform web pages a menu providing direct links both to the previous page and to the current page is displayed.

This element is very important to provide the end-user with a full awareness of the selected functionality during his/her navigation through the platform. It also facilitates a better understanding of the EMR structure.

Since the purpose of EMR is to collect clinical patient data, the main safety issues deal with the possibility to make mistakes while saving data. If this should happen, the physician could make a diagnosis mistake of false-positives or false negatives because of wrong saved data, or data attributed to a wrong patient. Some elements have been introduced in the interface of ORÁO to avoid this scenario. For example, the above mentioned personal data menu which appears on the left side of the examinations form, together with the bold patient name and last name in the top side of the examinations pages, aim to provide the end user with the awareness of the selected patient during the whole process. For the same reasons, the follow-up date is always shown next to the patient name and last name in the upper menu.

In the follow-up page, users must choose the date of the follow-up they want to open. Follow-ups may be consolidated, as stated above, or editable. The user is able to distinguish these two types from the menu containing the dates, thanks to the different background color. Green corresponds to a consolidated one, while white means that edits are allowed. Other elements that contribute to make the interface as usable as possible are the feedback messages. When the user performs an incorrect action, which could possibly have irreversible consequences, a message is shown informing about the danger. The messages are as clear as possible, written in the user language to make them widely understandable. The issues concerning data storage on the web, such as safety and privacy, have not been addressed yet because the clinical study is in a preliminary phase. The appropriate measures will be taken as soon as possible, during the next evolution of the pilot study.