We identified this issue at the connectathon, and at first thought this was a problem with the MITRE Reference Implementation. But then realized this is actually written into the spec.

Larry also mentioned that our EHR is not the first to run into this issue. He said this had happened before, and at that point, the developer who was testing had hard coded something to get around this so that we didn't realize the severity of the issue. 

The CRD Spec requires/recommends using prefetch templates that use _include to get the coverage linked to the order. 

For example, for a ServiceRequest, it says: 

_include=ServiceRequest:insurance:Coverage

At least in our EHR (and likely in most EHRs, especially as evidenced by what Larry said) the insurance information is NOT linked to the order at the point of order entry / order sign. So this _include query parameter will return nothing. 

Additionally, it is not realistic for the CRD service to proceed very far without this information. Most payers have multiple plans, and prior authorization requirements vary a lot between plans. Especially, plans offered across various lines of business etc. include a lot of differences between prior authorization requirements. And even within a same line of business, various employer groups will have differences in contract on what is covered and what requires prior authorization. 

If we take the broader scope of CRD as anything related to coverage requirements and not just prior auth, having the coverage becomes even more important.

And this will also not work very well for CMS / Medicare/Medicaid because CMS has delegated arrangements, and so this will break in delegated arrangements for CMS also.