FAQs

Commonly Asked Questions

What criteria does DD&T Committee use during consideration for sandbox approval?

  1. Is the external application functionality already performed by the EHR itself? If so, what is the value added by this application?
  2. Does the application respect core principles of the UCSF EHR, such as retaining ‘single source of truth?’ 
  3. Do the application’s clinical recommendations align with other UCSF Health standards (e.g. medications on UCSF formulary)? 
  4. Does the use of the API align with other key UCSF Health pillars, as articulated in the UCSF True North strategic plan?
  5. Do the APIs you want to use already exist?
  6. Is your app’s connection likely to be costly to maintain (e.g. how many times does it call our EHR, for what information, and in domains that change frequently or otherwise)? What is the cost of maintenance?
  7. Are you or your software partners capable of assuming the risks of connecting to and handling Protected Health Information (PHI)?
    1. Are your security procedures consistent with UCSF standards?
    2. Can you secure PHI in transit and at rest?
    3. If you’re using an external vendor, have they already or will they sign UCSF’s Business Associates Agreement?
    4. Are your partners (if any) in good standing as University of California (UC) vendor?
    5. What assurances can you provide regarding safeguarding/auditing data?
  8. Is this a read-only application or a read & write?
  9. If working with an outside vendor, what is the nature of the business relationship and what are UCSF’s intellectual property interests in the project?
  10. If working with an outside vendor, are they set up as an approved vendor in Epic’s App Orchard?

 

What considerations are important before an application can move past the sandbox and onto the production path?

  1. How will clinicians interact with this application? From where will it launch? How? How will the Dashboard know who the clinical user is?

  2. How will the tool ensure that a single patient identity is maintained across different data sources?

  3. Are any of the decision support tools/algorithms validated? If not, what is the plan to make it transparent to the clinician that the tools are not validated?

  4. Technical review — What types of API calls will these tools be making? How frequently? What will the load be on our servers?

  5. What would testing this application look like? How would you perform QA tests to ensure that it works as expected and is safe?

  6. Did this application pass the full risk security assessment?

 

Fees and level of service

Applicable fees will be discussed after the intake form is submitted.

 

Explain the acronyms

API = Application Program Interface

DD&T = The Digital Diagnostics and Therapeutics Committee

BAA = Business Associates Agreement

ITA = the UCSF Office of Innovation, Technology, and Alliances

PLR = the Privacy, Legal, and Risk Committee

IRB = Institutional Review Board

CTG = Committee on Technology Governance

ACE6 = Developer SandBox

POC = Proof of Concept, initial build and unit testing

TST = Test EHR environments, simulation of production environment (production path)

SUP = Copy of PRD from previous night (contains real patient data and is refreshed nightly)

PLY = Prototyping environment connected to Clarity. Contains de-identified patient data

PRD = Production environment (EHR)

CAB = Change Control Board for the EHR

EHR = Electronic health record

DT = Developer team

PHI = Protected health information