Regulatory Hub and External Regulatory Reporting
Almost every product sold today requires some form of regulatory marketing authorization to legally sell into a country or region. Companies must also monitor the safety of their products and report any potential safety issues. market authorization typically requires a submission of the product information in a country or region-specific format, for every country or region where it is sold. Typically, market authorizations must be renewed annually or updated when the product changes. Product safety reports also rely on the product data, and their format is specific to a geography.
The following image shows the regulatory submission architecture.
To to provide a flexible way to stay current with the ever-changing regulatory updates, PTC offers the Regulatory Hub capability. This enables you to use Regulatory reports and also to develop custom offerings. PTC provides a sample custom submission that can be used as a reference to create submission solutions. The Regulatory Hub example is created using the Customer Experience module in Windchill, with the report persistence and PDF generation via the ThingWorx Platform.
You can customize the configuration to use the ThingWorx internal server or a remote server for the communication between Windchill and ThingWorx. The internal and external customizations can reside in the project at the same time, but depending on the configuration trigger, the corresponding customization is initiated. This out-of-the-box sample code (SRHeMDRDist.zip) after extractions shows the following folders:
• doc-files – Material for reference
• src- Windchill source files for the Regulatory hub setup
• src_externsion – Source files for setting up the Regulatory hub to use the ThingWorx server
• src_remote – Source files for setting up the Regulatory hub to use a remote server
 | • The sample code is provided just for reference. It is the responsibility of the team building the solutions to assess the sample for applicability, robustness, security, etc., as part of their development process. • PTC has not performed any scalability or performance testing on the sample code. Although the sample is using the H2 database, this is not meant as recommendation of the configuration for testing or production. |
Following is the workflow diagram showing the eMDR submission with the sample Regulatory hub.
Primary Components of the Sample Code
Following are the Windchill components:
• SRH EMDR Decision — The Windchill SRH EMDR Decision object is a sub type of the Customer Experience Regulatory Report Decision. It is used to determine whether the regulatory report is needed and to manage the business process through its life cycle. This component enables the customers to manage the Customer Experience inside the Windchill Customer Experience module.
• SRH eMDR Life Cycle Version 1 — The SRH submission Life Cycle Version 1 is used by the eMDR Reg Hub object to interact with ThingWorx, so that Windchill is kept informed of the progress made by ThingWorx. ThingWorx sets the following states to indicate the progress:
◦ In Progress – Indicates that the data is being collected or being transmitted to the agency for the regulatory submission.
◦ Closed – Indicates that an successful acknowledgment was received. The state of the regulatory decision is set to Closed.
◦ Rejected – Indicates that the an unsuccessful acknowledgment was received. As a result, the state of the regulatory decision is set to In Work. This state is transient: after the state of the regulatory decision is assigned, the state of the submission is then set to In Work.
◦ Rework – The state is set to Rework when the submission is iterated. The state of the regulatory decision is set to In Work. This state is transient: after the state of the regulatory decision is assigned, the state of the submission is then set to In Work. This state is required because in Windchill the users can create a follow-up on the actions of the submission and on the actions of the decision. With this state, both actions produce the same outcome.
• SRHReportDelegate.java — Java interface that defines the functions used by workflows and actions by the sample code.
• SRHeMDRServicesThing — Provides the services for Windchill communication and mashups to interact with the data tables containing the sample data. It is important to set the following configurations to connect to Windchill:
◦ restURL – The URL to the Windchill Rest Services, https://<server>:<port>/Windchill/servlet/odata.
◦ username – The name of user with permissions to update data and primary content and set the state on the eMDR Reg Hub type.
◦ password – The password of the above user.
SRHeMDRServicesThing gains its functionality by implementing the SRHeMDRServicesThingShape. Thus, it is possible to have a different name for this object if it implements the SRHeMDRServicesThingShape.
Following are the ThingWorx components:
• SHRRemoteHelperThing — Runs external to ThingWorx. This allows running the SRHMain.java file on the server where files are read and written to or any other convenient location. It communicates with ThingWorx using ws(s) protocol over standard HTTP(s) ports. It requires a ThingWorx server licensed and configured to support ws(s) connections. This component keeps a PDF report, sending data and acknowledgement processing JAR files outside of ThingWorx.
• SRHEMDRProcessingThing — Runs internal to ThingWorx. Requires data and acknowledgement files to be read and written into a directory accessible by ThingWorx and by the system that is communicating with the agency. JAR files are required to create PDF reports, sending data and reading acknowledgements will be added to.
• SRHeMDRAutomationUser — To run with the sample security configuration, create an application using the SRHeMDRAutomationUser. Then use that key in Windchill and SHRRemoteHelperThing. To edit data via the eMDR mashup, you must be added to the SRHeMDRUser group.