Section: 9

marketingstatus-definitions.html

MarketingStatus Detailed Descriptions

Maturity Level: 3Standards Status:Trial Use

MarketingStatus


marketingstatus-examples.html

MarketingStatus Examples

Maturity Level: N/AStandards Status:Informative

See MedicinalProductPackaged examples for examples using MarketingStatus.


marketingstatus-mappings.html

MarketingStatus Mappings

Maturity Level: N/AStandards Status:Informative

This page provides mappings for MarketingStatus (see Mappings to Other Standards for further information & status).


marketingstatus.html

MarketingStatus

Maturity Level: 3Standards Status:Trial Use

The MarketingStatus structure defines TODO.

Note: the MarketingStatus structure allows modifier extensions.

Content

Constraints

MarketingStatus is used in the following places:

Interpretation of MarketingStatus in different contexts


mdc.html

Using MDC Codes with FHIR

Maturity Level: 1Standards Status:Trial Use

Summary

Source Medical Device Communications (MDC) codes are from ISO/IEEE 11073-10101 Nomenclature standard and amendments. This is a detailed system of codes used in personal health devices and and acute-care (point-of-care) medical devices for identification of physiological measurements and also for alerts, alarms, and numerous technical conditions such as calibration state and battery state. The physiological measurements can in most common cases be mapped to LOINC if desired using a table of equivalences developed by LOINC. Medical Codes and related values are available from the Rosetta Terminology Mapping Management System (RTMMS), maintained by the U.S. National Institute of Standards and Technology. RTMMS includes new codes in the process of being published in the standard.
SystemThe URI urn:iso:std:iso:11073:10101 identifies the MDC code system.
VersionDate (in FHIR date format YYYY-MM-DD) that this version of the code system was published.
CodeMDC codes are 32-bit unsigned decimal integers where the upper 16 bits are the partition (a usage category - see below) and the lower 16 bits are the term codes. The codes are available as CF_CODE10 in the RTMMS database.
DisplayThe standard provides a Reference Identifier (REFID in RTMMS) for each code, which can placed in this element. If defined, Systematic Name, Common Term, and Acronym are added as designations for use as alternative display
InactiveCodes with status withdrawn (see properties below) are considered inactive
Specification The normative specification is defined in the documents

Copyright Issues

IEEE holds copyright in the standards referenced. IEEE, as part of its support of the RTMMS database and on-going, royalty-free agreement with the NIST, makes these terms available for the development of IEEE11073 compliant products and supporting material (e.g. in user documentation, collateral, etc.). Any use of IEEE terms beyond compliant products and support material may require prior approval from IEEE. Please notify IEEE of any request to use, modify, or reproduce these terms in any manner beyond the permitted use described above. To request permission, please submit your request to stds-ipr@ieee.org.

The following information is provided free of charge to all NIST RTMMS users via the IEEE-SA and NIST Royalty Free Agreement:

(Source: https://rtmms.nist.gov/rtmms/index.htm#!ieee).

Frequently Asked Questions on Use of MDC Nomenclature

Source: 11073.org Our Standards > Conditions of Use

Q. If I am writing a commercial application that takes medical measurements (perhaps from a proprietary device) and transcodes it to an HL7 V2 message or V3 document or FHIR resources using IEEE 11073 nomenclature codes, ref-ids, and descriptions obtained from RTMMS or are my own, am I required to pay any type of fee to IEEE?
A. No. If you wish to obtain the official 11073-10101 standard you will need to purchase that document. However, if you are just interested in using the codes, Ref-ids, and even descriptions, they are freely available in the NIST RTMMS tool.

Q. If I am writing a commercial application that decodes HL7 V2 messages, V3 documents, and FHIR resources, and displays the contents in a human readable form where the descriptions of the codes are my own or are from RTMMS, am I required to pay any type of fee to IEEE?
A. No.

Q. If I make a commercial library with source where one of the source files contains all the codes, ref-id, and descriptions (either my own or from the RTMMS tool) needed for the type of application it supports, am I required to pay any type of fee to IEEE?
A. No.

Q. Am I freely able to use the codes, refids and above descriptions in customer-facing documentation?
A. Yes

Reference Identifiers

Text reference identifiers are given in the standards for each numeric code identifying a concept. Since they were constructed in simple patterns that are usually easy for humans to deduce meanings from, they are convenient for human readers, where the numeric codes are not. They are generally composed of upper case letters such as MDC_ECG_HEART_RATE. The few exceptions are cases that where mixed-case identifiers are familiar to end users, such as identifiers for certain ECG leads.

Partition Codes

The MDC codes are 32-bit, four-byte, integers. The most significant 16 bits are partition codes. Partitions define terminology groups, for example the dimension partition contains all the unit codes. There are currently the following partitions defined:

NameReference IdentifierCode
UnspecifiedMDC_PART_UNSPEC0
Object infrastructureMDC_PART_OBJ1
Supervisory Control And DataAcquisition (SCADA)MDC_PART_SCADA2
EventMDC_PART_EVT3
DimensionMDC_PART_DIM4
Virtual AttributeMDC_PART_VATTR5
Parameter GroupMDC_PART_PGRP6
Body SitesMDC_PART_SITES7
InfrastructureMDC_PART_INFRA8
File Exchange FormatMDC_PART_FEF9
ECG ExtensionMDC_PART_ECG_EXTN10
IDCO ExtensionMDC_PART_IDCO_EXTN11
Disease ManagementMDC_PART_PHD_DM128
Health and FitnessMDC_PART_PHD_HF129
Assisted Independent LivingMDC_PART_PHD_AI130
Return codesMDC_PART_RET_CODE255
External NomenclatureMDC_PART_EXT_NOM256
Device settingsMDC_PART_SETTINGS258
PrivateMDC_PART_PVT1024

Some of the partitions are currently used only for Personal Health Devices (PHDs) such as the Health and Fitness partition. Others, such as the virtual attribute partition, are only used by Point of Care Devices (PoCDs). However, there is nothing in either the 11073-10201, 11073-20601, or 11073-10101 standards that limit the use of any partition to either PoCDs or PHDs

Term Codes

The least significant 16-bits are term codes. While there are only a few partitions, for many of the partitions there are thousands of term codes. The term code, along with the partition, identifies the item. The example below shows a heart rate measurement encoding from an ECG device in XML and JSON:

 <coding>
   <system value="urn:iso:std:iso:11073:10101"/>
   <code value="147842"/>
   <display value="MDC_ECG_HEART_RATE"/>
 </coding>
  coding": [{
    "system": "urn:iso:std:iso:11073:10101",
    "code": "147842",
    "display": "MDC_ECG_HEART_RATE"
  }]

If one converts the code 147842 into HEX, the value becomes 0x24182. The most significant 16 bits indicates that the code comes from the SCADA partition (2) and the term code is 0x4182 or 16770. Implementers can easily obtain the partition and term codes using simple binary AND and SHIFT operations. If one looks up this code in the RTMMS tool one will find an array of information about the code, for example, the term description “Rate of cardiac beats”.

MDC Properties

In addition to the standard properties, the following properties are defined for MDC:
statusCodingLife cycle status of the term code in RTMMS
harmonizedbooleanIndicates whether the term code has been agreed upon during the open consensus-based Rosetta harmonization process
partitioncodePartition is a group for type+types of semantics that are assigned to a contiguous term code range and have a categorical relationship. Partition codes are listed in the table above
Status Property

[Final definitions still to be determined from what's available at RTMMS]

StatusDescription
provisionalTerms with provisional reference identifier and term code that may be used for development and interoperability testing. Provisional terms shall not be released in production devices
approvedTerms that got final approval for inclusion to RTMMS. Approved terms may be used in production devices
zombieProvisional terms that didn't get final approval. Reference identifier and term code will not be allocated to new terms
publishedTerms that are included in in a revision of the IEEE 11073-10101 standard
deprecatedDeprecated terms shall be removed from use in production devices
withdrawnUse of withdrawn terms shall be indicated as an error

medications-module.html

Work Group Standards Status:Informative

Medications Module

Introduction

This module is concerned with resources and functionality in 3 main domains:

Index

Medications

NameDescription
MedicationRequest

Represents an instruction for the administration of medication to a patient - both in the inpatient (hospital) and community setting. It can also include instructions for the dispensing, the reasons why the administration should occur and other data.

It is called an 'Request' to be consistent with other FHIR resources and the workflow pattern, but a common alias for this resource is a 'Prescription' or an 'Order'. The Order itself represents the content of the instruction and is not, by itself, actionable. The workflow process around 'fulfilling' the order is part of the generic FHIR workflow (see below), with the MedicationRequest representing the contents.

MedicationDispense The provision of a supply of a medication with the intention that it is subsequently consumed by a patient (usually in response to a prescription).
MedicationAdministration A record of a patient actually consuming a medicine, or if it has otherwise been administered to them
MedicationStatement This is a record indicating that a patient may be taking a medication now, has taken the medication in the past, or will be taking the medication in the future. The source for this information can be the patient, significant other (such as a family member or spouse), or a clinician. A common scenario where this information is captured is during the history taking process during a patient visit or stay. A medication statement is not a part of the prescribe->dispense->administer sequence, but is a report that such a sequence (or at least a part of it) did take place, resulting in a belief that the patient has received a particular medication. It may be used to construct a patients 'Current Medications' list.
Medication The medication resource represents an actual medication that can be given to a patient, and referenced by the other medication resources. In many cases, this resource is not needed and the drug is indicated by a reference to the appropriate terminology and so can be represented using a codeable concept. In other cases, however, it may be desired to indicate more details than the simple drug (such as the packaging, whether it is a generic medication or the active and inactive ingredients) and so the Medication resource can be used for this.
MedicationKnowledge The MedicationKnowledge resource is draft and is included for comment purposes. This resource represents information about a medication, for example, details about the medication including interactions, contraindications, cost, regulatory status, administration guidelines, etc.

Immunizations

NameDescription
Immunization The Immunization resource is intended to cover the recording of current and historical administration of vaccines to patients across all healthcare disciplines in all care settings and all regions. This includes immunization of both humans and animals, but does not include the administration of non-vaccine agents, even those that may have or claim to have immunological effects.
ImmunizationRecommendation A patient's point-in-time immunization and recommendation (i.e. forecasting a patient's immunization eligibility according to a published schedule) with optional supporting justification
ImmunizationEvaluation The ImmunizationEvaluation resource is intended to cover communicating the results of an evaluation of a vaccine administration event (documented using the Immunization resource) against a set of published recommendations (protocols).

Common Use Cases

Other resources

There are other resources that are of particular interest in the medication domain.

Security and Privacy

As with all clinical data, Medications (in particular) can be sensitive information as specific medications can indicate the presence of private information such as mental health disorders or HIV. However, withholding information about what medications a person is taking can lead to catastrophic results, and so needs to be considered very carefully. At the least, a clinician should be made aware that there is information available that they have not been given when making clinical decisions.

For more general considerations, see the Security and Privacy module.

Developmental Roadmap

The Pharmacy workgroup has plans to improve all existing resources e.g. adding in features that support detailing our conditional orders in a structured way; evaluating requirements for supporting drug formularies and medication knowledge. This work is expected to include the development and approval of a new resource and may involve updates to the Medication Resource.


messaging.html

Messaging using FHIR Resources

Maturity Level: 3Standards Status:Trial Use

FHIR Resources can be used in a traditional messaging context, much like HL7 v2 (see detailed comparison). Applications asserting conformance to this framework claim to be conformant to "FHIR messaging" (see Conformance).

In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens. Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request.

The events supported in FHIR, along with the resources that are included in them, are defined below.

The destination application processes the request and returns one or more response messages which are also a bundle of resources identified by the type "message", with the first resource in each bundle being a MessageHeader resource with a response section that reports the outcome of processing the message and any additional response resources required.

Basic Messaging Assumptions

This specification assumes that content will be delivered from one application to another by some delivery mechanism, and then one or more responses will be returned to the source application. The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, HTTP based transfer, MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else. The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request. This specification considers the source and destination applications as logical entities, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification, though this specification does provide a direct delivery mechanism below.

The agreements around the content of the messages and the behavior of the two applications form the "contract" that describes the exchange. The contract will add regional and local agreements to the rules defined in this specification.

This specification ignores the existence of interface engines and message transfer agents that exist between the source and destination. Either they are transparent to the message/transaction content and irrelevant to this specification, or they are actively involved in manipulating the message content (in particular, the source and destination headers are often changed). If these middleware agents are modifying the message content, then they become responsible for honoring the contract that applies (including applicable profiles) in both directions.

A key aspect of a message is the impact of its content:

Some Events defined by FHIR are assigned to one of these categories, but others are not able to be categorized in advance, and the category must be determined by the content, context, or use case.

Example: Elevation from Notification to Consequence

When it is necessary to receive an acknowledgement from multiple parties for a message of notification it becomes a message of consequence: The sender will have to send multiple messages, even if they have the same endpoint.

Implication to Receiver

Another key aspect of a message is the impact of its destination.receiver. In some circumstances it may be sufficient to direct a message to an endpoint, while in others it may be necessary to direct the message to a specific organization or person.

ConsequenceA message of consequence SHOULD have one and only one receiver specified.
CurrencyA message of currency MAY have one or more receivers specified.
NotificationA message of currency MAY have one or more receivers specified.

Message Exchange Patterns

Each FHIR request message has one or more response messages. There must be at least one response message so that the sender can know that the message was properly received. Multiple response messages SHALL NOT be returned for messages of consequence, and SHOULD not be returned for notifications.

In principle, source applications are not required to wait for a response to a transaction before issuing a new transaction. However, in many cases, the messages in a given stream are dependent on each other, and must be sent and processed in order. In addition, some transfer methods may require sequential delivery of messages.

Synchronous

For this reason, a synchronous exchange pattern - where the sender sends a message, and waits on the same channel for a single response, and then sends the next message - is the easiest to understand and manage:

This kind of messaging exchange is the most common because it's the simplest to understand.

Asynchronous

However synchronous message exchange does not cater for multiple response messages, which may arise when processing queries, and also imposes through-put limitations which may become relevant at high volumes. Additionally, it might not be practical or appropriate to wait for response messages. In these cases, the asynchronous message pattern should be used.

In Asynchronous messaging, the server acknowledges receipt of the message immediately, and responds to the sender separately. The server may respond more than once to any given message.

When a message is received, a receiver can determine from the content of the message header whether it's a new message to process, or a response to a message that has already been sent. Note that asynchronous messaging can be harder to implement due to the amount of complexity opposed to synchronous messaging; more can go wrong. This specification does not dictate any particular error handling protocols or responsibilities; these are left to trading partner agreements between implementers.

MessageHeader Identifiers & Timestamps

An incoming message contains two identifiers: the Bundle.id and the MessageHeader.id. Each time a new message is created, it SHALL be assigned an identifier (MessageHeader.id) that is unique within that message stream. Note that since message streams are often merged with other streams, it is recommended that the identifier should be globally unique. This can be achieved by using a UUID or an OID. Each time a message is sent, the Bundle.id should be changed to a new value.

When a receiver receives and processes the message, it responds with a new message with a new identifier, wrapped in a bundle which also has a new id. The response message also quotes the request MessageHeader.id in MessageHeader.response.identifier so that the source system can relate the response to its request.

A message has 2 important timestamps:

In addition, the message may have additional timestamps in additional resources in the message, either .meta.lastUpdated or others throughout the resources. The meaning of these will depend on the message event.

Absence of Reliable Messaging

Some of the message delivery mechanisms mentioned above are reliable delivery systems - the message is always delivered, or an appropriate error is returned to the source. However most implementations use methods which do not provide reliable messaging, and either the request or the response can get lost in transit. FHIR messaging describes a simple approach that receivers SHOULD conform to in order to handle the absence of reliable messaging that maintains predictable functionality.

If the sender of the message implements reliable messaging, it SHALL do the following when it receives no response to a message within a configured timeout period based on the value specified in the CapabilityStatement messaging.event.category for the event associated with the message:

ConsequenceResend the same message (with the same MessageHeader.id) with the same Bundle.id
CurrencyResend the same message (with the same MessageHeader.id) with a different Bundle.id
NotificationResend the same message (with the same MessageHeader.id) with a different Bundle.id

When a receiver implements reliable messaging, it SHALL check the incoming Bundle.id and MessageHeader.id against a cache of previously received messages. The correct action to take depends on what is received:

Both the Bundle.id and MessageHeader.id have not been receivedThis is the normal case, and the message should be processed
Both envelope and message already receivedThe original response has been lost (failed to return to the request issuer), and the original response SHALL be resent
The MessageHeader.id has already been received, but the Bundle.id is newA previously seen message has been resubmitted for processing again. The server may either reprocess the message, or reject the message
The Bundle.id has already been received, but the MessageHeader.id is newThis is an error - Bundle.id values should never be reused

The duration period for caching does generally not need to be very long. At a minimum, it could be 1 minute longer than the timeout of the sending system, though it may need to be longer depending on the re-sending policies of the sending system.

Applications that implement reliable messaging declare their reliable cache period in their Capability Statement.

Example: Consequence

In the first example, a Clinical EHR issues an order for a particular imaging examination to be performed on a patient. This is considered to be a message of Consequence: multiple orders should not be created (in practice there are usually human review processes that catch multiple orders, but repeat orders create entropy in the system that is harmful). The EHR sends a message where the Bundle.id is UUID 1 (72edc4e0-6708-42ab-9734-f56721882c10), with a MessageHeader.id of UUID 2 (dad53a57-dcb4-4f18-b066-7239eb4b5229).

The EHR system never receives a response to the message; it does not know whether the request message got lost, or the imaging management systems was unable to process the request, or whether it successfully processed the message and the response was lost. In this case, the EHR system resends the message with same two identifiers.

In this case, the imaging system successfully received the message, and processed it. Because it receives the resent order after 1 minute (which is within its 15 minute cache time), and the two UUIDs 1 and 2 match a message it has already processed, it knows that it already processed the order, and simply returns the previous response. In the case of additional resent queries, the application keeps sending the original response, though it may also alert system administrators that the same original message keeps being resent, since lost messages should be a rare occurrence.

When the EHR system finally receives the message, it knows how the imaging management system responded; it can be sure because the message id from the original request is echoed in the response portion of the returned message.

Example: Currency

In this second example, a Clinical EHR needs to know what appointment slots are available for a particular imaging procedure. This is a message of Currency: available slots are ever disappearing, and ordering a slot that has become unavailable is a waste of time for the humans and systems involved. The EHR sends a message where the Bundle.id is UUID 3 (4c7f5cb2-5964-4d42-b719-e0227461818c), with a MessageHeader.id is UUID 4 (63ed7d68-b2cc-421d-ba1c-a6c7785581f2).

The EHR system never receives a response to the message; it does not know whether the request message got lost, or the imaging management systems was unable to process the request, or whether it successfully processed the message and the response was lost. In this case, the EHR system resends the message with same MessageHeader.id (UUID 4), but creates a new Bundle.id (c7c17fe4-9560-49c7-b2ae-42636476fb86).

In this case, the imaging system successfully received the message, and processed it. When it receives the resent order after 1 minute (which is within its 15 minute cache time), it sees that although the message id is the same, the Bundle.id has changed, and it reprocesses the message again, and sends a new response.

When the EHR system finally receives the message, it knows the current slot availability on the imaging management system responded.

Note that the existence of active intermediaries (or "middleware") creates the need for this protocol - the original sender matches the response to the request based on the MessageHeader.id, and so an active intermediary that choose the re-initiate a query that it previously relayed cannot change the MessageHeader.id. This protocol avoids the need for the MessageHeader.id to change, and only requires change to the Bundle.id which is never the basis for context linking outside the immediate message exchange protocol described here.

Capability Statement

Applications may only assert conformance to "FHIR messaging" if they publish a Capability statement so the claim may be verified. A Capability statement lists all the message events supported (either as sender or receiver) and for each event, a profile that states which resources are bundled (sender), or are required to be bundled (receiver), and any rules about the information content of the individual resources.

$process-message

The simplest way to handle messages where there are also RESTful interactions occurring is to use the $process-message. This operation accepts a message, processes it according to the definition of the event in the message header, and returns a one or more response messages. See the opreation definition for further details.

Relationship between Messaging and REST

As well as this messaging framework documented here, FHIR also defines a RESTful API. The messaging and RESTful frameworks are related in that both share the same set of resources on which they operate. In fact, the basic MessageHeader resource that the messaging framework is implemented is itself a resource that can treated in a RESTful approach.

The kinds of functionality that the RESTful API and the messaging framework offer are very similar; their primary difference is architectural in nature.

For instance, the messaging framework defines an event for notifying that an administration resource has been created or updated; the REST API offers similar services (history and Subscription). On the other hand, there are differences in the capabilities offered - while a patient merge can be implemented as a series of RESTful operations performed by the client that update all resources linked to the patient, when a message command to merge patient records is processed, the server will do all the work, and is also able to merge in areas not exposed on the RESTful API. The REST API, however, provides a set of basic operations on all resources that would need special definitions in the messaging framework - definitions that are not provided.

There is no expectation that RESTful systems will need to offer messaging support, or vice versa, though systems may find it useful to support both sets of functionality in order to satisfy a wider range of implementers.

As a resource that can be used with the RESTful framework, the MessageHeader resource has the normal resource end-point (/MessageHeader), which is used to manage a set of static message resources. This could be used to make an archive of past messages available. Creating or updating MessageHeader resources in this fashion does not represent the actual occurrence of any event, nor can it trigger any logic associated with the actual event. It is just for managing a set of message header resources.

Asynchronous Messaging using the RESTful API

It is possible to exchange messages using the RESTful end-point as a central point of exchange. This is not particularly efficient compared to other methods, but is useful for low-volume asynchronous exchange.

To send a message, a sender posts the message bundle to the /Bundle end-point, with a uri that identifies the receiver at MessageHeader.destination.endpoint. The RESTful server accepts the bundle, stores it as a single bundle, and indexes it on the MessageHeader.

To receive messages, a receiver searches for all messages destined for itself, since its last check:

 GET [base]/Bundle?message.destination-uri=[rcv]&_lastUpdated=>2015-03-01T02:00:02+01:00

The receiver works through the response, processing each message. As each message is processed, the receiver creates a response message, reversing the source and destination, and posts it back to the server.

To check for responses, the original sender searches for response messages destined for itself, since its last check:

 GET [base]/Bundle?message.destination-uri=[snd]&message.response-id:missing=false
      &_lastUpdated=>2015-03-03T06:03:522+01:00

This lightweight protocol needs ongoing administration to ensure that multiple parties do not interfere with each other by re-using the same system identifier (and against malicious attack).

Defining Events

The message.code element carries a Coding that identifies the event that the message conveys.

Events may be defined using the MessageDefinition resource. This specification does not define any events, but may do so in the future if implementers find this useful.

Invoking Operations via Messages

A message can be used to invoke an operation as defined for a RESTful interface using an operation definition. To invoke an operation using a message:

The recipient executes the operation as specified, and then:

Here's an example:

<Bundle xmlns="http://hl7.org/fhir">
  <id value="urn:uuid:77831928-2a35-4c08-9496-8232323bf48c"/>
  <!-- normal bundle stuff -->
  <entry>
    <fullUrl value="urn:uuid:6080d4a7-5e05-45dc-96d5-f75329564d1f"/>
    <resource>
      <MessageHeader>
			  <id value="cac8143e-6138-4f45-b086-bb8ebf976aae">
        <!-- normal message header stuff -->
        <event>
          <system value="urn:ietf:rfc:3986"/>
          <!-- value set expansion -->
          <code value="http://hl7.org/fhir/OperationDefinition/ValueSet-expand"/>
        </event>
        <!-- more normal message header stuff -->
        <data>
          <reference value="urn:uuid:00213637-dc7c-40d2-a7de-f4ef1eea5685"/>
        </data>
      </MessageHeader>
    </resource>
  </entry>
  <entry>
    <fullUrl value="urn:uuid:00213637-dc7c-40d2-a7de-f4ef1eea5685"/>
    <resource>
      <Parameters>
        <parameter>
          <name value="identifier"/>
          <valueUri value="http://hl7.org/fhir/ValueSet/identifier-type"/>
        </parameter>
      </Parameters>
    </resource>
  </entry>
</Bundle>

Note that there's no way to anchor the execution of the operation against a URL. The only operations that can be executed in this way are defined to be executed at the System or Resource level for a particular resource.

Invoking Search via Messages

In the same way that a defined operation can be invoked, a regular search operation can be invoked. This also uses the Parameters resource, with the following rules:

Search Parameter Type Data Type
number integer
date dateTime
string string
token string or Coding (split the system and code apart)
reference uri
composite string
quantity string or Quantity (split the syntax out)
uri uri

Here's an example:

<Bundle xmlns="http://hl7.org/fhir">
  <id value="urn:uuid:77831928-2a35-4c08-9496-8232323bf48c"/>
  <!-- normal bundle stuff -->
  <entry>
    <fullUrl value="urn:uuid:c466754c-09c0-4f59-9f76-a48bd0ea27c9"/>
    <resource>
      <MessageHeader>
        <!-- normal message header stuff -->
        <event>
          <system value="http://hl7.org/fhir/restful-interaction"/>
          <!-- Search against Patient -->
          <code value="search-type"/>
        </event>
        <!-- more normal message header stuff -->
        <data>
          <reference value="urn:uuid:59a17a19-46eb-42d9-821a-f93a0c530cac"/>
        </data>
      </MessageHeader>
    </resource>
  </entry>
  <entry>
    <fullUrl value="urn:uuid:59a17a19-46eb-42d9-821a-f93a0c530cac"/>
    <resource>
      <Parameters>
        <parameter>
          <name value="resourceType"/>
          <valueString value="Patient"/>
        </parameter>
        <parameter>
          <name value="gender"/>
          <valueString value="m"/>
        </parameter>
      </Parameters>
    </resource>
  </entry>
</Bundle>

metadatatypes-definitions.html

Metadata Types - Detailed Descriptions

Maturity Level: 4Standards Status:Partially Normative

Table of Contents

ContactDetail Contributor DataRequirement ParameterDefinition
RelatedArtifact TriggerDefinition Expression UsageContext

ContactDetail

See also Base Definition, Examples and Mappings.

Contributor

See also Base Definition, Examples and Mappings.

DataRequirement

See also Base Definition, Examples and Mappings.

ParameterDefinition

See also Base Definition, Examples and Mappings.

RelatedArtifact

See also Base Definition, Examples and Mappings.

TriggerDefinition

See also Base Definition, Examples and Mappings.

Expression

See also Base Definition, Examples and Mappings.

UsageContext

See also Base Definition, Examples and Mappings.


metadatatypes-examples.html

MetaData Types - Examples

Maturity Level: 4Standards Status:Informative

Table of Contents

ContactDetail Contributor DataRequirement ParameterDefinition
RelatedArtifact TriggerDefinition Expression UsageContext

ContactDetail

See also Base Definition, Detailed Descriptions and Mappings.

For ContactDetail examples, see the examples in Library, Measure, and PlanDefinition.

Contributor

See also Base Definition, Detailed Descriptions and Mappings.

For Contributor examples, see the examples in Library, Measure, and PlanDefinition.

DataRequirement

See also Base Definition, Detailed Descriptions and Mappings.

For DataRequirement examples, see the examples in Library, Measure, and PlanDefinition.

ParameterDefinition

See also Base Definition, Detailed Descriptions and Mappings.

For ParameterDefinition examples, see the examples in Library, Measure, and PlanDefinition.

RelatedArtifact

See also Base Definition, Detailed Descriptions and Mappings.

For RelatedArtifact examples, see the examples in Library, Measure, and PlanDefinition.

TriggerDefinition

See also Base Definition, Detailed Descriptions and Mappings.

For TriggerDefinition examples, see the examples in PlanDefinition.

Expression

See also Base Definition, Detailed Descriptions and Mappings.

For Expression examples, see the examples in PlanDefinition.

UsageContext

See also Base Definition, Detailed Descriptions and Mappings.

For UsageContext examples, see the examples in Library, Measure, and PlanDefinition.


metadatatypes-mappings.html

Metadata Types - Mappings

Maturity Level: 4Standards 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

ContactDetail Contributor DataRequirement ParameterDefinition
RelatedArtifact TriggerDefinition Expression UsageContext

ContactDetail

See also Base Definition, Examples and Detailed Descriptions.

Contributor

See also Base Definition, Examples and Detailed Descriptions.

DataRequirement

See also Base Definition, Examples and Detailed Descriptions.

ParameterDefinition

See also Base Definition, Examples and Detailed Descriptions.

RelatedArtifact

See also Base Definition, Examples and Detailed Descriptions.

TriggerDefinition

See also Base Definition, Examples and Detailed Descriptions.

Expression

See also Base Definition, Examples and Detailed Descriptions.

UsageContext

See also Base Definition, Examples and Detailed Descriptions.


metadatatypes.html

MetaData Types

Maturity Level: 4Standards Status:Partially Normative

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 Contributor DataRequirement ParameterDefinition
RelatedArtifact TriggerDefinition Expression UsageContext

For an index of all data types, see the Data types page.

ContactDetail

See also Examples, Detailed Descriptions and Mappings.

The ContactDetail structure defines general contact details.

Constraints

ContactDetail is used in the following places:

Interpretation of ContactDetail in different contexts

 

Contributor

See also Examples, Detailed Descriptions and Mappings.

Constraints

Contributor is used in the following places:

Interpretation of Contributor in different contexts

 

DataRequirement

See also Examples, Detailed Descriptions and Mappings.

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

Constraints

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="performedPeriod"/>
		<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="performedPeriod"/>
		<path value="performedDateTime"/>
	</dateFilter>
</dataRequirement>

DataRequirement is used in the following places:

 

ParameterDefinition

See also Examples, Detailed Descriptions and Mappings.

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.

Constraints

 

RelatedArtifact

See also Examples, Detailed Descriptions and Mappings.

The RelatedArtifact structure defines resources related to a module such as previous and next versions of documents, documentation, citations, etc. Note that the name resource here is being used in a more general sense than the FHIR-specific Resource. The related resource may be a FHIR resource, or it may be another type of resource, represented using the Attachment data type.

Constraints

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:

Interpretation of RelatedArtifact in different contexts

 

TriggerDefinition

See also Examples, Detailed Descriptions and Mappings.

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:

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

Constraints

TriggerDefinition is used in the following places:

 

Expression

See also Examples, Detailed Descriptions and Mappings.

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.

Constraints

Expression is used in the following places:

 

UsageContext

See also Examples, Detailed Descriptions and Mappings.

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

Constraints

UsageContext is used in the following places:

Interpretation of UsageContext in different contexts