OpenDocket — medplum

Compliance Risk Analysis

medplum

https://github.com/medplum/medplum
Scanned 2026-03-23 · OpenDocket V1 · Primary: Claude Sonnet · Review: Gemini 2.5 Flash

Important Limitations of This Report

This report is not legal advice and is not defensible in court. It provides directional guidance only. To obtain a defensible compliance assessment, engage a licensed attorney and certified auditor.

Scope limitations: Only public repository content was analyzed. Infrastructure configuration, deployment settings, operational policies, vendor contracts, and staff training are outside scope.

A true compliance audit would also review: vendor contracts and BAAs, staff training records, incident response procedures, physical security controls, and system audit logs — none of which are visible in source code.

Risk Assessment

This analysis identified 56 compliance patterns across GDPR, HIPAA, PCI-DSS, SOC2, SOX, TCPA. After independent verification by Gemini 2.5 Flash, 8 high-severity findings were confirmed and 45 were identified as possible false positives — likely pattern matches in documentation or configuration files rather than application source code. The 8 confirmed findings represent the primary areas requiring attention.

ELEVATED RISK

8 confirmed high-severity findings
47 total patterns identified · 45 flagged as possible false positives by independent review

What This Means If Unaddressed

Framework	Regulatory Body	Max Penalty	Enforcement Trend
GDPR (9 high)	EU DPAs	Up to EUR 20M or 4% turnover	Cross-border enforcement rising
TCPA (8 high)	FCC	$500-$1,500 per violation	Class action filings at record levels
PCI-DSS (8 high)	PCI SSC	Fines $5K-$100K/month	v4.0 enforcement accelerating
HIPAA (8 high)	HHS / OCR	Fines up to $1.5M/year per category	Increasing enforcement, record penalties in 2024
SOX (7 high)	SEC / PCAOB	Criminal penalties, delisting	IT controls under increased scrutiny
SOC2 (7 high)	AICPA	Loss of enterprise contracts	Mandatory for enterprise SaaS sales

Top Findings

High RiskGDPRGDPR-001SECURITY.md:15 · Review: CONFIRMED

The development team must conduct a comprehensive data processing audit to identify all personal data processing activities within the system, then document the specific lawful basis under GDPR Articl

High RiskHIPAAHIPAA-008.github/labeler.yml:41 · Review: CONFIRMED

Implement documentation and configuration controls that demonstrate BAA compliance for all third-party integrations. This should include: (1) adding configuration files or code comments that reference

High RiskPCI-DSSPCIDSS-007.vscode/settings.json:24 · Review: CONFIRMED

Implement comprehensive audit logging that captures: (1) all individual access attempts to cardholder data with user identification, timestamps, and data elements accessed; (2) all actions performed b

Gemini Verification Layer

How to read this: The confirmed count is your action list. The false positive count shows where the scanner found keyword patterns in documentation rather than application source code. Click any finding to see exactly what evidence was found and why Gemini made its determination.

10Confirmed

1Context dependent

45Possible false positives

0Additional risk

Primary: Claude Sonnet (Anthropic). Verification: Gemini 2.5 Flash (Google). Neither constitutes legal advice.

Recommended Actions

High

Review the specific consent mechanisms found in `examples/foomedical/src/pages/PatientIntakeQuestionnairePage.tsx` and across the Medplum system, to verify they meet GDPR Article 6 requirements for all identified data processing activities. Document the explicit lawful basis for each personal data processing activity to avoid severe penalties for non-compliance.

GDPR · GDPR-001 · Confirmed

High

For the processing of patient health data, specifically BMI tracking as described in `examples/medplum-demo-bots/src/bmi-calculation-bot/bmi-calculation-bot.ts` and its `README.md`, conduct and document a comprehensive Data Protection Impact Assessment. This is required to evaluate privacy risks and demonstrate compliance with GDPR Article 35.

GDPR · GDPR-009 · Confirmed

High

Update `.github/workflows/build-agent.yml` to include explicit comments or configuration entries affirming the existence of a Business Associate Agreement with Azure for any PHI processing enabled by the `azure/login` action. Similarly, ensure the `medplum-photon-integration` example, referenced in `.github/labeler.yml`, is updated with BAA documentation if it handles PHI, as omitting such details constitutes a HIPAA violation.

HIPAA · HIPAA-008 · Confirmed

High

Before allowing the `membership-and-billing` route and its associated functionality in `examples/foomedical/src/Router.tsx` to process or store live cardholder data, the development team must integrate a PCI-DSS compliant payment gateway or verify that any stored Primary Account Numbers (PANs) are rendered unreadable via strong cryptography, as mandated by PCI DSS Requirement 3.5 to prevent data breaches.

PCI-DSS · PCIDSS-001 · Confirmed

High

Verify that the `AuditEvent` objects referenced in `examples/medplum-demo-bots/src/resource-usage/resource-usage.ts` and related logging mechanisms comprehensively capture all individual access to cardholder data, administrative actions, and access to audit trails. Failure to do so results in non-compliance with PCI DSS Requirement 10.

PCI-DSS · PCIDSS-007 · Confirmed

+ 6 more recommendations in the Findings tab

Risk Scorecard

Framework	High Risk	Confirmed	False Pos.	Medium	Concern
GDPR	9	3	6	1	0
HIPAA	8	2	8	2	0
PCI-DSS	8	2	8	1	1
SOC2	7	1	9	1	2
SOX	7	1	7	1	0
TCPA	8	1	7	0	0

Domains Detected

Saas

92.2%

Healthcare

90.0%

Ecommerce

69.8%

Fintech

53.0%

Communication

41.1%

Gdpr

14.2%

HIPAA

HHS / OCR · Fines up to $1.5M/year per category

10 findings · 8 possible FP

HIPAA-008

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The repository's healthcare domain, combined with evidence of third-party integrations (Azure login in CI/CD and a Photon integration example), directly triggers the HIPAA BAA requirement; the absence of BAA-related configuration or code indicates a clear risk.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/labeler.yml:41 - examples/medplum-photon-integration/src/**/* [CONFIG] .github/labeler.yml:43 integration: [CONFIG] .github/workflows/build-agent.yml:31 id-token: write # Required for OIDC authentication with Azure Trusted Signing [CONFIG] .github/workflows/build-agent.yml:137 - name: Login to Azure [CONFIG] .github/workflows/build-agent.yml:139 uses: azure/login@a457da9ea143d694b1b9c7c869ebb04ebe844ef5 # v2.3.0 [CONFIG] .github/workflows/build-agent.yml:141 client-id: ${{ secrets.AZURE_CLIENT_ID }} [CONFIG] .github/workflows/build-agent.yml:142 tenant-id: ${{ secrets.AZURE_TENANT_ID }} [CONFIG] .github/workflows/build-agent.yml:143 subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Finding

Does the system integrate with third-party services that may receive, maintain, or transmit Protected Health Information, and if so, is there evidence that Business Associate Agreement requirements are addressed in the code or configuration?

Remediation

Remediation refined by Gemini review

HIPAA-006

Medium Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The application source code (`examples/medplum-demo-bots/src/resource-usage/resource-usage.ts`) directly references 'AuditEvent', indicating the system's explicit engagement with audit event tracking for healthcare resources, which is central to HIPAA audit controls.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .vscode/settings.json:24 "cSpell.words": ["auditevent", "bullmq", "FHIR", "Fhircast", "Medplum"] [DOCS] SECURITY.md:7 Medplum uses enterprise-grade security and regular audits to ensure you're always protected. We unde [DOCS] SECURITY.md:24 - Third-Party Audits - Our organization undergoes independent third-party assessments to test our se [CONFIG] charts/templates/backendconfig.yaml:23 logging: [SOURCE] examples/medplum-demo-bots/src/resource-usage/resource-usage.ts:70 const auditEventCount = counts['AuditEvent'] || 0; [SOURCE] examples/medplum-demo-bots/src/resource-usage/resource-usage.ts:71 const totalResourcesMinusAuditEvent = totalResources - auditEventCount; [SOURCE] examples/medplum-demo-bots/src/resource-usage/resource-usage.ts:80 ['Counted Resources (total excluding AuditEvent)', totalResourcesMinusAuditEvent.toString()], [SOURCE] examples/medplum-demo-bots/src/resource-usage/resource-usage.ts:152 'AuditEvent',

Finding

Does the system implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information, as required under the audit controls standard?

Remediation

The system must ensure that the `AuditEvent` generation, as hinted by `counts['AuditEvent']` in `examples/medplum-demo-bots/src/resource-usage/resource-usage.ts`, fully and automatically records all PHI access, creation, modification, and deletion events, including user, timestamp, and detailed action context. This is crucial for satisfying HIPAA audit controls (HIPAA-006) for ePHI activity logging.

Remediation refined by Gemini review

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

HIPAA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files, which, while indicating a healthcare context (e.g., 'medications', 'graphiql'), do not directly confirm that the application's source code collects, stores, processes, or transmits Protected Health Information (PHI) or lacks specific safeguards.

Evidence

[CONFIG] .github/labeler.yml:38 medications: [CONFIG] .gitignore:23 packages/graphiql/public/ [CONFIG] .gitignore:23 packages/graphiql/public/ [DOCS] README.md:102 │ ├── graphiql # Preconfigured GraphiQL [DOCS] README.md:102 │ ├── graphiql # Preconfigured GraphiQL [DOCS] SECURITY.md:23 - Security Awareness Training - Our team members are required to go through employee security awaren [DOCS] SECURITY.md:57 - Social engineering, phishing, or physical attacks against Medplum employees, users, or infrastruct [DOCS] SECURITY.md:66 Our philosophy on this is aligned with the principles outlined in Troy Hunt's post on "Beg Bounties,

Finding

Does this system collect, store, process, or transmit individually identifiable health information as defined under 45 CFR §160.103, and if so, are adequate technical safeguards in place to protect the confidentiality of such Protected Health Information?

Remediation

Verify if the `graphiql` interface, referenced in `README.md` and excluded from `packages/graphiql/public/` in `.gitignore`, can access data containing Protected Health Information. If so, restrict `graphiql` access to ensure unauthorized users cannot query PHI, preventing potential unauthorized disclosure as per HIPAA Security Rule §164.312(a)(1).

HIPAA-002 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and a configuration file comment, which are insufficient to definitively confirm whether electronic Protected Health Information (ePHI) is encrypted at rest using methods consistent with NIST Special Publication 800-111 from a technical implementation perspective.

Evidence

[DOCS] SECURITY.md:13 - Encryption - Data is encrypted in transit with TLS 1.2 and 1.3. Data is encrypted at rest with AES [DOCS] SECURITY.md:13 - Encryption - Data is encrypted in transit with TLS 1.2 and 1.3. Data is encrypted at rest with AES [DOCS] SECURITY.md:55 - Reports of insecure SSL/TLS ciphers or protocol versions. [DOCS] SECURITY.md:13 - Encryption - Data is encrypted in transit with TLS 1.2 and 1.3. Data is encrypted at rest with AES [CONFIG] charts/values.yaml:12 # type: "azure:keyVaultURL:secretName" [SOURCE] examples/medplum-demo-bots/src/billing-bots/superbill.test.ts:13 import { randomUUID } from 'crypto'; [SOURCE] examples/medplum-demo-bots/src/epic/epic-query-patient.test.ts:20 import { generateKeyPairSync } from 'crypto'; [SOURCE] examples/medplum-demo-bots/src/epic/epic-query-patient.ts:6 import { createPrivateKey, randomBytes } from 'crypto';

Finding

Is electronic Protected Health Information encrypted when stored at rest using methods consistent with NIST Special Publication 800-111, as required for addressable implementation under the HIPAA Security Rule?

Remediation

Update `SECURITY.md` to specify the exact AES implementation (e.g., AES-256) and document comprehensive key management procedures, including key generation, storage, rotation, and destruction, demonstrating alignment with NIST SP 800-111 requirements. Providing these technical details is essential to establish clear evidence of compliance with the HIPAA Security Rule for electronic Protected Health Information encryption at rest.

HIPAA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

All cited evidence consists solely of GitHub configuration files, which are not application source code, and the specific lines referenced demonstrate the use of HTTPS for external connections, not a lack of encryption.

Evidence

[CONFIG] .github/CODEOWNERS:2 # See: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/custo [CONFIG] .github/workflows/add-issue-to-project.yml:21 project-url: https://github.com/orgs/medplum/projects/1 [CONFIG] .github/workflows/add-issue-to-project.yml:25 project-url: https://github.com/orgs/medplum/projects/3 [CONFIG] .github/workflows/build-agent.yml:50 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-agent.yml:52 # See: https://github.com/actions/cache/blob/cdf6c1fa76f9f475f3d7449005a359c84ca0f306/examples.md#no [CONFIG] .github/workflows/build-agent.yml:93 * Taken from https://github.com/dlemstra/code-sign-action [CONFIG] .github/workflows/build-agent.yml:162 endpoint: https://eus.codesigning.azure.net/ [CONFIG] .github/workflows/build-agent.yml:231 registry-url: 'https://registry.npmjs.org'

Finding

Are all transmissions of electronic Protected Health Information encrypted using transport-level security consistent with NIST guidelines, preventing unauthorized access during transmission across electronic communications networks?

Remediation

No changes are required in the files .github/workflows/add-issue-to-project.yml or .github/workflows/build-agent.yml based on the provided evidence, as the referenced 'project-url' and 'registry-url' values already correctly specify HTTPS, aligning with HIPAA requirements for protecting PHI during transit.

HIPAA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of .github configuration files related to repository management and CI/CD, which do not directly demonstrate the implementation or lack of application-level technical access controls for ePHI as required by the legal question; these files merely reference application code paths.

Evidence

[CONFIG] .github/labeler.yml:22 - packages/server/src/oauth/**/* [CONFIG] .github/labeler.yml:24 - packages/server/src/fhir/accesspolicy.ts [CONFIG] .github/workflows/add-issue-to-project.yml:11 permissions: [CONFIG] .github/workflows/add-issue-to-project.yml:22 github-token: ${{ secrets.MEDPLUM_BOT_GITHUB_ACCESS_TOKEN }} [CONFIG] .github/workflows/add-issue-to-project.yml:26 github-token: ${{ secrets.MEDPLUM_BOT_GITHUB_ACCESS_TOKEN }} [CONFIG] .github/workflows/assign-pull-request.yml:7 permissions: [CONFIG] .github/workflows/assign-pull-request.yml:14 permissions: [CONFIG] .github/workflows/autofix-ci.yml:11 permissions:

Finding

Does the system implement technical policies and procedures for electronic information systems that maintain electronic Protected Health Information to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR §164.312(a)(1)?

Remediation

Verify that the logic within `packages/server/src/fhir/accesspolicy.ts` (as referenced in `.github/labeler.yml`) explicitly implements technical policies for ePHI access, ensuring only authorized persons or programs can access it, in accordance with 45 CFR §164.312(a)(1).

HIPAA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The 'timeout-minutes' in GitHub Actions workflow files specifies the maximum duration for CI/CD jobs, not the inactivity timeout for user-facing sessions accessing PHI.

Evidence

[CONFIG] .github/workflows/build-agent.yml:22 timeout-minutes: 45 [CONFIG] .github/workflows/build-agent.yml:214 timeout-minutes: 45 [CONFIG] .github/workflows/build-agent.yml:296 timeout-minutes: 45 [CONFIG] .github/workflows/build-agent.yml:378 timeout-minutes: 45 [CONFIG] .github/workflows/build-deb.yml:19 timeout-minutes: 45 [CONFIG] .github/workflows/build-helm-charts.yml:19 timeout-minutes: 45 [CONFIG] .github/workflows/build.yml:21 timeout-minutes: 45 [CONFIG] .github/workflows/build.yml:79 timeout-minutes: 20

Finding

Does the system implement electronic procedures that terminate an electronic session after a predetermined time of inactivity, as required for PHI-accessing interfaces under the HIPAA Security Rule?

Remediation

The `timeout-minutes` settings in `.github/workflows/build-agent.yml` and `.github/workflows/build-deb.yml` govern CI/CD job execution, not user-facing application sessions. No changes are required in these specific files regarding HIPAA session management, as they do not impact PHI access duration for users.

HIPAA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, `.github/workflows/build-agent.yml`, is a CI/CD configuration file where credential exclusion enhances build pipeline security rather than indicating a lack of minimum necessary access controls for Protected Health Information within the application.

Evidence

[CONFIG] .github/workflows/build-agent.yml:152 exclude-azure-cli-credential: true [CONFIG] .github/workflows/build-agent.yml:153 exclude-environment-credential: true [CONFIG] .github/workflows/build-agent.yml:154 exclude-workload-identity-credential: true [CONFIG] .github/workflows/build-agent.yml:155 exclude-managed-identity-credential: true [CONFIG] .github/workflows/build-agent.yml:156 exclude-shared-token-cache-credential: true [CONFIG] .github/workflows/build-agent.yml:157 exclude-visual-studio-credential: true [CONFIG] .github/workflows/build-agent.yml:158 exclude-visual-studio-code-credential: true [CONFIG] .github/workflows/build-agent.yml:159 exclude-azure-powershell-credential: false

Finding

Does the system limit the Protected Health Information disclosed or accessed to the minimum necessary to accomplish the intended purpose, consistent with the minimum necessary standard under the Privacy Rule?

Remediation

No modification to `.github/workflows/build-agent.yml` is required, as the configured credential exclusions are security hardening measures for the build pipeline, not a direct indicator of non-compliance with HIPAA's minimum necessary access standard for PHI at the application level.

HIPAA-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files (GitHub workflow retention-days, Dockerfile comments, and auto_assign.yml), which do not directly demonstrate the absence of comprehensive policies and procedures for the final disposition of ePHI from primary storage media.

Evidence

[CONFIG] .github/auto_assign.yml:9 - mattlong [CONFIG] .github/workflows/build.yml:383 retention-days: 30 [CONFIG] .github/workflows/scorecard.yml:73 retention-days: 5 [CONFIG] Dockerfile:7 # The archive files are decompressed and extracted into the specified destinations. [CONFIG] Dockerfile:9 # See: https://docs.docker.com/reference/dockerfile/#adding-local-tar-archives [CONFIG] biome.json:50 "noDelete": "warn" [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1298 display: 'I could use a little more help', [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:2073 display: 'Little interest or pleasure in doing things?',

Finding

Does the system implement policies and procedures to address the final disposition of electronic Protected Health Information and the hardware or electronic media on which it is stored, as well as removal of PHI before media is available for reuse?

Remediation

While `.github/workflows/build.yml` and `.github/workflows/scorecard.yml` show artifact `retention-days`, this evidence does not directly confirm the lack of comprehensive PHI disposal policies for primary systems. Evaluate whether CI/CD artifacts generated through these workflows could inadvertently contain PHI and, if so, align their retention policies with HIPAA's secure disposal requirements to avoid potential unauthorized exposure.

HIPAA-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence, which consists of `restore-keys` in GitHub Actions workflow configuration files, is related to CI/CD caching and is unrelated to the system's procedures for breach detection, reporting, incident response, or emergency access to PHI.

Evidence

[CONFIG] .github/workflows/build-agent.yml:65 restore-keys: | [CONFIG] .github/workflows/build-agent.yml:240 restore-keys: | [CONFIG] .github/workflows/build-agent.yml:322 restore-keys: | [CONFIG] .github/workflows/build-agent.yml:404 restore-keys: | [CONFIG] .github/workflows/build.yml:47 restore-keys: | [CONFIG] .github/workflows/build.yml:101 restore-keys: | [CONFIG] .github/workflows/build.yml:209 restore-keys: | [CONFIG] .github/workflows/build.yml:311 restore-keys: |

Finding

Does the system implement procedures for detecting, reporting, and responding to suspected or known security incidents involving electronic Protected Health Information, and does it provide for emergency access to PHI during system disruptions?

Remediation

The `restore-keys` entries in `.github/workflows/build-agent.yml` and `build.yml` relate to CI/CD cache management and do not directly indicate a lack of HIPAA incident detection or emergency access procedures. Therefore, no specific changes to these lines are required to comply with HIPAA 164.308(a)(6)(ii) and 164.312(a)(2)(ii).

PCI-DSS

PCI SSC · Fines $5K-$100K/month

10 findings · 8 possible FP

PCIDSS-001

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The 'MembershipAndBilling' route in `examples/foomedical/src/Router.tsx` strongly indicates the application's intent to handle payment-related information, which, given the detected `fintech` and `ecommerce` domains, makes the potential for processing or storing cardholder data highly likely and directly relevant to PCI DSS Requirement 3.5.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/workflows/scorecard.yml:52 # repo_token: ${{ secrets.SCORECARD_TOKEN }} [CONFIG] charts/templates/_helpers.tpl:2 Expand the name of the chart. [CONFIG] charts/templates/_helpers.tpl:17 We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming s [SOURCE] examples/foomedical/src/Router.tsx:6 import { MembershipAndBilling } from './pages/account/MembershipAndBilling'; [SOURCE] examples/foomedical/src/Router.tsx:66 <Route path="membership-and-billing" element={<MembershipAndBilling />} /> [SOURCE] examples/foomedical/src/components/SideMenu.tsx:29 <span>{item.name}</span> [SOURCE] examples/foomedical/src/components/SideMenu.tsx:34 <span>{subItem.name}</span>

Finding

Does this system store, process, or transmit cardholder data including primary account numbers (PAN), and if so, are adequate protections in place to render stored PAN unreadable, as required under PCI DSS Requirement 3.5?

Remediation

Remediation refined by Gemini review

PCIDSS-007

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The source code reference to `AuditEvent` in `examples/medplum-demo-bots/src/resource-usage/resource-usage.ts` confirms that auditing is a concept within the application, making the primary analysis question about the comprehensiveness of audit logging for cardholder data under PCI DSS Requirement 10 a relevant and valid risk.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

Finding

Does the system implement audit trail mechanisms that record all individual access to cardholder data, all actions taken by any individual with root or administrative privileges, and all access to audit trails, as required under PCI DSS Requirement 10?

Remediation

Remediation refined by Gemini review

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

PCIDSS-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence solely consists of generic GitHub configuration and workflow files, with none of the cited lines indicating any direct handling, storage, or transmission of cardholder data to assess encryption practices.

Evidence

Finding

Is cardholder data encrypted using strong cryptography during transmission over open public networks and when stored at rest, consistent with PCI DSS Requirements 3.5 and 4.2?

Remediation

The evidence from `.github/CODEOWNERS` and `.github/workflows/*.yml` does not contain any cardholder data or related encryption configurations, therefore no specific modifications are needed within these files. Organizations handling cardholder data must apply strong cryptography for data in transit and at rest, per PCI DSS Requirements 3.5 and 4.2.

PCIDSS-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of GitHub configuration files, which govern CI/CD permissions and repository automation, not the application's runtime access control for cardholder data, making it unlikely to directly indicate a lack of PCI DSS Requirement 7 compliance.

Evidence

[CONFIG] .github/labeler.yml:24 - packages/server/src/fhir/accesspolicy.ts [CONFIG] .github/workflows/add-issue-to-project.yml:11 permissions: [CONFIG] .github/workflows/assign-pull-request.yml:7 permissions: [CONFIG] .github/workflows/assign-pull-request.yml:14 permissions: [CONFIG] .github/workflows/autofix-ci.yml:11 permissions: [CONFIG] .github/workflows/autofix-ci.yml:17 permissions: [CONFIG] .github/workflows/build-agent.yml:16 permissions: [CONFIG] .github/workflows/build-agent.yml:28 permissions:

Finding

Does the system restrict access to cardholder data to only those individuals and systems whose job requires such access, implementing role-based access controls consistent with PCI DSS Requirement 7?

Remediation

The permissions defined in `.github/workflows/*.yml` control GitHub Actions workflow access and do not directly address application-level role-based access controls for cardholder data. Verify that `packages/server/src/fhir/accesspolicy.ts` and related application code implement robust RBAC to restrict access to cardholder data, aligning with PCI DSS Requirement 7 to prevent unauthorized access.

PCIDSS-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files and documentation, without any application source code, which according to the decision rules classifies it as a possible false positive for network segmentation implementation.

Evidence

[DOCS] README.md:115 Thanks to [Chromatic](https://www.chromatic.com/) for providing the visual testing platform that hel [CONFIG] charts/templates/backendconfig.yaml:1 {{- if and (eq .Values.global.cloudProvider "gcp") (eq .Values.ingress.deploy true) }} [CONFIG] charts/templates/backendconfig.yaml:11 name: ingress-security-policy [CONFIG] charts/templates/frontendconfig.yaml:1 {{- if and (eq .Values.global.cloudProvider "gcp") (eq .Values.ingress.deploy true) }} [CONFIG] charts/templates/ingress.yaml:1 {{- if and (eq .Values.global.cloudProvider "gcp") (eq .Values.ingress.deploy true) }} [CONFIG] charts/templates/ingress.yaml:3 kind: Ingress [CONFIG] charts/templates/ingress.yaml:10 ingressClassName: "gce" [CONFIG] charts/templates/ingress.yaml:11 kubernetes.io/ingress.global-static-ip-name: medplum-external-ip

Finding

Does the system implement network segmentation to isolate the cardholder data environment (CDE) from other network segments, reducing the scope of PCI DSS compliance as described in Requirement 1?

Remediation

Review `charts/templates/backendconfig.yaml`, `charts/templates/frontendconfig.yaml`, and `charts/templates/ingress.yaml` to explicitly define and enforce network segmentation rules, such as `ingress-security-policy`, that isolate the Cardholder Data Environment (CDE) from all other network segments. Failure to do so risks non-compliance with PCI DSS Requirement 1 regarding CDE isolation.

PCIDSS-005 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (.yaml) and does not directly demonstrate a lack of vulnerability management practices as required by the verdict rules.

Evidence

[CONFIG] .github/workflows/build-agent.yml:8 workflow_dispatch: [CONFIG] .github/workflows/build-agent.yml:115 console.warn('Skipping %s due to error.', signtoolFilename); [CONFIG] .github/workflows/build-deb.yml:11 workflow_dispatch: [CONFIG] .github/workflows/build-deb.yml:81 --gpg-options="--passphrase-fd 0 --pinentry-mode loopback" \ [CONFIG] .github/workflows/build-helm-charts.yml:11 workflow_dispatch: [CONFIG] .github/workflows/build.yml:251 uses: SonarSource/sonarqube-scan-action@01850e2590cc09ed26831056406ae1525aa41ad5 # master [CONFIG] .github/workflows/build.yml:187 --health-cmd "redis-cli ping" [CONFIG] .github/workflows/build.yml:289 --health-cmd "redis-cli ping"

Finding

Does the system demonstrate evidence of vulnerability management practices including regular patching, dependency updates, and vulnerability scanning, consistent with PCI DSS Requirement 6?

Remediation

Integrate automated dependency and vulnerability scanning (e.g., via Dependabot, Snyk, or Trivy) directly into the build workflows defined in files such as `.github/workflows/build-agent.yml`, `.github/workflows/build-deb.yml`, and `.github/workflows/build-helm-charts.yml`. This action helps ensure all built artifacts are checked for known vulnerabilities before release, satisfying PCI DSS Requirement 6.2 for protecting systems from known vulnerabilities.

PCIDSS-006 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of CI/CD configuration files showing the use of ESLint, which does not definitively confirm the absence of other PCI DSS required security testing controls such as dedicated SAST, DAST, or penetration testing practices.

Evidence

[CONFIG] .github/workflows/autofix-ci.yml:28 - run: npm run lint:fix [CONFIG] .github/workflows/build.yml:76 eslint: [CONFIG] .github/workflows/build.yml:77 name: Run eslint [CONFIG] .github/workflows/build.yml:84 eslint_errs: ${{ steps.fmt.outputs.eslint_errs }} [CONFIG] .github/workflows/build.yml:106 name: Install eslint [CONFIG] .github/workflows/build.yml:121 - name: Run eslint [CONFIG] .github/workflows/build.yml:125 npm run lint 2> eslint.err > eslint1.err || echo 'failed' > .failed [CONFIG] .github/workflows/build.yml:129 echo "eslint_errs<<${delimiter}" >> "${GITHUB_OUTPUT}"

Finding

Does the system implement security testing controls including code review, static analysis, and penetration testing practices, as required under PCI DSS Requirement 6.3 and 11.4?

Remediation

Modify `.github/workflows/autofix-ci.yml` and `.github/workflows/build.yml` to integrate a dedicated security-focused static analysis tool (e.g., Semgrep, CodeQL, Snyk) alongside or in addition to ESLint, and establish external penetration testing procedures. This is necessary to meet PCI DSS Requirements 6.3.2 for comprehensive application security testing and 11.4 for maintaining a robust vulnerability management program.

PCIDSS-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, particularly the source code snippets from `ChargeItemPanel.tsx`, clearly refers to UI rendering keys (React `key` prop) and not cryptographic keys, indicating a fundamental misinterpretation of the context regarding key management practices.

Evidence

[CONFIG] charts/values.yaml:12 # type: "azure:keyVaultURL:secretName" [CONFIG] examples/medplum-photon-integration/photon-webhook.png:430 qC%M27']I)O\׎O;ǮsEcIJ:3\_1pNnmzfU+^ϫiV;|VO1'眇1dO^)r9[9̕tv){fzϔoUٷ//º%DEkl~7rOc@f [CONFIG] examples/medplum-photon-integration/photon-webhook.png:1466 iOw&b_rk(4grR}֔im?x)],a{DB >Z [SOURCE] examples/medplum-provider/src/components/ChargeItem/ChargeItemPanel.tsx:77 const cptCodeKey = `cpt-${chargeItem.id}-${JSON.stringify(cptCodes?.coding)}`; [SOURCE] examples/medplum-provider/src/components/ChargeItem/ChargeItemPanel.tsx:86 key={cptCodeKey} [SOURCE] examples/medplum-smart-on-fhir-demo/src/pages/LaunchPage.tsx:37 async function fetchSmartConfiguration(iss: string): Promise<SmartConfiguration> {

Finding

Does the system implement cryptographic key management procedures including key generation, distribution, storage, rotation, and destruction, consistent with PCI DSS Requirement 3.6 and 3.7?

Remediation

The identified lines `examples/medplum-provider/src/components/ChargeItem/ChargeItemPanel.tsx:77` and `86` refer to unique identifiers for list rendering, not cryptographic keys. No changes are required to these specific lines concerning PCI DSS Requirement 3.6 or 3.7.

PCIDSS-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided exclusively cites configuration files (`.github/labeler.yml`, `.github/workflows/*.yml`), which, according to the mandatory decision rules, leads to a verdict of POSSIBLE FALSE POSITIVE as it does not include application source code files to confirm direct interaction with or exposure of cardholder data.

Evidence

[CONFIG] .github/labeler.yml:41 - examples/medplum-photon-integration/src/**/* [CONFIG] .github/labeler.yml:43 integration: [CONFIG] .github/workflows/autofix-ci.yml:21 - uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 [CONFIG] .github/workflows/build-agent.yml:33 - name: Checkout repository [CONFIG] .github/workflows/build-agent.yml:34 uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 [CONFIG] .github/workflows/build-agent.yml:224 - name: Checkout repository [CONFIG] .github/workflows/build-agent.yml:225 uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 [CONFIG] .github/workflows/build-agent.yml:306 - name: Checkout repository

Finding

Does the system manage third-party service providers that have access to cardholder data with appropriate controls, agreements, and monitoring, consistent with PCI DSS Requirement 12.8?

Remediation

Review the usage of `actions/checkout` within `.github/workflows/autofix-ci.yml` and `.github/workflows/build-agent.yml` to determine if the CI/CD pipelines interact with or have potential access to cardholder data. If such access is confirmed, establish a formal third-party service provider management program for GitHub Actions, including due diligence and contractual agreements, to ensure compliance with PCI DSS Requirement 12.8.

PCIDSS-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation and configuration files, none of which directly demonstrate the presence or absence of a PCI DSS-compliant incident response plan specifically for cardholder data breaches, as required by Requirement 12.10.

Evidence

[DOCS] LICENSE.txt:158 incidental, or consequential damages of any character arising as a [DOCS] README.md:1 # [Medplum](https://www.medplum.com) · [![GitHub license](https://img.shields.io/badge/licens [DOCS] SECURITY.md:14 - Continuous Monitoring - Independent third-party penetration, threat, and vulnerability testing. [DOCS] SECURITY.md:27 - Continuous Monitoring - We continuously monitor our security and compliance status to ensure there [CONFIG] charts/values.yaml:55 allowPrivilegeEscalation: false [DOCS] examples/foomedical/README.md:11 <img src="https://sonarcloud.io/api/project_badges/measure?project=medplum_foomedical&metric=alert_s [CONFIG] examples/foomedical/package.json:25 "@mantine/notifications": "8.3.18", [SOURCE] examples/foomedical/src/main.tsx:5 import { Notifications } from '@mantine/notifications';

Finding

Does the system implement an incident response plan that addresses suspected or confirmed cardholder data breaches, including detection, containment, and notification procedures, as required under PCI DSS Requirement 12.10?

Remediation

Update `SECURITY.md` to include or clearly reference a comprehensive incident response plan that details procedures for the detection, containment, and notification of suspected or confirmed cardholder data breaches, as explicitly required by PCI DSS Requirement 12.10. Failure to document this plan risks non-compliance and potential severe penalties for data breaches.

SOC2

AICPA · Loss of enterprise contracts

10 findings · 9 possible FP

SOC2-010

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The README.md serves as a principal entry point for the Medplum repository. Given the highly regulated domains (healthcare, SaaS, GDPR), the absence of clear references or links to security policies (acceptable use, data classification, access management) within this prominent documentation is a direct failure to "demonstrate evidence of documented security policies" as required by SOC2 CC1.1. Therefore, the .md file, by its omission, serves as direct evidence of this compliance gap.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[DOCS] README.md:17 - [Contributing](#contributing) [DOCS] README.md:23 ## Contributing [DOCS] README.md:28 limited scope -- it's our entire product. Our [Contributing documentation](https://medplum.com/docs/ [DOCS] README.md:49 Did you learn how to do something using Medplum that wasn't obvious on your first try? By contributi [DOCS] README.md:67 **Ready to get started writing code?** Follow the [local setup instructions](https://www.medplum.com [DOCS] packages/app/README.md:44 For more information, refer to the [Developer Instructions](https://www.medplum.com/docs/contributin [DOCS] packages/cdk/README.md:16 See [Developer Setup](https://www.medplum.com/docs/contributing) for cloning the repository and inst [DOCS] packages/docs/blog/2025-05-15-so-youre-thinking-about-forking.md:31 | **Talent attraction** | Engineers prefer contributing to widely‑used projects; recruiting for a

Finding

Does the system demonstrate evidence of documented security policies, including acceptable use, data classification, and access management policies, as required under CC1.1 for the entity's commitment to integrity and ethical values?

Remediation

The README.md (lines 17, 23, 28, 49, 67) must be updated to clearly reference or link to the organization's formal security policies, including those for acceptable use, data classification, and access management. Failure to demonstrably document these policies through accessible means like the README.md violates SOC2 CC1.1 requirements for demonstrating integrity and ethical values.

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOC2-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (`.github/*.yml`) which indicate the presence of OAuth code and CI/CD authentication, but do not directly confirm the implementation or effectiveness of end-user authentication controls for the application itself, as required by the SOC2-001 question.

Evidence

[CONFIG] .github/labeler.yml:22 - packages/server/src/oauth/**/* [CONFIG] .github/workflows/add-issue-to-project.yml:22 github-token: ${{ secrets.MEDPLUM_BOT_GITHUB_ACCESS_TOKEN }} [CONFIG] .github/workflows/add-issue-to-project.yml:26 github-token: ${{ secrets.MEDPLUM_BOT_GITHUB_ACCESS_TOKEN }} [CONFIG] .github/workflows/build-agent.yml:31 id-token: write # Required for OIDC authentication with Azure Trusted Signing [CONFIG] .github/workflows/build-agent.yml:137 - name: Login to Azure [CONFIG] .github/workflows/build-agent.yml:139 uses: azure/login@a457da9ea143d694b1b9c7c869ebb04ebe844ef5 # v2.3.0 [CONFIG] .github/workflows/build-agent.yml:31 id-token: write # Required for OIDC authentication with Azure Trusted Signing [CONFIG] .github/workflows/build-agent.yml:146 - name: Sign executables with Azure Trusted Signing

Finding

Does the system implement logical access security controls over user authentication that are suitably designed and operating effectively to restrict access to authorized users, consistent with the Common Criteria CC6.1 requirement for logical and physical access controls?

Remediation

The development team should provide specific source code samples from the `packages/server/src/oauth` directory (as referenced in `.github/labeler.yml:22`) that demonstrate implemented user authentication controls like authentication middleware, session management, password policies, or multi-factor authentication. Failure to demonstrate these effective controls could result in non-compliance with SOC2 Common Criteria CC6.1, exposing the system to unauthorized access risks.

SOC2-002 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of GitHub configuration files (.yml), which do not directly demonstrate the application's implementation of role-based access control for end-users, thus making it an indirect finding.

Evidence

Finding

Does the system implement role-based or attribute-based access controls that restrict system functions and data access based on authorized user roles, consistent with the principle of least privilege as required under CC6.3?

Remediation

Review `packages/server/src/fhir/accesspolicy.ts` and related application code to document and clearly articulate how user roles are defined and how least privilege principles are enforced. This will provide verifiable evidence for compliance with SOC2 CC6.3 regarding the restriction of system functions and data access.

SOC2-003 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of config files showing URLs that already use HTTPS (e.g., `https://registry.npmjs.org`, `https://github.com`), directly contradicting the 'Pattern of Concern' for missing encryption in transit.

Evidence

Finding

Does the system protect data during transmission over networks using encryption or other equivalent security measures, consistent with the CC6.7 requirement for protection of information during transmission?

Remediation

No changes are required in the referenced lines of `.github/CODEOWNERS`, `.github/workflows/add-issue-to-project.yml`, or `.github/workflows/build-agent.yml` as all contained URLs (e.g., `https://registry.npmjs.org`, `https://github.com`) already employ HTTPS. This ensures data protection during transmission, consistent with SOC2 CC6.7 requirements.

SOC2-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of documentation and a spell-check configuration, which does not directly demonstrate the presence or absence of logging, monitoring, and alerting mechanisms within the application's implementation.

Evidence

[CONFIG] .vscode/settings.json:24 "cSpell.words": ["auditevent", "bullmq", "FHIR", "Fhircast", "Medplum"] [DOCS] README.md:1 # [Medplum](https://www.medplum.com) · [![GitHub license](https://img.shields.io/badge/licens [DOCS] README.md:1 # [Medplum](https://www.medplum.com) · [![GitHub license](https://img.shields.io/badge/licens [DOCS] SECURITY.md:7 Medplum uses enterprise-grade security and regular audits to ensure you're always protected. We unde [DOCS] SECURITY.md:24 - Third-Party Audits - Our organization undergoes independent third-party assessments to test our se [DOCS] SECURITY.md:14 - Continuous Monitoring - Independent third-party penetration, threat, and vulnerability testing. [DOCS] SECURITY.md:27 - Continuous Monitoring - We continuously monitor our security and compliance status to ensure there [DOCS] SECURITY.md:14 - Continuous Monitoring - Independent third-party penetration, threat, and vulnerability testing.

Finding

Does the system implement logging, monitoring, and alerting mechanisms that detect and record security events, anomalies, and unauthorized activities, as required under CC7.2 for monitoring system components for anomalies?

Remediation

To substantiate claims in `SECURITY.md` about 'enterprise-grade security and regular audits', add application-level logging for security events, including audit trails for authentication and data access. This demonstrable implementation is necessary to meet SOC2 CC7.2 requirements for monitoring system components for anomalies.

SOC2-005 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence exclusively cites a GitHub labeler configuration file, which, while supporting workflow automation, does not directly confirm or deny the presence of core change management controls like mandatory code review, version control, or controlled deployment procedures.

Evidence

[CONFIG] .github/labeler.yml:1 dependencies: [CONFIG] .github/labeler.yml:23 - packages/server/src/scim/**/* [CONFIG] .github/labeler.yml:46 - packages/ccda/src/**/* [CONFIG] .github/labeler.yml:58 - packages/ccda/src/**/* [CONFIG] .github/labeler.yml:69 - packages/cdk/src/**/* [CONFIG] .github/labeler.yml:71 - terraform/**/* [CONFIG] .github/workflows/add-issue-to-project.yml:19 - uses: actions/add-to-project@31b3f3ccdc584546fc445612dec3f38ff5edb41c # v0.5.0 [CONFIG] .github/workflows/add-issue-to-project.yml:23 - uses: actions/add-to-project@31b3f3ccdc584546fc445612dec3f38ff5edb41c # v0.5.0

Finding

Does the system demonstrate evidence of change management controls including version control, code review processes, and controlled deployment procedures, as required under CC8.1 for managing changes to infrastructure, data, software, and procedures?

Remediation

Review the existing labels in `.github/labeler.yml` to ensure critical components like `packages/server/src/scim` and `packages/ccda` are explicitly associated with mandatory code review processes and branch protection rules, ensuring compliance with SOC2 CC8.1 for managing changes to software and data.

SOC2-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and configuration files, which do not directly demonstrate the implementation of incident detection, response, and recovery procedures within the system's application logic, as required by the verdict rules.

Evidence

[DOCS] LICENSE.txt:158 incidental, or consequential damages of any character arising as a [DOCS] README.md:1 # [Medplum](https://www.medplum.com) · [![GitHub license](https://img.shields.io/badge/licens [DOCS] SECURITY.md:64 However, we believe in recognizing and rewarding valuable security research. For novel, verifiable v [CONFIG] charts/values.yaml:55 allowPrivilegeEscalation: false [DOCS] examples/foomedical/README.md:11 <img src="https://sonarcloud.io/api/project_badges/measure?project=medplum_foomedical&metric=alert_s [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:3 import { Alert, Loader } from '@mantine/core'; [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:70 <Alert variant="outline" color="red" title="Schedule unavailable" icon={<IconInfoCircle />}> [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:72 </Alert>

Finding

Does the system implement incident detection, response, and recovery procedures that enable timely identification and remediation of security incidents, consistent with CC7.3 requirements for evaluating security events and CC7.4 for responding to identified incidents?

Remediation

Update `SECURITY.md` or a linked document to explicitly detail internal incident detection, response, and recovery procedures, including formal classification, escalation, and documented workflows to meet SOC2 CC7.3 and CC7.4 requirements, thereby mitigating compliance deficiencies.

SOC2-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files that indicate the presence and handling of software dependencies, but do not directly confirm a lack of dependency vulnerability management controls.

Evidence

[CONFIG] .gitattributes:23 package-lock.json -diff [CONFIG] .gitattributes:24 package-lock.json linguist-generated=true [CONFIG] .github/labeler.yml:3 - any-glob-to-any-file: 'package-lock.json' [CONFIG] .github/workflows/build-agent.yml:204 echo "MEDPLUM_VERSION=$(node -p "require('./package.json').version")" >> $GITHUB_ENV [CONFIG] .github/workflows/build-agent.yml:274 echo "MEDPLUM_VERSION=$(node -p "require('./package.json').version")" >> $GITHUB_ENV [CONFIG] .github/workflows/build-agent.yml:356 echo "MEDPLUM_VERSION=$(node -p "require('./package.json').version")" >> $GITHUB_ENV [CONFIG] .github/workflows/build-agent.yml:438 echo "MEDPLUM_VERSION=$(node -p "require('./package.json').version")" >> $GITHUB_ENV [CONFIG] .github/workflows/build-agent.yml:64 key: ${{ runner.os }}-build-agent-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}

Finding

Does the system assess and manage risks associated with third-party vendors, libraries, and service providers, including dependency vulnerability management, consistent with CC9.2 requirements for risk assessment of third-party service providers?

Remediation

Modify the `.github/workflows/build-agent.yml` file to integrate a dedicated step for automated dependency vulnerability scanning (e.g., `npm audit` or a third-party tool) within the build process for Medplum components. This explicit action demonstrates active management of third-party risks, satisfying SOC2 CC9.2 requirements for dependency vulnerability management.

SOC2-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of GitHub workflow configuration files which do not contain any information relevant to data backup, replication, or recovery controls required by SOC2-008.

Evidence

[CONFIG] .github/auto_assign.yml:11 - ThatOneBro [CONFIG] .github/labeler.yml:2 - changed-files: [CONFIG] .github/labeler.yml:6 - changed-files: [CONFIG] .github/labeler.yml:13 - changed-files: [CONFIG] .github/labeler.yml:19 - changed-files: [CONFIG] .github/labeler.yml:28 - changed-files: [CONFIG] .github/labeler.yml:33 - changed-files: [CONFIG] .github/labeler.yml:39 - changed-files:

Finding

Does the system implement data backup, replication, and recovery controls that ensure availability and recoverability of data, consistent with the A1.2 criterion for recovery of infrastructure and data to meet objectives?

Remediation

No changes are required in `.github/auto_assign.yml` or `.github/labeler.yml` to address SOC2-008 Data Backup and Recovery. These files are related to repository automation, not application data handling or infrastructure configuration, therefore the compliance risk is not supported by this evidence.

SOC2-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence files, including config, test, and application source code snippets, are completely unrelated to multi-factor authentication implementation or its absence, rendering the finding unsupported by the given context.

Evidence

[CONFIG] .github/workflows/build-deb.yml:56 uses: ruby/setup-ruby@cf7216d52fba1017929b4d7162fabe2b30af5b49 # v1.262.0 [CONFIG] charts/templates/deployment.yaml:46 imagePullPolicy: IfNotPresent [SOURCE] examples/medplum-demo-bots/src/vital/vital.test.ts:260 id: '42fa4b3b-0b3b-4b3b-8b3b-2b3b3b3b3b3b', [SOURCE] examples/medplum-provider/src/components/pharmacy/DoseSpotPharmacyDialog.tsx:4 import { useDoseSpotPharmacySearch } from '@medplum/dosespot-react'; [SOURCE] examples/medplum-provider/src/components/pharmacy/DoseSpotPharmacyDialog.tsx:16 export function DoseSpotPharmacyDialog(props: PharmacyDialogBaseProps): JSX.Element {

Finding

Does the system implement or support multi-factor authentication for user access, particularly for privileged accounts and administrative interfaces, consistent with CC6.1 requirements for logical access security?

Remediation

Identify and configure the specific authentication service responsible for user access, explicitly requiring multi-factor authentication for all privileged and administrative accounts. Ensure the enforcement of MFA is integrated into the application's authentication flows, including any components involved in user sign-in or session management like those in `examples/medplum-provider/src/components/pharmacy/DoseSpotPharmacyDialog.tsx`, to comply with SOC2 CC6.1 requirements for logical access security.

SOX

SEC / PCAOB · Criminal penalties, delisting

8 findings · 7 possible FP

SOX-001

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The application's source code explicitly handles data related to 'financialStrain' in `examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx`, which, in a healthcare/fintech context, constitutes financial data highly relevant to SOX Section 302, despite the presence of database transaction isolation settings like 'REPEATABLE READ' in `docker-compose.full-stack.yml`.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/workflows/publish-meta.yml:63 # Check if asset already exists in S3 (idempotent check) [CONFIG] docker-compose.full-stack.yml:18 - 'default_transaction_isolation=REPEATABLE READ' [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1062 code: 'financialStrain', [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1063 display: 'Financial Strain', [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1067 linkId: '/supplementalQuestions/financialStrain', [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1068 text: 'Financial Strain', [SOURCE] examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx:1096 linkId: '/supplementalQuestions/financialStrain/11', [CONFIG] examples/medplum-chat-demo/data/example/example-data.json:2602 "display": "Anatomic pathologist (occupation)"

Finding

Does the system implement controls to ensure the integrity, accuracy, and completeness of financial data and transactions, consistent with SOX Section 302 requirements for management certification of financial statements?

Remediation

For financial data like 'financialStrain' identified in `examples/foomedical/src/pages/ScreeningQuestionnairePage.tsx`, establish comprehensive validation rules, robust audit logging for all modifications, and role-based access controls. These measures are crucial to ensure the integrity, accuracy, and completeness of financial data, aligning with SOX Section 302 requirements.

Remediation refined by Gemini review

Possible False Positives (7)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOX-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites GitHub Actions workflow configuration files (.yml), which define CI/CD permissions within the repository, and do not directly implement or govern access controls for financial systems or data as specifically defined by SOX-002.

Evidence

[CONFIG] .github/workflows/add-issue-to-project.yml:11 permissions: [CONFIG] .github/workflows/assign-pull-request.yml:7 permissions: [CONFIG] .github/workflows/assign-pull-request.yml:14 permissions: [CONFIG] .github/workflows/autofix-ci.yml:11 permissions: [CONFIG] .github/workflows/autofix-ci.yml:17 permissions: [CONFIG] .github/workflows/build-agent.yml:16 permissions: [CONFIG] .github/workflows/build-agent.yml:28 permissions: [CONFIG] .github/workflows/build-agent.yml:220 permissions:

Finding

Does the system implement access controls that restrict access to financial systems and data to authorized personnel, with appropriate authentication and authorization mechanisms, as required under SOX Section 404 internal controls?

Remediation

Review the `permissions` configurations within `.github/workflows/add-issue-to-project.yml`, `.github/workflows/assign-pull-request.yml`, and `.github/workflows/autofix-ci.yml` to ensure they adhere to the principle of least privilege, thereby limiting workflow token access to only essential repository resources, as excessive permissions could indicate a weakness in general IT controls relevant to SOX Section 404.

SOX-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The cited `.github/workflows` configuration files relate to build artifact timestamping for software integrity and web caching, which do not provide direct evidence for or against the existence of a tamper-evident audit trail for financial transactions required by SOX-003.

Evidence

[CONFIG] .github/workflows/build-agent.yml:168 timestamp-rfc3161: http://timestamp.acs.microsoft.com [CONFIG] .github/workflows/build-agent.yml:169 timestamp-digest: SHA256 [CONFIG] .github/workflows/publish-meta.yml:72 --cache-control "public, max-age=31536000, immutable" [CONFIG] .github/workflows/publish.yml:294 timestamp-rfc3161: http://timestamp.acs.microsoft.com [CONFIG] .github/workflows/publish.yml:295 timestamp-digest: SHA256 [CONFIG] .vscode/settings.json:24 "cSpell.words": ["auditevent", "bullmq", "FHIR", "Fhircast", "Medplum"] [DOCS] SECURITY.md:7 Medplum uses enterprise-grade security and regular audits to ensure you're always protected. We unde [DOCS] SECURITY.md:24 - Third-Party Audits - Our organization undergoes independent third-party assessments to test our se

Finding

Does the system maintain a complete and tamper-evident audit trail of all financial transactions, modifications, and access events, sufficient to support the audit requirements under SOX Section 802?

Remediation

The timestamping configurations in `build-agent.yml` (lines 168-169) and `publish.yml` (lines 294-295) are for software artifact integrity, and `publish-meta.yml` (line 72) configures caching; these do not directly address application-level financial transaction audit trails. Therefore, no specific changes to these files are required to meet SOX-003's financial audit trail requirements, as the provided evidence does not substantiate a compliance gap.

SOX-004 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively comprises configuration files (`.github/labeler.yml`) which define how changes are labeled, not the actual implementation of change management controls like code review, testing, or deployment policies themselves.

Evidence

[CONFIG] .github/labeler.yml:1 dependencies: [CONFIG] .github/labeler.yml:23 - packages/server/src/scim/**/* [CONFIG] .github/labeler.yml:46 - packages/ccda/src/**/* [CONFIG] .github/labeler.yml:58 - packages/ccda/src/**/* [CONFIG] .github/labeler.yml:69 - packages/cdk/src/**/* [CONFIG] .github/workflows/add-issue-to-project.yml:19 - uses: actions/add-to-project@31b3f3ccdc584546fc445612dec3f38ff5edb41c # v0.5.0 [CONFIG] .github/workflows/add-issue-to-project.yml:23 - uses: actions/add-to-project@31b3f3ccdc584546fc445612dec3f38ff5edb41c # v0.5.0 [CONFIG] .github/workflows/add-issue-to-project.yml:7 pull_request_target:

Finding

Does the system implement change management controls for software that processes financial data, including version control, code review, testing, and controlled deployment, consistent with SOX IT general controls?

Remediation

Leveraging the path classifications defined in `.github/labeler.yml` for `scim` and `ccda` packages, configure GitHub branch protection rules to mandate successful automated testing workflows and at least two required code reviews for any changes affecting these sensitive areas. This will provide robust change management controls consistent with SOX requirements.

SOX-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively consists of configuration files (.github/workflows/*.yml), which, according to the strict decision rules, leads to a 'POSSIBLE FALSE POSITIVE' verdict for this finding.

Evidence

[CONFIG] .github/workflows/build-agent.yml:8 workflow_dispatch: [CONFIG] .github/workflows/build-deb.yml:11 workflow_dispatch: [CONFIG] .github/workflows/build-helm-charts.yml:11 workflow_dispatch: [CONFIG] .github/workflows/build.yml:3 # see https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurre [CONFIG] .github/workflows/build.yml:2 # Limit a single job to run at a time for a given branch/PR to save resources and speed up CI [CONFIG] .github/workflows/build.yml:128 delimiter="$(openssl rand -hex 8)" [CONFIG] .github/workflows/build.yml:129 echo "eslint_errs<<${delimiter}" >> "${GITHUB_OUTPUT}" [CONFIG] .github/workflows/build.yml:132 echo "${delimiter}" >> "${GITHUB_OUTPUT}"

Finding

Does the system implement segregation of duties controls that prevent any single individual from having the ability to both authorize and execute financial transactions, or to both develop and deploy changes to financial systems?

Remediation

Remove `workflow_dispatch:` from `.github/workflows/build-agent.yml:8`, `.github/workflows/build-deb.yml:11`, and `.github/workflows/build-helm-charts.yml:11` for production deployment workflows, or implement GitHub Actions environment protection rules requiring explicit approvals for manual dispatches. This action directly addresses SOX Segregation of Duties by preventing unauthorized individuals from unilaterally deploying changes to financial systems, thereby reducing the risk of undetected fraud or error.

SOX-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided refers exclusively to configuration files for workflow artifact retention and metadata caching, not directly to financial records or audit documentation, making the short retention periods irrelevant to SOX Section 802 for financial data.

Evidence

[CONFIG] .github/workflows/build-deb.yml:79 --preserve-versions \ [CONFIG] .github/workflows/build.yml:383 retention-days: 30 [CONFIG] .github/workflows/publish-meta.yml:72 --cache-control "public, max-age=31536000, immutable" [CONFIG] .github/workflows/scorecard.yml:73 retention-days: 5 [CONFIG] Dockerfile:7 # The archive files are decompressed and extracted into the specified destinations. [CONFIG] Dockerfile:9 # See: https://docs.docker.com/reference/dockerfile/#adding-local-tar-archives [CONFIG] Dockerfile:8 # We do this to preserve the folder structure in a single layer. [CONFIG] charts/.helmignore:13 # Common backup files

Finding

Does the system implement data retention policies that preserve financial records, audit work papers, and supporting documentation for the minimum retention period required under SOX Section 802 (not less than 7 years)?

Remediation

The `retention-days` settings in `.github/workflows/build.yml` (30 days) and `.github/workflows/scorecard.yml` (5 days), and `cache-control` in `.github/workflows/publish-meta.yml` (max-age=1 year), pertain to build artifacts and metadata, not financial records. No changes are required to these specific files to address SOX Section 802 requirements for financial data retention, as the evidence does not support a compliance risk here.

SOX-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files related to GitHub repository management and build workflow caching, which are irrelevant to demonstrating the existence or documentation of internal controls over financial reporting as required by SOX 404(a).

Evidence

[CONFIG] .github/labeler.yml:24 - packages/server/src/fhir/accesspolicy.ts [CONFIG] .github/labeler.yml:55 compliance: [CONFIG] .github/labeler.yml:5 documentation: [CONFIG] .github/workflows/build-deb.yml:82 --cache-control="max-age=300" \ [CONFIG] .github/workflows/publish-meta.yml:72 --cache-control "public, max-age=31536000, immutable" [CONFIG] .github/workflows/publish-meta.yml:129 --cache-control "no-cache" [CONFIG] .github/workflows/publish-meta.yml:134 --cache-control "no-cache" [CONFIG] .github/workflows/publish-meta.yml:139 --cache-control "no-cache"

Finding

Does the system provide evidence of documented internal controls over financial reporting, including control objectives, control activities, and monitoring procedures, as required under SOX Section 404(a)?

Remediation

The provided evidence in `.github/labeler.yml` and `.github/workflows/*.yml` relates to repository management and build caching, not internal financial control documentation. These specific configuration files therefore do not require modification to fulfill SOX Section 404(a) requirements for documented internal controls over financial reporting.

SOX-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of a GitHub Actions workflow configuration file, which pertains to build integrity and caching, not direct controls for the alteration or destruction of financial records as required by SOX Section 802.

Evidence

[CONFIG] .github/workflows/build-agent.yml:64 key: ${{ runner.os }}-build-agent-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} [CONFIG] .github/workflows/build-agent.yml:73 - name: Set repo hash [CONFIG] .github/workflows/build-agent.yml:75 # This forces git shorthash to match between @medplum/agent and @medplum/core [CONFIG] .github/workflows/build-agent.yml:78 echo "MEDPLUM_GIT_SHORTHASH=$(git rev-parse --short=7 HEAD)" >> $GITHUB_ENV [CONFIG] .github/workflows/build-agent.yml:239 key: ${{ runner.os }}-build-agent-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} [CONFIG] .github/workflows/build-agent.yml:248 - name: Set repo hash [CONFIG] .github/workflows/build-agent.yml:250 # This forces git shorthash to match between @medplum/agent and @medplum/core [CONFIG] .github/workflows/build-agent.yml:253 echo "MEDPLUM_GIT_SHORTHASH=$(git rev-parse --short=7 HEAD)" >> $GITHUB_ENV

Finding

Does the system implement controls to prevent unauthorized alteration or destruction of financial records, including integrity verification, immutable storage, and tamper detection mechanisms, consistent with SOX Section 802 anti-destruction requirements?

Remediation

The `.github/workflows/build-agent.yml` file outlines build process integrity and caching, which does not directly address SOX Section 802 anti-tampering requirements for financial records. Therefore, no specific changes are warranted in this workflow file to mitigate the identified SOX-008 risk.

TCPA

FCC · $500-$1,500 per violation

8 findings · 7 possible FP

TCPA-006

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The evidence confirms the existence of consent record-keeping mechanisms in application source code, and the finding highlights a legitimate compliance risk regarding the sufficiency of recorded details for TCPA, which the provided snippets do not fully address.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[SOURCE] packages/server/src/migrations/schema/v1.ts:773 await client.query(`CREATE TABLE IF NOT EXISTS "Consent_History" ( [SOURCE] packages/server/src/migrations/schema/v14.ts:154 await client.query('CREATE INDEX ON "Consent_History" ("id")'); [SOURCE] packages/server/src/migrations/schema/v14.ts:155 await client.query('CREATE INDEX ON "Consent_History" ("lastUpdated")'); [SOURCE] packages/server/src/migrations/schema/v42.ts:707 'CREATE INDEX CONCURRENTLY IF NOT EXISTS "Consent_sourceReference_idx" ON "Consent" ("sourceReferenc

Finding

Does the system maintain records of consent that would be sufficient to demonstrate compliance in the event of a dispute, including the date, time, method of consent, and the specific consent language presented to the consumer?

Remediation

In `packages/server/src/migrations/schema/v1.ts:773`, the `Consent_History` table schema, and any related `Consent` table schema, must be updated to include fields for a precise `consent_timestamp`, the `consent_method` (e.g., 'web_form', 'sms'), and the `consent_language_text` or `consent_language_version_id` to link to the exact wording presented. This modification is critical to provide adequate proof of consent and avoid substantial fines for TCPA violations.

Remediation refined by Gemini review

Possible False Positives (7)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

TCPA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The cited evidence from `LICENSE.txt` and `NOTICE` refers to generic legal terms like 'agreed to in writing' within license agreements or notices, which does not constitute or reflect the operational collection of prior express written consent for marketing SMS messages as required by TCPA.

Evidence

[DOCS] LICENSE.txt:135 the terms of any separate license agreement you may have executed [DOCS] LICENSE.txt:144 agreed to in writing, Licensor provides the Work (and each [DOCS] LICENSE.txt:156 negligent acts) or agreed to in writing, shall any Contributor be [DOCS] LICENSE.txt:171 of any other Contributor, and only if You agree to indemnify, [CONFIG] NOTICE:15 Unless required by applicable law or agreed to in writing, software [SOURCE] examples/foomedical/src/pages/PatientIntakeQuestionnairePage.tsx:470 linkId: 'consent-for-treatment', [SOURCE] examples/foomedical/src/pages/PatientIntakeQuestionnairePage.tsx:471 text: 'Consent for Treatment', [SOURCE] examples/foomedical/src/pages/PatientIntakeQuestionnairePage.tsx:475 linkId: 'consent-for-treatment-signature',

Finding

Does the system obtain prior express written consent before sending marketing or promotional text messages, including a clear and conspicuous disclosure that consent is being sought, as required under 47 U.S.C. §227(b)(1) and 47 CFR §64.1200(a)(2)?

Remediation

To prevent misinterpretation, ensure that any future updates to `LICENSE.txt` or `NOTICE` clearly differentiate general legal agreements from specific active consent for marketing communications, and that dedicated application code implements explicit opt-in mechanisms for SMS, preventing TCPA violations under 47 U.S.C. §227(b)(1).

TCPA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, `cancel-in-progress: true` in GitHub Actions workflow configuration files, relates to CI/CD pipeline management and has no relevance to TCPA opt-out mechanisms.

Evidence

[CONFIG] .github/workflows/autofix-ci.yml:5 cancel-in-progress: true [CONFIG] .github/workflows/build-agent.yml:5 cancel-in-progress: true [CONFIG] .github/workflows/build-deb.yml:5 cancel-in-progress: true [CONFIG] .github/workflows/build-helm-charts.yml:5 cancel-in-progress: true [CONFIG] .github/workflows/build.yml:6 cancel-in-progress: true [CONFIG] .github/workflows/codeql-analysis.yml:17 cancel-in-progress: true [CONFIG] .github/workflows/deploy.yml:5 cancel-in-progress: false [CONFIG] .github/workflows/madge.yml:5 cancel-in-progress: true

Finding

Does the system provide a clear and easy mechanism for recipients to opt out of receiving further messages, and does it honor opt-out requests promptly, as required under TCPA and CTIA guidelines?

Remediation

The `cancel-in-progress: true` directive in `.github/workflows/autofix-ci.yml`, `build-agent.yml`, `build-deb.yml`, `build-helm-charts.yml`, and `build.yml` controls GitHub Actions workflow execution and is unrelated to recipient opt-out. Therefore, no changes are needed in these specific configuration files to address TCPA opt-out compliance.

TCPA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, `registry-url: 'https://registry.npmjs.org'` in GitHub Actions workflow files, specifies the package registry for builds and is entirely unrelated to the functionality of checking phone numbers against a Do Not Call Registry for outbound calls or messages, making the finding a false positive based on this evidence.

Evidence

[CONFIG] .github/workflows/build-agent.yml:50 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-agent.yml:231 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-agent.yml:313 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-agent.yml:395 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-deb.yml:37 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build-helm-charts.yml:30 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build.yml:39 registry-url: 'https://registry.npmjs.org' [CONFIG] .github/workflows/build.yml:93 registry-url: 'https://registry.npmjs.org'

Finding

Does the system check phone numbers against the National Do Not Call Registry and maintain an internal do-not-call list before initiating outbound calls or messages, as required under 47 CFR §64.1200(c)?

Remediation

Review relevant application code to determine if outbound calls or messages are initiated to individuals. If so, implement robust checks against the National Do Not Call Registry and an internal do-not-call list, as required by 47 CFR §64.1200(c).

TCPA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, `RECAPTCHA_SITE_KEY` found within `.github/workflows` configuration files, is entirely unrelated to the TCPA's message frequency disclosure requirements. The presence of a reCAPTCHA key in CI/CD configuration files does not indicate messaging activity or a lack of frequency disclosure, as reCAPTCHA is used for bot detection on web forms, not direct message management or consent. The primary analysis has made an unsubstantiated link between reCAPTCHA and TCPA messaging compliance.

Evidence

[CONFIG] .github/workflows/build-deb.yml:49 RECAPTCHA_SITE_KEY: '__RECAPTCHA_SITE_KEY__' [CONFIG] .github/workflows/build.yml:74 RECAPTCHA_SITE_KEY: '__RECAPTCHA_SITE_KEY__' [CONFIG] .github/workflows/build.yml:432 RECAPTCHA_SITE_KEY: '__RECAPTCHA_SITE_KEY__' [CONFIG] .github/workflows/deploy.yml:85 RECAPTCHA_SITE_KEY: ${{ secrets.RECAPTCHA_SITE_KEY }} [CONFIG] .github/workflows/publish.yml:90 RECAPTCHA_SITE_KEY: '__RECAPTCHA_SITE_KEY__' [CONFIG] .github/workflows/staging.yml:53 RECAPTCHA_SITE_KEY: '__RECAPTCHA_SITE_KEY__' [CONFIG] .github/workflows/staging.yml:85 RECAPTCHA_SITE_KEY: ${{ secrets.STAGING_RECAPTCHA_SITE_KEY }} [CONFIG] biome.json:63 "useMediaCaption": "warn",

Finding

Does the system disclose to consumers the expected frequency of messages before obtaining consent, and does it enforce frequency limits consistent with the disclosed rate, as recommended by CTIA guidelines?

Remediation

Implement a comprehensive messaging compliance system that includes: (1) user-facing disclosure forms showing expected message frequency before consent collection, (2) database schema to store user consent with disclosed frequency rates, (3) rate limiting mechanisms that enforce the disclosed frequency limits, and (4) logging systems to track message sending patterns for compliance auditing. The system should present clear frequency expectations (e.g., "up to 5 messages per week") during signup and technically enforce these limits in the messaging infrastructure.

TCPA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence (references to 'Brand Name Prescription Drug' in config and type definition files, and an 'IconBrandDiscord' in a UI component) is entirely unrelated to the presence or absence of sender identification in outbound messages, which is the core regulatory concern of TCPA-005.

Evidence

[CONFIG] examples/medplum-eligibility-demo/data/core/core-data.json:329 "display": "Brand Name Prescription Drug" [CONFIG] examples/medplum-eligibility-demo/data/core/core-data.json:449 "display": "Brand Name Prescription Drug - Formulary" [CONFIG] examples/medplum-eligibility-demo/data/core/core-data.json:453 "display": "Brand Name Prescription Drug - Non-Formulary" [SOURCE] examples/medplum-photon-integration/src/photon-types.d.ts:159 brandName?: string; [SOURCE] examples/medplum-provider/src/pages/getstarted/GetStartedPage.tsx:25 IconBrandDiscord, [SOURCE] examples/medplum-provider/src/pages/getstarted/GetStartedPage.tsx:570 <IconBrandDiscord size={24} color="var(--icon-secondary)" /> [SOURCE] examples/medplum-valueset-selector/src/pages/HomePage.tsx:15 "id": "rxnorm-branded-drugs", [SOURCE] examples/medplum-valueset-selector/src/pages/HomePage.tsx:16 "url": "http://example.org/fhir/ValueSet/rxnorm-branded-drugs",

Finding

Does the system include proper sender identification in all outbound messages, including the identity of the entity sending the message and how to contact them, consistent with TCPA and CTIA requirements?

Remediation

Implement sender identification functionality for all outbound messages by adding required fields such as sender name, organization identity, and contact information (phone number, email, or physical address). Create message templates or wrapper functions that automatically include this identification data before sending any communications. Establish configuration settings to manage sender contact details and ensure they are consistently applied across all messaging channels. Add validation to prevent messages from being sent without proper sender identification.

TCPA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively points to comments within CI/CD workflow configuration files (.github/workflows/*.yml), which are entirely unrelated to the application's consent revocation logic as required by TCPA.

Evidence

[CONFIG] .github/workflows/codeql-analysis.yml:63 # If this step fails, then you should remove it and run the build manually (see below) [CONFIG] .github/workflows/codeql-analysis.yml:70 # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines [CONFIG] .github/workflows/prepare-release.yml:33 # Upgrade to a patched version; this should be removed after Node has a tagged [CONFIG] .github/workflows/scorecard.yml:26 # `publish_results: true` only works when run from the default branch. conditional can be removed if [CONFIG] .github/workflows/upgrade-dependencies.yml:37 # Upgrade to a patched version; this should be removed after Node has a tagged [DOCS] LICENSE.txt:161 work stoppage, computer failure or malfunction, or any and all [CONFIG] docker-compose.full-stack.yml:4 restart: unless-stopped # for production usage, consider using 'always' [CONFIG] docker-compose.full-stack.yml:31 restart: unless-stopped # for production usage, consider 'always'

Finding

Does the system honor revocation of consent through any reasonable means indicated by the consumer, not limited to specific keywords, and process revocation within a reasonable timeframe, consistent with FCC guidance?

Remediation

The evidence provided in `.github/workflows/codeql-analysis.yml`, `.github/workflows/prepare-release.yml`, `.github/workflows/scorecard.yml`, and `.github/workflows/upgrade-dependencies.yml` consists solely of CI/CD workflow comments and does not pertain to application-level consent revocation mechanisms. Therefore, no changes to these specific files are warranted to address TCPA-007, as the evidence does not support the finding regarding insufficient consent revocation handling.

TCPA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files for internal GitHub Actions workflows and documentation describing service availability, none of which are application source code files that would directly implement or fail to implement time-of-day restrictions for outbound calls and messages as required by TCPA.

Evidence

[CONFIG] .github/workflows/codeql-analysis.yml:26 schedule: [CONFIG] .github/workflows/scorecard.yml:12 schedule: [CONFIG] .github/workflows/upgrade-dependencies.yml:14 schedule: [DOCS] examples/foomedical/README.md:85 The "Get Care" page is configured to search for availability with service-type "office-visit". Confi [DOCS] examples/foomedical/README.md:88 "resourceType": "Schedule", [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:6 import { Document, Scheduler, useMedplum } from '@medplum/react'; [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:16 const [schedule, loading] = useSearchOne('Schedule'); [SOURCE] examples/foomedical/src/pages/GetCarePage.tsx:19 if (!schedule) {

Finding

Does the system enforce time-of-day restrictions for outbound calls and messages, ensuring they are not sent before 8:00 AM or after 9:00 PM in the recipient's local time zone, as required under 47 CFR §64.1200(c)(1)?

Remediation

Within the application's functionality related to patient scheduling and availability (as described in `examples/foomedical/README.md`), confirm that any outbound communications, such as appointment reminders, incorporate recipient local time zone validation. This will ensure no prohibited calls or messages are sent outside 8:00 AM - 9:00 PM windows, aligning with 47 CFR §64.1200(c)(1).

What This Analysis Covers

OpenDocket scans source code patterns — specifically whether code handles regulated data in compliance-aware ways. It searches for evidence of encryption, access controls, consent mechanisms, audit logging, and other patterns that regulators look for.

What It Does Not Cover

Only public repository content is analyzed
Files in .gitignore are not scanned
Infrastructure, deployment, and cloud configuration are outside scope
Operational policies and procedures are outside scope
This analysis covers code at time of scan — changes after scan date are not reflected

Legal Limitations

This report is not defensible in court
It does not constitute legal advice
It does not satisfy regulatory audit requirements
To obtain a defensible compliance assessment, engage a licensed compliance attorney and certified auditor
OpenDocket provides directional guidance only

How Findings Are Generated

Primary analysis by Claude Sonnet (Anthropic)
Verification by Gemini 2.5 Flash (Google)
Question libraries are open source and community-maintained
All questions cite regulatory source text
Questions have not been validated by a licensed attorney

Why Two Models?

Claude Sonnet scans broadly — it finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.

Gemini 2.5 Flash then challenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?

The result is a tiered output:

CONFIRMED — Gemini agrees this is a real risk
CONTEXT DEPENDENT — Risk depends on deployment/infrastructure
POSSIBLE FALSE POSITIVE — Likely noise, review before acting

The confirmed count is the number you should act on. The total count shows the full scope of what was examined.

Evidence Tiers

Evidence is classified into three tiers based on file type:

[SOURCE] — Application source code (.ts, .py, .go, .rs, etc.) — strongest evidence
[CONFIG] — Configuration files (.yml, .json, .toml, Dockerfile) — moderate evidence
[DOCS] — Documentation (.md, .txt, .html) — context only, cannot produce High Risk findings

A finding is only classified as High Risk if supported by at least two source code files with matching evidence. Documentation references alone produce Pattern of Concern at most.

How to Use This Report

Share with your engineering lead for remediation planning
Share with your attorney as a starting point for compliance review
Re-scan after remediation to track progress
Do not present this as proof of compliance

Findings based on OpenDocket's open source question libraries. View and contribute