One of the most high-profile ARRA NHIN contracts, the Social Security Administration's (SSA) effort to gather medical evidence in support of disability claims over the Nationwide Health Information Network (NwHIN) and expand the Exchange's Participant list to a more national coverage is finally realizing tangible results as a number of contractors have moved their systems into go-live production state. For those of you don't remember this contract, it was awarded way back in February 2010 before Meaningful Use regulations were even finalized.
Of the 15 initial contractors, Douglas County Individual Practice Association (DCIPA), EHR Doctors, HealthBridge, Inland Northwest Health Services, Marshfield Clinic, MultiCare Health System, MedVirginia, OCHIN, Regenstrief Institute and Southeast Michigan Health Information Exchange have completed the contract.
[Related: Mapping the future of NwHIN in Maine and the Bronx.]
Community Health Information Collaborative (CHIC) went live in late September, and several of the contractors, including Center for Healthy Communities, Wright State University, and Lovelace Clinic Foundation (LCF), are slated to "go live" in the coming weeks. Several contractors, including CalRHIO, Carespark, and Gulfport Memorial Hospital gave up on the contract. In the case of CalRHIO, they folded up shop before the contract got started, and CareSpark closed its doors before they could reach the first milestone. Carespark's chairman said that "getting answers back from SSA was 'difficult,'" and "the final nail in the coffin was its inability to provide the technology in order to participate fully."
Please keep in mind that our technology design goal from the get-go was to create a complete HIE platform based on NwHIN Connect software from the Federal Health Architecture. We aimed to create our own technology for generating continuity of care documents (CCD) from an EHR instead of relying/waiting on a Meaningful Use CCD to come from the EHR vendor, which wouldn't have met the SSA Content standards anyway and didn't come until months too late. We also wanted to access EHR data directly and be able to map local clinical terms into standard coded terms during the process, something we know many EHRs lack and are important for the CCD if you want semantic interoperability.
We also developed our own document repositories and master patient index, and interfaced these services with the hospital EHR. We focused on patient privacy by refusing to shortcut having a patient privacy policy engine capable of applying discrete rules, something that Connect did not have in its stack. In addition, we wanted to validate our ability to let users request data from the NwHIN, something the contract with SSA didn't initially require, but ultimately did because they invented a new protocol during the course of the contract. We wanted to develop a GUI client that would let providers search, download and view patient documents over the NwHIN. All of this was pretty ambitious, but it was clear we needed all this technology to have a viable platform for HIE for our business to continue after the project.
For those of us who survived the ordeal, we learned some real-life practical lessons about HIEs that can be helpful to those following in our footsteps:
1. Meaningful Content is King. This old adage applies to EHRs and CCDs, too. When preparing our response to the RFP, we were provided a continuity of care document implementation guide that set forth the SSA markup and content requirements for what needed to be included in the CCD. We also had to prepare a content checklist and indicate what content we could include in the CCD from OpenVistA, our partner hospital's (Midland Memorial) EHR. The SSA was looking for enough documentation to render a disability determination. As always, the devil is in the details. The first milestone required us to produce a CCD from the hospital's EHR. We had to use a test patient because obviously no single patient in the EHR had all the information that the implementation guide required to us to mark up in a sample.
Once we agreed with SSA on the sample markup, we had met our first milestone and moved on to producing 50 CCDs for actual disability patients so that SSA could validate that what they were receiving from us electronically was the same as from the hospital via the paper process. Once we had our 50 CCDs passing the schematrons and definitions from NIST, we started analyzing the content and realized that many providers didn't fill out things like problem lists or a history of procedures in the EHR as structured information, even though the capability is present in the EHR. Now, Meaningful Use requires problem lists and allergies to be maintained on 80 percent of patients, but remember MU wasn't even defined when we bid on this contract.
[See also: The 5 roadblocks HIEs face. And this Q&A: On the trials and tribulations of unlocking patient data.]
Additionally, providers in an inpatient or outpatient setting don't code things like problems, diagnosis and procedures in the EHR. This is done by billing clerks in the financial package based on the clinical documentation in the EHR. Sure the billing package can have an HL7 interface back to the EHR to send back the coded information, but this interface might not be implemented because clinicians don't really care about coded diagnosis or procedure information in the EHR. What did that mean for us? We needed diagnosis information and a history of procedures because we indicated that we had it in the content checklist, so we had to construct an interface into the financial package at the hospital to get this coded information into the CCD that way.
For entities that would like to exchange records with the SSA, keep in mind that the CCD coming out of your EHR would not meet SSA's requirements even if it meets Meaningful Use. Meaningful Use doesn't require interoperable notes, encounters, vitals, family histories, plan of care, or activities of daily living assessments.
2. Structured vs. Unstructured Info in an HIE. Scanned documentation is useless to a CCD. Both HITSP C62 and Integrating the Healthcare Enterprise (IHE) and HL7 Clinical Document Architecture (CDA) have a template for base64 encoding the bytes of a scanned document and wrapping it as structured document meta data from CDA. This can be exchanged just like a CCD and this is very pertinent information to the patient's health. Unfortunately, SSA did not consider this and did not plan on supporting C62. As a result, scans were out, and this caught some of the contractors, who had indicated they had this content, by surprise. Meaningful Use EHR standards do not require that EHRs create C62 interoperable documents.
3. Specs, and their implementations are still unsettled. Along the same lines of the scanned documents, SSA also asked us to include text notes in the encounters section of the CCD. This became the subject of controversy in the standards harmonization community. A growing consensus of interoperability gurus takes the position that the way to handle next notes is creating a C62 for each test note and linking to them from the CCD.
SSA also asked us to implement a new NwHIN standard that wasn't even on the table when we bid on the project. This is known as access control protocol, which is a mechanism to exchange consent forms during a patient discovery request to make the release of information to SSA legit. This spec had only been implemented once or twice and was not part of the Connect software, so we had to develop our own Connect plug-in to implement the protocol.
Even the Meaningful Use standards changed the targets in the contract. The Secretary of HHS adopted the HITSP C32 as the interoperable format of choice. The SSA originally specified HL7 CCD, which is a subset of C32. So we had to push further than we originally intended.
[Cover story: The Direct route to more pertinet patient information.]
Unsettled, relatively new specs usually result in half-baked implementations, and the NwHIN Connect is no exception. There were plenty of problems with the FHA's NwHIN Connect Software that we weren't aware of until they manifested during the ONC/NIST conformance testing process for NHIN on-boarding. It surprised us that Connect had so many conformance issues, and that we would be required to fix them. Fixing these items took us three months and we were one of the first contractors to finish. Those looking at Connect should be aware that it requires a lot of integration code to make it work. The good news is Connect is open source, so if you have good Java programmers who understand HIE and aren't scared of a debugger, these things are fixable.
Other than conformance, there were also things in Connect that were incomplete and not ready for a production HIE system. The biggest holes were in the privacy policy decision point (PDP), universal client (for searching/retrieving NwHIN patient records), MPI (which Connect requires but doesn't provide even a simple scalable one), and the document registry/repository, which is so far out of spec it isn't funny. The changes from version to version of Connect are substantial, and new services are being added all the time to support new standards and apparently most of the development went into that and not properly testing code. Also, the sample data sets provided are terrible and not representative of anything real life, so we had to develop our own. SSA's interoperability testing revealed even more conformance problems that weren't caught or noted by NIST and ONC. I still don't know why.
4. Semantic Interoperability is still a few steps away. After all the focus on structured info - and we had all CCD sections, including problems, procedures, encounters, documents, labs, procedures and vitals - the irony is that SSA ended up creating a series of TIF images of the human readable information and putting it into the case reviewer's mailbox (it all ended up as unstructured information). At HIMSS11, the SSA showcased its ability to apply decision-support rules to the structured information and flag content for a manual reviewer; however, they did not put that system into production for some reason. My guess is that standard coded vocabulary content hasn't hit critical mass yet in EHRs and the resultant CCDs yet. The future promise of this technology boils down to a matter of semantic interoperability. Although we were able to provide standard codes for most of the sections (we supported ICD9, SNOMED and LOINC), my guess is that other contractors, many of whom tried to reply on the EHR vendor's CCD instead of developing their own CCD, didn't have a terminology service to code clinical terms even if they weren't coded in the EHR.
I'll admit I don't know many specifics about the other contractors. I did speak to several other contractors at HIMSS and a few contacted me via e-mail with questions relating to the CCD and NwHIN Connect. I would like to hear from the other contractors and compare content checklists and CCDs with them to see how they turned up. I would also like to hear how they tackled some of the issues I noted earlier with NwHIN Connect.
As president of EHR Doctors, Gerard Reeder is responsible for running all facets of the business.
