Clinical, Technical, Organizational and Financial Barriers to

Interoperability Task Force: Collation of previous findings and recommendations presented to HITPC and recent Congressional

HIT Hearings

July 23, 2015

Summary of Interoperability Related Hearing Findings

• Payment reform is driving a business need for interoperability but additional work is needed to further align incentives and ensure the health IT functional needs of providers to achieve payment reform goals are enabled– Smaller organizations are facing challenges in meeting the IT investments and administrative

burden associated with value- based payment models– Providers under accountable care arrangements face barriers to obtaining critical information

around behavioral health and other sensitive information to inform care– There are many advanced health model use cases that require only limited information about an

individual, not the complete record; stakeholders need tools that allow them to filter information so that only actionable information is transmitted, to avoid overwhelming the data recipient and to avoid unnecessary privacy risks

– Lack of clarity around privacy and security issues raised by sharing information with non-HIPAA covered community-based organizations impedes data sharing and raises concerns about adequate protection of PHI

• Data and health IT tools need to fit in provider workflows– Implementing the electronic sending and receiving of information is requiring significant workflow

retraining and in some instance development of entirely new workflows for providers. – Provider organization need to work through how to best integrate transition of care documents

into their existing care referral processes to limit the sending of redundant data.

2

Summary of Interoperability Related Hearing Findings

• Standards and technical architecture alone will not enable seamless interoperability the policy, business and legal aspects of interoperability also need to be addressed in tandem– Payment incentives for interoperability need to be aligned to promote

exchange– Exchanging data requires coordination and trust across a variety of players in

the healthcare ecosystem. The healthcare ecosystem is at an early stage of implementing ToC and VDT and is still working through some maturity issues

– Providers are finding it difficult to find trading partners ready to accept transitions of care

– Certification does not adequately cover interoperability – Patient matching continues to be a challenge for the industry

• To achieve payment reform goals the circle of interoperability needs to be widened to include providers not eligible for MU (e.g. LTPAC and behavioral health)

3

Mapping Approved HITPC Recommendations to Congressional Requested Topic Areas

Technical Operational Financial Certification Other (not included in

Congressional request)

HIE RFI X X X X

Query & Response

X – privacy and security

Certification X

LTPAC/BH Cert

X X

ACO HIT Capabilities

X X X X

Jason Task Force

X X X X

4

HITPC Interoperability Related Hearing Findings Since 2013

5

Hearing Findings

• Eight interoperability related hearings have been held since 2013 by the HITPC. The findings identified by the lead Workgroup for each hearing are outlined in the following slides.

– Joint HITPC/HITSC Health Information Exchange Hearing – January 2013 – Non-Targeted Query Hearing – July 2013– Accountable Care Workgroup Hearing – December 2013– Information Exchange Workgroup ToC/VDT Listening Sessions – February 2014

• Vendor Listening Session• Provider Listening Session

– Certification Hearing – May 2014– Meaningful Use Workgroup MU Listening Sessions – May 2014

• Day 1• Day 2

– Jason Task Force Listening Sessions – July/August 2014• Day 1• Day 2

– Privacy and Security Workgroup Big Data Hearing – December 2014• Day 1• Day 2

– Advanced Health Models Hearing – June 20156

Findings: Joint HITPC/HITSC HIE HearingJanuary 2013

• Significant exchange is occurring today• Shift from HIE 1.0 to 2.0• Payment reform is driving business needs for exchange• Business drivers should select the technology not the other way around• Data needs to be integrated into the providers workflow• We are on the right path to accelerate interoperability and exchange,

however work remains• Cross vendor exchange is a must in 2013• LTPAC and mental health providers need to be part of exchange• Meaningful use has created a tipping point for patient engagement. ONC

should keep its foot on the gas pedal

7

Findings: Non-Targeted Query Hearing (1 of 2)July 2013

• Access to each network is controlled to members who have executed some sort of participation agreement (binding them to abide by any query limitations or other network policies). These agreements are executed with the data holders and, in some instances, with the EHR vendors.

• Each network provides patients with some choice; most are opt-out but some are opt-in. Many adopt a model where the data is held by the network but is accessible only for those patients who have either opted-in or have not opted out. One network testified that data does not move into the HIE without opt-in consent.

• For sensitive data, most depend on the data partner to withhold data requiring additional consent, or other types of sensitive data. One network made Part 2 (substance abuse treatment data) available in the HIE (but only to providers who specifically request it, subject to a second consent from the patient, and subject to a second attestation of a treatment relationship; also reminder provided about re-disclosure limits). In many networks, patients who have concerns about access to sensitive data in the HIE are counseled to opt-out (or not to opt-in).  

8

Findings: Non-Targeted Query Hearing (2 of 2) July 2013

• Many of the networks do have role-based access levels for participants. • All networks do audits of access/disclosures, but only some make directly available to

patients.• None do an override of patient consent - some have emergency break the glass in

circumstances where patient has not yet provided any form of consent.• All networks limit access to certain purposes -- treatment is common to all; many

others also allow for operations and public health reporting purposes; a couple allow for payor/payment access.

• Most have some either inherent or express geographic limits. There is the possibility to do nationwide health information exchange, but right now, only exists for limited data sets.

• Testifiers expressed some concern about having federal policy potentially disrupting the arrangements they had carefully implemented; however, most expressed a desire for some guidance/common agreement terms that would help facilitate network to network (or HIE to HIE) exchange, and additional guidance on how to handle sensitive data.

9

Findings: Accountable Care Workgroup Hearing (1 of 2) December 2013

• Data integration across EHR systems and with population health platforms is a major challenge for providers collaborating under accountable care arrangements.

• Technical, strategic, and financial considerations continue to inhibit providers from exchanging information to support care coordination.

• While providers in accountable care arrangements are acutely experiencing these challenges today, they do not have the leverage to drive solutions alone.

• HIEs are facilitating exchange for accountable care in select markets, but sustainability and spread are still a major concern.

• There is lack of clarity and consensus around the key quality measures that are needed to effectively drive care improvement within ACOs.

10

Findings: Accountable Care Workgroup Hearing (2 of 2) December 2013

• While some providers are using Meaningful Use requirements as a platform for care transformation, many are still focused on simple reporting compliance.

• ACOs need to do more to prioritize a patient-centered approach to care.

• Smaller organizations are facing challenges in meeting the IT investments and administrative burden associated with value- based payment models.

• Providers under accountable care arrangements face barriers to obtaining critical information around behavioral health and other sensitive information to inform care.

11

Findings: Information Exchange Workgroup Hearing (1 of 6) February 2014

Overview• The vendor and provider panels both identified two main challenges to

meeting the TOC/VDT requirements:– Ecosystem Maturity: Exchanging data requires coordination and trust across a

variety of players in the healthcare ecosystem. The healthcare ecosystem is at an early stage of implementing ToC and VDT and is still working through some maturity issues.

– Workflow: Implementing the electronic sending and receiving of information is requiring significant workflow retraining and in some instances development of entirely new workflows for providers.

• Technology did not come through as a major issue in meeting the ToC/VDT requirements for those who have implemented 2014 CEHRT.

• The combination of items heard during the listening session could impact the ability of some providers to attest for Stage 2 this reporting period.

12

ToC Findings: Information Exchange Workgroup Hearing (2 of 6) February 2014

• Difficulty Finding Trading Partners for ToC– Providers are worried that they won’t have sufficient trading partners

ready in time to meet the 10% electronic requirement.– Some providers in particular face unique challenges

• For some rural providers their only trading partners in the community are non-MU eligible providers.

• Health systems with closed environments that are primarily served by a single EHR instance are relying on transitions to LTPAC providers

– Providers are actively working with their referral partners to address this through outreach and education. • Some providers and their vendors are actively recruiting their customers’ referral

partners into their HISP to make them Direct-accessible.• Some providers are even purchasing Direct end-points for their non-MU eligible

trading partners to help meet the measure.

– Challenges identifying whether their trading partner has a Direct address, and if so, finding the provider’s electronic address information.

13

ToC Findings: Information Exchange Workgroup Hearing (3 of 6) February 2014

• HISP-to-HISP Interoperability– A variety of panelists discussed HISP-to-HISP exchange. A number referenced

participation in DirectTrust or establishing one-off contracts as their approach to enabling exchange across disparate HISPs.

– Lack of common widely deployed provider directory standards or common directory infrastructure makes it difficult to find addressing information on providers participating in disparate HISPs. • Providers who practice at multiple organizations are receiving different Direct addresses at each

organization often from different HISPs. This also creates challenges in identifying the appropriate Direct address of a provider to send the ToC information to.

• During the listening sessions we heard confusion over what counts as a valid transition of care for measurement– How do I know a provider really received the message (e.g., does the Direct MDN

meet this requirement)?– How do I know the content of the message meets all the requirements? (e.g., is

historical data an issue if it’s not mapped to SNOMED?)– Does a referral within my health system count towards the denominator?

14

ToC Findings: Information Exchange Workgroup Hearing (4 of 6) February 2014

• Workflow retraining was raised as one of the most significant items in implementing ToC– Panelists shared a wide range of timelines, from 30 days-6 months, to rework existing workflows.– For some providers this is a completely new workflow; for others it requires reworking a paper

workflow and addressing new components such as the electronic sending, receiving, routing and incorporation of data.

– Ensuring implementation of ToC aligns with other programs requirements (for instance PCMH or accountable care).

– Provider organization need to work through how to best integrate the ToC documents into their existing care referral processes to limit the sending of redundant data.

• Differing workflows are being implemented to receive care summaries and route them to the appropriate party– Providers are having to develop new workflows to receive and manage inbound electronic care

summaries.• Some panelists stated that their organizations are creating central facility inboxes managed by

the HIM department which receive the messages and then route to the appropriate provider– Often times a transition of care is to an organization rather than a specific provider within the

organization. The organization then will decide which provider to route the patient/information to.

– How do providers ensure referral loops are closed and that messages are received and acted upon by the recipient? 15

VDT Findings: Information Exchange Workgroup Hearing (5 of 6) February 2014

• View and download seem to be well understood and implemented by providers and vendors. The transmit requirement posed the biggest challenge.

• Overall, panelists thought the VDT measure would not present a significant challenge for providers because patients are using view and download and there is little demand to transmit to 3rd party applications at present.

• HISP-to-HISP Interoperability– No clear solution for how a patient can find a provider’s Direct address in the

marketplace. Some providers are asking their vendors to develop a directory to share addressing information with patients.

– If trust is not established between two HISPs a patient is not able to transmit their information to the desired endpoint. This is a concern many providers and vendors have and they anticipate it will be a challenge for patients looking to transmit their data. No real world examples of solutions to this issue were shared during the listening sessions. • Panelists expressed there was no clear nationally sanctioned approach to

address the trust issue.

16

VDT Findings: Information Exchange Workgroup Hearing (6 of 6) February 2014

• Use of the C-CDA as a single content standard has helped drive standardization and eased implementation of VDT. Some technical issues still arise between vendor implementations of C-CDA but they are being worked out through testing and actual use.

• Panelists shared that provider outreach to patients to inform them about the portal is a key step to meeting the 5% measure.

• Panelists had limited discussion of workflow issues. The main items raised were training for providers on how to educate/engage patients and developing a workflow for receiving patient transmitted health data.

17

Findings: Certification Hearing (1 of 5) May 2014

Overview• No disagreement about intent of MU objective• Insufficient time for product development and testing• Concerns about certification include:

– Specificity of certification criteria locking in vendor-created inefficient workflows for providers

– Incompletely tested and unstable testing tools delays certification and creates rework

– Inconsistent interpretations among ATLs, ACBs, and auditors– Certification does not guarantee integrated product or interoperability – No clearinghouse for timely feedback and response (need faster than

NPRM cycles)

• Time required for certification (or documenting certification) crowds out innovation

18

Detailed Findings: Certification Hearing (2 of 5) May 2014

Panel I: Providers• EHR products may meet certification criteria, but the way the functions are

implemented may disrupt workflow– Some functions fulfill the letter of the criteria, but not the intent (e.g., clinical summaries,

patient education)– Some functions are implemented as “check the box”

• May be easy for vendor, but creates burden for provider and less useful

• Providers feel constrained to use products as certified, with inefficient work flow– Vendors be given enough flexibility to meet the rules without being constrained to a

particular workflow

• Some certified products do not work, or do not work in all states• Certification does not adequately cover interoperability• Certification program should be less prescriptive; focus on what and less on how• More flexibility and time for implementation is needed• An ideal certification program would provide product comparisons in terms of

their functionality

19

Detailed Findings: Certification Hearing (3 of 5) May 2014

Panel II: Vendors• Complete set of requirements are not provided with adequate time for

development – Requirements change from what was originally defined in the

certification rule impacting quality and usability• Certification criteria for MU objectives, reports that measure these

objectives, and the clinical quality measures are not aligned with each other and are not necessarily aligned with clinical practice

• The testing tools and associated data are not properly tested before they are rolled out for use in the vendor community, and change

• Recommend that the complexity of the program be reduced and that a Kaizen process be used to support an effective review of the certification program

• Focus certification on critical few: interop, CQMs20

Detailed Findings: Certification Hearing (4 of 5) May 2014

Panel III: Certification/Accreditation Bodies• Pilot test new procedures and test tools prior to publication• Improve consistency between testing labs. Pilot tests should be a

venue for all ATLs and ACBs to observe testing to understand the expected results, learn how the test tools operate, and then provide feedback to ONC

• Testing tools need to be more automated to efficiently handle more test cases, reuse test data sets, and employ more robust types of testing methodologies including testing the security of products.

• Focus on certification criteria related to interoperability and security testing.

• How EHRs handle various functionality should be left to developers to innovate

21

Detailed Findings: Certification Hearing (5 of 5) May 2014

Panel IIII: Private Sector Representatives• Need additional up-front testing and quality assurance• Mid-cycle revisions are disruptive to the overall program• Need subject matter experts in program development• Enhanced collaboration between the private sector and the

federal government would help • Focus on critical few

22

Findings: Meaningful Use Workgroup Hearing (1 of 2) May 2014

• MU1 useful and not unduly burdensome; MU2 has been challenging• Scope and pace of change causes vendors and providers to focus on meeting the

letter of MU and less on the spirit of MU– Sometimes burden of documenting compliance (certification or MU measure) exceeds effort

of implementing functionality– Fear, due to audits, is often a factor in driving implementations

• Transition of care (ToC) is the most challenging– Requirements of effective ToC not well defined; wasn’t happening in paper world– Requires new workflow that takes time to implement efficiently and well– Difficult to identify electronic recipients ready to accept (synchronous with readiness to

transmit)– Need to exchange more useful information, not just more data– Direct not working well

• Proprietary business interests and legacy technologies are impeding exchange– Prioritize information exchange for care coordination and patient engagement– Key to exchange is in the local community– Need policies for exchange across state boundaries and patient matching

23

Findings: Meaningful Use Workgroup Hearing (2 of 2) May 2014

• Timelines are unaligned or misaligned (programs, EP vs EH, CQMs, standards)• Timing

– Late delivery of final rules and guidance has impeded delivery of certified products– Providers and vendors are overwhelmed by the current pace and scope– Need more time to prepare for stage 3 and learn from stage 2 (though one vendor

expressed the need to keep moving forward and not slow down) • Multiple patient portals fragments records and workflows for patients• Patients believe that EHRs are useful across the range of clinical and patient-facing

functions. However, patients' ability to understand fully and benefit from the information may be affected by health literacy

• Challenges with measures outside of provider’s control (e.g., secure messaging)• Certification process overly rigid and complex, and impacts usability

– Lack of quality, unambiguous specifications make interpretation variable, resulting in rework and usability issues

• Redundant reporting requirements (CQMs)• Panelists “thrilled” to be able to share experiences to help others

24

Findings: JASON Task Force Listening Sessions (1 of 5) May 2014

Overview• Many reactions point out that the JASON report underestimates progress being made in sharing

discrete patient data. (Beyond “digital fax machine.”)• Many felt that while the vision of discrete data APIs was a reasonable path the necessary

standards are not ready, and the time frame proposed by the JASONS was too fast. Several panelists recommended incrementally improving upon current CDA document-centric standards

• Many panelists felt the implementation timelines in the JASON Report were not realistic and felt 6-10 years was a more reasonable timeline for a complete shift to discrete data API (e.g. FHIR).

• Many panelists thought focus on discrete APIs would advance interoperability. Numerous panelists considered FHIR to be the likely emerging candidate, though other options exist. A majority of opinions felt that FHIR itself, and implementation by vendors, would not be possible under current 2017 Edition timetable.

• Technical architecture alone will not enable seamless exchange of health information the policy, business and legal aspects of exchange need to be addressed in tandem. Building a “network” will be as challenging as implementing standard APIs over “stovepipe” legacy EHRs.– Business incentives for exchange need to be aligned. No elegant architecture will overcome

an economic disincentive to share patient data. – Governance is key, need to take the time to get it right.

25

Detailed Findings: JASON Task Force Listening Sessions (2 of 5) May 2014

APIs• Many stakeholders thought additional focus on standards-based, discrete data APIs could be helpful to advance

interoperability. • But other stakeholders had varying opinions of the role of APIs in solving interoperability issues:

– JASON like platforms and their robust APIs misdirect us down a maze of tightly coupled integrations that are costly, fragile and brittle, not at all based on the loosely coupled data exchanges [Who said this?]

– Specific API requirements as part of ONC certification are neither realistic nor necessary; the growing industry adoption of standards-based API work such as FHIR, if focused on high- value use cases, is the more appropriate and sustainable path to accelerated use of APIs across the industry.

• There were differing opinions among app developers on the need to standardize EHR APIs. Some app developers felt with it was important to have standard APIs across EHR vendors. Other app developers felt it wasn’t necessary to standardize vendor APIs if EHR vendors were required to create APIs that were well documented and could read and write information. Examples of industries where multiple APIs exist were cited.

• Several EHR Vendors pointed out that they already expose (proprietary) discrete data APIs, and have many third-party users of their APIs.

• Current API approaches are either document-centric (XDS, XCA) or discrete-data centric (FHIR, OpenEHR.) Numerous groups are working on developing FHIR and FHIR Profiles, including S&I’s DAF, SMART Platform, HSPC, and IHE.) Document-centric APIs were de-valued by the JASONS, but several panelists pointed out that CCDA documents typically include embedded discrete data elements.

• The existence of a “public” API does not automatically imply that any entity has a right to use the API. Additional licensing, certification, and business arrangements (among other steps) are usually required before access to the API is granted to third parties. 26

Detailed Findings: JASON Task Force Listening Sessions (3 of 5) May 2014

APIs (continued)• Suggested artifacts necessary for a public API:

– Complete documentation (Developer Resources) for each level of the API– Ideally, a “test bed” will accompany the API where the API can be tested, in a non---destructive manner,

without exposing any patient identifying information.– Many public APIs will also include sample applications that provide a framework for proper use of the

API.– Support mechanisms to assist developers in resolving issues– Licensing mechanisms to promote adoption and deployment to a client base.– Ability to communicate when a change to the API will be made

• There was sparse discussion of the JASON’s recommendations about cryptography, metadata translation, and indexing services. Some panelists pointed to the need for a National Patient Identifier or equivalent national scale MPI service (including linked patient consent tracking) in order to realize the full JASON vision.

• There was relatively little discussion of the JASON’s “privacy bundle” concept.

Timeline• Panelists had differing opinions on if the timing of including an API requirement in Meaningful Use Stage 3

was achievable. • Many panelists felt that the timelines outlined in the JASON Report were not achievable. The transformation

discussed would take more on the order of 6-10 years for the ecosystem to fully implement and operationalize the entire JASON architecture. 27

Detailed Findings: JASON Task Force Listening Sessions (4 of 5) May 2014

Standards: Current and Future:• A number of panelists felt that while the vision in the JASON Report was a reasonable path it would be

difficult to implement and that more would be gained through following an approach of incrementally improving upon the standards/infrastructure in existence today.

• Many sources have described the problems with currently deployed C-CDA and its implementations – However, several of our panelists believed that C-CDA usage was getting better over time and has significant value for a variety of use cases. There was agreement that improvements to C-CDA should be made as quickly as possible (MU2 issues)

• Patient identify management came up repeatedly as a central problem that will have to be better addressed to achieve the vision outlined in JASON or any other approach to improving interoperability.

• FHIR was viewed by panelists as the most likely path towards the JASON vision though many felt FHIR would not be ready in time for inclusion in Stage 3 of Meaningful Use. One specific example of necessary work to be completed was the development the ability to query for a “complete” patient record.

• Some panelists raised concerns that the JASON Report didn’t focus sufficient attention to the challenges around semantic translation though the FHIR testimony described how FHIR Profiles could alleviate most of the need for semantic translation services.

28

Detailed Findings: JASON Task Force Listening Sessions (5 of 5) May 2014

Patient controlled data use• Patient at the center may make it easier to manage some aspects of exchange of health

information– including some types of secondary use.– Methods for patients to directly control who has access to their data– Methods for patients to contribute to, view, and when necessary correct their data – Mechanisms for patients to authorize the use of their data for research– Of note, the JASONs have updated their original notion that patients

“own” their data, and have acknowledged that patients “participate in the management” of their data.

– There is confusion about rights associated with primary clinical data versus the copy that patients have a right to obtain.

• The research community has a different set of data and standards needs versus providing clinical care. The research community has its own set of standards development organizations and while at times leverage standards utilized for clinical care (such as the C-CDA) they also have other unique needs not covered by standards/infrastructure development for clinical care purposes.

29

Findings: Privacy and Security Big Data Hearings (1 of 10)December 2014

30

Health Big Data Opportunities & the Learning Health System Testimony

Beneficial opportunities for using data associated with the social determinants of health• User generated data; e.g., track diet, steps, workout, sleep, mood, pain, and heart rate• 3 characteristics: (1) breadth of variables captured, (2) near continuous nature of its collection, and

(3) sheer numbers of people generating the data• Personal benefits predictive algorithms for risk of readmission in heart failure patients• Community benefits asthma inhaler data to identify hot spots; track aggregate behavior of

runners• Key issues: privacy, informed consent, access to the data and data quality• Important to allow experimentation for the technology and methods to improve• Important to allow institutions catch up to learn how best to take advantage of opportunities and

realize potential benefits

“Care between the care” patient defined data. May ultimately reveal a near total picture of an individual – merged clinical and patient data; data must flow back and forth Data needs access, control and privacy mechanisms throughout its life cycle, at level of data use, not just data generation; data storage is not well thought through

Findings: Privacy and Security Big Data Hearings (2 of 10)December 2014

31

Health Big Data Opportunities & the Learning Health System Testimony

Must embed learning into care delivery; we still do not have answers for a large majority of health questions

Key points:1. Sometimes there is a need to use fully identifiable data2. It is not possible to get informed consent for all uses3. Impossible to notify individuals personally about all uses4. Can’t do universal opt-out because answers could be unreliable5. There is likely a standard that could be developed that determines “clearly good/appropriate uses”

and “clearly bad/inappropriate uses”

Focus on:6. Minimum necessary amount of identifiable data (but offset by future use needs)7. Good processes for approval and oversight8. Uses of data stated publicly (transparency)9. Number of individuals who have accessed to data minimized (distributed systems help accomplish

this)When we use identifiable data, we must store it in highly protected locations – “data enclaves”

Findings: Privacy and Security Big Data Hearings (3 of 10)December 2014

32

Health Big Data Opportunities & the Learning Health System Testimony

• Shift in the way we look into data and its use• Paradigm of looking into the data first and then beginning to understand different

findings and correlations that you didn’t think about in standard hypothesis-driven research, but you do when you’re doing data driven research

• Focus on sharing, integrating, and analyzing cancer clinical trial data• Use de-identified data; de-identification is the responsibility of the data provider); most

data providers use expert determination method

• Data collected and used to conduct topological data analysis• Mathematics concept that allows one to see the shape of their data • Analysis can identify healthcare fraud, waste, and abuse, as well as reduce clinical

variation and improve clinical outcomes• Use de-identified data• We have not been able to get a data set that shows a continuum of care for a patient• While interoperability isn’t exactly perfect in other industries, in healthcare we’ve seen

that to be a unique issue

Findings: Privacy and Security Big Data Hearings (4 of 10)December 2014

33

Health Big Data Opportunities & the Learning Health System Testimony

• Partners drawn from academia, care delivery, industry, technology and patient and consumer interest

• Key asset is the database – 7.7 terabytes of de-identified data from administrative claims of over 100 million individuals over 20 years, clinical data from electronic health records of 25 million patients, and consumer data on 30 million Americans

• Data provided to researchers vie secure enclave• Premise: combine the insights of multiple partners• Key issue: systematically coordinating uses of de-identified techniques with subsequent

uses of PHI

• Cloud-based, single instance software platform with 59,000 healthcare provider clients • Products include EHR, practice management, and care coordination services• Data immediately aggregated into databases; near real-time visibility into medical

practice patterns• Monitor visit data for diagnoses of influenza-like illness • Tracking the impact of the ACA on community doctors; sentinel group of 15k doctors;

measuring # patients seen, health status, and out-of-pocket payment requests

Findings: Privacy and Security Big Data Hearings (5 of 10)December 2014

34

Health Big Data Concerns Testimony

A person’s health footprint now include Web searches, social media posts, inputs to mobile devices, and clinical information such as downloads from implantable devices

Key issues include (1) notice and consent, (2) unanticipated/unexpected uses, and (3) security

HIPAA does not apply to most apps

Without clear ground rules and accountability for appropriately and effectively protecting user health data, data holders tend to become less transparent about their data practices

Patient perspective• Frustration with “data dysfunction” - cannot access and combine his/her own data• Privacy and security are cited as excuses/barriers that prevent access to personal data• Health data is a social asset; there is a public need for data liquidity

Findings: Privacy and Security Big Data Hearings (6 of 10)December 2014

35

Health Big Data Concerns Testimony

Issues from conferences on big data and civil rights:

• The same piece of data can be used both to reduce health disparities and empower people and to violate privacy and cause harm

• All data can be health data• Focus on uses and harms rather than costs and benefits. Focusing on C&B implies

trade-offs. Instead, seek redress via civil rights laws.• Universal design. Design the technology and services to meet the range of needs

without barriers for some.• Ensure privacy and security of health information via all the FIPPs, not just consent• Principle of preventing misuse of patient data. There are many good uses of health

information, but there must also be some prohibitions.

Findings: Privacy and Security Big Data Hearings (7 of 10)December 2014

36

Consumer Protections Testimony

• Ease of re-identification narrative may be misleading• If you de-identify data properly, success rate is very low for attacks. If you don’t use

existing methods or de-identify data at all, and if data is attacked, success rate is high• De-identification is a powerful privacy protective tools• Most attacks on health data have been done on datasets that were not de-identified at

all or not properly de-identified • De-identification standards are needed to continue to raise the bar. There are good de-

identification methods and practices in use today, but no homogeneity.• HIPAA works fairly well – but mounting evidence that Safe Harbor has important

weaknesses• De-identification doesn’t resolve issues of harmful uses; may need other governance

mechanisms, such as an ethics or data access committees• Privacy architectures. Still need to de-identify the data that goes in to Save Havens• Distributed computation. You push the computations out to the data sources and have

the analysis done where the data is located

Findings: Privacy and Security Big Data Hearings (8 of 10)December 2014

37

Consumer Protections Testimony• Cant’ regulate something called “big data” because once you define it, people will find a

way around it• The people who think privacy protections don’t apply to big data are likely the same

people who have always been opposed to privacy protections • No reason to think HIPAA’s research rules need to be different because of big data.

HIPAA at least sets a clear and consistent process that covered entities and business associates must follow

• Privacy laws today are overly focused on individual control• Individual control is inadequate as both a definition and an aspiration. Impossible

expectation to think a person can control his or her personal health data • The effect of control is an impediment to availability. For most patients & families, the

primary concern about data misuse was that they would be contacted• Privacy is too critical and important a value to leave to a notion that individuals should

police themselves• We need to be thinking about how to make sure data is protected at the same time that

it’s available. We don’t let the mechanisms of protection by themselves interfere with the responsible use of the data

Current Law Testimony• HIPAA Safe Harbor de-identification requires removal of 18 fields

• May not give researchers the data they need/want; but some researchers cited the value of de-identified data

• Limited data set is a bit more robust, but not a lot• Definition of research same under HIPAA and Common Rule (generalizable knowledge)• May receive a waiver to use data by an IRB or privacy board• HITECH changes:

• Authorization may now permit future research (must adequately describe it)• Some compound authorizations now permitted for research purposes

• HIPAA applies to covered entities and business associates; patient authorization/consent is not required for treatment, payment, or healthcare operations purposes

• Paradox in HIPAA• Two studies that use data for quality improvement purposes using the same data

points done to address the same question or sets of questions and done by the same institution will be treated as operations (no consent required) if the results are not intended to contribute to generalizable knowledge (intended for internal quality improvement instead)

Findings: Privacy and Security Big Data Hearings (9 of 10)December 2014

38

Current Law Testimony

• HIPAA does not cover a large amount of healthcare data• Past few years = explosion in amount of data that falls outside of HIPAA

• Mobile applications, websites, personal health records, wellness programs • FTC is default regulator of privacy and security unfair or deceptive acts or practices

• Very active on general enforcement of data security standards• Debate as to whether the FTC really has authority to do this; 2 pending cases

• Less FTC enforcement in privacy space, especially healthcare• Tough question is broader FTC ability to pursue unfair practices in area of data

privacy (enforcement of deceptive practices is easier)• Fair Credit Reporting Act (FCRA) governs how information is gathered, used, and what

people must be told about contents of credit reports• Specific prohibitions using medical data for credit purposes

• Many conflicting state laws, which are often confusing, outdated and seldom enforced• Key issue: substantial gaps exist

• More and more data that is health-related is falling outside the scope of HIPAA rules

Findings: Privacy and Security Big Data Hearings (10 of 10)December 2014

39

Findings: Advanced Health Models Hearing (1 of 3) June 2015

• Community organizations are integral partners to advanced health models and are highly motivated to share data, but sharing across clinical settings and social services is not standardized and poorly incentivized.

• Advanced health models are making substantial progress by making existing data actionable in new ways, but stakeholders also need seamless access to analytics capabilities to make this data useful.

• Some advanced health models are responding to interoperability challenges by granting community organizations with access to a single platform, rather than realizing true interoperability across different systems.

• Advanced health models will need a data infrastructure that goes beyond EHRs.• Mapping patient identities across data sets is very challenging without consistent

patient identifiers. • There are many advanced health model use cases that require only limited

information about an individual, not the complete record; stakeholders need tools that allow them to filter information so that only actionable information is transmitted, to avoid overwhelming the data recipient and to avoid unnecessary privacy risks.

40

Findings: Advanced Health Models Hearing (2 of 3) June 2015

• Lack of clarity around privacy and security issues raised by sharing information with non-HIPAA covered community-based organizations impedes data sharing and raises concerns about adequate protection of PHI.

• A shared longitudinal care plan is a critical concept for managing an individual’s health across a continuum that includes both clinical and nonclinical settings.

• Community service organizations have varying levels of data support with their internal systems.

• Lack of standards for human social services impedes their use and integration with clinical systems.

41

Findings: Advanced Health Models Hearing (3 of 3) June 2015

• Integrating social determinants data into existing health information exchange (HIE) organizations with clinical stakeholders presents governance and privacy challenges.

• Innovative approaches to community resource directories are addressing new ways to meet individual needs.

• Advanced health models have recognized the importance of caregivers and individuals being able to access, use, and contribute to their health data to actively support and promote individual shared care planning and shared decision making.

• AHMs are still at an early stage of developing effective patient engagement strategies.

• Global budgeting and tracking total cost of care across settings are major enablers of advanced health models and will further align incentives to encourage investments across settings and stakeholders.

42

Approved HITPC Interoperability Related Recommendations Since 2013

43

Approved HITPC Recommendations Related to Interoperability

• Accelerating HIE RFI Recommendations – April 2013 (IEWG)• Query and Response Transmittal Letter – August 2013 (P&S TT)• Certification Transmittal Letter – June 2014 • LTPAC and Behavioral Health Certification Transmittal Letter

– June 2014 (Certification and Adoption WG)• ACO Health IT Capabilities Transmittal Letter – July 2014

(Accountable Care WG)• JASON Task Force Transmittal Letter – October 2014 (Jason TF)

– JASON Task Force Final Report

44

Accelerating HIE RFI Recommendations – April 2013 (IEWG)

45

Payment PolicyBackground

• The diffusion of advanced payment models has successfully spurred provider demand for information exchange through a combination of “carrots” (e.g., gain-sharing) and “sticks” (e.g., hospital readmission penalties)

• These models are still nascent, however, and there a number of areas where they could be improved:– Complexity of requirements– Lack of alignment across payor programs, both across public programs

as well as across public and private– Relatively slow diffusion of advanced payment models and “long tail”

of fee-service model

46

47

1. HHS should work to simplify and harmonize requirements across advanced payment models for public and private payors. This will help providers focus on the desired outcomes rather than the often complex mechanics of the current programs

2. Since there is still a lag in adoption of HIE capabilities through advanced payment models:

− Highly focused supplemental payments to capitated and fee-for-service models to motivate HIE-enabled activities (e.g., higher E&M coding for “cognitive activities” using HIE, such as information reconciliation)

3. Voluntary certification program for HIE functions that enhance enablement of value-based purchasing activities

Payment PolicyRecommendations

Providers Ineligible for Meaningful UseBackground

• While MU Stages 2 and 3 are expected to create significant incentives for broader and deeper HIE adoption, significant sectors of the care continuum do not qualify for financial incentives, nor are they subject to the corresponding regulatory authority– Long-term and post-acute care providers (LTPAC), includes skilled

nursing, home health, rehabilitative, custodial, etc– Pharmacists– Commercial laboratories

• The inapplicability of MU to these types of providers leaves gaps in the HIE incentive and regulatory framework that result in structural impediments to progress in interoperability across the care continuum

48

Providers Ineligible for Meaningful UseRecommendations

1. HHS should harmonize required documentation and reporting across programs and with the MU framework– Harmonization of CMS-required documentation with CCDA– Incentives to Part D providers to motivate HIE-enabled and HIE-enabling

activities– Advance administrative simplification where it intersects with clinical

standardization, such as prior authorization documentation requirements2. Laboratories

– Provide safe harbor from certain CLIA requirements if providers are compliant with MU and using certified technology

– Increase aggressiveness of Stage 3 eligible hospital laboratory results delivery requirements to move the market faster

3. Require (if possible) or facilitate (if not) voluntary certification of technology used by providers ineligible for meaningful use, in alignment with MU requirements

49

State-level program/policy variationBackground

• State-level variation in program requirements and policies impedes HIE adoption by making it more difficult for multi-state care organizations and technology vendors to create scalable processes, services, and products

• Some of this variation lies in differences in programs that have Federal and State components (e.g., Medicaid reimbursement, Medicaid waivers, public health, etc.)

• Other types of variation lie in differences that are solely rooted in areas where States have independent policy authority (e.g., privacy, liability, etc.)

50

State-level program/policy variationRecommendations

1. CMS should include HIE requirements in all programs including state waivers and future advanced payment demonstrations, and require coordination as much as possible with the State HIT Coordinators

2. CDC should continue and increase its work to harmonize the variability across states in the standards utilized for public health reporting to enhance use of HIE

3. HHS should create model language available for inclusion in state-level programs (e.g., Medicaid MCO contracts, state employee health plans, etc.) to encourage HIE activities

4. HHS should identify and encourage any opportunities for reducing state-level variation in privacy and liability policies related to HIE activities

51

InfrastructureBackground

• HHS maintains a large infrastructure to manage its various programs related to health care payment, health care delivery, public health, and product regulation

• Some of these infrastructure components and associated services can be opened up for public use to catalyze and enhance development of market-based HIE products and services

52

InfrastructureRecommendations1. CMS should repurpose existing data and business infrastructure to

facilitate market development of HIE capabilities1. Apply open data principles to provider databases (NPES, MU, NPI) to

make data available to market for provider directory creation2. Build on credentialing of patients and providers to support validation

needs for HIE activities (e.g., provisioning patients with Direct addresses)

3. Enable patient access to immunization information contained in public health immunization registries

2. Alignment of FDA programs with MU framework, such as device interoperability (facility and home), structured product labeling standards, and event reporting standards

53

Appendix

54

55

1. HHS should work to simplify and harmonize requirements across advanced payment models for public and private payors. This will help providers focus on the desired outcomes rather than the often complex mechanics of the current programs

− Harmonize quality and outcome measures across HHS programs− Allow deeming of process measures that are nested within corresponding

outcomes measures and goals− Convene with private payors to align outcomes measures and the use of

electronic clinical quality measures (eCQMs)2. Since there is still a lag in adoption of HIE capabilities through advanced

payment models:− For those already in advanced payment model, highly focused

supplements to capitated payments for desired process enhancements, such as more use of HIE-enabled care coordination

− For those still in fee-for-service payment model, highly focused payments to support HIE-enabled “cognitive activities” (e.g., allow higher E&M codes for completion of HIE-enabled medication, allergy, care plan or problem list reconciliation prior to and after a transition-of-care)

Payment PolicyDetailed Recommendations

56

3. HHS should consider opportunities for certifying technology to facilitate value-based purchasing activities that go beyond the MU foundation− Depth: deeper integration into EHR workflows; tighter

content/vocabulary requirements; more robust reconciliation capabilities such med/problem/allergy reconciliation, etc.; eCQM and eCDS

− Breadth: interoperability with broader set of health care settings (e.g., LTPAC, etc.); inclusion of broader set of functions (e.g., population care management and aligned CDS), measures/CDS (e.g., ACO-specific measurement and reporting capabilities), and data management and analytic capabilities (e.g., claims, risk stratification); ability to consume externally generated alerts

Payment PolicyDetailed Recommendations (continued)

Providers Ineligible for Meaningful UseDetailed Recommendations

1. HHS should harmonize required documentation and reporting both across programs and with the MU framework– ONC should harmonize the care plan requirements so that meaningful use

eligible providers are able to receive care plans from non-meaningful use eligible providers (e.g., nursing facilities)

– The clinical elements of CMS-required documentation should be harmonized to the CCDA: Minimum Data Set (MDS), Outcome and Assessment Information Set (OASIS) and Care Tool, Home Health Plan of Care (CMS 485) and IRF-PAI (Part A fee-for-service rehabilitative inpatient)

– HHS should align the MTM and Stars Programs to incent the sending and receiving of a meaningful use harmonized CCDA

– CMS should accelerate levers in Part D to support cognitive activities such as medication therapy management by pharmacists

– HHS should continue its efforts to advance administrative simplification that would leverage HIE enablement, such as harmonization of prior authorization data requirements with CCDA structured data requirements

57

Providers Ineligible for Meaningful UseDetailed Recommendations (continued)

58

2. Specifically related to laboratories– A safe harbor to CLIA’s visual verification requirements should be established for

commercial labs if they utilize the meaningful use standards for transmitting labs to an EHR that is meaningful use certified

– In Stage 3 of meaningful use CMS should make the eligible hospital objective to provide structured electronic lab results to ambulatory providers a core measure and increase the required measure as aggressively as possible

3. ONC should encourage voluntary certification programs to support Meaningful Use ineligible provider participation in health information exchange, either formally (if statute allows) or in collaboration with private certification entities– Standardize certification of Home Health providers across the country and harmonize

documentation requirements with the CCDA– Certify technology to support CCDA-harmonized documentation (e.g., MDS for nursing

facilities, OASIS and Home Health Plan of Care for home health, IRF-PAI for inpatient rehabilitative facilities)

– Certify EP EHR technology to receive relevant CCDA-harmonized structured documents from MU ineligibles (e.g.. Home Health Plan of Care from home health providers)

– Authorize relevant MU ineligibles for other HHS electronic documentation programs, such as esMD

State-level program/policy variationDetailed Recommendations

1. When CMS approves state waivers for advanced payment models, where applicable, they should require the alignment of the outcomes and process measures with those established in Medicare advanced payment programs

2. CDC should continue and increase its work to harmonize the variability across states in the standards utilized for public health reporting to enhance use of HIE

3. CMS should continue to include HIE requirements in future advanced payment models, programs and solicitations

4. Where appropriate, HHS should require coordination with the State HIT Coordinator when releasing state level programs and solicitations, and also require ongoing coordination during implementation of these programs/solicitations and strongly encourage such coordination in all other relevant areas

59

State-level program/policy variationDetailed Recommendations (continued)

5. HHS should establish a framework for HIE maturity similar to the MITA framework. This framework can provide a roadmap to ACOs, health care providers, exchange entities, States and others that have to enable HIE to support their work. – e.g., States submitting an IAPD for 90/10 funding are currently required to

describe how their HIE activities will mature over time

6. HHS should work with states to implement common language across state employee health plans, Medicaid (including Medicaid managed care organizations) etc, that will help advance HIE. – For example states could require in solicitations for MCOs and/or the state

employee health plan that applicants require participating providers to electronically exchange health information at care transitions

7. On privacy policy variation, HHS should review the recommendations developed by the Health Information Security and Privacy Collaboration (HISPC) to determine if there are items that could be productively advanced today

8. HHS should review whether variations in liability related to HIE activities is a current or possible future barrier to adoption

60

InfrastructureDetailed Recommendations1. CMS should continue their open data efforts by publishing NPI, MU attestation, NPPES data to

support the establishment of provider directories. 2. HHS should explore opportunities available through their existing credentialing infrastructure

for organizations and individuals to see if this infrastructure could be leveraged to support validation/authentication needs for HIE. – e.g., Leverage/repurpose the validation that occurs for a patient to access their Medicare

claims information to issue and manage Direct addresses3. CDC should work with states to enable patients to access to their immunization information,

as a number of states do today. CDC and ONC should work together to develop a roadmap of methods that states can utilize to give patient access to immunization information either through patient-controlled applications and/or through provider-tethered applications

4. FDA should require or encourage device interoperability to make it easier for information to be extracted from medical devices, including home monitoring devices (e.g., home blood pressure monitor) for both providers and patients.

5. FDA should align its structured product labeling standard with those adopted by ONC and NLM. FDA should harmonize with NDC with RxNorm.

6. FDA should harmonize its event reporting standards with SNOMED

61

Query and Response Recommendations – August 2013

62

Query and Response Recommendations

Recommendations• At the April 4, 2013, HIT Policy Committee meeting, the Tiger Team

presented recommendations on query and response for health information exchange. The recommendations are based on scenarios 1 and 2 above, in which providers may request information, in a targeted manner, from another provider or entity for direct treatment purposes. These recommendations are not attempting to alter existing rules that vest providers with the responsibility to share patient information responsibly and within the bounds of the law. Instead, these recommendations are intended to reduce potential real or perceived barriers to responding to a query consistent with a provider’s professional obligations and the law.

• The HIT Policy Committee deliberated on these findings and approved

recommendations below for transmittal to the National Coordinator.

63

Query and Response Recommendations –Scenario 1

Scenario 1 Recommendations: Targeted Query for Direct Treatment Under HIPAAThe Tiger Team began its query and response discussion with Scenario 1, which is defined as a provider requesting PHI from another specific provider (or other specific providers) about a particular patient for direct treatment purposes. The query and response in this scenario are controlled by HIPAA; no stronger privacy laws apply. These recommendations are based on the existing obligations of the data holder and the requester. Specifically, the data holder:

– Needs some reasonable assurance as to the identity of the entity requesting the data,– Needs some reasonable assurance that the querying entity has, or is establishing, a direct treatment relationship with the patient,– Makes a decision about whether to release data, and if so, what data, consistent with law, and– If responding, needs to send back data for the right patient, and needs to properly address the response and send it securely.

The requester:– Needs to present identity credentials,– Must demonstrate (in some way) the treatment relationship, and– Must send patient identifying information in a secure manner to enable the data holder to locate the record(s).

In response to those obligations and the goal of providing clarity to both the requester and the data holder on satisfying their legal and professional obligations, the Tiger Team answered six questions. For questions 1 and 2, the answers provide possible options for addressing requester and data holder obligations and are not intended to be exhaustive.

1. What supports “reasonable” reliance, by the data holder, that the requester is who they say they are? (Possible solutions)a) The use of a DIRECT certificate may provide reasonable assurance of a requester’s identity to the data holder. When issued at the entity level, the

expectation is that entities have identity proofed and authenticated individual participants as per HIPAA.b) The requester may have membership in a network (HIO, vendor network, integrated delivery system (IDS), virtual private network (VPN), etc.) that

the data holder trusts.c) The requester is known to the data holder, such as through a pre-existing relationship.

64

Query and Response Recommendations –Scenario 1

2. What supports “reasonable” reliance, by the data holder, that the requester has (or will have) a direct treatment relationship with the patient –and in this direct treatment scenario, therefore has legal authority and is otherwise authorized to obtain the data? (Possible solutions)

a) A data holder’s own knowledge or history of the requester and patient’s relationship is sufficient to determine the requester and patient’s direct treatment relationship.

b) A data holder may have the capability to confirm a requester’s direct treatment relationship with a patient within a network or IDS.

c) A network that the data holder trusts has rules providing accountability for false attestation, such as penalties against the requesting entity.

d) A requester may provide some official communication of patient consent that does not conflict with expressions of patient wishes known to, or on file with, the data holder.

e) There may be a known existing treatment relationship with the patient. The requester may have previously sent a query for the patient to the data holder.

3a. Does it matter if the data holder makes the decision to disclose data or if the data holder’s response is automated (set by the data holder or automatic by participation, such as in a network)?

f) Yes. The data holder may make a decision to automate a response to a query and should adopt policies to govern when automatic responses are appropriate. Such policies should be linked to the degree of assurance the data holder has about identity and the legal authority to disclose data, based on the existence of a direct treatment relationship.

3b. To what extent does automation trigger our previous recommendations on the need for meaningful choice by patients?g) If the data holder maintains the ability to make decisions on when to disclose a patient’s information, they can

choose to automate their decisions (following similar policies customarily used to release patient information). However, if data holders do not have discretion over record release policies, the Tiger Team’s previous recommendations on “meaningful choice” for the patient apply.

65

Query and Response Recommendations –Scenario 1

4. What patient identifying information should be presented as part of the query?a) A requesting provider’s query should, ideally, present no more (but also no less) PHI than what is needed to

accurately match to a record.b) A query should start with available demographics before using more specific information.c) The HITPC/Tiger Team’s previous recommendations on matching should be implemented. These

recommendations called for (1) a standardized format for data matching fields, (2) healthcare organizations/entities to evaluate the effectiveness of their matching strategies as a means of improving accuracy, and (3) matching to be enforced through governance, (4) ONC to establish a program(s) to develop and disseminate best practices in improving data capture and matching accuracy, and (5) increased patient access to their health information and the establishment of audit trails to track where information has been accessed.

5. How should data holders respond to a query?d) Silence is not an appropriate response. Data holders should respond to queries in a timely manner by either

providing i) some or all of the requested content or ii) a standardized response indicating the content requested is not available or cannot be exchanged. This approach is based on the provisions of the Data Use and Reciprocal Support Agreement (DURSA), the participation agreement for the eHealth Exchange. (It should also be noted that even acknowledgement of the existence of a record is PHI.)

6. Should there be a requirement to account for and log query and/or disclosures, and should the log be shared with the patient upon request?

e) Yes. The data holder should log both the query from an outside organization and the response, regardless of its content. The requester should also log the query. This information should be available to the patient upon request.

66

Query and Response Recommendations –Scenario 2

Scenario 2 Recommendations: Targeted Query for Direct Treatment Under HIPAA and Other LawsThis scenario has similar actors to scenario 1, but is subject to additional laws. Scenario 2 is defined as targeted queries for direct treatment purposes that are subject to HIPAA and more stringent privacy laws that typically require patient consent or authorization before PHI disclosure. Additional laws may be stronger state privacy laws or other federal laws such as federal substance abuse treatment laws. Recommendations are as follows:

1. Data holders and requesters must comply with the laws or policies that are applicable to them. Patient consent or authorization may be required prior to a query and/or release of PHI.

2. The form of consent must comply with applicable law. The requester and data holder must each have a form that satisfies their legal requirements (if applicable). These forms may not be the same.

3. As a best practice and to assist providers in complying with applicable law and policies, parties to a query/response should have a technical way to communicate applicable consent/authorization needs or requirements, and maintain a record of such transactions. For example, data holders may need to communicate with a querying entity that a particular patient authorization is required before data can be shared; the data holder (and in some cases the requester) may need or want to record the communication and the authorization. As another example, data holders sharing data subject to 42CFR Part 2 (substance abuse treatment regulations) may need to communicate restrictions on “redisclosure.”

4. The HIT Standards Committee should further consider technical methods for giving providers the capacity to comply with applicable patient authorization requirements or policies. A “one size fits all” approach may not apply given current technologies. Entities may also use a service to meet their needs in this area.

67

Certification Recommendations – June 2014

68

Recommendations

1. Conduct a Kaizen process covering the entire certification process – from translation of meaningful use objectives to certification criteria to development of test scripts to development (and quality assurance) of testing tools to conduct of certification tests to conduct of post-attestation audits. Suggestions regarding the Kaizen included the following:

a) Involve broad stakeholders including: providers, developers, ATLs/ACBs, and auditorsb) Establish certification roadmap and timelines to improve predictabilityc) Create a timely plan, do, check, act (PDCA) mechanism for continuous feedback from the public

and process improvement

2. Limit the scope of certification to those functions critical to interoperability and outcomes improvement. Some suggested priority areas include interoperability, clinical quality measurement, and privacy and security. To be effective the critical-few approach would require:

a) Cross-organizational collaboration (and policy interoperability)b) Alignment of standards, measures, and programsc) Overarching governanced) Public-private collaboration

69

LTPAC and Behavioral Health Certification Recommendations – June 2014

70

Develop A Process for Evaluating Any New Certification Program

HITPC recommends that in considering whether to pursue any new certification initiative, ONC should consider the below Five Factor Framework, which balances the benefit of health IT certification against the various costs that might be incurred by the same. The Five Factor Framework asks whether the proposed certification initiative would :

1. Advance a National Priority or Legislative Mandate: Is there a compelling reason, such as a National Quality Strategy Priority, that the proposed ONC certification program would advance?

2. Align with Existing Federal/State Programs: Would the proposed ONC certification program align with federal/state programs?

3. Utilize the existing technology pipeline: Are there industry-developed health IT standards and/or functionalities in existence that would support the proposed ONC certification program?

4. Build on existing stakeholder support: Does stakeholder buy-in exist to support the proposed ONC certification program?

5. Appropriately balance the costs and benefits of a certification program: Is certification the best available option? Considerations should include financial and non-financial costs and benefits.

71

Certification Criteria for LTPAC and BH Settings

Recognizing the heterogeneity of settings, variation in scope of practice, and the differences in workflow within and across settings, the C/A WG organized certification criteria for LTPAC and BH settings into three categories. The first category of “All Providers” refers to certification criteria that the workgroup identified as being applicable to all provider types (e.g., hospitals, primary care, specialists, LTPAC and BH), the “LTPAC /BH Setting Specific” category refers to criteria relevant to the named care settings, and the “Some Providers” category references criteria that may be relevant to certain LTPAC or BH providers, depending on the scope and needs of the practice.

1. The following certification criteria are relevant to all providers:

– Transition of care: LTPAC and BH providers should adopt health IT that is certified by ONC for transitions of care. Beginning with the criteria in the 2014 Edition, transitions of care certification criteria for LTPAC and BH settings should align with the transition of care certification criteria for the EHR Incentive Programs. HITPC notes that all settings—including settings outside of MU such as LTPAC and BH—should use the same transitions of care certification criteria and standards to promote interoperability and improved care coordination.

– Privacy and Security: LTPAC and BH providers should adopt health IT that is certified by ONC for privacy and security. Beginning with the criteria in the 2014 Edition, privacy and security certification criteria for LTPAC and BH settings should align with the privacy and security certification criteria for the EHR Incentive Programs. HITPC notes that all settings—including settings outside of MU such as LTPAC and BH—should use the same privacy and security certification criteria and standards to ensure that all systems have the same core set of protections within their systems.

– In addition to the above recommendations, the Policy Committee’s Privacy and Security Tiger Team made additional recommendations regarding data segmentation which are relevant to the certification program and are included as attachments to this letter.

72

Certification Criteria for LTPAC and BH Settings

2. The following certification criteria are relevant to LTPAC and BH providers: – LTPAC Patient Assessments: Support the use of ONC specified HIT standards for the CMS-

mandated patient assessments (for example, the MDS for nursing facilities and OASIS for home health agencies) that are required in these care settings. This will enable reuse of the data for clinical and administrative purposes. ONC should partner with CMS to align the standards to support re-use and exchange of the information in these assessments. A certification criterion was not recommended at this time because of additional standards and workflow work needed to support the interoperable exchange of patient assessment data with other provider types.

– BH Patients Assessments: Future work was recommended to identify standards which could

support BH patient assessments by identifying the most useful data elements from existing assessments. Unlike for LTPAC, standardized assessments are not in place to be used uniformly. There are also state-specific assessments, adding to the variability.

– Trend Tracking: 1) Track national trends in LTPAC and BH health IT adoption, including use by functionality and by certification criteria; and 2) Utilize EHR adoption definitions consistent with those used in other ONC/CMS initiatives. Such tracking would provide baseline data and enable monitoring of EHR adoption and use among LTPAC and BH providers.

73

Certification Criteria for LTPAC and BH Settings

3. Other Considerations

• The workgroup also reviewed a broader range of ONC certification criteria that were categorized as “Relevant to Some Providers” (e.g., clinical reconciliation, CPOE, clinical decision support, labs, imaging, patient engagement). It was determined that these additional functionalities may be of value to some care settings depending on care delivery needs and scope of practice. However, because of the broad range of LTPAC and BH provider types with differing needs, the workgroup concluded that these criteria should be evaluated independently by each setting. The workgroup also noted that there may be programmatic reasons at the federal or state level for adopting certification functionality in this category.

• Finally, the C/A WG requested that the HITPC Quality Measurement Workgroup examine opportunities

for LTPAC and BH EHR certification related to quality measurement. While there are no final recommendations in quality measurement at this time, the draft recommendations of the Quality Measures Workgroup could serve as a foundation for future exploratory work.

• We appreciate the opportunity to provide these recommendations to inform the development of ONC’s new certification initiative. We concur that the modular, voluntary approach to certification will not only support provider access to the functionality they need from their EHRs but also will improve interoperability as health information travels with the individual across care settings.

74

ACO Health IT Capabilities Recommendations – July 2014

75

I. Exchanging Information across the Healthcare Community

Actionable Recommendationsa) CMS should leverage innovative service delivery models to encourage hospitals and other institutions to make admission, discharge, and

transfer (ADT) feeds available to any appropriate receiving entity across their community. Many communities have demonstrated that electronic patient event notifications supported by ADT feeds are a powerful and low-cost tool to allow participants in value-based payment programs to better manage patient care. As CMS looks to scale many of the innovative service delivery models it has deployed, and designs forthcoming models with a medical neighborhood or community orientation, it should work with ONC to ensure these models encourage participating hospitals and health systems make ADT feeds widely available to other entities to support community wide care coordination goals.

b) ONC should work with CMS to update hospital survey and certification standards to require institutions to make electronic discharge summaries available to external providers in a timely manner. CMS should update hospital survey and certification guidance to state surveyors to include assessing the degree to which hospitals send electronic discharge summaries in a timely manner to the external providers of the patient’s care, regardless of affiliation with the hospital.

c) Increase public transparency around hospital and health system performance on measures related to health information exchange through public reporting Web sites. ONC should work with CMS to explore public reporting options that would measure the degree to which hospitals and health systems are appropriately sharing health information. For example, this might be achieved through the reporting of Meaningful Use transitions of care measure results as part of inpatient quality reporting on the Hospital Compare Web site. HHS could also consider outcome measures which demonstrate that hospitals and health systems are achieving positive health outcomes that reflect effective sharing of information among providers.

d) Explore new accountable care models that focus on achieving shared savings in accountable care organizations that feature significant participation from LTPAC, behavioral health, or home health providers. CMS should explore accountable care models under which ACOs can receive shared savings for demonstrating improvement on measures reflecting successful coordination with entities such as LTPAC, behavioral health, and home health providers. Many of these providers were not eligible for the EHR incentive program and do not have the IT infrastructure to participate in robust care coordination initiatives; shared savings incentives from such a model could be targeted to support IT infrastructure development for these partners.

e) Explore regulatory options and other mechanisms to encourage appropriate sharing of information protected under 42 CFR Part 2 across participants in an accountable care organization. As SAMHSA considers options for refining rules around the sharing of information protected under 42 CFR Part 2, it should address key needs for providers participating in accountable care organizations. For instance, SAMSHA could permit ACO entities that include substance abuse facilities to establish QSOAs across participants with an administrative relationship, or clarify the conditions under which primary care providers conducting SBIRT services are considered Part 2 providers.

76

II. Data Portability for Accountable Care

Actionable Recommendationsa) Require certified products to allow increased access to data residing in EHRs by other types of HIT systems

to support population health management, operations, financial management, and other functions. The health IT certification program should consider a requirement by which vendors would demonstrate that they can easily integrate with other applications. For instance, ONC could implement standards being developed under the Data Access Framework (an S&I Initiative) around a common API for HIT applications which would allow real-time sharing of information between applications.

b) Pursue greater specificity in federal interoperability standards around transactional data. The availability of structured data is critical to accountable care infrastructure. ONC should continue to develop more specificity in federally recognized interoperability standards to promote semantic interoperability and seamless flow of information across systems. ONC should look for immediate opportunities to increase specificity around transactional data such as discrete HL7 data feeds for admissions, discharges and transfers, notifications, labs, prescriptions, etc., as well as further specification of structured data within the CCDA.

c) Strengthen data portability elements in certification criteria to ensure systems have demonstrated that they can receive and process data, not only send data. Lack of confidence around the ability of HIT systems to receive and process data, despite being certified to send data, is a major challenge for accountable providers seeking to coordinate care. ONC should expand testing procedures for certified EHR technology that require products to demonstrate the technical ability to not only send discrete data points in a recognized, structured, and consumable manner, but also receive and make data computable within a receiving application.

77

III. Clinician Use of Data and Information to Improve Care

Actionable Recommendationsa) Establish pilots to understand how clinicians can use electronic shared care planning tools to deliver effective team-based

care across settings. Granting agencies such as CMMI, AHRQ, HRSA, and others, should establish new initiatives to pilot, test, and document best practices for using electronic shared care planning tools including HIE-based services, EHR-based modules, and care management software.

b) Facilitate consensus around shared approaches to standards-based electronic shared care planning across the continuum of care to promote wider adoption of these tools. The comprehensive, longitudinal, care plan is an integral tool for coordinating patient care, particularly within the accountable care environment where multidisciplinary care teams across settings must deliver coordinated care. While electronic standards continue to mature, a lack of broad clinical consensus around the value of care planning approaches outside of specific disciplines (e.g. nursing), and questions about how to implement shared care planning approaches in practice, will continue to result in minimal adoption of these approaches. ONC can work with other agencies across HHS to act as a neutral convener to accelerate consensus across the clinical community around a vision for interdisciplinary shared care planning. Following input from clinical stakeholders, patients, vendors, technology experts, and others, HHS could then look at how various policy levers, including the future trajectory of electronic standards for care planning tools, can be aligned with this consensus vision.

c) Pursue research with federal partners such as AHRQ around the effectiveness of clinical decision support to improve the impact of these tools. More research is needed into when CDS is effective in informing clinician decision-making, e.g. the breadth of data needed to deliver effective decision support. ONC should partner with AHRQ and other federal partners to better understand how human factors research and user interface design can maximize the impact of clinical decision support and potentially inform how the health IT certification program can maximize the effectiveness of CDS in the future.

d) Explore strategies to increase the utility of CDS tools by supporting the incorporation of external data from multiple sources. A key use case for ACOs around CDS is the ability of external data to be integrated with data in the EHR so that it can trigger a more sensitive CDS alert. More work is needed around how to get to this functionality. ONC should prioritize development and certification of standardized functionality within EHRs that would enable consumption of external data to trigger clinical decision support alerts.

78

IV. Leveraging Existing Sources of Information to Support a Data Infrastructure for Value-Based Programs

Actionable Recommendationsa) CMS, ONC and other federal partners should work together to articulate a future strategy around how the

government can advance a scalable data infrastructure model to meet the data and reporting needs of providers in accountable care arrangements. Integrating clinical data with claims, cost, and price data across participating payers and providers can support less burdensome reporting of quality metrics, increased capacity of providers to improve quality and reduce costs, and improved specificity of predictive modeling. HHS and other federal partners can advance progress toward these objectives by articulating a strategy for how the federal government will engage with the various entities capable of receiving and aggregating these data at the local, regional, and state level (e.g., all-payer claims databases, regional health improvement collaboratives, health information exchanges, Medicare qualified entities, etc.).

b) ONC should coordinate across HHS to expand support for the development of state-level all-payer claims databases (APCDs) to support accountable care arrangements (inclusive of Medicare & Medicaid). CMS should use state-level mechanisms (e.g. SIM funding) to support the development of APCDs, ensure that Medicaid and private payers doing business in that state are contributing data to an all-payer claim database or other identified entity, and ensure that APCDs make data on their attributed patients available to provider groups taking on financial risk. A uniform quality assurance methodology to assess the reliability of claims integration processes should be independently developed as part of this program.

c) Drive progress on standardization and capture of social determinants of health data elements that are critical to accountable care and other delivery models. Healthcare stakeholders must work towards inclusion of a broader set of information of community and social inputs that are critical to effective care delivery, beyond clinical information alone. ONC should work with other HHS initiatives, such as the State Innovation Model, to understand the scope and issues related to making an integrated set of social determinants of health (SDH) available for both patient care and for planning/research purposes. ONC/HHS should build on existing efforts (e.g. current initiatives led by the Institute of Medicine) and consider establishing pilots to focus on the capture and sharing of social determinants of health data to inform how future policy directions can support access to and availability of this data.

79

JASON Task Force Recommendations– October 2014

80

JASON Task Force Recommendations

1. Focus on Interoperability. ONC and CMS should re-align the MU program to shift focus to expanding interoperability, and initiating adoption of Public APIs.

• Recommendation: Limit the breadth of MU to shift the focus to interoperability– MU Stage 2 experience shows that overly broad and complex requirements slow progress on all fronts.– Focused on interoperability will send strong signal to market and allow providers and vendors to focus resources.

• Recommendation: Three complementary HITECH levers should be exercised– Add certification of highly constrained Public API to CEHRT standards.– Encourage and motivate vendors to grant third-party access to Public APIs based on appropriate business and legal

conventions.– Structure incentive requirement programs (MU Stage 3 and others) so that providers grant third-party access to

Public APIs based on appropriate business and legal conventions.

• Recommendation: ONC and CMS should act with urgency to use HITECH to motivate industry-wide API-based capabilities– ONC should immediately engage the FACAs to further flesh out JTF recommendations on Public API-based

architecture– ONC should immediately contract with an SDO or other recognized operationally active industry consortium to

accelerate focused development of initial Public API and Core Data Services and Profiles for inclusion in MU Stage 3 and associated certification

– CMS and ONC should consider mechanisms to accommodate an accelerated development process for a feasible initial Public API specification

81

JASON Task Force Recommendations

2. Industry-Based Ecosystem. A Coordinated Architecture based on market-based arrangements should be defined to create an ecosystem to support API-based interoperability.

• Recommendation: A market-based exchange architecture should be defined by industry and government to meet the nation’s current and future interoperability needs based on the following key concepts:

– Coordinated architecture. A loosely couple architecture with sufficient coordination to ensure that a market-driven ecosystem emerges for API-based exchange.

– Data Sharing Networks (DSN). An interoperable data sharing arrangement whose participants have established the legal and business frameworks necessary for data sharing.• Conform to the Coordinated Architecture and use the public API. • Could include, but is certainly not restricted to, existing networks such as those run by vendors or providers or health

information exchange organizations. – Public API. A standards-based API that is to be implemented with certain obligations and expectations

governing “public” access to the API.– Core Data Services. Fundamental, standards-based data services that implementations of the Public API are

expected to provide.– The Coordinated Architecture

• Should not be single, top-down architecture• Loosely coupled based on scalable internet principles to accommodate implementation heterogeneity• Leverage and build upon existing networks, while encouraging new networks• Do not envision that the Coordinated Architecture is necessarily an entity or actual implementation, but rather, standards

and principles based on internet principles and building blocks82

JASON Task Force Recommendations

3. Data Sharing Networks in a Coordinated Architecture. The architecture should be based on a Coordinated Architecture that loosely couples market-based Data Sharing Networks.

• Recommendation: The nationwide exchange network should be based on a Coordinated Architecture that “loosely couples” market-based Data Sharing Networks

– The Data Sharing Networks• Data sharing arrangements that provide facilitating policy and infrastructure to support use of Public APIs• Within the DSN:

– Facilitating API-based exchange among entities. This has a technical component (e.g., what technologies are used to identify patients or authenticate users across entities?), and a policy component (e.g., what data or documents are accessible through a Public API, and what are the allowed purposes for data or documents accessed through a Public API?)

• Across DSNs:– Implementing services to be used to bridge across different DSNs, when this is deemed necessary. This will have

cross-network technical components (e.g., which standards and protocols are used for different DSNs’ patient-matching or authentication technologies to interact with each other?), and policy components (e.g., how are “out of network” entities authorized, and what data or documents are accessible to authorized “out of network” entities?)

• Clinical and financial systems that expose the Public API will have the ability to exchange data without needing a DSN

83

JASON Task Force Recommendations

4. Public API as basic conduit of interoperability. The Public API should enable data- and document-level access to clinical and financial systems according to contemporary internet principles.

• Recommendation: The “Public API” should enable data- and document-level access to clinical and financial systems in accordance with Internet-style interoperability design principles and patterns. The Coordinated Architecture and Data Sharing Networks create an ecosystem to facilitate use of the Public API.

– The Public API• Comprises two components

– an implementation of certain technical standards (the “API”)– an agreement to meet certain obligations governing “public” access to the API

• What makes an API a “Public API” is a set of conventions defining “public” access to the API– A “Public API” does not imply that data is exposed without regard to privacy and security. However, there are

legal and business considerations that must be addressed before any given healthcare provider and/or vendor would allow another party to use the API to access information.

– What is “public” in a “public API” is that the means for interfacing to it are uniformly available, it is based on non-proprietary standards, it is tested for conformance to such standards by trusted third parties, and there are well-defined, fairly-applied, business and legal frameworks for using the API.

84

JASON Task Force Recommendations

5. Priority API Services. Core Data Services and Profiles should define the minimal data and document types supported by Public APIs. • Recommendation: Core Data Services and Profiles should define the minimal data and document

types supported by all Public APIs. HITECH should focus initially on Clinician-to-Clinician Exchange and Consumer Access use cases.

– The Core Data Services• Read/write access to both clinical documents (e.g., CCDA, discharge summary, etc.) and discrete clinical data elements

(e.g., problems, medications, allergies, etc.)• Initial focus areas for the industry:

» Clinician-to-clinician exchange (including ancillary service providers)» Consumer access» "Pluggable" apps – for consumers and for clinicians» Population health and research» Administrative transactions

• The Core Data Profiles– Tightly specify data elements and formats used in Core Data Services– Priority profiles should be developed for Clinician-to-Clinician Exchange and Consumer Access

• Initial recommended focus of HITECH– Clinician-to-Clinician Exchange

» Complement current document-centric approaches that exist in the market today – Consumer access

» Natural extension of View/Download/Transmit and Blue Button» Leverage account services already provided by entities hosting patient portals and patient applications» Could open wide avenues of growth from mHealth and “pluggable app” companies who are not tied to legacy software

85

JASON Task Force Recommendations

6. Government as market motivator. ONC should assertively monitor the progress of exchange and implement non-regulatory steps to catalyze the adoption of Public APIs • Recommendation: Federal government should take the following actions to help the industry overcome barriers:

– Transparency. Aggressive and ongoing public monitoring of the pace of development and use of network mechanisms through collection of API usage data and development of an adoption evaluation framework to facilitate Public API-based exchange

– Guidance. Issuing authoritative, ongoing guidance to provide industry-wide direction and benchmarks, and to encourage specific actions for the development of DSNs and the Coordinated Architecture

– Organization. Convening existing exchange networks (i.e., prospective DSNs) to catalyze adoption of the Public API and development of industry-based governance mechanisms

– Incentive alignment. Aligning incentive programs and existing regulatory processes to stimulate use of the Public APIs, such as ACO contracts, LTPAC regulation, lab regulation, etc

– Federal operational alignment. Requiring federal healthcare entities to adopt the Public APIs in their technology procurement activities and day-to-day market interactions, such as Medicare/Medicaid, Department of Defense, Department of Veterans Affairs, Indian Health Services, NASA, etc.

• Recommendation: Federal government should consider taking the following steps to enable orchestration of Core Services across the DSNs:

– DSN bridging standards. Developing voluntary standards for vendor-neutral, cross-DSN bridging to fully enable the narrow set of robust transactions required for the loosely coupled architecture (such as patient identity reconciliation, authorization/authentication, key management, etc)

– Nationwide shared services. Developing standards for, and ensuring deployment of, universally necessary shared services that are highly sought after and thus would facilitate DSN alignment, such as public use licensed vocabularies, and perhaps nationwide healthcare provider and entity directories, etc.

• Recommendation: The government may choose to consider direct regulation of DSNs in the event that the market does not develop effective coordination mechanisms

– Such actions would involve a significant increase in the government's regulatory authority over health information exchange activities, which would have high risk of unintended consequences that could slow market progress.

– Any such increase in regulatory authority should be carefully considered through evaluation of reasonable and meaningful benchmarks, and specifically calibrated to address any remaining barriers that the market has failed to overcome. 86

Congressional Testimony

87

Senate HELP Committee HIT Hearings

• June 16 - Achieving the Promise of Health Information Technology: What Can Providers and the U.S. Department of Health and Human Services Do To Improve the Electronic Health Record User Experience?

• June 10 - Health Information Exchange: A Path Towards Improving the Quality and Value of Health Care for Patients

• March 17 - America’s Health IT Transformation: Translating the Promise of Electronic Health Records Into Better Care

88