 HL7 RPS DSTU R2 HL7 Version 3 Standard: Regulated Product Submission, Release 2 August 2010 |
 HL7 IG RPS, R1-2008 HL7 Version 3 Implementation Guide: Regulated Product Submission, Release 1 May 2008 |
Content Last Edited: 2012-09-02T14:31:49
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
2.7 Interactions
2.A Regulated Product Submission Release 2 Implementation Guide
This is a Draft Standard for Trial Use of the Version 3 Regulated Product Submission Release 2 topic. This topic, in the Regulated Studies domain, was approved as a DSTU following a successful DSTU ballot during HL7 International's January 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
Regulatory authorities receive submissions to address a variety of regulatory issues. The information contained in these submissions is divided into numerous files (paper and electronic). Frequently, files in one submission are related to files in earlier submissions. Because the information is divided into numerous files sent over time, it is often difficult to efficiently process and review the information.
The goal of the Regulated Product Submission message is to facilitate the processing and the review of submissions. Accordingly, the Regulated Product Submission Refined Message Information Model captures all information required for the efficient processing and review of regulatory submissions.
Different product types have different table of contents; that is to say, different lists of topics that must be addressed within the submission. However, the general data layouts of all regulated products are the same. Therefore, the objective of the Regulated Product Submission message is to define one message structure that can be used for all regulated products. It is intended that this message will be used, worldwide, for regulated products, including but not limited to, foods, medical devices, human therapeutics, and veterinary medicine. It is important to note that the wide range of products that is contemplated leads to providing a generic structure for the actual specification.
Please note that Regulated Product Submission is similar to the Medical Records Document Topic. This is based on the fact that both require attention to needs for managing a complex set of documents.
Scope
The scope of the initial release of this standard is to define the message for submitting information to regulatory authorities. This message includes the contents of a regulatory submission and all information needed to process the submission message. This message is flexible enough to be used for regulatory submissions for any regulated product. Subsequent releases of the standard will provide information about the submission (e.g. information currently collected on application forms) in addition to information about the files in the submission.
Although this message can be used for company-to-company communication, the initial intent of this message is for the communication from industry to regulatory authority.
The Regulated Clinical Research Information Management Technical Committee invites anyone with additional requirements to submit content proposals for future releases of the standard.
|
||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
Over time, an application will typically consist of multiple submissions and regulatory assessments. For example, the marketing application for a drug product can generate multiple regulatory decisions. The first decision may support the initial marketing approval of the product for a specific indication. Subsequent regulatory decisions may approve or deny additional indications for the drug product. The application thus contains multiple submissions, each with their own regulatory action. Each of those submissions (e.g., initial marketing application, supplemental marketing application) would generally be comprised of multiple submissions units.
A submission is made up of one or many submission units.
Note: the current specification does not support a message from the regulatory authority to applicant
| Submission Unit sent |  PORP_IN000001UV01 |
Acme Pharmaceuticals has prepared information relating to its new product - Global Fixit. This information provides information about the quality, safety and effectiveness of the product, and consists of many files that Acme has collected over several years. Acme has marshaled these files, which are designed to address a previously defined set of categories, into its first submission unit. That first submission unit will be sent to a regulatory authority for marketing approval in that jurisdiction. In this initial submission unit, the submission unit message identifies all of the submitted files, and indicates the document category or categories that the files belong. This first submission unit commences the application and represents the first regulatory submission for that application.
Since this is the initial submission unit for the application, each file in this submission unit is active. The submission is then transmitted to the regulatory authority.
The regulatory authority receives the submission and validates the message for accuracy. The regulatory authority incorporates the message into their tracking\review system creating a new application, original submission, and the first submission unit to the original submission.
Device Co. is planning on creating a pre-approval submission for a Class III PMA product. Device Co has already sent the original submission unit message and supporting files. However, new studies are available pertaining to the effectiveness of this device. Device Co will submit a new submission unit and the supporting files. This new submission unit will be linked as an amendment to the original submission. The regulatory authority receives and validates this submission unit and then this submission unit is associated with the original submission
Device Co. is planning on creating a submission for a Class III product. Device Co. has already sent the original submission unit message (i.e., the original submission) and many amendments to the original submission.
This product is going to be used for a different purpose than stated in the original submission so a new Submission must be initiated. Device Co will submit the new submission and supporting files containing the relevant information that supports the new use of the product. As required by the Regulatory Authority, this new submission and the original submission will be linked together under the same application.
The regulatory authority receives and validates this submission unit for this new submission. This new submission (e.g., referred to as a supplement or variation) and the original submission are both associated to the same application.
Note: In most cases, supplements/variations can only be created after the original has been approved.
In some regulatory processes, it is acceptable for the Applicant to provide information to the regulatory authority in defined reviewable units. Generally, these units of information support a particular discipline (e.g., clinical) and provide the opportunity to expedite some regulatory review processes.
For example, Acme Pharmaceutics has discovered a potential cure for cancer and received permission to submit a continuous marketing application. Acme now has the ability to send information in predefined reviewable units.
Acme creates a submission unit for transmission to the regulatory authority that addresses the clinical modules. Since it is expected that the regulatory authority review may turn up questions related to particular modules, Acme makes sure that the submission unit indicates which type of module it addresses.
The regulatory authority processes this submission unit and associates the unit to the correct submission.
In certain regulatory processes, the same documentation may need to be submitted to multiple applications.
Acme Manufacturing produces an annual report that pertains to multiple active applications. The company submits one submission unit and applies that unit to each application that requires the annual report. The regulatory authority processes this submission unit and associates it to all relevant applications.
In certain regulatory processes, the same documentation may need to be submitted to multiple submissions.
Acme Manufacturing changes some CMC processes that pertains to multiple active submissions for a product. The company submits one CMC submission unit and applies that unit to each submission that it pertains to. The regulatory authority processes this submission unit and associates it to all relevant submissions.
During the review of a submission, it may be necessary for the Applicant to withdraw the submission from further review or to preempt an unfavorable action by the regulatory authority.
Subsequent to the original submission of the Global Fixit submission, Acme scientists are able to spend time reviewing the outcome of ongoing studies of Global Fixit's efficacy. It turns out, after statistical review, that the product is not particularly effective. As a result, Acme wishes to withdraw the submission from consideration. A submission unit is created to withdraw the submission and all related submission units; it is transmitted to the regulatory authority.
The regulatory authority processes this submission unit message and marks the submission and related submission units as obsolete.
A submission unit is made up of one submission unit message and many files. Properly defined, the submission unit message concept enables companies to create new submission units from any combination of new and previously submitted files. The submission unit message is processed by the regulatory authority and is integrated into their tracking/review system.
Note: the current specification does not support a message from the regulatory authority to applicant
| Submission Unit sent | PORP_IN000001UV01 |
The results of ongoing studies related to Global Fixit are now available; and these results show that the product is even more useful than previously thought. As a result, Acme decides to add this information to the files that were previously submitted in support of the Global Fixit submission. A new submission unit is created that refers to the additional files (i.e., the new study results) and appropriate file references to relate this new information to the existing information. The submission unit is transmitted to the regulatory authority. The regulatory authority processes this submission unit.
Note: A submission unit message contains many file references. When a submission unit message is provided in support of a submission, individual file references can either be added to the submission, supersede existing file references in the submission, append existing file references, or may mark specific files as obsolete from the submission.
The review process for the Global Fixit submission has extended over a substantial amount of time, and Acme has found that new information relevant to the submission has been received. For example, the original submission contained a summary of clinical pharmacology information derived from a series of studies using human biomaterial, and several new studies contain information that requires changes to this summary. Therefore, researchers working for the company have rewritten this summary and submits a new submission unit with the new file marked as a replacement to the previous file.
The regulatory authority processes this submission unit. If information relevant to the submission was not submitted in the original submission unit, the submission might have been non-filed or refused to accept.
Note: A submission unit message contains many file references. When a submission unit message is provided in support of a submission, individual file references can either be added to the submission, supersede existing file references in the submission, append an existing file reference, or may mark the file as obsolete from the submission.
Global Fixit has been manufactured at two locations, Big Factory and Little Factory. Acme Manufacturing now wishes to concentrate all its manufacturing at Big Factory. Therefore it is necessary to inform the regulatory authority of this change and to update the submission to ignore all information related to manufacturing taking place at Small Factory. Therefore Acme creates a submission unit to inform the regulatory authority to ignore all files that relate to the manufacture at Small Factory. The regulatory authority processes this submission unit.
Note: This method can also be applied to logical documents consisting of multiple physical files.
The Calming Myst submission, a medication for heart burn, included the inclusion of a drug-substance file. However, Acme has now decided that it needs to break this file into several smaller files for better file management. In essence, the company wants regulatory authority to review the drug-substance information in the more granular form. A new submission unit is created that contains multiple drug-substance files to meet the documentation requirement for drug substance information. Each file is marked as a replacement for the previously submitted drug-substance file. The original drug-substance file is marked as obsolete (or replaced).
The regulatory authority processes this submission unit.
Note: The life cycle of the new more granular file is linked to the original summary file life cycle.
Before the clinical study begins, Acme would like to add several new (or not previously submitted) pages to a sample case report form file. The addition will allow reviewers at the regulatory authority to have this new information. The company prepares a submission unit that contains a file with only the new pages. The submission unit message marks this file as an addendum to the previously submitted case report form file. The addendum is considered a separate file that has its own lifecycle
Note: A submission unit message contains many file references. When a submission unit message is provided in support of a submission, individual file references can either be added to the submission, supersede existing file references in the submission, append an existing file reference, or may mark the file as obsolete from the submission.
Acme employee, Fred Firestone, has carried out further review of the recently submitted addendum to the sample case report form. As a result of his work, the company realizes that it needs to replace the addendum in order to improve the case report form. Therefore, an additional submission unit is created that contains a new addendum file to replace the previously submitted one. The new addendum is linked to the old one, and marked as a replacement.
Note: Addendum files has a life cycle independent of the file they are added to. If a future submission unit replaces the addendum file, the new addendum file would amend the same original file.
Further review of the - much changed - sample case report form mentioned above, leads Acme's Submission Control Branch to determine that the regulatory authority's review task would be eased if all the contents of the case report form were included in a single file. That is to say, it would be better to support the documentation requirements with a single file, rather than having an original file along with one or more addenda. Acme would like the regulatory authority to only review the new consolidated file, and it would like the regulatory authority to be aware that the new file replaces both previously submitted files. A new submission unit is created that contains the new summary file, and marks it as a replacement for both the previous sample case report form file and the addendum.
Acme Manufacturing has prepared a submission for a product to be marketed to mountain climbers - known as High Altitude Fixit. One component of the submission will be a protocol file that pertains to three different studies in the submission. It documents the protocol that was followed during those studies. When the High Altitude Fixit submission unit is prepared, it will contain, among other files, the protocol file and other documentation providing the results of the three studies. Each of the three studies references the protocol file. The submission unit transmission contains only one copy of the protocol file. The regulatory authority processes this submission unit.
Several years ago, Acme submitted a submission to market a medication for heart burn known as Calming Myst, which was to be produced under license from a European manufacturer. However, all the files related to the earlier submission unit have been marked as ignore because Acme was never able to come to a final arrangement with the manufacturer for the production of the product.
However, new management of the European firm is more agreeable, and Acme is confident that it will have the Calming Myst contract in hand by early next year. As a result, Acme would like to reactivate the European manufacturing files for regulatory authority review. A submission unit message is created that refers to the previously submitted files and reactivates them for regulatory review.
Note: The all files associated with this manufacturer has been reactivated. The complete lifecycle of all logical documents associated with this manufacturer are also reactivated.
Subsequent to the original Global Fixit submission, Acme researchers realize that an analytical procedure file had been mistakenly categorized as the protocol document of one of the studies in that previous submission's units. This was a mistake, since it should have been categorized as an analytical procedure document. The company wants to inform the regulatory authority to change the category assignment of the file. The submission unit that Acme transmits to the regulatory authority is designed to inform the regulatory authority that the previously referenced protocol actually should be referenced as an analytical procedure. The procedure file is not re-transmitted.
The European manufacturer who produces the Calming Myst product, has done previous business with Acme manufacturing for a number of years. In a previous application - for Calming Balm - Acme had submitted information for that manufacturer that is relevant to the Calming Myst application. Since the regulatory authority already has the files for the manufacturer, Acme decides to reference those files in the new application. The Calming Myst submission unit contains references to those previously submitted files. The submission unit does not contain copies of the previously submitted files. The regulatory authority processes this submission unit. It is possible for the reviewers to access the referenced files as if they had been submitted in this submission unit.
Note: It is possible for the reviewers to access the referenced files as if they had been submitted in this submission unit.
This method applies to studies, logical files, or any other file or groups of files that the company has previously sent to the regulatory authority.
Subsequent to the Calming Myst application, the European manufacturer decides to move its manufacturing operations to another facility and to introduce advanced technologies to the processes. This requires changing the manufacturer information in all the applications related to the products they manufacture; in particular, it applies to both the Calming Balm and Calming Myst submissions. Acme will submit a new submission unit as part of the Calming Balm submission that contains the updated files. A new submission unit for the Calming Myst product is submitted as well. In that submission unit, references to the new files are included, but the actual files are not. The regulatory authority processes this submission unit. It is possible for the reviewers to access the referenced file as it was submitted in this submission unit.
Note: This method applies to files, logical documents or any other files or groups of files that the company has previously sent to the regulatory authority.
In the High Altitude Fixit submission, Acme had previously submitted a protocol file that pertained to three different studies within the application. Since that time, investigators under contract to Acme have updated the protocol file specifically for one of the three studies. However, these changes are not relevant to the other two studies. Acme would like the regulatory authority to review the new protocol file for the one study, while continuing to review the previous protocol file for the other two. A new submission unit is created that has the new protocol file marked as a replacement for the relevant study. The submission unit contains no reference to the other two studies. As a result, regulatory authority continues to review the previous protocol file for them.
The original Global Fixit submission unit included a safety file. In a later submission unit for the same submission, the same safety file was mistakenly submitted again as an original file. However, new information has been received, which has led to an updated safety report. Acme wants to replace both previously submitted safety files with the new report. A submission unit is created that contains the new safety file, and marks it as replacement for both of the previously submitted files.
Note: This method can be applied when switching from a more granular document structure to a less granular one.
|
||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
The organization that assumes responsibility for producing documentation for the purpose of seeking approval to either start testing or market a specified product.
The organization that reviews relevant information and has the ability to approve a product for testing or marketing.
|
||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: |
Applicant determines they have enough information that warrants a submission unit to a regulatory authority. The applicant can create a new submission unit, amend an existing submission or withdraw a submission.
|
||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | None |
Security, Confidentiality, and Data Integrity
Application systems sending and receiving documents are responsible for meeting all legal requirements for document authentication, confidentiality, and retention. For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.
Document Identification, Revisions, and Addenda
An original report is the first version of a report. It gets a new unique value for ContextOfUse.id, a new value for ContextOfUse.setId, and has the value of ContextOfUse.versionNumber set to equal "1".
An addendum is an appendage to an existing report that contains supplemental information. The appendage is itself an original report, as described in the previous paragraph. The related report being appended is referenced via an ActRelationship, where the ActRelationship.typeCode is set to equal "APND" (for "appends"). The related report being appended remains in place and its content and status are unaltered. If the related report is subsequently replaced, the addendum will then be associated with the most current related report in the related report set (see setId). If a new report replaces both the previous report and the addendum, the ContextOfUse.setId will be the same as the previous reports ContextOfUse.setId and will have an ActRelationship.typeCode is set to equal "RPLC" (for "replace") for both the previous report and the addendum.
A replacement report replaces an existing report. The replacement report gets a new globally unique ID value, while the replacement report uses the same value for ContextOfUse.setId as the related report being replaced, and increments the value of ContextOfUse.versionNumber by 1. (Note that version number must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.) The related report is considered superseded, but is still retained in the system for historical reference. The related report being replaced is referenced via an ActRelationship, where the ActRelationship.typeCode is set to equal "RPLC" (for "replaces").
These relationships are summarized in the following illustration:
Context of Use (Document) Statuses and Transitions
A context of use is a file that is being referenced in a particular submission unit with a particular code value. The same file can have several context of use. Accordingly, it is possible that each context of use of the same file has different statuses. In addition, a context of use is associated to a submission through a submission unit. Thus, it is possible to query all active documents in a approved submission.
Documents only assume a subset of the states that other Acts can take on. When a document is released to regulatory authorities, its status becomes "active". Documents that are "active" are rendered "obsolete" when they are replaced with a revision. A document can also be rendered "obsolete"by a status change. If a document is rendered "obsolete", that document can be reactivated. Obsolete documents cannot be revised.
In a later phase an active document will end its life when the submission that document belongs to has come to a conclusion.
Submission Statuses and Transitions
Submissions only assume a subset of the states that other Acts can take on. When a submission is released to regulatory authorities, its status becomes "active" or "In Review". Since the current specification only supports communication from applicant to regulatory authority, only withdrawing and activating a submission is currently supported.
In the future, submissions will have the extra states of approvable, not approvable, and approved.
Submission Interaction
For the scope of this project, all communication from applicant to regulatory authority are in the form of a submission. Note: the current specification does not support a message from the regulatory authority to applicant.
Applicant determines it has enough information to warrant sending a submission to a regulatory authority. The applicant can create a new submission, amend an existing submission or withdraw a submission.
ContextOfUse Codes
A document's content is defined by one or more topic codes (e.g. Manufacturer, Introduction, Summary, etc.). The combinations of these topic codes are well defined by product types. A single topic code can be used in different context. For example, in human therapeutic products the combination of the topic codes Chemistry, Drug substance, Manufacturer is a valid document context. If Chemistry has a topic code of 35, Drug substance has a topic code of 71, and Manufacturer has a topic code of 140, then the combination of Chemistry, Drug substance, and Manufacturer would have a ContextOfUse code of 35-71-140. In addition, if Drug Product has a topic code of 70, then the combination of Chemistry, Drug Product, and Manufacturer would have a ContextOfUse code of 35-70-140.
In addition the same ContextOfUse code can be used for multiple products. For example the combination of Chemistry, Drug substance, and Manufacturer would be a valid ContextOfUse code for both Human Therapeutic products as well as Animal Products.
It is also common that different product types will use different combinations of the same topic code. For example a Medical Device product would have a ContextOfUse code that specifies a Cover Letter. However, a Human Therapeutic product would have a ContextOfUse code that would combine the topic codes of both Administrative and Cover Letter.
Model Overview
As industry moves away from paper submissions, all companies producing regulated products will benefit from having published electronic submission standards. Accordingly, the focus of the initial message allows applicants to submit information electronically. The submitted information is structured as a collection of documents that is organized by report sections. The actual table of required and optional report sections varies from product to product and is defined by regulatory authorities.
Submitted documents are assigned to support one or more report sections. Furthermore, multiple documents can be assigned to a single report section. Since the same information can be submitted to support multiple applications, it is imperative that this standard allows the re-use of data between applications. Re-using data is accomplished by using the Uniform Resource Locator scheme (through the reference property of the ED datatype that is assigned to Act.text) in the File Act. The URL scheme allows the file in one application to provide a reference to a document that was submitted in another application.
A single document can be in multiple report sections of an application and can also be in multiple applications. For this reason, we have defined the ContextOfUse Act which provides the relationship of a document to a report section. Since a submission unit can contain multiple ContextOfUse, this class can be used to indicates each assignment of a document to a section. Looking across multiple submissions, it is possible to record a single document's context in multiple applications as needed.
Since this message is primarily focused on document management, it would seem that the ContextOfUse Act would be the obvious choice to the entry point of this message. However, applicants transmit information to regulatory authorities in the form of submission units containing multiple ContextOfUse. These submission units support the overall application. Accordingly, the entry point for this message is the Submission Unit Act.
Domain Model Walk-Through
SubmissionUnit
A collection of documents submitted at a particular point in time in order to further the granting of a submission.
Attributes
-
SubmissionUnit.ID: The unique identifier that is used to refer to this act
-
SubmissionUnit.code: The code specifying the particular kind of submission unit (e.g. Original, Amendment, Supplement).
-
SubmissionUnit.statusCode: A submission unit is either active or null.
Relationships
-
Submission: This clone defines the organization of the submission unit. A submission unit either pertains to one or more Submissions or pertains to one or more Reviewable Units. For example, an annual report submission unit can apply to multiple applications. Therefore, the applicant will create one submission unit and associate that unit to multiple submissions.
-
ReviewableUnit: A reviewable unit is a way to organize several submission units so they are reviewed as an independent unit within a submission. A submission unit either pertains to one or more Submissions or pertains to one or more Reviewable Units.
-
ContextOfUse: A submission unit contains zero to many ContextOfUse. The ContextOfUse Act contains most of the supporting information to help further the granting of an application. Two ContextOfUse Acts with the same Code can be sorted by priorityNumber. When the applicant administratively changes the status of the submission to obsolete, the applicant would create a submission unit message with no context of use.
Submission
The submission is a way to organize an application into discrete units. Most typically the submission will be used to organize information based on a review clock. Receipt date from the regulatory authority is important for a submission. Since the message, at this time, is only from applicant to regulatory authority, submission does not have a date attribute.
Attributes
-
Submission.id: The unique identifier that is used to refer to this act
-
Submission.Code: The code specifying the particular kind of submission (e.g. Original, Supplement, Annual report).
-
Submission.statusCode: A submission is either active or null. In the future we plan on extending the status code to reflect the approval status of the submission.
Relationships
-
SubmissionUnit: The submission can be related to one or more submission units or one or more reviewable units. The submission unit can have a default order, the priorityNumber, used in the relationship to a submission. Note: There is a harmonization proposal to change priorityNumber from the value type of INT to REAL. The REAL value type will allow the applicant to order a submission unit between two other previously submitted submission units.
-
ReviewableUnit: The submission can be related to one or more submission units or one or more reviewable units.
-
Application: Each submission organizes information for a single application.
ReviewableUnit
The reviewable unit is a way to organize a submission into discrete units. Each reviewable unit can have a status. A reviewable unit performs similar to submission.
Attributes
-
ReviewableUnit.id: The unique identifier that is used to refer to this act
-
ReviewableUnit.Code: The code specifying the particular kind of submission (e.g. Original, Supplement, Annual report).
-
ReviewableUnit.statusCode: A submission is either active or null. In the future we plan on extending the status code to reflect the approval status of the submission.
Relationships
-
SubmissionUnit: The submission can be related to one or more submission units or one or more reviewable units. The submission unit can have a default order, the priorityNumber, used in the relationship to a submission. Note: There is a harmonization proposal to change priorityNumber from the value type of INT to REAL. The REAL value type will allow the applicant to order a submission unit between two other previously submitted submission units.
-
Submission: Each reviewable unit organizes information for a single submission.
Application
A request for approval to either market a product or to allow the applicant to start testing of a proposed product.
Attributes
-
Application.id: The unique identifier that is used to refer to this act
-
Application.code: The code specifying the particular kind of application (e.g. New Drug Application, 510k, Veterinary New Drug Submission). Each product type will be supported by a different application code.
-
Application.statusCode: An application is either active or null.
Relationships
-
Submission: There are zero to many submissions that contain information for an application.
-
KeywordDefinition: An application has zero to many keywords that can be used to make a KeywordDefinition.
-
File: An application can have zero to many files that can be referenced by a ContextOfUse Act. Once a file has been established any submission unit in any application to refer to that file.
File
The File Act defines the submitted document in a submission unit.
Attributes
-
File.id: The unique identifier that is used to refer to this act
-
File.text: The File.text attribute uses an encapsulated data (ED) type. The components of this data type will be used to transmit a document's URL (ED.reference), a document format or media type (ED.type). In addition, the ED type can be used to transmit the document itself (ED.BIN). However, this message will not allow the use of the ED.BIN attribute. To allow document re-use it is important that each file is transmitted separately from this message. The mechanism for packaging an HL7 Clinical Document Architecture (CDA) document in File.text is described in the CDA specification.
Relationships
-
Application: A file can be submitted in an application. Although that file can be reused within this application and in other application, please refer to specific implementation guide on how to reuse documents. There can be zero to many Files within an Application. For example, if a submission status is changed to obsolete no files will be submitted.
FileReference
A file can be used many times. Each time the file is used, that file has a different context of use. Accordingly, each context of use must refer to one file.
Attributes
-
FileReference.id: This is the same id that is used in the File Act.
Relationships
-
ContextOfUse: A context of use reference one file. In the case that a context of use is being made obsolete, there is no need for a file reference.
Keyword
A Keyword is a reference to the KeywordDefinition Act. One or more Keywords can be associated to a contect of use.
Attributes
-
Keyword.id: Reference to the KeywordDefinition.id. This field should only be used if there is not coding system equivalent
-
Keyword.code: Used if the keyword is from a coding system not from keyword definition.
Relationships
KeywordDefinition
A keyword definition contains name value pairs that are used within the context of an application. Each keyword is an item of information that provides context for the document(s) in a context of use. Keywords are used only to further define the context of a ContextOfUse, and the Keywords, by themselves, have no intrinsic value. Since one of the goals of this message was to create one message structure that can be used for all regulated product types, we decided not model individual keywords or keyword groups as classes and relate these classes to specific ContextOfUse codes.
Attributes
-
KeywordDefinition.id: The unique identifier that is used to refer to this act
-
KeywordDefinition.code: The type of Keyword (e.g., Manufacture, Dosage Form, Rout of Admin)
-
KeywordDefinition.statusCode: Active or nullified.
-
KeywordDefinition.effectiveTime: Signifies the keyword's creation time, when the keyword first came into being.
-
KeywordDefinition.value: The value of the KeywordDefination.code
Relationships
-
Application: A Keyword can be used in one to many context of use.
-
PreviousKeywordDefinition: This clone represents the source of a replacement relationship. One can only replace another KeywordDefinition. When the KeywordDefination is replaced, that KeywordDefinition is obsolete; therefore, that KeywordDefiniation cannot be used in a context of use.
PreviousKeywordDefinition
PreviousKeywordDefinition is used to replace an existing KeywordDefination. Once a KeywordDefinition is replaces, that KeywordDefination can no longer be associated with a context of use.
Attributes
-
PreviousKeywordDefination.id: Reference to the KeywordDefinition.id.
Relationships
-
KeywordDefinition: This clone represents the target of a replacement relationship. One can only replace another KeywordDefinition.
ContextOfUse
The ContextOfUse Act defines the use of the submitted document in the context of a submission unit. The document and its assignment to a particular code will be used to create a table of contents. This table of contents will be used by Regulatory Authorities to review an application. Based on regional guidance, a document can be submitted once and be referred to by other ContextOfUse's text attribute in the same submission unit, different submission unit for the same application, or different submission units in a different application.
Attributes
-
ContextOfUse.id: The unique identifier that is used to refer to this act
-
ContextOfUse.code: The code that specifies how the file is to be used within the submission process (e.g. Protocol, Summary Introduction). Note: ContextOfUse codes vary between different product types.
-
ContextOfUse.title: The title for the document in the associated assignment.
-
ContextOfUse.statusCode: See section "Document Identification, Revisions, and Addenda"
-
ContextOfUse.setId: See section "Document Identification, Revisions, and Addenda"
-
ContextOfUse.versionNumber: See section "Document Identification, Revisions, and Addenda"
Relationships
-
RelatedContextOfUse: This clone represents the source of a document relationship. The target is either being appended, revised, or transformed by the source document. One ContextOfUse can be the targets for many ParentContextOfUses. See section "Document Identification, Revisions, and Addenda"
-
SubmissionUnit: RelatedContextOfUses is the components of the submission unit. There can be one or more ContextOfUses within a submission unit.
-
Keyword: A ContextOfUse can be further defined, based on the ContextOfUse.code attribute, by zero to many Keywords. This is used to determine additional attributes of the document. (e.g., a document that is associated with a particular Study or Manufacturer). Only certain, well defined, ContextOfUse.code can be associated to a particular Keyword.
-
FileReference: A ContextOfUse refers to a File through the FileReference. Accordingly every ContextOfUse, must have one and only one FileReference.
RelatedContextOfUse
A ParentContextOfUse provides a relationship between a ContextOfUse and ContextOfUse that was recorded previously. See section "Document Identification, Revisions, and Addenda"
Attributes
-
RelatedContextOfUse.id: Reference to the ContextOfUse.id
-
ReleatedContextOfUse.versionNumber: See section "Document Identification, Revisions, and Addenda"
Relationships
-
sequelTo: Relates RelatedContextOfUse to the ContextOfUse and defines the sequence order of the ContextOfUse Act.
-
ContextOfUse: This clone represents the target of a document relationship.One ContextOfUse be associated with zero to many RelatedContextOfUses.
| Submisson MessageHMD | PORP_HD000001UV01 |
|
||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This is the HMD for the Regulated Product Submission, submission units message.
| Regulated Product Submission MT | PORP_MT000001UV01 | |
|
||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
The submission unit is sent from the application to the regultory authority
| Trigger Event | Regulatory Product Submission Unit Notification | PORP_TE000001UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Regulated Product Submission MT | PORP_MT000001UV02 |
| Sender | Regulatory Authority | PORP_AR000002UV01 |
| Receiver | Regulatory Authority | PORP_AR000002UV01 |
This Annex holds an Implementation Guide that has been developed to support the Implementation of Regulated Product Submission (RPS), Release 2 an HL7 draft standard for trial use.
This document is currently in a "stand-alone" format. HL7 currently has no approved format for implementation guides. When such a format becomes available, this document will be converted so that it can be represented here directly as domain content. Click here to download a copy of the approved document.
| Return to top of page |