Department of VA - Pre-Decisional - HIMSS18 · Department of Veterans Affairs (VA) FHIR Transition Plan (FTP) 2017 Department of VA - Pre-Decisional

Department of Veterans Affairs (VA)FHIR Transition Plan (FTP) 2017

Department of VA - Pre-Decisional

VA Enterprise Objective –Veteran-Centric Future State

Veteran Perspective: VA Clients can access and update their information at anytime, anywhere, through multiple channels, and they do not have to provide the same information more than once. VA Clients will obtain the same, consistent service regardless of the channel they use.

VA Perspective: Updates from VA Clients are made available in a timely manner to everyone in VA who requires them. Leadership and staff can obtain correct, consistent, and consumable information and answers to questions across the department.

Multiple Channels: Includes MobileDepartment of VA - Pre-Decisional 2

VA’s Challenges

• VA is faced with: Rapidly evolving technology Shifting social and demographic changes Tight fiscal constraints Pressure to rapidly adapt to changing business and technology factors.

• To maintain a modern IT environment and achieve a Veteran-Centric Future State, VA must continually reassess how to efficiently and effectively provide, sustain, and enhance IT services in support of Veterans.

Information Exchange Standards are a critical part of VA’sContinuous Reassessment

Department of VA - Pre-Decisional 3

VHA’s Mission & Vision –Continuous Improvement towards Veteran-Centric Future State

• MISSION: Honor America's Veterans by providing exceptional health care that improves their health and well-being.

• VISION: Be a benchmark of excellence and value in health care and benefits by providing exemplary services that are both patient centered and evidence based. This care will be delivered by engaged, collaborative teams in an integrated environment that supports learning, discovery and continuous improvement.

• VHA Strategic Planning Process: VA Directive 1075 identifies the following principles that are embodied in every VHA effort:1. Patient-centered2. Team-Based3. Data-Driven and Evidence-Based4. Prevention or Population Health5. Providing Value6. Continuously Improving. Driving Force behind

VA transition to FHIR


The VA Enterprise

Note I: The above figure is NotionalNote II: The above figure is Copyrighted by Microsoft Corp, 2003.


System 1 System 2

System 3

System 4System 5

System N

Each System has its own:

• Objectives/goals• Use Cases• Requirements• Technology Stack• Data Representation• Data Meaning• Funding Stream • Resources• Constraints• Leadership and Organization• Processes (way of doing things)• Customer Base.

The World that Currently Exists


Why HL7 Standards…Why FHIR?

The benefits of using HL7’s FHIR increase rapidlywith the number of systems involved.

Note: Example above taken from HL7 Material Department of VA - Pre-Decisional 7

• FHIR Combines features and lessons learned from HL7’s Version 2, Version 3 and CDA product lines.

• Designed to leverage the latest web standards to assist in broadening the scope of sharing healthcare data (i.e. mobile and cloud-based applications).

• Enhances the ability to attract technical talent and reduce healthcare-specific learning curves.

• FHIR solutions are built from a set of modular components called “Resources”. Resources: Are small logically discrete units of exchange Are “of interest” to healthcare and have defined behavior and meaning Have a known identity (a url) by which they can be addressed Identify itself as one of the “resource types” defined within the FHIR Specification Contain a set of structured data items as described by the definition of the “resource type” Contain a human-readable XHTML representation of its content Have an identified version that changes if the contents of the resource change.

Resources have multiple representations. A given representation is valid if it meets the above rules and is depicted in either XML or JSON as defined within the FHIR specification. Other representations are permitted, but are not explained by the FHIR Specification.

Official Link for FHIR Standard: http://www.hl7.org/implement/standards/fhir/

Why HL7 Standards…Why FHIR?


VA FHIR Transition Plan (FTP) 2017-Steps

How does VA transition from the existing world to a world of FHIR?

Start with the following foundation:

• Configuration Management (CM) and Change Control• FHIR Security• VA FHIR Leadership/Authority• Communications.


VA FTP – Step 1

Configuration Management (CM) &

Change Control


FHIR Alignment…is it Enough?

If all interfaces comply with the FHIR Standard, then how can “one-off” solutions still evolve and interoperability prevented?


• Purpose: FHIR’s Purpose is to enable the electronic exchange of healthcare information.

• Concept: FHIR, as the basis for information expression and sharing, promotes information

ubiquity, reducing integration cost and burden.

If all system interfaces comply with the main body of the FHIR standard, interoperability will be achieved; meaning, information will be:o Discoverableo Accessibleo Understandable.

11

Components that can cause “One-Off” Solutions

• Initial focus needs to be on the following components, which can cause the creation of “one-off-solutions”: Mappings: How data maps to the FHIR Specification. Extensions: Allows additional data elements that lie outside the core specification to

be implemented in FHIR. Profiles: Allows a user to author and publish a customized, more specific

resource definition by specifying a set of constraints and/or extensions on the base resource.

• Different implementations of the above components can be done for the same data, and all can be FHIR compliant.


If different implementations of mappings, extensions, and profiles are done for the same data, data loss can occur and interoperability negatively

impacted.

12

VA needs to establish a CM / Change Control Process that:

• Is Simple: Easy to understand and follow across the Enterprise.

• Impartial: Independent of system functions and equipment that employ FHIR.

• Pro Development without Excessive Oversight: Focuses on business needs while allowing for community self-governance.

• Identifies VA Use Cases / Requirements: Encourages VA programs/projects to come to the table with use cases/requirements that are not met by the FHIR Core. Provides support and traceability to VA business requirements.

• Supports FHIR Evolution: Places VA in a position where it can assist HL7 to further evolve the FHIR Core Standard.

Foundation of FHIR Interoperability –CM / Change Control over Mappings, Extensions & Profiles


Next – 2017


Officially establish the following for VA FHIR Component CM and Change Control:

• Change Control Board (CCB) Charter identifying purpose, operations, membership roles, responsibilities, and skill sets.

• FHIR Component Registry Enterprise registry with access for all authorized users.

• Change Control Request (CCR) Process and System Develop the details of the process and begin utilization Enterprise application with access for all authorized users CCR specific communication mechanism (i.e., email) to inform community of CCRs and results.

• FHIR Component Development Guidance and Criteria Guidelines, templates, and tools for development Used during reviews to accept or reject requests for development.

• Verification & Validation Testing and Approval Process Designated Testing Entities and Operations Testing Tools / Environment.

14

VA FTP – Step 2

FHIR Security


FHIR Security


• FHIR – Is not a Security Protocol.

• FHIR – Does not define any security related functionality.

• FHIR – Needs additional security layered beneath it for appropriate secure implementations.

• Combination of the following constitutes a safe and appropriate set of standards to serve as building blocks for healthcare applications: FHIR Healthcare Content OpenID Connect Authentication OAuth2 Authorization RESTful transport (HTTPS – also called HTTP over TLS).

16

Security Standards Required for FHIR Implementation

Note: Each standard has dependencies on those that lie directly beneath it.

JOSE: JSON Object Signature & Encryption JWA: JSON Web Algorithms JWK: JSON Web Key JWT: JSON Web Tokens

JSON: JavaScript Object Notation JWE: JSON Web Encryption JWS: JSON Web Signature TLS: Transport Layer Security


UMA (User-Managed Access)

OpenID Connect (Identity Federation)

OAuth2 (Authorization) JWT (Secure Tokens)

TLS (Secure Transport)

JOSE(Data Signature & Encryption)

JWK JWS JWE JWA

17

• Security, Privacy & Patient Consent: Identify all current Federal and VA Policies and Industry Guidance (i.e., NIST) that will impact the use of FHIR in VA.

• Implementation Guidance: Develop guidance that translates each identified policy into implementation steps for using FHIR in a secure fashion and compliant with security protocols. This includes, but is not limited to:

Identifying where each of the following applies and how: Security Labeling UMA (User Managed Access) OPENID Connect (Federated Authentication) OAUTH (Authorization) TLS (Secure Transport) Security recommendations under the FHIR US Core.

Specifying the use and role of appropriate FHIR Resources.

Prototyping, Testing, and Validating the guidance.

Obtaining official VA sign-off of guidance and mandating its use.

• VA Identity & Access Management (IAM): Work with current VA IAM systems to evaluate their role and responsibilities in supporting authentication and authorization when accessing VA FHIR APIs.

Next – 2017


VA FTP – Step 3

VA FHIR Management & Governance


VA FHIR Community / Ecosystem

Establish VA FHIR Community/Ecosystem that:

• Serves as an advocate and liaison between VA and HL7 FHIR communities • Makes formal decisions for the Enterprise on FHIR• Defines business rules, constraints, and requirements • Develops FHIR guidance, mandates, and policies for implementation• Assigns FHIR related tasking.

Provide Oversight and Guidance necessary to ensure a successful transition.


Current State –The VA FHIR Transition Working Group (FTWG)

Current Purpose:• Key vehicle for collaboration on the FHIR Standard across the VA• Principal oversight body for VA’s transition to FHIR• Ensures proper follow-on management and sustainment by appropriate VA organizations.

Current Membership: Includes “participation by” and “coordination between” VA’s Program/Project Leaders, Business Stakeholders, and Technology Stakeholders.

All VA FTWG members are responsible for communicating:

• Their organization’s perspective, efforts and issues on FHIR to the VA FTWG.

• All points and decisions made by the VA FTWG back to their respective organization to ensure agreement and compliance.

Chair: The VA FTWG will be a co-chaired body; having both a business and technical co-chair.


Recommended Future State –Evolving the VA FTWG into a VA FHIR Community / Ecosystem

Department of VA - Pre-Decisional22

VA FTP – Step 4

Socialization / Communication


Next – 2017


Establish VA Internal Website Focused on FHIR:

• VA FHIR Time-lines, Announcements, and Decisions• Mandates and Policy Announcements• Guidance for Development, CM and Change Control, and Testing• Links to tools and environments• Announcements for Change Control Request Status • HL7 and FHIR Evolution Announcements• Balloting Announcements, Schedule, and Links to Process• Inventory of current VA FHIR Efforts and APIs, with corresponding point of contacts.

Rene’ KinseyEmail: [email protected] of Veterans Affairs (VA) Office of Information and Technology (OI&T) Enterprise Program Management Office (EPMO)Health Products Interoperability Team

Point of Contact

25

BACK-UP


Example High-Level CM Processfor

FHIR Mappings, Extensions, and Profiles


Search Repository to see if

FHIR Component exists

Does component Meet all

Program/ProjectRequirements?

Does FHIR Component

Exist?

No

Yes

No Submit request to Pursue development of

component

Yes

Register & Use for Program/Project

FHIR API

Does component Meet partial

Program/ProjectRequirements?

No

Analyze component to see if it meets Program/ProjectRequirements

Yes

Submit requestTo modify current

Component

FHIR ComponentChange Control

Board(CCB)

FHIR Component Reuse & Development Request

FHIR Component: Mappings, Profiles, or Extensions Department of VA - Pre-Decisional28

FHIR ComponentCCB Review

Modification DevelopmentApproved?

No

Yes

Request Rejected.Reason for Rejection

& Alternative Solution

Provided

Testing Past?

Development

Approval &Submission into

Official VA FHIR Component

Registry

NewDevelopmentApproved?

No

Yes

Submit for Validation /

Verification Testing

No

Yes

FHIR Component Review, Development, Testing & Approval


FHIR Component: Mappings, Profiles, or Extensions

FHIR Evolution

Approval &

Submission intoOfficial

VA FHIR Component Registry

Formal AnnouncementMade via VA FHIR

Communications

Submit Extensionsto

Official VA –HL7 FHIR

Working GroupMembers

Present to HL7 FHIR Working

GroupsFor Possible

Inclusion into FHIR Core

Included in FHIR

CORE?

Official VA Notice to upgrade

APIs to New FHIR Version.

Release of Development &

TestingGuidance

Formal AnnouncementMade via VA FHIR

Communications

Update VA FHIRComponent

Registry& all

Verification & ValidationTesting Tools & environments.

No change.

Continue ExtensionUse and Support.

No

Yes


FHIR Component: Mappings, Profiles, or Extensions

Security Standards Required for FHIR Implementation


Open Security Standards for FHIR Interfaces

Standard DescriptionTransport Layer Security (TLS) TLS is an Internet Engineering Task Force (IETF) standard for securing a communications channel between a client and a

server, providing transport-layer encryption, integrity protection, and authentication of the server using X.509 certificates (with optional client authentication). TLS provides transport-layer encryption, integrity protection, and authentication. Many application protocols can be sent over a TLS-secured channel, including HTTP in the form of HTTP Secure (HTTPS). TLS 1.2 is the most recent version of the protocol, but use of it is not yet ubiquitous, with many software packages supporting only TLS versions 1.1 and below.

OAuth 2.0 IETF standard for an authorization framework whereby resource owners can authorize delegated access by third-party clients to protected resources; OAuth enables access delegation without sharing resource owner credentials, with optional limits to the scope and duration of access. OAuth also provides the basis for other useful protocols serving different but related purposes, including OpenID Connect and User-Managed Access (UMA).

JavaScript Object Notation (JSON) Ecma standard text format for structured data interchange – not a security standard, but a key component of several standards listed within this table.

JSON Web Signature (JWS) Draft IETF standard for attaching digital signatures or Message Authentication Codes (MAC) to JSON objects

JSON Web Encryption (JWE) Draft IETF standard for encrypted JSON objects

JSON Web Keys (JWK) Draft IETF standard for representing public and private keys (or sets of keys) as JSON objects

JSON Web Algorithms (JWA) Specifies cryptographic algorithms to be used in the other JOSE standards

JavaScript Object Signing and Encryption (JOSE) Collective name for the set of JSON-based cryptographic standards (JWS, JWE, JWK, and JWA)

JSON Web Token (JWT) Draft IETF standard for conveying a set of claims between two parties in a JSON object, with optional signature and encryption provided by the JOSE standards

OpenID Connect 1.0 OpenID Foundation standard for identity federation based on OAuth 2.0, using JWT to convey signed and optionally encrypted identity claims

User-Managed Access (UMA) Draft IETF standard for an OAuth 2.0-based access management protocol enabling resource owners to create access policies authorizing requesting parties to access their resources through OAuth clients

[1] ECMA was originally an acronym standing for the European Computer Manufacturers Association, but the organization changed its name in 1994 to Ecma International to reflect its global focus.Department of VA - Pre-Decisional 32

Interoperability Metrics to Manage Your Health Information Exchange (HIE) Growth:

The Department of Veterans Affairs (VA) Experience

Omar Bouhaddou, PhD, Nelson Hsing, ScD, Nitin Jain, MBA, MS, Margaret Donahue, MD present:

Slide title

2

VistA*: A Critical VA System

LEGEND

Phase 1

Phase 2

Phase 3

Phase 5

Phase 4

Phase 6

3

CPRS* – Clinician Interface to VistA

* Computerized Patient Record System (CPRS) 4

VHIE* Partners

Community Care Partners 88

Hospitals 815

Clinics 14,153

FQHCs 438

Labs 450

Pharmacies 8,487

Nursing Homes 150

OtherAncillarySites 652

Total Unique Veteran Patients Available for

Exchange with VA

914,166*

ProductionPartners TestingPartners FY17PrioritizedPartners VAMedical Centers

Visit “VLER Health Exchange in your Area” (http://www.va.gov/VLER/vler‐health‐your‐area.asp) to view our Exchange Community Health Partners.*VHIE = Veterans Health Information Exchange

5

Human readable

Computable

VA C-CDA

6

7

Managing Health Information Exchange

Management thinker Peter Drucker is often quoted as saying that "you can't manage what you can't measure." Drucker means that you can't know whether or not you are successful unless success is defined and tracked.

8

VHIE Analytics

Data Quality Metrics

System Performance Metrics

eHealth Exchange Operations

Performance Metrics

Direct Operations Performance Metrics

Business Outcome Metrics(Administrative, Financial,

Clinical)

‐ PD/QD/RD availability & success rates

‐ CONNECT Response time‐ Network Utilization & Time

Out

‐ #Inbound/Outbound messages (PD/QD/RD)

‐ #Veterans correlated‐ #Veterans consented

‐ Partner C‐CDA scores: completeness & quality

‐ #messages sent/received

‐ HISP level volume‐ #Partners in production

9

Operational Metrics

05000

1000015000200002500030000350004000045000

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

July2016

Aug2016

Sept2016

Oct2016

Nov2016

Dec2016

Inbound rolling 12 months

0

10000

20000

30000

40000

50000

60000

70000

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

July2016

Aug2016

Sept2016

Oct2016

Nov2016

Dec2016

Outbound rolling 12 months

0

10000

20000

30000

40000

50000

60000

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

July2016

Aug2016

Sept2016

Oct2016

Nov2016

Dec2016

Veterans Correlated rolling 12 months

0

5000

10000

15000

20000

25000

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

July2016

Aug2016

Sept2016

Oct2016

Nov2016

Dec2016

Veterans Authorized rolling 12 months

System Performance

90.00%

95.00%

100.00%

01 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31

VHIE RD Service Success Rate

% RD Response success rate SLA success rate

0 1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930Days of the Month

Response Efficiency for 3 Service Types over 30 Days

PD

QD

RD

10

Data Quality

Data Quality Surveillance

11

0%20%40%60%80%100%

Quality by

Total

Sections

Quality by Sections

Based on analyses of C32 real patient data from VLER Health Exchange Partners

11

Outcome MetricsDo Partner’s Allergy Information Agreewith VA Records?

58%

5%

95%

43% 38%

0%

20%

40%

60%

80%

100%

VA Partner Shared

Percentage of Allergies Known to Providers

Unique total

• VA and Partners agree on 38% of allergies• 58% of allergies known only to VA• 5% of allergies are known only to Partners

VHIE use by VA provider is associated with a 800% increase in allergy documentation

76%

1%

23%

Veterans

Visited VAafterWalgreens

Visited VAbefore, notafter

Increase in Immunization Rates

12

Why HIE Metrics Are Important?• Operational metrics

– Partner onboarding requires careful evaluation of shared patients, technological readiness, data quality to optimize value and cost of connecting. The network transactions must eventually demonstrate that HIE supports all care coordination uses cases for all patients.

• System metrics– Monitoring up/down status of partners and response time, failed transactions has helped

identify multiple technical bottlenecks. More SLAs are needed across the network. • Data quality index

– Data quality surveillance continuously monitors data richness, quality and fitness for use, which in turn promotes adoption and patient benefits.

• Outcome metrics– A better history of all encounters from all sources with relevant information drive HIE usage

and must eventually translate into clinical, administrative and financial value for stakeholders.

13

Conclusion

• You can’t manage and improve what you can’t measure.• Establish a set of operational metrics and an analytics

dashboard to monitor the health of your HIE. • Participate in industry efforts to help standardize

interoperability metrics.

14

Q & A

Contact us: [email protected] Visit us: www.va.gov/vler

15

Complexity is the Enemy of InteroperabilityIgniting Interoperability with HL7® FHIR®

60 Second History Lesson:

Longitudinal Electronic Health

Record

Overseas Battlefields Back HomeBootcamp

The Interoperability Challenge

Legacy Viewer SustainmentA little over a year ago, VA clinicians asked OI&T to maintain legacy system access to DoD data until CPRS and VistaWeb were replaced

• But legacy data sharing mechanisms needed to be updated in less than 12 months to:

– Align with target architectures

– Use the agreed upon patient identifier, called an EDIPI (Electronic Data Interchange Personal Identifier), across the interagency boundary

– Use modern standards

– All while supporting the thousands of queries per hour that were and are occurring in production

Solution Was Not Just Technical• Clinical - VHA project to provide

functional evaluation of replacement• Communication - Excellent

collaboration with other data sharing initiatives

– MVI Team– JLV Team– DMIX / DES Team– DAS Team

• Process - Dark launch of replacement to enable production side by side comparisons

Current Solution in ProductionAn HL7® FHIR® service was developed to obtain the patient’s EDIPI and collect the DoD data through the DES (DMIX Exchange Service). Legacy VistA DoD data collector was converted into a FHIR® client to complete the integration.• Use of the FHIR® standard loosely couples the DoD data

service to VistA - makes the service reusuable (e.g. the mobile app)

• Use of the FHIR® standard loosely couples VistA to the DoD data service – makes the client resuable as well (e.g. the Cerner data in VistA)

• Service was a drop in replacement for legacy data sharing and has been hit thousands of times per hour since deployment

Quantifiable Results Using FHIR®• Over 3 million queries from production VA VistA systems

since last summer’s initial release

• From over 600 unique VA facility identifiers representing individual VA hospitals, clinics, and other facilities

• By over 150,000 unique clinical and administrative users

• Over 60 million records exchanged since August of 2016

• Average individual query processing time of 7s

CPRS

Web Browser

VistaWebServer

Master Veteran Index

(MVI)

DES

LVS HL7® FHIR ®

Station 200

VistA

AHLTA CDR

TMDS

DHMSMGenesis

DoD Military Treatment FacilitiesSHARE / CHCS / Essentris

DAS

VAClinicians

VistA

Station 200 LVS HL7® FHIR ®

VistAWebServer

Web Browser

CPRS

VA Clinicians

Master Veteran Index (MVI)

LVS HL7® FHIR ®

DAS

DES


AHLTA CDR

TMDS

DHMSMGenesis

LVS HL7® FHIR ®


AHLTA CDR

TMDS

DHMSMGenesis

DES

DAS

DES


AHLTA CDR

TMDS

DHMSMGenesis

LVS HL7® FHIR ®

LVS HL7® FHIR ®

All DoD Data is Converted to Standard FHIR Resources

VA Clinicians

CPRS

Advantages of Using Published Standards: Service is Loosely Coupled to VistA

VA’s FHIR Implementation is Ready for Reuse – Today!

Advantages of Using Publishe Standards: Client is Loosely Coupled to DoD

We Appreciate Your Attention.Come to the FHA Interoperability

Showcase Demonstration Area for More Detail

We Appreciate Your Attention.Come to the FHA Interoperability

Showcase Demonstration Area for More Detail

Documents

Department of VA - Pre-Decisional - HIMSS18 · Department of Veterans Affairs (VA) FHIR Transition Plan (FTP) 2017 Department of VA - Pre-Decisional