IDMP

HL7 V3 IDMP CMM, R1
HL7 Version 3 Standard: Identification of Medicinal Products - Creation and Maintenance Messages, Release 1
DSTU Ballot 4 - May 2012

Responsible Group	Pharmacy Work Group HL7
Pharmacy WG Co-Chair	Tom de Jong tom@nova-pro.nl Nova Pro Consulting
Pharmacy WG Co-Chair	Hugh Glover, BSc, PhD hugh_glover@bluewaveinformatics.co.uk Blue Wave Informatics LLP
Pharmacy WG Co-Chair	Melva Peters melva.peters@gpinformatics.com Gordon Point Informatics Ltd
Vocabulary Facilitator	Julie James, MRPharmS julie_james@bluewaveinformatics.co.uk Blue Wave Informatics LLP
Model and Methodology Facilitator	Hugh Glover, BSc, PhD hugh_glover@bluewaveinformatics.co.uk Blue Wave Informatics LLP

HTML Generated: 2012-04-04T09:47:24

Content Last Edited: 2012-04-02T15:00:02

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.

View Revision Marks Hide Revision Marks

Preface
    i Notes to Readers
    ii Message Design Element Navigation
1 Overview
    1.1 Introduction & Scope
    1.2 Domain Information Models
    1.3 Storyboards
2 IDMP Creation and Maintenance Topic
    2.1 Introduction
    2.2 Application Roles
    2.3 Trigger Events
    2.4 Refined Message Information Models
    2.5 Hierarchical Message Descriptions
    2.6 Interactions
3 IDMP CMETS Topic
    3.1 Refined Message Information Models
    3.2 Hierarchical Message Descriptions
4 Quality Analysis Report Topic
5 CMETs Used by this Domain
6  Interactions Annex
    6.1 By Application Role
    6.2 By Trigger Event
    6.3 By Message Type
7  Glossary

The Identification of Medicinal Products (IDMP) Project is a Joint Initiative Council ISO/HL7 project that defines a series of domain information models for identification of medicinal products in the context of registration of a new product with a regulator, updating existing registrations and reporting of adverse events to a regulator. IDMP is balloting through ISO as a series of five specifications detailing how medicinal products should be described and includes supporting vocabulary sets in addition to the domain models.

The IDMP Messaging Model being balloted here is separate from the ISO/HL7 ballot described above though it draws heavily upon it and is consistent with the information models within it and within the HL7 Common Product Model topic. The objective here is to define messages for the flows of information required to send messages to and from the interested parties in order to create and establish a new or revised set of IDMP identifiers and associated vocabulary for a medicinal product, pharmeceutical product or substance.

May 2012 Ballot

After the January ballot, comments received have resulted in the following changes being made:

There was concern that processes that are the subject of this ballot overlap with those in the SPL and RPS ballots. While it is true that there is overlap, this cannot be avoided if we are to provide a standardised process that can be used in Realms where neither SPL nor RPS is in use. The process described here is intended to be a minimum process for transfer of data, and a tightly restricted set of CMETs for transport of that data. Provided that minimum is met, the objectives of IDMP can be met with other processes and less restrictive CMETs.
Balloters also expressed concern about the use of the IDMP CMETs rather than the full Common Product Model CMETs arguing that some attributes of the CPM CMETs were required for their maintenance process even though they were not IDMP items. This has been resolved by introducing a choice box to allow full CPM CMETs to be used in place of IDMP CMETs. To resolve the potential failure of interoperability when the sending party uses CPM CMETs and the receiving party expects IDMP CMETS (and vice versa) an XSLT transform will be provided to convert a message instance in one format into the other format. Since the IDMP CMETs are proper restrictions of the IDMP CMETs this is not a difficult tranform to create.
Balloters complained again about the use of acronyms, particularly the use of IDMP in artefact names. This has been avoided wherever possible
Fixed typos and rephrased some sections

January 2012 Ballot

Following feedback from the September Ballot the following changes have been made:

Fixed typos and rephrased some sections
Added in some storyboard narrative's that failed to publish in September
Balloters complained about the use of acronyms. The authors felt the repeatedly spelling out the acronyms would be unwieldy however the section on Abbreviations in the introduction has been expanded with material taken from the ISO FDIS 11615 standard
Some classes have been renamed by dropping "message" from in the name
A business process for PhPID Updates has been added
The CMET topic has been further expanded and is now normative
The Substances CMETs are now drawn from the Common Product Model topic directly

September 2011 Ballot

Following feedback from the May Ballot the following changes have been made:

A new introduction has been added to give context to the different sets of message flows and describe the architectures
The Creation and Maintenance Topic has been expanded to cover the entire lifecycle of a product in both architectures
The CMET topic has been expanded
Many artefacts have been renamed to improve clarity of explanation

May 2011 BallotBallots Prior to May 2010

The domain identified by the POME prefix originally dealt with the Medication model developed by the Pharmacy Work Group. This has been subsumed into the Common Product Model and the underlying model and derived CMETs are now presented there. Also under POME was the Medication Knowledgebase Query topic which was moved into the main Pharmacy domain (PORX) in January 2011.

▼ IDMP Creation and Maintenance Topic ()

	IMPID Assignment Request (POME_RM500110UV)
	MPID Update Request (POME_RM500180UV)
	PhPID Assignment Request (POME_RM500190UV)
	Substance ID Assignment Request (POME_RM500210UV)
	Substance ID Update Request (POME_RM500240UV)
	IMPID Update Request (POME_RM500270UV)
	MPID Assignment Request (POME_RM500160UV)
	PhPID Update Request (POME_RM500290UV)
	IMPID Assignment Notification (POME_RM500120UV)
	PhPID Assignment Notification (POME_RM500200UV)
	Substance ID Assignment Notification (POME_RM500220UV)
	MPID Assignment Notification (POME_RM500150UV)

▼ IDMP CMETS Topic ()

	R_MPID_ApplicationChoice (POME_RM514020UV)
	R_MPID_AssignedChoice (POME_RM514010UV)
	R_MPID_Assigned (POME_RM514011UV)
	R_PhPID_Application (POME_RM513021UV)
	R_PhPID_ApplicationChoice (POME_RM513020UV)
	R_PhPID_Assigned (POME_RM513011UV)
	R_PhPID_AssignedChoice (POME_RM513010UV)
	R_MPID_IdentifiedChoice (POME_RM514030UV)
	R_MPID_Identified (POME_RM514031UV)
	R_MPID_Application (POME_RM514021UV)

The Identification of Medicinal Products (IDMP) Messaging Model describes those flows of messages required to send information to and from the interested parties to create and establish identifiers and working vocabulary for identification of medicinal products, pharmeceutical products and substances.

The abbreviations and explanations below are generally taken from the ISO FDIS 11615:2011(E) Health informatics - Identification of Medicinal Products - Data elements and structures for the unique identification and exchange of regulated medicinal product information as indicated by the FDIS reference at the end of most notes.

Abbreviation	Description	Notes
GTIN	Global Trade Identification Number	GS1 unique identifier of items that are traded (e.g. Pharmaceuticals, Medical Devices) in the supply chain. More commonly known as "the bar code number". GS1 is the company that manages the GTINs. NOTE 1 A Global Trade Item Number (GTIN) is used to identify any item upon which there is a need to retrieve predefined information and that may be priced or ordered or invoiced at any point in any supply chain. GTINs may be 8, 12, 13 or 14-digits in length. (FDIS Ref: 3.1.34)
IBAID_1	Investigational Medicinal Product Batch Identifier	Required unique identifier allocated to a specific batch of an (Investigational) Medicinal Product, which appears on the outer packaging of the Investigational Medicinal Product. It is constructed by using the batch number assigned by the Manufacturer and the Exportation Date. NOTE This is for indexing purposes and to contribute to improving patient safety by allowing for the unique identification of an (Investigational) Medicinal Product at the package level. (FDIS ref 3.1.36)
IBAID_2	Investigational Medicinal Product Batch Identifier	Optional unique identifier allocated to a specific batch of an (Investigational) Medicinal Product, which appears on the immediate packaging, where this is not the outer packaging. It is constructed by using the batch number assigned by the Manufacturer and the Exportation Date. NOTE This is for indexing purposes and to contribute to improving patient safety by allowing for the unique identification of an (Investigational) Medicinal Product based at the level of the immediate container. (FDIS Ref: 3.1.37)
INN	International Non-proprietary Name	Official non-proprietary or generic name given to a pharmaceutical substance, as designated by the World Health Organization. (FDIS Ref: 3.1.41)
IMP	Investigational Medicinal Product	The pharmaceutical form of an active substance or placebo being tested or used as a reference in a clinical trial, including products already with a marketing authorisation but used or assembled (formulated or packaged) in a way different from the authorized form, or when used for an unauthorized indication, or when used to gain further information about the authorized form. (FDIS Ref: 3.1.41)
IMPID	Investigational Medicinal Product Identifier	Unique identifier allocated to an investigational Medicinal Product supplementary to any existing identifier as ascribed by a Medicines Regulatory Agency in a jurisdiction or a sponsor of a clinical trial NOTE This is for indexing purposes and to contribute to improving patient safety by allowing for the unique identification of Medicinal Products worldwide. (FDIS Ref: 3.1.46)
IPCID	Investigational Medicinal Product Package Identifier	Unique identifier allocated to an investigational Medicinal Product at package level supplementary to any existing identifier as ascribed by a Medicines Regulatory Agency in a jurisdiction or a sponsor of a clinical trial NOTE This is for indexing purposes and to contribute to improving patient safety by allowing for the unique identification of Medicinal Products worldwide. (FDIS Ref: 3.1.47)
MPID	Medicinal Product Identifier	Unique identifier allocated to a Medicinal Product supplementary to any existing authorisation number as ascribed by a Medicines Regulatory Agency in a jurisdiction. NOTE This is for indexing purposes and to contribute to improved patient safety by allowing for the unique identification of Medicinal Products worldwide. (FDIS Ref: 3.1.70)
PCID	Medicinal Product Package Identifier	Unique identifier allocated to a packaged Medicinal Product supplementary to any existing authorisation number as ascribed by a Medicines Regulatory Agency in a jurisdiction NOTE This is for indexing purposes and to contribute to improving patient safety by allowing for the unique identification of Medicinal Products worldwide. (FDIS Ref: 3.1.72)
PhPID	Pharmaceutical Product Identifier	Unique identifier for a pharmaceutical product - a generic concept that liniks together many different presentations of a set of ingredients.

The following drawing shows a stylised representation of the regulation and identification of a medicinal product during its lifecycle. There are many variations on this pattern (some of which are discussed further below) and these are achieved by combining or re-ordering the steps of the business processes.

Please note that in the descriptions that follow

A PharmaCo may decide not to continue with development of a product at any point up to its release to the market. Even if development is abandoned all identifiers issued up to that point will remain valid.
Application and Issuing of an identifier is shown as a simple process - in reality there is likely to be some interchange between the two parties to clarify certain details - the details of this messaging are not shown in this summary.
The links in each section will take the reader to a process model specific to that part of the process.

Step	Discussion
Exploratory development of New Moeity	A PharmaCo identifies a new substance, or a new way of presenting an existing substance or combination of substances. Before they can do any formal Clinical trials they have to have appropriate identifiers so that the regulators can track the material and relate it to other similar material
Issue new Substance ID	The regulator will arrange through an appropriate registration process for any new substances to be given globally unique identifiers. Click for Detailed Process Description(Jumps to the Storyboard section within the topic)
Issue PhPID	The particular combination of substances and presentation will be assigned a set of globally unique identifiers (Pharmaceutical Product Identifiers - PhPID) which can be used in subsequent analysis to associate information from comparable products. Click for Detailed Process Description(Jumps to the Storyboard section within the topic)
Issue IMPID	The Regulator will issue an IMPID that covers the use of the new moiety in a particular set of circumstances. Click for further discussion of process(Jumps to the Storyboard section within the topic)
Phase 1 Clinical Trials	The PharmaCo can now undertake the Phase 1 Clinical Trials For the purposes of this flow description we shall assume they then decide to continue to the next stage but in reality they may not take this any further.
Phase 2 and Phase 3 Clinical Trials	The development of the new moiety will continue through the trial stages and there will be dialog with the Regulator during this - none of that dialog is the subject of IDMP messages and will not be considered here.
Submit Marketing Authorisation Application	Once trials are complete the PharmaCo may decide to market the product. If so they must apply to one or more regulators in different regions for an appropriate Marketing Authorisation and as part of this they will be issued with a Medicinal Product Identifier. This is specific to the Marketing Authorisation and Region and the fine details of the application process will be different between different regions. Click for Detailed Process Description(Jumps to the Storyboard section within the topic)
Product Released to Market	The new moiety has now become a medicine that can be used according to the terms of its Marketing Authorisation. The availability of this medicine and its associated information (including identifiers) has to be made known to potential users.
Updates, Revisions, Variations and Extensions as required (also Suspensions) Approve Variations	During the life of a product the PharmaCo may seek to use it for purposes beyond the original Marketing Authorisation or require the modification of the authorisation. The product may also be in short supply and be temporarily unavailable All these steps are managed by dialog between PharmaCo and Regulator. When supporting information for a medicinal product changes (eg new clinical information is added to an SmPC or PIL a new "version" of the appropriate identifier is created. Click for Detailed Process Description(Jumps to the Storyboard section within the topic)
Product Discontinued or Withdrawn Manage Discontinuation or Withdrawal	At some point a PharmaCo may decide to stop marketing a product (discontinue), or due to safety concerns the regulator may require it to be removed from the market (withdrawn). These steps are managed by dialog between PharmaCo and Regulator.

Go To Top

Diagram

Description

All of the RMIMs presented in this domain follow a very similar pattern. Rather than present essentially the same walkthrough for each a general walkthrough is presented here and is refered to from each RMIM together with a brief note of the differences. Before reading these walkthroughs look at the dynamic model that is presented - much more of the actual business process is presented there.

The focal act is a registration act since the overall process we are working with is one of registering details of a Substance, a PhPID, and IMPID or an MPID, or alternatively modifying those details - that is changing the registration. The Registration act has an ID and this is used to identify a specific registration act, and hence allow us to relate different registrations together. The most obvious one being an update of an earlier request.

In order to link Registration acts together there is a PriorRegistration act that carries the id of an earlier registration act. It is linked to the focal registration act by any one of a Fullfillment, Replacement or Update relationship.

Both the focal registration act and the prior registration act can be linked to a CMET that provides the detail of the appropriate IDMP identifier and the supporting information. These CMETs are all essentially flavours of the Common Product Model differing in which elements are optional. Clearly for an application for an identifier the ID cannot be provided since it has not been issued - but when the identifier is issued the ID must be mandatory. The first CMET is the "application" flavor while the second is the "assigned" flavor.

Walkthroughs for the CMETS are here:

Every message has an Applicant and an Issuer. The Applicant details are represented in the Author, Performer and Receiver participations to the R-AssignedParty CMET. The Issuer details could have been represented in a similar way, but in other similar regulatory focussed messages (ICSR and SPL for instance) the Regulator and Territory are represented as players and scoper of a TerritorialAuthority role associated with a Contract Event act. The same pattern has been adopted here.

Lastly there is an Annotation CMET which has two functions. Firstly it is used for any formal notes that have to be attached to a message that are not otherwise modelled. Secondly it is used to itemise specific queries when an application or update is deemed to be incomplete.

There are 12 RMIMs presented, 3 each for the 4 different IDs that must be managed. The three patterns are:

Assignment Request - the CMET will be an Application flavor.
Assignment Notification - the CMET will be an Assignment flavor - this is the most complete statement of content equivalent to a "universal" flavor.
Update Request - this can be further divided to cover the obvious case of where additional information is provided in support of an earlier application; but it also covers the case where the Issuer wishes to ask for clarification from the Applicant, and similarly the response will also be an update. Some updates cover the first use of an ID for those realms where MPIDs are pre-issued and the Issuer must be informed when they are used; and it also covers the case when a product is retired and its ID is no longer in use.

Registration

This is the focal act of the message; it is a registration act, for which the associated "registered subject"" is a choice from the ConceptBeingProcessed choice box - either a Medicinal Product (MPID or PhPID) or a Substance

This uses the premise that the process of managing IDMP identifiers is - in HL7 messaging terms - a "registration" process.

It is important to understand that this act and its identifiers refers only to the registration messages, not to the actual registration event. Identification of the registration event and its associate identifiers is dealt with inside the CMET structures which are specific to Substance ID, PhPID, and IMPID or MPID as appropriate.

id - The identifier(s) for the Registration primarily for traceability. The datatype is discrete set (an unordered collection of values that contains discrete distinct values) of identifiers; therefore more than one identifier may be provided if this is required for a particular business use case

code - IDMP specific vocabulary to define the type of request for instance MPID vs MPID + PhPID.

effectiveTime - The time when the registration message becomes "active". This attribute is concerned with process control, the actual registration or updates to an ID are recorded within the CMET.

activityTime - This describes how long the registration takes - the "low time" attribute in the datatype would be when the registration is initiated and the "high time" attribute in the datatype will be when its finally finished. This attribute is concerned with process control, the actual registration or updates to an ID are recorded within the CMET.

confidentialityCode - This attribute indicates the sensitivity/confidentiality of the information in the registration.

languageCode - The (primary) language of the registration, and the information provided in support of the registration

subject1

This structure relates the main registration act to the set of information about the medicinal product or substance that is being "registered" as having an IDMP code.

SubjectOf

This structure is used when there is a requirement to attach annotation(s) to the registration act. These annotations may include identifying specific fields within the application that are inadequately defined, or that require further definition.

InFullfillmentOf

Allows a registration event to be related to the initial registration request that is being fulfilled

UpdateOf

Indicates that the target act identifies an earlier application that is now being updated. The information content of the earlier application can be indicated using one of the attached CMETs.

PriorRegistration

This is the reference to a previously communicated registration request or event whose information is being replaced.

id - This is the identifier (or identifiers) for the registration act being replaced

subject

This structure relates a previous registration act to the set of information about the medicinal product or substance that was originally being "registered" as having an IDMP code.

Author

This structure is used to describe the person or organisation who is the author of the registration information. The author information is described using the Assigned Party CMET

signatureCode - This identifies whether the author of the registration act and its information has signed the registration

signatureText - This is most commonly used for an electronic signature which by means of checksums guarantees the validity of the message. Alternatively it could also be used for a representation of a conventional human signature if that were useful.

Performer

This structure is used to describe the person or organisation who performs the registration. The performer information is described using the Assigned Party CMET

signatureCode - This identifies whether the performer of the registration has signed the registration

signatureText - This is most commonly used for an electronic signature which by means of checksums guarantees the validity of the message. Alternatively it could also be used for a representation of a conventional human signature if that were useful.

Verifier

This structure is used to describe the person or organisation who verifies the details of the registration. The verifier information is described using the Assigned Party CMET

Receiver

This structure is used to describe the person or organisation to whom the registration is sent. The receiver information is described using the Assigned Party CMET

subject2

This structure describes the registration as the subject of a Contract Event.

The structure that is being linked here is the conventional means used by HL7 for describing regulatory authorities.

component

This structure is used when there is a requirement to show that one registration act is a component of another. The definitions of the attributes are as follows:

sequenceNumber - This describes the ordering of any component registration acts (e.g. if both Substance ID and PhPID were being requested together, the Substance ID must be processed first)

priorityNumber - Indicates which of several equivalent actions should be taken first.For instance if a complex application required 2 PhPIDs we might want to ensure the more difficult one was processed first. There may be very occasions where this attribute is required.

seperatableInd - If set, shows that the components must all be considered together, that one is not meaningful without the others.

For example this might happen if a single registration process is registering MPIDs for a compound product that is made up of two component products. Both the compound product and the components products would each have separate sets of supporting information.

This would require a parent registration act and three child registration acts, one for the compound and one for each of components. The attribute sequenceNumber could be used to indicate that the two components should be registered before the compound, and priorityNumber could be used to show which of the that one of the two components has greater importance. Having greater importance does not mean that it should be processed first, merely that it is more important - there may be other business pressures that are not known that govern this. The information on the compound only makes sense in the context of its two components and the seperatableInd attribute can be set to show that the information on either the compound or the components should not be considered without also considering the others.

ContractEvent

This structure can carry information about any associated regulatory business processes that are important to the IDMP request (e.g. an authorisation process). It is is a parallel structure to "approval" in Common Product Model

id - This is an identifier or identifiers for the contract act

code - Specifies the kind of approval process followed.

effectiveTime - This describes the valid time for the "contract" (for example: the date of granting a marketing authorisation)

author

This describes the "author" of the regulatory event - the agency and the jurisdiction (territory) that manages the event

TerritorialAuthority

The role provides a linkage to the agency that authors the approval, and to the territory over which that agency has jurisdiction. The purpose of this role is to allow either the Country code alone or the Agency or both to be specified as the author of approvals.

Agency

This describes the agency entity that is the author of the regulatory contract event

id - A unique identifier for the agency

name - This is used to record the text name for the agency

telecom - This is used to record the telecoms information for the agency

addr - This is used to record the address for the agency

Territory

This describes the jurisdictional area that the regulatory contract event is applicable for

code - This code identifies the actual jurisdiction

name - This attribute can carry the name of the jurisdiction, if there is no coded information available

Go To Top

► Storyboards (Sorted by Title)

▼ Storyboards (Sorted by Display Order)

	Compound Process - Existing Product (DOME_ST561000UV)
	IMPID Update Request (DOME_ST542100UV)
	IMPID Assignment Request (DOME_ST541100UV)
	MPID Assignment Request (DOME_ST551100UV)
	MPID Update Request (DOME_ST552100UV)
	PhPID Assignment Request (DOME_ST531100UV)
	PhPID Update Request (DOME_ST532000UV)
	Substance ID Assignment Request (DOME_ST521100UV)
	Substance ID Update Request (DOME_ST522100UV)

For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.

Purpose

The other storyboards presented show elements of a complete business process for managing IDMP identifiers. There are many ways in which they can be combined to operate a real world system for that task and it is not the aim of this domain to be prescriptive as to how that is done. However to illustrate how a real world system COULD be constructed the storyboard presented here takes some of the elements presented in the other storyboards and combines them into a more complex process - albeit one that leaves out a number of important aspects. This is not meant as an absolute statement of how a process HAS to work, it is just an example. Implementers establishing actual systems will have to take the components that best meet their specific requirements.

Exoticillin has been on the market for several years and was granted its Marketing Authorisation before the IDMP identifiers were developed. As part of the IDMP rollout the manufacturer (Applicant) must now ask their Regulator (Issuer) to provide a suitable MPID. The manufacturer sends an MPID Assignment Request message to the Regulator.The Regulator checks that an appropriate set of Substance IDs and PhPIDs are available for Exoticillin and where necessary sends a message requesting the necessary IDs to the relevant Issuer.Once the Substance IDs and PhPIDs are available the Regulator completes the rest of the process and issues the required MPIDs.

The business process shown here does not include any processes for Issuers posing questions of clarification to the Applicant and getting responses. The process would be exactly as shown elsewhere and has been omitted to keep the diagram to a reasonable size. For the same reasons the actions undertaken if a request for a Substance ID or PhPID was not granted have been glossed over.

Diagram

Purpose

The drawing below shows the basics of the process for update of an IMPID. This follows exactly the same pattern as for update of MPID, Substance ID and PhPID and the text below is also essentially the same.

The Application Roles involved are abstract roles and constitute one party making an application for a new IMPID and the other party being responsible for issuing that ID. Clearly a Pharmaceutical Company requiring an update for an IMPID is an Applicant and the Regulator receiving the application is an Issuer. If then the Regulator has to apply to (say) a Central Authority for the update, the Regulator becomes an Applicant and the Central Authority is an Issuer. Once the Central Authority has made a determination and communicated back to the Regulator, the Regulator resumes its role as the Issuer and transmits the determination back to the Applicant (the Pharmaceutical Company).

The process begins when the Applicant (usually a Pharmaceutical Company) has new or revised information about an investigational product for which they already have an ID.

The Applicant sends a message to the Issuer. When the Issuer begins to process the message one of three possible things can happen:

The Issuer is unclear or unhappy with the information provided and seeks further clarification.
The Issuer accepts the update and sends an acknowledgement to the Applicant.
The Issuer does not accept the update and refuses the update request stating the reason for refusal.

The Assigning Authority goes through an essentially similar process and the application to update may be rejected, or accepted. Whatever the outcome, the result is passed back to the Regulator for them in turn to pass back to the Pharmaceutical Company.

During the process questions may arise that the Issuer has to pass back to the Applicant - there is a processing loop for questions to be asked and responses provided. It may be that if the Regulator is taking the role of Applicant they may themselves have to pass these questions back to the Pharmaceutical Company and when an answer is received pass it back to the Assigning Authority. There is no reason why the Assigning Authority cannot ask questions directly of the Pharmaceutical Company - no change is required to the messaging model.

Diagram

**Interaction List**
IMPID Update Request	POME_IN500470UV
IMPID Detail Clarification Request	POME_IN500450UV
IMPID Detail Clarification Response	POME_IN500460UV
IMPID Update Request Granted	POME_IN500480UV
IMPID Update Request Refused	POME_IN500490UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The stories that follow illustrate how this may work out in practice.

Note: NOTE: These stories are for illustration only and do not represent a recommended implementation

Fred's Farmaceuticals Inc. are progressing the Phase 3 clinical studies of Exoticillin formulated as a basic capsule product. However, the protocol for the trial is being changed slightly, with additional contra-indications (exclusions) for the patient population. This requires them to make an update to the information that supports the IMPID for the Exoticillin investigative product.

Fred's Farmaceuticals send the request to update the IMPID information to their Regulator authorizing the trial protocol, who will act as the Issuer of the IMPID. This requires interaction IMPID Update Request (POME_IN500470UV).

The Issuer then considers the request and determines that the information is correct and the update is accepted - this is interaction IMPID Update Request Granted (POME_IN500490UV).

Purpose

The drawing below shows the basics of the process for assignment of an IMPID.

The Application Roles involved are abstract roles and constitute one party making an application for a new investigational medicinal productand the other party being responsible for issuing that ID. Clearly a Pharmaceutical Company requiring an ID for a new moiety is an Applicant and the Regulator receiving the application is an Issuer.

It is unlikely that, for IMPIDs, that the Regulator will have to apply to a Central Authority for an ID, but the process and the messages would support this should this be the business requirement. In this case the Regulator would become an Applicant and the Central Authority is an Issuer. Once the Central Authority has made a determination and communicated back to the Regulator, the Regulator would resume its role as the Issuer and transmit the determination back to the Applicant (the Pharmaceutical Company).

The process begins when the Applicant (usually a Pharmaceutical Company) has completed Phase 1 Clinical Trials and now need to progress to Phase 2 and 3. To do this they have to have an identifier for the investigational product involved.

The Applicant sends a message to the Issuer. At this point one of three possible things can happen:

The Issuer can see that the product for which an ID is required is not one for which an ID will be issued - if this the case the application will be rejected stating the reason for rejection.
The Issuer recognises that the product is known and already has an ID. The ID will then be sent to the Applicant.
The Issuer decides a new investigational product ID is required and has to adopt the role of Applicant and pass the request to the Assigning Authority who will be in the role of Issuer.

The Assigning Authority goes through an essentially similar process and the application may be rejected, or a suitable new ID is found or created. Whatever the outcome, the result is passed back to the Regulator for them in turn to pass back to the Pharmaceutical Company.

Diagram

**Interaction List**
IMPID Assignment Request	POME_IN500110UV
IMPID Detail Clarification Request	POME_IN500450UV
IMPID Detail Clarification Response	POME_IN500460UV
IMPID Assignment Request Granted	POME_IN500120UV
IMPID Assignment Request Refused	POME_IN500130UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The stories that follow illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation .

Fred's Farmaceuticals Inc. are embarking on a tranche of Phase 3 clinical studies of Exoticillin formulated as a basic capsule product. Alongside the process of registration of the trial protocol, they apply for an IMPID for the investigative product, to use in safety reporting.

Fred's Farmaceuticals send the request to their Regulator authorizing the trial protocol, who will act as the Issuer of the IMPID. This requires interaction IMPID Assignment Request (POME_IN500110UV).

The Issuer then considers the request and determines that a new IMPID is required - this is interaction IMPID Assignment Request Granted (POME_IN500120UV).

Purpose

The drawing below shows the basics of the process for assignment of a new MPID. It can also be used to obtain an MPID for products already marketed but for which an MPID has not yet been assigned.

The Application Roles involved are abstract roles and constitute one party making an application for a new MPID and the other party being responsible for issuing that ID. Clearly a Pharmaceutical Company requiring an ID for a new medicinal product is an Applicant and the Regulator receiving the application is an Issuer.

It is unlikely that for MPIDs the Regulator has will have to apply to a Central Authority for an ID, but the process and the messages would support this should this be the business requirement. In this case the Regulator would become an Applicant and the Central Authority an Issuer. Once the Central Authority has made a determination and communicated back to the Regulator, the Regulator resumes would resume its role as the Issuer and transmits the determination back to the Applicant (the Pharmaceutical Company).

The process begins when the Applicant (usually a Pharmaceutical Company) has completed all the Clinical Trials and now applies for a marketing authorization. To do this they have to have an identifier for the product involved.

There are differences between regions in the way that this process works. For instance in the USA Pharmaceutical Companies are issued with a block of IDs to be used for new marketing authorizations as they wish. In contrast in Europe the company has to request an ID from the issuer of the marketing authorization.

The process description in this section ONLY applies to the process of requesting an identifier (as practiced in Europe for instance). It does NOT apply to the process where the identifier is pre-issued (as in the USA). The correct process to follow for the pre-issue case is the MPID Update process.

Click for MPID Update process

The Applicant sends a message to the Issuer. At this point one of three possible things can happen:

The Issuer can see that the product for which an ID is required is not one for which an ID will be issued - if this the case the application will be rejected stating the reason for rejection.
The Issuer recognises that the product is known and already has an ID. The ID will then be sent to the Applicant.
The Issuer decides a new product ID is required and has to adopt the role of Applicant and pass the request to the Assigning Authority who will be in the role of Issuer.

Diagram

**Interaction List**
MPID Assignment Request	POME_IN500170UV
MPID Detail Clarification Request	POME_IN500500UV
MPID Detail Clarification Response	POME_IN500510UV
MPID Assignment Request Granted	POME_IN500180UV
MPID Assignment Request Refused	POME_IN500190UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The story that follows illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation.

Fred's Farmaceuticals Inc. have finished the studies on the antibiotic Exoticillin and are in the process of obtaining a marketing authorization for the medicinal product ExotoKillin.

Since they are based in Germany, but they wish to have a pan-European marketing authorization, Fred's Farmaceuticals send the request to their centralized Regulator who will act as the Issuer. This requires interaction MPID Assignment Request (POME_IN500170UV).

The Issuer then considers the request and determines that a new MPID is required - this is interaction MPID Assignment Request Granted (POME_IN500180UV).

Purpose

The following drawing shows the message flows that may exist for update of the information associated with a MPID.

The Application Roles involved are abstract roles and constitute one party making an application for an update and the other party being responsible for authorising and effecting that update.

In some regions (for example the USA) MPIDs are pre-issued to a Pharmaceutical Company. When they wish to use an MPID for a new product they do NOT use the MPID Creation process instead they submit an UPDATE for that ID associating it with the relevant information.

The process begins when the Applicant (usually a Pharmaceutical Company) has new or revised information about an existing Marketed Product for which they already have an ID, or, for the pre-issue business architecture, when the Applicant wishes to assign a previously unused pre-issued ID to a new medicinal product.

The Applicant sends a message to the Issuer. When the Issuer begins to process the message one of three possible things can happen:

The Issuer is unclear or not satisfied with the information provided and seeks further clarification.
The Issuer accepts the update and sends an acknowledgement to the Applicant.
The Issuer does not accept the update and refuses the update request stating the reason for refusal.

The Assigning Authority goes through an essentially similar process and the application to update may be rejected or accepted. Whatever the outcome, the result is passed back to the Regulator for them in turn to pass back to the Pharmaceutical Company.

Diagram

**Interaction List**
MPID Update Request	POME_IN500298UV
MPID Detail Clarification Request	POME_IN500500UV
MPID Detail Clarification Response	POME_IN500510UV
MPID Update Request Granted	POME_IN500300UV
MPID Update Request Refused	POME_IN500310UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The stories that follow illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation.

Fred's Pharmaceuticals is marketing the medicinal product ExotoKillin throughout Europe. Post-marketing surveillance uncovers a new adverse event, discolouration of the skin of the toes in a very small number of patients. Information about this adverse event is added to the Summary of Product Characteristics, and this requires an update to the MPID information for ExotoKillin. At the same time they also add a 2g tube pack in addition to the 5g tube that already exists.

The adverse event is reported using an ICSR message.

This updated product information is submitted to the Regulator for verification using the interaction MPID Update Request (POME_IN500298UV).

The Regulator then considers the all the information and determines that the MPID supporting information has been correctly updated and issues a new PCID (pack identifier). They then notify Fred's Farmaceuticals of this using the interaction MPID Update Request Granted (POME_IN500300UV).

Fred's Farmaceuticals Inc., the US subsidiary of the German parent company, is obtaining a obtaining a marketing authorization for the medicinal product ExotoKillin for the USA.

Fred's Farmaceuticals Inc. have a set of unused MPIDs that have been issued to them by their Regulator. They select one of these MPIDs for the medicinal product ExotoKillin and, along will all the relevant supporting information about the medicinal product ExotoKillin, they submit this to the Regulator for verification using the interaction MPID Update Request (POME_IN500298UV).

The Regulator then considers the all the information and determines that the MPID has been correctly assigned and therefore they accept the "update" - this is interaction MPID Update Request Granted (POME_IN500300UV).

Given that this story is based in the US it is likely that the same end results could be achieved using the RPS standard. It is less likely that this would be an option in Europe.

Purpose

The following drawing shows the message flows that may exist for issue of a single PhPID or a set of PhPIDs to support product development. It can also be used to obtain PhPIDs for products already marketed.

The Application Roles involved are abstract roles and constitute one party making an application for a PhPID or set of PhPIDs and the other party being responsible for issuing that ID/those IDs. A Pharmaceutical Company requiring PhPID(s) for a product is an Applicant and the Regulator receiving the application is an Issuer. If then the Regulator has to apply to (say) a Central Authority for an ID the Regulator becomes an Applicant and the Central Authority is an Issuer. Once the Central Authority has made a determination and communicated back to the Regulator, the Regulator resumes its role as the Issuer and transmits the determination back to the Applicant (the Pharmaceutical Company).

The process may begin when the Applicant (usually a Pharmaceutical Company) has either a new moiety or a new formulation of an existing moiety or a new combination of moieties/formulations that they wish to research in clinical trials. To do this they have to have identifiers for the presentation(s) involved.

The process may also begin when the Applicant (usually a Pharmaceutical Company) wishes to or is required to obtain PhPIDs for existing products.

The Applicant sends a message to the Issuer. At this point one of three possible things can happen:

The Issuer can see that the set of information for which an ID or set of IDs is required is not one for which an ID will be issued - for example one of the defining concepts (substance, administrable dose form etc.) is not valid. If this is the case the application will be rejected stating the reason for rejection.
The Issuer recognises that the set of information corresponds with an existing know set and already has an appropriate set of PhPIDs. These IDs will then be sent to the Applicant.
The Issuer decides one or more new PhPIDs is required and has to adopt the role of Applicant and pass the request to the Assigning Authority who will be in the role of Issuer.

The Assigning Authority goes through an essentially similar process and the application may be rejected, or a suitable (new) ID or set of IDs is found or created. Whatever the outcome, the result is passed back to the Regulator for them in turn to pass back to the Pharmaceutical Company.

Diagram

**Interaction List**
PhPID Assignment Request	POME_IN500320UV
PhPID Detail Clarification Request	POME_IN500430UV
PhPID Detail Clarification Response	POME_IN500440UV
PhPID Assignment Request Granted	POME_IN500330UV
PhPID Assignment Request Refused	POME_IN500340UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The three stories that follow illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation

Fred's Farmaceuticals Inc. have been investigating the antibiotic properties of various novel substances and have now synthesised a new material Exoticillin Trihydrate for which they have already obtained a Substance ID, but they need a set of PhPIDs, based on the substance itself and an initial administrable dose form to be used in the early trials.

Since they are based in the USA Fred's Farmaceuticals send the request to their Regulator who will act as the Issuer. This requires interaction PhPID Assignment Request (POME_IN500320UV).

The Issuer then considers the request and determines that a new PhPID is indeed required.

Having received the request from Fred's Farmaceuticals the Regulator must itself make a request to the PhPID Assigning Authority for IDs to be issued. The Regulator therefore becomes an Applicant and the PhPID Assigning Authority becomes the Issuer.

As above the Applicant uses interaction PhPID Assignment Request (POME_IN500320UV) to request the ID and the Issuer uses interaction PhPID Assignment Request Granted (POME_IN500330UV) to send a back the issued ID(s).

Note: Since PhPIDs can relate to many different medicinal products around the globe, if the requested PhPIDs already exist, the Assignment Request Granted message can still be used to return the relevant PhPID identifier information to the Applicant.

Narrative Example

The story that follows focuses on illustrating the process involved when insufficient or incorrect information is present in a PhPID Request, and illustrates the Enquiry process.

Note: There is no "refusal" of a PhPID request as such, as all medicinal products shall have a set of PhPIDs.

In real life this story would probably involve both a Regulator and a PhPID Assigning Authority and the process flow would go from Pharmaceutical Company to Regulator to PhPID Assigning Authority and then back again. For simplicity the necessity for the Regulator to play the role of both Issuer and Applicant will be omitted here. This duality was illustrated in the previous storyboard .

Note: This story is for illustration only and does not represent a recommended implementation.

Creation of PhPID With Enquiry (POME_SN531120UV)

Fred's Farmaceuticals Inc. have a new modified release dose form which they want to use for the formulation of Exoticillin Trihydrate to improve its duration of action. They require new PhPIDs for this product with the new dose form. Fred's Farmaceuticals request PhPIDs from the Issuer.

This requires interaction PhPID Assignment Request (POME_IN500320UV).

The Issuer considers the request and is concerned that the dose form as identified is not using a valid dose form ID. The Issuer sends a request for more information using interaction PhPID Detail Clarification Request (POME_IN500430UV). The Applicant (Fred's Farmaceuticals) reviews the information and sends revised dose form information to the Issuer using interaction PhPID Detail Clarification Response (POME_IN500440UV). This indicates that the dose form is a modified release capsule.

The Issuer decides that since the dose form is a modified release tablet, there is already a set of PhPIDs that reflect the relevant combination of substance and administrable dose form. The Issuer therefore uses interaction PhPID Assignment Request Granted (POME_IN500330UV) to communicate the PhPID information back to the Applicant.

Purpose

PhPIDs are issued on the basis of a set of existing IDs for substance, form etc. Once issued that combination of substance(s) and strength(s) in that dose form will always have that set of PhPIDs. If the underlying information for, say, substance changes sufficiently for the ID to change a new PhPID will be required, conversely if the substance information does not change sufficiently to warrant a new identifier then the PhPID will remain unchanged.

The one exception is where the status of a PhPID has to be changed because one of the components has a change in status. For example if a PhPID is issued against a set of 3 ingredient substances and then one of the ingredient substances is withdrawn then the entire PhPID set will have to change from "Live" to "Withdrawn".

The update process for a PhPID that has been issued is therefore strictly limited to status changees only.

Diagram

**Interaction List**
PhPID Update Request Granted	POME_IN500530UV
PhPID Detail Clarification Request	POME_IN500430UV
PhPID Update Request Refused	POME_IN500540UV

Purpose

The following drawing shows the message flows that may exist for issue of a new Substance ID.

The Application Roles involved are abstract roles and constitute one party making an application for a new substance ID and the other party being responsible for issuing that ID. Clearly a Pharmaceutical Company requiring an ID for a new moiety is an Applicant and the Regulator receiving the application is an Issuer. If then the Regulator has to apply to (say) a Central Authority for an ID the Regulator becomes an Applicant and the Central Authority is an Issuer. Once the Central Authority has made a determination and communicated back to the Regulator, the Regulator resumes its role as the Issuer and transmits the determination back to the Applicant (the Pharmaceutical Company).

The process begins when the Applicant (usually a Pharmaceutical Company) has found a new moiety that they wish to engage in Phase 1 Clinical Trials. To do this they have to have an identifier for the substance(s) involved.

The Applicant sends a message to the Issuer. At this point one of three possible things can happen:

The Issuer can see that the substance for which an ID is required is not one for which an ID will be issued - for example a compound that is a mixture of substances. If this the case the application will be rejected stating the reason for rejection.
The Issuer recognises that the substance is a known substance and already has an ID. The ID will then be sent to the Applicant.
The Issuer decides a new Substance ID is required and has to adopt the role of Applicant and pass the request to the Assigning Authority who will be in the role of Issuer.

Diagram

**Interaction List**
Substance ID Assignment Request	POME_IN500350UV
Substance Detail Clarification Request	POME_IN500380UV
Substance Detail Clarification Response	POME_IN500390UV
Substance ID Assignment Request Granted	POME_IN500360UV
Substance ID Assignment Request Refused	POME_IN500370UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The three stories that follow illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation

Create New Substance ID (POME_SN521110UV)

Fred's Farmaceuticals Inc. have been investigating the antibiotic properties of various novel substances and have now synthesised a new material Exoticillin Trihydrate. To begin Phase 1 clinical Trials they need a Substance ID for this material.

Since they are based in the USA Fred's Farmaceuticals send the request to their Regulator who will act as the Issuer. This requires interaction Substance ID Assignment Request (POME_IN500350UV).

The Issuer then considers the request and determines that a new substance ID is indeed required.

Having received the request from Fred's Farmaceuticals the Regulator must itself make a request to the Substance ID Assigning Authority for an ID to be issued. The Regulator therefore becomes an Applicant and the Substance ID Assigning Authority becomes the Issuer.

As above the Applicant uses interaction Substance ID Assignment Request (POME_IN500350UV) to request the ID and the issuer uses interaction Substance ID Assignment Request Granted (POME_IN500360UV) to send a back the newly issued ID

If Fred's Farmaceuticals had been based in Japan they would have sent their request directly to their local Substance ID Assigning Authority not to their Regulator. The only practical difference this makes is that the Issuer would be the Substance ID Assigning Authority not the Regulator. The set of interactions used would remain the same.

Narrative Example

The story that follows focuses on illustrating the process involved when insufficient information is present in a Substance ID Request, and also illustrates the rejection of the request. The middle part of the story concerned with Enquiry could be used as part of other stories.

In real life this story would probably involve both a Regulator and a Substance ID Assigning Authority and the process flow would go from Pharmaceutical Company to Regulator to Substance ID Assigning Authority and then back again. For simplicity the necessity for the Regulator to play the role of both Issuer and Applicant will be omitted here. This duality was illustrated in the previous storyboard .

Note: This story is for illustration only and does not represent a recommended implementation.

Rejection of New Substance ID Request After Enquiry (POME_SN521120UV)

Fred's Farmaceuticals Inc. have a new antibiotic Exoticillin Trihydrate (for which a Substance ID has been obtained) but their latest formulation requires a novel adjuvant to improve efficacy. They require a Substance ID for this adjuvant.

Fred's Farmaceuticals request a new Substance ID from the Issuer. This requires interaction Substance ID Assignment Request (POME_IN500350UV)

The Issuer considers the request and is concerned that composition of the adjuvant is not sufficiently clearly stated in the request. The Issuer sends a request for more information using interaction Substance Detail Clarification Request Substance Detail Clarification Request (POME_IN500380UV).

The Applicant (Fred's Farmaceuticals) sends additional information to the Issuer using interaction Substance Detail Clarification Response (POME_IN500390UV). This indicates that the adjuvant is a mixture of already known substances.

The Issuer decides that since the adjuvant is a mixture of known substances there are no grounds for creating a new Substance ID for the adjuvant. The Issuer therefore uses interaction Substance ID Assignment Request Refused (POME_IN500370UV) to communicate both the outcome of the original request and to convey the reason for rejection.

Purpose

The following drawing shows the message flows that may exist for update of the information associated with a Substance ID.

The Application Roles involved are abstract roles and constitute one party making an application for an update and the other party being responsible for authorising and effecting that update.

The process begins when the Applicant (usually a Pharmaceutical Company) has new or revised information about an existing substance for which they already have an ID.

The Applicant sends a message to the Issuer. When the Issuer begins to process the message one of three possible things can happen:

The Issuer is unclear or unhappy with the information provided and seeks further clarification.
The Issuer accepts the update and sends an acknowledgement to the Applicant.
The Issuer does not accept the update and refuses the update request stating the reason for refusal.

Diagram

**Interaction List**
Substance ID Update Request	POME_IN500400UV
Substance Detail Clarification Request	POME_IN500380UV
Substance Detail Clarification Response	POME_IN500390UV
Substance ID Update Request Granted	POME_IN500410UV
Substance ID Update Request Refused	POME_IN500420UV

Narrative Example

The Application Roles used in the interactions are abstract and in real life will be played by a variety of organisations. The story that follows illustrate how this may work out in practice.

Note: These stories are for illustration only and do not represent a recommended implementation

'Update Substance Information(POME_SN522110UV)

Fred's Farmaceuticals Inc. have been developing their new antibiotic Exoticillin Trihydrate. They have now developed the bulk manufacturing process and they wish to have this recorded and the Substance ID updated to reflect this.

Fred's Farmaceuticals (Applicant) send the update request to their Regulator (Issuer). This requires interaction Substance ID Update Request (POME_IN500400UV).

The Issuer then considers the request, accepts it and makes the necessary update. The then send an acknowledgement back to the Applicant using interaction Substance ID Update Request Granted (POME_IN500410UV)

View Revision Marks Hide Revision Marks

Return to top of page

IDMP

Table of Contents

Preface