Software Compliance Attestation

Full Title

A Software Compliance Attestation is a machine readable packet that can be sent by a software application to a Relying Party attesting to the application source and compliance status.

Context

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.
• The phrase "health IT developer" is not clear if it is each individual programer, or the team or company that developed the program. since there could be many programs, and since there is no concept of "professional engineer" in the software industry to sign the certificate, we presume that the company will designate a "responsible party to assert the competence of the team.

Problems

• No matter how the responsible party is determined, there must be means for the software to provide some attestation to the EHR that it has been so approved.

Solutions

1. There must be criteria established to determine that the developer is qualified.
2. There must be a machine readable sent by the software to the EHR attesting to its provenance.
3. There must be a registrar to establish a chain of trust to each party.
4. It would be best if the same attestation could provide "proof-of-presence" or other data needed by the EHR to determine the assurance that both the software and the user had achieved. This would satisfy the TEFCA IAL2, AAL2 requirements at that same time.

References

• NIST laboratory Accredidation Program for Voting Machines
• NIST NVLAP Common Criteria Testing LAP for security testing of computer software.
• NIST NVLAP Cryptographic and Security Testing LAP initially named Cryptographic Module Testing (CMT), was established by NVLAP to accredit laboratories that perform cryptographic modules validation conformance testing under the Cryptographic Module Validation Program (CMVP)
• NIST NVLAP Healthcare Information Technology LAP In response to the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009, the U.S. Department of Health and Human Services along with the Office of the National Coordinator for Health Information Technology requested establishment of the Healthcare Information Technology Testing Laboratory Accreditation Program by NVLAP to accredit laboratories that perform functional and conformance testing of electronic health record (EHR) technology products to meaningful use requirements as defined in the nationally recognized EHR products testing standards.