Maturity Level: N/A | Standards Status:Informative |
HL7 v3 was intended to be the next generation of HL7's messaging standards. It introduced a common Reference Information Model (RIM), data type model and set of vocabulary as well as a formal standards development methodology. In addition, it introduced the use of "documents" as an alternative architecture to messaging for sharing healthcare information (see the CDA comparison). While nominally covering both, the term "v3" is typically used to refer to "v3 messaging". The data types used as a basis for v3 have also been adopted by ISO as ISO 21090. The HL7 RIM has also been adopted as an ISO standard.
v3 messaging has been adopted by a number of large projects, particularly in the electronic health record area, though it has not achieved the market penetration of HL7 v2. The HL7 RIM and the ISO 21090 data types have also been used by other SDOs and projects that have not leveraged the full HL7 v3 methodology. Most of the comments and guidance provided here will apply to those solutions as well.
Reference model: The use of the HL7 RIM is a core aspect of the HL7 v3 methodology and it is front and center in the specification and the wire format. All data elements in HL7 v3 instances are derived from either the RIM or the ISO data types. In FHIR, this is true of most resources and data type elements, but not all. Some resources (StructureDefinition, CapabilityStatement, ValueSet, etc.) deal with content that is outside the RIM's scope. And in a few circumstances, adjustments have been made in the FHIR data types that are not yet supported in the HL7 v3 data types model. The expectation is that these changes will be supported in the next version of the v3 data types model. The main difference is that the serialization format of FHIR is not driven by the RIM mappings. This results in considerably more concise and intuitive instances. It is possible to implement FHIR with absolutely no knowledge of the HL7 RIM.
Codes: v3 places considerable reliance on coded attributes to convey the meaning of instances. Examples include classCode, moodCode, determinerCode, etc. The allowed codes for these attributes are strictly controlled by HL7. FHIR also has attributes that are limited to codes defined in the FHIR specification - those using the code data type. However, these are generally limited to attributes with business meaning - status, contact types, etc.
Both FHIR and v3 make use of value sets to define the sets of codes that can be used for attributes within particular contexts. However, in FHIR, a ValueSet is just another type of resource, meaning it can be sent as part of an instance just like any other piece of data. (The same is true of StructureDefinition, CapabilityStatement and other meta-level resources.)
Granularity & referencing: HL7 v3 models are broken into 3 main types - wrappers, payloads and Common Message Element Types (CMETs). These are combined into interactions to define the set of content that can be sent over the wire at one time. In some cases, the granularity of each of these models will exactly align with the granularity of FHIR resources, but not always. v3 models are divided based on the expectation of re-use. FHIR models are divided based on whether the objects they represent can be considered to "stand alone". In HL7 v3, numerous models can exist to represent the same essential underlying healthcare information construct. For example, at the HL7 International level, there are 10 different CMETs for the concept of "Patient". In addition, some payload models represent patient directly without using CMETs. Further variation exists in the v3 models created by HL7 affiliates and other v3 implementers. Each of these different CMETs has their own schema and may use different element names, different levels of nesting and different constraints. With FHIR, there is only one Patient resource. Many profiles can be created on that resource, but all of them will use the same schema and support the same serialization format.
Design by constraint: The design methodology in v3 is one of "design by constraint". The idea is that all data needed for any sort of healthcare communication is represented in the HL7 RIM. All other data models simply constrain the RIM to reflect the needs of particular domain spaces. This starts at the international level with further refinement happening in individual countries, projects and finally specific implementations. As models become closer to the implementer, they become less abstract. The result is a tendency for v3 models to be extremely broad in their coverage and capability and somewhat abstract. They need to be this way to ensure that all possible implementations in the space covered by that model can be properly constrained. As well, each model produces its own schema and, in most cases, constrained schemas are not strictly wire-compatible with the schemas of the model being constrained.
FHIR takes a different approach. FHIR resources do not attempt to represent all data elements that could possibly be used in a space. Instead, only those data elements that are expected to be used by "most" implementations within the scope of the resource are considered part of the core resource definition. (This is sometimes referred to as "The 80% rule" - if approximately 80% of systems maintaining the resource will support the element, then it is part of core). All other data elements are expected to be handled using extensions. Profiles are used both to constrain resources and to define extensions appropriate to narrower implementation spaces. Serialization format interoperability is retained across all profiles on a given resource.
Context conduction: When conveying healthcare information between humans, much data can be inferred from context. For example, if a report has an "author" noted on a cover page, it is generally inferred that each statement within the report is authored by that same person. This inference grows more challenging when data needs to be analyzed by computers, whether for query, decision support or other analysis. Thus far, the HL7 v3 methodology has provided three distinct mechanisms to allow data models to define how "context" should propagate through models, making explicit for computers what humans would normally understand intuitively. FHIR has chosen a different path. In FHIR, no context is conducted - everything is explicit. If a report about a patient contains 100 observations about that same patient, each observation will include a reference to the patient. However, this is relatively painless because it's only a reference - an id and possibly a short display value. One of the benefits of this approach is that each resource can be safely consumed and examined without concern for the context in which that resource was communicated. The meaning of each resource instance is fully self-contained.
Null flavors: In healthcare, it's quite common for data to be unknown, unavailable, have an exceptional value or otherwise fall outside the bounds of a "normal" value. To deal with this, v3 introduced the concept of "null flavor" on almost every attribute and data type property in its models. These coded null flavors could be sent in place of or in addition to the data that would typically be sent for the attribute, association or data type property. Examples include the ideas of "Unknown", "Not asked", "Positive infinity", "Trace amount", "Masked", "Other", etc. Unless an element was explicitly marked as "mandatory" - meaning no null flavors were permitted - these null flavors could appear anywhere.
FHIR approaches the problem differently. Null flavors are only introduced in the core specification in those circumstances where it is expected that most systems will need them. Where needed, the flavors are constrained to those relevant to that element.
Using RIM mappings: Most resource elements and data type properties include mappings to the RIM. These mappings serve two purposes. They help to define FHIR semantics in terms of HL7's reference models, helping to ensure that the Work Groups defining the data elements have a good and consistent understanding of the meaning of every element. They also provide guidance for implementers of v3 specifications that may be looking to migrate to or map between v3 and FHIR. However, for the latter use it's important to understand some limitations on the RIM mappings. The RIM is a language which allows the same "idea" to be conveyed in several ways with varying granularity and expressiveness. Thus, it's entirely possible for a RIM element to map to a core FHIR element even though its RIM representation is somewhat different than described in the mapping. In addition, not all v3 models adhere to good modeling practices, so some data elements that would appear to map to a FHIR element might not map if the information has not been well represented. Therefore, RIM mappings should be taken as a guide, not an absolute, and mappings must be done in the context of the v3 specification being mapped. (Also, see Abstract models below.)
v3 extensions: While the core of the v3 methodology is "design by constraint", it still makes provision for the use of extensions - either in a foreign namespace or denoted by a special attribute. When converting between v3 and FHIR, the use of such extensions will need to be taken into account. As a rule, most v3 extensions will map to FHIR extensions, as the v3 design-by-constraint principle suggests that anything that would qualify as "core" in FHIR would already have been part of the base v3 specification.
Abstract models: As previously noted, many of the v3 models created at the HL7 International level are quite abstract. As a result, the models can be used to say a wide variety of things, often in a wide variety of different ways. This makes defining a mapping between those specifications and FHIR (or any other specification) quite tricky. For practical v3 <-> FHIR interoperability, mappings will need to be created at the level of message specifications, implementation guides and/or templates that are more concrete and closer to the implementation level. For example, mapping all of CDA to FHIR would be impossible given the expressive capability of the right-hand-side of the CDA model. However, mapping the Consolidated CDA (CCDA) templates to FHIR is quite possible.
Context conduction: As discussed above, HL7 v3 models rely on context conduction - either implicitly or explicitly controlled. When converting to FHIR, the context will need to be propagated into each resource.
Update mode: In HL7 v3 instances, updates are generally handled in snapshot mode, similar to the FHIR approach - if any information changes, the entire record is sent, including the modified data elements. However, the v3 methodology does support the introduction of an "updateMode" property to allow only the changes to be sent for all or part of an instance. Each element repetition is flagged with an updateMode to indicate whether the element is to be added, removed, updated, etc. Additional updateModes allow further control over updates. As with the v2 discussion above, implementers will need to generate a full snapshot of each resource or consider using the Patch Operation instead.
Additional considerations: Most of the implementation considerations for interoperating between FHIR and HL7 v2 also hold with v3. Specifically: Extensions, Independent vs. Contained resources, Resource Identification, Merging references and resources and Generating human-readable content.
Maturity Level: N/A | Standards Status:Informative |
Health Level Seven (HL7) has been developing healthcare information exchange and related standards since 1987. In that time, the organization has produced a number of standards families - many used throughout the world to automate healthcare data sharing and improve patient care. FHIR has been written to be implementable without any knowledge of these other specifications. However, FHIR does leverage this prior experience, both in terms of applying best practices learned from experience and attempting to avoid some of the pitfalls of earlier work.
This appendix describes the relationship of FHIR to some of HL7's other standard families. It may be of interest to those coming to FHIR with previous experience with other HL7 standards as well as those who may need to support interoperability between FHIR solutions and implementations of other HL7 standards.
In this appendix:
Notes:
Work Group Standards Status:Informative |
The Conformance Module represents metadata about the datatypes, resources and API features of the FHIR specification and can be used to create derived specifications.
The core FHIR specification describes a set of resources, frameworks and APIs that are used in many different contexts in healthcare. However, there is wide variability between jurisdictions and across the healthcare ecosystem around practices, requirements, regulations, education and what actions are feasible and/or beneficial.
For this reason, the FHIR specification is a "platform specification" - it creates a common platform or foundation on which a variety of different solutions are implemented. As a consequence, this specification usually requires further adaptation to particular contexts of use.
Typically, these adaptations specify:
Note that because of the nature of the healthcare ecosystem, there may be multiple overlapping sets of adaptations - by healthcare domain, by country, by institution, and/or by vendor/implementation.
FHIR provides a set of resources that can be used to represent and share the adaptations listed above in a computable fashion. These resources are collectively called the conformance resources. Although these conformance resources can be used in isolation they are typically used in the context of an Implementation Guide or a Capability Statement:
The content of an Implementation Guide is described using the ImplementationGuide resource, while the capability statement is represented by the CapabilityStatement resource. These two resources make use of the complete set of conformance resources to fully capture the set of adaptations they represent. Note that the CapabilityStatement resource is one of the conformance resources, the first just describing the capabilities of a system, while the latter is the set of all conformance resources, including:
Conformance resources may be used independently, not just within the context of an ImplementationGuide resource or capability statement. See the section Common use cases for examples of such uses.
The conformance resources and their relationships are shown below:
Resources shown with a dotted box are described in other sections of the specification:
ValueSet
, ConceptMap
and StructureMap
are from the section on terminology,
TestScript
is part of the section on Implementer Support.
The conformance resources do not represent patient-related data, and as such are less susceptible to data breaching. Some caution is required however:
StructureDefinitions
may contain invariants formulated as structured
expressions that are evaluated by external engines (i.e. xpath), which -if improperly
sandboxed- could provide low-level access to the systemConformance resources are commonly used as part of an Implementation Guide or CapabilityStatement resource. There are many ways to use the resources independently however, including:
StructureDefinitions
to
claim conformance to the rules laid out in those StructureDefinitionsCapabilityStatement
resources, effectively functioning
as a discovery endpoint for services within an organizationStructureDefinitions
and
OperationDefinitions
to generate code that represents the structures as
classes and operations as remotely callable functions to provide an easier programming
model to a software developer. NamingSystem
resources, so vendors and
implementers can quickly look up the URLs or oids for a given terminology or identifier
system.A subset of the conformance resources has been tested and used in production tooling and are now normative. These include StructureDefinition and ValueSet. Others, like CapabilityStatement, have been used widely, but not across all elements. As a consequence, these resource have a considerable number of elements marked for "trial use", while other parts are normative and will no longer change in a substantive way.
Other resources are still under development:
ImplementationGuide
: used in the HL7 production tooling but has not received much use
outside of these tools yet.CompartmentDefinition
: was new in STU3, and as such has not undergone much production
useThese resources have been mainly used in the tools used to build the FHIR publication, early-adopter implementation guides and the FHIR Foundation conformance resource registry. In future, we expect to see more widespread use of these resources in validation tooling, code-generators and more extensive model-based guide authoring tools.
Maturity Level: Normative | Standards Status:Normative |
The FHIR specification describes a set of resources and several different frameworks for exchanging resources between different systems. Because of its general nature and wide applicability, the rules made in this specification are fairly loose. As a consequence, this specification allows that different applications might not be able to interoperate because of how they use optional features. Applications claiming conformance to this specification make the claim in respect of a specific exchange framework, and in regard to specific details about their usage of those frameworks and resource contents.
Applications claim conformance to one (or more) of the following exchange frameworks:
To provide details about specific usage of the frameworks and resource contents, FHIR provides a conformance layer that implementers, national/regional programs, and other profiling organizations such as IHE, can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases. The conformance layer itself is implemented using the following key resources:
Value Set | Defines a set of coded values (see "Using Codes" for more details) |
StructureDefinition | Makes rules about how a resource (or type) and its data elements are used in a particular context, including defining how extensions are used. A structure definition references value sets for the coded elements in a resource |
CapabilityStatement | A statement of the kinds of resources and operations provided and/or consumed by an application. The Capability Statement references profiles to describe specific use of resources by the application |
Implementation Guide | A single coherent collection of capability statements, profiles, extensions, value sets, and documentation describing a set of interoperable applications |
The specification also provides a number of tools that can assist with enforcing technical conformance to this base specification.
FHIR is a closed specification. The specification defines what is possible and required for those portions of an API or exchange framework that wish to declare themselves as FHIR conformant, and that includes exchange resources that conform to the documented requirements of this specification. Systems may choose to support capabilities beyond those defined by FHIR (e.g. by adding additional end points/services with other names), but those portions of their interfaces that extend beyond what FHIR explicitly allows cannot be considered or described as "FHIR conformant".
Conformance with this specification does not provide any guarantee of patient or data safety. However, choosing to not conform to this specification carries additional risk in two ways:
Systems can only claim FHIR Conformance for functionality described in the applicable CapabilityStatement.
This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119. Unlike RFC 2119, however, this specification allows that different applications might not be able to interoperate because of how they use optional features. In particular:
The contents of a resource and the formats used to represent resources SHALL conform to the rules described in this specification, as defined in the narrative of the specification, and as controlled by the conformance properties defined below.
Data elements defined in resources and data types have 3 properties that are directly related to conformance: Cardinality, Is-Modifier, and MustSupport. These interact to place conformance requirements on implementations.
All attributes defined in FHIR have cardinality as part of their definition - a minimum number of required appearances and a maximum number. These numbers specify the number of times the attribute may appear in any instance of the resource type. This specification only defines the following cardinalities: 0..1, 0..*, 1..1, and 1..*. Profiles that describe specific use cases may use other values for cardinality within the limits of the cardinality defined by the base resource.
Note that when present, elements cannot be empty - they SHALL have a value attribute, child elements, or extensions. This means that setting an element to a minimum cardinality of 1 does not ensure that valid data will be present; specific FHIRPath constraints are required to ensure that the required data will be present.
In this specification, very few elements have a minimum cardinality of 1. Resources are used in many contexts, often quite removed from their primary use case, and sometimes even basic information is quite incomplete. For this reason, the only elements that have a minimum cardinality of 1 are those where they are necessary to any understanding of the resource or element that contains them. The minimum cardinalities should not be taken as a guide to what elements are expected to be present in any particular use of the resource, including their normal/primary usage purpose. In some cases, this specification publishes additional profiles that define which elements are required in particular situations. Similar profiles are published by jurisdictions, vendors, profiling organizations, or projects.
For elements that have cardinality > 1, the order in which they appear may have meaning. Unless the element definition (either in this specification or the extension) defines a meaning to the order explicitly (using ElementDefinition.orderMeaning), the meaning of the order is not defined, and implementations are allowed to reorder the elements. Note that it is not possible to define a meaning for the order of the elements in a profile using a StructureDefinition. When there is no definition of the meaning of the order, implementations that need to choose a single element from a list of elements for some use SHALL do so based on the semantics of the content of the element that repeats. Profiles and Implementation guides may often make rules about this selection process.
Clients should not depend on servers maintaining ordering of elements, unless the retrieved resource conforms to a profile which mandates maintenance of ordering. If a server cannot maintain ordering, it must strip off known profile tags which require maintenance of ordering, and strip off unknown profiles (since they might require maintenance of ordering).
Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when extensions are defined.
An element is a modifier if and only if it cannot be safely ignored because its value, or its meaning if missing, may cause the interpretation of the containing element or one of its descendants to no longer conform to the stated definition for the element. Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty" that invert or negate the meaning of the resource (or element) that contains them.
Modifier is not an indication of the degree of importance for a particular piece of information or whether the element ought to be ignored when the resource is used for common use-cases. It is expected that if you ignore an element you may miss an important piece of computable meaning.
For example, consider Observation:
Observation.status
allows the entered-in-error
code, which indicates
that no actual Observation occurred at all. The definition of Observation indicates that it is a measurement that has
been made - and doesn't allow for the possibility of a measurement that wasn't made. As a result, if the status
element were ignored and an Observation were interpreted at face value based on its definition, a system or user
would infer that an Observation had occurred, which would be falseObservation.subject
element, it wouldn't know who or what was observed, which
would make the remaining information largely useless for most usage.
However, any system that ignores the subject would not have a false understanding of the Observation as it's
defined. The system would understand what type of observation was made, when and what was found, just not who it was aboutObservation.code
is not a modifier element. While the Observation would have
little utility without the code, the understanding when ignoring the element that “some” Observation had been
made on the specified subject at the specified date and time would still be true when the element was
reintroduced. The only exception would be if a value expressed in the Observation.code element could
somehow convey that the Observation had not occurred or otherwise cause the instance to diverge from
the defined meaning of Observation when ignoring the element
The definition of is-modifier
has a corollary: any element that meets the requirement that it could
cause the interpretation of the containing element or its descendants to diverge from their definition
SHALL explicitly declare how such divergence could occur and must be marked as a modifier element.
Any element not marked is-modifier
and without that explanation SHALL NOT be used by an implementer in such a
manner as to make the element behave as a modifier. For example, using a special "name" on a patient
to indicate that the subject isn’t a real patient, but is instead an artificial structure used for
non-patient tests would be non-conformant with FHIR because Patient.name is not a modifier element
Whether an element is a modifier cannot be changed when element usage is described in a constraining Structure Definition. When an element is labeled as Is-Modifier, the documentation must be clear about why it is a modifier.
A typical example of a modifier element is one that negates the element that contains it. For instance, in the following fragment of a resource definition:
Name | Flags | Card. | Type | Description & Constraints![]() |
---|---|---|---|---|
![]() ![]() | DomainResource | Allergy or Intolerance (generally: Risk of Adverse reaction to a substance) | ||
![]() ![]() ![]() | Σ | 0..1 | dateTime | Date(/time) when manifestations showed |
![]() ![]() ![]() | Σ | 1..1 | Reference(Patient) | Who the sensitivity is for |
![]() ![]() ![]() | ?! Σ | 0..1 | CodeableConcept | unconfirmed | confirmed | refuted | entered-in-error AllergyIntoleranceVerificationStatus (Required) |
![]() ![]() ![]() | Σ | 0..1 | code | CRITL | CRITH | CRITU AllergyIntoleranceCriticality (Required) |
The definition of an AllergyIntolerance is that it contains information about "Risk of harmful or undesirable,
physiological response which is unique to an individual and associated with exposure to a substance".
If the value of the 'verificationStatus' element is set to entered-in-error
, the
entire resource does not actually contain valid information about any risk of exposure, and
it is not safe for applications to ignore this element. As a consequence, it is labeled as 'is modifier = true'. In this tabular representation of the resource,
this shows as the flag '?!'. The JSON and XML representations
of a resource definition have their own representation of 'is modifier = true' status, and
it is defined directly in a ElementDefinition.
If a narrative summary is present, and the status is generated
, Is-Modifier elements SHALL be represented in the narrative summary of the resource.
If Narrative is present with some other status Is-modifier elements SHOULD be represented.
If the value of a modifier element is not explicit in the instance, or known by the context, the resource might not be able to be safely understood. Wherever possible, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, in order to introduce certainty in their handling. However, sometimes this is not possible - much legacy data is not well described. Implementations producing resources SHOULD ensure that appropriate values for isModifier elements are provided at all times.
Implementations processing the data in resources SHALL understand the impact of the element when using the data. Implementations are not required to "support" the element in any meaningful way - they may achieve this understanding by rejecting instances that contain values outside those they support (for instance, an application may refuse to accept observations with a reliability other than "ok"). Alternatively, implementations may be able to be sure that, due to their implementation environment, such values will never occur. However applications SHOULD always check the value irrespective of this.
Note that processing the data of a resource typically means copying or filtering data out of a resource for use in another context (display to a human, decision support, exchange in another format where not all information is included or storing it for this kind of use). Servers and background processes that simply move whole resources around unchanged are not "processing the data of the resource", and therefore these applications are not required to check Is-Modifier elements.
Every element in the base resource has a value of "true" or "false" for the Is-Modifier flag. The value of the flag cannot be changed by profiles on the resource, in either direction. When a StructureDefinition defines an extension, it labels the extension with the Is-Modifier flag, and this cannot be changed in other profiles. Note that extensions that have is-Modifier = true are represented differently in resource instances ("modifierExtension" instead of "extension"), and there are additional rules about how they are handled.
Most status
elements are marked as modifiers because of the presence of the entered-in-error
status.
Other modifiers are defined:
Labeling an element MustSupport means that implementations that produce or consume resources SHALL
provide "support" for the element in some meaningful way. Because the base FHIR specification is intended
to be independent of any particular implementation context, no elements are flagged as mustSupport
=true as
part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
For this reason, the specification itself never labels any elements as MustSupport. This is done in StructureDefinitions, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc.
Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.
All elements may have constraints attached to them (also known as 'invariants'). Constraints defined on an element have the following properties:
Key | Identifies the constraint uniquely amongst all the constraints in the context - typically, this is used to refer to the constraint in an error message |
Requirements | An explanation of why the constraint has been applied - what harmful conditions are being avoided |
Severity | The severity of the invariant - see below |
Human Description | A human description of the rule intended to be shown as the explanation for a message when the constraint is not met |
Expression | A FHIRPath expression that must evaluate to true when run on the element |
XPath | An XPath expression that must evaluate to true when run on the element in the XML representation |
Many constraints are defined in the base specification. In addition, additional constraints may be defined in profiles that apply to resources. Systems are not required to evaluate the constraints, just as they are not required to check for conformance, or schema validity. However, systems SHOULD always ensure that all resources are valid against all applicable constraints.
Constraints have a severity level:
Error (rule) | A rule that all resources must conform to. Validators should report it as an error if the rule is violated, and applications processing the content can reject it as an invalid resource |
Warning | Report this as a warning that there may be a problem with the resource, but it is considered valid and can be processed normally |
Guideline | A warning marked with an extension (http://hl7.org/fhir/StructureDefinition/elementdefinition-bestpractice) that indicates that it should be a treated as an error if the implementation context asks a validator to enforce best practice rules. See Best Practices for a full list |
Elements can also be explicitly associated with constraints defined elsewhere. This is a notification to implementers that the element is affected by the constraint. It has no meaning when the constraints are evaluated.
Profiles may define additional constraints that apply to an element, but they cannot alter or remove constraints that are already applied.
In addition to the conformance metadata, each element has other metadata properties defined in the ElementDefinition:
This specification includes many examples. While every effort has been made to ensure that the examples are fully conformant to the specification, if the examples disagree with the specification, the specification is considered correct and normative, not the examples. This same rule applies to the reference implementations.
The examples reflected in this specification do *not* represent actual people. Any resemblance to real people - alive or dead - is entirely coincidental. In some cases, examples may be drawn from real clinical data. However, if this has occurred, the content has been scrubbed to remove any identifying information.
Maturity Level: 2 | Standards Status:Trial Use |
Source | CPT is made managed by the American Medical Association |
System | The URI http://www.ama-assn.org/go/cpt identifies the CPT code system |
Version | Where a version is appropriate, use the year of release e.g. 2014 |
Code | "Code" in the CPT tables (a 5-character code) |
Display | "Description" in the CPT tables |
Inactive | Todo: Describe how it is determined which concepts are inactive |
Subsumption | No Subsumption relationships are defined by CPT |
Filter Properties | None defined |
CPT is released each October. CPT versions are identified simply by the year of their release.
<coding> <system value="http://www.ama-assn.org/go/cpt"/> <version value="2014"/> <code value="31502"/> <display value="Tracheotomy tube change prior to establishment of fistula tract"/> </coding>
CPT is a registered trademark of the American Medical Association. The AMA holds the copyright for the CPT coding system.
When Value Sets include CPT codes, the copyright element should include the text "CPT copyright 2014 American Medical Association. All rights reserved.".
No filter properties have been defined at this time.
The value set URL http://hl7.org/fhir/ValueSet/cpt-all is a value set that includes all CPT codes.
Maturity Level: N/A | Standards Status:Informative |
The FHIR community meets as part of the wider HL7 community and draws on its extensive human resources, institutional memory, previous standards and corporate support. HL7 itself owns FHIR and makes it freely available and the community relies on HL7 provided infrastructure.
The FHIR community gathers, meets, or communicates using the following infrastructure, provided by HL7 directly, or by the HL7 FHIR Foundation:
In addition, the community holds regular face to face connectathons and meetings as part of the HL7 Working Group meetings. The formal governance arrangements that manage FHIR development are documented on HL7's Confluence site.
FHIR is a specification produced by the HL7 Community. Many individuals and organizations contribute to the FHIR specification. Of particular note:
Maturity Level: 3 | Standards Status:Trial Use |
Source | Available at http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx. Developed by The CDC's National Center of Immunization and Respiratory Diseases (NCIRD) |
System | The URI to identify CVX codes is http://hl7.org/fhir/sid/cvx |
Version | If it is desired to exchange the version, use the date of the last updated code in the format YYYYMMDD |
Code | Use the value of "CVX Code" column in the web page |
Display | Use the value of the "Short Description" column in the web page |
Inactive | Todo: Describe how it is determined which concepts are inactive |
Subsumption | No Subsumption relationships are defined by CVX |
Filter Properties | None are described yet |
If it is desired to exchange the version, use the date of the last updated code in the format YYYYMMDD.
CVX has no copyright acknowledgement needed, nor are there any license terms to adhere to.
No need for filters identified yet.
No need for implicit value sets identified yet.
Maturity Level: Normative | Standards Status:Normative |
This page provides the detailed descriptions for the data types
Table of Contents
Primitive Types | Complex Types |
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
todo
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Mappings and R2 Conversions.
Maturity Level: N/A | Standards Status:Informative |
This page includes additional examples of the data types, based on common usages and questions
Table of Contents
A boolean true value:
<active value="true" />
A negative integer value:
<score value="-14" />
A high-precision decimal value:
<pi value="3.14159265358979323846264338327950288419716939937510" />
A stream of bytes, base64 encoded:
<data value="/9j/4...KAP//Z" /> <!-- covers many lines -->
A Unicode string:
<caption value="Noodles are called ?? in Chinese" />
A URI that points to a website:
<reference value="http://hl7.org/fhir" />
A URI that is a urn:
<id value="urn:isbn:0451450523" />
A date of birth:
<date value="1951-06-04" />
An approximate date of birth:
<date value="1951-06" />
The instant a document was created, including time zone:
<instant value="2013-06-08T10:57:34+01:00" />
The instant a document was created, expressed in UTC, with milliseconds:
<instant value="2013-06-08T09:57:34.2112Z" />
2:35pm in the afternoon:
<time value="14:35" />
A URI that is the root oid of HL7:
<root value="urn:oid:2.16.840.1.113883" />
A URI that is a uuid:
<id value="urn:uuid:a5afddf4-e880-459b-876e-e4591b0acc11" />
A code:
<code value="acq4+acq5" />
A code with single internal space:
<code value="Question 4b" />
A numeric id:
<id value="314" />
An alphanumeric id:
<id value="alpha-gamma-14" />
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
A PDF document:
<document> <contentType value="application/pdf" /> <language value="en" /> <data value="/9j/4...KAP//Z" /> <!-- covers many lines --> <title value="Definition of Procedure" /> </document>
document : { contentType : { value : "application/pdf" }, language : { value : "en" }, data : { value : "/9j/4...KAP//Z"}, title : { value : "Definition of Procedure" } }
Since the JSON examples have the same structure as the XML, only XML is shown for the rest of the examples.
A reference to a DICOM image via WADO:
<image> <contentType value="application/dicom" /> <url value="http://10.1.2.3:1000/wado?requestType=WADO&wado_details..." /> <hash value="EQH/..AgME" /> </image>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
A primary key from an application table (an OID in the space allocated by HL7 to some organization to further sub-allocate):
<identifier> <use value="official" /> <system value="urn:oid:2.16.840.1.113883.16.4.3.2.5" /> <value value="123" /> </identifier>
A patient identifier defined by a hospital:
<identifier> <use value="official" /> <system value="http://www.acmehosp.com/patients" /> <value value="44552" /> <period> <start value="2003-05-03" /> </period> </identifier>
In this case, the period is used to track when the identifier was first assigned to the patient.
An identifier that refers to a patient FHIR resource on a particular system:
<identifier> <system value="urn:ietf:rfc:3986" /> <value value="http://pas-server/xxx/Patient/443556" /> </identifier>
This is not a resource reference - it's a logical reference by the patient identifier.
A UUID:
<identifier> <use value="temp" /> <system value="urn:ietf:rfc:3986" /> <value value="urn:uuid:a76d9bbf-f293-4fb7-ad4c-2851cac77162" /> </identifier>
UUIDs are often used for temporary identifiers, though this is not necessary.
A US SSN:
<identifier> <use value="usual" /> <type> <coding> <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/> <code value="SSN"/> </coding> </type> <system value="http://hl7.org/fhir/sid/us-ssn" /> <value value="000111111" /> </identifier>
Notes:
A medical record number assigned on 5-July 2009:
<identifier> <use value="usual" /> <type> <coding> <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/> <code value="MRN"/> </coding> </type> <system value="urn:oid:0.1.2.3.4.5.6.7" /> <value value="2356" /> <period> <start value="2009-07-05" /> </period> </identifier>
A root only:
<v3:id root="0.1.2.3.4.5"/>
becomes:
<identifier> <system value="urn:ietf:rfc:3986" /> <value value="urn:oid:0.1.2.3.4.5" /> </identifier>
A root with an extension:
<v3:id root="0.1.2.3.4.5" extension="13412"/>
becomes:
<identifier> <system value="urn:oid:0.1.2.3.4.5" /> <value value="13412" /> </identifier>
See v3 Mapping Notes
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
A simple code for headache, in ICD-10:
<code> <system value="http://hl7.org/fhir/sid/icd-10" /> <code value="G44.1" /> </code>
A SNOMED CT expression:
<problem> <system value="http://snomed.info/sct" /> <code value="128045006:{363698007=56459004}" /> </problem>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
A simple code for headache initially coded in SNOMED CT (by picking the SNOMED CT code from a pick-list), and then translated to ICD-10:
<concept> <coding> <system value="http://hl7.org/fhir/sid/icd-10" /> <code value="R51" /> </coding> <coding> <system value="http://snomed.info/sct" /> <code value="25064002" /> <display value="Headache" /> <userSelected value="true" /> </coding> <text value="general headache" /> </concept>
A concept represented in an institution's local coding systems for unit for which no UCUM equivalent exists:
<unit> <coding> <system value="urn:oid:2.16.840.1.113883.19.5.2" /> <code value="tab" /> <display value="Tablet" /> </coding> <coding> <system value="http://unitsofmeasure.org" /> </coding> </unit>
A SNOMED CT expression:
<diagnosis> <coding> <system value="http://snomed.info/sct" /> <code value="128045006:{363698007=56459004}" /> </coding> <text value="Cellulitis of the foot" /> </diagnosis>
In this case, there is no display element, because no display is defined for SNOMED CT expressions.
Using the value set:
The results on a urinalysis strip:
<valueCoding> <system value="http://example.org/codes/simple-grades" /> <code value="+" /> </valueCoding>
And where the value set would be something like this:
<ValueSet xmlns="http://hl7.org/fhir"> <text> <status value="generated"/> <div xmlns="http://www.w3.org/1999/xhtml"> <p>Possible Clinistix codes: neg, trace, +, ++, and +++</p> </div> </text> <url value="http://hl7.org/fhir/ValueSet/clinistix"/> <name value="Codes for Clinistix"/> <publisher value="HL7"/> <contact> <name value="FHIR project team"/> <telecom> <system value="url"/> <value value="http://hl7.org/fhir"/> </telecom> </contact> <description value="Clinistix Codes"/> <status value="draft"/> <experimental value="true"/> <date value="2013-10-01"/> <compose> <include> <system value="http://example.org/codes/simple-grades"/> <concept> <code value="neg"/> </concept> <concept> <code value="trace"/> </concept> <concept> <code value="+"/> </concept> <concept> <code value="+"/> </concept> <concept> <code value="++"/> </concept> <concept> <code value="+++"/> </concept> </include> </compose> </ValueSet>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
A duration:
<time> <value value="25" /> <unit value="sec" /> <system value="http://unitsofmeasure.org" /> <code value="s" /> </time>
A concentration where the value was out of range:
<result> <value value="40000" /> <comparator value=">" /> <unit value="mcg/L" /> <system value="http://unitsofmeasure.org" /> <code value="ug" /> </result>
An amount of prescribed medication:
<dose> <value value="3" /> <unit value="capsules" /> <system value="http://snomed.info/sct" /> <code value="385049006" /> </dose>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
US Dollars:
<time> <value value="25.00" /> <currency value="USD" /> </time>
Vietnamese Dong:
<result> <value value="410000" /> <currency value="VND" /> </result>
A quantity that represents a currency amount - used in Ratio where Money is not used:
<numerator> <value value="25.45" /> <unit value="US$" /> <system value="urn:iso:std:iso:4217" /> <code value="USD" /> </numerator>
(See full example on Ratio)
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
Range of Quantity (distance):
<estimate> <low> <value value="1.6" /> <unit value="m" /> </low> <high> <value value="1.9" /> <unit value="m" /> </high> </estimate>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
Titer (Ratio of integer:integer)
<result> <numerator> <value value="1" /> </numerator> <denominator> <value value="128" /> </denominator> </result>
Unit cost (Ratio of Money(as Quantity):Quantity):
<charge> <numerator> <value value="103.50" /> <unit value="US$" /> <code value="USD" /> <system value="urn:iso:std:iso:4217" /> </numerator> <denominator> <value value="1" /> <unit value="day" /> <code value="day" /> <system value="http://unitsofmeasure.org" /> </denominator> </charge>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Examples
23rd May 2011 to 27th May, including 27th May:
<coverage> <start value="2011-05-23" /> <end value="2011-05-27" /> </coverage>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Example
The output from an EKG device:
<sampledData> <origin> <value value="0"/> <unit value="μV"/> <system value="http://unitsofmeasure.org"/> <code value="uV"/> </origin> <period value="2"/> <factor value="2.5"/> <dimensions value="1"/> <data value="-4 -13 -18 -18 -18 -17 -16 -16 -16 -16 -16 -17 -18 -18 -18 ...."/> </sampledData>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
A Simple example
<name> <family value="Everyman" /> <given value="Adam" /> <given value="A." /> </name>
Composite names
<name> <family value="Contrata" /> <given value="Mary Jane" /> </name>
These cases can be quite ambiguous - is "Mary Jane" one name, or two? Different systems, and data enterers may treat this differently, and the person themselves might not know. Parts are allowed to contain spaces, but systems should consider how to treat these cases. Composite names separated by "-" should be treated as a single name part.
A common pattern: a person is called by a name other than that expected from their official name (first given name in most cultures).
<name> <use value="official" /> <family value="Chalmers" /> <given value="Peter" /> <given value="James" /> </name> <name> <use value="usual" /> <given value="Jim" /> </name>
This same pattern is often encountered with immigrants, who retain their real name for official use, but adopt a localized name for everyday use:
<name> <use value="official" /> <family value="Sczypinski" /> <given value="Piotr" /> <given value="Andre" /> </name> <name> <use value="usual" /> <family value="Skipper" /> <given value="Jim" /> </name>
Some people may also have a nickname that needs to be recorded:
<name> <use value="official" /> <family value="Brown" /> <given value="Steven" /> </name> <name> <use value="nickname" /> <given value="Junior" /> </name>
Note that there is some ambiguity in real life as to whether a non-official name is the patient's usual
name, or whether it's their
nickname
. In principle, nick names are used occasionally and informally, whereas the usual name is used consistently, and in
formal contexts. However, there is no formal criteria for the differentiating these usages, and even within a culture, people may vary in
their cases.
Karen van Hentenryck is of Dutch origin, and the "van" is a voorvoegsel.
<name> <use value="official" /> <family value="van Hentenryck" > <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" > <valueString value="van" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name"> <valueString value="Hentenryck" /> </extension> </family> <given value="Karen" /> </name>
See the Extensibility Example for more information about the use of extensions.
Complex example from Germany: Dr.phil. Regina Johanna Maria von Hochheim-Weilenfels, NCFSA. This example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, and professional designations.
<name> <use value="official" /> <family value="von Hochheim-Weilenfels"> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix" > <valueString value="von" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name"> <valueString value="Hochheim-Weilenfels" /> </extension> </family> <given value="Regina" /> <given value="Johanna" /> <given value="Maria" /> <prefix value="Dr. phil."> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier" > <valueCode value="AC" /> </extension> </prefix> <suffix value="NCFSA" /> </name> <name> <use value="maiden" /> <family value="Hochheim" /> </name>
This example makes use of the ISO 21090 extensions to carry the rarely used ISO 21090 qualifier attribute "AC".
Japanese example in the three forms: ideographic (Kanji), syllabic (Hiragana) and alphabetic (Romaji).
<name> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-representation"> <valueCode value="IDE" /> </extension> <family value="木村" /> <given value="通男" /> </name> <name> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-representation"> <valueCode value="SYL" /> </extension> <family value="きむら" /> <given value="みちお" /> </name> <name> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-representation"> <valueCode value="ABC" /> </extension> <family value="KIMURA" /> <given value="MICHIO" /> </name>
The three forms may be differentiated by the character subset each contains, but some systems require the differentiation to be made manually, which can be done using the ED representation extension.
Russian example in the two forms: Cyrillic and Latin:
<name> <family value="ЕМЕЛИН" /> <given value="ИВАН" /> <given value="ВЛАДИМИРОВИЧ" /> </name> <name> <family value="EMELIN" /> <given value="IVAN" /> <given value="VLADIMIROVICH" /> </name>
In Russian usage, these names are known as the domestic and foreign names respectively. The two forms are differentiated by the character subset each contains.
Scandinavian example: Erikson is the family name. Jan Erik are the given names, and Östlund the family name of the mother, which is taken as a Mellannamn.
<name> <use value="official" /> <family value="Erikson" /> <given value="Jan" /> <given value="Erik" /> <given value="Östlund"> <extension url="http://hl7.org/fhir/StructureDefinitioniso-20190#name-qualifier" > <valueCoding> <code value="MID" /> <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifier2" /> </valueCoding> </extension> </given> </name>
This example makes use of the ISO 21090 extension to carry the culture specific ISO 21090 qualifier attribute "MID" for the Mellannamn.
Then Jan Erikson has a daughter, Karin, with his wife Margrete Hansen. The first communication of the new born name is "Margrete Jente" (Margrete's Girl) and the mother's family name, not the given name (Karin). The father's Family name is not used at all. This is a known temporary name assigned directly after the birth of the child.
<name> <use value="temp" /> <!-- use could be OR+OLD, depends how record keeping is done --> <family value="Hansen" /> <given value="Margrete Jente" /> </name>
The baby's name is subsequently changed to the fathers' family name, and to use the mother's name as mellomnamn.
<name> <use value="official" /> <family value="Erikson" /> <given value="Karin" /> <given value="Hansen"> <extension url="http://hl7.org/fhir/StructureDefinitioniso-20190#name-qualifier" > <valueCoding> <code value="MID" /> <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifier2" /> </valueCoding> </extension> </given> </name>
Later, Karin gets married to Per Berg, and decides to adopt Berg as her family name, and also decides to use Erikson as the mellom navn. (Note: Karin could have chosen to use another mellom navn, e.g. the family name of her mother, her father or other family names as specified by naming laws of the country in question).
<name> <use value="old" /> <family value="Erikson" /> <given value="Karin" /> <given value="Hansen"> <extension url="http://hl7.org/fhir/StructureDefinitioniso-20190#name-qualifier" > <valueCoding> <code value="MID" /> <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifier2" /> </valueCoding> </extension> </given> </name> <name> <use value="official" /> <family value="Berg" /> <given value="Karin" /> <given value="Erikson"> <extension url="http://hl7.org/fhir/StructureDefinitioniso-20190#name-qualifier" > <valueCoding> <code value="MID" /> <system value="http://terminology.hl7.org/CodeSystem/v3-EntityNamePartQualifier2" /> </valueCoding> </extension> </given> </name> <name> <use value="usual" /> <family value="Berg" /> <given value="Karin" /> </name>
These examples are taken from the W3C International Examples, which should be consulted for further information.
A patronymic is "The part of a name that links to the genealogy":
<name> <text value="Björk Guðmundsdóttir"/> <family value="Guðmundsdóttir"/> <given value="Björk"/> </name>
A patronymic with a "son/daughter of" appellation:
<name> <text value="Isa bin Osman"/> <family value="bin Osman"/> <given value="Isa"/> </name>
A Chinese name with a generational name:
<name> <text value="毛泽东"/> <!-- left to right --> <family value="毛"/> <given value="泽东"/> </name> <name> <text value="Mao Ze Dong"/> <!-- left to right --> <family value="Mao"/> <given value="Ze Dong"/> </name>
Note that many systems in China do not store family and given names separately, and just use text
.
Additional Western name (see also example above):
<name> <use value="official" /> <family value="Yao" /> <given value="Ming" /> </name> <name> <use value="usual" /> <given value="Fred" /> </name>
Composite Family name:
<name> <family value="Carreño Quiñones" > <extension url="http://hl7.org/fhir/StructureDefinition/humanname-fathers"> <valueString value="Carreño" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-mothers"> <valueString value="Quiñones" /> </extension> </family> <given value="María-Jose" /> </name>
Note that it is optional whether to break down the family name to mother's and father's parts, and not always of value, as in this Brazilian Example:
<name> <family value="Santos Tavares Melo Silva" /> <given value="José" /> <given value="Eduardo" /> </name>
Note that this naming pattern can become quite extreme ("Pedro de Alcântara João Carlos Leopoldo Salvador Bibiano Francisco Xavier de Paula Leocádio Miguel Gabriel Rafael Gonzaga"). A more practical example is
<name> <family value="Costa Teixeira" > <extension url="http://hl7.org/fhir/StructureDefinition/humanname-fathers"> <valueString value="Costa" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-mothers"> <valueString value="Teixeira" /> </extension> </family> <given value="Manuel" /> </name>
After marriage, this may change to
<name> <family value="Costa Teixeira Sanches" > <extension url="http://hl7.org/fhir/StructureDefinition/humanname-fathers"> <valueString value="Costa" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-mothers"> <valueString value="Teixeira" /> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/humanname-partners-name"> <valueString value="Sanches" /> </extension> </family> <given value="Manuel" /> </name>
Russian Examples (using Cyrillic):
<name> <family value="Ельцин" /> <given value="Борис" /> <given value="Николаевич" /> </name> <name> <family value="Ельцина" /> <given value="Наина" /> <given value="Иосифовна" /> </name>
Example with Initial:
<name> <family value="Public" /> <given value="John" /> <given value="Q." /> </name>
Other Examples:
<name> <text value="Velikkakathu Sankaran Achuthanandan"/> <family value="Velikkakathu" /> <given value="Sankaran" /> <given value="Achuthanandan" /> </name> <name> <text value="Kogaddu Birappa Timappa Nair"/> <family value="Nair" /> <given value="Birappa" /> <given value="Timappa" /> <prefix value="Kogaddu" /> </name> <name> <text value="Aditya Pratap Singh Chauhan"/> <family value="Singh" /> <given value="Aditya" /> <given value="Pratap" /> <suffix value="Chauhan" /> </name> <name> <text value="Madurai Mani Iyer"/> <given value="Mani" /> <prefix value="Madurai" /> <suffix value="Iyer" /> </name> <name> <text value="Abu Karim Muhammad al-Jamil ibn Nidal ibn Abdulaziz al-Filistini"/> <family value="ibn Nidal ibn Abdulaziz" /> <given value="Muhammad" /> <given value="al-Jamil" /> <prefix value="Abu Karim" /> <suffix value="al-Filistini" /> </name>
Todo: need to discuss this with Indian / Arabic implementers. Note that collecting and storing the text element makes the primary purpose of the structured parts for index/searching, and fidelity of the name parts is not critical.
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Note about these examples: the most important element in an address is the 'text' element - this defines what is printed on the envelope, the actual postal address. The other data elements are provided to support either data analysis based on a patient's address, or for the many systems that exchange fully structured addresses specific to a particular culture. For this reason, these examples focus on the structured data elements of the address.
Example
HL7 office's address.
<address> <use value="work" /> <text value="1050 W Wishard Blvd RG 5th floor Indianapolis, IN 46240" /> <line value="1050 W Wishard Blvd" /> <line value="RG 5th floor" /> <city value="Indianapolis" /> <state value="IN" /> <postalCode value="46240" /> </address>
A UK example address, with the county 'HUDDERSFIELD'.
<address> <text value="1 Back Lane Holmfirth HUDDERSFIELD HD7 1HQ"/> <line value="1 Back Lane"/> <city value="Holmfirth"/> <district value="HUDDERSFIELD"/> <postalCode value="HD7 1HQ"/> </address>
A temporary postal address - i.e. an address that it doesn't make sense to try and visit.
<address> <use value="temp"/> <type value="postal"/> <line value="PO Box 31445"/> <city value="Erewhon"/> <postalCode value="0001"/> </address>
The next set of examples are taken from the official international postal union examples.
Rue Lougoraïa 12, app. 10 | thoroughfare type, name and number, apartment |
Korolevo | locality |
223016 NOVY DVOR | postcode + post office name |
Minsk | District name of district |
Minsk | Region name of region |
BELARUS | Country |
<address> <line value="Rue Lougoraïa 12, app. 10"/> <city value="Korolevo"/> <district value="Minsk"/> <state value="Minsk" /> <country value="BELARUS" /> </address>
Protea Apt 12 | apartment number |
22 Ally Hassan Mwinyi | premise + street |
14111 MSASANI | postcode + locality |
DAR ES SALAM | province |
TANZANIA | country |
<address> <line value="Protea Apt 12"/> <line value="22 Ally Hassan Mwinyi"/> <city value="MSASANI"/> <state value="DAR ES SALAM" /> <postalCode value="14111"/> <country value="TANZANIA" /> </address>
15 Shiri | premise + sub-locality 2 |
Kimashuku Village | sub-locality |
25204 MACHAME KUSINI | postcode + locality |
HAI | sub-province |
KILIMANJARO | province |
TANZANIA | country |
<address> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-precinct"> <valueCode value="Kimashuku Village"/> </extension> <line value="15 Shiri"/> <city value="MACHAME KUSINI"/> <district value="HAI"/> <state value="KILIMANJARO" /> <postalCode value="25204"/> <country value="TANZANIA" /> </address>
705-1104 | building number + door |
56, Dalgubeol-daero 323beon-gil, Suseong-gu | street |
Daegu | city |
Rep. OF KOREA | country |
706-907 | postcode |
<address> <line value="705-1104"/> <line value="56, Dalgubeol-daero 323beon-gil, Suseong-gu"/> <city value="Daegu"/> <country value="Rep. OF KOREA" /> <postalCode value="706-907"/> </address>
3F | building floor |
42, Toegye-ro 77beon-gil | street |
Chuncheon-si | city |
Gangwon-do | province |
Rep. OF KOREA | country |
200-066 | postcode |
<address> <line value="3F"/> <line value="42, Toegye-ro 77beon-gil"/> <city value="Chuncheon-si"/> <state value="Gangwon-do" /> <country value="Rep. OF KOREA" /> <postalCode value="200-066"/> </address>
Ga-B101 | building number + door |
136, Sesil-ro | street |
Busan | city |
Rep. OF KOREA | country |
612-837 | postcode |
<address> <line value="Ga-B101"/> <line value="136, Sesil-ro"/> <city value="Busan"/> <country value="Rep. OF KOREA" /> <postalCode value="612-837"/> </address>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Example
Home phone number:
<telecom> <system value="phone" /> <value value="(555) 675 5745" /> <use value="home" /> </telecom>
In ISO 21090, CDA and other HL7 v3 specifications, the TEL data type requires that the telephone number be represented as a formal URI in RFC 3166 syntax. Many CDA documents violate this rule, since the telephone numbers are not collected from the user in conformance with the underlying rules (particularly around extensions, notes about use, etc.), so the base FHIR type does not require the phone number to be conformant. An ISO 21090 extension can be used to convey this if desired:
Example
Formally correct URI:
<telecom> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-TEL-address" > <valueUri value="tel:+15556755745" /> </extension> <system value="phone" /> <value value="(555) 675 5745" /> <use value="home" /> </telecom>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Example
A series of appointments for radiotherapy:
<schedule> <event value="2012-01-07T09:00:00+10:00" /> <event value="2012-01-14T09:00:00+10:00" /> <event value="2012-01-22T11:00:00+10:00" /> </schedule>
BID (twice a day) (no start or end specified):
<schedule> <repeat> <frequency value="2" /> <period value="1" /> <periodUnit value="d" /> </repeat> </schedule>
1/2 an hour before breakfast for 10 days from 23-Dec 2011:
<schedule> <repeat> <boundsPeriod> <start value="2011-12-23" /> <end value="2012-01-02" /> </boundsPeriod> <when value="ACM" /> <offset value="30" /> </repeat> </schedule>
Note that the end date is inclusive like the end date of a Period.
TID, for 14 days:
<schedule> <repeat> <boundsDuration> <value value="14" /> <unit value="d" /> <system value="http://unitsofmeasure.org" /> <code value="d" /> </boundsDuration> <frequency value="3" /> <period value="1" /> <periodUnit value="d" /> </repeat> </schedule>
BID, start on 7/1/2015 at 1:00 PM:
<schedule> <repeat> <boundsPeriod> <start value="2015-07-01T13:00:00" /> </boundsPeriod> <frequency value="2" /> <period value="1" /> <periodUnit value="d" /> </repeat> </schedule>
Take just once, with no specified time
<schedule> <repeat> <count value="1" /> </repeat> </schedule>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Example
todo
<signature> <!-- todo --> </signature>
See also Base Definition, Detailed Descriptions, Mappings, Profiles & Extensions and R2 Conversions.
Example
todo
<Annotation> <!-- todo --> </Annotation>
Maturity Level: N/A | Standards Status:Informative |
This page lists profiles and extensions defined in this specification itself for the data types. For background information, see Profiling Resources and Extensibility. Additional profiles and extensions may be found in published Implementation Guides, or in the Conformance resource registry.
Table of Contents
Primitive Types | Complex Types |
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
Profile Name | Rules | Formal Definitions |
Simple Quantity | XML, JSON | |
Usage: |
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
See also Base Definition, Examples, Detailed Descriptions, Mappings and R2 Conversions.
Maturity Level: N/A | Standards Status:Informative |
This page provides mappings for the data types. There are mappings to HL7 v2, HL7 v3, and (where appropriate) vCard (see Mappings to Other Standards for further information & status).
Table of Contents
Primitive Types | Complex Types |
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
When mapping an HL7 v3 II data type to a FHIR Identifier, there are two possibilities:
To search on a CDA II.root
- which may appear in either Identifier.system
or Identifier.value
, use the syntax identifier=|[root],[root]
.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
vCard Mappings
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.
See also Base Definition, Examples, Profiles & Extensions, Detailed Descriptions and R2 Conversions.