I can view a landing page when I select if I am a medical professional or individual patient

Acceptance criteria:

New landing page with two buttons for the user to select if they are a medical professional or individual patient

Research querying Jaime's API and put forward recommendations on how to carry out the required filtering

Research how Jamie's app was queried in the last Curenetics project.
Link to last Curenetics project code https://github.com/fac-15/Curenetics/blob/master/src/Components/Results/Results.js
[line 16 fetch request]
getTrials = () => {
const { postCode, age, gender } = this.props.userInfo;
const baseUrl = "https://curenetics-api.herokuapp.com/data/trials/uk/";
const distance = "100";
fetch(${baseUrl}${postCode || "B152TH"}/${distance}/${gender || "m"}/${age || "70"}/.json)
.then(res => res.json())
.then(result => {
this.setState({
results: result.results,
isLoading: false,
});

Process

Process Guide

Overview:

This issue is intended to document for our current processes within this project. Once everyone agrees on the document, contents should only be changed once discussed with and agreed by the whole team.

Values

Written in semantic HTML
Avoids divs (uses React Fragments or appropriate semantic tag)
Forms are appropriately labelled
Site is accessible by keyboard navigation (appropriate interactive elements are focussable)
Uses aria labels when text is not visible on the screen
Uses aria-labelledby attribute where necessary
Follows the agreed color themes to ensure appropriate color contrast

TDD

This is for any code on the back end:

Javascript functions will be written as pure functions so they are testable
Javascript should be written in TDD

Stand-ups

Standups will be held at 10:30 London time, 12:30 Palestine time.

In order to keep focus, our aim for standups will be 15min every day. They will focus on what you are currently working on, what you plan to do next and if you have any blockers. Discussions at stand up should revolve around things that concern the whole team.

Additional time for discussion can be arranged immediately following standup for questions or getting help from one another. This can be done in pairs or larger groups.

Daily Stand Up Log

At the end of each day, please go to issue #3 and fill in what you worked on that day, what you will work on the next day you're working on the project and any blockers you're facing. This is very important to make sure everyone is fully aware what is going on in the project.

Clean Kanban / Issue assignment!

Always aim to only assign yourself to one issue at a time. There is flexibility on this - sometimes with smaller issues that are all linked it will make sense to assign all of them to yourself. However, this should be absolutely never more than 5.

Workflow / PRs

Issues will be created by Scrum master and added to the kanban with a priority label
Team members can pick up any issue by assigning themselves it and by dragging it into the in progress column of the kanban
-- Issues must be picked up in order of priority. Do not work on priority 3s until priority 2s are all closed
When the ticket has been completed, the team member should check that it passes the Pre-PR Checklist:

Pre Pull Request Checklist

Branch is up to date with master
The project runs
You can download and install locally, and run the project locally
All existing and new features run without bugs
The build script runs without error
(If the project is already deployed to Heroku) the branch to be merged can deploy successfully to Heroku
Code is consistent
Linter is used, no error messages
Code is consistent with agreed team style
Naming of files is consistent with project (e.g. all files named with camelCase)
Tests are in place
Test file is in the relevant test folder
Tests all pass
All tests should pass locally and on Travis
Edge cases have been considered in tests
Test coverage is maintained
PR will not bring down coverage by more than 1%
Files and lines of code have been ignored if they cannot be tested
No console logs
-- Console.log is only used for crucial system messages (e.g. which port server is on).
Console.error is used in error handling.
global.console.log and global.console.error are mocked in tests when needed to avoid littering the console

Once this checklist is passed, the team member will open up a PR. This PR will NOT be added to the kanban, it should only live in the pull request tab of Github. The PR should reference the issue number(s) that it relates to.

The PR should be labelled with awaiting review when it is ready to be reviewed. The corresponding issues can then be moved to the review column on the kanban.

The reviewing team members can use the approved label if they are happy for the PR to be merged.

Merge conflicts tag should be used if the PR needs to be merged with working branch
After the team member has completed the changes, they can label the PR with awaiting review and wait for an approved review.

Except for days when only London or Palestine developers are working (e.g. Sunday), PRs made by London team should have one approved review from the Palestinian team and vice versa.

The PR should then be merged by the person who opened it.

After the PR has been merged, the branch should be deleted and the corresponding issues on the kanban should be closed.

Naming Branches

Branch naming follows feature/fix convention
E.g. feature/add-search-function or fix/change-searchbar-color

Commit Messages

Should include issue #
Written with 'imperative tone' to describe what a commit does, rather than what it did.
E.g. Change color of search bar instead of Changed/changes color of search bar

Installing modules

If installing a module, please flag this in the team Slack.
Whoever installs module should include it on the project readme, linking it the documentation and including a few sentences on what it does in the project

React-js extension

stick with convention of using js instead of jsx.
E.g. button.js instead of button.jsx

Styled Components
Project should use a global theme to hold global css variables such as font styles/sizes, colors and margins (should be made at the beginning of the project)
we should be as consistent as possible with our styled components naming convention. An approach that I suggest is to import * from the styling sheet - as is in this example.

import Header from ‘Components/Header’;
import * as S from ‘./styles';
const Navigation = () => (
  <S.Navigation>
    <Header>{headerContent}</Header>
    <S.Content>{content}</S.Content>
  </S.Navigation>
);

We can write the style file like this:
import styled from 'styled-components';

export const Label = styled.label`
   //STYLES HERE//
`;

export const Input = styled.input`
   //STYLES HERE//
`;

For more: https://medium.com/inturn-eng/naming-styled-components-d7097950a245

Constants Folder
For navigation routes, api routes and anything that will be reference multiple times across multiple different files, please create a relevant file within the Constants folder so these can be easily updated at a later date.

If I don’t want to upload PDFs, I can select to skip and enter the records manually

Acceptance criteria:

A ‘Enter records manually’ button at bottom of the landing page

Set up User Testing

Hi @sesola - do you think you'd potentially be able to set up user testing for Thurs/Fri next week?

All we need would be c. 3 medical professionals that you envisage using this app to whom we can show the design prototype and test some user flows. We can carry this out with them remotely and each session would be no more than 30 minutes.

Send link to API repo and codebase

Hi @jbrough - can you please send us the link to the repo so we can look at the code and potentially move over to a repo we own as discussed. Thanks!

I can see a files page where I can select a button to upload one or more PDFs of my patient(s)’s medical records

Acceptance criteria:

Short description explaining what to do
Button to upload a PDF file(s)
How multiple files are uploaded needs to be worked out during a technical spike during the dev process
Validation to ensure it’s a PDF file being uploaded and not anything else

Wireframe:

Agreed data structure example - Jon's API

Hi @sesola - @'ing you on this until we get a github handle for Jon.

We need an example of what the dataset and structure will look like of the JSON data that is returned to us from your software, in order that we know how to query and use it within our part of the app.

Could Sola and Jon liaise on this please? Once we have a structure template and example dataset to work with then we will be able to work on the development, giving you time to get the software working

Build prototype in Figma

This will be desktop first with a single breakpoint to accommodate mobiles

Desktop wireframes
Mobile wireframes

Sign NDA

relates to #10

Need the whole team to sign and return to me via email so I can give back to Sola. Have sent the NDA to everyone.

I am able to edit any of the fields in my list of patients to correct data

Acceptance criteria:

Each field outlined issue in #23 will be directly editable so the user can manually change the value

Wireframe:

Set up general theme file

Add all colors and CSS variables in a theme.js file
Set up universal css reset file

Create Common Components

At the start of the project it's good to identify some common components (e.g. navbar, button ) that we feel we will need so this can be made at an early stage

When I’ve uploaded my PDFs I am able to hit submit for these documents to be analysed

Acceptance criteria:

Submit button once they’ve uploaded their PDF files
Set up API / post request to send the relevant data to @cloudstartuptech 's software so the PDFs can be analysed
Encrypt the files before they are sent

Deploy on Netlify

Create an account for Sola and add to the App info spreadsheet in Resources issue #9
Add relevant initial env variables and store in App info spreadsheet in Resources issue #9
Set up continue deployment on Netlify

If the clinical trial has only partially matched it is shown with an orange border

Acceptance criteria:

If it is outside the required criteria, but within the threshold (to be provided by product owner), then show an orange dot next to the criteria
The colours could show as words so they could be seen if the pdf was printed on a b/w printer.

@sesola - we need you to provide the thresholds please for the eligibility criteria. Can you please add as a comment to this issue. Thanks!

Wireframe:

I am able to submit my patients details to find clinical trials

Acceptance criteria:

‘Find Clinical Trials’ button at the bottom of the list of sections
Query Jamie’s API (@jbrough) to find trials in the UK within the last year that match the values submitted
We may filter to only return trials that are currently recruiting or will recruit soon, to keep the file size and number down

Having submitted my patients’ details I am able to see a list of my patients each with top level details

Acceptance criteria:
List of sections (one per patient/medical record submitted) each with top level details, including:
Patient ID
Number of matching clinical trials that are recruiting or will recruit soon
View more button

Wireframe:

If entering manually, I am able to add a series of details for each patient

Acceptance criteria:

Wireframe:

Provide Copy

Hi @sesola - do you mind providing the copy we need to use on the website please? The most important thing for example is what term we use to refer to the records (as from user testing it seemed 'medical records' is confusing) and the clear warnings we provide before the user goes ahead and sends PDF files.

The simplest way to do this is if you could go to the wireframes here (on the desk version): https://www.figma.com/file/BaIHfKxJN8zhXlVoTxlTJu7B/CURENETICS2?node-id=47%3A1181

And then add the required copy you actually want as comments. To do this you press the comment icon on the top header and then select wherever you want to add a comment. If you don't have a comment there we will assume you're happy with the copy.

Let me know if any issues!

Agree how to send medical records to Jon's software

Hi @sesola - @'ing you until we get Jon's github handle.

We need to understand how we should send medical records to Jon's software in order that it can be processed and turned into structured data this returned to us.

This could be for example, that we iterate through the documents, sending one and a time and getting a JSON data object back for each one, or it might be we send all the PDFs at once and get one nested JSON dataset back for all of them.

If you could let us know please here, we can then begin planning this aspect of the app.

When uploading PDFs I can delete them if I choose to no longer upload them

Delete icon next to each PDF I add to the add your files section
Selecting the delete icon removes the PDF from the list

Wireframe:

Once my files are analysed I am able to see a list of my patients each with structured data pulled from their documents

Acceptance criteria:

This will be working potentially with multiple data objects from the JSON object @cloudstartuptech returns to us from the files being analysed, so it will need to iterate through these.

Wireframe:

Send over NDAs to sign

@sesola to send over the NDA for everyone in team to sign so we can view the example medical records

While it is searching for clinical trials I can see a loading screen so I am aware analysis is in progress

Relates to #22 as this could potentially be a common component

Acceptance criteria:

Loading icon (potentially showing % progress but this is bonus)

Wireframe:

Agreed data structure example - Jamie's API

Hi @jbrough - can you please provide us with an example of what the dataset and structure within your api looks like, in order that we can work out how best to query it

Agree File Structure

I believe this will follow standard React file structure conventions, but issue here to agree it amongst the team.

Initial suggestion:

the suggested file structure

├── README.md
├── client
|  ├── package.json
|  ├── public
|  └── src
|     ├── assets
|     ├── components
|     |  ├── Common
|     |  ├── Pages
|     |  ├── App.js
|     |  └── App.test.js
|     ├── constants
|     ├── helpers.js
|     ├── index.js
|     └── styles
|     |   |______ globalStyle.js
|     |   |______ reset.css

Technically we don't need to have a 'client' folder but I've left this as this enables us to also build out a back end if ever we need to. Open to changing it though

RESOURCES

JSON Data
Example file of the JSON data returned from @jbrough 's api:
Jamie API JSON example.pdf

App info
All important app information here (e.g. env variables): https://docs.google.com/spreadsheets/d/15jb8qsbmAh69GJlfG_f2S8YYJriCwEZHILiZdFBlqps/edit?usp=sharing

Brand Guidelines
https://github.com/yalla-coop/curenetics/files/3620208/Curenetics.BrandBook.pdf

Further branding advice can be found here:
https://github.com/yalla-coop/curenetics/files/3620209/Investment.Deck.Curenetics.pdf

Wireframes / Design
Here are the agreed wireframes:
https://www.figma.com/file/BaIHfKxJN8zhXlVoTxlTJu7B/CURENETICS2?node-id=47%3A1181

Reference to user testing feedback
Here's the issue that summarises the user feedback: #48

While my PDFs are being analysed I can see a loading screen so I am aware analysis is in progress

Acceptance criteria:

Loading icon (potentially showing % progress but this is bonus)

@cloudstartuptech - how we can keep track on how the documents are doing? This goes back to our point as well around how we can get the JSON data returned to us as ideally this will be automatic as a response to us sending a post request with the files

Wireframe:

User Testing Feedback

Please share the HackMD and add below a list of:

any user stories we need to add or modify
changes we recommend making to the designs

When viewing all patients I am able to click an export button to export all matching trials for each of the patients in one PDF

Relates to #29

Acceptance criteria:

Export all data as PDF button at top of the list which will trigger a download of a PDF containing all information about the patients and matching clinical trials, including:
- Patient ID
- Number of matching clinical trials that are recruiting
- Then a list of the clinical trials with more details as outlined in #29

Set up project codebase

Set up initial codebase
Install initial agreed packages
Sort out git ignore file
Set up eslint configuration so it works across everyone's editors and let everyone know what set up they need

Design inconsistencies and ambiguities

From doing the initial ui setup, I think there are a few inconsistencies we best clear up, and the user flow seems to be a bit hard to follow, I will do my best to summarise below:

Figma design here

Back buttons and breadcrumbs

We have a combinations of arrows, chevrons, uppercase and lowercase text, and purple and grey colours that have no real correlation between small and large screen sizes, or location within the app. Best to pick to one style, and stay to it.

icon button styles

would be nicer to get these two aligned (same font size and colour)

Adding options to a menu

So far, we have 'about' in the menu in the top right (on desktop). Should we also include 'upload' and 'manual entry' here to make all options more apparent?

pdf upload and manual entry combination

Is this something we can support? It could be a bit of a frustrating user experience to lose all results if wanting to combine both manual entry and pdf upload

matches index (screen 13)

What does this mean? Are trials sorted by best match? If so, should we let the user know this
What type of sort do the sorting arrows perform? Could you select the option you want to sort by from a dropdown instead?

clinical trials details (screen 14)

Why do we have an input field to tell us the name of the file we are getting trials back for? Should this not be a heading or plain text? Also, what if we manually entered the data, would we say 'entry 10' instead?
In order to not take up a huge amount of room on the page, we should have expandable cards that are collapsed by default, and expand to the size shown when clicked
green colour used by the table on white probably isn't going to be very accessible. It could also be confused / confounded with 'potentially eligible' and 'nearly eligible' instead. Perhaps giving the whole result card a top border with the eligibility colour and status text would be a better solution.
In each card, do we not want to export the single trial with the button, rather than 'all trials'?

**losing data after submission **

I understand we aren't storing data on the app for confidentially / safeguarding concerns, also the extra bell and whistle of adding login functionality, BUT are the below alerts not somewhat contradictory?

- I would suggest re-wording of the first modal to say "Data you have entered or uploaded will be wiped when you click the 'match clinical trials' button", and "results will be wiped when you close the app" - In addition, results and uploads / entries will also be wiped if a user uses the forward / back buttons in the browser _unless_ we a) find a way to autosave their data as they enter it, and b) save references to their results where they are stored on the API. I would suggest doing this, as having information for say 100 trials saved in localStorage will likely put a greater performance load on the user's browser.

Research Cypress for testing and demo

Whoever takes on this issue needs to:

do research into Cypress
build out a dummy test which they can use as a demo for the rest of the team

When viewing the list of clinical trials for each patient I am able to click an export button to export all clinical trials as a PDF or each clinical trial individually

Acceptance criteria:

When viewing an individual patient, an export button at the top which will trigger a PDF download of all the matched clinical trials
When viewing an individual clinical record I can export purely that record

This will do the same download function as the export button in #28

If entering manually, when I hit submit I am shown a list of clinical trials

Acceptance criteria:

This would trigger the top overview list (relates to #29 )where it shows number of matching clinical trials

This relates to #36

Jamie's API column headings information wanted

Jamie

In addition to the column headings we had in the last JSON file could we please also have 5 more:

Cancer (all types), male and female.
From any recruiting trial in the UK.

Title (Study Title as listed on https://clinicaltrials.gov) note: we had no title last time, and just inserted the 1st keyword as a title which didn't really work.
Acronyms
Drugs (Intervention as listed on UK trials.gov)
Sponsor (Sponsor as listed on https://clinicaltrials.gov)
Number Enrolled on the trial (listed as Number Enrolled on https://clinicaltrials.gov)

[The trial number: this was on the JSON but we didn't use it last time. We will used it this time.]

Keywords to match trials on

Hi @sesola and @jbrough this is related to #2 but I thought it important enough to have as a separate issue for us to have a clear place to discuss.

If we can't use Jamie's API to filter on eligibility criteria as such (beyond age, cancer type etc), then it might be possible to do some filtering based on keywords?

However, for this to be possible we would need to be 100% clear on:

what keywords are listed for clinical trials
what matching keywords might also be found in medical records
what keywords would clearly indicate some form of eligibility if we find it in both the clinical trials and the medical records

For example, what we don't want is a clinical trial having a certain keyword that is actually only there because it means people wouldn't be eligible if they have that in their medical records, so we need to be clear what and why keywords are listed for clinical trials and whether these are always positive things we can match against.

This may require the two of you discussing this week? And then we can add the thoughts as comments below.

User Journeys

The core user journey for this project:

As a doctor/medical professional, I can upload PDF documents that cover the medical details of my patients for this data to be tidied and then matched against any relevant clinical trials

Bonus user journeys depending on time

As a doctor/ medical professional, I can manually enter medical details for my patients to find relevant clinical trials

As an individual, I can manually enter my medical records to find relevant clinical trials

Set up Figma environment and invite everyone

Create project environment
Invite everyone to collaborate

I can still view the website with colour/visual impairment

Acceptance criteria:

Ensure the website follows semantic html
Ensure there is sufficient color contrast

Agree on tech stack and eslint

The current plan so far:

Front-end: React, HTML, CSS
Back-end: Is it needed since we'll be connecting to external APIs?
Testing: Supertest
Eslint: Usually airbnb config

Main things to still agree:

Styled components?
Testing language (Jest?)
Are we setting it up with Create React App?

I can view and use the app across phone and desktop

The design will be desktop first, with a single breakpoint to make look suitable for phones/tablets

Acceptance criteria:

Functional on browsers outlined in #32
Functional on default browser on mobile devices
1 break point between desktop and phone, to provide some responsiveness to the web app

Confirm what medical entities we can query in Jamie's API to filter clinical trials

From Jon's document analysis we will get a structured data set to then use to query your API @jbrough

However, we need to work out what data points we can query in order to filter the clinical trials relevant for that client

At the moment we understand the options to be:

Age
Gender
Cancer Type

In addition we will be able to get hold of the postcode (but we won't use this to filter beyond ensuring the trial is in the UK)

Can you please let us know what else we can query from your API. It is essential to get:

A list of potential inclusion / exclusion criteria
Where and how we access this in the API

If there are no other entities we can directly query, then are there potential keywords we get hold of? And if so, @sesola , could you please liaise with @jbrough to let us know which keywords we should look for that might come from the medical records enabling us to match.

Set up travis and codecov

Set up travis configuration
Put in files we want to ignore for testing
Remove patch coverage in codecov

Confirm medical entities to pull out of the medical records

Hi @sesola can you please list here which medical entities you need Jon's software to pull out of the medical records please?

At the moment we know we'll need:

patient ID
age
gender
type of cancer
postcode of the hospital or their address?

Clicking view more, I am able to see the list of clinical trials with the core information for each trial

Acceptance criteria:

Wireframe:

Curenetics.BrandBook.pdf

Would you like us to use the logo, fonts and colours in the Curenetics Branding Book?

Or can we use the logo we developed in the earlier Curenetics project (blue dots connected in the shape of a C which had a science feel).
We also used blue colour for tabs and backgrounds (we are thinking of adding another colour to this). Plus we used the sans serif Google font Lato.

I am able to use the platform across the latest versions of Chrome, Firefox, Safari, Edge and Internet Explorer on Windows, Linux and Mac

Internet Explorer as a particular one we will need to check. Lots of medical professionals unfortunately need to use old systems and are often made to use Internet Explorer so we need it to work across all these browsers.

If I am an individual patient I can manually enter my details (NOT upload PDFs)

Acceptance criteria:

NOTE: THIS WOULD NOT INCLUDE UPLOADING PDF

yalla-coop / curenetics Goto Github PK

curenetics's People

Contributors

Stargazers

Watchers

curenetics's Issues

Process Guide

Overview:

Values

TDD

Stand-ups

Daily Stand Up Log

Clean Kanban / Issue assignment!

Workflow / PRs

Pre Pull Request Checklist

Naming Branches

Commit Messages

Installing modules

React-js extension

Recommend Projects

Recommend Topics

Recommend Org