Generated Narrative: StructureDefinition C4DIC-Barcode-extension Name Flags Card. Type Description & Constraints <a href="StructureDefinition-C4DIC-Barcode-extension-definitions.html#Extension" title="This extension enables payers to provide an image of the barcode found on a member's physicial insurance card. This image may be displayed by consuming applications when rendering the coverage information for use by the health plan member. Often there are data elements relevant to the health plan coverage encoded in the barcode. The extension also allows for the health plan to provide a Label for the image which can be displayed in the consuming application as well as a Description of the content in the image file. Detailed descriptions are encouraged to assist with accessibility.">Extension 0..* Extension Barcode #xD; extension 3..* Extension Extension #xD; Slices for extension Content/Rules for all slices #xD; extension:description 1..1 Extension Extension #xD; extension 0..0 Extension #xD; url 1..1 uri "description" #xD; value[x] 0..1 string Value of extension #xD; extension:image 1..1 Extension Extension #xD; extension 0..0 Extension #xD; url 1..1 uri "image" #xD; Slices for value[x] 0..1 Value of extension Slice: Unordered, Open by type:$this #xD; valueAttachment Attachment #xD; valueReference Reference(DocumentReference) #xD; value[x]:valueAttachment 0..1 Attachment Value of extension #xD; contentType 1..1 code Mime type of the content, with charset etc. #xD; data 1..1 base64Binary Data inline, base64ed #xD; value[x]:valueReference 0..1 Reference(DocumentReference) Value of extension #xD; reference 1..1 string Literal reference, Relative, internal or absolute URL #xD; extension:label 1..1 Extension Extension #xD; extension 0..0 Extension #xD; url 1..1 uri "label" #xD; value[x] 0..1 string Value of extension #xD; url 1..1 uri "http://hl7.org/fhir/us/insurance-card/StructureDefinition/C4DIC-Barcode-extension" #xD; value[x] 0..0 Value of extension #xD; Documentation for this format
HL7 International / Payer/Provider Information Exchange Work Group
This extension enables payers to provide an image of the barcode found on a member's physicial insurance card. This image may be displayed by consuming applications when rendering the coverage information for use by the health plan member. Often there are data elements relevant to the health plan coverage encoded in the barcode. The extension also allows for the health plan to provide a Label for the image which can be displayed in the consuming application as well as a Description of the content in the image file. Detailed descriptions are encouraged to assist with accessibility.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), 'value')])
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Source of the definition for the extension code - a logical name or a URL.
The definition may point directly to a computable or human-readable definition of the extensibility codes, or it may be a logical URI as declared in some other specification. The definition SHALL be a URI for the Structure Definition defining the extension.
Value of extension - must be one of a constrained set of the data types (see [Extensibility](http://hl7.org/fhir/R4/extensibility.html) for a list).
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Mime type of the content, with charset etc.
Identifies the type of the data in the attachment and allows a method to be chosen to interpret or render the data. Includes mime type parameters such as charset where appropriate.
Processors of the data need to be able to know how to interpret the data.
The mime type of an attachment. Any valid mime type is allowed.
ED.2+ED.3/RP.2+RP.3. Note conversion may be needed if old style values are being used
The human language of the content. The value can be any valid value according to BCP 47.
Users need to be able to choose between the languages in a set of attachments.
The actual data of the attachment - a sequence of bytes, base64 encoded.
The base64-encoded data SHALL be expressed in the same character set as the base resource XML or JSON.
The data needs to able to be transmitted inline.
A location where the data can be accessed.
If both data and url are provided, the url SHALL point to the same content as the data contains. Urls may be relative references or may reference transient locations such as a wrapping envelope using cid: though this has ramifications for using signatures. Relative URLs are interpreted relative to the service url, like a resource reference, rather than relative to the resource itself. If a URL is provided, it SHALL resolve to actual data.
The data needs to be transmitted by reference.
RP.1+RP.2 - if they refer to a URL (see v2.6)
Number of bytes of content (if url provided)
The number of bytes of data that make up this attachment (before base64 encoding, if that is done).
The number of bytes is redundant if the data is provided as a base64binary, but is useful if the data is provided as a url reference.
Representing the size allows applications to determine whether they should fetch the content automatically in advance, or refuse to fetch it at all.
The calculated hash of the data using SHA-1. Represented using base64.
The hash is calculated on the data prior to base64 encoding, if the data is based64 encoded. The hash is not intended to support digital signatures. Where protection against malicious threats a digital signature should be considered, see [Provenance.signature](http://hl7.org/fhir/R4/provenance-definitions.html#Provenance.signature) for mechanism to protect a resource with a digital signature.
Included so that applications can verify that the contents of a location have not changed due to technical failures (e.g., storage rot, transport glitch, incorrect version).
A label or set of text to display in place of the data.
Applications need a label to display to a human user in place of the actual data if the data cannot be rendered or perceived by the viewer.
The date that the attachment was first created.
This is often tracked as an integrity issue for use of the attachment.
Literal reference, Relative, internal or absolute URL
A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.
Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.
Type the reference refers to (e.g. "Patient")
The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources).
This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified.
Aa resource (or, for logical models, the URI of the logical model).
Logical reference, when literal reference is not known
An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.
When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy. When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it. Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any).
Plain text narrative that identifies the resource in addition to the resource reference.
This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.