This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2 Content Examples Detailed Descriptions Mappings Profiles 6.7 Resource Binary - Content This resource maintained by the FHIR Management Group Work Group A binary resource can contain any content, whether text, image, pdf, zip archive, etc. 6.7.1 Scope and Usage There are situations where it is useful or required to handle pure binary content using the same framework as other resources. Typically, this is when the binary content is referred to from other FHIR Resources. Using the same framework means that the existing servers, security arrangements, code libraries etc. can handle additional related content. Typically, Binary resources are used for handling content such as: CDA Documents (i.e. with XDS) PDF Documents Images (the Media resource is preferred for handling images, but not possible when the content is already binary - XDS) A binary resource can contain any content, whether text, image, pdf, zip archive, etc. These resources are served in their native form on the rest interface, but can also be represented in XML or JSON, such as when including these resources in a bundle (used when it is convenient to include these in the feed directly rather than leaving them by reference). 6.7.2 Boundaries and Relationships This resource is generally used as the target of a Document Reference or an Attachment , when a FHIR server finds it convenient to manage the content within the same overall REST framework as the other resources. This resource is referenced by [DocumentManifest] 6.7.3 Resource Content Structure UML XML JSON All Structure Name Flags Card. Type Description & Constraints Binary Resource Pure binary content defined by sime other format than FHIR contentType 1..1 code MimeType of the binary content MimeType ( Required ) content 1..1 base64Binary The actual content UML Diagram Binary ( Resource ) MimeType of the binary content represented as a standard MimeType (BCP 13) contentType : code 1..1 « The mime type of an attachment MimeType » The actual content, base64 encoded content : base64Binary 1..1 XML Template < <!-- from --> < < </Binary> JSON Template { "resourceType" : "", // from " " } Structure Name Flags Card. Type Description & Constraints Binary Resource Pure binary content defined by sime other format than FHIR contentType 1..1 code MimeType of the binary content MimeType ( Required ) content 1..1 base64Binary The actual content UML Diagram Binary ( Resource ) MimeType of the binary content represented as a standard MimeType (BCP 13) contentType : code 1..1 « The mime type of an attachment MimeType » The actual content, base64 encoded content : base64Binary 1..1 XML Template < <!-- from --> < < </Binary> JSON Template { "resourceType" : "", // from " " }   Alternate definitions: Schema / Schematron , Resource Profile ( XML , JSON ), Questionnaire 6.7.3.1 Terminology Bindings Path Definition Type Reference Binary.contentType The mime type of an attachment Required BCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049) 6.7.3.2 Serving Binary Resources using the RESTful API The Binary resources behaves slightly differently to all other resources on the RESTful API. specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/xml+fhir" or "application/json+fhir", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly. Note that due to the way the web infrastructure works, it is not possible to make blanket rules about the relationship between the "Accept" field in the http request, and the return type, which is why there is no hard rule about this. However the intent is that unless specifically requested, the FHIR XML/JSON representation is not returned. Note that in the native binary representation, the metadata is not available directly, though some of it is replicated in the HTTP response headers. 6.7.3.3 Security Considerations Binary resources are not constrained, and therefore can be of any content type and encoding. Therefore extra care needs to be taken to validate the content of the Binary resource against malicious or malformed content. For more details see Security of Narrative . 6.7.4 Search Parameters Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services. Name Type Description Paths contenttype token MimeType of the binary content Binary.contentType © HL7.org 2011+. FHIR DSTU (v0.4.0-4902) generated on Fri, Mar 27, 2015 00:17+1100. Links: What's a DSTU? | Version History | Specification Map | Compare to DSTU1 | | Propose a change try { var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index'); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } if (!currentTabIndex) currentTabIndex = '0'; $( '#tabs' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { var active = $('.selector').tabs('option', 'active'); currentTabIndex = ui.newTab.index(); try { sessionStorage.setItem('fhir-resource-tab-index', currentTabIndex); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } } });