S&I Framework Face to Face, esMD and Trust relationships

I spent a good part of today learning more about the Electronic Submission of Medical Documents S&I Framework project, and a bit of time with the Query Health Clinical workgroup working on user stories.  I skipped one meeting I should have attended to address CDA Consolidation Ballot reconciliation, even though I thought there were better uses of my time (Face to Face meeting time is so valuable;  I could have saved the T-con time for other stuff, mostly spending time with people I don't otherwise see).

A couple of observations:  I cannot be in five places at once, nor can many of my colleagues who are trying to pay attention to these efforts.  It takes a big investment to send one person to these meetings, especially in DC where hotels are so over-priced.  I'd love to see them divide the meeting up into three tracks:  Clinical, Technical, and Business oriented.  That way, if you want to stay in on a single track, you can, but, you can also scheduled the different initiatives for different time slots so you can follow a single initiative through its various tracks.  Right now, if you are in the Query Health Clinical Workgroup, but also want to learn about something else (e.g., esMD), you have to make choices about where to spend your time, and you can miss important discussions (like I did on XDR and X12 277/275).  And, if you happen to have a lot of clinical (or business or technical) expertise, you can share it more readily across projects, and cross fertilize.  It would also do a bit to form some cohesion across S&I projects.  I count ten different workgroups that are presently active in S&I:  3 in Query Health, esMD, TOC, CDA Documentation, CDA Consolidation, Provider Directory, LRI, and Data Segmentation.  That's quite a bit to follow for even two people.

In the afternoon esMD meeting session that I attended, I think one of the most wonderful ideas was floated and agreed upon by the group.  They decided that they needed to attack three work items, and had people sign up for each one.  The groups are to decide upon the scope of the work they need to do, and then, after having made that assessment, determine WHERE they need to spend their time.  So, if for example, the Clinical Content workgroup in esMD discovers that the scope of their efforts includes clinical content in CDA documents for attachments, and they discover that HL7 is already working on this using the CDA Consolidation guide, that group can figure out how to engage with HL7.  BTW:  Of the people that signed up, at least half are already in the HL7 Attachments workgroup, including two of the co-chairs.  And if the Provider Profile Authentication workgroup decides that their scope overlaps greatly with the provider directory workgroup, they can add to that effort.  It was great, by the way, to see how deeply CMS is involved in this project and that they've brought it to the S&I Framework.  Meaningful Use, is after all, a CMS regulation, so it's good to see them engaged.

One of the biggest challenges that the esMD project is going to have is around FISMA and establishing trust between the different organizations.  There will be providers, "Health Information Handlers" or HIH's, which you know as RHIOs, HIEs, and claims clearing houses.  For some reason we needed yet another acronym to add to the soup we've all be eating.  The HIH will help the provider organizations send the attachments back to the MACs, RACs, CERTs, and PERMs.  More acronyms, here's a brief primer:

MAC = Medicare Administration Contractor:  A Medicare claims payer.
RAC = Recovery Administration Contractor:  A Claims Auditor.
CERT = Comprehensive Error Rate Testing: Another kind of claims auditor that estimates overpayments from Medicare.
PERM =  Program Error Rate Measurement: Another kind of claims auditor that estimates overpayments from Medicaid.

So, the MAC, RAC, CERT or PERM decides that a claim needs looking into.  It writes down (on paper) the claim information, and sends it to the provider, asking for backup information (medical records) that can be used to audit the claim.  The provider then creates a pile of paper records that they want the requester to look at for the audit and mails it back.  The auditing organization then turns all of that into digital paper which it pushes through a review process.  The first phase of esMD made it possible for an HIH to return the information back on behalf of a provider to the auditing organization in an X12 attachments transaction, but left in the paper process to request the information. The reason for doing this is because of FISMA.  If a Federal Information Processing system has to send PHI to a provider directly (rather than receiving it), CMS has to jump through some unspecified hoops to make the relevant authorities happy.

In phase 2, they want to make the request electronically, so here is where FISMA comes back in.  So, in order to ensure that providers are requesting services from an HIH, they are considering using digital signatures, which would have a big impact, especially on smaller providers.  If you tell them to get a certificate, you run into the danger of them coming back with an SSL server certificate, which is the wrong kind of thing.  So, they assume the HIH will help them with that process.  But wait?  Why does a provider need a digital certificate?  So they can sign a transaction that tells the auditor that the provider authorized it?  Is that really a good reason to force all providers to get digital certificates?

To complicate things further, the information being sent back are clinical documents, and CMS wants these auditing arms to ensure that the documents have the signature of the authorizing provider.  Oh, great!  We can use the same digital signature certificate to digitally sign the documents!  WAIT A MINUTE.  No, really you cannot.  First of all, the content that was signed by the provider is "electronically signed" in the providers system.  The EHR systems don't capture a digital signature of the database changes made during an EHR session covering a patient visit, and those systems aren't sending that data anyway, they are sending a clinical document, which could be a transformation of the content in the database, which wouldn't be created unless it was needed.  So, now the EHR system has to then sign on behalf of the authorizing provider when the document is created, but we don't want the system to just be able to sign on behalf of a provider without that provider's explicit authorization (as that defeats the purpose of the certificate to begin with).  So, that idea gets shot down.

What is in the providers system is what is called an Electronic Signature.  Now, FDA has a lot of experience with electronic signatures, because they are used by systems that Medical Device manufacturers and the FDA use to verify design controls of medical devices.  The regs for that are fairly straightforward, but as John Moehrke pointed out to me, those systems are used not just by the manufacturer, but also by FDA during audits, and "electronic signatures" aren't transferable outside the system that uses them.  And there are standards that describe all the details about how to deal with this too:  ASTM E1762-95(2009) Standard Guide for Electronic Authentication of Health Care Information.  This guide discusses both electronic and digital signatures.

So, now we need to somehow build a chain of trust that enables CMS to be sure that the clinical documents it has are truly signed by the authorizing provider as asserted in the documentation.  Some issues I should bring up:

1. These auditors jobs are just to address mistakes made in billing.  They aren't there to address fraud (another arm of CMS deals with that).  Almost assuredly they do find fraud too, but that isn't there main role.  
2. One of the complaints that CMS hears from providers is that the different auditors use different rules to determine whether a document was signed, and each develops their own guidelines.  What is looked for today is some evidence that a document was signed, a date, some text indicating that the provider electronically signed it, or evidence of a wet signature.  Different organizations have different rules about what suffices.  Given the current level of technology used today, jumping to digital signatures is by comparison, like swatting a fly with a jackhammer (something that apparently was being used quite effectively for something other than fly-swatting upstairs today -- fortunately I wasn't in a room affected by it).

So, you have a generating system, a provider, an HIH, the auditing organization, and CMS to build this chain of trust between.  One of the questions that I asked is how VA handles this today with their systems, because clearly they are a federal agency transferring PHI to other providers, such as Kaiser.  Well, in the NwHIN, these organizations sign the DURSA, which is apparently enough to resolve these problems.  But CMS doesn't want to have to execute a DURSA agreement with every provider it wants to send electronic requests to.  So they want another way to solve this problem.  I don't know if CMS executes a contract with every provider that bills it, but I would certainly expect that there would be something like that already.  I don't know if they could add something small (the DURSA is 40 pages) to that to enable the trust they need, or if a full blown digital certificate process is really needed.  And CMS apparently doesn't want to have to trust the HIH to certify that providers have signed up with them (although it might be easier to execute something like a DURSA with the smaller number of HIHs than the much larger number of providers).

It all gets very tangled, and this is why I stay away from security.  I'll be interested in seeing what they work out, but I'm pretty sure if they try to go down the digital certificate path with all providers wanting to sign up with an HIH they'll create more trouble than they need.

I don't have any solutions at the moment, just some thoughts:

1. Many EHRs implement electronic signatures inside the system.  If this becomes a certification requirement, and providers are attesting to use of a certified EHR that generates the attachment content, these two steps can provide one link in the chain.  There is, of course, in this CMS activity, no direct connection to Meaningful Use certification, but those processes might help.
2. Some of these organizations contract with, or must execute an agreement with CMS or one of the organizations that it contracts with.  Add something to those agreements to add trust.  You might even include digital signatures at some level, but don't go down to the provider level.
3. Providers need to engage with the HIH and execute an agreement with them.  Allow the HIH to obtain a wet signature on paper, which maybe they can later scan and digitally sign.
4. The HIH is dealing with responding to an already existing claim.  If the HIH sent the claim to CMS, what processes did they use to establish trust with CMS to do that and to enable other transactions where CMS can send them claim status?  Can those processes be extended to cover sending the request?  If they didn't originate the claim (are only dealing with audits), could a similar agreement to those used by claims originators (and therefore claims status checkers) also be used to establish another link in the chain for these kinds of organizations?

And of course, as I read back through all of this, I realize that I too have entangled trust of the provider signature up with some other trust around relationships between CMS and the provider that enable the PHI to be sent in a request to the provider.  I told you it was complicated.