specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Oracle Health (Cerner)
providerId: cerner
generated: '2026-08-14'
created: '2026-05-04'
modified: '2026-08-14'
method: probed
source: >-
  https://docs.oracle.com/en/industries/health/millennium-platform-apis/mfrap/r4_overview.html,
  https://docs.oracle.com/en/industries/health/millennium-platform-apis/apis.html, plus live
  unauthenticated responses from https://fhir-open.cerner.com/r4/{tenant} on 2026-08-14
limit_count: 0
limits_published: false
tags:
  - Oracle Health
  - Cerner Millennium
  - FHIR
  - Rate Limiting
description: >-
  Oracle Health publishes no rate limits for the Millennium Platform FHIR APIs, and the API returns no
  rate-limit headers. An integrating agent gets neither a documented budget nor a runtime signal.
note: >-
  This artifact previously carried invented per-tier limits (10/min free, 100/min professional,
  1000/min enterprise) and an invented X-RateLimit-* header set, written by a 2026-05-04 bulk sweep. None
  of it came from Oracle Health and all of it has been removed.
findings:
  - fact: No rate limits are documented anywhere in the Millennium Platform API documentation.
    evidence:
      - url: https://docs.oracle.com/en/industries/health/millennium-platform-apis/mfrap/r4_overview.html
        status: 200
        note: >-
          The R4 overview documents the full HTTP status table (400/401/403/404/406/409/422/500) and does
          not mention 429, throttling, quotas or limits at all.
  - fact: No rate-limit response headers are returned.
    evidence:
      - url: https://fhir-open.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/metadata
        status: 200
        note: >-
          Live unauthenticated response carries no X-RateLimit-*, no RateLimit-* (RFC 9239 style) and no
          Retry-After.
  - fact: 429 is not in the documented status table.
    note: >-
      That does not mean the platform never throttles — an undocumented throttle is still a throttle. It
      means a client cannot distinguish "throttled" from "broken" from the contract, and has no advertised
      recovery window.
headers:
  limit: null
  remaining: null
  reset: null
  retryAfter: null
  policy: null
responseCodes:
  throttled: null
  serviceUnavailable: 503
limits: []
agent_guidance:
  - >-
    Assume conservative concurrency. With no published ceiling and no header feedback, an agent cannot
    tune against a budget; treat parallelism as a risk to the health system's shared tenant, not a
    performance dial.
  - >-
    Back off exponentially with jitter on any 429 or 503 and honour Retry-After if it ever appears, even
    though it is not currently advertised.
  - >-
    For population-scale work use the Bulk Data Access API rather than fanning out per-patient reads —
    the export flow is the platform's supported path for volume and puts the throttling decision on the
    server.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com