EP3 Foundation, ONC Comments : simplebooklet.com

9 EP3 Foundation They must secure informat ion, prot ect privacy, and ensu re confid entialit y while also giving in divid uals t he cap ac ity to access and aggr egat e the inf ormation they are authorized to use. Limit amount of USCDI exchanged to the limited amount necessary While we generally agree with many of the Principles for Trusted Exchange, we do not endorse the principle and accompanying TEFCA requirements that appear to require a// participants provide a// information available in the US Core Data for Interoperability to a// parties for a// the listed Permitted Purposes of treatment, payment, health care operations, public health and benefits det er min at io n. Proposed TEFCA Section 3.2 requires any Participant of a QHIN that collects and maintains EHi in the data classes included in the then current USCDI to fulfill a request for information to the extent the EHi is available. The proposal then qualified these requirements with a general statement that the disclosure is only required to the extent it would be permitted under applicable law. Under this approach, it would be easy for participants and users to erroneously presume or conclude that the disclosure of all data elements of the USCDI would be appropriate for all Permitted Purposes. However, this would not be an accurate interpretation of the law. The Framework should expressly call out HIPAA's minimum necessary as a constraining factor in releasing EHi in the USCDI. The HIPAA Pr ivacy Rule requires that uses, disclosures and requests for protected health information should be the limited to the minimum amount necessary to accomplish the purpose of the release. Se vera l of the listed Permitted Purposes, (e.g., many health care operations) could be accomplished wit h the disclosure of limited data sets (as defined under the HIPAA Pr ivacy Rule) or other pseu donymized or obfuscated data. Greater emphasis should be placed on the fact that QHINs, Participants and End Users may only exchange the minimum amount of information necessary for any specific Permitted Purpose. It should also be made clear that it is not appropriate to presume that the release of a// USCDI data elements is necessary or appropriate for a// Permitted Purposes.7 The "all or nothing" approach to exchanging data should be discarded in favor of in novat ive approaches that facilitate the secure exchange of a limited amount of data that is useful for recipients. As an example, EP3 Foundation and its participating ecos yst em partners have been pioneering breakthrough in novat io n including Quantum Pr ivacy, the Proof-of-Trust BlockChain and the Unified Trust Model which eliminates the under lying conflict bet ween privacy and sharing inherent in traditional approaches. 7) We have heard allegat io ns that some healt h in for matio n exchanges assume that the release of a pat ient's entire record meets t he minimum necessary standard for purposes other than treatment. The Fr amework should not perpet uat e this alleged behavio r.

Page 10

Page 11

Page 12

12 February, 2078 We believe that forward-thinking innovations are critical to achieve interoperability and realize Congress' vision of empowering every individual to use their electronic health information to the fullest extent and to allow providers and communities to deliver smarter, safer, and more efficient care. In the light of this, the EP3 Foundation has designed an innovation checklist that reflects the challenges already existing in the exchange of health information and serves as a guide to identify the policies, practices, and technologies that build ● financial sustainability and cost to participating organizations and individuals. ● ability to achieve real-world data liquidity that supports both pat ien t-ce nter ed care and population analytics. ● ability to access, link and reconcile comprehensive records about patients including clinical and administrative data, genomics (and trusted, interoperable networks. (Appendix A) other -omics), device data, behavior, lifestyle and social determinants of health We believe that new approaches and innovations are required for the goals of the Cures Act to be realized and the trusted exchange framework operational. Innovation cannot emerge from the consensus of incumbents or from top-down centralized planning processes. Therefore, selecting a single RCE will likely eliminate the catalyst of competition and the diversity of approaches essential to successful innovations. With that in mind, we recommend that instead of selecting a single entity, ONC should establish a process where multiple organizations or consortia are selected to function as RCEs, allowing them to compete to recruit participants and collaborate in designing and implementing QHINs and Connectivity Brokers. The ONC would then establish a process for rigorously evaluating the resulting approaches, along with their QHINs and Connectivity Brokers. This evaluation must be based on assessment criteria based on the desired capabilities and principles for the Cures Act, as opposed to whether the implementation conformed to any particular technology approach assumed by an RCE or the ONC. ● trustworthy enforcement of security, privacy, regulatory compliance and commercial rights of all participants ● costs to develop, operate, and access by various stakeholders (patients, clinicians, providers, government agencies, vendors, etc.) ● the ability to authorize access to trusted parties to sensitive health information and to securely share that information across healthcare providers and systems. We believe that new data paradigms and technologies offer actionable health data. It is possible for patients, providers, and communities to find and aggregate the comprehensive data needed to improve health outcomes and maximize efficiencies. To illustrate the essential elements to enable nationwide interoperability and real-time, actionable health data, we have included our Interoperable Health Networks Design Criteria and Checklist. (Appendix B) These criteria should be tied to the metrics that matter: ● architectural openness, support for competitive marketplace for services.

Page 13

Page 14

14 APPENDIX A Yes No 1 Empower Individuals Improve patients ability to coordinate their own care? Not limited to what is stored in electronic health records? Access Data from different sources (including technologies that individuals use every day)? Enable individuals to access and aggregate longitudinal data? 2 Enable Providers and Communities Improve patient and provider safety? Increase efficiency? Gather and aggregate comprehensive data from many sources? Provide a common method for authenticating trusted health information network participants? 3 Public and Population Health Provide real-time, quality data collection? Deliver real-time actionable data? Provide privacy-protected, secure access to comprehensive health information? 4 Open and Accessible APIs Does it enable open and accessible application programming interfaces (APIs) Is it user-focused innovation to make health information more accessible? Does it improve electronic health record (EHR) usability?

Page 15

Page 16

16 1. DESIGN CRITERIA FOR NATIONWIDE PERSONAL HEALTH NETWORK ❑ A. Must have an open, modular and distributed network architecture that is capable of dynamically linking together and displaying disparate data sources, security and policy enforcement mechanisms, decision support and analytic services, messaging tools, user interface modules, and portals. Must support the use of modules and services from different vendors that may be based upon different technology platforms, data standards and APIs and programmatic interfaces, and hosted in different physical locations by different organizations. ❑ B. Must incorporate shared cloud-based governance and policy enforcement mechanisms capable of privacy-preserving attribute level cross-organizational security and privacy compliance, commercial rights management and access authorization across organizations with disparate technology infrastructure and policies, as follows: ❑ i. Must be capable of supporting end-to-end policy and regulatory compliance enforcement spanning data ingestion, data transformation, record linking and reconciliation, population analytics, process orchestration and access authorization. ❑ ii. Must be accredited and/or certified for compliance with diverse regulatory requirements including, at a minimum, HIPAA, FERPA, GLBA, CFR 42-2 and IRS 6103) by nationally recognized industry collaboratives or non-profit governance organizations, and/or have regulatory compliance mechanisms that are FISMA or FedRAMP certified for end-to-end privacy and security protection. Such accreditations and/or certifications must provide robust assurance to participating organizations and individuals that they can safely share data with the network and rely upon it to authorize access to privacy sensitive and regulated data and any derived outputs without exposing themselves to undue regulatory compliance liabilities, nor allowing data to be diverted or re-used for unauthorized purposes. ❑ iii. Must allow disparate organizations and individuals to safely share, combine, transform and analyze privacy sensitive, regulated and proprietary data into comprehensive longitudinal profiles and datasets, without risking privacy or security or regulatory compliance of participants. The objective is to enable cost-effective support for patient-centered, personalized health, precision health and population analytics on a nationwide scale, while ensuring that data cannot be diverted or re-used without authorization, and without forcing participants to incur excessive integration, legal or compliance costs. ❑ C. Must incorporate network-based mechanisms to authenticate users; proof their identities, credentials, and relationships, verify record matches, and to discover and authorize access to patient records or application functionality across disparate systems and organizations, and to do so on demand on a nationwide scale. This capability must include the following properties: ❑ (i) Must support diverse network-based services and mechanisms for authentication, identity proofing, identity matching, credential verification, cybersecurity surveillance, records retention, disclosure management, discovery, consent and authorization. Must be interoperable and extensible with additional similar mechanisms via standard interfaces, including OpenID, OAuth, SAML, etc. ❑ (ii) Must be capable of dynamically combining multiple authentication services, identity providers, identity matching algorithms and credential verification services when authenticating and authorizing access by a user in order to support higher assurance levels, enable convenient and reliable access by a nationwide user population, provide fault tolerance, and protect against breaches by fraudulent organizations or insiders. ❑ (iii) Must support the ability to dynamically escalate to stronger authentication and identity or attribute proofing if risk factors for security breach or inappropriate use are detected, and the ability to create audit trails including biometric signatures (such as voice recordings, fingerprints or pictures) that are sufficiently strong to support prosecution if fraud or abuse is detected. ❑ (iv) Must support use of cloud-based, auditable mechanisms to accurately match the identity of the online users and records across disparate organizations, systems and devices. This must support a distributed network of data sources and identity matching algorithms, so as to accommodate different and changing identifiers for the same people. ❑ (v) Must support cloud-based patient consent services that can authorize access and use of patient data from disparate organizations, applications and devices that have different identity information for the patient and/or the online user.

Page 17

17 ❑ (vi) Must support convenient, on-demand provisioning of new users via email, phone or fax numbers, so that the network can grow virally based on messages or referrals sent by existing users or based on existing user identity databases. ❑ (vii) Must have the ability to support adoption and use by individual clinicians, patients and researchers using standard web browsers and mobile apps, without the active support or participation of the provider organizations they work for. ❑ D. Must enable use of cloud-based privacy-preserving mechanisms that allow patient data from disparate sources to be aggregated, linked and reconciled to support population-scale analysis of comprehensive patient longitudinal records from disparate sources and type. This must include: ❑ i) Support for network-based services capable of translating between different terminologies and record formats so that disparate clinical, claims, laboratory, prescriptions, genomic, demographic and behavioral and other records can be meaningfully compared and analyzed. ❑ ii) Offer robust protection of patient privacy including the capability of obfuscating/de-identifying and selectively re-identifying/de-obfuscating source data, as well as segregating or filtering sensitive information like mental health records or genomic sequencing data. ❑ iii) Offer the ability to persistently link security, privacy and other policies to data at the attribute level, so that specified policies are enforced upon any aggregated datasets or analytic results that derived from source data 2. QUALIFIED NETWORK CRITERIA The Secretary shall establish an objective, evidence-based, multi-stakeholder process for assessing, certifying and rating the performance of vendor products, and enabling services for compliance with Qualified Network Criteria. The Secretary shall provide funding for vendor neutral assessment methodologies, rating schemes and certification programs, and sponsor proof-of-concept pilots to support incubation and validation of Qualified Network enabling technology, and create financial incentives for vendors to develop Qualified Networks and enabling services in a competitive marketplace. Under this Act, a ‘Qualified Network’ is one that is architecturally capable of supporting patient-centered, consumer-directed, value-based care, precision health and pre-emptive fraud prevention, and other services described in Section 3 of this Act. Specifically, a ‘Qualified Network' must satisfy the following criteria: ❑ A. Must have an open, modular and distributed network architecture that is capable of dynamically linking together and displaying disparate data sources, security and policy enforcement mechanisms, authentication and identity matching services, decision support and analytic services, messaging tools, user interface modules, mobile apps, devices and portals. The network must support the use of modules and services from different vendors that may be based upon different technology platforms, data standards and programming interfaces, and hosted in different physical locations by different organizations. ❑ B. Must have open interfaces and licensing terms that allow for data sharing and messaging with users of other networks and applications, and interoperation with data sources, security services, and software modules from other vendors and service providers. This provision is intended to promote open competition, modularity and ongoing innovation in technology and business models, not to pursue interoperability through compliance with government mandated standards. ❑ C. Must be capable of conveniently authenticating, proofing and matching the identity, credentials and attributes of patients, clinicians, staff and caregivers on a nationwide scale. This capability must include the following properties: ❑ i. Support for diverse network-based services and mechanisms for authentication, identity proofing, identity matching, credential verification, cybersecurity surveillance, consent and authorization management. ❑ ii. Have the ability to dynamically combine multiple authentication services, identity providers, and credential verification services when authenticating a user in order to support higher assurance levels, provide fault tolerance, and protect against breaches by fraudulent organizations or insiders. ❑ iii. Support convenient, on-demand provisioning of new users via email, phone or fax numbers, so that the network can grow virally based on messages or referrals from existing users.

Page 18

18 ❑ iv. Must have the ability to support adoption and use by individual patients, caregivers and clinicians using standard web browsers and messaging clients. ❑ v. Support online privacy preserving screening of users for fraud risk and criminal backgrounds. ❑ D. Must be capable of enforcing robust privacy, security, rights management and compliance policies on all patient information and messages flowing through the network, including: ❑ i. A way to persistently link enforceable policy requirements to patient data that can be enforced by independent network services, as opposed to relying solely upon enforcement by the recipient’s application or administrative practices. ❑ ii. Offer secure, privacy preserving shared mechanisms for a patient to access their own records, to restrict or authorize access by others, and for being notified or reviewing audit logs describing when their records are accessed, by whom, and for what purpose. ❑ iii. Offer robust mechanisms for anonymizing, encrypting and obfuscating patient records from disparate sources so that they can be aggregated into population scale longitudinal records and analyzed without jeopardizing privacy, security or rights management. ❑ iv. Support neutral, privacy-preserving cloud-based shared mechanisms for records retention, disclosure management, and cybersecurity surveillance.

EP3 Foundation, ONC Comments

Page 1

Page 2

Page 3

Page 4

Page 5

Page 6

Page 7

Page 8

Page 9