Hosting

Problem: One week prior to the COMP2014 final presentation our Azure access was revoked by Microsoft due to a plan expiration.

Solution: We rapidly responded to this urgent issue, which took the entire Pathways product offline, by exploring both alternative platforms and pursuing avenues to regain access to Azure. Upon critical reflection of the options available we elected to change our hosting provider to Heroku for the demonstration only. This decision was made as we needed absolute confidence in our application host for the demonstration and presentation sessions, something we could no longer risk with the Azure platform.

Authentication

Problem: We needed to ensure that only doctors could access doctor functionality, and only patients could access patients. It was critical that no one could login as anyone else.

Solution: We employed the devise gem to manage user accounts and security. Devise protects every page, and restricts access to pages dependent on access levels we set. Devise also protects Pathways from timing attacks and numerous other common weaknesses in authentication systems.

Access Controls

Problem: We needed to ensure only the correct medical professionals were able to modify a patient.

Solution: We built team access controls, an additional feature not specified in the requirements. Team access controls add significant amounts of value and extensibility to the product.

Scalability

Problem: Whilst not in the formal requirements, we wanted to ensure Pathways worked well not only for the gastrointestinal oncology team, but for an entire hospital or NHS trust should the application be rolled out widely.

Solution: To ensure the product was fully scalable we took a number of measures. Firstly, we hosted the application on Microsoft Azure, which allows for cheap and easy scaling, thanks to its pay-what-you-use pricing structure. We also used extensive database indexing to ensure that even as the numbers of patients, doctors and treatment modules grows to be very large the database is still extremely responsive. To handle the large numbers of patients and doctors we implemented the team access controls detailed above to isolate teams of patients and doctors from those who are not relevant to them. Superusers are of course able to adjust these teams at any time.

Test Information

Problem: We needed large amounts of fake data in order to test the functionality of the application.

Solution: We employed the Faker gem to generate very large quantities of fake data to populate the application with. This gem was extremely powerful as it allowed us to specify the data to generate very precisely, and it saved significant amounts of developer time.

Data Storage

Problem: Pathways needed to store very large amounts of treatment and user data, and in order to scale effectively query response times must always remain low. We needed to run extremely complex queries against this database to retrieve treatment modules from categories along a timeline of potentially hundreds of states instantaneously. We needed to manage team access and therefore large numbers of patients and doctors, who had relationships with one another.

Solution: We employed Postgres to satisfy database requirements. Postgres is a very high performance database application that will allow for easy scaling to larger numbers of patients, doctors and trusts.

We considered the use of MySQL, however Postgres has two distinct advantages. Postgres offers higher performance, allowing for better scaling, and for the storage of JSON snippets, required for the Pathways API.

The database in Pathways has been fully indexed to allow query response times to remain low, even as the information set available becomes large. This is a critical feature, as it allows Pathways to scale with relative ease across Guy’s and St. Thomas’, as well as across multiple NHS trusts.

We engineered complex SQL queries to retrieve information from this database. The most technically challenging of these queries was engineered to retrieve all modules currently assigned to a patient along the patient pathway. This query can be seen below.

Automated Testing

We used rspec and Capybara for complete automated testing of the Pathways project. Rspec allowed us to check functionality was working as expected, and that relationships between objects, such as different levels of user accounts and treatment modules and states, were functioning correctly.

Some of our rspec test cases are below:

The result of running these tests can be seen below:

Behavior Driven Testing

We used the cucumber gem to provide powerful user driven test cases. These tests allows us to simulate real user journeys and to verify the application was behaving as expected. This was a valuable addition to our suite of automated tests and provided additional confidence the product was not malfunctioning following automated deployments.

User Acceptance Testing

User acceptance testing was employed upon completing the first release of the application. Credentials for access were handed to the clinical team, who tested the application and raised any issues, bugs or feature requests via the client-facing ticket tracker.

We reflect these client-raised tickets in our internal bug tracker, where they are managed through to completion. This is industry standard practice and allows us to ensure no work is missed. Full details of the ticket tracking solution can be accessed in the collaboration tools section.

Completion of user acceptance testing allowed us to ensure client satisfaction with the end product. This was only possible due to the aggressive development schedule employed by the development team, as we had a month from completing the application until the end of module hand over, during which we were able to bug fix and improve the application to exactly match varying client requirements.

We have created an API that allows any other application developer full access to the backend of the Pathways project. Full details of the API should be accessed through the community tab of this website.

Before we began building Pathways we extensively analyzed the requirements and proposed user journeys, before fully designing the database and system. We were able to use these designs throughout the project, using model-driven development, and this is apparent from the similarity between the designs and the final diagrams. These first diagrams and usecases can be seen below.

Upon completion of the Pathways project we generated several technical diagrams. These document the database design and give an overview of the controllers that make up Pathways. These diagrams can be seen below.

Brief diagrams:

Full size brief models diagram Full size brief controllers diagram

Complete diagrams:

Full size complete models diagram Full size complete controllers diagram

We provided access to Pathways to the clinical team on March 30th. After this date all feature requests, bug fixes and suggested improvements from the client were managed via the client-facing ticket tracking software, Axosoft. When a ticket was raised during this platform a paired ticket would be opened using the internal ticket-tracking software, Github. We would manage or resolve these issues as appropriate, logging status in the ticket software. This is industry standard practice and ensures no features or bugs are missed. This process is covered in the User Acceptance Testing section above.

Pathways uses the Model-View-Controller pattern through due to the Ruby on Rails development framework. The model view controller design pattern is very powerful, and is an industry standard method of implementing user interfaces. Users interact with a controller, which impacts a model, updating a view which is then fed back to the user as one continuous process.