Native Apps for US Healthcare

From IDESG Wiki
Jump to navigation Jump to search

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:

  1. US Cures Act Final Rule of 2020-05-01 - the regulations
  2. Medicare rules for reimbursement - the hammer behind adoption of the regulations.
  3. Trusted Exchange Framework and Common Agreement (TEFCA)
  4. 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. Presumably it would apply if data were generated or collected by the app and uploaded into a EHR that required the provenance of the data to be included.
  • 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.

The local wiki page Software Compliance Attestation was created to address a third-party application registration process, It is a summary of the Kantara Recommendation on Mobile Authentication Assurance Statement (MAAS),

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.

Solutions

  • Mobile Authentication Assurance Statement (MAAS) 1.0.0 is a specification under development in Kantara.for apps to prove their security to the relying party.
  • AppVet is a shared service for vetting the security of Android and iOS mobile applications.
  • FirstNet, a service supported by the US Gov't for first responders, has an app verification process running now.

List of Apps found

Warning, these are not validated in any way. See the wiki on Patient Choice to see why uncertified apps is a really bad idea.

  1. Care Passport seems to be portal based.
  2. Common Health helps people collect and manage their personal health data and share it with the health services, organizations and apps they trust. Open Source on GitHub Android only
  3. One Record All your medical records in one place. Where have you received care in the last five years?

References

Retrieved from "https://wiki.idesg.org/index.php?title=Native_Apps_for_US_Healthcare&oldid=15998"