PHINMS and DIRECT interoperability

[Eduardo "Eddie" Gonzalez Loumiet]

Are any folks out there interested on this topic? We (Florida & Uber
Operations) are working on this project. Stay tuned.

[Y. Emily Cheng]

SC is interested. Look forward to learning more.

On Sep 13, 3:07 pm, "Eduardo \"Eddie\" Gonzalez Loumiet"

[Badgett, Allen A.]

Oklahoma would be interested although I think "Direct" is a figment of someone's imagination.

Allen
405 271 9444 x46184

[Lowe, Phillip (DOH)]

Washington State is just watching. We don't have any partners who have
shown an interest in using DIRECT.

We were supposed to be connecting to a state-wide hub as a more
efficient method of electronic exchange but that is now on hold as the
powers that be have decided to do a major business case analysis.

At the level of reality, it is hard to interest any of our partners to
do anything other than sFTP unless they are talking to multiple states
and using PHINMS.

Phill Lowe (360) 236-4261 Philli...@DOH.WA.GOV
Epidemiology Data Systems Manager, EHSPHL Informatics
"The Department of Health Works to Protect and Improve the Health of
People in Washington State"

[tom]

There is noise enough about DIRECT here in Wisconsin for me to look
into this. I have skimmed a bit and am curious as to whether you
invision a DIRECT hub, client, or both for integration with PHINMS.
There are certainly several DIRECT open source implementations already
out there that would be useful for a quick and dirty implementation.

But, I have to agree with Phil as to a reality check. My own
experience would suggest that clients would be more interested in say
an MLLP-PHINMS bridge, since many of the commercial HL7 interfaces now
require and/or support this for data transfer. This is actually high
on my list of updates to my own PHINEAS project (small footprint light
weight PHINMS work-alike - see https://mywebspace.wisc.edu/tdunnick/web/phineas.html).

Tom

On Sep 13, 3:33 pm, "Lowe, Phillip (DOH)" <Phillip.L...@DOH.WA.GOV>
wrote:

> Washington State is just watching.  We don't have any partners who have
> shown an interest in using DIRECT.  
>
> We were supposed to be connecting to a state-wide hub as a more
> efficient method of electronic exchange but that is now on hold as the
> powers that be have decided to do a major business case analysis.  
>
> At the level of reality, it is hard to interest any of our partners to
> do anything other than sFTP unless they are talking to multiple states
> and using PHINMS.
>

> Phill Lowe (360) 236-4261 Phillip.L...@DOH.WA.GOV

[Frans de Wet]

Tom,

We have used Mirth as an MLLP-PHINMS bridge with great success (especially since it also gives you some other interface capabilities) with a fairly straight forward install and configuration.  

We developed Mirth connectors for sending messages to PHINMS and receiving messages from PHINMS.  These connectors, or at least the use of them in new versions of Mirth, have been in a bit of sleep state for a few months since Mirth 2.0 came out since they left out the capability to support external connectors at that time.  It will be back in play in version 2.2.2.  

We envision and have built Direct instances that handle all Direct communication: both receiving Direct messages from other Direct senders and transmitting Direct messages to other Direct instances.  At this time it is the Java Reference Implementation with some configuration changes.

In the middle we have an interoperability layer that manages the routing of Direct addresses (above-mentioned Direct instance(s) handle this) to PHINMS recipients/arguments/etc and the reverse.  

This is very similar to our approach for routing MLLP data with Mirth to and from PHINMS.  Only the metadata differs.

Did I answer all your questions?  

Thanks,

Frans de Wet

Managing Member

Uber Operations LLC
(850) 583-0041

[tom]

Frans,

Thanks for the information. Here at the Wisconsin Heath Laboratory we
currently use Mirth to bridge MLLP to PHINMS as well. And the Java
Reference edition of DIRECT would also be my starting spot for a
PHINMS interface, so it's good to know we are on similar paths.

I'm still struggling to figure out exactly why our clients would be
more interested in setting up DIRECT rather than PHINMS though, other
that the "it's newer so it must be better" mind set. My experience
has been that the simpler and easier it is to set up transport, the
better the "buy in" from participating clients (labs, hospitals,
etc). But I admit to not looking at any DIRECT client software as
yet, so I don't really know what that set up investment would be,
particularly for automated operation. It does look like it suffers
from the same certificate distribution and control issues that PHINMS
has.

As for the MLLP-PHINMS bridge, the Mirth/PHINMS solutions needs
either a big server for both, or two smaller servers. PHINMS requires
500MB disk and 1GB memory and both require configuration. I know
hardware is cheap, but there is the support as well (OS patches,
etc).

My PHINEAS work alike currently uses about 2MB disk and 4MB memory. I
wouldn't expect that to grow by more than 50% after adding MLLP
support (probably less). That small enough to drop any old place.
And the intent is for receivers to be able to deliver pre-configured
versions to clients (click and run). But it's a work in progress and
I'll probably add chunking and digital signitures before moving on to
MLLP.


Tom

On Oct 11, 1:05 am, Frans de Wet <fran...@gmail.com> wrote:
> Tom,
>
> We have used Mirth as an MLLP-PHINMS bridge with great success (especially
> since it also gives you some other interface capabilities) with a fairly
> straight forward install and configuration.
>
> We developed Mirth connectors for sending messages to PHINMS and receiving
> messages from PHINMS.  These connectors, or at least the use of them in new
> versions of Mirth, have been in a bit of sleep state for a few months since
> Mirth 2.0 came out since they left out the capability to support external
> connectors at that time.  It will be back in play in version 2.2.2.
>
> We envision and have built Direct instances that handle all Direct
> communication: both receiving Direct messages from other Direct senders and
> transmitting Direct messages to other Direct instances.  At this time it is
> the Java Reference Implementation with some configuration changes.
>
> In the middle we have an interoperability layer that manages the routing of
> Direct addresses (above-mentioned Direct instance(s) handle this) to PHINMS
> recipients/arguments/etc and the reverse.
>
> This is very similar to our approach for routing MLLP data with Mirth to and
> from PHINMS.  Only the metadata differs.
>
> Did I answer all your questions?

> *
> *
> Thanks,
> *Frans de Wet*
> Managing Member
> *Uber Operations LLC
> *(850) 583-0041
>

[Frans de Wet]

Is PHINEAS cross platform capable.  I have not looked at your link you made available somewhere else on here ... 

Thanks,

Frans de Wet
Integration Engineer
(850) 583-0041

[tom]

Frans,

PHINEAS is currently MS only, but I've tried to isolate the usual
platform dependent stuff (network, threading, etc) anticipating that
at some point someone might want a *NIX/posix version, or whatever.
It's not that I'm a MS fan, just that most targets (especially for a
small footprint project) would probably be MS.

The main link again for anyone who might be interested is
https://mywebspace.wisc.edu/tdunnick/web/phineas.html. It has the
project abstract and links to GITHUB source, the 2011 CDC presentation
slides, and source/binary zips. The current version is about a month
old (I was in Europe all of September), but I should be getting some
updates posted in the next week or so.

Tom

On Oct 11, 1:40 pm, Frans de Wet <fran...@gmail.com> wrote:
> Is PHINEAS cross platform capable.  I have not looked at your link you made
> available somewhere else on here ...

> *
> *
> Thanks,
> *Frans de Wet*

> Integration Engineer
> (850) 583-0041
>

[Badgett, Allen A.]

I have been working with a provider for several months trying to connect
to PHINMS using BizTalk. We have worked through most of the problems
except for encryption/decryption.

We have exchanged certificates and CPA files and configured all the
necessary routes and the message is encrypted and transmitted to our
receiver PHINMS. The problem remains with decryption on our end. The
message is not decrypted and we get an error message like:

Encryption key
(DN=E=all...@health.ok.gov, CN=Allen Badgett, T=Computers/Database
Management, OU=EmployeeID - 163782, OU="www.verisign.com/repository/CPS
Incorp. by Ref.,LIAB.LTD(c)99", OU=IRMO G2, O=Centers for Disease
Control and Prevention, L=Oklahoma City, S=Oklahoma, C=US) and

decryption key
(DN=EMAILADDRESS=all...@health.ok.gov, CN=Allen Badgett,
T=Computers/Database Management, OU=EmployeeID - 163782,
OU="www.verisign.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)99",
OU=IRMO G2, O=Centers for Disease Control and Prevention, L=Oklahoma
City, ST=Oklahoma, C=US)

You can see that the decryption key is slightly different. Does anyone
have some experience that can help us?

Allen
Office 405 271 9444 x46184
Cell 405 623 6905

[tom]

Allen,

Been there and done that. You are REALLY close.

PHINMS is very picky about the format of the DN in the payload
envelope. Unfortuantely, the "email" part of the DN is more or less
an extension of x509 and as a result the tag/id is somewhat
implementation dependent (e.g. it's probably a Java API issue for
PHINMS). If you "fix" the email tag in the DN, life will be good.

With my PHINEAS project I found OpenSSL generated certificates tagged
email addresses as "emailAddress", and I ended up taking the
(perfectely good) DN generated by OpenSSL and folding the tags to
uppercase before placing them in the payload envelope. After that
everything worked.

Tom

On Oct 31, 10:14 am, "Badgett, Allen A." <All...@health.ok.gov> wrote:
> I have been working with a provider for several months trying to connect
> to PHINMS using BizTalk. We have worked through most of the problems
> except for encryption/decryption.
>
> We have exchanged certificates and CPA files and configured all the
> necessary routes and the message is encrypted and transmitted to our
> receiver PHINMS. The problem remains with decryption on our end. The
> message is not decrypted and we get an error message like:
>
> Encryption key
> (DN=E=all...@health.ok.gov, CN=Allen Badgett, T=Computers/Database
> Management, OU=EmployeeID - 163782, OU="www.verisign.com/repository/CPS
> Incorp. by Ref.,LIAB.LTD(c)99", OU=IRMO G2, O=Centers for Disease
> Control and Prevention, L=Oklahoma City, S=Oklahoma, C=US) and
>
> decryption key
> (DN=EMAILADDRESS=all...@health.ok.gov, CN=Allen Badgett,
> T=Computers/Database Management, OU=EmployeeID - 163782,

> OU="www.verisign.com/repository/CPSIncorp. by Ref.,LIAB.LTD(c)99",

[Badgett, Allen A.]

Tom,
We have been trying to "Fix" the email tag but so far without success. Do you have an example of what you did that we can look at?

Allen
Office 405 271 9444 x46184
Cell 405 623 6905

-----Original Message-----
From: phi...@googlegroups.com [mailto:phi...@googlegroups.com] On Behalf Of tom
Sent: Tuesday, November 01, 2011 7:49 AM
To: PHINMS User Community

[tom]

Sure Allen!

The code snippet from PHINEAS crypt.c is below. I'm not sure how
much that will help. The simple explanation is "make it look like the
PHINMS DN". From what you posted, you need to replace the 'E' email
tag with 'EMAILADDRESS'. I haven't looked at the Biz-Talk API so I
don't know exactly how you would code this. In PHINEAS I am building
the envelopes from templates, and then filling them in and/or
modifying them with an XML API so I can pretty much do anything I want
with them. Biz-Talk might not give you that much control.

Anyway, here's the C function that builds a PHINMS compatible
certificate DN using the OpenSSL library API. I just stuff the result
into the payload envelope...

Tom

/*
* Get a distinguished name from an X509 subject.
*
* We could do this explicitly...
* char *sn_list[] =
* {
* SN_commonName,
* SN_countryName,
* SN_localityName,
* SN_stateOrProvinceName,
* SN_organizationName,
* SN_organizationalUnitName,
* SN_pkcs9_emailAddress
* };
* X509_NAME_get_text_by_NID(X509_NAME *name, int nid, char *buf,int
len);
*
* Instead we'll just reverse the oneline, changing the slashes to
commas.
* PHINMS (Java?) also folds everything to uppercase on the left side
* of the '=', in particular the emailAddress.
*/
char *crypt_X509_dn (X509 *cert, char *dn, int len)
{
int i;
char buf[1024], *list[8], *ch, *p;
X509_NAME *subject;

if ((subject = X509_get_subject_name(cert)) == NULL)
error ("Can't get subject\n");
/* get the DN from the subject */
X509_NAME_oneline (subject, buf, len);
i = 0;
for (ch = buf; ch != NULL; ch = strchr (ch, '/'))
{
*ch++ = 0;
for (p = ch; *p && (*p != '='); p++)
*p = toupper (*p);
list[i++] = ch;
}
strcpy (ch = dn, list[--i]);
while (i--)
{
ch += strlen (ch);
if ((ch - dn + strlen (list[i]) + 2) >= len)
break;
strcpy (ch, ", ");
strcpy (ch + 2, list[i]);
}
return (dn);

[Badgett, Allen A.]

Thanks Tom. I'm going to look at this.

Could you join us on a conference call on this problem. It would be some CDC people, probably Tavan and some people from Allscripts an HIE. They are try to connect to PHINMS.

Not sure when the call will be but probably sometime today.

[Badgett, Allen A.]

This is to continue the thread we have been discussing about biztalk to PHINMS 2.8.01 sp1.

I think we have gotten by the name problem but we get a new error. Anyone have an idea?

<KeyName>EMAILADDRESS=kranth...@allscripts.com, CN=Kranthi Kumar, T=Computers/Database Management, OU=EmployeeID - 151270, OU="www.verisign.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)99", OU=IRMO G2, O=Centers for Disease Control and Prevention, L=Raleigh, ST=North Carolina, C=US</KeyName>

Note: Looking for an explanation of the highlighted error. Thank you all!

Reginald B

*******************REQUEST INFO START****************
Conversation ID: 54dc930a-8203-4bba-b9ca-9b4932c7bc76; Message Id:9171c6d4-593b-4462...@PHINMS-1.com
CPA:uriyoursandmycpa; From: phinms.allscripts.com; To: receiver
Service: test; Action: send
*******************REQUEST INFO END *****************
|
http-5088-2|11/02|12:43:30|Warning: EbXMLInfo:signingCertRef unspecified|
http-5088-2|11/02|12:43:30|Service:test, Action: send found|
http-5088-2|11/02|12:43:30|Service=test, Action=send found in servicemap|
http-5088-2|11/02|12:43:31|Error decrypting - Key not specified or obtained|
http-5088-2|11/02|12:43:31|Service type is worker queue|
http-5088-2|11/02|12:43:31|handling worker queue, lfn=null|
http-5088-2|11/02|12:43:31|pushing to queue ReceiverSQLMap|
http-5088-2|11/02|12:43:31|pushing to Queue: ReceiverSQLMap|
http-5088-2|11/02|12:43:31|getting database id for queue=ReceiverSQLMap|
http-5088-2|11/02|12:43:31|in getDatabaseId, nodename=workerQueue|
http-5088-2|11/02|12:43:31|getConnection, dbid=ReceiverSQL181|
http-5088-2|11/02|12:43:31|getConnection, got connection|
http-5088-2|11/02|12:43:31|pushToQueue, got connection to queue|
http-5088-2|11/02|12:43:31|got connection|
http-5088-2|11/02|12:43:31|got tablename=workerqueue|
http-5088-2|11/02|12:43:31|getting database id for queue=ReceiverSQLMap|
http-5088-2|11/02|12:43:31|in getDatabaseId, nodename=workerQueue|
http-5088-2|11/02|12:43:31|dbtype=sqlserver, tablename=workerqueue|
http-5088-2|11/02|12:43:31|doing sql server insert into: workerqueue|
http-5088-2|11/02|12:43:31|Warning: Record:messageId unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:arguments unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:messageRecipient unspecified|
http-5088-2|11/02|12:43:31|Inserting record with processing status=queued|
http-5088-2|11/02|12:43:31|Warning: Record:applicationStatus unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:processId unspecified|
http-5088-2|11/02|12:43:31|Inserting into table: workerqueue|
http-5088-2|11/02|12:43:31|Insert error|
http-5088-2|11/02|12:43:31||
http-5088-2|11/02|12:43:31|getting database id for queue=ReceiverSQLMap|
http-5088-2|11/02|12:43:31|in getDatabaseId, nodename=workerQueue|
http-5088-2|11/02|12:43:31|Error inserting to worker queue|
http-5088-2|11/02|12:43:31||
http-5088-2|11/02|12:43:31|Re-establishing connection|
http-5088-2|11/02|12:43:31|getting database id for queue=ReceiverSQLMap|
http-5088-2|11/02|12:43:31|in getDatabaseId, nodename=workerQueue|
http-5088-2|11/02|12:43:31|doing sql server insert into: workerqueue|
http-5088-2|11/02|12:43:31|Warning: Record:messageId unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:arguments unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:messageRecipient unspecified|
http-5088-2|11/02|12:43:31|Inserting record with processing status=queued|
http-5088-2|11/02|12:43:31|Warning: Record:applicationStatus unspecified|
http-5088-2|11/02|12:43:31|Warning: Record:processId unspecified|
http-5088-2|11/02|12:43:31|Inserting into table: workerqueue|
http-5088-2|11/02|12:43:31|SQL Server insert successful, table=workerqueue|
http-5088-2|11/02|12:43:31|getting database id for queue=ReceiverSQLMap|
http-5088-2|11/02|12:43:31|in getDatabaseId, nodename=workerQueue|
http-5088-2|11/02|12:43:31|ReceiveFileServlet: processMessage done|
http-5088-2|11/02|12:43:31|Composing message without SyncReply|
http-5088-2|11/02|12:43:31|Transport Success.|
http-5088-2|11/02|12:43:31|No SyncReply requested. Hence, not sending back a response|

[tom]

Allen,

Re: the conference call... I could possible get in on one. My
schedule is a bit chaotic. The main issue here is that since this is
a moderated group, posts don't show up immediately, plus I don't keep
my email client running continuously. When writing code I tend to
reduce distractions (:-). Anyway, provide a day or two lead time,
email me directly and we can most likely coordinate a call.

Re: the new issue below... Unfortunately the "highlight"... didn't (at
least in my client). I'm guessing you were asking about...

> http-5088-2|11/02|12:43:31|Error decrypting - Key not specified or obtained|

Without looking through the PHINMS source (which I don't have), that's
a bit too cryptic to nail down. However here is what I would suspect
as possibilities...

1. The receiver must be finding a certificate since it now matches up
the DN and that issue went away. Perhaps that certificate (needed for
decryption) only has the public key. Are you sure the receiver has
the private key?

2. Certificate encryption schemes are typically two level. The
payload is encrypted using a one time symmetric key which provides
fast and secure encryption. This key is then encrypted by the slower
less efficient asymmetric public key found in the certificate itself.
The payload envelope should have an entry for the (RSA) encrypted
symmetric key. Perhaps this is not getting filled in by your Biz-Talk
interface. Check the <CipherValue> tag within the <KeyInfo> part of
the envelope. Note this is distinct from the <CipherVaule> tag that
is contained in the following <CipherData> part of the envelope.
There should be two... one for the key and one for the data. The
<KeyInfo> part of the envelope should look something like...

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/
xmlenc#rsa-1_5"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>EMAILADDRESS=tdun...@wisc.edu, OU=Phineas Project,
ST=Wisconsin, L=Madison, C=US, O=Phineas Health, CN=Phineas
Application</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>11njHvLPhmqZF3ccwaqum6HLHmmkOelU9kuomJIxedBog20i49nXr9yts
+Supd0gED26QE0Phy9L8n3FIDFWbl9u33NoQs6uhdZQ8GZFt11HNHs
ZgpgLq6nyjUkF2mhCcFcYwIX4eRLQyZ/gKcdavMARlThD5jmlsS6njADD0/
ll1fu51pPunfmwY+U12Swpsqj3SJL8d/mQiI+eFqa2C/
3g11tBhFzCwdbLKcljvZaHdpg4cAg
mZN9upOasd+u4XJMfdZcqkLRL9jwtYcdtN9Bi8jfczstogCbxPFMoW9O
+LTaR92JUZtES7CPUaYV1ygYlmj9zFtIEmyRVPrsmOg==</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>

Tom

On Nov 2, 11:09 am, "Badgett, Allen A." <All...@health.ok.gov> wrote:
> This is to continue the thread we have been discussing about biztalk to PHINMS 2.8.01 sp1.
>
> I think we have gotten by the name problem but we get a new error. Anyone have an idea?
>

> <KeyName>EMAILADDRESS=kranthi.ku...@allscripts.com, CN=Kranthi Kumar, T=Computers/Database Management, OU=EmployeeID - 151270, OU="www.verisign.com/repository/CPSIncorp. by Ref.,LIAB.LTD(c)99", OU=IRMO G2, O=Centers for Disease Control and Prevention, L=Raleigh, ST=North Carolina, C=US</KeyName>

>
> Note: Looking for an explanation of the highlighted error. Thank you all!
>
> Reginald B
>
> *******************REQUEST INFO START****************

> Conversation ID: 54dc930a-8203-4bba-b9ca-9b4932c7bc76; Message Id:9171c6d4-593b-4462-94d0-1e9aa7d96...@PHINMS-1.com

[Mayo, Travis (CDC/OSELS/PHITPO) (CTR)]

I have granted you both permissions to post without being moderated. This thread is very beneficial to the entire PHINMS development community.

[Mark Doerr]

This is a most interesting thread. Tom, I think I know you from my days at the PHIN group at the UW-DoIT where I helped set up ELR messaging  using PHIN-MS. Could you contact me?