# Restrict mime-type in DV_MULTIMEDIA

**Category:** [Tools](https://discourse.openehr.org/c/tool-dev/36)
**Created:** 2022-08-29 11:06 UTC
**Views:** 655
**Replies:** 8
**URL:** https://discourse.openehr.org/t/restrict-mime-type-in-dv-multimedia/2960

---

## Post #1 by @martijn.vaneenennaam

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

---

## Post #2 by @thomas.beale

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](https://github.com/openEHR/terminology/blob/master/openEHR_RM/en/openehr_terminology.xml#L84)).

---

## Post #3 by @martijn.vaneenennaam

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?

---

## Post #4 by @thomas.beale

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](https://github.com/openEHR/terminology/blob/master/openEHR_RM/openehr_external_terminologies.xml#L445).

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!

---

## Post #5 by @pieterbos

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 https://www.w3.org/ns/iana/media-types/ . 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 https://specifications.openehr.org/releases/AM/latest/ADL2.html#_term_constraint_basics  .

---

## Post #6 by @thomas.beale

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](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_term_constraint_basics).

---

## Post #7 by @pablo

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.

---

## Post #8 by @Colin_Sutton

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.

---

## Post #9 by @yampeku

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

---


**Canonical:** https://discourse.openehr.org/t/restrict-mime-type-in-dv-multimedia/2960
**Original content:** https://discourse.openehr.org/t/restrict-mime-type-in-dv-multimedia/2960