type: docsource: source/metadatatypes.html

[%settitle Metadata Types%] [%file newheader%] [%file newnavbar%] <%mdtheader base%>

MetaDatatypes

Responsible Owner: [[%wgt fhir%]]([%wg fhir%]) Work Group	Standards Status:Normative

Types Framework Cross Reference: Base Types | Datatypes | Resources | Patterns

This page describes a set of types used for conveying metadata about knowledge resources (mainly for Terminology, Conformance and Clinical Definition resources).

Table of Contents

ContactDetail	DataRequirement	ParameterDefinition	RelatedArtifact
TriggerDefinition	Expression	UsageContext	ExtendedContactDetail
VirtualServiceDetail	Availability	MonetaryComponent

For an index of all datatypes, see the Datatypes page.

ContactDetail

[%StandardsStatus normative DataType infrastructure%]

The ContactDetail structure defines general contact details.

[%dt ContactDetail 1%]

Constraints

[%dt.constraints ContactDetail%]

ContactDetail is used in the following places: [%dtusage ContactDetail%]

DataRequirement

The DataRequirement structure defines a general data requirement for a knowledge asset such as a decision support rule or quality measure.

[%dt DataRequirement 1%]

Constraints

[%dt.constraints DataRequirement%] [%tx DataRequirement%]

A DataRequirement differs from a parameter in that it specifies the data to be provided in terms of the type of data, and specific filters on code-valued and/or date-valued attributes. Data requirements are not named because they are referenced by type within the evaluation context.

DataRequirements are used by knowledge modules to communicate the set of required data to a consumer in a way that is computable (as opposed to a set of named parameters which must be integrated by hand based on the meaning of the parameter as communicated through the documentation).

DataRequirements are typically used to communicate patient-dependent information such as MedicationStatements and Encounters, whereas Parameters are typically used to communicate patient-independent information such as configuration values.

For example, consider the following CQL expression:

define "Total Colectomy Procedures":
  [Procedure: "Total Colectomy Value Set"] P
    where P.performedPeriod during "Measurement Period"

The criteria is looking for procedures matching the "Total Colectomy Value Set" that were performed during the "Measurement Period". In this case, "Measurement Period" is a parameter, referenced by name, whereas the reference to Procedure uses the name of the resource type, and so constitutes a data requirement of the criteria:

<dataRequirement>
    <type value="Procedure"/>
    <codeFilter>
        <path value="code"/>
        <valueSetString value="Total Colectomy Value Set"/>
    </codeFilter>
    <dateFilter>
        <path value="performed"/>
        <valuePeriod>
            <start value="2016-01-01"/>
            <end value="2016-12-31"/>
        </valuePeriod>
    </dateFilter>
</dataRequirement>

If a resource type has multiple date attributes, then it may be necessary to include multiple date criteria. For instance, in the example above the Procedure resource is using the performedPeriod date attribute. However, the Procedure resource also provides a performedDateTime (specific date and/or time when procedure was performed) attribute. Therefore, if the date criteria for the Procedure in the example was recorded using the performedDateTime attribute, the date criteria would be incomplete. To account for this additional date attribute, the example could be expanded as follows:

define "Total Colectomy Procedures":
  [Procedure: "Total Colectomy Value Set"] P
    where exists (P.performedPeriod during "Measurement Period")
      or exists (P.performedDateTime during "Measurement Period")

The data requirement for the expanded criteria:

<dataRequirement>
    <type value="Procedure"/>
    <codeFilter>
        <path value="code"/>
        <valueSetString value="Total Colectomy Value Set"/>
    </codeFilter>
    <dateFilter>
        <path value="performed"/>
    </dateFilter>
</dataRequirement>

DataRequirement is used in the following places: [%dtusage DataRequirement%]

ParameterDefinition

The ParameterDefinition structure defines a parameter to a knowledge asset such as a decision support rule or quality measure.

Parameters are typically used to communicate patient-independent information such as configuration values, whereas DataRequirements are typically used to communicate patient-dependent information such as MedicationStatements and Encounters.

[%dt ParameterDefinition 1%]

Constraints

[%dt.constraints ParameterDefinition%] [%tx ParameterDefinition%]

The RelatedArtifact structure defines resources related to an artifact such as previous and next versions of documents, documentation, citations, etc. Note that the name artifact here is being used in a general sense; The related artifact may be a FHIR resource, or it may be another type of resource, represented using the Attachment datatype.

[%dt RelatedArtifact 1%]

Constraints

[%dt.constraints RelatedArtifact%] [%tx RelatedArtifact%]

The following examples illustrate the use of relatedArtifact elements to provide citations:

<relatedArtifact>
    <label value="1"/>
    <type value="citation"/>
    <citation value="Linder, J.A., D.W. Bates, G.M. Lee, J.A. Finkelstein. 2005. _Antibiotic treatment of children with sore throat_ JAMA 294(18):2315-2322. "/>
  </relatedArtifact>
  <relatedArtifact>
    <type value="citation"/>
    <label value="2"/>
    <citation value="Infectious Diseases Society of America. 2012. _Clinical Practice Guideline for the Diagnosis and Management of Group A Streptococcal Pharyngitis: 2012 Update._ "/>
  </relatedArtifact>
  <relatedArtifact>
    <type value="citation"/>
    <label value="3"/>
    <citation value="Roberts, R.R., B. Hota, I. Ahmad, et al. _Hospital and Societal Costs of Antimicrobial-Resistant Infections in a Chicago Teaching Hospital: Implications for Antibiotic Stewardship._ Clin Infect Dis. Oct 2009; 49(8):1175-84."/>
  </relatedArtifact>

RelatedArtifact is used in the following places: [%dtusage RelatedArtifact%]

Interpretation of RelatedArtifact in different contexts

The RelatedArtifact type is used in a variety of contexts, and supports flexible description of relationships between artifacts. For example, the type can be used to describe both successor and predecessor relationships. This flexibility is needed to support use cases where only one side or other of the relationship is represented in FHIR. In practice, this datatype SHALL NOT be used to create bi-directional linking between FHIR resources.

Guidance on RelatedArtifact Usage

For resources that make use of RelatedArtifact, the relevant work group SHALL decide which relationships and target types are 'core' for the resource, which would historically have been handled as extensions, and which are not relevant at all. They SHALL define invariants that prohibit the use of relationships and/or target types for their resource that are never relevant or are redundant with other core elements or long-used extensions. (And if there is overlap with extensions that are not long-used, will ensure that the context for those extensions excludes the resource.) They will also add documentation to the element referencing RelatedArtifact calling out those relationship types that are considered 'core'.

Work groups considering the adoption of the RelatedArtifact data type, may only do so after evaluating what proportion of the incorporated elements are core for their resource and determining that the majority of the relationship types meet those criteria. They would still need to impose invariants around nonsensical or redundant relationship types and targets and provide documentation about which types were considered core. The note will also indicate that addition of new relationship types requires agreement that those relationships are 'core' to the majority of resources using the RelatedArtifactType and approval of the FHIR Infrastructure work group (from a methodology perspective).

TriggerDefinition

The TriggerDefinition structure defines when a knowledge artifact is expected to be evaluated. The structure can represent three main kinds of triggering events, depending on the value of type:

Named Event
Scheduled Event
Data Event

A named event is an event identified by the implementation environment. This allows any event generated within the implementation environment to be used as a trigger, but it requires pre-coordination of the names involved with the consuming environments. HL7 V2 events are assigned the URI http://terminology.hl7.org/CodeSystem/v2-0003#[code] e.g., http://terminology.hl7.org/CodeSystem/v2-0003/A01, and reference any data change that would trigger the sending of the matching HL7 V2 version, if the application providing the FHIR API supports v2 events internally.

A scheduled event occurs on a fixed or periodic schedule.

And finally, a data event occurs in response to some data-related event in the integrated environment such as a record being added or updated. The data-of-interest for a data event is described using a DataRequirement. This allows for systems to automatically invoke based on data activity occurring within the system. A condition may also be specified to further refine the trigger

[%dt TriggerDefinition 1%]

Constraints

[%dt.constraints TriggerDefinition%] [%tx TriggerDefinition%]

TriggerDefinition is used in the following places: [%dtusage TriggerDefinition%]

Expression

The Expression structure defines an expression that generates a value. The expression is provided in a specifed language (by mime type)

The context of use of the expression must specify the context in which the expression is evaluated, and how the result of the expression is used.

[%dt Expression 1%]

Constraints

[%dt.constraints Expression%] [%tx Expression%]

Language support

While the expression data type supports any language, a few specific languages defined by HL7 at particularly of interest for the purposes of this specification:

text/fhirpath: See FHIRPath Documentation
text/x-fhir-query: See FHIR X-Query Documentation
text/cql: See CQL (Clinical Quality Language) Documentation. There are also 2 CQL variants:
- text/cql-identifier: See CQL Identifier
- text/cql-expression: See CQL Expression

Expression is used in the following places: [%dtusage Expression%]

UsageContext

The UsageContext structure defines the context of use for a module.

[%dt UsageContext 1%]

Constraints

[%dt.constraints UsageContext%] [%tx UsageContext%]

UsageContext is used in the following places: [%dtusage UsageContext%]

ExtendedContactDetail

The ExtendedContactDetail structure defines extended contact details for a named, or unnamed individual/purpose.

These are extensively used in provider directory resources where contact information is often very rich in nature, and requires additional metadata around their usage.
This datatype permits the context of the contact informations use to be provided, and groups them together with other important metadata.

Not all properties are expected to be present in all instances, and only the ones that apply.
e.g., A website contact will only have the telecom included, but might also include a purpose and possibly a period if required. Whereas an accounts contact detail could include their name, postal address and telephone number (and possibly Organization if it was an outsourced capability)

The period provides the general start and end of the contact's applicability for usage. This is not intended to store a history of usages over time, but a convenient way to record upcoming relevant changes to the content when it is being published.
This permits a contact to be marked as becoming available from X, or is expected to no longer be available from Y. An extension may be used to mark a contact's general availability times (9am - 5pm) and also exceptions where the contact is not available (e.g., Public holidays)

[%dt ExtendedContactDetail 1%]

Constraints

[%dt.constraints ExtendedContactDetail%] [%tx ExtendedContactDetail%]

ExtendedContactDetail is used in the following places: [%dtusage ExtendedContactDetail%]

VirtualServiceDetail

The VirtualServiceDetail structure defines details of a virtual communication capability, such as a web conference call.

[%dt VirtualServiceDetail 1%]

Constraints

[%dt.constraints VirtualServiceDetail%] [%tx VirtualServiceDetail%]

VirtualServiceDetail is used in the following places: [%dtusage VirtualServiceDetail%]

Availability

The Availability structure defines a pattern of availability data typically used in directory resources.

[%dt Availability 1%]

Constraints

[%dt.constraints Availability%] [%tx Availability%]

Availability is used in the following places: [%dtusage Availability%]

MonetaryComponent

The MonetaryComponent structure defines a the set of properties across the financial resources.

This component is typically used in a list where each value provides a different type of value contributing to the final value used in line items on a financial transaction.
For example, a line item for a product might include the net price, the tax amount, and the surcharge amount as separate components.

[%dt MonetaryComponent 1%]

Constraints

[%dt.constraints MonetaryComponent%] [%tx MonetaryComponent%]

MonetaryComponent is used in the following places: [%dtusage MonetaryComponent%]

[%file newfooter%] try { var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index'); } catch(exception){ } if (!currentTabIndex) currentTabIndex = '0'; $( '#tabs-ContactDetail' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-DataRequirement' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-ParameterDefinition' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-RelatedArtifact' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-TriggerDefinition' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-Expression' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-UsageContext' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-ExtendedContactDetail' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-VirtualServiceDetail' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-Availability' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); $( '#tabs-MonetaryComponent' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { store(ui.newTab.index()); } }); function store(currentTab) { try { sessionStorage.setItem('fhir-resource-tab-index', currentTab); } catch(exception){ } $( '#tabs-ContactDetail' ).tabs('option', 'active', currentTab); $( '#tabs-DataRequirement' ).tabs('option', 'active', currentTab); $( '#tabs-ParameterDefinition' ).tabs('option', 'active', currentTab); $( '#tabs-RelatedArtifact' ).tabs('option', 'active', currentTab); $( '#tabs-TriggerDefinition' ).tabs('option', 'active', currentTab); $( '#tabs-Expression' ).tabs('option', 'active', currentTab); $( '#tabs-UsageContext' ).tabs('option', 'active', currentTab); $( '#tabs-ExtendedContactDetail' ).tabs('option', 'active', currentTab); $( '#tabs-VirtualServiceDetail' ).tabs('option', 'active', currentTab); $( '#tabs-Availability' ).tabs('option', 'active', currentTab); $( '#tabs-MonetaryComponent' ).tabs('option', 'active', currentTab); document.activeElement.blur(); }