Open AlistairNWard opened 3 years ago
I can get the "clinical summary" from the endpoint https://mosaic.frameshift.io/api/v1/projects/:project_id/attributes
. I tried on project #521.
If the summary is not added in mosaic, we can show buttons to add a summary from clin. I found the endpoint to post-project attributes:
https://mosaic.chpc.utah.edu/api/#api-Project_Attributes-CreateProjectAttribute
I added a clinical summary for the platinum project from clin.
Looks good. We'll have to decide on whether we accept the attribute "Clinical Summary", or just "Clinical summary"? Of if there are one or a number of attributes close to clinical summary, give the user the option of which attribute to use?
If I remember correctly, the response returned an array for the "Clinical Summary" attribute (I will check this to confirm). So if there are multiple values we can loop and display all those values.
For reference: Linked branch - https://github.com/iobio/clin.iobio/tree/adit_369_clinical_summary
I imported a public attribute "Clinical summary" to the project and added the summary. We will use this in the report's page, and in clin, the user can edit this. If there is another attribute for summary (eg. Clinical Summary) which the user has added by creating a new project attribute, we can show that in the report as well.
Unless we are able to standardise the attributes that are attached to projects, we can't guarantee what this summary will be called. We should look at whether we can use the API to query what project level attributes exist for the project and provide the user the option to pick the attribute that they want to use. If "Clinical summary" exists, we can default to that
This will allow to set the clinical summary on the "review-case" page. If there are multiple attributes for the clinical summary it will show a button that will open a dialog and you can select the one that is most appropriate. By default, it selects the first value.
If there is just one attribute, it will use that value to set the clinical summary and the button will not be shown. If there is no attribute named clinical summary, then the project description will be used. And if the project description is blank it will show a default value which is currently "A summary of the trio goes here....".
I tried with the different cases for the clinical summary attributes:
Test: dev.clin
Yes, this makes sense. We default to using the clinical summary attribute, but make sure that there aren't other similar attributes. If there is more than one attribute "close" to clinical summary, we give the user the choice. The choice should be drawn from all available project attributes - not just those that look like clinical summary.
We need to think about how this will work on all pages. I'll give it some thought and add some ideas. But for starters:
Review Case We need to be able to edit the summary, or choose an attribute from Mosaic, so maybe something like this:
We could think about this a bit more. If you select an attribute from Mosaic, maybe it should populate the editable field? Then you can pick an attribute from Mosaic, see what the value is, and edit it if you choose. I'll give some more thought to how this would look.
I added a card for HPO terms, but that's not for now, just a thought. It would be nice down the line to pull both these in from Mosaic.
Phenotypes We want to allow the user to type or paste what they want, or select the clinical summary (or HPO terms). So maybe we need a button here to populate with clinical summary? Obviously need to think about diverging this from standard genepanel functionality and not overcomplicate.
Report Can the summary also be edited here? I'll think about it
Review Case - Yes, I am updating this so that it allows selecting the summary from all available project attributes and not only from a variant of the Clinical summary.
Phenotypes- If we allow the user to select HPO terms from attributes on the "review case" page, we can pass this information to the "Select phenotype" input box.
Report - We need to think if we want to allow making any changes on the "report" page or it just displays the final report. We can also think of having a "draft" mode or "published" mode. If you have published it becomes uneditable unless you change It back to draft status.
Yeah, this is a fair point regarding the report. It probably makes sense for it to be read-only. Maybe a tooltip to explain that it can be edited on the Review Case page would be enough
When we were discussing yesterday, we were thinking of showing the project attribute name as options for the radio button. Instead, we can directly show the value of these attributes and the user can select from these options. We can eliminate one extra step that we were thinking of.
My concern would be that some of the attributes could be quite long, which might make it hard to read them all. Also, there could be different summaries that look somewhat similar (e.g. clinical summary and patient summary), so it might be easier in that instance to be picking based on the name.
I was thinking something like this, although it would be good to find some examples that do something similar to improve the styling.
So the value of the selected attribute is shown. We'd want to make the connection between the selected button and the value clearer, so would be worth looking for examples. Thoughts?
Look at pulling the clinical summary from Mosaic with some safety features. Hopefully, we can reuse this to add a number of other attributes.
Here are a couple of screenshots for discussion. First, we should style the report to have a section at the top for general info and the clinical summary. These are the main pieces of information
If info was not available in Mosaic, we would provide help. For example (this is just a quick sketch for discussion), if there was no clinical summary attribute to pull from, the Clinical summary card would say that there is no information and provide a couple of options, e.g. to manually add the summary (ensuring that we don't require connection to Mosaic, or that the project is maintained), or instructions on how to add data into Mosaic that would propagate to clin. In this latter case we'd have an information modal pop up to explain what to do. This probably shouldn't be a button, but something relevant to the task.