JillDeGraff
commented
5 years ago Closed JillDeGraff closed 5 years ago
JillDeGraff
commented
5 years ago JillDeGraff
commented
5 years ago Proposes 6 deregulatory actions to reduce burden for health IT developers, providers and other stakeholders, outlined in Section III.B
Proposes emphasis on capabilities with related standards and implementation specs to fulfill purposes of proposed regulation
JillDeGraff
commented
5 years ago ONC proposes removal of certain 2015 Edition Certification Criteria and Standards to reduce burden and costs for HIT developers and health care providers. They would be removed upon the effective date of any final rule. ONC welcomes comment on the items proposed for removal, and recommendations for any other criteria or standards that it should consider for removal.
Justifications given for removing these certification criteria are summarized below:
i. Remove the "problem list" certification criterion from Section 170.315(a)(6) ii. Remove the "medication list" certification criterion from Section 170.315(a)(7). To be replaced by RxNorm as part of the USCDI. iii. Remove the "medication allergy list" certification criterion from Section 170.315(a)(8). To be replaced by RxNorm as part of the USCDI. iv. Remove the "smoking status" certification criterion from Section 170.315(a)(11). To be addressed in the USCDI. v. Remove the specific USCDI "smoking status" code sets, in favor of a more general representation of smoking status, in Section 170.207(h)
Remove the "drug formulary and preferred drug list checks" because it does not require any standards that facilitate interoperability.
Remove the "patient-specific education resources" certification criterion from Section 170.315(a)(13) because of advancements in the use of automation and algorithms to provide appropriate educational material to patients in a timely manner. Removal will reduce unnecessary burden in the certification process.
Remove these certification criteria from Section 170.315(b)(4) and 170.315(b)(5), respectively because of apparently limited market demand for them to be certified.
Remove "secure messaging" certfication criterion from Section 170.315((e)(2) because of multiple alternative criteria that support patient engagement and widespread integration of this capability. Also, removal will not negatively impact HIT interoperability.
JillDeGraff
commented
5 years ago Background. FDASIA required the FDA, in consultation with the ONC and FCC, to develop a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to HIT, including mobile medical apps. The FDASIA Health IT Report was delivered in April 2014. In it, the FDA recommended a single process for HIT developers/manufacturers to follow to satisfy the requirements of all agencies, and to leverage existing processes, systems and standards for patient safety in health IT. The voluntary Software Precertification (Pre-Cert) Pilot Program is implementing these recommendations.
The FDA Precert Program is notable for its orientation away from premarket reviews of specific products, in favor of a streamlined approval for mobile medical apps developed by organizations that receive organization-level certification based upon demonstrated commitments to a culture of quality, patient safety and organizational excellence.
ONC proposes that health IT developers holding a precertification under the FDA Pre-Cert Program could qualify for, and benefit from, certain efficiencies under the Program. For example, HIT developers holding a precertification under the FDA Software Pre-Cert Program could be exempt from testing and certification of its HIT to the 2015 Edition:
The ONC requests comments, as it believes some stakeholders might not agree that "recognition" of the FDA PreCert Program is the right approach.
Influenced by the FDA PreCert framework, the ONC invites comment on whether it should develop similar processes to those established for the FDA Precertification Program, by providing a pathway for some HIT developers who can meet demonstrated capabilities of excellence to have their products and services precertified, as an alternative to the current Program, which focuses on specific HIT being presented for certification.
JillDeGraff
commented
5 years ago The proposed criteria are oriented around enhancing interoperability and improving access to patient records, with an emphasis on using technical standards developed or adopted by voluntary consensus standard bodies, where practical. Preference is to avoid government-unique standard, or other standards, unless required to deliver favorable economic and/or technical outcomes
ONC proposes to use voluntary consensus standards, except in four instances:
The USCDI replaces the "Common Clinical Data Set (CCDS)" throughout the 2015 Edition. More detail in Section IV.B.1.b of the proposed rule for the USCDI's overall structure and organization.
According to the ONC, the CCDS placed a semantic constraint on the types of data classes that were being considered for interoperable exchange. USCDI re-orients the focus on data classes and data elements that should be included some of which might not be part of a CCDS.
The ONC will follow a predictable, transparent and collaborative process to expand the USCDI. After v1 is adopted, Health IT developers would be allowed to voluntarily implement and use a new version of an adopted USCDI, by following the ONC's proposed "Standards Version Advancement Process", describved in Section VII.B.5 of the proposed rule.
Standard= USCDI v1, found in proposed Section 170.213. Once adopted, health IT developers would be required to update their certified health IT support USCDI v.1. To maintain certification, HIT developers with health IT certified to any of the following certification criteria would need to plan for real world testing, and provide updated certified HIT to their cusotmers within 24 mo after effective date for the final rule:
1. "transitions of care" certification criteria (Section 170.315(b)(1)
2. "view, download and transmit to 3rd party" certification criteria (Section 170.315(e)(1))
3. "consolidated CDA creation performance" certification criteria (Section 170.315(g)(6))
4. "transmissions to public health agencies - electronic case reporting" certification criteria (Section 170.315(f)(5))
5. "application access- all data request" certification criteria (Section 170.315(g)(9)).The overall structure and organization of the USCDI standard is found at here. The ONC adopted only a modest expansion to reduce burdens of a rapidly expanding set of data classes and data elements beyond the CCDS. The delta between the CCDS and USCDI v1 is discussed below.
Baseline would equal the newest versions of the minimum standard code sets included in the CCDS available at publication of the final rule.
USCDI v1 includes data elements for address and phone number, to improve comprehensiveness of health information for patient care. Would also be consistent with the list of patient matching data elements specified in the 2015 Edition "transitions of care" certification criterion (Section 170.315(b)(1)(iii)(G), which supports exchange of patient data between providers of patient care).
USCDI v1 would make pediatric vital sign data elements mandatory (e.g. occipital frontal circumference for children less than 3 YO, BMI percentile per age and sec for youth 2-20 YO, weight for age per length and sex for children < 3 yO and reference range/scale or growth curve.) Currently, they are optional in the 2015 Edition CCDS definition.
USCDI v1 would add a new data class, titled "clinical notes", consisting of structured and unstructured data elements. The free text portion is most highly sought among clinicians because it includes assessment, diagnosis, plan of care and evaluation of plan, patient teaching and other relevant data points. As a standard, ONC proposes 8 note types, identified by Argonaut Project participants, as a minimum bar:
Provenance (author, author's time stamp and author's organization) was identified by stakeholders as valuable context for understanding when and who created data. Especially important as interoperability achieved through APIs, when a full C-CDA is no longer transmitted, but instead the pertinent data from a record is transmitted. Thus, each item of data needs provenance.
ONC requests comment on a recently published implementation guide within HL7 that provides further guidance on the UDI, specifically around real world testing and costs (for the regulatory impact analysis).
ONC requests comment on removing the Medication Allergies data element, and creating a new data class titled "Substance Reactions," which would be meant to be inclusive of "Medication Allergies".
USCDI, defined at proposed Section 170.213, establishes data policy, and does not directly associate with any content exchange standards selected by ONC in the proposed rule. ONC believes that all data classes in the USCDI v.1 can be supported by commonly used content exchange standards, like HL7 C-CDA Release 2.1 and FHIR.
ONC proposes to adopt the HL7 CDA(r) R2 IG: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1 in Section 170.205(a)(4)(i) to provide further clarity on context exchange standards, like C-CDA Release 2.1, which is part of 2015 Edition certification criteria at 170.205(a)(4). An example of how the Companion Guide provides more detailed specifications is that it specifies clinical notes to be recorded under "note activity" and the location and value set of data elements like race and ethnicity, which are required data elements in the USCDI. The C-CDA Release 2.1 alone provides some optionality or lacks specificity, which the Companion Guide may address. The Companion Guide and C-CDA Release 2.1 concern 6 certification criteria
Note that real world testing of interoperability on these criteria would have to be completed within 24 months after the final rule is effective.
Proposes a new e-prescribing standard, in line with the NCPDP SCRIPT 2017071 standard that CMS has adopted for its CMS Medicare Part D standards. See 84 Fed Reg 7424, starting at page 7444
Would remove the HL7 Quality Reporting Document Architecture standard requirement from the 2015 edition CQMs, and in its stead require that health IT certified to the CQM criteria support the latest annual CMS QRDA IGs (for hospitals and eligible professionals), whenever a final rule is published. Over time, ONC expects FHIR APIs may be utilized for CQM reporting, and solicits comment on the future possibility of FHIR-enabled APIs replacing or complementing the CMS QRDA reports.
ONC proposes a new 2015 Edition certification criterion for EHI export, in Section 170.315(b)(10), as a means to provide patients and health IT users with a means to efficiently export the entire EHR for a single patient or all patients in a computable, electronic format, and facilitate the receiving health IT system's interpretation and use of the EHI. The new certification criterion would complement other provisions that support patient access to their EHI, all of which the ONC expects will eventually be accessible via APIs.
By providing a baseline capability for exporting EHI in a commercially reasonable format, the new certification criterion would help remediate past practices in which HIT developers could effectively block the export and portability of data for use in competing systems or applications, or charge rents for access to the basic technical information needed to facilitate the conversion or migration of data to competing health IT systems.
ONC does not propose a specific standard for implementing this certification criterion.
A user must be able to timely execute the single patient EHI export at any time the user chooses and without subsequent developer assistance to operate. For example, a health IT developer should not:
By "timely", ONC does not mean real-time; however, the export should not be longer than reasonably necessary to avoid interference with other clinical functions of the health IT system. According to the ONC, delays that cause or contribute to users being presented with data files that no longer contain current, accurate or valid data would not conform with the certification criteria.
By "user", ONC refers to a health care professional or his or her office staff, or a software program or service that interacts directly with the certified HIT. The certification criterion does not address access directly by a patient, but ONC requests comment on whether the criterion should be more prescriptive, by only allowing the patient and his/her authorized representative to be the requestor of their EHI, similar to how ONC has previously scoped the "view, download and transmit to 3rd parties" certification criterion at Section 170.315(e)(1).
A HIT developer of HIT certified to the proposed new EHI Export certification criteria would be required, at a customer's request, to provide a complete export of all EHI that is produced or managed by means of that HIT. The certification criterion focuses on the technical outcome, and gives flexibility to HIT developers to decide how to achieve the outcome, as long as it is achieved in a timely and efficient manner and in a format that is commercially reasonable. ONC notes that under Section 170.402, health IT are required to provide assurances that they will provide reasonable cooperation and assistance to other persons (including customers, users, and third party developers) to enable the use of interoperable products and services. See Section VII.B.2. of the Proposed Rule
EHI export would encompass all EHI that the health IT system produces and electronically manages for a patient or group of patients, including clinical, administrative and claims/billing data. It would also include any data stored in separate data warehouses that the system has access to, can produce and electronically manages. ONC's use of EHI is intentionally broad. "We clarify that 'EHI' also includes the oldest EHI available on that patient to the most recent, no matter the specific electronic format."
ONC also notes that it would encompass imaging information. With regard to imaging, however, ONC understands that "EHRs may not be the standard storage location for images". For this reason, it solicits comment on the feasibility, practicality and necessity of exporting images and/or imaging information. It also requests comment on image elements that should be included (e.g. image quality, type and narrative text.) and on how the ONC should address use cases where it is infeasible or impractical to transfer all possible data elements. As an example, the ONC suggests that HIT developers attest or publish as apart of their export format documentation the types of EHI that they cannot support for export.
Some types of metadata would not be required for export (e.g. internal database table names)
ONC proposes that health IT developers make their export formats (data dictionary or export support file) publicly available via hyperlink as part of certification to the EHI export criterion, and keeping the hyperlink up-to-date with current export format. This requirement would be consistent with the proposed rules against information blocking.
The "export EHI" certification criterion does not require persistent and continuous access to EHI. It is only intended to support discrete data export capability. However, the ONC regards it as a necessary step towards persistent and continuous access. In its discussion, the ONC encourages health IT developers to consider persistent and real-time approaches as part of the step-wise progression we see towards open, standards-based APIs for a growing number of data elements per the USCDI in the proposed "standardized API for patient and population services" criterion.
The ONC seeks input on EHI export and timeframes. In particular, beyond exporting all the EHI the health IT system produces and electronically manages, should it include capabilities to permit health carte providers to set timeframes for EHI export, such as only the past two years or past month of EHI?
The new "export EHI" would be included in the Base EHR definition, which means that all health care providers participating in the CMS Promoting Interoperability Program (formerly the Medicare and Medicaid EHR Incentive Program) would need this capability in their CEHRTs. It would vastly expand data export certification requirements, since the current "data export" criterion is limited to clinical data specified in the C-CDA. The effective data for including the export EHI certification criterion in the Base EHR definition would be 24 months from the effective data of the final rule.
ONC would replace the "application access-data category request" certification criterion with a new "standardized API for patient and population services" criterion in Section 170.315(g)(10), and include this criterion in the 2015 Edition Base EHR definition. Consequently, all CEHRTs would need to support this functionality. See Application Programming Interfaces
The 2015 Edition includes a privacy and security certification framework, at Section 170.550(h), that applies to all Health IT Modules presented for certification. The ONC proposes the addition of two questions that HIT developers would answer regarding these Health IT Modules.
In the first question, HIT vendors would attest whether or not their technologies encrypt all authentication credentials. If HIT vendors affirmatively attest to this criterion, the proposed attestation would tie to FIPS 140-2 cryptography requirements, which the ONC commentary regards as the “seminal, comprehensive and most appropriate standard”.
In the 2nd question, HIT vendors would attest whether or not their technologies use multi-factor authentication. The attestation would also address whether their MFA implementation, where applicable, conforms with industry recognized standards like NIST SP 800-63B Digital Authentication or ISO 27001. In commentary accompanying the proposed rule points to the Healthcare Industry Task Force on Cybersecurity’s recommendation that the industry adopt NIST SP 800-46 guidelines in services where any personal data can be remotely accessed.
The ONC proposes to remove from the 2015 Edition Certification Criteria two “data segmentation for privacy” (DS4P) certification criteria for summary care records (C-CDAs), and replace them with three new DS4P certification criteria. The criteria concern the implementation of security labels that facilitate the exchange of data in accordance with privacy policies that originate from patients, the law or an organization. The existing DS4P certification criteria only required the use of security labels at the document-level. Based on feedback, the ONC states that document-level security labels don't give providers sufficient flexibility to address more granular segmentation needs, especially in pediatric care and behavioral health care. To address these limitations, he new DS4P certification criteria would support document-, section- and entry-level segmentation and consent management in the exchange of C-CDAs and through FHIR servers
As with the current DS4P certification criteria, the ONC would not include the proposed DS4P certification criteria in the 2015 Edition Base EHR definition. Instead, they are being proposed to put DS4P capabilities on a glide path that would eventually help automate existing manual redaction workflows.
The DS4P certification criteria proposed for Section 170.315(b)(12) and (13) would apply to C-CDAs and be based on the HL7 DS4P standard.
The DS4P certification criteria proposed for Section 170.315(g)(11) would support data segmentation and consent management in APIs by following Consent2Share. Consent2Share is an open source application for data segmentation and consent management that ONC created with the Substance Abuse and Mental Health Services Administration (SAMHSA). The ONC encourages developers to participate in the Consent2Share community to expand support of data segmentation for health care providers engaged in complex use cases, including thosed involved in pediatric care, behavioral health care, HIV/AIDS, alcohol, tobacco, sexuality and reproductive health, and opioid use disorder.
Throughout the 2015 Edition Criteria, the ONC has removed references to the Medicare and Medicaid EHR Incentive Programs, and replaced them with references to the Medicare and Medicaid Promoting Interoperability Program, to align with the name change invoked by the CMS, and reflect the shift in policy priorities from meaningful use of EHR to interoperability and improving patient access.
JillDeGraff
commented
5 years ago JillDeGraff
commented
5 years ago (note: not all sections have been summarized. Contributions are welcomed.)
JillDeGraff
commented
5 years ago (note: not all corrections under V. Modifications to the ONC Health IT Certification Program have been summarized. Contributions are welcomed.)
JillDeGraff
commented
5 years ago Consistent with the 2015 Edition privacy and security certification framework, each certification criterion has a set of appropriate P&S "safeguards" that must be in place. In the 2015 Edition, ONC required that an ONC-ACB ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text "first level paragraph" cateory of Section 170.315(e.g. 170.315(a)) would be certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation).
In this proposed rule, ONC would require the new criteria (Section 170.315(d)(12) and (13) to apply to all Section 170.315 certification criteria. ONC notes that the P&S Framework will likely need further updating, if proposals for removing certain certification criteria are finalized.
JillDeGraff
commented
5 years ago Section 4002 of the Cures Act requires the Secretary of HHS, through notice and comment rulemaking, to establish Conditions and Maintenance of Certification requirements for the Program. Specifically, health IT developers or entities must adhere to certain Conditions and Maintenance of Certification requirements concerning information blocking; appropriate exchange, access and use of EHI; communications regarding HIT; APIs; real world testing for interoperability; attestations regarding Conditions and Maintenance of Certification requirements; and submission of reporting criteria under the EHR reporting program.
JillDeGraff
commented
5 years ago The Conditions of Certification express initial requirements for HIT developers and their certified Health IT Modules. The Maintenance of Certification express continuing requirements that must be met by HIT developers and their certified Health IT Modules under the program. "Health IT Module" is defined in 45 C.F.R. 170.102 as "any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary."
The Maintenance of Certification requirements are aligned with their related Conditions of Certification, but represent standalone requirements. Procedurally, this approach creates a clear baseline with an expectation that evidence will be collected to demonstrate that the Conditions of Certification are continually being met. Noncompliance triggers the ONC's corrective action process, which could ultimately lead to termination from the program.
JillDeGraff
commented
5 years ago Section 4004 of the Cures Act creates a new Section 3022(a) of the PHSA, which requires that developers of technologies certified under the ONC's voluntary health IT certification program, health care providers, health information exchanges and health information networks not take any action that constitutes "information blocking". Congress also directed the ONC, through notice and comment rulemaking, to define reasonable and necessary practices that would not constitute information blocking, which the ONC does in a new Section 171.103.
ONC implements this Congressional mandate with significant definitions for information blocking, electronic health information and other key terms. It also defines seven exceptions when information blocking would be permitted, if detailed requirements are satisfied.
Prohibitions on information blocking would be enforced through new statutory and regulatory authorities. First, the Cures Act grants the HHS office of the inspector general authority to investigate information blocking claims, backed by additional authority to impose civil money penalties (on developers, networks and exchanges) and the potential for programmatic disincentives. Second, under the ONC proposed rule, the ONC proposes to exercise its authority to terminate certifications under its voluntary HIT certification program if a health IT developer is found to engage in information blocking, even if the activity does not concern certified health IT. Third, under the CMS proposed rule on data interoperability and patient access, CMS would require eligible professionals in the Quality Performance Program to make an annual attestation that they have not knowingly or willfully engaged in information blocking. These attestations would be reported in Physicians Compare.
If implemented as proposed, how would business practices and contracts change for health IT developers, health care providers, developers that seek access to electronic health information for their services, health information networks and health information exchanges?
to promote the privacy of EHI
to promote the security of EHI
to recover costs reasonably incurred to provide access, exchange or use of EHI
in response to requests for EHI that are infeasible
in connection with licensing interoperability elements on reasonable and non-discriminatory terms
to maintain and improve health IT performance.
Elsewhere in the proposed rule, the ONC includes
this requirement at Section 170.401, and defines "information blocking" in a The ONC's approach in defining information blocking has two parts. First, it would establish a broad definition of business practices that constitute impermissible information blocking, with clarification that disclosures required band then
Developers of technologies certified under the ONC's voluntary health IT certification program are not the only entities subject to the information blocking provisions of the Cures Act, and the implementing regulations proposed by ONC. Part 171 would also apply to health care providers, health information exchanges and health information networks, and provides new defined terms for HIEs and HINs. In the related CMS proposal on data interoperability and patient access, CMS would update the Physician Compare website to include information from an updated attestation that health care providers would make, stating that they have not knowingly or willfully engaged in information blocking activities. See 84 Fed Reg 7610, 7645 (March 4, 2019)
Part 171 contains a range of definitions to
To enforce provisions against information blocking, the ONC would exercise its authority with regard to the Certification Program. As well, it notes that the HHS OIG has investigatory and enforcement authority over information blocking, including authority to impose CMPs for information blocking conducted by health IT developers of certified HIT, HINs and HIEs. OIG can also investigate health care providers for information blocking for which health care providers could be subject to disincentives.
JillDeGraff
commented
5 years ago Under Part 171 of the ONC's Proposed Interoperability Rule, Information blocking would mean a practice that--
Except as required by law or covered by an exception set forth in subpart B of this part, is likely to interfere with, prevent, or materially discourage access, exchange or use of EHI; and
If conducted by a HIT developer, HIE, or HIN, such developer, exchange or network knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI; or
If conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interferewith, prevent, or materially discourage access, exchange or use of EHI.
ONC then proposes seven (7) permissible exceptions for activities that that would not constitute information blocking, even if they interfere with the access, exchange or use of EHI. Broadly, these exceptions address activities that —
A. prevent harm
B. promote privacy of EHI
C. promote security of EHI
D. allow for recovery of costs reasonably incurred
E. excuse an actor from responding to requests that are infeasible
F. permit licensing of interoperability technology on reasonable and non-discriminatory terms
G. reasonable and necessary to promote the performance of health ITEach exception is qualified by specific requirements [summarized in the links provided]. In designing these exceptions, including their specific requirements, the ONC was guided by three policy considerations:
To promote public confidence in health IT infrastructure, protect patient safety and/or promote competition or innovation in health IT and its use to provide health care services to consumers To mitigate a significant risk that "reasonable and necessary activities” might not be engaged in, out of concern that these activities would constitute information blocking To tailor permissible exceptions through appropriate conditions, so that they are limited to the reasonable and necessary activities that they are designed to exempt.
To qualify for this exception, the actor must have a reasonable belief that the practice will directly and substantially reduce the likelihood of harm to a patient or another person, arising from (1) corrupt or inaccurate data being recorded or incorporated in a patients electronic health record; (2) misidentification of a patient or patient’s EHI; or (3) disclosure of a patient’s EHI in circumstances where a licensed health care professional has determined, in the exercise of professional judgment, that the disclosure is reasonably likely to endanger the life or physical safety of the patient or another person. Circumstances arising under (3) would not disturb applicable federal or state law requirements giving patients the right to review that determination, where applicable. To the extent a practice implements an organizational policy, the exception also imposes policy standards. In all other cases, the actor must make a finding in each case, based on the particularized facts and circumstances, and based on, as applicable, relevant clinical, technical and other appropriate expertise, that the practice necessary and no broader than necessary to mitigate the risk of harm
JillDeGraff
commented
5 years ago The Cures Act requires a health IT developer, as a Condition and Maintenance of Certification under the Program, to provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking or any other action that may inhibit the appropriate exchange, access and use of EHI. The ONC proposes to implement these assurances in [Section 170.402]. Under Subpart B of proposed Part 171 of the proposed rule, starting at Section 171.200, the ONC proposes seven (7) "reasonable and necessary" activities that would constitute exceptions to the information blocking definition.
JillDeGraff
commented
5 years ago Section 171.201 - Exception - Preventing harm Section 171.202 - Exception - Promoting the privacy of EHI Section 171.203 - Exception - Promoting the security of EHI Section 171.204 - Exception - Recovering costs reasonably incurred Section 171.205 - Exception - Responding to requests that are infeasible Section 171.206 - Exception - Licensing of interoperability elements on reasonable and non-discriminatory terms Section 171.207 - Exception - Maintaining and improving HIT performance.
JillDeGraff
commented
5 years ago For the avoidance of doubt, the Conditions of Certification would include at [Section 170.402] assurances](https://github.com/JillDeGraff/ONCWatch/issues/1#issuecomment-473683440) by the health IT developer that the certified Health IT conforms to the full scope of the certification criteria to which its health IT is certified. They would also be required to provide an assurance that they have made certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes, and not take any action that could interfere with a user's ability to access or use certified capabilities within the scope of the technology's certification. These assurances are likely to find their way in commercial contracting terms.
By way of example, the ONC states that these actions would violate these assurances:
Organizations will need to review their business practices to eradicate these activities if they exist.
JillDeGraff
commented
5 years ago As a Condition of Certification, ONC proposes that all HIT developers that produce and electronically manage EHI would need to certify its HIT to the 2015 Edition "electronic health information export" certification criteria, as proposed in Section 170.315(b)(10).
HIT developers of certified HIT certified to this criteria would need to provide EHI export capabilties within 24 months after the final rule becomes effective. HIT developers that never previously certified HIT would have 12 months from certification, if later.
JillDeGraff
commented
5 years ago HIT developers would be subject to a 10 year record and information retention policy, beginning from the date of certification, in order to demonstrate initial and ongoing compliance with the ONC Health IT Certification Program. It applies separately to each unique Health IT Module (or complete EHR, as applicable).
An exception is proposed for certification criteria that are later removed from the CFR before a 10-year period expires. In these cases, records only need to be kept for 3 years from the date of removal, or the expiration of the 10 year period, whichever occurs sooner.
For Health IT developers that have never participated in the ONC Health IT Certification Program, presents their Health IT Modules for certification and produces and electronically manages EHI, the record keeping and compliance responsibilities associated with the Conditions and Maintenance of Certification are going to be a significant new cost that will need to be budgeted into its service offerings, and included in calculations to justify recovery of reasonably incurred expenses, per Subpart B of the Information Blocking Rule.
JillDeGraff
commented
5 years ago ONC requests comment on whether the Assurances provided by some HIT developers as part of the proposed Conditions and Maintenance of Certification regulations include a requirement that they participate in the TEFCA. According to the ONC, doing so would give further assurances to customers and ONC that these HIT developers are not taking actions that constitute information blocking or any other action that may inhibit appropriate exchange, access and use of EHI. The requirement would have to come up in a subsequent rulemaking, but ONC requests these comments as an RFI. The ONC only envisions the requirement for HIT developers that have a Health IT Module certified to any of the following 2015 Edition certification criteria, because the capabilities included in these criteria support access and exchange of EHI:
The ONC doesn't envision TEFCA being a requirement for HIT developers of HIT Modules that do not support access and exchange of EHI; for example, HIT developers of clinical decision support HIT Modules would not be subject to the requirement, if proposed and implemented.
JillDeGraff
commented
5 years ago The ONC proposes a two-part test to implement provisions of the Cures Act that prohibit a HIT developer from prohibiting or restricting communication regarding (a) the usability, interoperability or security of the HIT or (b) relevant information about users' experience when using the HIT, the developers' business practices related to EHI exchange or the manner in which users have used the HIT. Under the two-part test, it would never be legitimate or reasonable to restrict communications required by law, made to a government agency or made to a defined category of safety organizations. HIT developers would be permitted to impose certain narrow kinds of prohibitions and restrictions enumerated in proposed Section 170.403(a)(2)(ii). Health IT vendors would also be prohibited from establishing or enforcing contract provisions that contravene the proposed rule. Under the proposed Maintenance of Certification provisions, health IT vendors would need to notify existing customers within 6 months of the effective date of a final rule that contract provisions in conflict with the requirement will not be enforced by the HIT developer, and to provide follow up notices annually until the contract is amended to remove or void the contravening contract provisions.
JillDeGraff
commented
5 years ago Following is a high-level description of the exceptions from the proposed rule In the ONC's proposed Conditions and Maintenance of Certification for Health IT Developers that would restrict health IT developers from prohibiting or restricting communications regarding the the usability, interoperability or security of the HIT or relevant information about users' experience when using the HIT, the developers' business practices related to EHI exchange or the manner in which users have used the HIT.
(A) Developer employees and contractors. A health IT developer may prohibit or restrict the communications of its employees or contractors. (B) Non-User Facing Aspects of HIT. A health IT developer may prohibit or restrict communications that disclose information about non-user-facing aspects of the developer's HIT (C) Intellectual Property. A health IT developer may prohibit or restrict communications that would infringe IPRs existing in the developer's HIT, provided:
(D) Screenshots. Health IT developers may require persons who communicate screenshots to follow specified parameters (e.g. not to alter screenshots or infringe the IPR of third parties, or only use redacted screenshots of 3rd party content and PHI) (E) Pre-Market Testing and Development. Health IT developers may prohibit or restrict communications that disclose information or knowledve solely acquired in the course of participating in pre-market product development and testing activities.
JillDeGraff
commented
5 years ago The ONC's discussion of the Conditions and Maintenance of Certification related to APIs begins in the proposed rule on page 7476. It implements the Cures Act requirement that HIT developers publish APIs that allow "health information from such technology to be accessed, exchanged and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law." The Cures Act's API Conditions of Certification also states that a developer must, through an API, "provide access to all data elements of a patient's EHR to the extent permissible under applicable privacy laws."
This preamble outlines the ONC's proposals to implement the Cures Act's API Condition of Certification, which include new standards, new implementation specifications and a new certification criterion, as well as detailed Conditions and Maintenance of Certification requirements. The ONC also proposes to modify the Base EHR definition.
2019 03 13_Posnack_APICoC_Fees_IB.pdf is a slide deck prepared by the ONC about the API provisions of the proposed rule. It was accessed on March 15, 2019 from HealthIT.gov
JillDeGraff
commented
5 years ago The ONC interprets the "effort" exerted (i.e. by whom) to be focused on API users, which could include third party software developers, the health care providers that acquire API technology, and patients, health care providers and payers that use apps/services that connect to API technology. It interprets "without special effort" to require that APIs, and the health care ecosystem in which they are deployed, have three attributes: Standardized, transparent and pro-competitive.
JillDeGraff
commented
5 years ago The proposal would update 45 CFR 170.102 to include the following new terms:
JillDeGraff
commented
5 years ago In the proposed rule, the ONC proposes to adopt FHIR Release 2 as the baseline standard conformance requirement in a new API standards section at 45 CFR 170.215(a)(1). FHIR Release 2 is also referenced for use in the new "standardized API for patient and population services" certification criterion at CFR 170.315(g)(10). The ONC reports that approximately 87% of hospitals and 57% of clinicaians are served by delovered with a FHIR Release 2 API, reflecting rapid progress since publication of the 2015 Edition certification criteria to advance the FHIR Standard.
While the ONC believes FHIR Release 2 best reflects the industry's current maturity and implementation readiness, it observes that FHIR Release 3 is published. Additionally, FHIR Release 4 has not been published, and updated associated implementation specifications are expected to follow. The ONC remarks that FHIR Release 4 has several key improvements which will be compelling for many health IT developers. As a result, the ONC expects many health IT developers will either rapidly process to FHIR Release 4 from Release 3, or skip Release 3 entirely.
For these reasons, ONC wants to know if it should adopt just FHIR Release 2 as the baseline API standard (Option 1), adopt FHIR Release 2 and 3 (Option 2), adopt FHIR Release 2 and 4 (Option 3) or adopt just FHIR Release 4 (Option 4). In the preamble, the ONC observes that Option 3 would appear to be the best near and long term option for the industry, as long as the FHIR Release 4 implementation specifications are published in time for the final rule. Option 3 would allow lagging health IT developers to catch up to the FHIR Release 2 baseline while enabling leading health IT developers to move directly and immediately to FHIR Release 4. The ONC regards Option 4 as the next best option, if the implementation specifications are published in time for the final rule, because it would still give industry 12 months of development experience with FHIR Release 4 without putting a drag on the industry's transition to FHIR Release 4.
The ONC highly encourages stakeholders to express their perspectives and explicitly note their preferred option in comments.
JillDeGraff
commented
5 years ago ...
Proposes to adopt three (3) implementation specifications to constrain implementation choices on the proposed FHIR Release 2 baseline conformance standard and further assure that APIs can be used "without special effort".
Argonaut Data Query Implementation Guide version 1 (45 C.F.R. 170.215(a)(3). Specifies FHIR profile constraints for 13 of the associated FHIR resources proposed for inclusion in the ARCH
Argonaut Data Query Implementation Guide Server conformance requirements (45 C.F.R. Section 170.215(a)(4). Viewed by the ONC as essential for ensuring that all FHIR servers are consistently configured to support the defined data queries and "supported searches" associate with each Argonaut profiled FHIR resource.
JillDeGraff
commented
5 years ago ...
JillDeGraff
commented
5 years ago ...
The ONC would retire the current "application access - data category request" certification criterion at 45 C.F.R. Section 170.315(g)(8), which applies standards-less requirements for API functionality when data is requested from a C-CDA. In its place, the ONC proposes a new "standardized API for patient and population services" at a new Section 170.315(g)(10). During a transition period (through month 24 after the final rule's effective date), HIT developers would be able to choose between the two certification criterion. The proposed "standardized API for patient and population services" would apply to any Health IT Module presented for certification and any technology meeting the 2015 Edition Base EHR definition presented for EHRT certification.
Key highlights
ONC notes that FHIR Release 2 does not have as many capabilities to support population level services. By contrast, FHIR Release 4 includes technical specification to enable standardized population-level services in a more efficient manner.
HIT presented for testing and certification against the proposed "standardized API for patient and population services" certification criterion would need to meet these requirements:
JillDeGraff
commented
5 years ago ...
The ONC proposes a new API Condition of Certification requirement at 45 C.F.R. Section 170.404.
The Condition of Certification would apply to any developer of Health IT Modules certified to any of the certification criteria in 45 C.F.R. Sections 170.315(g)(7) through (11), namely:
It would not apply to health IT developers that do not have technology certified to any of the foregoing criteria. Note, that the ONC also proposes to update the "Base EHR" definition at 45 C.F.R. 170.102 to include the the "application access - patient selection", "application access - all data request", and "standardized API for patient and population services" certification criteria, but not the "consent management for APIs" certification criterion. The definition would also give developers the option of certifying to the "application access - data category request" certification criterion instead of the "standardized API for patient and population services" during a 24-month transition period after a final rule takes effect.
JillDeGraff
commented
5 years ago ...
The ONC proposes a new API Condition of Certification requirement at 45 C.F.R. Section 170.404.
...
The Cures Act's API Condition of Certification requires that a developer, through an API, "provide access to all data elements (emphasis included) of a patients' electronic health record to the extent permissible under applicable privacy laws." Initially, the ONC constrains its interpretation of "all data elements of a patient's electronic health record" to the limited set of data elements defined by the UCSDI and supported by the ARCH. The API Conditions of Certification will accommodate updates in required data elements as the UCSDI and the ARCH are updated.
JillDeGraff
commented
5 years ago The ONC proposes that the API Condition of Certification require specific business and technical documentation to be freely and publicly accessible. These would include all terms and conditions, as well as the technical documentation described in the "standardized API for patient and population services" certification criterion.
"terms and conditions" would include any fees, restrictions, limitations, obligations, registration process requirements and other terms or conditions that would be material and needed to:
The ONC proposes that any and all fees charged by an API Technology Supplier for use of its API technology must be published and described in detailed, plain language as part of its publicly available terms and conditions. The description of the fees must include all material information, including:
After a 6-month transition period from the final rule's effective date, suppliers with products already certified to Section 170.315(g)(7), (8) or (9) would have to revise their API documentation to come into compliance with these transparency conditions.
The ONC would expect API Technology Suppliers to revise and/or construct terms and conditions for its API technology that account for and reflect the provisions of the proposed API Conditions of Certification. Revised terms and conditions would also need to address compliance with the ONC's proposed Information Blocking regulation, so that API Technology Suppliers can qualify for applicable exceptions, like "Recovering Costs Reasonably Incurred" and "Licensing of Interoperability Elements on Reasonable and Non-Discriminatory Terms".
Another transparency condition concerns the processes used by API Technology Suppliers to verify third party app developers. The ONC notes in passing that had it implemented the OAuth 2.0 standard, it would have outright prohibited API Technology Suppliers from identity proofing or verifying authenticity of developers of apps designed to enable patient access. In the alternative, the ONC seeks comment and recommendations on factors that would enable registration with minimal barriers; for example, by:
Meantime, the ONC proposes to permit API Technology Suppliers to institute a process to verify the authenticity of app developers, subject to the following conditions:
Examples of verification techniques suggested by the ONC include:
The ONC notes that app developers would still need to be registered, and thus be identifiable and able to have their access deactivated if they behave in malicious ways [acceptable use policies]. Also, the patient seeking access through the app needs to authenticate themselves in order to connect to the FHIR server and specify the scope of data the app may access.
For apps used by health care providers, the ONC recognizes that API Technology Suppliers may establish additional mechanisms within to vet app developers to ensure that they operate appropriately within the providers' health IT environment and won't degrade overall system performance. The ONC advises that these mechanisms could fit into the "value-added services" permitted fee and result in the app being acknowledged or listed by the health IT developer in some special manner (e.g. in an "app store" or "verified app" list). The ONC's proposals do not specify any explicit limits to the nature and governance of these approaches, but cautions HIT developers to design these approaches in ways that avoid violations of the proposed Information Blocking regulation.
JillDeGraff
commented
5 years ago The permitted fee conditions in the proposed API Conditions of Certification have been designed to align with the requirements of the information blocking exceptions proposed in the Information Blocking regulation. Absent a valid exception, the API Conditions of Certification would prohibit API Technology Suppliers from imposing fees associated with certified API technology (but not for other types of technology or unrelated services). In order for API Technology Suppliers to recover costs and earn a reasonable return on their investment in providing certified API technology, the ONC has identified categories of "permitted fees" that API Technology Suppliers would be permitted to charge and remain in compliance with the API Conditions of Certification.
Other than with regard to "value-added services," proposed in Section 170.404(a)(iv), fees permitted under the API Conditions of Certification must arise between an API Technology Supplier and an API Data Provider. Any fee arising in connection with an API User's use of API technology would need to exist solely between the API Data Provider and the API User. Suppliers would not be permitted in any way to impose fees on any person in connection with an API Technology Supplier's work to support the use of certified API technology to facilitate a patient (or patient app's) ability to access, exchange or use their EHI. However, API Technology Suppliers would be permitted to charge API Data Providers based on the usage activities of API Users.
These fee parameters would not prohibit another party from paying for API Technology Supplier's permitted fee, however. For example, an API User could offer to pay the permitted fee charged to an API Data Provider by an API Technology Supplier. In devising payment strategies, the ONC reminds stakeholders to be mindful of other federal and state laws and regulations that could prohibit or limit certain types of relationships involving remuneration.
General Conditions - Permitted Fees
Specific Proposed Permitted Fees
1. Reasonable Fees for Developing, Deploying or Upgrading API technology
2. Recovery of Costs To Support API Usage for Purposes Other than Patient Access, Exchange and Use
3. Permitted Fee for Value-Added Services
4. Prohibited Fees The ONC provides examples of what it views to be prohibited fees because they inappropriately create barriers to entry or competition and reflect rent-seeking and other opportunistic behaviors:
5. Record-Keeping Requirements API Technology Suppliers would be required to maintain for inspection detailed records of all fees charged with respect to certified API technology and all costs they claim to have incurred to provide API technology to API Data Providers. They would also need to document the criteria used to allocate any costs across relevant customers, requestors or other persons, so that the ONC would be able to objectively determine whether cost allocations are reasonable and comply with cost allocation requirements. Consistent with the Assurances Condition of Certification, records would need to be retained for 10 years (or three years post-removal by the ONC of a relevant API certification criterion), whichever occurs first.
Comments sought.
JillDeGraff
commented
5 years ago These conditions further align the API Conditions of Certification with the pro-competitive principles guiding the ONC's rulemaking.
General Condition
Specific Conditions
API Technology Suppliers - Additional Obligations. To support the use of API technology in production environments, API Technology Suppliers would be required to provide all support and other services that are reasonably necessary to enable the effective development, deployment and use of API technology by API Data Providers and its API Users. In this regard, they would be required --
JillDeGraff
commented
5 years ago
This GitHub repository provides high-level and selectively detailed summaries of the ONC's proposed rulemaking, published in the Federal Register on March 4, 2019.
The ONC accepts formal comments from the public on the proposed rules until 5pm on May 3, 2019. If you want to submit comments, go to the Federal eRulemaking Portal and upload your comments in MS Word (preferred), MS Excel or Adobe PDF.
Not all sections of the proposed rule have been summarized. Feel free to contribute! Follow links in the Table of Content structure to pages that have been summarized.
The ONC's presentation to HIMSS about the Proposed Rule and other resources provided by the ONC about the proposed rule is available on HealthIT.gov.