Interoperability Roadmap Public Comments

Uploaded

BCBSA would like to thank the Office of the National Coordinator for this opportunity to comment on CONNECTING HEALTH AND CARE FOR THE NATION: A SHARED NATIONWIDE INTEROPERABILITY ROADMAP (DRAFT VERSION 1.0). Our comments in letter form are attached.

1. General:

The actions proposed in the roadmap are the right actions to improve interoperability in the near term. Overall, the short-term actions seem appropriate to energize and increase public/private national participation in HealthIT interoperability. In keeping with the general industry trend of improving quality of care, engaging patients and reducing cost using HealthIT as a vehicle, the strategies were appropriate. Overall, the target of the short-term actions point towards enforcing behavioral changes and removing current barriers to interoperability through public-private collaborative governance, better alignment of stakeholders’ policies, standards and practices. For example, getting federal agencies to change and align their policies to efforts on the roadmap is a good strategy to increase compliance across the board. In addition, the alternative payment methodology that will allow 30% of Medicare payments to providers be based on quality and value by 2016, 90% of fee-for-service Medicare payments aligned with clinical quality measures by 2018, and 50% of all supporting care coordination are good measures that could reinforce providers’ behavior towards demonstrating quality and value through interoperability.
Learning Health System as a long term strategy is an innovative approach that with great deal of coordination and trust is achievable over a long period of time, possible exceeding 10 years duration. Given that the health care system in the United States is complex with multiple ecosystems, it will be imperative that trust is fostered across the spectrum for the learning health system to be effective. Private entities must be able to trust and collaborate with governmental entities in reaching decisions meaning that the government will need to use less of a top-down legislative approach. In contrast, top-down approach’s desirability is in effecting change. The two approaches should be reconciled. Another way to achieve trust is to focus on creating sub- learning systems within each ecosystem and then abstracting common standards for application across the industry to avoid further overwhelming an already overloaded system.

Gaps to be addressed
In theory, the short-term actions in the road map can be effective if successfully implemented. However, there needs to be more information on ‘how’ and ‘who’ will ensure the success of implementation. Below are additional gaps that should be addressed.

a) In what ways would the ONC ensure that “independent” federal agencies policy align with the interoperability roadmap? Would there be an overarching body with the authority to effect the policy changes being proposed?
b) ONC will need to ensure that stakeholders across healthIT ecosystems have equal footing in the collective decision making between competing policies, business interests, and standards. The use of a decision-making body might be appropriate.
c) The cultural change expected of providers in building block D will take time to materialize. The plan calls for providers and their organizations to include interoperability requirements in the contract they sign with developers. Even when this is done, it is possible that the technological tool may be at the infancy state or new standards are implemented post contract. Developers that met previous interoperability standards may become incapable of meeting new ones due to the time it takes to develop new technical tools. Providers and their organizations should be able to trust that ONC certified vendors/developers meet the interoperability standards. Providers’ due diligence should be limited to ensuring the developers they contract with have up-to-date certification. New standards should be provided ample time to mature before becoming mandatory.

Appropriateness of timing
In general the three-year estimate for each arm of the short-term stages is constricted and rushed. ONC should extend the timelines. Given that the Affordable Care Act (ACA) has been in establishment since 2009 with consistent and continuous work towards using information technology to achieve Meaningful Use, yet, there are still many challenges. In what ways can some of the short-term actions be done in a shorter time period? For instance, activities like the creation and adoption of policies, and driving consumer choice toward advocating for healthIT by selecting providers that have advanced IT-enabled functions take time. Before consumers can become healthIT advocate, they must first independently understand healthIT, buy-in to the value of healthIT, and guaranteed the privacy and security of their health information in an age of increased cyber-attack. Patients, especially the older strata of the population may not be independently persuaded to change a provider that has a sub-standard IT system as advanced IT may not equate to better care to them.
In addition, ICD-10, and Meaningful Use stage 3 are additional ongoing initiatives with similar timelines. A recent survey on healthcare purchasing showed that over 30% of respondent hospitals are planning on switching vendors in 2015 with implementation possibly going into 2017. All of these initiatives are constraints on providers and consumers resource.

Associating the right actors/stakeholders with critical actions
The right actors are associated with the right actions. The bigger issue of concern is ensuring that the actors have the tools, influence and the ability to make the necessary changes in the time frame assigned.

2. Priority Use Cases
Rationale for the top 3(three) use cases
Out of the 56 use cases, the following 3 have been selected by KHIE. The selected use cases are the core use functions of interoperability which are 1) data exchange across systems that makes the data available at the provider level and integrated into their workflow, 2) access to health information at the patient level (as opposed to raw data that patients may not understand), and 3) data availability at the societal level for cost reduction and population health management. Other use cases listed are also important. However, for a national initiative, it is critical that the core use cases stay true to the mission and vision of the inception of interoperability, which is to have the right data available for the right patient at the right time, even in emergency situations. Some of these use cases are complimentary and should be combined. Whenever such is the case, KHIE has taken the liberty to combine them.

1) Public health agencies routinely use data derived from standards -based connections with HIEs and EHRs and uses it to plan investments in public health activities. These public health activities include population health management utilizing data from all relevant sources on each patient (including information on births, deaths and occupational health hazards) and is accessible to providers and other population health stakeholders (#1 and #50 combined ).
2) Emergency medical providers have the ability to query data from other sources while managing chronically ill patients after a disaster regardless of geography or what network the data resides in (#49).
3) Patients have the ability to access their holistic longitudinal health record when and where needed.

3. Governance

Without a coordinated effort, chances are that will be a few public-private governance organizations forming as a result of the call-to-action for the roadmap. The challenge then becomes how to select the best one that should represent all healthcare ecosystems. Too many sticks in the fire may be divisive, time wasting and may send contradictory message to the same industry that ONC is seeking to unify. Instead of waiting to identify an industry-led governance effort, ONC should be the conduit for the creation of an industry-led governance group where all stakeholders can contribute to directly or through sub-ecosystems. This way, concerted efforts would benefit the outcomes and the timeframe of the roadmap objectives.
The level of authority that the governance framework will have should be pre-established. ONC would need to further clarify whether the governance structure would be formal or informal. For example, an advisory group providing recommendations on learning systems may not have the power to effect the type of change that a formal governance organization on interoperability could. The long term success of roadmap is dependent on the governance framework. The governance body must be able to achieve results to avoid losing stakeholders interests.

4. Supportive Business, Cultural, Clinical and Regulatory

Private health plans and purchasers have financial interests in breaching gaps in healthcare quality and in value-based payments. Interoperability with bidirectional exchange between payers and providers will support the send, find or receipt of common clinical data list in real time. Real time availability of clinical data set can be used to automate authorization of care in situations where clinical information is needed, it can decrease waste in repetitive services cost, and help mitigate cost of frequent users of ER through the initiatives that Health Information Exchanges (HIEs) in the nation are developing. It makes good business sense for private payers to identify frequent ER users as a risks management strategy to reduce cost since these small percentage of consumers will have higher cost of care that are preventable through case management or enrollment in a patient centered medical home. Private payers will need to support providers to send, find or receive common clinical data to achieve the benefits stated.

Furthermore, encouraging the sharing of information across the continuum of care would reduce re-admissions and enhance smoother transitions of care. The periodic review of medical records that private payers do can be done electronically, which also will reduce expenses to the private payers.

Private payers should align with federal policies and reinforce adoption of standards and certification. The alignment of interoperability initiatives and private payers’ business model is a critical success factor. Private payers’ payment model, especially those with Medicare and Medicaid related products should foster interoperability and not create competition that may jeopardize interoperability efforts.

In addition, there should be a way to incentivize private payers to support send, find or receive common clinical data across the care continuum of their commercial products as a way to drive positive behavior. ONC should not assume that independent private payers will change their business models to promote interoperability without incentives.

ONC should cautiously approach two of the roadmap’s recommendations. One, the recommendation that “payers make the adoption of certified health IT systems or demonstration of interoperability a condition of participation for providers that wish to take part in insurance programs” and two, that consumers be incentivized to choose providers within their networks that have advanced IT-enabled capabilities around care coordination.” The two recommendations are great but they assume that 1) providers’ choice is a barrier to interoperability and 2) that consumers will respond to the nudge of interoperability from an outside entity they don’t trust. The recommendations failed to recognize that providers may have certified HealthIT systems, but the vendor may not have functioning interoperability services. Due to the nature of relationship patients have with their providers, consumers may still choose to stay with their provider of choice. Importantly, the opinion of providers can shape the opinion of consumers/patients as most consumers still hold their providers’ in high regard. Instead of asking consumers to pick providers with certified HealthIT systems, efforts should be on vendors and developers to ensure that the certified HealthIT systems function as expected at the point of care, enabling the flow of information and adding value to providers work flow. Providers are more effective advocate in driving patients/consumers engagement in HealthIT than payers or governmental agencies would be because of existing political perceptions of payers and the government.

5. Privacy and Security Protections for Health Information

• Predefined security methods as REST lacks a well-articulated security model. Address the security vulnerability of APIs associated with RESTful.
• Level of encryption
• Provide guidelines and standards on use of certificates for authentication using web tokens
• Provide guidelines on the implementation of authorizations

6 Core Technical Standards and Functions

a) Care plan field and narrative are areas that can be further standardized.

b) Accurate Individual Data Matching will sufficiently address the industry needs and address current barriers?

The approaches proposed are ideal to increase patient data matching and quality. The measurement of the accuracy of the present patient identity processes to identify where improvements are needed, standardization of data elements and development of best practices for the improvement of data quality at the time of registration are good foundational steps.

7. Certification and Testing
ONC should emphasis more on qualitative measurement of interoperability from the users’ perspective. If the need for interoperability is to ensure that the right information is available at the right time, then, it becomes imperative to measure semantic interoperability at the point of care or at the point of use. Performance metrics that determine the degree to which the information received met the intended needs should be the focus of evaluation. Quantitatively performance measurement of semantic interoperability should be done to determine the degree to which the data content of CCD and/or CCDA are parsed and consumed by the receiving applications. Furthermore, during certification process, robust but measurable grading metrics around semantics should be included. This will help ensure that each vendor’s certification is vetted. ONC should leverage the newly formed joint certification and testing model for IHE profile (across organization and state boundaries) collaboration between IWG, HIMSS and ICSA labs as an example of a vehicle to accomplish this objective.

8. Measurement
a) Yes
b) Of the measures mentioned on the roadmap, the ‘impact’ of interoperability on better health quality and cost should be the most important. Interoperability is a means to an end; to impact cost and quality of care. As such it is appropriate that the impact of interoperability on cost and quality should be included in the measurement.
c) Use cases
d) ONC should leverage successful practices from local or regional initiatives regarding care transitions, readmissions, and ED visits that have proven to increase quality of life and replicate on the national level.
e) Certification and testing, and maturity of technology: ONC should ensure that vendors obtaining certification have products that are functional. ONC should also create reasonable timeline to allow for one standard to mature before rolling out new standards.
f) Public Health registries are wealth of information. Immunization, Syndromic surveillance, Cancer registries, and reportable diseases through the Centers for Disease Control and Prevention (CDC) are important data sources that have been in existence for decades and that have been improved under the ACA. Clinical analytics of these data should be one of ONC next focus. That way, the data that are already available are being used.
g) Health Information Exchange, Regional Extension Centers are available additional resources that can be used to address measurement of interoperability gaps. For example, Kentucky Health Information Exchange as a state designated public health agent (PHA) assists providers connect to up-to-date technology. Providers are not responsible for procuring the latest technology themselves as long as their vendors have the ability to connect; the providers are able to connect as well.
h) Data process should flow from private vendors to state entities and then from the state to the national level.
i) Howbeit imperfect, the following are some examples of short-term and long-term ways to measure impact:
1) Opinion poll (providers). Use this tool to measure the semantic of data content received e.g. CCDA at the point of care based on providers’ perspective.
2) Claims data and providers financial performance: ascertain whether providers with advanced IT-enabled capabilities around care coordination have reduced claims/per patient which will demonstrate that they are accessing and utilizing already available information on patients as opposed to reworking.
3) Provider productivity: Are doctors seeing more patients in the day because the average time spent per visit is reduced due to technology? Measure provider volume/day before and after IT adoption and interoperability initiatives.
4) Certification and Testing: what percent of 2014 certified vendors have problems connecting to HIEs or national registries? Measure the efficacy of the current technological tools to achieve the desired outcomes.
5) Public health registries: analyze the quality of data in the national registries.

Forum Systems Synopsis of Attached Response:

LHS Requirement

E. Ubiquitous, secure network infrastructure: Enabling an interoperable, learning health system requires a stable, secure, widely available network capability that supports vendor-neutral protocols and a wide variety of core services.

API Security Gateway technology is inherently vendor-neutral, supporting of a broad diversity of vendor specific formats so as to facilitate simplified brokering of system information without the overhead of tightly coupling disparate systems together. The secure portion aligns directly with the API Security Gateway capabilities to secure the protocol channels via SSL/TLS and the message-level information with PKI encryption, SSH encryption, and PGP encryption for data security in motion and at-rest. Network security is further ensured with API Security Gateway technology that has achieved FIPS 140-2 and NDPP certifications to ensure no ability to compromise the gateway systems themselves.

Cyberattacks are the additional consideration in this area, which is what the Security in API Security Gateway is comprised of. The API Security Gateway threat mitigation and deep-content inspection technology protects information flows from data breaches and cyberattack with unique content-specific attack vector analysis and detection technology.

 
LHS Requirement

F. Verifiable identity and authentication of all participants: Legal requirements and cultural norms dictate that participants be known, so that access to data and services is appropriate. This is a requirement for all participants in a learning health system regardless of role (individual/patient, provider, technician, etc.)

There is a physical and logical component to this item. API Security Gateway technology handles the logical component of identity token variant consolidation and unification of identity from the myriad of technologies across the on-premise and cloud landscapes to mobile, desktop, and smart-devices. The ability for the API Security Gateway to unify identity ensures that the concepts of role-based, attribute-based, and content-based access control can be applied. This is essential in the realm of HHS where participant sensitivity to data access and information is paramount. The API Security Gateway combines modern technologies of single-factor, mutli-factor, PKI-based, SAML-Based, and OAuth-based authentication as core aspects of the unification abilities.

LHS Requirement

G. Consistent representation of permission to collect, share and use identifiable health information: Though legal requirements differ across the states, nationwide interoperability requires a consistent way to represent an individual's permission to collect, share and use their individually identifiable health information, including with whom and for what purpose(s).

Achievement of this area is known in the logical access world as ABAC, attribute-based access control. This is an extensible means to aggregate the types of permissions and roles that an identified subject, device, or system is entitled to which then is used to build the policies of enablement and sharing. API Security Gateway technology is an ABAC engine allowing interoperability to also be a guiding factor to achieving a common representation of permissions even if the disparate systems are not prepared, or technically capable of achieving this on their own.

LHS Requirement

H. Consistent representation of authorization to access health information: When coupled with identity verification, this allows consistent decisions to be made by systems about access to information.

Achievement of this area is known in the logical access world as ABAC, attribute-based access control. This is an extensible means to aggregate the types of permissions and roles that an identified subject, device, or system is entitled to which then is used to build the policies of enablement and sharing. API Security Gateway technology is an ABAC engine allowing interoperability to also be a guiding factor to achieving a common representation of permissions even if the disparate systems are not prepared, or technically capable of achieving this on their own.

LHS Requirement

I. Stakeholder assurance that health IT is interoperable: Stakeholders that purchase and use health IT must have a reasonable assurance that what they are purchasing can interoperate with other systems.

A principled approach of adoption of API Security Gateways gives this assurance as the founding principles of this technology and the modernization capabilities achieve a posture of vendor-agnostic standards-based integration optimization, reduction of vendor-lock and proprietary solutions, and decouples the complexities of identity, access-control, and data security from the applications layers and builds this into an interoperability-layer (the gateway itself) whereby these patterns and principles are repeatable and agile.

LHS Requirement

J. Consistent Data Formats and Semantics: Common formats (as few as necessary to meet the needs of learning health system participants) are the bedrock of successful interoperability. Systems that send and receive information generate these common formats themselves or with the assistance of interface engines or intermediaries (e.g., HIOs, clearinghouses, third-party services.) The meaning of information must be maintained and consistently understood as it travels from participant to participant. Systems that send and receive information may or may not store standard values natively and therefore may rely on translation services provided at various points along the way.

Defining standards and driving adherence is one strategy to achieve higher consistency, but often systems are gated by their own limitations, either technical or cost-prohibitive. This is where the capabilities of data mediation and data conversions of API Security Gateway technology enable presentation of APIs that are defined, standard, and modern while in-turn converting those data streams and formats for vintage systems to align with the new common formats.

LHS Requirement

K. Standard, secure services: Services should be modular, secure and standards-based wherever possible.

This is the precise concept of Secure API Agility. Services are communicated with via their APIs. These APIs should be extensible, agile, and secure. It should not solely be the role of the service provider to try and build all these concepts and design principles into the end-mile service layer. Rather, the approach is the build these principles in the API layer that exposes these services. This enables much more streamlined agility in the development and maintenance of the services, while still maintaining the security posture and diverse interoperability concepts at the API layer where the consumers access the service. This is the fundamental principle of the API Security Gateway.
 
L. Consistent, secure transport technique(s): Interoperability requires transport techniques that are vendor-neutral, easy to configure and widely and consistently used. The fewest number of protocols necessary to fulfill the needs of learning health system participants is most desirable.

Driving adherence is one strategy to achieve higher consistency, but often these systems are limited by technology and cost to try and alter the underlying technology baselines to achieve modern secure formats. A great example of this is Heartbleed and OpenSSL. Over 2/3 of the entire internet remains exposed to vulnerabilities imposed by these c-based security library approaches to transport security. API Security Technology is not based on OpenSLL or C-based libraries and can thus expose the communication point to these services through consistent, secure transport, and then translate the protocol what the back-end systems can consume and understand.

Please see attached comments.

April 3, 2015

Dr. Karen DeSalvo
Office of the National Coordinator for Health Information Technology
U.S. Department of Health and Human Services
200 Independence Avenue S.W.
Suite 729-D
Washington, D.C. 20201

Dear Dr. DeSalvo,

Please accept this letter on behalf of Magee Rehabilitation Hospital (Magee) in response to your request for public comments to the Office of the National Coordinator (ONC) for Health Information Technology’s publication of the first draft of “Connecting Health and Care for the Nation – A Shared Nationwide Interoperability Roadmap” (Version 1.0). Thank you for the opportunity to comment.

Magee looks forward to future versions of this document and appreciates the opportunity to provide feedback. Our hospital is an independent, 96-bed, post-acute nonprofit inpatient rehabilitation facility that provides physical and cognitive rehabilitation services to the Greater Philadelphia community. We employ over 600 staff, and Magee is nationally recognized for outstanding programs in physical and cognitive rehabilitation. Our organization has comprehensive services for spinal cord injury, brain injury, stroke, orthopedic replacement, and amputation. Magee, in conjunction with Thomas Jefferson University Hospital, serves as the federally designated Regional Spinal Cord Injury Center of the Delaware Valley. Only 14 such centers exist in the country. Magee is also a founding member of The Christopher and Dana Reeve Foundation NeuroRecovery Network, which provides state of the art rehabilitation therapy.

We commend ONC’s continued dedication to the expansion of, and improvements to, our nation’s health IT ecosystem. Generally, we are in agreement with the actions identified by ONC in order to ensure a majority of individuals and providers across the care continuum are able to utilize common and compatible sets of electronic information. We are also appreciative of ONC’s ambitious goals and timelines. That being said, we would like to offer a few suggested changes to the report, emanating from challenges and experiences we have had in our attempts, as an independently owned, post-acute rehabilitation facility, to participate in an increasingly interoperable health IT ecosystem.

Firstly, on page 21 of the report, under the section “Who is this Roadmap For?,” the report includes a breakdown of stakeholders in order to denote “which stakeholder groups are best positioned to take on critical action.” Under “people and organizations that deliver care and services” subsection, we believe that post-acute facilities should be listed. Post-acute inpatient rehabilitation facilities, such as Magee, are not currently eligible to participate in the Electronic Health Records (HER) meaningful use program; nonetheless, we remain key stakeholders in the continuum of healthcare and national attempts to improve health IT interoperability. We understand that this report is unable to focus on technology adoption. However, its broader goals will only be met if segments of the health care industry that have been presently excluded by policymakers from government financed EHR incentive programs are explicitly recognized as important participants in EHR expansion and interoperability.

Secondly, on page 39 for the report under the section titled “Supportive Business, Clinical, Cultural and Regulatory Environments,” ONC also correctly identifies the need for a shift towards “value-based and person-centered health systems” that reward positive patient health outcomes. Magee, as a post-acute facility, strongly favors interoperable systems that span the entire continuum of healthcare so that we can easily and effectively communicate with acute care facilities and primary care physicians to improve care and reduce costs. Achieving this goal is another area where expansion of EHR incentives would have great benefit. In the present environment, post-acute health organizations are not required or encouraged to adopt certified EHR systems and therefore fall outside the regulatory oversight and guidance created to produce a truly interoperable ecosystem.

We believe that financial ability of all providers to acquire the necessary technology is essential in discussions of the “Support Business, Clinical, Cultural and Regulatory Environments” section and that including post-acute facilities will strengthen the goal to achieve interoperability. In addition, we believe there remains a significant risk of creating marked inefficiencies if post-acute providers are not included in early stages of discussions related to mapping the road ahead for interoperability. Since post-acute will, necessarily, be part of interoperability, better planning will be achieved if post-acute perspectives are brought into the discussions at early stages so that post-acute EHR needs can be identified, planned for and anticipated.
Overall, Magee Rehabilitation is very appreciative of the work being done by ONC to improve interoperability. Magee also encourages ONC to broaden its discussion in this report to highlight post-acute organizations and their inability to benefit from government incentives to adopt EHR systems. The exclusion of post-acute facilities from EHR incentive programs will have serious long-term repercussions in achieving the goal of an interoperable health IT ecosystem.

We thank ONC for its extensive interoperability roadmap and its ambitious goals. We also thank ONC for the opportunity afforded to us to comment on the report. Should you have any questions or require further clarifications, please do not hesitate to contact Magee Rehabilitation’s Chief Information and Infrastructure Officer and Corporate Compliance Officer, Travis Gathright by email at TGathright@mageerehab.org or by phone at 215-587-3463.

Respectfully Submitted,

Travis Gathright, MHA

This is a good first step in moving the Nation to a Nationwide standard. We look forward to working with ONC to get the next version as detailed and specific as possible.

Please see attached.

See attached

Please see attached consensus comments in response to the draft Interoperability Roadmap, on behalf of the following stakeholders:

ACT | The App Association
American Association for Respiratory Care
American Telemedicine Association
Baxter Corporation
Biocom
Christus Health
Intel
Panasonic Corporation of North America
Personal Connected Health Alliance
Qualcomm
Telecommunications Industry Association
Underwriters Laboratories

Please contact us if we can be of any further assistance to ONC in this matter.

Sincerely,

Brian Scarpelli
Director, Government Affairs
Telecommunications Industry Association (TIA)
d: 703.907.7714 | m: 517.507.1446
BScarpelli@tiaonline.org | tiaonline.org