Requirement

Project Background

Platform for Enhanced Analytics and Computational Healthcare (PEACH), Project PEACH is a large scale open source community driven Data Science project by the Computer Science Department at University College London. The goal of Project PEACH is to provide a data science tool for medical professionals and researchers that can aid them in diagnostic and analytics processes through the use of big data, machine learning and data visualisation.

PEACH is a Recommender System using Hadoop technologies. As an open source architecture and supporter of open data, PEACH is intended to support a wide variety of contributor data sets. Pollution data, IoT data and government public policy open data are just a few examples of inclusion. Template 1 of Project PEACH is focusing on allergies, sensitivities and intolerance's. The diagnosis of allergies can be problematic. Elimination diets and food diaries are onerous for patients to maintain and can still lead to undiagnosed allergies. According to the European Academy of Allergy and Clinical Immunology, over 150 million people have allergies in Europe, the most common chronic disease ("A European Declaration on Allergen Immunotherapy." (2011). The European Academy of Allergy and Clinical Immunology (EAACI)). Template 1 will aim to predict a patient’s sensitivity level across varying levels of exposure to external factors such as food, pollen and pollution. PEACH intends to collect numerous data sets on an individual user basis through the use of mobile applications, wearable technologies and IoT devices. Some examples of these data sets are food diaries, retail shopping data, atmospheric factors, internal body conditions and social media activity. PEACH’s machine-learning engine uses collaborative filtering to predict a user’s sensitivity level to external factors. Medical professionals using template 1 can use this visualized data to target the diagnostic process and potentially find the more uncommon allergies, sensitivities and intolerances affecting a patient.

Over time in further templates the data in PEACH can be analyzed for demographic trends to determine populations that have higher sensitivities to certain external factors. As a next iteration, Template 2 will include all of the Open Cancer datasets and have a focus on operative care. PEACH serves as an open source analytics and collaborative studies data science engine, and seeks contributors from researchers, health charities, medical schools and computer scientists. It will shortly be joining the OpenEHR specification to enable other organisations to contribute data and analyse from it with support of the NHS Open Source. It supports multiple forks for its hadoop based back end (including Azure HDInsight and Amazon Web Services) and intends to make use of user-centred data from both traditional medical data sources and sources of the technological revolution. PEACH is to remain open source under the UK NHS Open Source and collaborators are welcome from all medical fields.

Our Client

Dr.Navin Ramachandran

Our client is from UCLH, Dr Navin Ramachandran. Consultant Radiologist at UCLH, with subspecialist interests in Uroradiology, Interventional Oncology (including Renal Tumour Ablation), Acute and Interventional Radiology. College Tutor for Radiology, UCLH. Undergraduate education lead for Radiology. Head of Centre for Imaging & Clinical Anatomy at UCL.

---

Problem Statement

UCLH Peach - tool project is about making a form generator that generate form out of a template. The tool should be based on openEHR which is a few regulations of how records has to be stored on this platform. OpenEHR is a virtual community working on means of turning health data from the physical form into electronic form and ensuring universal interoperability among all forms of electronic data.

The form generated is going to help standardise the input of the patients across the world gathering records under certain regulation so that they can build an common understanding of the records.

What the project is going to do is to first take archtypes from the database and combine all those archtypes to form a template. The template will be the input of the form generator and then the form will be generated based on it. During the process of generation, users will also be able to customise the form, moving elements.

Requirement Gathering

Since the very first meetings our team agreed that needs of an end user has to be a central consideration in order to produce a successful solution. Therefore, a precise understanding of what will be included in the system and how it will be used had to be obtained on the early project stages. This was achieved through constant consultation with our client and careful refinement with every iteration of requirements we produced.

We received a comprehensive set of information about needs of our client and put them into context using our technical knowledge. The fact, that we collected requirements in multiple forms will provide our team with comprehensive guidance on different stages of system lifecycle. Furthermore, it will ensure that a system that matches user needs in a precise manner is produced.

Personas

The personas helped us to identify who are the core stakeholders of our system and how we can better serve their needs.

Storyboards

We created the simple storybord to clearly demonstrate to our client how the application can be used.

Requiremente Overview

Since the very first meetings our team agreed that needs of an end user has to be a central consideration in order to produce a successful solution. Therefore, a precise understanding of what will be included in the system and how it will be used had to be obtained on the early project stages. This was achieved through constant consultation with our client and careful refinement with every iteration of requirements we produced.

Initial Requirements

MosCoW

Must

• Complete all the steps described on flowchart diagram
• Have unambiguous and friendly for non-technical users UI
• Be able to use output of the form generator in render forms
• Provide software documentation in the form of user manual and use case videos
• Produce readable and well commented code that can be used for further development

Should:

• Be able to view a list of OPTs that have already been loaded into the system
• Use UI components common with other UCLH Peach applications
• Have a complete form renderer integrated into layout customisation section

Could:

• Provide form preview before the layout is confirmed
• Be a part of container application

Wont:

• Restrict user to a certain form layout
• Duplicate backend for an already imported template

Use Cases