Best practice for passing images with Phenopacket

[dnil]

Hi folks,

thank you for a super useful resource! We a bit new on the track, and currently find ourselves more or less having to pass a couple of images along with certain Phenopackets - primarily radiography evidence for exchange external to the hospital, where it would be super smooth not to have to trade multiple files.

Is there already a best practice for this, e.g. serialising as a Measurement, as a data-URL in an Evidence ExternalReference or File? Anything to avoid that would most certainly break other service? Thank you kindly!

I guess this is pretty similar to #143, but we would ideally like to be able to do this in the short term, with minimum discomfort for later changes. All the best!

[pnrobinson]

Hi @dnil -- there are no current best practices for this, but it would be great to touch bases and discuss, and perhaps we can add a page to the documentation. We are guessing there might be a version 3 in a few years and we would like to work with the community to figure out how to best add additional needed features. I am at peter robinson at jax org.

[julesjacobsen]

If your EHR exposes a REST API it should be possible to add the URI to a File message attached to a phenopacket instance. As @pnrobinson said there isn't a current best practice for attaching arbitrary files, apart from using a File and a URI reference.

Do you mean you'd like to embed the radiography file into the phenopacket itself?

[dnil]

Hi @julesjacobsen!

The use case is for a patient or geneticist to fill in data for a phenotype report to UDNI in a small app, which could then be passed on to other initiatives, international diagnostic units and so on. Obviously we think using Phenopackets for this is a good idea. But some specialists, in particular in radiology, were not happy with receiving only the ontology based conclusions of another expert, but need to see images to agree.

Any EHR API would be firewalled, at least in several use cases. We could perhaps store multiple files, or some sort of file
bundle including the packet, but it adds complexity to the services. It would be so clean and simple to just exchange one record. Hence embedding is a suggestion. 😊

[julesjacobsen]

Well, if it's your app and your data and system, then you can create a wrapper message like this:

syntax = proto3;

import "phenopackets/schema/v2/phenopackets.proto";

message UdniReport {
    Phenopacket phenopacket = 1;
    repeated Image images = 2;
}

message Image {
     bytes bytes = 1; // MAX 2GB!
// might want some other data too like a file name or a format or maybe some OntologyClass tags
// added by a specialist to describe the image. 
}

then compress and stuff the image into the Image message to send alongside the phenopacket and any other system-specific data you might need.

The application can then handle it all as one big blob of data and the radiographers get what they want too. Does this make sense? In the future we can think about adding this to the next version of the standard if others are keen on having it too.

[dnil]

Thank you, looks viable and nice enough! I think we will lean towards doing something like that.

Just in case, do you think it would otherwise break other apps or the intent if we piggybacked a picture directly into e.g. a URL/URI or a measurement value?

[julesjacobsen]

If you're sharing this data with anyone else then yes, stuffing a picture into a string type will cause some confused apps as they will not render the data correctly. Doing this will also completely break the intent of the field.