Media file archetype - ready for publication

Clinical CKM publication
1

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 and its recently published sibling, the ‘Information resource archetype’ - “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
Please reply to this topic if you have any objections or comments.

5 Likes
2

@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
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

3

Hi Chaya,

Which CDR are you using?

The codeset is indeed taken from IANA and is documented here

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 which does contain image/dicom-rle ?

4

Hi @ian.mcnicoll
We are using ehrBase.

Is there a way to bypass this validation and be able to ingest Media type in IANA

5

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.

6

Yes @ian.mcnicoll that works for now.

Thanks.

1 Like
7

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.

1 Like
8

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.

9

I created a CR to handle this (see [SPECTERM-26] - openEHR JIRA) and added the followings to IANA_media-types codeset

  <code value="image/dicom-rle"/>
  <code value="image/jls"/>
  <code value="model/mtl"/>
  <code value="model/obj"/>
  <code value="model/stl"/>

The change will be part of an upcoming TERM Release 3.1.0.

10

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

2 Likes