Pharmaceutical Quality - Chemistry, Manufacturing and Controls (PQ-CMC) Submissions to FDA, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 1.1.6 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/FHIR-us-pq-cmc-fda/ and changes regularly. See the Directory of published versions
This implementation guide is based on the HL7 FHIR It uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.
This IG only contains only bundles of the document type because the bundle instances will be delivered with a eCTD filing. Any implementation adapting these for use in a FHIR server should read RESTful operations
FHIR defines the notion of Must Support. To help establish conformance expectations for systems. For the purposes of this implementation guide, "must support" shall be interpreted as follows: Conformant systems SHALL be capable of sending and receiving the data element. When a system persists a resource instance, all "must support" elements SHALL be persisted and retrieved with other elements.
Developers implementing the Invariants will need to be familiar with the [FHIRPath Specification](http://hl7.org/fhirpath)
This implementation guide defines profiles on several resources. Implementations are expected to be conformant with these profiles to be conformant with this implementation guide.
<p>
FHIR defines the notion of <a href="http://hl7.org/fhir/R5/conformance-rules.html#mustSupport">Must Support</a> to help establish conformance expectations for systems. The specific meaning of
"must support" is left to be defined in individual implementation guides. For the purposes of <i>this</i> implementation guide, "must support" shall be interpreted as follows:
</p>
FHIR bundles are used to group a collection of resources into a single package. This can include various resources like lab records, research studies, and more. Each Bundle profile defines a specific use case or standard for how resources should be bundled together. Profiles ensure that the bundles meet certain requirements and follow consistent formatting rules. The Composition profiles are categorized under various document types to better organize and define their use cases. Each profile in a bundle corresponds to a specific type of document or record. For FHIR in general, a Composition profile might be used for documents such as a discharge summary or a lab report. In this Implementation Guide (IG), the Composition profiles are used to itemize the elements required in a particular eCTD section. The diagram shown below functions as a legend for the symbols and notations used in the Composition profile diagrams. This is crucial for interpreting the relationships and details correctly.
For more detailed information about the profiles illustrated in the diagrams, users can refer to the Artifacts page and the profile pages linked in the diagrams. This page provides specifics about the requirements for each profile, helping users understand how to implement or use the profiles effectively. By examining the diagrams and referencing the profiles on the Artifacts page and individual profile pages, users can gain a thorough understanding of how FHIR bundles in this IG are structured and how to apply the profiles in practice.
Note: The example bundles provided in the eCTD bundle pages are not linked to any real products or substances. They are illustrative, sometimes using real chemical compounds for context, but their primary purpose is to demonstrate the profile features rather than actual scientific content. Values within these examples may be augmented or altered to fit the requirements of the standard or to illustrate specific features.
All entries in the bundle must have an identifier to support the ability for them to be referenced within the document. Unless there is a unique identifier and system available, provide a Uniform Resource Identifier (URI): Generic Syntax as the identifier. More information is available at: https://datatracker.ietf.org/doc/html/rfc3986/. The system should be entered as “urn:ietf:rfc:3986”.
Although FHIR allows for multiple ways to reference other resources, they are not all appropriate for the PQ/CMC use case because the receiving endpoint is not a FHIR server. Resources cannot be referenced using a URL to a server. They must be added in a bundle together with the other resources required by the composition to have everything available in one XML file.
Overview of Requirements for PQ/CMC Bundles
Steps for Implementation:
By following these guidelines, you can ensure that the PQ/CMC bundle’s complex data is presented in a clear and standardized human-readable format, facilitating easier access and understanding. Transform use is not required. However alternate narrative generation must support a similar layout. If data is presented in table format by the Transform Tool, then it is expected that an alternate generation method also presents the data in a table.
There are many elements defined by the markdown datatype. The sytlesheets are restricted to GitHub flavor of Markdown. Line feeds must be double spaces. Not all markdown features are supported.
Narrative Transform HTML Page
Narrative Transform Text Area and Save Button
Any versioning of bundles is for the application sponsor's usage. The status of all bundles is "active". The eCTD software will replace all prior bundles versions and the latest bundle will be the current version.
Bundle examples contain one instance of a profile when the cardinality for that profile is one, and two instances of a profile when the cardinality is one to many. There are many bundles that will contain ten or more entries of the same type of profile, such as product composition, batch formula, quality specifications and stability reports.
eCTD submission to the FDA will be in XML format. JSON format is supported by this IG because there are several use cases in the CMC domain where JSON representation may be helpful to the larger community. For example, there are commercial FHIR servers that only support JSON, the Industry PQ project supports both XML and JSON representations and since the submission to FDA is a downstream activity in the overall CMC data flow, it makes sense to provide flexibility for implementers and CMC vendors. Additionally, entities integrating the FHIR content in internal systems often prefer and may leverage the JSON representations.