Saving pedigrees fails when family members have medical reports attached

Description

Steps to reproduce:

  • create a patient

  • attach a medical report PDF of around 1MB

  • draw the pedigree

  • try to save -> saving fails, the error is that the form is too big

The cause is that the medical reports are included in the patient json, which is included in the pedigree.

The ideal fix would be to not include the reports, how quick and easy is it to do it?

A quick workaround is to increase the maximum form size.

Environment

None

Activity

Show:
Andrew Misyura
July 31, 2018, 12:26 AM

we need to discuss how medical reports are added to JSONs. I think started because of that. But OI think Gene42 is using that data in some other cases so just excluding reports is not a good solution. I was think in that medical reports controllers should maybe put some kind of URLs to download data instead of actual data, but need to discuss this ad make sure none of Gene42 code is not broken after the change

Daniel Gross
July 31, 2018, 3:45 PM

Thanks for the heads up. The only case that we use that data is for a custom record push implementation that sends patient JSON directly instead of using the patient push API. I agree with you that the ideal solution is to enable/disable the medical reports data using URL arguments.

I think Daniel Gross started OPEN because of that

This is correct, and actually finished the implementation and it is already being used. I will add the details to PT-3757.

Andrew Misyura
July 31, 2018, 4:19 PM
Edited

I wonder if in the future we can include a URL for medical reports where a report can be downloaded (e.g. a rest endpoint) instead of a complete report PDF (or whatever)? I really don't like having multi-megabyte JSONs with BASE64 (or whatever) encoded data, even if that can be disabled when not needed. Would that work for everyone in the long term?

P.S. someone mentioned that medical reports can now be pushed, which implies push uses regular push machinery which uses the JSON - removing reports form JSON will break that. I think we should discuss what we can do about this, since push uses a custom protocol we may add a separate step to push specifically medical reports file-by-file (as something known to be large). After all, the problem is not in pedigree, just having family with multiple patients makes it more likely to fail, but it can still fail (e.g. push fails, REST PUT fails) even for a single patient

Daniel Gross
July 31, 2018, 6:00 PM

I agree that using a URL instead of the encoded file content is a better approach in general. However it would break our current JSON-based custom push implementation, because the current implementation expects to be able to send the entire record (including all attachments) with a single HTTP PUT. This implementation could be changed, however, and should not be considered a blocker to changing this functionality.

Assignee

Andrew Misyura

Reporter

Sergiu Dumitriu

Labels

None

External issue ID

None

Components

Fix versions

Affects versions

Priority

Blocker
Configure