ProofPoint blocking Direct Individual Messages EPIC

[Peter Bachman]

Currently testing individual certificate (Full Federal Bridge compliant)with an Epic Care Everywhere year certificate. The mx record for the test domain goes through ProofPoint as opposed to regular Epic mail. ProofPoint refuses to respond for support, but Epic has white listed our domain NHDS1.com

That means ProofPoint is a black box. NHDS1.com is not black listed. Care Everywhere claims to have a full SMTP Stack out side of HISP.

They first provided a group cert with a claim that it was an individual certificate. They have so far failed to send a signed email for the test subject.

This is not going through a HISP and will not be going through a HISP.

https://open.epic.com/Clinical/EHRtoEHR

Has anyone connected successfully with Epic’s test CA
Using individual FBCA certificates for Direct not going through a HISP?

[Peter Bachman]

As an additional note Digicert has a wildcard certificate for *.epic.com which may be affecting the ability to build a valid chain that is trusted by outlook, certificate manager validated the path, as well as the PKI Interoperability test tool using the test root. However Outlook won’t send. I am wondering if Outlook is only looking at the wild card certificate and ignoring the test certificate anchor and individual address certificate. Have not been able to get any message from the test subject either.

This is for 360x.

--
You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhindirect-disc...@googlegroups.com.
To post to this group, send email to nhindirec...@googlegroups.com.
Visit this group at https://groups.google.com/group/nhindirect-discuss.
For more options, visit https://groups.google.com/d/optout.

[Vassil Peytchev]

Hi Peter,

 

There were some rules that prevented ProofPoint to properly route the Direct messages to the specific Epic test domain.

 

This has been fixed, and the messages are reaching the final destination.

 

Thanks,

 

--Vassil

 

From: nhindirec...@googlegroups.com <nhindirec...@googlegroups.com> On Behalf Of Peter Bachman
Sent: Thursday, July 5, 2018 8:39 AM
To: nhindirect-discuss <nhindirec...@googlegroups.com>
Subject: Re: ProofPoint blocking Direct Individual Messages EPIC

 

External Mail. Careful of links / attachments. Submit Helpdesk if unsure.

[Peter Bachman]

Thank you for the clarification.

I used to write Sendmail parsing rules so I am familiar with how complex and arcane that can be.

It looks like we have some basic architectural issues here. 

While S/Mime over TLS uses the Internet, different layers of the OSI stack are further integrated including my IP for country equals US in regards to HIT in regards to policy OIDS. The problem clearly is not at a technical layer, but all the layers.

For PP to step up to the plate and be useful they have to understand the risk analysis of S/Mime versus regular Internet mail for these filters.

I got a Russian based phish confirmed by Virus Total through GMail the other day, where my general domain email has had to be entirely white listed. That’s really unusual because GMail filters are really good. 

90 % of regular Internet mail is spam or phishing mail. But different rules apply to Direct as a AS 1 based standard. The fact that HISPs are vulnerable to data leakage under HIPAA and thus must be  BAA means the approach is less secure but more DLP friendly.

The amount of Spam/Phish from LOA 3 verified Direct individual certificate holders like Dr. Beller I don’t think has ever been measured. 

This is what David Kibbe means when he says that DirectTrust is equivalent to a Spam filter when blocking messages that are not in a curated trust bundle in a HISP. Or the same analogy with Aaron and Nate. While this trust bundle was proposed as part of a package with Digicert, in reality it’s a very basic approach that reinforces data silos. The state of the art is far more advanced.

Other countries without these silos have demonstrated lower healthcare costs and better outcomes since they have fluidity.

That functionality is also possible without a physical HISP per the Direct Applicability statement with higher security using the rules of the road. 

For this, data  blocking has to be made transparent per NIST Fair Information Practices which can be understood by mere mortals and not Sendmail wizards parsing a 554 response code. So this test domain is useful.

We have to always factor risks into HIPAA information flows, especially from anything related to PHI. 

A Sendmail rule set without adequate and useful support can be ok for the general Internet, (managed from the recipient side via whitelist) but to use the general reachability functionality of the IPv4/v6 address space applied to HIT, and incentivized under MU2 previously, there also needs to be effective use of the x.500 and x.509 policy OIDs so that specific information blocking rules are not misapplied. This is an identifiable risk that affects the clinical use case of Transitions of Care.

ProofPoint was a fail on my end responding to a formal support ticket. Or via RFC requirements for Internet mail relay hosts to deliver a human response to mail to postmaster@domain which was a feature of RFC 822.  The fact that the mail server responded  with 554 for your test domain was a proof that blocking was taking place by rule.  So thanks for getting them to fix that.  

They could be useful in enabling Direct Indvidual Addresss as long as they understand the risk analysis, which is blocking of Direct Messages covered under Section 4004 of the 21st Century Cures act.

This Healthcare Information Blocking law was instituted after information blocking in Direct was discovered and documented  through among several other things, a misapplication of Intellectual Property law regarding Databases and data sent to patients put some EHR customers at risk of violating contracts by using Direct to send healthcare data to patients. This was somewhat resolved, via API and now FHIR can send data directly to a Smartphone via Apple Health Kit API. All without a Portal.