<aside>
<img src="/icons/question-mark_orange.svg" alt="/icons/question-mark_orange.svg" width="40px" />
- Third-party audits, such as SOC 2 Type 2, ISO27001 with statement of applicability, or HITRUST.
- Results from any recent penetration tests of the system.
- A data flow diagram depicting the architecture of the system.
- Details of any existing contracts with UF, such as Business Associate Agreements (BAA) or Confidentiality Agreements, particularly related to HIPAA/Health data.
- Information on whether your systems support Single Sign-On capabilities with UF (SAMLv2 or OIDC).
- Availability of multi-factor authentication functionality.
- Hosting details of the system (e.g., AWS, Azure, Google Cloud).
- Is the data inputted into the AI used for training or learning purposes?
- Upon deletion, is the data completely removed from both the system and the AI?
- Does your system ensure segregation of the University of Florida's data from that of other customers and vendors?
- Where is the AI data processing conducted—are operations carried out within the Vendor Cloud or the client’s device?
- Could you specify whether the AI is developed in-house, licensed, or outsourced to another provider, such as OpenAI?
- Does your organization have agreements in place to protect the security and privacy of the University of Florida's data handled by the AI provider? If so, please provide details.
- Has an AI Risk Assessment been conducted in accordance with the NIST AI Risk Management Framework or an equivalent framework? If available, please share the findings.
</aside>
Recommendations
- Offload the requirements to a third party. For example, if you store all data in Azure or GCP, then have them sign the BAA, and pass along their cybersecurity audits, etc.
- Do not integrate if not needed. If your system is self-contained and does not communicate with anything the IT Dept manages, they can’t ask you for anything.
- Prepare anything that is a “template” or is “easy”, like diagrams, or “self-certified compliances”. Everything else, say you are working on it.
- Select the most common requirements (like ISO 13485 and 9001, and FDA 510k) and start working on it. 90% of the requirements are shared, and a good QMS should be useful anyway.
- Large E&O insurance policy coverage.
Our technology
1. Compliance Frameworks
Our product is designed to be HIPAA-compliant from the outset, with a strong emphasis on patient data privacy and de-identification practices. This ensures our handling of Protected Health Information (PHI) meets foundational healthcare privacy requirements.
While we have not yet adapted our infrastructure to SOC2 Type 2 compliance, we recognize the importance of implementing this standard for long-term security. We are actively exploring pathways to align our practices with SOC2 Type 2 standards, including access controls, data confidentiality, and availability monitoring. These efforts are part of a broader commitment to achieving robust compliance that aligns with the most rigorous healthcare standards in the U.S.
2. Current Security Practices in Place
Our infrastructure for [Product Name] functions as follows:
- Data Transmission: Participant audio data is transmitted securely from the VR headset to a computer connected to the hospital’s internet, which then communicates via encrypted WebSocket to our AWS-managed cloud environment.
- WebSocket Security: To enhance security, WebSocket URLs are obfuscated, stored in separate locations with different passwords, and rotated randomly.
- Data Processing: Audio data received in AWS is processed using Amazon Transcribe (speech-to-text) and then fed into our in-house LLAMA AI model, fully deployed and managed within AWS. We do not use third-party systems such as OpenAI for this model.
- Data Output and De-Identification: The AI’s text responses are converted to audio via Amazon Polly and sent back to the participant via WebSocket. All transcriptions and responses are de-identified using spaCy before being relayed to our research assistant through encrypted Telegram messages. Additionally, de-identified data is stored in an AWS database for long-term analysis.
(Are there any additional access control details on the AWS side, such as IAM roles or AWS Shield, that could be mentioned here to add further clarity?)
3. Leveraging AWS for Compliance and Security
Our system is hosted entirely on AWS, which is certified for SOC2, SOC3, ISO27001, and HIPAA eligibility. This foundational infrastructure provides our baseline security, covering data encryption, access control, and incident response. These services are monitored and independently audited, ensuring that we meet industry standards for data security and compliance.