PHINMS Quick Tips

Public Health Information Network Messaging System (PHINMS) Quick Steps provide an easy reference for frequently-requested information on PHINMS. The Quick Steps refer to Release 3.2. Suggestions for additional Quick Steps can be sent to the PHINMS Web Site point-of-contact available via the Support link.

PHINMS Software Request

Contact PHINTech@cdc.gov to request a copy of PHINMS 3.2 application installation packages.

1. PHINMS System Requirements

PHINMS 3.2 has been tested on the following operating systems:

  • Windows Server 2016
  • Windows 10

Note: PHINMS 3.2 should work with other versions of Windows as long as it’s 64-bit system.

The system requirements for using PHINMS are as follows:

  1. 6GB hard disk space.
  2. 4GB memory.
  3. TLS 1.2.
  4. local administrator privileges.

 Top of Page

2. PHINMS Software Request

Contact PHINTech@cdc.gov.
 Top of Page

3. PHINMS New Installs

The Installation Wizard guides the user through the base installation of the PHINMS Sender and/or Receiver. It is the responsibility of the administrator to configure routes and database connections after completing the installation. The following major components are installed with the wizard:

  1. Tomcat 9 server.
  2. PHINMS 3.2 Receiver and Sender applications.
  3. PHINMS 3.2 default configuration files and directory structure.
  4. Shortcut to PHINMS 3.2 console on user specific desktop.
  5. Default database:
    • HSQLDB 1.8.0.4 engine.

When “Install as service” is selected on Windows platform, Tomcat 9.0.43 will be installed in the Windows services panel with the display name of “PHINMS Tomcat Instance” and HSQLDB with “PHINMS Database Engine Service”.

 Top of Page

4. Compatible Products

PHINMS 3.2 has been tested on the following operating systems and databases:

  1. Operating systems:
    • o Windows Server 2016.
    • o Windows 10.
  2. Certified Default Database:
    • o HSQL DB 1.8.0.4 – used for testing purposes
  • Production Qualified Databases:
    • o Microsoft SQL Server 2016.
    • o Oracle (Not tested)
    • o MySQL (Not tested)

PHINMS has been tested on certain JDBC drivers to connect to the supported databases and found no issues based on the tests performed. It is however the responsibility of the PHINMS customer to decide which JDBC driver to use.

 Top of Page

5. Obtain a CDC Party ID

Regardless of the PHINMS version installed, a CDC PartyID is required. A PartyID is required for each instance of PHINMS or each installation of PHINMS. A PartyID uniquely identifies a PHINMS installation, also known as an instance or node, in the Public Health Information Network (PHIN). The PHINMS installation transmits the PartyID along with every message which notifies the recipient of the origin of the message. A PartyID will resemble “2.16.840.1.114222.4.3.2.2.2.1.2”.

Send a completed PHINMS Software Request for each PHINMS installation to obtain a PartyID from the PHIN Help Desk PHINTech@cdc.gov. Save the PartyID until the initiation of the PHINMS installation. The PartyID will be permanently stored once entered into the PHINMS Installation wizard.

 Top of Page

6. Obtain a User ID and Password

Once Step 2 is complete, the PHIN Help Desk will need to be contacted to obtain the User ID, password, and the FTP site used to download the PHINMS software.

 Top of Page

 

7. Install PHINMS Software

The installation steps are located in the PHINMS Implementation Guides. Refer to one of the following release specific guides:

 Top of Page

 

8. Obtain a Digital Certificate

A Digital Certificate issued by Verisign through the CDC’s Secure Data Network is required when sending messages to the CDC. A CDC’s Digital Certificate will only be provided to partners sending data to the CDC. When a messaging partner sends data to organizations other than the CDC, a Digital Certificate will need to be acquired from a third-party vendor.

 Top of Page

9. PHINMS Configuration

The PHINMS Implementation Guides provides basic configuration instructions to successfully use PHINMS.

 Top of Page

10. Restart vs. Refresh PHINMS

When PHINMS configuration files have been changed or a new component has been added, the PHINMS Tomcat service will need to be restarted for the changes to take effect. This can be done in Services located in the Administrative Tools folder. When adding data to the database, using the refresh button on the console will suffice.

 Top of Page

11. PHINMS Installation Verification Test

PHINMS has two components, the Sender and the Receiver. Sending a Ping message from the Sender to the Receiver ensures both the PHINMS Sender and Receiver components are working properly. Complete the installation test by referring to one of the following release specific guides:

 Top of Page

12. CDC Connectivity Test

The CDC Connectivity Test is used to verify messages can be sent directly to the CDC or to use the CDC as an intermediary server (Route-not-Read). This test ensures the PHINMS Sender is able to send an outbound Ping message to a PHINMS Receiver hosted at the CDC and the CDC’s Receiver successfully receives the message. Complete the CDC Connectivity test by referring to one of the following release specific guides:

 Top of Page

13. Create Route Map

A Route Map is used to send messages to specific recipients. The Route Map stores the recipient’s attributes, such as the URL, transport protocol, and authentication type. Create a Route Map by referring to one of the following release specific guides:

 Top of Page

 

14. Transport Queue Configuration

The Sender uses a Transport Queue (TransportQ) is a relational database table interfacing between the application creating the message and PHINMS which stores the meta-base information and data to be sent. The Sender polls the TransportQ for messages. PHINMS is packaged with a database; however, a different database can be configured for the TransportQ. Use the applicable Implementation Guide pertaining to the version which documents the steps to configure a TransportQ. The Implementation Guide is located on the Installation tab.

 Top of Page

 

15. Worker Queue Configuration

The Receiver uses a Worker Queue (WorkerQ) to store incoming messages in a database table. The WorkerQ is configured from the Receiver configuration screens located in the console. The 3.2 release comes bundled with HSQL but can be configured using other databases. Use the applicable Implementation Guide pertaining to the version which documents the steps to configure a WorkerQ. The Implementation Guides are located on the Installation tab.

See Page 42

 Top of Page

 

16. Service Map for the Worker Queue Configuration

Each message has an envelope with addressing information tags referred to as a Service and Action pair. They are character strings logically mapped to a Worker Queue (asynchronous messaging). The service and action pair determines the location of the delivery. The Service Map and the Worker Queue are configured on the Receiver. Refer to Step 14. The Service Map also includes the type of Message Handler which is Servlet, Worker Queue, and Error Queue.

 Top of Page

 

17. Digital Certificate Configuration

Instructions are in the PHINMS 3.2 Implementation Guide pdf icon[4 MB, 58 Pages, 508] for importing and exporting the Digital Certificate.

See Page 34

 Top of Page

 

18. PHINMS Upgrade

Instructions are located in the PHINMS 3.2 Implementation Guide pdf icon[4 MB, 58 Pages, 508] for upgrading PHINMS using the correlating version.

See Page 22

 Top of Page

Page last reviewed: April 1, 2021