-
Type:
Change Request
-
Resolution: Not Persuasive
-
Priority:
Medium
-
US Da Vinci PAS (FHIR)
-
STU3
-
Financial Mgmt
-
(profiles) [deprecated]
-
Overview
-
-
Robert Dieterle / Rachael Foerster: 20-0-1
-
Clarification
Existing Wording: When combined with the Da Vinci Coverage requirements Discovery (CRD) and Documentation Templates and Rules (DTR) implementation guides, direct submission of prior authorization requests will further increase efficiency by ensuring that authorizations are always sent when (and only when) necessary and that such requests will almost always contain all relevant information needed to make the authorization decision on initial submission.[...] CRD Query "4. System starts CRD query … a 'token' that temporarily allows the payer to securely query the EMR for additional patient information"
Proposed Wording: The preferable alternative here must be for the payer to directly seek authorization for the EMR/EHR's FHIR Server and acquire a token to query the EHR/EMR FHIR Server with scopes suitable for Payer's access per policies.
If for any practical reasons (e.g., latency, routing/discovery) the EMR/EHR must provide an access token to the Payer, this access token:
- MUST NOT be issued with full access/scopes and MUST be restricted to the scopes the Payer in question is authorized to access per policies,
- The audit records for issuing this access token (whether it is issued by the EHR/EMR FHIR server directly or issued by an OAuth server) MUST reflect the identity of the Payer to whom this access token is issues,
- The EMR/EHR MUST NOT share the same access token with different Payers.
These basic requirements guarantee that Payer's access to any further data a) remains subject to all applicable restrictions/policies and b) there is clear accountability about the use of any access token used to retrieve data from the EHR/EMR FHIR Servers, and c) EMR/EHR can mark any outgoing data requested by the Payers with appropriate security labels indicating that the data is release for the specific purpose of payment and cannot be redisclosed or repurposed.
Comment:
Full automation of PAS relies on CRD, which is based on CDS-Hooks. CRD Query CDS-hooks uses a privacy risky approach to enabling a payer to access patient records in a providers system using the provider's access token. [See quote for CRD query in Proposed Wording for this comment.]
The provider's access token gives authorized access to patient information used for treatment purposes, only a subset of which should be used for HIPAA payment/operations purposes of use. The payer can access treatment information based on the payer's policy for minimum necessary, which may not be aligned with the provider's policy for minimum necessary for HIPAA payment/operations. While a provider may reasonably rely on a covered entity limiting their request for information to the minimum necessary for payment/operations, a provider has to know in advance what the payer thinks they "need to know" in order to reasonably rely on the payer's determination of minimum necessary. In addition, there may be privacy restrictions on patient records that require an access control system to decide whether the payer is authorized for these records. This is a serious privacy and security flaw in CRD and thereby in PAS.
Our alternative is stated in the Proposed Wording for this comment.
Summary:
Full automation of PAS relies on CRD, which is based on CDS-Hooks.
- is voted on by
-
BALLOT-10854 Negative - Kenneth Rubin : 2019-Sep-FHIR IG PAS R1
- Balloted