# Media file archetype - ready for publication
**URL:** https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674
**Category:** CKM publication
**Created:** [1 July 2021 05:59 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674 "2021-07-01T05:59:15Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@heather.leslie](https://discourse.openehr.org/u/heather.leslie)
#### Post date: [1 July 2021 05:59 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/1 "2021-07-01T05:59:15Z")
Hi everyone,
The content description for this ‘Media file’ archetype is “A media file that is acquired or used as part of the healthcare process, and associated metadata.”
Relevant examples include:
- A photo of an injury;
- A diagram of the location of a specific clinical finding;
- A radiological image;
- An audio or video recording of an interview;
- Scanned pathology slide;
- Data output from a clinical device, such as an ECG machine; or
- A scanned image of paper documentation or hand-written clinical notes.
It started life as a single archetype to provide metadata details about the multimedia data type, intially named ‘Multimedia resource’. But as the content evolved it became evident there was more than one type of multimedia that we were dealing with. Gradually we have teased out the requirements and issues into two archetypes - this [‘Media file’ archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.1800) and its recently published sibling, the ‘[Information resource archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.4513)’ - “Information, instructional or educational material supplied to an individual, or their carer, as part of the provision of healthcare.”
Despite the unexpected length of design time, the archetype has been deemed ready for publication by the Editors after only one review round. While there are a number of dissenting recommendations, all were found to be due to not understanding the attributes of the multimedia data type or that this archetype will be nested within a parent ENTRY archetype which will hold context details such as DICOM details or anatomical location. The content of this archetype is describing the metadata about the file, not the context of capture or use, and is intended to complement and enhance the comprehensive set of attributes already carried by the data type.
Unless there are objections the ‘Media file’ archetype will be published on July 8, 2021.
Link to the archetype: [https://ckm.openehr.org/ckm/archetypes/1013.1.1800](https://ckm.openehr.org/ckm/archetypes/1013.1.1800)
Please reply to this topic if you have any objections or comments.
---
### Author:  [@chaya](https://discourse.openehr.org/u/chaya)
#### Post date: [13 July 2023 15:32 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/2 "2023-07-13T15:32:01Z")
@heather.leslie
The Multimedia datatype (Content) takes limited set of media\_type, although the specification says that it has the code set from IANA MIME types.
Our problem is we are not able to ingest anything other than the code sets mentioned in the archetype.
How do we add dicom image reference ( image/dcm) in content, content|media\_type
As per the IANA MIME types code set media type for dicom [image/dicom-rle](https://www.iana.org/assignments/media-types/image/dicom-rle)
Even content|media\_type as image/dicom-rle is not working
Getting the below error:
Invariant Media\_type\_valid failed on type DV\_MULTIMEDIA
Can you please suggest.
Thanks
Chaya
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [13 July 2023 16:07 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/3 "2023-07-13T16:07:23Z")
Hi Chaya,
Which CDR are you using?
The codeset is indeed taken from IANA and is documented [here](https://specifications.openehr.org/releases/TERM/latest/SupportTerminology.html#_media_types)
and really defined as part of the datatype and not the archetype as such.
but I’m not sure that all CDRs religiously validate against that list i.e. some may accept other mime types.
@birger.haarbrandt @matijap @Seref @bna @pablo -what is the current status of validation against the official mime types?
@sebastian.iancu - is there a place for ‘losing’ our local list and just reference [Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml) which does contain image/dicom-rle ?
---
### Author:  [@chaya](https://discourse.openehr.org/u/chaya)
#### Post date: [13 July 2023 16:47 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/4 "2023-07-13T16:47:33Z")
Hi @ian.mcnicoll
We are using ehrBase.
Is there a way to bypass this validation and be able to ingest Media type in IANA
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [13 July 2023 16:57 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/5 "2023-07-13T16:57:44Z")
Not right now , I suspect because it would need a code change in Ehrbase, an/or a change in the openEHR specs, which are needed IMO.
One option might be to use **application/dicom** in mediatype but not ideal.
We do really need to update the codeset or alternatively relax the validation.
---
### Author:  [@chaya](https://discourse.openehr.org/u/chaya)
#### Post date: [13 July 2023 17:49 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/6 "2023-07-13T17:49:31Z")
> [@ian.mcnicoll](#):
>
> application/dicom
Yes @ian.mcnicoll that works for now.
Thanks.
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [14 July 2023 15:59 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/7 "2023-07-14T15:59:01Z")
I don’t know yet exactly the implication of relaxing the specifications (by referring to external set instead of openEHR terminology); neither if it is just a validation process that has to be “relaxed” on implementation side …
Perhaps we should first have a discussion about this on one of our next SEC meeting.
In the meanwhile we could add `application/dicom-rle` to our specification set, and I guess is then just a matter of time until it will be supported in AD and EHRbase.
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [18 September 2023 21:22 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/8 "2023-09-18T21:22:13Z")
> [@ian.mcnicoll](#):
>
> -what is the current status of validation against the official mime types?
IIRC we have an extended list of mime types since there are some in the openEHR terminology but last time I checked that was out of date.
That is another code set maintained by an external entity that might not be a good idea to maintain ourselves on our terminology, unless there is a formal, more automated, way of getting new values into our code set, better than manually checking for updates and manually updating our terminology file.
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [19 September 2023 09:39 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/9 "2023-09-19T09:39:25Z")
I created a CR to handle this (see [[SPECTERM-26] - openEHR JIRA](https://openehr.atlassian.net/browse/SPECTERM-26)) and added the followings to IANA\_media-types codeset
```auto
### Author:  [@varntzen](https://discourse.openehr.org/u/varntzen)
#### Post date: [20 September 2023 11:43 UTC](https://discourse.openehr.org/t/media-file-archetype-ready-for-publication/1674/10 "2023-09-20T11:43:10Z")
Hi
Not trying to be a party pooper, but I think the question and discussion does not belong in this thread. The original thread is only about the publication process, and is in the Clinical channel. The ongoing discussion might get lost unless not copied and moved to a more appropriate channel, Implementation, Specification or Tooling, of your choice.
Cheers, Vebjørn