Difference between revisions of "CARIN App Registration"

Revision as of 15:55, 2 August 2021

This is a review of the CARIN Alliance - App Registration Implementation Guide dated 2021-06-01

The CARIN Alliance is a consortium of health information exchange organizations operated by Leavitt Partners.
The published the draft App Registration Implementation Guide on 2021-06-01'
The primary scope of the Guide concerns the app registration and patient authorization experiences.
The guide is focused on the adpotion of best practices and not on compliance.
The guide only accresses health data provided to the patient in FHIR format from an Electronic Health Record (EHR) from a HIPAA covered entity.
Under the final rule for the 21st Century Cures act, payers can only deny access to an application or developer to open APIs, including the patient acmes APIs, if these connections pose an unreasonable security risk to protected health information in their own systems.
- It is unclear why the word "payer" appears in the above sentence as it should apply to all EHRs.
- So while this particular implementation guide may be targeted to payers, this review addresses the broader problem of all EHR.
- The operating assumption is that HIPAA protected health information also in present in payer information.
Educational materials are required for patients. This review considers that targeted material needs to be present at the pont where the patient makes a choice.

The guides is for a "voluntary attestation framework that is aligned to the CARIN Code of Conduct."
The guide focuses on registration for Developers and their Applications.
CARIN makes the assumption that most applicants will be approved.
As is make clear in the Patient Choice wiki, most health apps today do not protect the data in the patients domain.
From that we can conclude that the CARIN guide is directed towards the profitability of the various organizations involved and not on patient empowerment.
An API sandbox is recommenced for payers.
An Attestation Framework is not required by rule, but strongly recommended.
Application profiles are recommended - this is a very positive approach that needs to be deployed across all of healthcare.
Any decision about allow an app access to PHI must be made within 5 business days, which implies that some sort of pre-registration is needed.
An API to the registration service is described, but it appears to only apply to registration and not to verification.

The guide was written as though the NCCOE (NIST SP 1800 series) publications or the zero trust criteria of the EO on Cybersecurity were never published..
The guide gives a strict reading of the rule for the benefit of the payers with only every limited concern for the patient.
The rest of the document is designed as a check list for security concerns.
Threats are only addressed in terms of intelligence reports with no indication that a threat analysis of the deployment is desirable.
The goal for mitigation risk is targeted to the creation of a binding contract with the patient.

@@ Line 30: / Line 30: @@
 * The guide gives a strict reading of the rule for the benefit of the payers with only every limited concern for the patient.
 * The rest of the document is designed as a check list for security concerns.
-* Threat are only addressed in terms of intelligence reports with no indication that a threat analysis of the deployment is desirable.
+* Threats are only addressed in terms of intelligence reports with no indication that a threat analysis of the deployment is desirable.
 * The goal for mitigation risk is targeted to the creation of a binding contract with the patient.