View raw Markdown
type: resourceresource: NutritionOrder

NutritionOrder

Introduction

Scope and Usage

Note to Balloters: To ensure this resource is ready for Normative status, we are seeking ballot comment on the substantive content. The key changes made since R5 include:

  • Removed the instantiates workflow elements NutritionOrder.instantiatesCanonical, NutritionOrder.instantiatesUri and NutritionOrder.instantiates; and advise implementers to use the workflow instantiates extensions
  • Renamed NutritionOrder.orderer to NutritionOrder.requester to align with the workflow pattern
  • Renamed NutritionOrder.oralDiet.texture.foodType to NutritionOrder.oralDiet.texture.type
  • Removed NutritionOrder.oralDiet.fluidConsistencyType
  • Added NutritionOrder.oralDiet.caloricDensity and NutritionOrder.supplement.caloricDensity
  • Updated NutritionOrder.enteralFormula backbone
  • Pulled NutritionOrder.additive into its own backbone (previously part of NutritionOrder.enteralFormula)

Note to Implementers: For an overview of this resource and others in the Nutrition domain, also see the module page.

The NutritionOrder resource describes a request for oral diets (including general diets such as General Healthy diet, or therapeutic diets such as Consistent Carbohydrate, 2-gram Sodium, or Fluid Restricted), oral nutrition supplements (such as nutritionally complete pre-packed drinks), enteral nutrition (tube feedings) and infant formula which govern the distribution of food and nutritional products used to feed patients within a patient setting. It does not cover orders for parenteral (IV) nutrition which are typically filled by pharmacy. These nutrition orders are combined with information on a patient's food allergies and intolerances, and ethnic or cultural food preferences (e.g. Kosher or Vegetarian) to inform healthcare personnel about the type, texture, and/or quantity of foods that the patient should receive or consume.

Enteral orders are distinguished from supplements because they have some unique attributes and typically include administration information whereas oral nutritional supplements may simply be supplied (e.g. home health or outpatient settings). In a simple case, the requestor may designate the type of product, product name, and the route of administration along with free text instructions without having to complete the additional structured details.

This resource is intended to be used by practitioners from a variety of specialties such as physicians, dietitians/nutritionists, or speech therapists. One practitioner may simply order a base element oral diet such as General Healthful diet. Another practitioner, based on the scope of practice, may use other elements to communicate additional therapeutic needs or patient preferences. The optionality included gives an ordering practitioner the capability to write a simple order for an oral diet, nutritional supplement or formula with minimal requirements beyond that of specifying the diet, supplement or formula product, but also supports the ability to provide more detailed information that may be further augmented by a dietitian or nutrition specialist. For example, a physician may order a 2 g sodium diet. A speech therapist, based on the results of a swallowing evaluation, then orders an International Dysphagia Diet Standardisation Initiative Framework - Soft and Bite-Sized Level 6 food (regime/therapy).

Boundaries and Relationships

The NutritionOrder resource is used for requesting oral diets, oral nutrition supplements, enteral feedings, and infant formula. The MedicationRequest resource should be used for requesting parenteral (IV) nutrition and prescribing dietary supplements such as vitamin or mineral supplements.

The Nutrition Order is a record of the request for the supply of a diet, oral supplement, enteral formulas, and infant formula for a patient. However, to initiate the request requires the use of the Task resource and its associated workflow with the Nutrition Order referenced from Task.basedOn, or by using the nutrition Task resource in the context of a messaging or service workflow where the request is explicit or implicit. For further information about this separation of responsibilities, refer to the Fulfillment/Execution section of the Request pattern.

Notes

Notes:

Enteral continuous vs. intermittent tube feedings

Tube feedings can be administered via continuous drip using a pump or via intermittent feedings, using gravity drip or a pump. The examples Nutrition Order Enteral Bolus Feeding Example and Nutrition Order Enteral Cycled Feeding Example show how this resource can be used to order both kinds of enteral feeding using the structured data elements. The continuous feeding typically specifies rate of administration and a maximum volume of delivery using the enteralFormula.administration.rate and enteralFormula.maxVolumeToDeliver elements. On the other hand, the intermittent feeding typically specifies the amount and frequency of administration using the enteralFormula.administration.quantity and enteralFormula.schedule elements. In both cases, to vary the rate or quantity over time the enteralFormula.administration element can be repeated.

Note about the examples

The examples associated with this resource demonstrate the core elements and do not necessarily reflect real-world implementations that may be constrained by future profiles for a given implementation or setting. For example, a renal diet is often comprised of pre-coordinated components including common nutrient modifications such as protein, potassium and phosphorus to assist with the speed of entry of complex diet orders.

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-NutritionOrder-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="NutritionOrder-core"/>
  <version value="0.1"/>
  <name value="NutritionOrderHL7Extensions"/>
  <title value="Nutrition Order  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2017-10-18T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - Orders and Observations WG"/>
  <description value="Defines common extensions used with or related to the NutritionOrder resource"/>
</ImplementationGuide>

Resource Packs

list-NutritionOrder-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="NutritionOrder-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/NutritionOrder-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

nutritionorder-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

nutritionorder-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=The Identifier.type element can be to indicate filler vs. placer if needed. This is explained in further detail here.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=Typically the system placing the order sets the status to "requested". Thereafter, the order is maintained by the receiver that updates the status as the request is handled. This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy.

Unmapped Elements