This is a Draft Standard for Trial Use of the Version 3 Structured Product Labeling Release 5 topic. This topic, in the Regulated Studies domain, 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 24 months from the date of publication. Suggestions for revision should be submitted at //www.hl7.org/dstucomments/index.cfm.

Following this 24 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

SPL release 5 is an extension of the SPL release 4 content to cover more details of medical devices. Most importantly, however, SPL R5 is the first release to rely on the Common Product Model (CPM) for its product data elements content.

SPL since release 2 consisted of 3 parts: (1) document data structures, (2) data structures describing the product, and (3) data structures describing the clinical use of the product, and connected through the highlight excerpt. Since this release 4, a fourth part, "Product Instance", was added to support listing of devices and biologics, or of any kind of regulated product where reporting must be done on current manufacturing and distribution activity. Now, for release 5, the product structures (2) and the clinical use structures (3) as well as the product instance (4) structures are all found in the Common Product Model. Thus, the SPL specification itself has become but a remnant, i.e., only the structure document model (1). This testifies to the success of the SPL specification, because these 4 core SPL product models have become the foundation of the HL7 common product model which finds use in a much wider scope far beyond product labeling and listing.

This specification is accompanied by a bundle of supporting materials including the model interchange files (MIF) and the W3C XML Schema (schema). Due to the fact that SPL R5 uses the CPM CMETs, the schema is now divided up over many more files which include each other. However, the SPL R5 schemas as they are released in this bundle of supporting materials, have been tested for backwards compatibility with SPL R4 documents. Therefore, none of the existing SPL R4 documents need to change and remain valid under SPL R5.

The Structured Product Labeling (SPL) specification is a document markup standard that specifies the structure and semantics of the content of authorized published information that accompanies any medicine licensed by a medicines licensing authority. These documents are known as "product label," "package insert," "prescribing information," "product information," "medicines information," and under many other names. The precise definition and content of product labeling usually varies depending on the country. (For example, in the U.S., all written, printed, or graphic matter accompanying a medicinal 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 regulations, definitions and guidances applicable for the realm in which the standard will be used.

An SPL document is created by an organization that is required by law to submit product information document because it is responsible for the creation or marketing of a product, or any other person or organization compelled by other motives to submit information about products, whether originally created or not. This includes, original manufacturers, repackagers, relabelers, and public agencies or private information publishers that submit product information documents. Recipients of product label documents are any person or organization, including the public at large, or an agent of the public (such as a regulatory authority). The need to create SPL documents is typically governed by legal statutes which set points such as the completion of a new drug application (NDA), the change of product information or annual reports as requiring submission of an SPL document.

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 both preserves the human readability of the content and facilitates machine processing of that content. The document may contain references to media files, such as images, which should accompany the SPL document. However, the wrapping of files is not specified, and guidances to this effect exist by regulatory authorities who accept SPL.

SPL is structured analogous to HL7 Clinical Document Architecture (CDA), which specifies the structure and semantics of "clinical documents" for the purpose of exchange. In earlier releases of SPL the CDA text markup XML schema and its defining text had been copied from the CDA specification. This XML schema is also known as the "narrative block" schema, and included in the SPL XML schema release as NarrativeBlock.xml. This narrative block schema is part of the SPL specification; however, it will no longer be reproduced verbatim but rather will be included into the SPL specification by reference only and only variances between CDA and SPL will be discussed in detail.

Even though the SPL specification was designed analogous to the HL7 Clinical Document Architecture, there are fundamental differences between the two specifications, for example:

• CDA documents involve a Patient - SPL documents do not.
• CDA documents involve one or more Providers - SPL documents do not.
• CDA documents involve an Encounter - SPL documents do not.
• The potential for authentication is subtly different for product labeling documents than for CDA documents. While a product labeling document may be authenticated, and may even have a requirement for legal authentication in some realms, this authentication occurs on the officially approved version of the document rather than on each minor revision of the document in the process of finalizing it.

SPL was the first HL7 Structured Documents specification designed analogous to CDA but not as simple constraint of the CDA specification itself. It is anticipated that the next release of CDA will split the material into a common HL7 Structured Documents specification that describes the principles of Documents, Document Participations (author, authenticator etc.), Sections, Narrative Block, etc. and a family of content specifications such as CDA (for patient clinical documents), SPL (for product labels) and other types of documents.

The 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 differences 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

It is important to note that the SPL specification models the structure and semantics of labeling content and not the presentation found in printed labeling! It standardizes the markup of the required content, specifically the structure and semantics of that content. Although the human readability requirement specifies that the content must at the very least be readable using a generic stylesheet that applies to all HL7 structured documents, the use of specialized stylesheets for specific presentation purposes is not prohibited. Limited support for the presentation of content is provided in CDA "narrative block" and has been adopted by SPL.

The SPL specification does not currently specify the creation or management of documents, only their storage and exchange markup. Document management is critically interdependent with the product labeling specification, but the specification of document management messages is outside the present scope of the SPL specification.

This specification does not address the transfer mechanism for product labeling documents. The specification for messages that might carry the product labeling document is outside the scope of the SPL specification, although the CDA standard does specify how to package clinical documents within HL7 messages. An SPL document may be transmitted in an HL7 message that is designed to transfer clinical documents. Alternatively, several other mechanisms may be used to transfer product labeling including physical media, PDF, electronic transfer of word processing applications, among many others.

A conformant SPL document is one that at a minimum validates against the SPL Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. However a computer cannot validate many aspects of conformance. The focus of this section is to highlight these aspects of SPL that cannot be machine validated - particularly those aspects related to the SPL human readability requirements.

Description of Application Roles moved to the main specification. The following responsibilities have been condensed leaving the actual requirements and not mentioning optional steps which were not required. Also those requirements which are simply restating some constraints that are documented in the HD and XML Schema are not repeated.

Recipient responsibilities

• Assume default values where they are defined in this specification, and where the instance does not contain a value: Where SPL defines default values, the recipient must assume these values in the event that no value is contained in an SPL instance. This holds regardless of whether or not the SPL Schema supplies the recipient with the default values. This receiver responsibility notwithstanding, it is recommended that originators not rely on default assumptions but instead place all relevant data explicitly into the document. In no way are originators encouraged to "compress" their documents by systematically removing information that is the same as the implied defaults.
• Parse and interpret the SPL content sufficiently to be able to render it: A recipient of an SPL document must be able to parse and interpret the SPL document sufficiently to be able to render it, using the following rendering rules:
• The NonXMLBody, will need to be rendered with a software tool that recognizes its particular MIME media type. Since there can be no guarantee that a recipient can render every possible MIME type, a NonXMLBody may be ignored by a recipient. A sender can only rely on the recipient being able to render a NonXMLBody if there is a prior bilateral agreement. Hence, the NonXMLBody is not plug-and-play interoperable. See also the HL7 Data Type specification for the status of various MIME types.
• The StructuredBody, must be rendered by the recipient including at least the Section.title, and Section.text (Narrative Block) elements. The absence of the Section.title signifies an unlabeled section.

Originator responsibilities

• Properly construct SPL Narrative Blocks: An originator of an SPL document must ensure that the content of the document body is structured such that a recipient, adhering to the recipient responsibilities above, will correctly render the document.

This section summarizes the scope of the SPL document and data structures. Formerly it was discussed as 'requirements' and split over two parts of the specification. A discussion of requirements can not be actionable normative content. But the material is suitable as a scope statement, providing a summary of data covered by SPL.