Toward a Virtual Lifetime Electronic Record: The Department of Veterans Affairs Experience with the Nationwide Health Information Network

NwHIN Exchange Pilot Program at VA

On December 17, 2009, VA and Kaiser Permanente (KP) took their implementation of the NwHIN Exchange specifications live in the San Diego, California area. DoD joined on January 31, 2010. These connections provided VA, DoD and KP clinicians with a simple functionality for health information “query” and “retrieve” from each other’s EHRs. This was the beginning of the VLER Health and NwHIN pilot program [8].

The program was expanded to 11 additional VA sites with 11 different VLER Health private sector partners (PSPs), supported by different HIE organizations; all consistently implemented the same standards for patient matching, query and retrieve and content formatting. Today, all these pilot sites have demonstrated exchange of information based on real patients who provided authorization to VA and those private sector partners who required authorization. More VLER pilot sites have been added in 2012, but are not reported here.

VA HIE, which includes access to all VA facilities and VLER partners, resides centrally and is developed and maintained by one VA national team. This central team is responsible for ensuring VA technical solution conforms to NwHIN standards specifications. In parallel, VLER partners also test and onboard their implementation against ONC compliance criteria. For each pilot, a shorter testing phase between VA and the VLER partner has been required to ensure compatibility of various technical and content details. In the long term, hopefully, this peer-to-peer testing will be reduced to a minimum, as the standards mature and the NwHIN evolves into a more “plug and play” interchange platform.

Each VA pilot site also includes a VLER Health Community Coordinator. This is a local staff member working at the VA Medical Center (VAMC) whose responsibility it is to set up and assist a local team that will oversee the VLER Health implementation. The local work is threefold: 1) production validation of the exchange to ensure the exchange and the data are as they are supposed to be, 2) patient enrollment in the VA NwHIN program through information campaigns and the collection and data entry of the patient authorization preferences, and 3) provider training and promotion to use the HIE.

Clinical Data Available for Exchange and User Interface

The VA and participating PSPs exchange clinical data through use of two primary content standards called the C32 and the C62. The C32 and C62 are Continuity of Care Documents (CCDs) based on HL7 standards and xml syntax to describe administrative (e.g., demographics, insurance) and clinical (e.g., problems, medications, allergies, test results) information. C32 content is comprised of 18 content modules that represent clinical data in both structured and textual form. C62 documents represent unstructured clinical notes (e.g., consults, history and physicals, discharge summaries, results of diagnostic tests, radiology reports, and surgery reports). These standards are the foundation for an interoperable NwHIN system, where health information can be consumed by any health system using software that is compliant with NwHIN exchange standards.

To integrate data retrieved through the NwHIN, VA utilized the same HIE platform (called VistAWeb) used to view data from remote VA sites and extended it to include data retrieved through the NwHIN. Indeed, the VA EHR, the Computerized Patient Record System (CPRS), only shows data from the local VA facility. When remote data from other VA facilities or DoD or NwHIN partners are available for the patient, VA clinicians are notified and can click on a link to a Web application (VistAWeb) to see these data either each source separately or all integrated. To a VA clinician, other PSPs like KP are seen as other facilities and sources of data. VistAWeb does not require a second user login and preserves the patient context.

Individual source data are displayed using style sheets to render the xml tagged information [see Figure 1 for an example].

Integrated data views are also available for most data modules in the C32 and C62 documents (see Figure 2 for an example).

Implementation of NwHIN Exchange at VA

To implement the NwHIN functionality, a health care organization needs two new components: a Gateway and an Adapter (see Figure 3).

Adapter/Gateway

The Gateway provides the services required to connect to the NwHIN Exchange over the Internet. The Adapter provides the services required to connect the backend system (Veterans Health Information Systems and Technology Architecture [VistA] in the case of the VA) and the Gateway. To stimulate adoption of NwHIN Exchange, VA, DoD, and other federal agencies have combined investment and development resources to produce a public domain NwHIN-conformant gateway called the CONNECT Gateway [9]. Each of these federal agencies now uses a copy of the CONNECT Gateway, and several private sector health care organizations have taken advantage of this opportunity as well.

Veterans Authorizations and Preferences (VAP)

VAP is the subsystem responsible for authorizing health information exchange to trusted PSPs and managing Veteran electronic consent directives. VAP creates an enterprise-wide electronic solution capable of supporting Veteran authorization preferences and consent directives. Also, it enforces organizational policies on privacy and security relative to Release of Information (ROI), and the disclosure of individually-identifiable health information to carry out treatment. The VAP system is comprised of both user and machine interfaces to set patient preferences for how patient data can be shared.

Signed authorizations from Veterans can be obtained either on paper (mailed in or hand delivered) and then entered into the VAP system by ROI staff or electronically by using the VA/DoD eBenefits patient portal, where Veterans can sign pre-approved authorizations. These authorizations are then processed automatically by VAP without human intervention. The VAP application generates three main reports: 1) the Accounting of Disclosures, 2) the Received NwHIN Documents Report, and 3) the Opt In/Opt Out Report. These reports provide a required audit and accountability of the transactions conducted over the NwHIN, including access to copies of the information exchanged.

Measuring the Value of Information Exchange

Access to a complete EHR through the use of HIEs is expected to yield safer, higher quality health care at a lower cost by reducing duplication of tests, therapies, and hospital admissions; this access will provide better medication management and improve patient engagement. However, formal evaluations are rare [10]. VA’s has setup a formal evaluation plan organized across seven evaluation domain areas: 1) System performance (e.g., system availability, response time); 2) Veteran participation (e.g., outreach, education, and authorization of exchange [opt in]); 3) Usage (e.g., frequency of use, usability); 4) Provider experience and satisfaction; 5) Veteran experience and satisfaction; 6) Outcomes (e.g., quality, utilization, processes, and related costs); and 7) Implementation and maintenance costs.

These metrics will help inform the VA scalability plan and national deployment of the VLER/NwHIN program to all VAMCs. The complete VLER program evaluation report is not yet available and will be reported in a future submission. However, early results are promising in terms of health expected care cost avoidance at selected VA emergency department pilot sites [12].

Implementation of NwHIN Direct at VA

To implement the NwHIN Direct secure email communication protocol, VA also leveraged the reference implementation available through ONC (Java instance). This component provides the management of certificates and the secure communication with other standards-based communication “Gateways.” In addition, the NwHIN Direct solution required an “Adapter” component that handles the interfaces with the VA system (VistA). This Adapter is responsible for automatically extracting health information that needs to be sent out to non-VA providers and for importing health information from non-VA providers into the VA EHR.

The NwHIN Direct platform user interface is a typical Web mail user interface, built in-house for better integration with VA systems. Another major integration is with the VAP system described above for the tracking of disclosures. However, the issue of privacy and patient consent are less significant for a push technology like NwHIN Direct.

VA NwHIN Exchange Partners

VA has been an early adopter and active participant of the NwHIN activities since the prototypes phase. Currently, VA is successfully exchanging real patient data over NwHIN with the following PSPs:

• Kaiser Permanente (San Diego, California);

• MedVirginia (Hampton, Virginia and Richmond, Virginia);

• Inland Northwest Health Services (Spokane, Washington);

• Indiana Health Information Exchange (Indianapolis, Indiana);

• HEALTHeLINK (Buffalo, New York);

• Community Health Information Collaborative (CHIC) (Minneapolis, Minnesota);

• North Carolina Healthcare Information & Communications Alliance, Inc. (NCHICA) (Asheville, North Carolina);

• South Carolina Health Information Exchange (Charleston, South Carolina);

• Utah Health Information Network (UHIN) (Salt Lake City, Utah and Grand Junction, Colorado);

• MultiCare (Puget Sound, Washington);

• San Diego Beacon Community (University of California, San Diego, California); and

• DoD (San Diego, California; Hampton and Richmond, Virginia; Spokane, Washington; Puget Sound, Washington).

VA actively assisted others to become full NwHIN participants, providing whatever support was needed to complete ONC onboarding and the additional VLER partner testing. VA and DoD coordinated workgroups with their PSPs to address the main challenges including patient identity matching, messaging, data content, and project management. These workgroups clarified any questions within the NwHIN specifications, made recommendations on optional components, and explicitly documented how each PSP system was configured. For instance, the Patient Matching Workgroup re-emphasized the importance of standardized format and values for the patient demographic traits to ensure a match and documented what traits each partner sends with a patient discovery message (i.e., do you know this patient) and what traits are used by their patient matching algorithm. The Data Content Workgroup clarified the C32 and C62 specifications, compiled an XPath spreadsheet showing each PSP’s location and tagging their data elements in the CCDs, and encouraged each PSP to share a fully populated sample CCD so that style sheets could be developed and tested.

After testing was completed using test patients, the software was released with limited production use until further “production validation” was conducted by the VLER Health Community Coordinators. This production validation phase was done using real patients (i.e., opted-in patients only) as permitted by each PSP’s policies. The total number of unique patients at the 12 VA NwHIN pilot sites is estimated to be 645,000. The number of shared patients with VLER partners is difficult to estimate, but the VA business office previously evaluated that 65% or more Veterans receive a portion of their care from the private sector [11].

Veteran Participation

VA is an opt-in consent model, meaning that Veterans have to provide a signed authorization before their VA EHR is disclosed to non-VA/DoD providers. Enrollment is accomplished using different methods including mailing invitations, during registration, through eBenefits, at the ROI office, at the dispensing pharmacy, etc. As of May 9, 2012, a total of 48,744 Veterans completed VA VLER Health authorizations. The number of Veterans who were contacted by the VA with information about VLER Health is not readily available. As of May 9, 2012, VA received 244 subsequent requests from Veterans to opt-out of VLER Health after opting-in, reflecting less than 1% of total authorizations. Veterans can opt-out at any time, and may opt-in and out multiple times.

Initially, pilot sites mailed invitation packages with authorization forms included, often from both VA and the PSP (if required). However, over time, sites adopted a more integrated enrollment during registration or visit, as it is a more scalable approach. Veterans also have a patient portal where they can e-sign the VA authorization form and have it recorded and processed automatically without any human intervention.

Mail campaigns have been relatively successful, with up to 50% participation. When the VLER/NwHIN program is presented in person to Veterans, it is exceptionally rare that they decline participation. The online enrollment is under-utilized, mainly due to the effort required to create an account with “in-person authentication.” Remote proofing is being implemented, which should reduce this burden significantly. Current education and authorization methods are attracting older Veterans and those who reside in urban areas, but are less likely to attract younger Veterans and those who reside in rural areas, confirming initial impressions reported [8].

Correlations

After a patient is enrolled and the signed authorization is recorded in VAP, the system announces the patient’s identity to all VLER partners in an attempt to determine if the patient is known and may have records elsewhere. Demographic traits are exchanged during this “Patient Discovery (PD)” exchange and each PSP responds with a positive match or an empty reply. When a positive match is found, the responder sends back their demographic traits and their patient ID. This enables the sender to validate the match using the demographics received. This is considered a “no risk” approach. However, the patient match success rate is far less than ideal. As of May 9, 2012, a total of 23,611, or 53%, of Veterans who opted in were successfully correlated by the VA with a NwHIN Exchange Partner. The failures are mainly due to lack of accurate, standardized, complete data. In other words, without a complete set of the primary identifiers (i.e., first name, last name, middle name/initial, gender, date of birth, and social security number), it is unlikely to reach a positive match or correlation. Other reasons include partial coverage of opted in Veterans population, requirement for a second authorization, and difference in matching algorithms.

Other insights related to Identity, Privacy, and Consent Management gained from our initial experience include:

• When onboarding a new participant to NwHIN that has millions of patients, creating initial correlations is challenging. PD as a broadcast-out model is difficult to scale for a future NwHIN that supports hundreds of HIEs.

• PD specifications do not provide clear guidance on how to keep the patient correlations up-to-date when there are patient ID changes (e.g., marriage), merges, etc.

• Inclusion of the full Social Security Number (SSN) in the demographic traits is necessary for any reasonable level of matching success. Some organizations or states do not exchange SSNs or only exchange the last four digits, which makes it unlikely a unique match can be achieved.

• Lack of a “common/standard” consent model is a barrier. Patients may have to sign multiple consents, one for each organization, before their data are shared.

• Specification would benefit from more clear definitions of the Security Assertion Markup Language (SAML) attributes and more complete XML samples of the permitted values. For example, it is unclear how the SAML assertions provided in a Patient Discovery (PD) are to be used in combination with the SAML assertions provided in the subsequent Query for Docs (QD) and Documents Retrieve (DR). For example, if a PD exchange occurs with Purpose of Use = Treatment and Role=Medical Doctor, how are implementers supposed to respond to a subsequent QD that comes in where the Purpose of Use = Treatment but Role=Administrative Health Care Staff?

Content (C32 and C62s)

Evolving data standards and specifications lead to data mapping, display, and usability challenges. Further, NwHIN Specifications are silent with regard to the payload, and subject matter experts (SMEs) are absent for providing clear guidance to NwHIN participants. As a result, during implementation, it has taken substantial negotiation between partners to align differing interpretations. The National Institute of Standards and Technology (NIST) tool [http://xreg2.nist.gov/cda-validation/validation.html] is seen by most as a helpful tool for content validation, but it does not validate the complete C32 instance and still allows for variations that have to be accommodated by receivers of the information. Further, C62 validation is yet to be created. Key data content exchange issues and areas of improvement include:

• Increasing the use of a C62 documents instead of embedding clinical reports inside the C32;

• Protocols for early tests of exchange of a fully populated C32 to ensure all data elements are represented and displayed correctly;

• Better use of validation and testing tools for determining whether an XML instance document is correct with respect to the specifications identified within related HITSP constructs;

• Notification to end-users that the patient has data over the NwHIN;

• Improved integration of C32/62 data received within EHR systems;

• Explicit definition and display of data filters used to populate each section of the C32. This is necessary in order to inform end users, control volume of data, and improve response time;

• Systematic response behavior for when there is no C32 document available, no data for a particular section of the C32, or no specific data element in a section is available; C32 schema data requirements do not seem to match the real world data that are available. This leads to padding xml documents with “UNKNOWN” data structures.

• Better definition of syntax for narrative sections of the CDA and a case can be made for the need to populate the structured sections so data can be organized and integrated;

• C32 specifications do not provide a simple single Xpath to data locations. The current specifications typically only have the very end of the XPath explicitly indicated. There are many cases where it is unclear exactly how these end XPaths should be anchored. Thus, implementers may select different full XPaths for the same field (e.g., entry/act/effectiveTime/low/@value vs. entry/act/entryRelationship/observation/effectiveTime/low/@value).

• More specific display of data sources (e.g., hospital name instead of HIE name);

• Document classes as defined by Logical Observation Identifiers, Names, and Codes (LOINC) for the exchange of “C62/HL7 Unstructured documents” lack granularity and clarity. For instance, does “procedures” include diagnostic and treatment procedures (e.g., surgeries)? What does the document class “interventional study note” include? There is a need for a standard document ontology that provides both standard document titles and a standard hierarchy classification. Mapping individual note titles to current LOINC class codes leads to issues when sharing information, either by having to request too broad of a code and getting too many results, or too specific of a code and missing results.

• It would be desirable to have a single (universal) style sheet that all PSPs could use for C32 data display. This reference style sheet would enable viewing of all fields, both code and text, via all options that are considered valid (e.g., originalText, displayName, using references, code without display).

• Methods for decreasing data duplication when the same data elements are received from multiple partners.

• QD specifications do not properly handle the issues of different date ranges across multiple C32 modules. Date range for a C32 is not practical or clinically meaningful. Date ranges are needed at the level of each C32 section (e.g., allergies, medications, problems, labs, etc.).

• QD specifications do not provide any clear guidance on retrieving large volumes of data sets.

The recent work of the newly formed HL7 “Consolidation CDA” workgroup is helping address these issues and other similar problems reported by SSA, CMS, and a multi-state/vendor Care Connectivity Consortium, all using the NwHIN Exchange standards.

VLER Health Usage

One pilot was implemented in 2009, another in 2010, and the remainder sites in 2011. Consequently, there are too few transactions recorded at the time of this publication. There are hundreds of transactions between VA and PSPs and thousands between VA and DoD. We expect the number of transactions to grow significantly as the system’s availability is more reliable, as the richness of the content is more consistent across VLER partners, as the number of patients enrolled grows, and as the end users become more familiar with the new functionality and the data available to assist them with clinical decision making.

NwHIN Direct Pilots

NwHIN Direct is a relatively recent project at ONC and at VA (started late 2010). VA selected the “Mammography Consults and Referrals Use Case” as the first use case to implement NwHIN Direct. There are over 100 VAMCs that refer over 100 mammography services to non-VA providers. The process for handling these referrals is being standardized across VA facilities. NwHIN Direct supports this standardization initiative by providing an efficient and secure communication between VA and its PSPs.

There are several NwHIN Direct pilot sites under implementation, including Tennessee, Utah, Washington DC, and others. Although the first use case is mammography referral, software development is underway to expand functionality to cover all outpatient and inpatient referrals and ultimately all communication types that can improve coordination of care between VA and non VA providers caring for Veterans. Also, the use of NwHIN Direct by patients to securely send their VA records to non-VA providers or to commercial Personal Health Records such as Microsoft Health Vault is also being considered. Note that NwHIN Direct focuses as a starting place on the mammography use case, but NwHIN Exchange is not limited to a particular use case and covers all types of patients and the exchange of their health summaries and clinical notes.

Through this initial work with NwHIN Direct we have learned several important lessons:

• Workflow engineering is critical and must precede migration from paper communication through fax and hand carry to secure email messaging. It is essential to obtain stakeholders buy in.

• Integration with EHRs is difficult, both for outbound referrals and inbound consultation reports, but must be addressed to provide real gains in productivity.

• Public Key Infrastructure (PKI) certificates are currently issued by the local VA and are individual certificates as opposed to organization level certificates; this is a bottleneck. There is need for trusted sources that can issue federal bridge anchored, organization level, PKI certificates.

• There is a need for provider directory standards and how to populate and share these directories.

• NwHIN Direct users do not have standardized email addresses (e.g., xxxx@direct.va.gov)

• Content payload lacks standard specifications or best practices, which slow down progress and integration of NwHIN Direct communication with all the tools that providers use to best support care.

• Lack of Memorandum of Understanding (MOU) agreements between NwHIN Direct services vendors (also called HISPs) and the provider members they support also slows down progress. These MOUs will should include re-assurance assertions of privacy and security measures taken by the HISP.

Finally, during this initial VLER Health pilot phase, there were several governance issues that hampered progress, which since then have been shared with and addressed by ONC in their new governance proposal. For instance, there is currently no “availability” rule imposed by ONC on NwHIN participants. An availability rule would enforce uptime requirements and drive performance for all NwHIN participants. Also, ONC is the only body onboarding NwHIN candidates. To relieve this bottleneck, ONC is considering defining accreditation rules for private sector bodies to help with onboarding, similar to the EHR Certification process. Finally, there is a need for a repository of all NwHIN standards and an easy way to find them. Guidance on what version of the NwHIN specifications should be implemented and honored during exchanges is needed.