Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-36276

Security review of SDC Adaptive Forms in DTR

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci DTR (FHIR)
    • 1.1.0-ballot [deprecated]
    • Clinical Decision Support
    • DTR Questionnaire for adaptive form
    • Formal Specification
    • 4.16
    • Hide

      We will add the following statement into the DTR spec in an area that deals with the set-up/pre-configuration:

      "DTR apps are expected to be technically able to run against any EHR and work with any payer.  However, for a DTR app to be used, it needs to be trusted appropriately manage access to personal health information by the EHRs and payers.  EHRs will choose which DTR apps they will trust and support.  Similarly, all DTR apps must be registered with the payer systems with which they communicate.  This registration process will ensure the following:

      • The DTR app is 'trusted' by the payer to deal with patient-identifiable data
      • The DTR app knows the relevant endpoints to use to access Questionnaires, DocumentReferences and other relevant information
      • The DTR app has a shared secret allowing secure access to the payer endpoints

      Even after an application has been successfully registered, payers and EHRs SHOULD monitor the application behavior and MAY suspend an application's access if it is suspected of malicious behavior."

      Show
      We will add the following statement into the DTR spec in an area that deals with the set-up/pre-configuration: "DTR apps are expected to be technically able to run against any EHR and work with any payer.  However, for a DTR app to be used, it needs to be trusted appropriately manage access to personal health information by the EHRs and payers.  EHRs will choose which DTR apps they will trust and support.  Similarly, all DTR apps must be registered with the payer systems with which they communicate.  This registration process will ensure the following: The DTR app is 'trusted' by the payer to deal with patient-identifiable data The DTR app knows the relevant endpoints to use to access Questionnaires, DocumentReferences and other relevant information The DTR app has a shared secret allowing secure access to the payer endpoints Even after an application has been successfully registered, payers and EHRs SHOULD monitor the application behavior and MAY suspend an application's access if it is suspected of malicious behavior."
    • Bob Dieterle / Isaac Vetter : 11-0-0
    • Clarification
    • Non-substantive

    Description

      TL;DR: With SDC Adaptive forms, the DTR App needs at least ability to write to the Payer FHIR server. Is it possible a badly behaved app can post data pretending to be real end user responses, and elicit PHI/PII out of the payer system? I am afraid of this risk. Therefore, I request a security review of the use of SDC Adaptive Forms.

      ---------------------------------------

      In DTR, there are two connections which require authentication / security

      1. Between the App and the Provider/EHR FHIR server
      2. Between the App and the Payer FHIR server

      #1 is completely taken care of using SMART on FHIR, and I am not raising any concerns there.

      However, #2 is an area of concern, because "any DTR App" that the provider chooses should be allowed to function as the DTR App. The best method for authentication we have here is some form of Client Credentials, because SMART on FHIR cannot be federated/delegated. 

      The payer obviously does not want to expose a significant scope to the DTR app. A "generally available" FHIR Questionnaire, and a "generally available" CQL query is fine, but anything PHI/PII is not fine - because the app maybe interacting in the context of one patient, but can query stuff in context of other patients etc. Since client credentials cannot limit scope to the patient in current context like SMART on FHIR can, we have to limit scope to no patients / patient data. So the App's credentials will only allow Read operations on the FHIR Questionnaire and the CQL query. (In fact, a payer may want to stand up a dedicated sandboxed DTR "FHIR" server, which has no PHI/PII and only the stuff that is furnished to "unsafe" DTR Apps.)

      In the past, a proposal to store patient data on the payer FHIR server was introduced. I had requested security review of that, and that was aborted as a result of said security review because of the above concern. 

      We are again now introducing SDC Adaptive Forms, which stores (or posts and reads) data to the payer FHIR server. To me, this again brings up the same security concern. Is it possible for a malicious (or passively malicious) DTR App to obtain (or modify) information about patients other than the one in the current context? (Especially, with SDC Adaptive Forms, the payer needs a real FHIR server; a sandboxed DTR "FHIR" server that only contains Questionnaire and CQL query is no longer viable.)

      With SDC Adaptive forms, the DTR App needs at least ability to write to the Payer FHIR server. Is it possible a badly behaved app can post data pretending to be real end user responses, and elicit PHI/PII out of the payer system? I am afraid of this risk.

      Therefore, I request a security review of the use of SDC Adaptive Forms, in the light of the previous security review that was done around DTR App saving data to Payer FHIR server referenced above. I checked with Lloyd, but apparently there isn't a Jira ticket or anything around the previous security review mentioned - it was discussed in HL7 calls and done as a follow-up of the discussion on the call. However, please make sure that the reviewers who do this requested security review are well familiar with the context of the previous review!

      Attachments

        Activity

          People

            Unassigned Unassigned
            m_varghese Varghese Mathew
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: