View raw Markdown
type: resourceresource: PackagedProductDefinition

PackagedProductDefinition

Introduction

Scope and Usage

For an overview of this resource and others in the Medication Definition domain, also see the module page

A medically related item or items of any type, in a container or package, representing the unit that has been prepared for sale, supply, shipping or storage. These can include packaged medications, devices and other items such as food, biologicals, raw materials, cosmetics, medical fluids, gases etc. This resource represents the whole package of items, and all the packaging within, rather than the individual items themselves and may contain other packages (parent/child relationships). In some cases a "product" exists at exists at logically different levels, and therefore has a variety of available packages associated with it. Typically the packages are associated with different sizes/quantities.

This resource is usually used with MedicinalProductDefinition, via the productFor relationship. For cases where only a subset of PackagedProductDefinition is need in a product, use as a contained resource to MPD may be appropriate. See MedicinalProductDefinition for an example.

Consistent representation of different package aspects

The PackagedProductDefinition resource covers two main areas - package types that exist for a product (linked via productFor), and the packaging within those packages.

These can be thought of as the "package type" and the "packaging" respectively. The package type is covered by the PackagedProductDefinition class and the packaging by the Package backbone element (broadly the left and right of the UML model). It is possible to leave either part un-populated.

A package type can be documented without needing to say in detail what physical packaging or items are within it. This is common in many drug dictionaries, which list package types, but not their internals.

Conversely it is possible to only populate the Package backbone, and child classes, to cover packaging of an item but not say anything about the product outer packaging or the overall package that will eventually be on sale. This would be appropriate when focusing on the physical product and the inner packaging, perhaps at a manufacturing stage, without needing to populate package details not relevant (or not existing) at that phase.

Other implementations will use both "halves". A single application could start by using the Package class for packaging and then populate the package type data later on.

It is very important that a consistent representation is used. Packaging always uses the Package backbone, whether or not there are any package type properties documented. A diagram of this is shown on the Medication Definition module page.

Recursive relationships in this resource

This resource has two recursive relationships. One is primarily intended to be "internal" to the package - for package layers and contents, and the other for aggregated packages (e.g. for wholesaling) that are made up of other packages.

Feedback
In order to properly meet all packaging uses cases, consistent representation of different package information and recursive relationships are aspects of this resource that BR&R workgroup are particularly seeking implementation feedback on. (Comments links are found at the bottom of each page.)

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-PackagedProductDefinition-packs.xml

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

<List xmlns="http://hl7.org/fhir">
  <id value="PackagedProductDefinition-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

packagedproductdefinition-fivews-mapping-exceptions.xml

Unmapped Elements