App Team 7

For our MINAP mobile application, we have chosen to go with the Android mobile platform. One of the main reasons behind this choice of platform (as opposed to the option of creating a mobile web app) was due to the issues of security if the app is developed further in the future for actual use in the hospital. A native application would be the ideal choice, to ensure full utilisation of the platform’s security features.

A bonus of choosing the Android platform (or any native platform, really) helps lock down the user interface to the design standards in place, rather than trying to reinvent the wheel. Most apps would conform to these standards, and so it would help with reducing the cognitive load when learning to use our mobile app.

Although this would mean a departure from the current web app’s structure (programming-wise), the benefits of following UI standards and security will hopefully far outweigh the initial cost of time (and effort) in programming.

From the previous blog post, we can see that the current web app page flow can be modelled into a simple page navigation flow, as shown below.

This interface flow diagram maps the current flow of use in the web app, with the exception of a new page addition – patient details. Patient details are currently displayed on each page in the web app, reminding the user who the current patient being entered into the database is. For mobile, we would need to separate this section into its own page due to size constraints. The downside of doing this, would mean that there would be no feedback on the page to remind the user of the current patient details – something that needs to be addressed when the UI is more thoroughly fleshed out.

We will keep the current web app’s navigation behaviour and visual signifiers (usage of back, next, and compass icon) for consistency across the whole system, to ensure that existing users can use their preexisting mental model for the mobile app.

Beyond the navigation flow, the MINAP web app makes use of question mark icons ( ? ) as points of help for the user (e.g. clicking on the ( ? ) icon next to the value “Administrative Status” will open a dialog box containing help relevant to the input box)

Our mobile app will also retain these help icons and dialog boxes, ensuring the user can obtain help within the data collection process, whenever there is relevant information to display – especially since our mobile app would ideally be used by a far wider audience than the current web app.

Not shown in the flow diagram (for simplicity’s sake) is the ability to log out from every page (with the exception of the log in page), and the ability to save. The save icon should be prominently be displayed on each value page, though the log out button can possibly be hidden from view for small screen sizes.

To get a better idea on just how we can represent these functions, we would need to further explore the visual affordances provided to us by our target mobile platform to ensure consistency across their app ecosystem.

Current Solution Analysis

MINAP’s participants use a web application for data capture. The web application is limited in its use to the Windows platform as well as to the Internet Explorer (ver 9 and below) web browser. While hospitals and clinics have this in mind, and thus have their equipment ready for these limitations, newer participants may need to go out of their way to accommodate MINAP’s needs.

Logging in

Authorised users are given a set of credentials unique to them. These credentials then create a session that keeps track of both the user and the user’s workplace throughout the data capture process and are automatically filled in to the appropriate fields in the web application.

If the user’s log in details are cleared against MINAP’s users database, a legal disclaimer page will be shown in order to protect the sensitive data about to be used.

Data Capture

Data Capture itself can take several minutes to an hour depending on the patient’s information. The navigation buttons along the left side of the screen are of no concern for this project. The right side of the screen will display the patient’s demographic information as well as identifying the user that created the record in use across the top half.

Each pages’ bottom half will display the controls necessary to capture the patient’s information. Controls that may be used include (but are not limited to) text fields, buttons, radio buttons, dropdown lists, and calendar input boxes. Data validation can happen once exiting the particular field or page, or when saving the record. In addition each field contains a tool tip for the information that it captures as well as the corresponding field number in MINAP’s dataset.

Navigation-wise, each page has at least three buttons: “Save” places all data onto a permanent record (it will not, however, navigate or indicate in any way that the saving has taken place); “Close” will end the data capture without saving progress (a message box will inform the user of this), the user will then be directed to a listing of all patients entered into the system. The other three buttons: “Next”, “Back” and what MINAP refers to as the “Compass” need further looking into.

The “Compass” is, in essence, a navigation map. Pressing this button will bring the user to a flow-diagram-like display of the pages that are available for data capture. The user can then navigate directly to the page desired provided it is available. If the “Compass” is not used, the web app has a linear way of navigating through screens. “Next” and “Back” will fulfill the expected functions in this linear way. It should be noted that if the user accessed a page via the “Compass” page, pressing “Back” will not bring up the “Compass”, but the page that precedes the current display in the previously mentioned linear navigation.

It must be mentioned that throughout the data capture process, the decisions made across certain field or fields will trigger the appearance of one or more fields and even entire pages for further capture.

Conclusions

While the web app MINAP currently uses has served its purpose, it could stand to receive an update. There are areas that are no longer obscure to its users only because of their current use of the app. As a group, we had a tough time getting to know the finer details of the system and even our client had to, at times, consul with her coworkers in order to answer some of out questions.

In our solution, we must do away with as many of these gray areas and make our solution as intuitive as possible without losing major functionality.

Comments are now enabled on all posts!

To comment, just click on the title of the post you want to add your thoughts to. We’re using the DISQUS comment system, so you can login with any of the compatible services.

As part of our client meeting on the 12th, I also presented a series of storyboards of my vision for future MINAP data collection (based on our client’s own stories). I though I should probably share it on this blog. Our client didn’t have much to comment on it – so it must be pretty good (or unspeakably horrible).

Present:

• Julie goes on her usual rounds in the hospital
• She meets a patient
• She checks and records the patient’s data
• She leaves to see another patient
• The cycle continues until much later
• Julie then passes on her records to a dedicated ‘data aggregator’ who inputs the data into the MINAP web app (as seen in one of MINAP’s public reports)

Future:

• Edwards goes on his usual rounds in the hospital
• He meets a patient
• He checks and records the patient’s data
• He realises that the patient is eligible to be entered into the MINAP dataset
• He whips out his phone and creates a quick record of the patient’s details
• He then leaves and does his usual rounds
• When Edward has a bit more time to himself, he logs on to the MINAP web app
• Eligible patients have been created in the MINAP dataset as ‘stubs’ which he can now quickly fill in with the relevant information

This would be our ideal scenario upon completion of our app – however unrealistic that may be.

The two personas we’ve introduced are pretty tech savvy, currently owning smartphones for a considerable amount of time. Where are all the non-savvy users?

The MINAP dataset and interface is a very complicated system to the first-time user (as we have experienced first hand), and reducing this complexity to a mobile device whilst still retaining most (if not all) the functionality of the web app is (I think) a monumental task. Whilst we will keep in mind that not all users have used smartphones before, I believe the requirement of the user having had previous experience with mobile apps is necessary to avoid them being overwhelmed by the experience of entering data into the MINAP system on a mobile device.

Obviously, the easiest way to mitigate this problem is to include a tutorial (which was also suggested by our client). I personally believe that most users tend to skip tutorials anyway, and that the time is better spent trying to make the app as intuitive as possible for the more experienced users. We will however provide a tutorial for our app in the near future – if time permits.

Why we need Edward

As part of our effort to better know our end users, we ran a quick survey with our client to find out just how many MINAP users own a smartphone, and their willingness to use their personal devices for work. Our client deployed the survey via SurveyMonkey to MINAP’s current user-base, and encouraged them to forward the link around. The survey has been running for about a week now, and will be left open for several more weeks to allow more responses, but 79 responses have been collected so far.

As the questions in the survey primarily involved more technical questions (such as “what brand is your phone/tablet?”), a more in depth commentary will be included in the report associated with this development blog. However, we have included questions such as :

Do you currently use your smartphone/tablet for work-related activities during work hours? (Yes / No)

and

Would you use an app on your smartphone/tablet if it helped supplement your work? (Yes / No)

with a section at the end for freeform comments to allow further feedback.

So far, 72.4% of surveyed users responded No to using their personal devices for work-related activities, but 75.3% answered Yes to the possibility of using an app for supplementing their work. From these two responses alone, it looks like people are willing to use new technology – just not their own. The picture becomes clearer when having a look at the comments left by the users:

We are not allowed to use our phones on wards so not sure how this would work. Our trust is very unlikely to buy a tablet for use by MINAP […] If I had the equipment and an App available, I would be very happy to use it.

and

I would be more than willing to use a smartphone / table for work related activities if it was provided by work. Currently I use a personal iPhone only and would breach confidentiality / clinical governance issues if this was used for work related activities.

and

Any devices used in the workplace would have to be procured by our IM&T Dept.

show obvious concerns with regards to data protection and security, preventing the use of personal devices for work from both a personal and work perspective.

This is a key factor that has convinced us to ensure that our application will not be used in any real-life setting until a proper security audit has been performed. However, from a usability perspective, we need to ensure that users concerned about security are being reminded that the data entered into our mobile app is stored, transmitted, and securely deleted from the device when completing a record.

To help remind us of this issue, we have created Edward – a security conscious 30 year old clinician. Unlike Julie, who was born of feedback from the client, Edward reflects the more privacy-concerned users.

So who is Edward anyway?

• (extremely) tech savvy single 30 year old clinician
• owns a (personal) tablet and smartphone
• enjoys a good work-life balance
• frequent reader of The Guardian
• works in a hospital trust on a tight budget
• loves efficiency
• is professional with his patients, and respects their privacy
• constantly saves his work and is meticulous with organising files

Edward would love to streamline his workflow for entering patients into the MINAP dataset, but is well aware of data privacy laws governing patient data. As such, he begrudgingly enters patients into MINAP on Internet Explorer, but knows full well of the dangers of data leaks. He checks the application privileges on his tablet and smartphone before installing any new apps, and has helped some of his friends remove obnoxious apps from their own devices. He is distrusting of how secure mobile apps are, but can see their potential as time savers at work…

In order to get a better grasp on the usability and usage of the project. The team would like to introduce our persona, Julie.

Julie is a 28-year-old Nurse working in the General Hospital (MINAP Code: YYY). She is in charge of admitting and taking care of all types of patients at General Hospital.

Due to budget constraints, Julie cares for multiple patients at the same time gathering data for other organizations in addition to MINAP. Since entering a patient’s data for MINAP’s web application requires being physically in front of a computer as well as time to complete the record, Julie finds the whole process “unwieldy”.

Julie is tech-savvy in that she owns a smartphone, she has never used it for work, though. However, as she has some time with the patient while they are being admitted, Julie wonders if she could at least flag the patient for later input to MINAP’s database through her smartphone.

As she checks in a new patient, Julie wonders… “Is there an app for that?”

The team has come to realize that in order to continue the objectives this blog is to meet, it must come clean. Up to this point, information regarding our client and project has been, to a point, redacted. This is a practice that will hinder rather than help from this point on.

Our Client: Project Manager for MINAP

The Myocardial Ischaemia National Audit Project (MINAP) investigates the management of heart attacks. Participating hospitals and ambulance services are to provide a record of their management practices. These records are then compared to national and international clinical standards. The National Institute of Cardiovascular Outcomes Research (NICOR) is a partnership of clinicians, IT experts, analysts, academics and managers. Its mission is to “provide information to improve heart disease patients’ quality of care and outcomes”. Using different audits, MINAP being one of them, NICOR aims to provide the NHS, government and regulatory bodies real world data to be used in patient care. The team’s primary point of contact is the Project Manager for MINAP, who we have referred to as the ‘client’ in previous posts.

Our Project: A mobile solution

Participating facilities are requested to enter all patients with suspected heart attack. Data is collected by nurses and other clinical audit staff and entered in a dedicated web application. This web application collects all patient data, from demographics to diagnosis and release information. As it stands, the web application contains a 130 field dataset that is updated every two years (latest revision, June 2013). The data is then validated against a set of rules which include, but are not limited to, value range checks, date range checks, data type checks and encryption rules. Once completed, records are stored on MINAP’s Domino server. A further look into the web application will be posted in a later post.

The app dev team has been tasked to produce a mobile application that will serve as a starting point for the data capture process, thus relieving clinicians of some of the burden of data entry. This project will retain the major functionality of the web application while working with a slightly reduced dataset. Validation and storage must be taken into account, as well as maintaining a semblance of familiarity for the current user base. The target platform for this mobile solution is the Android OS for smartphones.

With the final deadline fast approaching (Jan 21st) and the holiday season nearing (and the introduction of the new HCI coursework requirements), David will be taking a break from writing up weekly posts on meeting minutes. All of the team will be pitching in to write up individual posts relating to their work being done.

All posts will be tagged with the name of the author, with the tags always being visible when viewing the ‘Archives’ section of this blog. You can always return to the main view by clicking (or tapping) on the title at the top of the page.