presidential-innovation-fellows / clinical-trials-search Goto Github PK

Currently, if a client hits the /clinical-trial/<id> endpoint and no trial matching the specification is found, the only thing returned is an empty set ({ }). This should probably be fleshed out a bit, although given that this endpoint normally returns a simple protocol object, it's hard to know what else you'd return.

Perhaps it would make more sense to keep the response an empty set, but also set the HTTP status code to 404 to indicate that truly, no resource was found with that identifier.

The API was designed such that multiple filters against a single field are union operations (OR), and filters against multiple fields are intersections (AND). These operations make work correctly when it is against the fields of trials. For example, finding all lung cancer trials in New York city.

However, this raises issues with certain types of nested objects, specifically the trial sites. For example, when looking for trial sites that are in Springfield, Illinois the API will match any trial that has a study site with city = Springfield and also having a site with state = Illinois, but nothing constrains the match to those study sites that have BOTH city = Springfield AND state = illinois.

A real world example, trial NCT02496585, has two trial sites, one in New York, NY and one in Basking Ridge, NJ. I can submit a query that looks for any trial with State = NJ and City = New+york and this trial will match.

See the link below for an example:
https://clinicaltrialsapi.cancer.gov/clinical-trials?nct_id=NCT02496585&sites.org.state_or_province=nj&sites.org.city=New+york

When performing filters against multiple fields within a nested object, the API should use the nested filter functionality of ElasticSearch.

We've found a few examples where our CCR protocols' ID numbers aren't in the ccr_id field of the API responses; I presume that this is a problem with the underlying data, but somehow we'd like to figure out how to solve this.

Examples:

• https://clinicaltrialsapi.cancer.gov/clinical-trial/NCT01434602
• https://clinicaltrialsapi.cancer.gov/clinical-trial/NCT01295944

Without a dependable field in which to find our CCR identifier, it's harder to search for our protocols via the API. It looks like all (or nearly all?) the time, our identifier will show up in protocol_id... but we're not sure if that's true 100% of the time. And then most-but-not-all of the time, the ccr_id field is also populated with it.