yalla-coop / curenetics Goto Github PK
View Code? Open in Web Editor NEWA platform enabling medical professionals to more quickly find relevant clinical trials for their patients
A platform enabling medical professionals to more quickly find relevant clinical trials for their patients
Acceptance criteria:
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,
});
Relates to #29
Acceptance criteria:
Acceptance criteria:
Acceptance criteria:
NOTE: THIS WOULD NOT INCLUDE UPLOADING PDF
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
Acceptance criteria:
This will do the same download function as the export button in #28
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 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
Acceptance criteria:
@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
Whoever takes on this issue needs to:
@sesola to send over the NDA for everyone in team to sign so we can view the example medical records
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:
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.
This will be desktop first with a single breakpoint to accommodate mobiles
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
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!
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:
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.
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:
Back buttons and breadcrumbs
icon button styles
Adding options to a menu
pdf upload and manual entry combination
matches index (screen 13)
clinical trials details (screen 14)
**losing data after submission **
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
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.
This is for any code on the back end:
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.
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.
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.
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.
Branch naming follows feature/fix convention
E.g. feature/add-search-function or fix/change-searchbar-color
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
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
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.
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:
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
Acceptance criteria:
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.
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.
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.
[The trial number: this was on the JSON but we didn't use it last time. We will used it this time.]
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!
Acceptance criteria:
The design will be desktop first, with a single breakpoint to make look suitable for phones/tablets
Acceptance criteria:
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!
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:
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:
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.
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.
Acceptance criteria:
Acceptance criteria:
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.
Acceptance criteria:
Acceptance criteria:
Go back to results button that will take the user back to the previous page
A top section that provides overview:
A section for each clinical trial
BONUS: The trials will be sorted in order of distance from the patient (if a postcode was submitted)
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
Please share the HackMD and add below a list of:
Relates to #22 as this could potentially be a common component
Acceptance criteria:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.