Skip to main content

Digital Delivery Policy

Note: This page is a documentation-friendly presentation of MedFeed's Digital Delivery Policy and additional operational guidance for customers. It is not legal advice. For the canonical policy text, always refer to the MedFeed website and the Terms & Conditions.

Purpose & scope​

This Digital Delivery Policy explains how access to the MedFeed platform is provisioned and maintained, what customers can expect regarding availability and updates, and where to go for support or billing questions. It applies to all paid platform subscriptions and governs digital (non-physical) delivery of the service.

1. Delivery & account activation​

  • No physical shipping. MedFeed is cloud-delivered software—customers do not receive physical media or hardware as part of the standard subscription.
  • When access begins: Access is granted when the customer's account is activated after payment confirmation and execution of a subscription agreement. Credentials are delivered electronically (via email or the Platform's secure portal).

Operational notes (recommended):

  • Keep the admin email address and billing contact up to date so activation messages and credentials are received promptly.
  • Use a temporary/test admin account to validate access before onboarding end users.

2. Availability, maintenance & notifications​

  • Availability: MedFeed aims to make the Platform available to customers, but availability is subject to scheduled maintenance events and third-party infrastructure performance (for example: AWS, Azure, Cloudflare, MongoDB).
  • Scheduled maintenance: The policy states scheduled maintenance will be notified 48 hours in advance. Customers should expect brief interruptions or degraded performance during planned maintenance windows.
  • Third-party dependencies: Because the Platform is hosted on third-party cloud and networking services, outages or performance degradation at those providers can affect MedFeed availability. The Company's ability to guarantee uptime is therefore partially dependent on those providers.

What to expect in a maintenance notice (typical):

  • Start / end time for the maintenance window (with timezone).
  • Expected user impact (read-only, partial feature impact, full downtime).
  • Recommended customer actions (e.g., pause scheduled dictations, avoid major exports).
  • Rollback plan or contact for immediate assistance.

Emergency maintenance:

  • For urgent fixes (security, data integrity, major outage), the Company may need to perform emergency maintenance with less notice. In such cases the Company will attempt to notify customers as soon as reasonably practicable.

3. Service credits & refunds​

  • Policy statement: The Digital Delivery Policy explicitly states that downtime does not entitle Customers to refunds or credits under this policy. For billing or refunds questions, customers should refer to the Terms & Conditions and the Cancellation & Refund Policy.

Operational guidance (recommended):

  • If uptime guarantees or service credits are required for your deployment, negotiate them explicitly in your subscription or enterprise agreement and document the SLAs there.
  • Consider monitoring the service from your environment (synthetic checks) so you can correlate local issues (network, firewall) with platform availability.

4. Customer responsibilities​

  • Infrastructure & compatibility: Customers must provide adequate internet connectivity, compatible systems (for example HIMS/EMR integration points), and local network configuration necessary for the Platform to function. MedFeed is not liable for access failures or degraded experience caused by the Customer's infrastructure.
  • Account & credential management: Customers are responsible for secure storage and rotation of credentials provided by the Platform (admin accounts, API keys) and for following their own internal access control policies.

Recommended customer checklist:

  • Whitelist required outbound domains and ports according to the MedFeed onboarding checklist.
  • Ensure client devices have supported browsers and up-to-date OS versions.
  • Verify microphone, camera, and permission settings on representative clinician devices (for voice and scribe workflows).
  • Maintain a test tenant or sandbox for verification before rolling out changes to production users.

5. Updates, upgrades & deprecation​

  • Company discretion: The Company may deploy updates, enhancements, and new features at its sole discretion. The Company is not obligated to maintain legacy functionality. Customers should therefore expect ongoing evolution of the Platform and potential deprecation of older features.

Best practices for customers:

  • Subscribe to release notes and changelogs so you can plan upgrades and training.
  • Use staging/sandbox tenants to validate major updates before applying them to production.
  • Maintain documented integration tests for any EHR/EMR mappings or API connections you depend on, so changes can be detected early.

6. Onboarding & access provisioning (typical flow)​

This section describes the common operational steps customers can expect when onboarding (the exact process may vary by customer agreement):

  1. Purchase / subscription execution and billing confirmation.
  2. Account activation and admin credential delivery (email or secure portal).
  3. Admin config: tenant settings, SSO/SAML configuration (if applicable), user import or provisioning.
  4. Test users created (recommended) and functionality validated (scribe, feedback capture, task routing).
  5. Go-live: scheduling user training and enabling production users.

7. Security, data & compliance (referenced)​

  • The Digital Delivery Policy itself focuses on delivery and availability. For details on data handling, data protection, subprocessors, and retention, customers should consult the Privacy Policy and Terms & Conditions. See those documents for specifics about how Customer Data and End-User Data are processed, and for regulatory obligations.

8. Contact points​

Use the following contacts for issues related to delivery, billing, data protection and security incidents (as listed in the policy):

  • Sales & Pricing: sales@medfeed.ai
  • Billing & Cancellations: billing@medfeed.ai
  • Data Protection Officer (DPO): dpo@medfeed.ai
  • Security Incidents: security@medfeed.ai

Operational tip: Add these addresses to your vendor escalation directory and assign primary/secondary contacts on your side so incident communications are rapid and clear.

9. FAQs (clarifications you may care about)​

Q: Will scheduled maintenance always be 48 hours in advance?
A: The policy states scheduled maintenance is notified 48 hours in advance; emergency or security fixes may require shorter notice. Customers should expect planned notices but also prepare for occasional urgent updates.

Q: Is there a guaranteed uptime or SLA in this policy?
A: The Digital Delivery Policy does not promise a monetary SLA or service credits for downtime and explicitly states downtime does not entitle customers to refunds or credits. If you need contractual uptime guarantees, include them in your subscription agreement.

Q: What happens if my local network causes failures?
A: Per the policy, the Company isn't liable for failures caused by the Customer's infrastructure. Follow the recommended checklist (section 4) to reduce local failure risk.

Q: Where can I find more detail about data handling and subprocessors?
A: See the Privacy Policy and Terms & Conditions for details on subprocessors, data retention, and data owner vs. processor responsibilities.

10. Revision & authoritative source​

This document is a documentation-friendly rendering and operational expansion of MedFeed's Digital Delivery Policy. The authoritative source is the MedFeed website; if discrepancies arise, the live policy on medfeed.ai governs.

Last reviewed: 2025