-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Medium
-
FHIR Core (FHIR)
-
STU3
-
FHIR Infrastructure
-
Datatypes
-
2.23.2.2
-
-
Grahame Grieve/Rick Geimer: 9-0-0
-
Compatible, substantive
-
STU3
Existing Wording: contentType
Comment:
Attachment.contentType is unusual in that it uses a code type, with a required binding, but is not a closed value set. I thought we use "code" when the value set is fully known. However, not only is the value set not fully known, it is imprecise: in some cases mime type parameters (like charset) can be ignored, but in other cases it is significant; multiple mime type parameters may occur an any order without affecting interpretation of the mimetype (application/foo;version=1;charset=UTF-8 is the same as application/foo;charset=UTF-8;version=1)
At a minimum there should be discussion in the element details pointing out that it may be necessary to parse the string, e.g. to remove charset, version, or other parameters.
There are probably complications related to search that should include a warning.
Consider using a Coding.
(Similar code vs Coding issue for Attachment.language)
Summary:
Clarify use of code for Attachment.contentType
- is voted on by
-
BALLOT-4910 Affirmative - Elliot Silver : 2018-May-FHIR R4 INFRASRUCTURE R1
- Closed