Restrict mime-type in DV_MULTIMEDIA

Implementation Tools
1

Hello,

I’m designing an archetype (ADL2) that can be used to upload photos. For this I am using a DV_MULTIMEDIA.
It all works, but what I want to do next is restrict (in the archetype) the mime-type of the file to image/jpeg.

How do I go about this? I was thinking something like:

ELEMENT[id5] occurrences matches {1} matches { 
    value matches {
        DV_MULTIMEDIA[id6] matches {
            media_type matches {[at1]}    -- image/jpeg
        }
    }
}

Where I make a term_definition at1, with a term_binding. But what term to bind to? And is this the best way to go?

Thanks!
Martijn

1 Like
2

The tool should allow you to do this:

ELEMENT[id5] occurrences matches {1} matches { 
    value matches {
        DV_MULTIMEDIA[id6] matches {
            media_type matches {[openehr::429]}    -- image/jpeg
        }
    }
}

Where 429 is the openEHR code for image/jpeg (see here in the XML terminology file).

1 Like
3

Thanks for your reply Thomas! The constant you are referring to is commented out in that file, is there a reason for that?; and is it ADL2.0 compatible?

4

Opps my fault. THat appears to be the previous way we did this. The new way appears to be to treat MIME types like country codes and other such terminologies - the correct terms are here.

So the tool should really be doing this:

ELEMENT[id5] occurrences matches {1} matches { 
    value matches {
        DV_MULTIMEDIA[id6] matches {
            media_type matches {[IANA_media-types::image/jpeg]}
        }
    }
}

But we probably need to check with @ian.mcnicoll , @sebastian.iancu , @sebastian.garde just to be sure this is correct!

5

Well in ADL 2 you cannot directly use that way of binding terms - The way to do is it to create a local at-code. Then, create a term binding that binds the external term to that local value code. The term binding must point to a term represented as a URL. For the openEHR-terminology, such a URL scheme is defined and used. For the iana media types - I don’t think so. So the question would be, how do we create such URLs, and do we perhaps need a registry for that, listing which scheme to use for which code?

In the case of IANA media types, an official URI namespace is specified in IANA MIME type namespace . That means in this case https://www.w3.org/ns/iana/media-types/image/jpeg#Resource

FHIR also has such a list, but it is mainly for identifying terminologies, not necessarily individual terms/codes within such a terminology.

Alternatively, a term binding to be used from the list of term bindings is possible, in the form of matches {[at5@snomed_ct]}, for example, as in paragraph 8.3 of the ADL 2 spec. However, at least Archie does not support that syntax yet.

Explained in the specification in Archetype Definition Language 2 (ADL2) .

2 Likes
6

Ah I had not realised you were using ADL2 (I was assuming Archetype Designer or one of the others) - in which case, everything is mapped via at-codes as Pieter has said.

Here’s the relevant part of the ADL2 spec.

7

The problem of constraining media/mime type by code is the openEHR terminology is very constrained and is not updated to the latest iana codes, even worst, you might need to use local codes and extend the openEHR terminology, which leads to issues on using the codes. Had this problem when designing the data validation for EHRServer, and I think it would be better to use the mime type directly as its code_string, that is to avoid using the openEHR terminology codes for this specifically. Second, I would leave the list of possible mime types open for used defined codes. The issue that generates is portability, since other systems might not be able to access the local extension for possible codes.

3 Likes
8

But photos are not only jpeg. Shouldn’t the archetype allow all the image mime types? You could restrict the possibility to jpeg in a template, if necessary for your application.

1 Like
9

In any case, this constraint is not really useful unless the archetype somehow commands 100% your UI. Which I don’t see as being useful for multimedia. You would typically validate the data type even before the upload, with specific UI logic, not validate just the mime type when storing

In any case I would think that for external terminologies (not managed within openEHR, the list of codes should be a recommendation) you would always assume that more codes can exist

1 Like