PHINMS receiver setup

[ccrawf...@gmail.com]

Hello.  It's been quite a while since i have been in this user group.

I am wandering now different locations have installed PHINMS as a receiver.

We have 2 instances - 1 for test and 1 for production, each on a different server.

Each instance is installed with the same CDC party ID.  

Each has a different service/action pair.

Each has its own host URL.  

This is causing our sender clients to have 2 separate PHINMS instances installed for testing and production.  PHINMS software will not allow separate sender routes to be created where the receiver party ID is the same.   Some of our clients don't/can't install multiple PHINMS instances.

Any help will be greatly appreciated.

Christina Crawford

[Francis de Wet]

• Increment the test environment party ID.  If your prod party ID is <prefix>.1 make test <prefix>.2.  
• Or, pick something completely random like <myorgname>_test.  

There are ways to configure clients to have the same partyid for multiple senders, but it is not "fun".  

Take note, any change in the partyid will need sender clients to update their config.  From what I remember you cannot "make changes" to the existing one but you need to recreate it from scratch.  If you "change it" then the actual file on disk does not have the correct name which means PHINMS cannot find file when it attempts to send since it finds the file by combining the sender and recipient partyids (if sender partyid is "a", recipient partyid is "b", file is named "a.b.xml" ... or some such. If you change the recipient partyid to "c" the file in the routeconfig remains "a.b.xml" but PHINMS code looks for "a.c.xml" and cannot find it).  

The partyid does not have to be a numeric dot value.  Quest, for example, had the partyid QUEST or some such.

This is posted from memory so some of it may be a little off.  Let me know if it is helpful.  

Frans

[Lowe, Phillip (DOH)]

We set up .186.1 as prod and .186.2 as test/staging to match what CDC does when we first set up PHINMS.  We also have two servers because when using SQL server you can’t configure a working sender and a working poller on the same machine.  Our main sender/receiver does use the same party id as our main poller.  They do share the same db but I use different schemas so I know what data is coming from where.

 

I wonder if your PROD and test servers are pointed at the same database.  That would allow “fixes” to be implemented but isn’t allowed by our security folks.

 

We have a couple of cancer related senders who just use their name as their party ID.

 

Franz is right about the  receiver configuration editing.  If you didn’t enter it correctly the first time then you need to delete it.  Close the console and start over.

 

 

Phill Lowe

Data Interoperability Team / OIS / Washington State Department of Health

Philli...@doh.wa.gov  425-894-9054  www.doh.wa.gov

 

From: 'Francis de Wet' via PHINMS User Community <phi...@googlegroups.com>
Sent: Thursday, August 24, 2023 1:20 PM
To: PHINMS User Community <phi...@googlegroups.com>
Subject: Re: PHINMS receiver setup

 

External Email

--

---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/phinms/f2d57e46-292a-45a0-85b2-f999f5bfe3a5n%40googlegroups.com.

[ccrawf...@gmail.com]

Our test and production PHINMS instances are pointing the same database table name but different databases = 1 test and other is production.

Phil, having your sender/receiver using the same party ID in 1 PHINMS instance will work because you are using 2 different party IDs for each PHINMS instance.  Did you just increment the last digit yourself and then use the same CDC certificate for both PHINMS instances?  i have heard that if CDC gives out multiple party IDs they give a CDC certificate for each party ID.

If we just to uninstall our test PHINMS and reinstall with a new party ID by just incrementing the last digit from our production party ID, we would have to email all of our test PHINMS clients to create a new sender route map on their end with our new test PHINMS party ID and send us a new test CPA file for us to import.  This would most likely then allow our PHINMS clients to have 1 PHINMS instance with a test sender route and a production sender route to us as our receiver party IDs would be different for test and production, right?  What else would we have to change?  But having different party IDs now might affect on how our system will redirect the files to the right PHINMS instances.  I think our web team may have a process in place that uses the receiver party ID and host URL to know where to redirect the files.

[Lowe, Phillip (DOH)]

We use the same certificate for both PROD and QA. 

Our main machines are sender / receivers.   We also use the same cert for our secondary (polling only) machines as well.

Both prod machines use the .1 and the QA machines use .2 (party ids)

 

 

We have separate URLs between PROD and QA.  Prod is FORTRESS.WA.GOV.  QA is TEST-FORTRESS.WA.GOV.

Yes, if you change the partyid, CDC will need to send you a new CPA but that isn’t a big deal to do on either end.

 

You should talk to your IIS folks about what is happening at that level.   WA does something totally different at that level as we have a State Level Gateway that does other things as well that we can’t get around.  It does provide the URLs and there are two, one for PROD and one for QA.

 

Phill Lowe

Data Interoperability Team / OIS / Washington State Department of Health

Philli...@doh.wa.gov  425-894-9054  www.doh.wa.gov

 

From: phi...@googlegroups.com <phi...@googlegroups.com> On Behalf Of ccrawf...@gmail.com
Sent: Thursday, August 24, 2023 2:11 PM
To: PHINMS User Community <phi...@googlegroups.com>
Subject: Re: PHINMS receiver setup

 

External Email

Our test and production PHINMS instances are pointing the same database table name but different databases = 1 test and other is production.

 

Phil, having your sender/receiver using the same party ID in 1 PHINMS instance will work because you are using 2 different party IDs for each PHINMS instance.  Did you just increment the last digit yourself and then use the same CDC certificate for both PHINMS instances?  i have heard that if CDC gives out multiple party IDs they give a CDC certificate for each party ID.

 

If we just to uninstall our test PHINMS and reinstall with a new party ID by just incrementing the last digit from our production party ID, we would have to email all of our test PHINMS clients to create a new sender route map on their end with our new test PHINMS party ID and send us a new test CPA file for us to import.  This would most likely then allow our PHINMS clients to have 1 PHINMS instance with a test sender route and a production sender route to us as our receiver party IDs would be different for test and production, right?  What else would we have to change?  But having different party IDs now might affect on how our system will redirect the files to the right PHINMS instances.  I think our web team may have a process in place that uses the receiver party ID and host URL to know where to redirect the files.

On Thursday, August 24, 2023 at 4:34:47 PM UTC-4 Lowe, Phillip (DOH) wrote:

We set up .186.1 as prod and .186.2 as test/staging to match what CDC does when we first set up PHINMS.  We also have two servers because when using SQL server you can’t configure a working sender and a working poller on the same machine.  Our main sender/receiver does use the same party id as our main poller.  They do share the same db but I use different schemas so I know what data is coming from where.

 

I wonder if your PROD and test servers are pointed at the same database.  That would allow “fixes” to be implemented but isn’t allowed by our security folks.

 

We have a couple of cancer related senders who just use their name as their party ID.

 

Franz is right about the  receiver configuration editing.  If you didn’t enter it correctly the first time then you need to delete it.  Close the console and start over.

 

 

Phill Lowe

Data Interoperability Team / OIS / Washington State Department of Health

Philli...@doh.wa.gov  425-894-9054  www.doh.wa.gov

To view this discussion on the web visit https://groups.google.com/d/msgid/phinms/39880786-4c64-4679-bc3c-dc89420a1a7fn%40googlegroups.com.

[ccrawf...@gmail.com]

Hello.  Our web team person called Phintech.  They suggested uninstalling our test PHINMS and reinstalling with a new party ID.  They suggested getting a new party ID from them.

Attached is a picture of some of our current clients.  It might be hard to just increase the last number.  What do you suggest using to increase our last digit?

Our CDC party ID is;         2.16.840.1.114222.4.3.2.2.3.657.1

We have some some clients that have CDC party IDs that are very close to ours:       2.16.840.1.114222.4.3.2.2.3.657.22

                                                                                                                                                     2.16.840.1.114222.4.3.2.2.3.657.10

If we just increase the last digit, we might actually use a real CDC party ID. So i don't think we can just increase our last digit to someting like .2 or .3.  

What would anyone suggest to use for our last digit so we don't have to get a second CDC party ID for our test PHINMS?  This would also be another CDC certificate we would have to renew every year and have to maintain different certificates for each environment.  Too much work.

Thanks,

Christina

[Lowe, Phillip (DOH)]

Understanding OIDs 101:

 

The CDC has assigned an OID to you under their OID space.  That is 2.16.840.1.114222.4.3.2.2.3.657  

These numbers have specific meanings that can be looked up:  2  second try at doing this correctly, 16 based on nationality, 840 United States of America, 1 Federal, 114222 CDC, 4.3.2.2.3 – within CDC eventually pointing at PHINMS systems, 657 your state.

 

Anything below this number is your responsibility to manage.  You have shared with CDC that the .1 is your PROD destination.  You have probably shared this with other facilities as well.  Any other number below your assigned OID is your’s to assign as you see fit and won’t (unless there is something wrong going on) interfere with anyone else. .2 is often assigned as the Staging or QA destination.

 

WA DOH has a number of partners who only report to WA DOH.  We have assigned them numbers starting above 100 in our OID as there is no need for them to register with the CDC.  We have a document that has recorded all of the OIDs that we have assigned, both those within the PHINMS space and those based on other OIDs assigned to WA. (we have an OID assigned by HL7 too)  In some messaging (PHLIP messages to CDC), we have an OID that identifies each software system that DOH uses so if there is a question, we can tell where the data came from.

To view this discussion on the web visit https://groups.google.com/d/msgid/phinms/c0b6f7a7-8d36-413a-b67f-c2f6c520ce72n%40googlegroups.com.

[Lowe, Phillip (DOH)]

WA has 4 PHINMS servers.  A pair for QA and a pair for PROD.   Both PROD have a partyid of ..186.1,  Both QA have a partyid of ..186.2.  The primary servers are in the DMZ and do inbound and outbound.  The secondary servers are in the inside network and just do polling.  We use MS SQL server, and this prevents a sender from also polling.  CDC says this works with Oracle, but we don’t have Oracle to test with.  Our partners can send to both servers from one instance.  We have routed information from one server to the other in the past. Internally we have a bridge between PROD and QA so we can forward data from partners who can’t send PROD data from their QA PHINMS but who are still in onboarding.

 

From: phi...@googlegroups.com <phi...@googlegroups.com> On Behalf Of ccrawf...@gmail.com
Sent: Thursday, August 24, 2023 1:04 PM
To: PHINMS User Community <phi...@googlegroups.com>
Subject: PHINMS receiver setup

 

External Email

Hello.  It's been quite a while since i have been in this user group.

--

---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/phinms/7e3edbf6-2f70-472d-ae5b-915920f30cabn%40googlegroups.com.