can PHINMS receiver database table have extra columns added at the end

[Christina Crawford]

We are becoming a receiver in PHINMS now as we were only a sender. 

We will be receiving HL7 2.5 1 files from other out of state PHINMS senders for PA residents. 

We were thinking of only creating 1 SQL Server receiver workerqueue database table and using 1 service/action pair.  To distinguish between states, we were going to dictate the file name to have the state in it.

We are thinking of having Rhapsody monitor this receiver database table to grab the data from it and send it on its way to our internal process.  We wanted to do it this way so to minimize the number of Rhapsody communication points needed.

I am wanting to know if extra columns can be added to the receiver database table so we can indicate that the file has been picked up and sent on its way to our internal process.

How has anyone done something like this?

Christina Crawford

[Schneider, Edward (MNIT)]

No, but I doubt that altering the columns from the specifications formally required by the PHINMS technical documents would be a good idea, in terms of PHINMS operation.

Our PHINMS receives data from multiple senders, and we process a significant amount of those through Rhapsody.  We separate some of them (typically for different disease categories or kinds of lab results) by instructing the senders to use an appropriate choice, as we direct, for the Message Recipient, while using a common service/action pair.  We minimize use of commpoints, to some degree, by accepting (for example) most Electronic Lab Reporting results through a Rhapsody common communications point (database input), doing some preliminary processing, and channeling the results through dynamic commpoints to different routings internally, based on message properties.  (Dynamic commpoints in Rhapsody don't incur the same licensing costs as the standard commpoints.  Using them may not be totally intuitive, though.)

However, if you want to go with your current idea, I'd recommend just creating a supplementary table mirroring the standard PHINMS message_inq format plus your extra columns, and doing a pass-through from the PHINMS message_inq to your message_inq_plus, where you can do whatever added operations you need to, then route from there.  (We are doing some of that, too; and when we copy a row entry from the original message_inq-type table, we update the processingstatus column for that row in the original table from 'queued' to 'processed.')

Edward A. Schneider

Information Technology Specialist/Middleware Administration | Application Data Services Unit

Minnesota IT Services | Partnering with Minnesota Department of Health
625 North Robert St.
P.O. Box 64975
St. Paul, MN 55164-0975
O: 651-201-4047
Information Technology for Minnesota Government | mn.gov/mnit

---

From: phi...@googlegroups.com <phi...@googlegroups.com> on behalf of Christina Crawford <ccrawf...@gmail.com>
Sent: Wednesday, March 14, 2018 1:13:37 PM
To: PHINMS User Community
Subject: can PHINMS receiver database table have extra columns added at the end

 

--

---
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.
For more options, visit https://groups.google.com/d/optout.

[Lowe, Phillip (DOH)]

The standard record has what you need without additions.  The FromPARTYID table tells you what you need to know.  We found this to be annoying and created an additional table called PARTYIDmap.  This table only has two tables, PARTYID and shortname. Joining the two together gives both the PARTYID OID and the shortname which is simpler and understandable.  You can also build the partyidmap table in Rhapsody to map each partyid to a state abbreviation.  We actually build our own file names for inbound PHINMS messages to include the recorded from the PHINMS workerqueue table so we can track back to the original message.  The process has been reliable so we don’t have to track back more than once in a blue moon but it is easy to do.

 

One thing to watch out for is if you get data from a new partyid and don’t have your joins right, the new data won’t be accessible.  Pulled some hair out the first time that happened then I fixed the joins J

 

Phill Lowe – 360 236-4261

 

From: phi...@googlegroups.com [mailto:phi...@googlegroups.com] On Behalf Of Christina Crawford
Sent: Wednesday, March 14, 2018 11:14 AM
To: PHINMS User Community <phi...@googlegroups.com>
Subject: can PHINMS receiver database table have extra columns added at the end

 

We are becoming a receiver in PHINMS now as we were only a sender. 

--