36C77619R0006-0002009.docx

Veterans Health Information Exchange (VHIE) Health Exchange

VA Business and Technical Requirements (VBTR) Document

Final

January 2016

TABLE OF CONTENTS

VHIE HEALTH EXCHANGE VBTR DOCUMENT

1. Purpose and Scope President Barack Obama announced the Veterans Health Information Exchange (VHIE) initiative on April 9, 2009, stating the Department of Defense (DoD) and Department of Veterans Affairs (VA) would “work together to define and build a seamless system of integration so that when a member of the Armed Forces separates from the military, he or she will no longer have to walk paperwork from a DoD duty station to a local VA health center. Their electronic records will transition along with them and remain with them forever.”

The VHIE Initiative was launched by this announcement in both VA and DoD, via the DoD/VA Interagency Program Office (IPO), to address gaps in electronic availability and compatibility of a Servicemember’s or Veteran’s lifetime health and administrative records. Later in 2009, VHIE Health was the first VHIE Program to deploy a technological solution to exchange health information with private sector providers based on national standards over a secure, trusted network.

In 2013, VA and DoD separated their respective VHIE Health Programs from the DoD/VA IPO. Today, the VA VHIE Health Program is being implemented within the Veterans Health Administration Office of Informatics and Analytics.

The VHIE Health initiative is intended to provide portability and accessibility of health data for Veterans. It will enable secure, seamless, cross-boundary information sharing among VA, and participating private sector partners nationwide by leveraging and advancing comprehensive standards and best business practices for Health Information Technology (IT). In doing so, it will result in improved quality of care for our Veterans.

The scope of the VHIE Health program is to deliver the capability to exchange clinical health data of veterans with Private Sector Providers using the eHealth Exchange

Visual Depiction of the eHealth Exchange

The purpose and scope of the VHIE VA Business and Technical Requirements (VBTR) Document is to document unique VA business, technical, and content requirements as well as scope definition for onboarding with VHIE Health. The VBTR is intended to serve as the authoritative project document for this information. The VBTR is in addition to each VHIE partner’s requirement; architecture/design and/or development related to onboarding the eHealth Exchange.

This VBTR is for the query-based Exchange. VHIE Health program has a separate VBTR for the Direct project.

The VHIE Health Exchange VBTR is organized as follows:

1. Purpose and Scope

2. VHIE Health Exchange Objectives

3. Assumptions

4. VHIE Health Exchange unique requirements

5. VHIE Health Exchange onboarding process

VHIE Health Exchange Objectives Use Case Missing from the Veteran’s electronic health record is important information based on care provided by private sector healthcare systems. Since the majority of Veterans receive a portion of their health care from private providers, a significant, often critical, piece of the “story” of the lifetime health record is missing, or at least disjointed and unavailable electronically. VHIE Health Exchange was initiated by VA and chartered as a program at the IPO to pursue health record interoperability with private sector providers in order to acquire and share this missing health component of VHIE. The use cases include continuity of care and transfer of care scenarios.

Workflow VHIE Health Exchange gives clinicians from eHealth Exchange participating organizations immediate access to important health record information at the point of care and has the potential to improve care for Veterans. VHIE Health Exchange is a query-based exchange where a clinician from one organization can request, receive, and display health information from other participating organizations that know the patient.

The health information exchanged between VHIE Health Exchange partners for shared patients who opted in the exchange is shared primarily using 2 types of standards-based documents:

1. A health summary document formatted as:

a. HITSP C32 (C32 Header + Body with C32 Section Templates)

b. C-CDA R1.1 Continuity of Care Document (CCD) (C-CDA R1.1 Header + CCD Section Templates)

2. A clinical note document formatted as:

a. HITSP C62 Unstructured Document [C32 Header + Non-XML Body (txt, pdf) ])

b. C-CDA R1.1 Structured Note Document (C-CDA R1.1 Header + Section Templates)

c. C-CDA R1.1 Unstructured Note Document [C-CDA R1.1 Header + Non-XML Body (txt, pdf, gif, tif, word, etc.)] Business Objectives VA management priorities guiding the development of the VHIE Health Exchange program include the following priorities:

1. Support the VHIE Health Exchange initiative by:

· Increasing the rates of adoption at existing locations

· Adding partners based on mutual identification of business drivers, Ability to engage in high volume high quality exchanges

· Trait Matching, health information exchange (HIE) maturity, Exchange Volume, Standards Use, Population

· Emphasizing “gaps” to promote regional health exchange (i.e., Southeast, Intermountain West)

2. Maximize Return on Investment (ROI)

System Overview To implement this standard-based solution, each organization needs to implement 2 basic components: a Gateway and an Adapter (see Figure 1). The Gateway communicates with other Gateways securely over the Internet. VA VHIE uses the publicly available CONNECT gateway (version 4.2.2.2 - version 4.5 targeted for 2016). The Adapter translates between the Gateway and the organization backend system or EHR. The User Interface (VistAWeb) initiates data queries over the eHealth Exchange and displays this data to clinician end users. The patient databases (VistA) are used to extract the data which is then transformed into CCD documents by the Adapter to respond to queries from VHIE Health Exchange partners. The Master Veteran Index (MVI) enables patient identification (ID) matching to ensure requestor and responder are communicating about the same patient. The Veterans Authorization Preferences (VAP), a required component, serves the VA to record patient consent directives and enforce them through a policy decision engine, as well as audit transactions in order to meet disclosures accounting obligations.

Figure 1: VA systems, at a high level, that support VHIE and eHealth Exchange

Performance Evaluation Overview A comprehensive, transparent assessment and evaluation of the VHIE Health Exchange production pilot program was initiated in 2009. Between October 1, 2011 and March 31, 2012, the performance of these pilots was the subject of rigorous measurement and data collection. A summary of key findings is discussed around these domains: 1) Technical Capability; 2) Value and Usability; and 3) Readiness. It provided a status of the current pilots and a summary of significant findings, and it informed a set of options for future engagement in HIE activities for VA. The findings provided an assessment of factors considered essential to national deployment, such as Department system capability, private sector capability, standards maturity, privacy, security, consumer choice, patient matching, usage, data content quality and availability and consumer and clinician perceived value.

VHIE Health Exchange Partners participated in the previous performance evaluation. In particular, they facilitated interviews with their providers and patients. VHIE Health Exchange Partners participation in future performance evaluation program would be welcome.

Assumptions eHealth Exchange Onboarding VHIE Health Exchange partners have completed successfully the eHealth Exchange onboarding process as coordinated by The Sequoia Project [http://www.sequoiaproject.org/ehealth-exchange/onboarding].

eHealth Exchange Specifications Overview VHIE Health Exchange Partners solutions shall support the following eHealth Exchange Specifications, found here: http://sequoiaproject.org/resources/exchange-specifications

NOTES:

· VA supports 2010 and 2011 specifications.

· eHealth Exchange specifications may not be backward compatible, but CONNECT helps with that. It checks the UDDI info, identify what version the participant supports, and adapt its messaging to that version.

References:

Data Use and Reciprocal Support Agreement (DURSA) Executable Version dated 30 Sept 2014 > http://sequoiaproject.org/ehealth-exchange/onboarding/dursa/

· Health Information Technology Standards Panel (HITSP) Summary Documents Using HL7 CCD Component dated July 8, 2009 Version 2.5 http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32

· HITSP Unstructured Document Component dated July 8, 2009 Version 1.1 http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=62

HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm:http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258

VA VHIE Health Exchange unique requirements Business Requirements

0.1.1 Content Rich Information

VHIE’s eHealth Exchange partners are expected to send and receive patient health summaries (HITSP C32 or C-CDA R1.1 CCD documents) and clinical notes (HITSP C62s or C-CDA R1.1 Structured Note Documents, or C-CDA R1.1 Unstructured Note Documents). Regarding the patient health summary (HITSP C32 or C-CDA R1.1 CCD), VHIE Health Exchange Partners are expected to populate a minimum number of the content modules as shown in Table 4-10.

In addition, VHIE eHealth Exchange Partners are encouraged to send and receive clinical notes (HITSP C62s or C-CDA R1.1 Structured or Unstructured Note Documents). The clinical notes that the VA can both provide and receive are identified in Table 4-3: VHIE Health Exchange Document Class Codes Currently Supported. Therefore, Exchange Partners are encouraged to focus on implementing these Document Class Codes in order for VA clinical notes to be provided to their organization and so that VA clinicians can receive their organization’s clinical notes.

The VA C-CDA CCD also contains VA clinical notes within several sections of the document, but only the VA C-CDA CCD – the VA C32 does not contain clinical notes. Like all other clinical data in the VA C-CDA CCD, the included clinical notes are provided with VA-defined limits on the date range and number of notes. The specifics on these VA-defined limits are outlined in Table 4-12: VA CCD Data Limits. Whereas your organization can define these data limits when VA clinical notes are requested with a Query for Documents request for the desired Document Class Code(s) and data ranges.

0.1.2 Promoting Use of the System: pre-fetch, clinician training, and patient enrollment To promote use of health information exchange, it is essential that the system is responsive, the users are well trained, and patients are recruited to provide authorization and participate.

Pre-fetch It is recommended that VHIE eHealth Exchange partners consider the implementation of a ‘pre-fetch’ capability. A pre-fetch capability would trigger the query and retrieval of patient health information ahead of an actual encounter. This strategy will improve response time and make it more likely that health information exchange will be used during an encounter when clinician users need and request the information from the system. The information will be cached and ready to serve. This will in turn improve clinician’s adoption of health information exchange.

Implementation of the pre-fetching capability can vary. For instance, on a daily basis, the system could identify correlated patients with a visit appointment on that day and query and save their health information ahead of time. VHIE Health Exchange has defined the following requirements for its own implementation of the ‘pre-fetch’ feature:

· System shall identify Veterans that are correlated with an eHealth Exchange partner.

· System shall initiate retrieval of partner data no more than 24 hours prior to a scheduled appointment or scheduled admission for an eHealth Exchange participating patient.

· Data retrieved shall be temporarily stored inside the VA firewall.

· The clinician GUI (VistaWeb/iEHR/etc.) shall retrieve eHealth Exchange data from the temporary storage location.

· Clinicians shall have the ability to refresh/update the eHealth Exchange data as needed by initiating real time retrieval.

· System shall have the ability to display any new data retrieved via the real time retrieval.

Clinician training It is recommended and expected that VHIE Health partners provide training to clinician users on health information exchange.

At least 20 users should be trained on the partner system before go-live date. This will ensure a minimum amount of use of the system, feedback on the performance of the system, and benefits for patients.

It is expected that gradually, each VHIE Health Exchange partner will have in place a training plan for all users.

Patient enrollment If a VHIE Health Exchange partner requires patient consent prior to health information exchange (as VA does), then an active program for patient enrollment will be required in order to ensure a minimum return on investment in this technology.

VHIE Health Exchange partners need to demonstrate that an active program for communication and patient recruitment is in place to gradually increase the benefits of health information exchange to all Veterans treated in the private sector.

0.1.3 Promoting usability: single sign on, patient context, notification, and data integration The following capabilities are essential to make the system user-friendly, lessen the time requirement to access eHealth Exchange data, and help with adoption of health information exchange.

Single sign on Single sign on allow clinical users to request and receive health information from other organizations without having to leave their clinical information system and login another system.

Preserving patient context If a user must move to another system to request, receive, and view health information from other organizations, it is very helpful if the patient context is preserved between the original system (e.g., EHR) and the Health Information Exchange (HIE).

Notification Notification refers to the capability of the system to indicate when a patient has information available from external sources.

Data integration Clinicians find that data integration across all data sources more helpful than reviewing data from each source separately. For instance, presentation of a one aggregated medication profile is more useful than showing multiple medication lists. The next level of sophistication would be to assist with data reconciliation.

Identity traits Ability to send available identity traits in patient discovery message, such as: full legal name, date of birth, gender, Social Security Number (SSN), address, and phone number to improve patient matching.

Training Plan Plan to train health care providers on how to access VA data

Electronic health record (EHR) alerts Capability for EHR alerts informing clinicians that VA health data is available for viewing.

Pre-Fetch Ability for EHR to “pre-fetch” Veteran health data prior to patient encounter.

Technical Requirements

0.1.4 eHealth Exchange Specifications: Messaging Platform WS-I Security Profile 1.1 To onboard the eHealth Exchange, a participant needs to support all of the encryption methods, including FIPS 140-2. VHIE Health Exchange and other Federal Agencies require FIPS 140-2 compliant encryption. Private sector eHealth Exchange participants may not. This means that Private Sector participants who want to connect with VHIE Health Exchange will need to support FIPS 140-2 encryption.

For more information, see: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html Table 4-0: WS-I Security Profile

VHIE requires FIPS 140-2 compliant encryption – TLS v1.0

0.1.5 eHealth Exchange Specifications: Authorization Framework The Nationwide Health Information Network Authorization Framework is defined in Authorization Framework Production Specification v2.0. See Table 4-0: above.

Additional clarification and scope limitations unique to VHIE Health Exchange are provided below.

Subject The <Subject> element shall identify the Subject of the assertion. This element also includes a NameID Format attribute which declares the format used to express the value contained in this element – the person making the request at the initiating organization:

UID=user ID, CN=First name and last name, O=name of the organization.

Filling in these values correctly helps with compliance testing.

Note that the term “subject” in SAML and XACML refers to the individual making the request. In this specification, the term “User” is generally used with the same meaning, but when referring to attributes defined in SAML or XACML, the naming convention of the standard is retained.

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"> <saml:AttributeValue>Walter H.Brattain IV</saml:AttributeValue> </saml:Attribute>

Organization-id “urn:oasis:names:tc:xspa:1.0:subject:organization-id” A unique identifier for the organization that the user is representing in performing this transaction shall be placed in the value of the <AttributeValue> element. This organization ID shall be consistent with the plain-text name of the organization provided in the User Organization Attribute. The organization ID may be an Object Identifier (OID), using the urn format (that is, “urn:oid:” appended with the OID); or it may be a URL assigned to that organization.

OrganizationID holds an OID of the facility. When a partner is identifying a trust community, they need to look at the HomeCommunity ID and not the more detailed OrganizationID.

HomeCommunityId <saml:Attribute Name="urn:N HIN:names:saml:homeCommunityId"> <saml:AttributeValue>urn:oid:2.16.840.1.113883.3.190</saml:AttributeValue> </saml:Attribute> Subject: Role Value Set HITSP/C80 v2.0 Jan 2010 - 2.2.3.15.6 Author Role - Table 2-154 Author Role Value Set 2.16.840.1.113883.3.18.6.1.15 (Author Role was replaced with Subject Role). The following table shows the ‘Roles’ currently supported by VHIE Health Exchange.

Table 41: Subject:Role Value Set

Clarification is needed for the role when using Patient Discovery. It is intended to be the user who initiated the patient discovery process and could be Administrative healthcare staff. That is the role VHIE Health Exchange uses when initiating Patient Discovery.

The Role used for Query for Document and Retrieve Documents in VHIE Health Exchange should be 112247003 Medical Doctor. However, there may be partners using other roles beside ‘Medical Doctor’. VHIE Health Exchange does not check the role of incoming PDs, or QDs or RDs. VHIE Health Exchange (and Partners) need to debate internally their policies as to what to authorize or not.

An example of the syntax of this element is as follows:

<saml2:Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role">

</saml2:Attribute>

Purpose of Use Value Set The value set for Purpose of Use currently supported by VHIE Health Exchange is listed in the following table.

Table 4-2: Purpose of Use Code Descriptions

An example of the syntax of this element is as follows:

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse"> <saml:AttributeValue> <PurposeForUse xmlns="urn:hl7-org:v3" xsi:type="CE" code="OPERATIONS" codeSystem="2.16.840.1.113883.3.18.7.1" codeSystemName="N HIN-purpose" displayName="Healthcare Operations"/> </saml:AttributeValue> </saml:Attribute>

Note that the Patient Discovery should be made based on purpose of use = TREATMENT ( Refer to NHIN Authorization Framework Production Specification v3.0).

VA outbound Patient Discovery are only ‘Treatment’ and ‘Emergency’, but inbound Patient Discovery can be ‘Treatment’ or ‘Coverage’ or ‘Emergency’.

Very Helpful Patient Discovery Request Parameters There is not a common set of demographics for exchange other than those in the specifications. Since the initiator does not know what the responder’s algorithm is they should send as many demographics as allowed in the specifications.

In particular, the Social Security Number (SSN) plays a critical role in the success of patient ID matching and SHOULD be included in the Request Parameters as well as the Response Parameters.

When specified within the request, the SSN is specified in a LivingSubjectId element – potentially one of several. When specified within the response, the SSN is specified as in an OtherIDs element. SSN is designated using the OID 2.16.840.1.113883.4.1.

VA requires that a LivingSubjectId field with the partner’s assigning authority and unique patient ID be present in the Patient Discovery message to VA. Without this, VA cannot create a correlation. Partner Document Queries undergo a policy check that requires VA’s identity management system have a correlation or the inbound Document Query will fail.

With SSN, VA can achieve over 80% matching success rate, whereas this success rate degrades down to 20% without it.

0.1.6 eHealth Exchange Specification: Query for Documents VHIE Health Exchange Partners will ignore date ranges in the Query for Documents requesting Health Summaries (HITSP C32s or C-CDA R1.1 CCDs). In both the HITSP C32 Content Module Specification and in the HL7 C-CCDA R1.1 Consolidated Health Story Specification, there is no clear guidance on how to apply date ranges to the clinical sections of the document. Each Exchange participant will determine the content limits for the clinical sections of the health summary document and shall make these content limits visible or known to the receiving organization when it is rendered – for example, by providing descriptive text in the section narrative block or by indicating date ranges in the section title (e.g.: Results: MM/DD/YYYY - MM/DD/YYY). As a result, a health summary is returned with the defined content limits of the responding organization without regard to the date range provided from the initiating organization.

However, VHIE Health Exchange Partners will honor/apply date ranges in the Query for Documents requesting clinical notes (HITSP C62s, C-CDA R1.1 Structured Note Documents, or C-CDA R1.1 Unstructured Note Documents). notes). In this case, clinical note documents are returned which do respect the date range provided the query from the initiating organization Further, in queries for clinical notes (HITSP C62s, C-CDA R1.1 Structured Note Documents, or C-CDA R1.1 Unstructured Note Documents), a partner has the option of returning the XDSTooManyResults error if the serviceStartTimeFrom and serviceStartTimeTo parameters indicate a wider time range than the partner is willing to support. When this error is returned, additional free text shall also be included in the error message to indicate the maximum time range supported by that partner. This text information must make sense to the remote user so they can modify their query to successfully get data back. The initiating partner should respond to the XDSTooManyResults error message by surfacing the error to the end user and should include the free text part of the message so that the user has some idea how to change their query to perform a Query for Documents without receiving this error. See the IHE technical framework revision 7, volume 3, section 4.1.13 ''Error Reporting'' for the structure of a registry error.

If a partner receives a request for a class code for which they either do not have any documents for the specified patient or they do not have internally mapped at all, that partner should simply return an empty list.

If a query is received without document code, then VHIE Health Exchange returns all document types it has about the patient.

The specifications miss specifying the need and how to populate this attribute: ‘XDSdocentrystatus’. It needs to be populated, describing the ‘statustype’ that is either ‘approved’ (approved for delivery) or ‘deferredcreation’ (on demand of the requestor – an attribute added by eHealth Exchange Specifications Factory beyond the IHE profile). An example of the syntax of this element is as follows:

Query for Documents Parameters Class Code VHIE Health Exchange supports the following Class Codes in Query for Document requests.

Table 43: VHIE Health Exchange Document Class Codes Currently Supported

When initiating a Query for Documents request for a Health Summary (HITSP C32 or C-CDA R1.1 CCD), the LOINC Class Code is 34133-9 –Summarization of Episode Note.

When initiating a Query for Documents request for a clinical note ( HITSP C62s, C-CDA R1.1 Structured Note Documents, or C-CDA R1.1 Unstructured Note Documents ), the functional areas listed below will be mapped to the indicated LOINC Class Codes:

Table 44: Functional Area / LOINC Class Codes Mapping

18761-7: Transfer Summarization Note

47046-8: Summarization of Death Note

34140-4 : Transfer of Care Referral Note

47039-3: Admission History and Physical Note

34121-4: Interventional Procedure Note

47045-0: Study Reports

26441-6: Cardiology Studies

26442-4: Obstetrical Studies

27895-2: Gastroenterology Endoscopy Studies

27896-0: Pulmonary Studies

27897-8: Neuromuscular Electrophysiology Studies

28619-5: Ophthalmology/Optometry

34806-0 Note (Oncology)

28634-4: Miscellaneous Studies

34122-2: Pathology Procedure Note

18725-2: Microbiology studies

26438-2: Cytology Studies

47526-9: Cytopathology Report

50668-3 Microscopic Observation

If multiple Class Codes are included, then all documents matching any of the codes should be returned. (i.e., OR semantics should be used when multiple Class Codes are included in the request).

ServiceStartTimeFrom / ServiceStartTimeTo and ServiceStopTimeFrom / ServiceStopTimeTo It is strongly recommended that all queries for clinical notes ( HITSP C62s, C-CDA R1.1 Structured Note Documents, or C-CDA R1.1 Unstructured Note Documents )include one or more of the service Start/Stop From/To parameters to keep searches for data in source systems targeted at specific data sets rather than just “asking for everything”. Responding systems have the option of responding with a “XDSTooManyResults” error if the time range indicated by these parameters is considered to be “too broad”.

For Unstructured Document exchanges, these parameters MAY be provided in the Query for Documents by the Initiating Gateway and MUST be used if provided to filter and search for matching notes to share back in the response from the Responding Gateway.

DocumentEntryStatus Document entry status means different things depending on whether the document is already created or assumes deferred creation. The example below shows either.

The Initiating Gateway shall accept a Document Entry without size, hash, creationTime values when availabilityStatus=”DeferredCreation”. The Initiating Gateway may retrieve the referenced document via a normal XCA Cross Gateway Retrieve.

VHIE partners MUST include one or more DocumentEntryStatuses in a Document Query Request to indicate that they are requesting a filtering (narrowing) of the results to a particular set of DocumentEntryStatuses.

Responding VHIE partners MUST filter their results based upon the DocumentEntryStatus. It is recommended that partners always include both “urn:ihe:iti:2010:StatusType:DeferredCreation” and “urn:oasis:names:tc:ebxmlregrep:StatusType:Approved” statuses so that both existing and “generate on demand” documents will be included in the response.

Format Code Note that for the Format Code parameter, responding Gateways must minimally honor a request to filter out document formats that do not match what was requested even if they do not have the capability to search internally within their communities using these fields.

The VHIE Health Exchange supported value set is listed in the following table.

Table 45: The FormatCode Value Set Supported by VHIE Health Exchange

(Per HealtheWay Exchange Specifications Wiki Q&A:

http://exchange-specifications.wikispaces.com/share/view/66990226) JohnMoehrke Apr 17, 2014:

This is work that is still ongoing.

Keith tells me that the current proposed formatCode is urn:hl7-org:sdwg:CCDA:1.1

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

MS Word embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

RTF embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

HTML embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

GIF Image embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

TIF Image embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

JPEG Image embedded in CDA

Until Further Defined***:

urn:hl7-org:sdwg:ccda-nonXMLBody:1.1 New With C-CDA R1.1:

PNG Image embedded in CDA

***Note for Format Concept Code - Per HealtheWay Exchange Specifications Wiki Q&A(http://exchange-specifications.wikispaces.com/share/view/76205747) Outdated Query for Document Specifications Pertaining to CCDA formatCodes Nov 11, 2015:

“Both versions of the Query for Document Web Service Interface Specifications (2011 and 2010) refer to HITSP/C80 in regards to the usage of formatCodes (as well as other items). An issue exists since the inception of the CCDA Implementation Guides and updated versions of the IHE PCC TF-2 specifications. As implementers chose to create and send CCDA Release 1.1 (and the upcoming Release 2.1/2.0) documents, an uncertainty exists in regards to which formatCode to use in the Query for Document response transaction. Implementers may stress staying compliant to the eHealth Exchange specifications (2011 and 2010), and choose to use the HL7 CCD formatCode of urn:ihe:pcc:xphr:2007 when sending CCDA R1.1 documents. However, the usage of the HL7 CCD formatCode for CCDA R1.1 documents is misleading to the receiver of that document. The correct formatCode to use when sending CCDA R1.1 documents is urn:hl7-org:sdwg:ccda-structuredBody:1.1, which is documented in the IHE PCC TF-2 Revision 10. The latest version of the IHE PCC TF-2 specifications will be published relatively soon, and will most likely contain formatCodes for CCDA R2.1/2.0 documents. Clinical document content guides are progressing forward, but the transactional guides are not. When will the Query for Document Web Service Interface Specifications be updated to make reference to the latest available version of the IHE PCC TF-2 specifications so that implementers can feel more comfortable in using the CCDA specific formatCodes so that they are compliant to over-arching eHealth Exchange specifications? If these documents are not updated, then the sender and receiver of CCDA documents will have to make separate agreements about the usage of CCDA specific formatCodes.”

A Responding Gateway should include HealthSummary(s) formatted as HITSP C32 or C-CDA R1.1 CCD if a Class Code = 34133-9 is included in the Class Code parameter and the FormatCode parameter is:

· blank OR

· contains the value of “urn:ihe:pcc:xphr:2007” (for HISTP C32) OR

· contains the value urn:hl7-org:sdwg:CCDA:1.1 (for C-CDA R1.1 CCD).

· Note: These FormatCodes indicate that the requested and returned Health Summary Document has a CDA Header and Structured Data (i.e: a body with templated sections). However, it is t possible that a partner may at some point have Health Summary document that have been scanned in from paper and could then be shared as Unstructured Documents (HITSP C62 or C-CDA R1.1 Unstructured Document) rather than in HITSP C32 or C-CDA R1.1 CCD format. In this case, the expected FormatCodes would be:

· urn:ihe:iti:xds-sd:pdf:2008: For a HITSP C62 with an embedded scanned pdf of the health summary

· urn:hl7-org:sdwg:ccda-nonXMLBody:1.1: For a C-CDA R1.1 Unstructured Document with an embedded scanned version of the health summary document The Document Format is an optional parameter in Query for Document requests, but filtering based on this parameter is required on the part of the Responding Gateway.

VHIE Health Exchange partners MAY include one or more Format Codes in a Document Query Request to indicate that they are requesting a filtering (narrowing) of the results to a particular set of Format Codes.

Author Specialty Code (optional) While an author’s specialty can be pre-coordinated into a LOINC code, the standards community at large has been taking the general approach of using only the high-level LOINC-based “Class Codes” to designate the class of document and encoding any specialty information with a separate “authorSpecialty” code (SNOMED-CT based C80 “Clinical Specialty” codes; Table 2-149).

The VHIE partners recommend following this approach of using the authorSpecialty code to represent the author’s specialty in the Document Query and Document Query Response transactions.

VHIE partners MAY include an authorSpecialty code in a Query for Documents to indicate that they are requesting a filtering (narrowing) of the results to a particular specialty.

Responding VHIE partners are NOT required at this time to filter their results based upon an authorSpecialty code (i.e. the authorSpecialty code may be ignored- in such a case an unfiltered list of documents corresponding to the rest of the query parameters [e.g. class code and date range] will be returned)

0.1.7 eHealth Exchange Specifications: Retrieve Document Data Content for HISTP C62 Unstructured Document (UD) and C-CDA R1.1 Unstructured Document (aka: Clinical Note) Exchange VHIE partners will comply with all HITSP, IHE and HL7 specifications for Unstructured Documents (HITSP C62 or C-CDA R1.1 Unstructured Document) Data Content will be handled with the “Virtually Scanned Documents” context, as described in XDS-SD”:

· “Virtually Scanned”**electronic documents are existing electronic documents not derived from legacy paper or film that either are PDF/A or plaintext format or have been converted to one of these formats for the purposes of sharing.

**Note: Since C-CDA R1.1 expands the types of embedded text and graphic formats, the “Virtually Scanned” scenario is assumed to extend to those formats as well.

The HITSP C62/C-CDA R1.1 UD Data Enterer in our “virtually scanned” scenario is software, not a person. Only the Template ID, Enterer Time and the ID are required for the dataEnterer element (a person’s name is not required). Thus, the following implementation is recommended in “virtually scanned” situations:

· Set the dataEnterer/time to the date/time the document was created by the software

· Set dataEnterer/id to an identifier representing the software

· Do not include the assignedPerson element (including the name subelement), as these are optional and not relevant in the “virtually scanned” scenario

The ClinicalDocument/component/nonXMLBody/text element contains the base64 encoded content for the Unstructured Document.

· For HITSP C62:

· The “mediaType” attribute of this “text” element MUST contain one of the following values depending on whether the content is formatted as plain text or PDF/A: “plain/text” or “application/pdf”.

· The “representation” attribute of this “text” element MUST be set to “B64” to indicate base64 encoding.

· The “compression” attribute will not be used so no compression of the content will be supported for VHIE Health Exchange.

· For C-CDA R1.1 UD:

· The “mediaType” attribute of this “text” element MUST contain one of the following values defined in Table 43 of the HL7 C-CDA R1.1 Specification (see below):

Table 43: Supported File Formats Value Set (Unstructured Documents)

· The “representation” attribute of this “text” element MUST be set to “B64” to indicate base64 encoding.

· The “compression” attribute will not be used so no compression of the content will be supported for VHIE Health Exchange.

0.1.8 eHealth Exchange Specifications: Patient Discovery Initiating and Responding to Patient Discovery The following table describes how VA initiates and responds to patient discovery requests.

Table 46: Patient Discovery Workflow for VA

1. Patient Discovery is initiated thru the VAP application by a VA staff member. Many are initiated at the time the VHIE Health Exchange authorization is obtained from the Veteran.

1. In 2016, Patient Discovery will be initiated through a nightly pre-fetch process as well as from the VistA Web clinician user interface.

1. VHIE Health Exchange partners will respond to these patient discoveries in real-time.

Note: from time to time, VA may initiate large batches of patient discoveries. These Patient Discovery queries will NOT be done out to all parties. VHIE Partners will be notified in advance.

Patient ID Matching Algorithms The following table defines the patient matching algorithms used by VA:

Table 47: VA Matching Algorithms

Matching Attributes The following table documents the traits VA sends when initiating or responding to patient discovery:

Table 48: VA Patient Discovery Traits

Traits VA Sends During Patient Discovery

Notes

1. Middle Name for VA.

2. Address = Street Address has 1, 2, 3 lines

3. Zip is a 9 digit code

4. State is the FIP code

5. M, F or Null

6. See eHealth Exchange Specifications on Patient Discovery parameters optionality

The following table documents the traits VA uses for matching:

Table 49: VA Patient Matching Traits Traits VA Uses for Patient Matching

x: Required y: Used if provided h: Highly Desired

Notes

1. If any primary identity fields are not provided, the partner will need to provide additional traits such as Address, Phone Number, MMN, POB City, and POB State to increase the probability of matching.

Additional Resources on Patient Matching For additional information regarding best practice patient matching principles related to eHealth Exchange, refer to the paper “A Framework for Cross-Organizational Patient Identity Matching” authored by The Sequoia Project, the Care Connectivity Consortium (CCC), and Intermountain Healthcare, at http://sequoiaproject.org/wp-content/uploads/2015/11/The-Sequoia-Project-Framework-for-Patient-Identity-Management.pdf.

This framework is focuses on improving accurate patient ID matching, especially across organizations. It contains 3 parts:

1. Intermountain Healthcare study showing strength of different traits (e.g., last name (5%), SSN (98%))

1. A patient matching maturity model

1. A list of minimally acceptable patient matching principles for organizations to adopt

VA Consent Models Before Veteran Health data can be shared with external partners, Veterans in the VA health system must authorize participation in VHIE Health Exchange. Participation in VHIE Health Exchange is optional, and Veterans can opt-out at any time.

In order to share patient data, VHIE partners may or may not require authorization or consent from their patients. The following table describes the VA requirements for patient authorization/consent to share data.

Table 410: VA Authorization/ConsentRequirements

After a Veteran completes an authorization form, the identity of the Veteran must be authenticated, and the authorization form must be validated and entered into the Veterans Authorization and Preference. This process is referred to as the “opt-in” process.

The Veteran authorization is required as per Title 38 USC 7332. It is valid for 5 years for treatment, payment, and health care operations purposes of use and 2 years for coverage purpose of use. ‘Payment’ is currently not a supported purpose of use.

Furthermore, VA policies have recently changed. Patient authorization status is now checked only for

· Inbound Query for Documents (i.e., requests by partners for VA records)

· Inbound Document Retrieve (i.e., requests by partners for VA data) Authorization checks for the following are not performed for the following:

· Inbound and Outbound Patient Discovery (i.e., exchange of demographic traits for patient ID matching)

· Outbound Query for Documents

· Outbound Document Retrieve

Non-Functional Requirements

0.1.9 Response Times

There are no VA response time requirements for VHIE Health Exchange. However, partners shall determine average response times for Patient Discovery, Query for Documents and Retrieve Documents transactions to support the development of baseline response times.

Also, the ‘pre-fetch’ strategy should improve response time to clinician end-users and therefore enhance adoption.

0.1.10 Gateway Port

When communicating with VA we support the “normative” eHealth Exchange ports, 443, 4437 or 14430, for test and production systems. Partners using port 4437 or 14430 will need to supply VA with their inbound IP address for whitelisting. Additionally, VA will need to know whenever that IP address changes so that the partner’s whitelist entry can be updated. If a partner’s IP address is not white listed or if it changes, VA outbound queries to the partner will cease functioning until the IP address can be added to the white list.

This is identified in the Nationwide Health Information Network Messaging Platform Specification v3.0 section 2.3 Operational Management.

0.1.11 URL/Endpoint Classification

VA uses BrightCloud (http://www.brightcloud.com/tools/url-ip-lookup.php) to determine what external URLs VA systems and users can connect to. If the partner’s endpoints or IP addresses for the endpoints are not categorized or are marked as suspect, then the VA firewall rule would block outbound queries to the partner. The partner can request that BrightCloud categorize or reconsider a classification or VA can make this request. In the past we have encountered URLs and IPs that are not categorized and others that were reused by a partner system but previously belonged to other parties and, as a result, had a bad categorization that blocked testing with the partner.

0.1.12 Encryption

FIPS 140-2 compliant encryption TLS version 1.0 is the required encryption method. Messages should be conveyed inside a 2-way-TLS channel, with fully mutual authentication of both end points, using a FBCA cross certified Managed CA. The messages themselves are plain text, but are cryptographically signed in the SOAP header. All messages are audit logged at both ends of the exchange.

Content…