- FHIR Binary Resource
- Electronic Health Records Exchange Through FHIR
- Medical Terminology
- Processes Data
- Processes Information
- Processes Documentation
- Health Information Exchange
- Electronic Health Records
- FHIR Smart
- Smart on FHIR
A Binary resource can contain any content, whether text, image, pdf, zip archive, etc. There are situations where it is useful or required to handle pure binary content using the same framework as other resources so that the existing servers, security arrangements, code libraries, etc. can handle additional related content.
Get The Data
- ResearchNon-Commercial, Share-Alike, Attribution Free Forever
- CommercialCommercial Use, Remix & Adapt, White Label Log in to download
When a Fast Healthcare Interoperability Resources (FHIR) server finds it convenient to manage the content within the same overall REST framework as the other resources, the Binary resource is generally used as the target in the Attachment data type to reference content via the .url element, such as in the DocumentReference and Media resources. Consequently, the Binary resource can be a target wherever the Attachment data type is used such as in the DocumentReference resource.
The DocumentReference and Media resources allow conveying binary content (via attachment) or pointing to one (as a Binary or non-FHIR URI) along with the metadata around that resource, and as such are searchable. Binary resources do not support ‘search’.
While CDA and PDF documents are conveyed as Binary (because they cannot be expressed natively in FHIR), FHIR Documents do not need to be similarly encoded and can be sent natively in FHIR using Bundle. However, in some situations FHIR Documents may be sent as a Binary if there is a need to treat them the same as other types of documents or binary files.
The Binary resource does not convey context of the file. If the context (information such as author, procedure, technique, etc.) should be conveyed, Media or DocumentReference resources are appropriate. The Binary resource may be used to convey actual binary file content conveyed by those resources. The Media resource is preferred for handling images, but this is not possible when the content is already binary (e.g. in some uses of IHE XDS).
Fast Healthcare Interoperability Resources (FHIR) is a draft standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization.
Its goal is to facilitate interoperation between legacy healthcare systems, to make it easy to provide healthcare information to healthcare providers and individuals on a wide variety of devices from computers to tablets to cell phones, and to allow third-party application developers to provide medical applications which can be easily integrated into existing systems.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs (Uniform Resource Locators). FHIR was supported at an American Medical Informatics Association meeting by many EHR (Electronic Health Record) vendors which value its open and extensible nature.
About this Dataset
John Snow Labs; Health Level Seven International;
|Source License URL
|Source License Requirements
FHIR, HL7, Medical Terminology, Processes Data, Processes Information, Processes Documentation, Health Information Exchange, Electronic Health Records, FHIR Smart, Smart on FHIR
FHIR Binary Resource, Electronic Health Records Exchange Through FHIR
|Name of the concept in the FHIR structure
|required : 1
|A Computer-ready name (e.g. a token) that identifies the structure - suitable for code generation. Note that this name (and other names relevant for code generation, including element & slice names, codes etc) may collide with reserved words in the relevant target language, and code generators will need to handle this.
|The type the structure describes.
|A free text natural language description of the structure and its use
|The value of the keyword should be an array of unique strings. The data object to be valid should contain all properties with names equal to the elements in the keyword value.
|The value of this keyword can be anything. The data is valid if it is deeply equal to the value of the keyword.
|Computer Ready Name
|This is a Binary resource
|The logical id of the resource
|The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
|A reference to a set of rules that were followed when the resource was constructed
|Extensions for implicitRules
|The base language in which the resource is written.
|Extensions for language
|MimeType of the binary content represented as a standard MimeType (BCP 13).
|Extensions for contentType
|This element identifies another resource that can be used as a proxy of the security sensitivity to use when deciding and enforcing access control rules for the Binary resource. Given that the Binary resource contains very few elements that can be used to determine the sensitivity of the data and relationships to individuals