Agreed data structure example - Jon's API

[thejoefriel]

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

[thejoefriel]

Now adding @cloudstartuptech to this issue

[thejoefriel]

Hi @cloudstartuptech - we are due to work on this at the start of next week. Do you think you'll be able to send us the example JSON data structure by the end of this week please? Let me know if you think there will be issues with this.

[thejoefriel]

Hi @cloudstartuptech - on this, @sesola has a couple of other key entities he needs to be pulled out of the medical records:

1. ECOG status (@sesola would this always be written as a number?)

2. Gleason (@sesola would this always be written as a number?)

3. Disease within prostate--> focal disease Disease outside prostate--> advanced disease or metastatic disease

@sesola on all these can you provide a clear list of how they might be written in records so Jon knows how to find them please? Ideally just like age we will want a key-value pair in the JSON data that is returned to us (e.g. ECOG status: 2)

Thanks!

Joe

[martinbagshaw]

Example of the json object from the previous iteration of the project - kindly supplied by @susanX .

I believe this constitutes a result (list of records) returned from querying the API.

As you can see from the results, each trial has multiple locations, many of which are missing basic details, such as trial organiser / contact, phone number, email, etc.

To summarise, the fields included in the above are:

• Conditions
• Gender
• Phase
• IDInfo (not sure what this is - please advise @sesola ?)
• Keywords (likely to require some specialist knowledge in order to use as part of a search)
• Locations
• MESHTerms (not sure what this is - please advise @sesola ?)
• MaxAge
• MinAge
• OverallStatus - e.g. whether the trial is recruiting, running, or completed. Could be useful to filter based on this, and exclude completed trials by default, for example.
• XMLName (not sure what this is - please advise @sesola ?)

@sesola what other data, if any, do we require to build out this service? Please feel free to reign in anyone else on this discussion.

The sooner we can work out the breadth and structure of the data, the sooner we can work out how to filter it for the user.

[thejoefriel]

@mr-bagglesworth - this is Jon's API (analysing the medical records) not Jamie's, so I'm hiding your comment above to avoid confusion

[thejoefriel]

For reference, this is what we've sent as our expectation of how the JSON data will be returned to us which has been agreed by Jon.

This would be per medical record submitted:

{
    age: 
    gender:
    fileReference: (this will be either the filename or something else so we can link the data object with the relevant file that will be stored locally for the session) 
    postcode:
    cancerType:
    ECOGStatus:
    gleasonScore: (if there’s more than one score, either we need you to return the highest one or return all the scores in an array so we can then pull out the highest one ourselves)
         Keywords: [“disease within prostate”, “focal disease”, “disease outside prostate”, “metastatic disease”, “advanced disease”] (so if any of these terms are found in the pdf record they are added to this array of keywords) 
}