Product SPL

Product Brief - Structured Product Labeling (SPL)

back to Main_Page
back to Product_List

Product Name

Structured Product Labeling (SPL)

Standard Category

Health Information Knowledge Representation Standards

Type

Normative, ANSI Standard

Releases

• ANSI/HL7 SPL, R1-2004
• ANSI/HL7 V3 SPL, R2-2005
• ANSI/HL7 V3 SPL, R3-2007
• ANSI/HL7 V3 SPL, R4-2009

Summary

The Structured Product Labeling (SPL) specification is a document markup standard that specifies the structure and semantics for the regulatory requirements and content of product labeling. Like most documents, an SPL document has sections and sections contain text (paragraphs, lists, tables); SPL documents can be rendered and published in these standard narrative presentations. At the same time, the SPL specification provides semantic markup that permits extraction of relevant data embedded in the narrative so that it can be used for other purposes. In other words, SPL markup of a product labeling document preserves both the human readability of the content and facilitates machine processing of that content.

SPL is approved by Health Level Seven (HL7) and has been adopted by the U.S. Food and Drug Administration (FDA) as a mechanism for exchanging medication information. (fromWikipedia). SPL is also used by the FDA for the submission of other regulatory information supporting product labeling, specifically for establishment registration and labeler information.

Description

SPL documents contain both the content of labeling (all text, tables and figures) for a product along with additional machine readable information (including drug listing data elements and clinical data elements). Drug listing data elements include coded information about the product (including product and generic names, ingredients, ingredient strengths, dosage forms, routes of administration, appearance, DEA schedule) and the packaging (package quantity and type). Clinical data elements include coded information about the clinical use of the product (including indications and use, contraindications, drug interactions, warning and precautions and use in special populations). This specification includes a detailed description of an information model for structured product labeling documents as well as the XML representation of that model. The information model is based on the HL7 Reference Information Model (RIM) and uses the HL7 Version 3 Data Types. SPL is based on the HL7 Clinical Document Architecture (CDA), which specifies the structure and semantics of “clinical documents” for the purpose of exchange (see 3.1.1 Relationship of the SPL Specification to CDA). The SPL Schema is defined as an XML entity. An SPL document references the SPL Schema. For this version of the specification, document analysis focused primarily on labeling for drug products. In the U.S. or internationally, drug product labeling may also be known variously as a package insert, prescribing information, product information, or summary of product characteristics, among others. The precise definition and content of product labeling may also vary depending on the country. (For example, in the U.S., all written, printed, or graphic matter accompanying a drug product is called “labeling”. For human prescription drugs, the “content of labeling” includes all text tables and figures in the labeling described in 21CFR 201.57.) Implementers of this standard should refer to applicable regulations and definitions in the realm in which the standard will be used. The standard facilitates adaptation to different regulatory realms by allowing each coded element in an instance to draw its values from independent external code sets defined by the regulator and referenced in the instance.

THE PURPOSE OF THE SPL

The major purpose of the SPL specification is to facilitate the review, editing, storage, dissemination of, and access to, product labeling document content. It is intended to:

• Facilitate provision of the content of product labeling both electronically and in a human readable format. SPL documents can be exchanged across systems without the need for additional transformation steps.
• Improve dissemination of product labeling (both new product labeling and product labeling updates) to users of product labeling. The ability to provide the most up- to-date product labeling in a timely manner is considered to be critical to improving risk management of regulated products.
• Facilitate more efficient evaluation of labeling changes by allowing more effective use of computer technology to compare different versions of labeling on a section by section basis.
• Promote more coordinated data collection throughout the regulatory agency and improve processing, storage and archiving capabilities. Reduce or eliminate redundancies in data collection.
• Improve access to information and enhance the ability to query and report on the content of labeling, allowing better support for specific analyses such as sub-population assessments of differ- ences in products based on gender, race, age, and geographic location.
• Improve interoperability of the regulatory agency’s systems with other clinical information systems.
• Use standards to improve integration of clinical data.
• Enhance patient safety by helping to provide prescribers and consumers with improved access to information needed to make better risk management decisions in a format that will enhance integration with other technical and clinical applications.
• Support retention of legacy product labeling in databases.

In general, this specification shares the goals of the CDA, which are to:

• Give priority to delivery of patient care.
• Allow cost effective implementation across as wide a spectrum of systems as possible.
• Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
• Promote longevity of all information encoded according to this architecture.
• Enable a wide range of post-exchange pro- cessing applications.
• Be compatible with a wide range of document creation applications.
• Promote exchange that is independent of the underlying transfer or storage mechanism.
• Prepare the design reasonably quickly.
• Enable policy-makers to control their own information requirements without extension to this specification.

Although SPL does not give priority to delivery of patient care in the same way as CDA documents, which are directly associated with patient encounters, the goal of providing timely information about medical products ultimately serves patient care.

Additional goals of the SPL specification include:

• Facilitate review, storage, and dissemination of product labeling.
• Maximize timeliness of availability of product labeling.

The most recent version, Release 4, received ANSI approval in March 2009 and extends the SPL standard to include medical devices, veterinary medicine, and additional listing information. It is available for purchase at the HL7 bookstore at www.HL7.org.

Business Case (Intended Use, Customers)

The primary customers for SPL are health care professionals or patients who access the content of labeling electronically, or health care professionals using the content of labeling and the coded product or clinical data through the mediation of an electronic prescription decision support systems.

The investment in SPL is expected to be repaid by a reduction in health care delivery costs, specifically those costs arising from the use of hard to access, incomplete or out of date prescribing information. For example, drug interactions are a major cause of hospitalizations among those over 65, so it is expected that electronic delivery of relevant information could reduce the number of these events.

While in principle SPL could be implemented by any community of pharmaceutical information suppliers and users, in practice it can only be implemented with the participation of the appropriate market regulator in the country where the products are sold.. The regulator defines the code sets and implementation rules so that prescription information can be delivered electronically in a timely, authoritative and comprehensive service. So far this has been done only by the FDA, but other regulators without existing electronic encoding initiatives could easily adopt their own version of SPL.

For example, in Canada it would be relatively straight-forward technically for the regulator, Health Canada, to define code sets so that Canadian content of labeling could be managed, distributed and rendered in an electronic form conforming to national legal requirements with the added benefit of enhanced machine processability. These codes sets would identify document type and language, the individual sections of the Product Monograph, and key product information (such as dosage form and route of administration).

Once SPL has become a regulatory standard in a given realm, and a recognized authoritative distribution source has been established, the stakeholders may expect to achieve the following benefits:

• drug companies: faster and broader dissemination of their product information
• regulators: more efficient database updates and more effective information provision to their professional and public clients
• medical professionals: better information sooner, therefore better prescribing decisions
• health care payers: reduced costs
• patients: avoiding adverse drug reactions and drug-drug interactions, promoting compliance with prescription directions

Benefits

The benefits that accrue to all stakeholders in the drug regulatory process by adoption of Structured Product Labeling (SPL) make the business case for implementation of SPL overwhelming. The benefits of SPL derive from use of standard, universally adopted information standards such as XML, from the specific aspects of the SPL model for describing prescription drug content, and from adoption of an open standard for SPL. (from FDA Publication, see Appendices)

Implementations/ Case Studies (Actual Users)

SPL is mandated in the US for
(a) submitting content of labeling with marketing applications and supplements thereto for human prescription drugs and some biological products and
(b) for electronic Establishment Registration and Product Listing for all listed human prescription drugs (including compressed medical gasses), over the counter human drugs (including some cosmetics containing drug substances), biological products and animal health products.
At this time the FDA does not use the SPL submitted under (a) for reviewing content of labeling or for exchanging information with the application’s sponsor. The FDA is updating some of their internal databases from the SPL submitted under (b) and passes all labeling SPL submitted under (b) to the National Library of Medicine for posting on the Daily Med web site. The clinical data elements are not currently used in this implementation but the FDA has issued guidance concerning ‘indexing SPL’ under which it will provide SPL instances containing clinical information (initially drug class) and references to those product labeling SPL instances to which the clinical information applies.

For details of the FDA’s implementation see their SPL resources web page at: http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/default.htm

Some systematic downstream use of the SPL posted to Daily Med, has started. For example, an association of hospital pharmacists has asked that variations in the coding and placement of Med Guides sections be eliminated so that the content from Daily Med instances can be used reliably to print these guides when prescriptions are issued. In addition, a ‘value added’ search and retrieval service has been launched by Reed Technology using SPL imported daily from Daily Med.

Resources

• SPL Project Wiki
• SPL Work Group Wiki

Work Groups

• RCRIM WG

Education

• See more at http://www.hl7.org/implement/training.cfm

Certification Available

• none

Links to current projects in development

• Medical Product Information (includes Drugs, Devices, Biologics, Veterinary Products) (SPLr5)
  • wiki: http://wiki.hl7.org/index.php?title=Medical_Product_and_Device_Listing
  • Project Insight # 325