Common Product Model
 HL7 CCPM, R1 HL7 Version 3 Standard: Common Product Model CMETs, DSTU Release 11 June 2011 |
HL7 CCPM, R1 HL7 Version 3 Standard: Orders; Substances CMETs, DSTU Release 11 June 2011 |
| Responsible Group | Orders and Observations Work Group HL7 |
| Co-Chair, CPM Project and Orders and Observations Workgroup | Hans Buitendijk |
| Editor, Modeling Facilitator, and Co-Chair, Orders and Observations Workgroup | Gunther Schadow |
| Modeling Facilitator | Mead Walker |
HTML Generated: 2012-08-31T12:07:10
Content Last Edited: 2011-06-14T14:26:17
HL7® Version 3 Standard, © 2011 Health Level Seven® International All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
Table of Contents
Preface
i HL7 Draft Standard for Trial Use
ii Notes to Readers
iii Changes from Previous Release
iv Message Design Element Navigation
1 Overview
1.1 Introduction & Scope
1.2 Domain Information Models
2 ProductKind Topic
2.1 Introduction
2.2 Storyboards
2.3 Refined Message Information Models
2.4 Hierarchical Message Descriptions
3 ProductInstance Topic
3.1 Introduction
3.2 Storyboards
3.3 Refined Message Information Models
3.4 Hierarchical Message Descriptions
4 ProductEstablishment Topic
4.1 Introduction
4.2 Refined Message Information Models
4.3 Hierarchical Message Descriptions
5 ProductEvent Topic
5.1 Introduction
5.2 Refined Message Information Models
5.3 Hierarchical Message Descriptions
6 ProductInformation Topic
6.1 Introduction
6.2 Refined Message Information Models
6.3 Hierarchical Message Descriptions
7 ProductUseGuideline Topic
7.1 Introduction
7.2 Refined Message Information Models
7.3 Hierarchical Message Descriptions
8 DeviceActDefinition Topic
8.1 Introduction
8.2 Refined Message Information Models
8.3 Hierarchical Message Descriptions
9 Substance Topic
9.1 Introduction
9.2 Refined Message Information Models
9.3 Hierarchical Message Descriptions
10 SubstanceSpecification Topic
10.1 Introduction
10.2 Refined Message Information Models
10.3 Hierarchical Message Descriptions
11 Quality Analysis Report Topic
12 CMETs Used by this Domain
13 Glossary
This is a Draft Standard for Trial Use of the Version 3 Common Product Model CMETS, DSTU Update Release 10 topic. This material was approved as a DSTU following a successful DSTU ballot during HL7 International's May 2010 ballot cycle.
"Publication of this draft standard for trial use and comment has been approved by Health Level Seven, Inc. (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 18 months from the date of publication. Suggestions for revision should be submitted at //www.hl7.org/dstucomments/index.cfm.
Following this 18 month evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard
The Common Product Model has been developed to address common data requiremements across the areas (publishing domains) within HL7 that address product related information. The domains of interest include:
- Pharmacy: The model content draws heavily on the Pharmcy DMIM, and includes the contents used to support medication information. It is expected that a CMET or CMETs will be developed to meet pharmacy needs.
- Immunization: It is expected that, if medication data requirements are properly modeled that the data requirements for immunization messaging will be satisfied as well.
- Patient Safety: The model contents draws heavily on the Individual Case Safety Report (ICSR). The included CMET provides a representation of the data needed to represent the product information contained within the ICSR.
- Structured Product Labeling The model content draws heavily on theSPL RMIM model, and includes the contents used to support labeling reporting. It is expected that a CMET or CMETs will be developed to meet SPL needs.
- Stability Reporting The model content includes the structures and attributes needed to support product information for stability reporting. The creation of a CMET to support the needs of this reporting is expected to be explored.
- Billing and Accounts Currently, the Billable Clinical Product CMET contains relevant product related information. The project will explore the extent to which additional content is needed to fully support this area.
- Image Integration A ballot commenter suggested that messaging in this area needs to pass information about items of durable equipment such as imaging devices. The project will explore the extent to which additional content is needed to fully support this area.
- Substances There is now two topics dedicated to the definition and specification of substances (small molecules, polymers, proteins, nucleic acid, natural mixtures and complex substances).
In addition, the project team is open to contributions based on the work of standards organizations external to HL7. In this context, reference has been made to the ISO project "Identification of Medicinal Products" (IDMP, which includes efforts under the auspices of CEN, NEMA/MITA, COCIR, JIRA). Contributions from those working on the prEN ISO 11615, 11616,11240,11239, 11589, 11238 and 15XXXicsr efforts within the context of ISO TC 215, WG6 have been considered and discussed with those participants.
This version of the Common Product Model is a major re-factoring of the previous version. It breaks the model into several compoenents or modules which are presented in separate topics. Each topic yields multiple CMETs.
This version also has all the definitions that were formally only "collated" from various pre-existing definitions compiled and merged into one.
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
Domain Overview
The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models. Accomplishing this goal requires that the committees involved reach full agreement on the content of the models, as well as the resolution of concrete issues raised by the construction of common reusable structures.
Within the the context of this model, a "product" is defined in a broad fashion as "any material item or substance that can be offered to a market that might satisfy a want or need. However, items produced and consumed at home are also included" Such a broad definition is used to satisfy the needs of health care in which a wide range of individual items, ranging from drugs through biologic entities to devices, is used to treat disease and other health conditions. Broadness is also required to address safety (adverse event) reporting in which reports are received related to items including drugs, biologic products, food and food supplements, medical devices, cosmetics, veterinary feed, etc.
The model content includes the structures and attributes needed to support product information for medical devices (including imaging devices). The creation of a CMET to support the needs of this reporting is expected to be explored.
However, even given such a broad description, the scope of this product model is limited to those products that are used within healthcare, or for which information is collected in situations relevant to individual and public health.
The domain includes a Common Product Domain Messaging Information Model (DMIM) that is intended to express a pattern that can be used by the HL7 V3 messages that have a requirement to identify and represent products. This would include, for example, medications in the Pharmacy messages, or medications and other product types in the Individual Case Safety Report (ICSR messages). The normative content of the model will be represented by Common Message Element Types (CMET) that will be directly usable in other HL7 specifications.
The project has the following goals and deliverables:
- The creation of a Common Product Model, which takes into account all the current product-like models used in V3 messages - for example SPL (Structured Product Label), ICSR, Immunization and Pharmacy.
- Identification of the versions of the appropriate product-like models used
- To identify common class names where applicable and determine if a name change can be done, with the understanding of the potential impact to backwards compatibility for existing standards.
- To define one or more CMETs that can be used to represent product information within those HL7 models that need to represent product information
|
||||||||||||||||||||||||||||||||||
|
Diagram
The model includes information for a kind of product. For the most part, this includes all products of a particular type produced by a given manufacturer. For regulated medicinal products it includes all the products produced as authorized by a particular approval. Within this section, information is defined regarding the product itself, the substances it is comprised of (including moiety information), different ways of classifying the product and identifying equivalents, and container and packaging information. The role relationships between the entity classes show make it possible to show the substances contained within the product, whole part relationships for assembled products, and the relationship between containers and the products or other containers packed within them. In addition, this section allows the recording of administrative guidelines, monitoring programs, policies, regulatory approvals, marketing activities, and documents associated with the product type.
Please note that the model developers intend to include class and attribute descriptions within the model. Due to limitations associated with current tooling, these will be found in association with the CMETs drawn from the domain model.
Diagram
This section includes information on individual products, and product lots. This includes instance specific information such as expiration date and lot number, as well as software version information for device instances. It also includes information about the container(s) for product instances. The section also addresses information about production/disposition and transportation of products. The notion of product event is designed to support the recording of information about a product's production, and final disposition. Transportation events make it possible to track the movement of a product from the place of production to that of consumption. Investigation events cover the situation in which a product is returned to the manufacturer for investigation after a product defect or product related adverse event has been recorded.
Please note that the model developers intend to include class and attribute descriptions within the model. Due to limitations associated with current tooling, these will be found in association with the CMETs drawn from the domain model.
Diagram
The section contains information about organizations that are identified as manufacturers, as marketing authorization holders, or playing other roles with regard to the development, production, and transportation of products.
Please note that the model developers intend to include class and attribute descriptions within the model. Due to limitations associated with current tooling, these will be found in association with the CMETs drawn from the domain model.
Diagram
Specifies the sorts of Events and Activities that are tracked from the perspective of the product (rather than the patients receiving the product.) The set of acts is not intentionally limited, notably, SubstanceAdministration and Supply could be specializations for such purposes as product utilization reporting or monitoring.
Diagram
This section contains a variety of additional product information (characteristics), and a reference to a product document which serves to indicate a "version" of a product description. There are also representations of product activities such as regulatory actions (approvals), marketing activity, and policies and programs under which the distribution and use of the products may be controlled.
Diagram
Descriptions of how a product should be used safely and effectively.
There are currently 2 competing models in HL7, first was Structured Product Modeling (SPL) release 2 (in 2004), then in 2009 was a second model approved by the pharmacy committee (spearheaded for use in Canada.) Currently the best that can be done to arrive at a single harmonized standard is to provide an alternative between these 2 variants.
Diagram
Diagram
Describes when and how a product should be used safely and effectively. Contains the dosing instructions, indication, issues (adverse effects, interactions, contraindications), and a safe use protocol which includes monitoring observations.
Diagram
Description of the services (actions) that a device performs, such as observation definitions for devices that produce observation results, but treatment or intervention actions (and usually in combination with observations) are also possible.
The Device Act definition choice is the extension point to support in vitro diagnostic devices, implanted devices, and others. The device act is the service that the device itself performs. This is an observation for diagnostic devices and any other acts for other devices. For implanted pacemakers, for example, the device act would be a composite act consisting of sensing (observations) and pacing.
Diagram
This is a definition of observation services that a diagnostic device performs. It focuses on an Observation in definition mood, where a code from a standard vocabulary (e.g. LOINC) can be provided to state what property the device measures. In addition, a specific link to the Substance may be given that is the analyte which the device detects. For example, if the device measures digoxin concentrations, the analyte is digoxin. Multiple observations (batteries) may be specified as a structure of sub-observations. If observations are calculated (e.g., anion gap from a blood gas analyzer) this can be specified with the derivedFrom relationships. Interpretation ranges of the results may be specified using the reference values and manifestation links.
Diagram
Description of the actions. i.e., observations and interventions (procedures), that a device performs when it operates. This model is based on use cases from implantable cardiac devices, including pacemakers, implantable cardioverter defibrillators (ICDs), cardiac resynchronization therapy (CRT) devices, and implantable sensors. In addition to providing pacing and cardioversion or defibrillation therapy (Procedure), and keeping a retrievable record about some of the interventions delivered by the device, these devices also produce observations about the patient (e.g. heart rate, arrythmia episodes) and about the device itself (e.g., battery status).
Adapted from Therapeutic Devices from POTD_RM000001UV last balloted in the Implanted Devices Cardiac, Normative Ballot 2 - May 2007 but the final status is unclear (?).
Diagram
The Substance model provides a choice of two levels of detail for substance descriptions, as a "clinical" model with just a substance and an active moiety, or as a "chemical" model with detail reaching into the molecular structure. The SubstancePresence Role allows specifying a substance contained in another substance (a specimen) or at a specific compartment or cellular location.
Diagram
The usual entry point for a substance submission is the IdentifiedSubstance role. The entry point on the Substance entity allows the detailed substance structure to be used in combination with other entities (e.g., directly connected to formulations.)
The Substance Entity class represents the substance (as a universal). Upon hearing the word "substance", one may think of (1) a larger amount of this substance, such as a pail full of a liquid, as sizeable crystal, or of (2) a single smallest quantum of the substance, such as a single molecule or a single complex. Which intuition we choose determines how we consider the notions of quantity (measured vs. counted) or part (a cup from the pail, chip from the crystal vs. a molecular substructure, or moiety, from the molecule). Whether we have a single molecule or a large amount, however, is only a difference in quantity (many singular entities make up the amount and there is no amount of the substance smaller than its singular molecule.
The differences in the conception of part along this quantity axis are in no way special, even macroscopic objects can be subdivided into parts in different ways. For example, a loaf of bread can be divided into (1) crust outside and the crumb inside or (2) it may be divided into slices; in whole-grain bread, one may (3) discern on elongated bread, such as French Baguette, the ends from the shaft; and one may (4) dissect individual kernels of grain from the more homogenous polymerized starch mass. Thus it is with substances also, they may be dissected into portions, regional parts, and molecular parts. The molecular parts are called moieties.
The Substance is identified by a code, which is the primary code, a primitive without further post-coordination and no translations. Any use case where the Substance needs to be related to other conceptualizations of the same (or sufficiently equivalent) Substance, shall use the EquivalentSubstance role. The SpecializedKind structure can be used, as always, to declare the Substance a specialization of any number of Substance classifications.
The IdentifiedSubstance role, also one of the entry points to the Substance model, declares that this substance, identified by that id, is so identified by the scoping Organization or for the scoping region ("Territory"). The substance id (extension and root) and the playing Substance Entity's code (code and codeSystem) must be the same. This will allow references to Substances as Entities and in a generic IdentifiedSubstance role to resolve to one unique object.
Moiety is a molecular part, or, more generally, a part of the smallest amount (quantum) of the substance. Moiety is a structural part, meaning that removal of such parts changes the nature of the substance. Conversely, removal of a portion from a crystal does not change the substance. The Moiety class in the model is a partitive Role class with a code attribute, allowing the further distinction of the kinds of molecular subdivisions.
Moieties may be constructed of smaller moieties (e.g., functional groups). For example, if one wishes to say that one of the hydrogen atoms on a benzene ring is substituted with a hydroxyl group (to form phenol), one may say that the base moiety is benzene but a Modification exists connecting the benzene with a hydroxyl group. Note, this detail of small molecules may be (and often would be) conveyed in encapsulated structure specifications elsewhere. However, for larger molecules, such as proteins, the sub-moieties would specify the existence of, for example, a glycan or phosphate residue substituted on the base moiety.
When substances are being defined based on moieties, these base moieties are often stated by their basic Substance code that stands for the unmodified substance. However, this would create a problem, since the code in the Substance would mean that the substance is unmodified, when in fact it is being modified by the connection with the Modification role. To prevent ambiguity, one must in these cases provide also a unique identifier on the base substance. This identifier makes the modified Substance special and different from the unmodified Substance referenced in the code.
Moiety1 (Entity) is the substance that is the part of the larger substance. Rather than repeating all the descriptive elements on the Moiety1 (Entity), the Moiety1 (Entity)'s code contains the code of another defined Substance so its description may be looked up (or can be sent with the same data package).
Bond: A bond is a connection between two specified moieties. Normally, moiety structures can be specified simply by breaking down the molecule into its part moieties and breaking those moieties down further. However, when multiple bonds exists between moieties, those may be specified. This can also be used to specify all the bonds in case where the moieties are provided as a parts list. For instance, in the most general case, a substance is specified by all its elements and all its bonds (this is, for example, how the MDL/MOLFILE format works.) Specific examples of the use of the bond role is to specify a protein based on its sub-units (chains) as moieties and the disulfide bridges specified as bonds connecting the subunits.
The Moiety and Bond roles have quantity and positionNumber attributes. The quantity specifies how many (numerator) of the specified Moieties or Bond exist in the whole molecule or next larger moiety (denominator). The positionNumber allows indicating where the moiety or modification attaches to the base molecule. The detail of how positionNumber is used and interpreted must be specified in the definition of the Moiety.code or Modification.code.
DerivationProcess: specifies how the substance is made. This information is not relevant for substances that are structurally completely defined and should not be used in those cases. The derivation information may be necessary, however, if the substance is not completely defined by exact structure. For example, the exact number and placement of substitutions of additional moieties to a base substance may not be constant, the length of chains of a polymer may not be specified exactly, and the length of chains of a tryptic peptide mix may not be exactly defined. When all that can be said of a substance is what the source material and processes are, then this is specified using the DerivationProcess and referencing the source material as an IdentifiedSubstance.
Interaction allows specifying the counter-part of a molecule which is essentially defined by its interaction. For example, antibodies are defined by their antigen interaction. Likewise, receptors are defined by the target (e.g. hormone) and a complex peptide-hormone may be defined by the receptor that it reacts with. Note, the Interaction structure even allows to specify detailed molecular reactions which form pathways, while this is a logical step with many important applications in biomedical research computing, it is not the main purpose for including the Interaction structure into the Substance model. Here the Interaction structure is intended for use if this Interaction contributes essentially to the very definition of the Substance.
Characteristic is a recurring theme in any specification of material. These Characteristics are observable properties that can be examined (measured) on the substance and their specification contributes to the definition of the substance or provides essential and useful information about the substance. For example, molecular mass can be ascribed to the substance by means of a Characteristic. Coded Characteristics may specify chiral properties of the substance. And Characteristics with encapsulated data can provide a structure specification using a standard external to HL7, such as MOLFILE, SMILES or InChi.
Documents may be references to other substance monographs or journal articles that contribute to the very definition of the substance.
A discussion document that gives examples of these data structures is available at here.
Diagram
A substance specified to the extent of clinical detail, i.e., with substance code and name and active moiety, as well as generalizations of either.
Diagram
The IDMP Specified Substance describe further characteristics of a single substance or multiple substances as used in a product. This is done by providing a Substance Specification, which is comprised of manufacturing process steps, analytical test definitions, and other characterizations.
| Return to top of page |