Datatypes R2 Issue 17

Introduction

Very often ED content comes from a file that has a name, or some other source where there is some text that describes the content - for when it will eventually be a file name.

This name is a useful thing for applications - they can use it when they do move the content into a filename, or display the name in preference to the content sometimes.

backward compatible: yes

INM Summary

After discussion, this proposal has been modified to add the property:

 description : ST

To the type ED. The definition for the property is:

 This property is a stand-in for the full media for use as an 
 alternative description of the media where the media 
 is not accessible for display.

Additional Description:

 The intent of this property is 
 compliance with disability requirements such as those expressed
 in American's with Disability Act (also known as "Section 508").

description would be optional in the datatypes specification

Approved - INM 11/06/2007 Telecon

Discussion

We can simply add title:ST to the abstract and add it as an attribute in the XML ITS.

This was approved at the BOF in Holland.

This is not right. Why don't you use the reference for this? What does a "filename" mean? It's a file:// URL, so what makes it special and unusable for reference? Gschadow 12:15, 3 May 2007 (CDT)

Don't agree to the title either. There is no need for it. Applications can just make up some file name. They will have to anyway because it needs to be unique in the directory wherever they save this file. There should be no meaning to the file name. It's not an identifier. Applications can make up the filename or alt="" bubble however they want. It is too much burden on HL7 to put it in, then we need to deal with it in the equal criteria, then we need conformance for it. Too much work for no real benefit. Gschadow 12:19, 3 May 2007 (CDT)

Revising my assessment Gschadow 13:01, 3 May 2007 (CDT)

Clarification

The real use case for this is complience with the American's with Disability Act also known as "Section 508" complience. Likely to pop up in other countries too, so not a "U.S. Realm" issue. The use case is an alternative description of the media where the media is not accessible to "screen readers". I would ammend the proposal to add a property

 description of type ST

which is like thumbnail a stand-in for the full media in certain circumstances. It is expressly not just a title, let alone a filename. There would have to be sender and receiver responsibilities, i.e., any agents suitable for users who are covered entities of such accessibility regulations would have to produce and maintain description properties. For others it is optional.

With this amendment, I will change my vote to For. Gschadow 13:01, 3 May 2007 (CDT)

Note From Charlie:

Agree that there is a usecase for this (the screenreader one) and that this is different to the failename requirement. I think that the filename requirement goes "the sender located the data using one URL (file://...) but the data is being made available to the receiver at a different URL (cid://... Or urn:hl7-iiref: or some such). We needed something like this in GP2GP, and ended up having to model the attachemnts as a class to get that information in. It could be argued that the requirement to share local names to the files should be depricated, but it is useful at least for legacy data, so it would be nice to have some guidence. Not sure how CDA / Attachements SIG do this -- but we should clear it up between this work, and the wrappersR2 work

Motion we approve this change.

For: Grahame, Lee, Lloyd, Dale, Gunther
Against: 
Abstain:

Status

Proposed.

Links

Back to Data Types R2 issues