Native Apps for US Healthcare: Difference between revisions
| Line 10: | Line 10: | ||
The [https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification#footnote-1-p25644 final rule on the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program] (issued 2020-05-01) has a fairly large chunk of guidance including: | The [https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification#footnote-1-p25644 final rule on the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program] (issued 2020-05-01) has a fairly large chunk of guidance including: | ||
* First the FDA part is interesting because upload of data to the EHR would probably trigger section 618 of FDASIA. That would require all such software to be approved by the FDA, but would not necessarily apply to software that only downloaded data. | * First the FDA part is interesting because upload of data to the EHR would probably trigger section 618 of FDASIA. That would require all such software to be approved by the FDA, but would not necessarily apply to software that only downloaded data. | ||
* Section III Application registration = We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server. - - - However, implementers of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion. | * Section III Application registration = We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server. - - - However, implementers of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the '''third-party application registration process that a health IT developer must meet under this criterion''' is not a form of review or “vetting” for purposes of this criterion. | ||
==Issues== | ==Issues== | ||
Revision as of 00:41, 15 August 2020
Full Title
Status of current regulatory information on the approval of Native Apps for US Healthcare.
Context
There are three sources of requirements for Native Apps for US Healthcare:
- US Cures Act Final Rule of 2020-05-01 - the regulations
- Medicare rules for reimbursement - the hammer behind adoption of the regulations.
- Trusted Exchange Framework and Common Agreement (TEFCA)
- FDA Medical device regulations
The final rule on the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (issued 2020-05-01) has a fairly large chunk of guidance including:
- First the FDA part is interesting because upload of data to the EHR would probably trigger section 618 of FDASIA. That would require all such software to be approved by the FDA, but would not necessarily apply to software that only downloaded data.
- Section III Application registration = We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server. - - - However, implementers of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion.
Issues
The following are to apply to states.File:CMS-200814.pdf It does not seem unreasonable to expect the same will apply to all managed plans.
When the API will be required
On page 1 quote
Implement and maintain a standards-based Patient Access API: The CMS Interoperability and Patient Access final rule requires state Medicaid agencies, Medicaid managed care plans, CHIP agencies, and CHIP managed care entities to make certain health information about Medicaid and CHIP beneficiaries accessible through a Patient Access application program interface (API) by 2021-01-01. This policy enables beneficiaries to have access to their health data on their internet-enabled devices (such as smartphones). Due to the COVID-19 public health emergency (PHE), CMS is exercising enforcement discretion, however, and does not expect to enforce this requirement prior to 2021-07-01.
What is required of a Native App
On page 3 quote
These managed care regulations require the plans and entities to comply with the same standards that apply to the fee for service programs. The CMS Interoperability and Patient Access final rule requires compliance with the API technical standards adopted by HHS at 45 CFR 170.215 including the Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard and relevant technical standards.
What Data is Covered
On page 6 quote
The CMS Interoperability and Patient Access final rule requires Medicaid managed care plans and CHIP managed care entities to develop the ability to share the United States Core Data for Interoperability (USCDI) as specified in 45 CFR 170.213 with the approval and at the direction of a current or former enrollee or the enrollee’s personal representative under the Payer-to-Payer Data Exchange policy. An assessment of the ability to create that data set and the completeness of that data set for all parties and the ability to send and receive such data by all parties would be appropriate as a first step in preparation for implementation.
States might make good partners
On page 7 quote
CMS will continue advancing policies which improve a patient’s right of access to their health information. We encourage states to continue to engage with CMS as stakeholders by providing feedback on these policies. States should reach out to their CMS MES State Officers for technical assistance on enacting these policies where relevant. CMS values the states as partners in expanding patient access to their health information and anticipates more opportunities to support such interoperability.