Coverage
How much of the federal marketplace has a publicly checkable FHIR endpoint
Of the 133 organizations reviewed so far, 80 publish a base URL this project retrieved a conformance document from. That figure is over the reviewed part of the frame only: 133 of 176 organizations, in 20 of 30 states. The other 43 have not been looked at, which is a fact about this project.
The four counts below are never added together and never reported as one number. "Nobody has looked yet" is not evidence about an issuer, and a rate whose denominator mixed it with "we looked and found nothing" would publish this project's backlog as an issuer's silence. The code refuses to compute such a rate rather than relying on nobody asking for one.
The four populations
| Population | Organizations | What it means |
|---|---|---|
| verified | 80 | publishes a base URL a CapabilityStatement was retrieved from |
| documented unreachable | 6 | publishes a base URL in its own materials that did not answer on the date it was checked |
| no public url found | 47 | was reviewed, and no base URL a stranger could read was found in its own documentation |
| not yet reviewed | 43 | has not been reviewed by this project. A fact about this project's progress, never about what the organization publishes |
By state
| State | On the frame | Verified | Documented, unreachable | No public URL found | Not yet reviewed | Review status |
|---|---|---|---|---|---|---|
| AK | 2 | 1 | 0 | 1 | 0 | 2 of 2 reviewed |
| AL | 4 | 3 | 0 | 1 | 0 | 4 of 4 reviewed |
| AR | 4 | 0 | 0 | 0 | 4 | not yet reviewed |
| AZ | 7 | 4 | 1 | 2 | 0 | 7 of 7 reviewed |
| DE | 3 | 2 | 0 | 1 | 0 | 3 of 3 reviewed |
| FL | 15 | 9 | 0 | 6 | 0 | 15 of 15 reviewed |
| HI | 2 | 0 | 0 | 0 | 2 | not yet reviewed |
| IA | 6 | 3 | 0 | 3 | 0 | 6 of 6 reviewed |
| IN | 5 | 5 | 0 | 0 | 0 | 5 of 5 reviewed |
| KS | 6 | 4 | 0 | 2 | 0 | 6 of 6 reviewed |
| LA | 6 | 4 | 1 | 1 | 0 | 6 of 6 reviewed |
| MI | 7 | 5 | 0 | 2 | 0 | 7 of 7 reviewed |
| MO | 7 | 5 | 0 | 2 | 0 | 7 of 7 reviewed |
| MS | 5 | 3 | 0 | 2 | 0 | 5 of 5 reviewed |
| MT | 3 | 0 | 0 | 0 | 3 | not yet reviewed |
| NC | 6 | 5 | 0 | 1 | 0 | 6 of 6 reviewed |
| ND | 3 | 0 | 0 | 0 | 3 | not yet reviewed |
| NE | 5 | 3 | 0 | 2 | 0 | 5 of 5 reviewed |
| NH | 4 | 0 | 0 | 0 | 4 | not yet reviewed |
| OH | 11 | 6 | 0 | 5 | 0 | 11 of 11 reviewed |
| OK | 7 | 3 | 1 | 3 | 0 | 7 of 7 reviewed |
| OR | 6 | 0 | 0 | 0 | 6 | not yet reviewed |
| SC | 6 | 0 | 0 | 0 | 6 | not yet reviewed |
| SD | 3 | 0 | 0 | 0 | 3 | not yet reviewed |
| TN | 6 | 0 | 0 | 0 | 6 | not yet reviewed |
| TX | 15 | 4 | 2 | 9 | 0 | 15 of 15 reviewed |
| UT | 6 | 0 | 0 | 0 | 6 | not yet reviewed |
| WI | 12 | 9 | 1 | 2 | 0 | 12 of 12 reviewed |
| WV | 2 | 1 | 0 | 1 | 0 | 2 of 2 reviewed |
| WY | 2 | 1 | 0 | 1 | 0 | 2 of 2 reviewed |
Publishes a base URL that answered
- Premera Blue Cross Blue Shield of Alaska (AK): 2 of 2 listed surfaces answered when they were checked
- Ambetter of Alabama (AL): 1 of 1 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Alabama (AL): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (AL): 1 of 1 listed surfaces answered when they were checked
- Ambetter from Arizona Complete Health (AZ): 1 of 1 listed surfaces answered when they were checked
- Cigna HealthCare of Arizona, Inc (AZ): 2 of 2 listed surfaces answered when they were checked
- Imperial Insurance Companies, Inc. (AZ): 1 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (AZ): 1 of 1 listed surfaces answered when they were checked
- Ambetter Health of Delaware (DE): 1 of 1 listed surfaces answered when they were checked
- AmeriHealth Caritas Next (DE): 2 of 2 listed surfaces answered when they were checked
- 22 Health (FL): 2 of 2 listed surfaces answered when they were checked
- AmeriHealth Caritas Next (FL): 2 of 2 listed surfaces answered when they were checked
- AvMed (FL): 1 of 2 listed surfaces answered when they were checked
- Cigna Healthcare (FL): 2 of 2 listed surfaces answered when they were checked
- Cigna HealthCare of Florida, Inc. (FL): 2 of 2 listed surfaces answered when they were checked
- Florida Blue (BlueCross BlueShield FL) (FL): 2 of 2 listed surfaces answered when they were checked
- Florida Blue HMO (a BlueCross BlueShield FL company) (FL): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (FL): 1 of 1 listed surfaces answered when they were checked
- Wellpoint (FL): 1 of 2 listed surfaces answered when they were checked
- Ambetter Health (IA): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (IA): 1 of 1 listed surfaces answered when they were checked
- Wellmark Health Plan of Iowa, Inc. (IA): 1 of 1 listed surfaces answered when they were checked
- Ambetter Health (IN): 1 of 1 listed surfaces answered when they were checked
- Anthem Blue Cross and Blue Shield (IN): 1 of 2 listed surfaces answered when they were checked
- CareSource (IN): 2 of 2 listed surfaces answered when they were checked
- Cigna Healthcare (IN): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (IN): 1 of 1 listed surfaces answered when they were checked
- Ambetter from Sunflower Health Plan (KS): 1 of 1 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Kansas City (KS): 2 of 2 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Kansas, Inc. (KS): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (KS): 1 of 1 listed surfaces answered when they were checked
- Ambetter from Louisiana Healthcare Connections (LA): 1 of 1 listed surfaces answered when they were checked
- AmeriHealth Caritas Next (LA): 2 of 2 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Louisiana (LA): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (LA): 1 of 1 listed surfaces answered when they were checked
- Ambetter from Meridian (MI): 1 of 1 listed surfaces answered when they were checked
- Blue Care Network of Michigan (MI): 1 of 1 listed surfaces answered when they were checked
- Blue Cross Blue Shield of Michigan Mutual Insurance Company (MI): 1 of 1 listed surfaces answered when they were checked
- Priority Health (MI): 1 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (MI): 1 of 1 listed surfaces answered when they were checked
- Ambetter Health (MO): 1 of 1 listed surfaces answered when they were checked
- Anthem Blue Cross and Blue Shield (MO): 1 of 2 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Kansas City (MO): 2 of 2 listed surfaces answered when they were checked
- Cox HealthPlans (MO): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (MO): 1 of 1 listed surfaces answered when they were checked
- Ambetter Health (MS): 1 of 1 listed surfaces answered when they were checked
- Cigna Healthcare (MS): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (MS): 1 of 1 listed surfaces answered when they were checked
- Ambetter of North Carolina (NC): 1 of 1 listed surfaces answered when they were checked
- AmeriHealth Caritas Next (NC): 2 of 2 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of NC (NC): 2 of 2 listed surfaces answered when they were checked
- Cigna Healthcare (NC): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (NC): 1 of 1 listed surfaces answered when they were checked
- Ambetter Health (NE): 1 of 1 listed surfaces answered when they were checked
- Blue Cross and Blue Shield of Nebraska (NE): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (NE): 1 of 1 listed surfaces answered when they were checked
- Ambetter from Buckeye Health Plan (OH): 1 of 1 listed surfaces answered when they were checked
- Anthem Blue Cross and Blue Shield (OH): 1 of 2 listed surfaces answered when they were checked
- CareSource (OH): 2 of 2 listed surfaces answered when they were checked
- MedMutual (OH): 1 of 1 listed surfaces answered when they were checked
- Paramount (OH): 1 of 1 listed surfaces answered when they were checked
- UnitedHealthcare (OH): 1 of 1 listed surfaces answered when they were checked
- Ambetter of Oklahoma (OK): 1 of 1 listed surfaces answered when they were checked
- CommunityCare (OK): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (OK): 1 of 1 listed surfaces answered when they were checked
- Cigna Healthcare (TX): 2 of 2 listed surfaces answered when they were checked
- Imperial Insurance Companies, Inc. (TX): 1 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (TX): 1 of 1 listed surfaces answered when they were checked
- WellPoint (TX): 1 of 2 listed surfaces answered when they were checked
- Anthem Blue Cross and Blue Shield (WI): 1 of 2 listed surfaces answered when they were checked
- CareSource (Common Ground Healthcare) (WI): 2 of 2 listed surfaces answered when they were checked
- Group Health Cooperative-SCW (WI): 1 of 2 listed surfaces answered when they were checked
- HealthPartners (WI): 1 of 1 listed surfaces answered when they were checked
- MercyCare Health Plans (WI): 2 of 2 listed surfaces answered when they were checked
- Network Health (WI): 1 of 2 listed surfaces answered when they were checked
- Quartz (WI): 2 of 2 listed surfaces answered when they were checked
- Security Health Plan (WI): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (WI): 1 of 1 listed surfaces answered when they were checked
- CareSource (WV): 2 of 2 listed surfaces answered when they were checked
- UnitedHealthcare (WY): 1 of 1 listed surfaces answered when they were checked
Publishes a base URL that did not answer
A finding about the public record rather than a gap in this one. Such an endpoint stays listed and keeps being probed from every vantage, because an entry that was dropped cannot be corrected.
- Blue Cross Blue Shield of Arizona (AZ): 1 listed surface, each published by the organization and not retrievable on the date it was checked
- CHRISTUS Health Plan (LA): 1 listed surface, each published by the organization and not retrievable on the date it was checked
- Blue Cross and Blue Shield of Oklahoma (OK): 1 listed surface, each published by the organization and not retrievable on the date it was checked
- Blue Cross and Blue Shield of Texas (TX): 1 listed surface, each published by the organization and not retrievable on the date it was checked
- CHRISTUS Health Plan (TX): 1 listed surface, each published by the organization and not retrievable on the date it was checked
- Aspirus Health Plan (WI): 2 listed surfaces, each published by the organization and not retrievable on the date it was checked
What "did not answer" was
What "did not answer" was, for each of the 7 listed surfaces these organizations publish. This is a property of the publishing run, not of the curation record above: the population says on what basis the entry earned its place in the registry, and the condition says what the surface did on the day this page was generated.
These counts are never added to each other. A surface that answered and declined this request and a surface that produced no document are different facts about different things, and one number covering both is what this breakdown exists to replace. This project does not read either condition as a choice or as a defect; it reports the condition it observed, and the counts below are of surfaces, not of organizations.
| Condition | Surfaces | What it means |
|---|---|---|
| Answered, and declined this request | 1 | the surface answered, and declined to serve this request |
| Answered, but not with the document | 4 | the surface answered, and the answer was not the document |
| No answer reached this project | 2 | no answer from the surface reached this project |
| Condition not in the vocabulary | 0 | the surface produced a condition this project's closed vocabulary has no label for, published as itself rather than filed under the nearest label |
| Vantages reported different conditions | 0 | the reporting vantages did not report the same condition, and this project publishes the disagreement rather than choosing one of them |
| No condition recorded on this build | 0 | this build recorded no condition for the surface. A fact about the build, never about the organization |
| Organization | State | Endpoint | Condition |
|---|---|---|---|
| Blue Cross Blue Shield of Arizona | AZ | bcbs-arizona-patient-access | Answered, and declined this request |
| CHRISTUS Health Plan | LA | christus-provider-directory | Answered, but not with the document |
| Blue Cross and Blue Shield of Oklahoma | OK | hcsc-provider-directory | Answered, but not with the document |
| Blue Cross and Blue Shield of Texas | TX | hcsc-provider-directory | Answered, but not with the document |
| CHRISTUS Health Plan | TX | christus-provider-directory | Answered, but not with the document |
| Aspirus Health Plan | WI | aspirus-patient-access | No answer reached this project |
| Aspirus Health Plan | WI | aspirus-provider-directory | No answer reached this project |
Reviewed, no base URL a stranger could read
The federal rule these organizations are in frame for does not require an issuer to print its base URL where an unregistered visitor can read it, so this is not a compliance finding about anyone. What a missing base URL costs is narrower and worth naming exactly: conformance stops being checkable by anyone who has not already entered a business relationship with the plan.
- Moda Health Plan, Inc. (AK): Moda's interoperability page prints no base URL. It routes developers to a vendor-hosted developer portal, and that portal served an automated client nothing but its own heading, so no address was read.
- Oscar Insurance Company (AL): Oscar's interoperability developer page prints no base URL for either surface. It directs a developer to create an account with 1upHealth, the platform Oscar delegates Patient Access to, and documents no Provider Directory API anywhere on the page.
- Antidote Health Plan of Arizona, Inc. (AZ): the plan's interoperability page describes its APIs and withholds every base URL, releasing endpoint documentation only after organization registration and approval by email; the same gate is applied to the Provider Directory API, which the page groups under public APIs that still require registration
- Oscar Health Plan, Inc. (AZ): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Highmark Blue Cross Blue Shield Delaware (DE): Highmark Blue Cross Blue Shield Delaware's APIs are published on the Highmark Health Interoperability Developer Portal, and no base URL for them appears in any document this project could retrieve. The portal's API catalog is browsable without an account and lists the FHIR Patient Access and Provider Directory APIs by name, but each entry's host and base path are rendered by the portal's own JavaScript and were not served to an automated client; Highmark's member-facing CMS and ONC interoperability page names the entity and prints no address either. The portal presents its six FHIR APIs under one 'Highmark Health Organization' heading rather than per legal entity, and Highmark's interoperability page lists Highmark BCBSD Inc. as one of the five entities the rule reaches.
- Ambetter Health (FL): the issuer's own interoperability page describes both APIs and prints no base URL for either, directing developers to Centene's Partner Portal, which serves a 1,128-byte single-page-app shell with no API content to an unregistered visitor - the same posture, byte for byte, as the Texas Ambetter brand's
- Capital Health Plan (FL): the issuer's only interoperability page says CHP has contracted with 1Up Resources to manage both APIs and prints no base URL; every 'FHIR API' link on it lands on the vendor's generic FHIR education page, which prints none either and never mentions CHP. The page itself notes that the mandate requires this information to be publicly available
- Florida Health Care Plans (FL): the issuer's third-party API page says FHCP has contracted with mPulse to manage and support both APIs and prints no base URL; the vendor's public documentation prints only multi-tenant HealthTrio hosts with no FHCP identifier anywhere, and those hosts reject the standard FHIR media type, answering 406 to an Accept: application/fhir+json request for /metadata
- Health First Commercial Plans, Inc. (FL): the issuer's developer documentation says Health First Health Plans has partnered with Epic for its interoperability solution and prints no base URL, linking only to Epic's generic developer pages; neither documentation page mentions a Provider Directory API at all. Epic's public endpoint directory prints a 'Health First' row that answers, but nothing connects that row to this issuer beyond the shared name, and a vendor's directory row is the attribution this registry excludes
- Molina Healthcare (FL): the issuer's developer portal - an Azure API Management instance operated by Cognizant TriZetto - names 'FL - Molina Healthcare' in its servicing list and prints no hostname anywhere; the API list it serves an unregistered visitor renders no API entries, only portal chrome, and its 47-page product documentation PDF is generic vendor material containing no occurrence of 'Molina' and no absolute base URL
- Oscar Health Maintenance Organization of Florida (FL): the issuer's member and developer pages describe the Patient Access API as delegated to 1upHealth and print no endpoint; reaching one requires creating a 1upHealth developer account. No Provider Directory API documentation exists anywhere on hioscar.com: its complete sitemaps hold only the two patient-access pages and their Spanish variants
- Avera Health Plans (IA): the plan names its Patient Access vendor but neither the plan nor the vendor prints a finished base URL for it; the vendor's only published addresses are a testing environment it describes as containing synthetic data, which this project does not count as production
- Medica (IA): Medica publishes both base URLs in a document it hosts, but the live file is unreachable to automated clients: every request returns a bot-challenge page. The version read was an Internet Archive capture of Medica's own URL from 2024-07-14, and a 2024 snapshot is not evidence about what is published today, so the addresses are held out of the registry until the live document is confirmed current.
- Oscar Insurance Company (IA): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Medica (KS): Medica publishes both base URLs in a document it hosts, but the live file is unreachable to automated clients: every request returns a bot-challenge page. The version read was an Internet Archive capture of Medica's own URL from 2024-07-14, and a 2024 snapshot is not evidence about what is published today, so the addresses are held out of the registry until the live document is confirmed current.
- Oscar Insurance Company (KS): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- HMO Louisiana (LA): the parent publishes base URLs but scopes them in its own words to its own coverages, and names this subsidiary on that page only in boilerplate; nothing published by either entity names HMO Louisiana in connection with a FHIR API
- McLaren Health Plan Community (MI): the plan names its Patient Access vendor and links only that vendor's generic documentation, which prints demonstration hosts and directs developers to contact the vendor for production endpoints; no base URL for this plan is printed anywhere, and no Provider Directory API is published
- Oscar Insurance Company (MI): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Medica (MO): Medica publishes both base URLs in a document it hosts, but the live file is unreachable to automated clients: every request returns a bot-challenge page. The version read was an Internet Archive capture of Medica's own URL from 2024-07-14, and a 2024 snapshot is not evidence about what is published today, so the addresses are held out of the registry until the live document is confirmed current.
- Oscar Insurance Company (MO): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Molina Healthcare (MS): Molina's interoperability developer portal prints no base URL that can be read without registering for an account. The portal is the organization's own, it names the platform it runs on, and the addresses sit behind the registration step.
- Oscar Health Plan, Inc. (MS): Oscar's interoperability developer page prints no base URL for either surface. It directs a developer to create an account with 1upHealth, the platform Oscar delegates Patient Access to, and documents no Provider Directory API anywhere on the page.
- Oscar Health Plan of North Carolina, Inc (NC): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Medica (NE): Medica publishes both base URLs in a document it hosts, and the live document is not served to an automated client: every request returns a refusal rather than the file. No live read was obtained on this date, so the addresses stay out of the registry rather than entering it on the strength of a document nobody here has read in its current form.
- Oscar Insurance Company (NE): Oscar's interoperability developer page prints no base URL for either surface. It directs a developer to create an account with 1upHealth, the platform Oscar delegates Patient Access to, and documents no Provider Directory API anywhere on the page.
- Antidote Health Plan of Ohio, Inc. (OH): the plan publishes a CMS interoperability page of its own and withholds every base URL on it: 'Authorization server URL documentations are shared after successful organization registration and approval.' The gate is applied to the Provider Directory API too, which the same page groups under 'Public APIs' that 'still require registration but will be automatically approved'
- Molina Healthcare (OH): Ohio's member site routes third-party developers to Molina's national developer portal with a bare 'click here to register' link and prints no hostname; that portal publishes no production endpoint for any state, and Ohio is not among the states its Servicing list names
- Oscar Health Insurance (OH): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site
- Oscar Insurance Corporation of Ohio (OH): the same two brand-level pages that cover the other Ohio Oscar issuer, publishing no base URL and naming no legal entity, state or HIOS id; nothing published distinguishes this entity from Oscar Health Insurance, and nothing supports asserting a shared endpoint either
- SummaCare (OH): the base URLs are not printed: the vendor portal SummaCare names as its API documentation publishes a template, 'https://apis.ssctech.com/interop-[Healthplan]/open/fhir/R4/', plus a separate table mapping SummaCare to the abbreviation 'summa'. Every component is the publisher's and the substitution rule is the publisher's own instruction, but the finished string appears nowhere, so it is held out of the registry rather than assembled here
- Medica (OK): Medica publishes both base URLs in a document it hosts, but the live file is unreachable to automated clients: every request returns a bot-challenge page. The version read was an Internet Archive capture of Medica's own URL from 2024-07-14, and a 2024 snapshot is not evidence about what is published today, so the addresses are held out of the registry until the live document is confirmed current.
- Mending Health (OK): the plan publishes a complete Patient Access API notice naming every implementation standard it supports, and then releases the endpoint only on request by email; no base URL appears in the document, and no Provider Directory API is published or mentioned anywhere on the site
- Oscar Insurance Company (OK): Oscar publishes two brand-level interoperability pages and no base URL on either; Patient Access is delegated to a third-party platform reachable only by creating an account with that vendor, and no Provider Directory API is documented anywhere on the site.
- Ambetter from Superior HealthPlan (TX): the issuer's own interoperability page describes both APIs and prints no base URL for either, sending developers to Centene's partner portal instead; that portal returns a 1,128-byte shell with no API listing to an unregistered visitor, so reading either base URL requires a Centene account
- Baylor Scott and White Health Plan (TX): the issuer's interoperability page prints no base URL and hands off to its vendor's developer portal on a third-party domain; the page does not mention a Provider Directory API at all
- Community First (TX): the issuer's interoperability page names its vendor and the implementation guides it conforms to, and prints no base URL; the only technical link it offers is the vendor's own developer documentation on the vendor's domain
- Community Health Choice (TX): the issuer's interoperability page describes both APIs and prints only a link to its own developer portal; the portal's landing page prints no base URL and offers an unregistered visitor nothing but Sign in and Sign up, while calling the Provider Directory API a 'publicly available standards-based API set'
- Harbor Health (TX): no interoperability, API, FHIR, or developer documentation of any kind exists on the issuer's site
- Moda Health Plan, Inc. (TX): the issuer's interoperability page prints one address and it is its vendor's developer portal on a third-party domain, not a FHIR base URL
- Molina Healthcare (TX): the issuer runs its own developer portal on its own domain and that portal prints no hostname anywhere: the API list it serves an unregistered visitor carries four sandbox APIs with relative paths and no service URL, and no production API at all
- Oscar Insurance Company (TX): the issuer delegates its Patient Access API to a vendor platform and prints no endpoint; obtaining one requires a third-party developer account. There is no Provider Directory API page on the issuer's site at all
- Sendero Health Plans, Local Nonprofit (TX): the issuer's interoperability section names FHIR, OAuth 2.0 and the provider and pharmacy directories as public non-PHI data, and prints no endpoint; its 'learn more about API' link goes to a vendor QA host that answers 403, and its developer path issues credentials by email after a compliance review
- Dean Health Plan (WI): Dean's own site documents a Patient Access API delivered through a third-party platform and publishes no base URL, linking only to that vendor's generic help-center home; no Dean-published Provider Directory endpoint exists. Its parent does publish base URLs, but that document names only the parent and never names Dean, so it cannot be attributed to this row
- Medica (WI): Medica does publish both base URLs in a document it hosts, but the live file is unreachable to automated clients and the version read was an Internet Archive capture from 2024-07-14. A 2024 snapshot is not evidence about what is published today, so the addresses are held out of the registry until the live document is confirmed current
- Highmark Blue Cross Blue Shield West Virginia (WV): Highmark Blue Cross Blue Shield West Virginia's APIs are published on the Highmark Health Interoperability Developer Portal, and no base URL for them appears in any document this project could retrieve. The portal's API catalog is browsable without an account and lists the FHIR Patient Access and Provider Directory APIs by name, but each entry's host and base path are rendered by the portal's own JavaScript and were not served to an automated client; Highmark's member-facing CMS and ONC interoperability page names the entity and prints no address either. The portal presents its six FHIR APIs under one 'Highmark Health Organization' heading rather than per legal entity, and Highmark's interoperability page lists Highmark West Virginia Inc. as one of the five entities the rule reaches.
- Blue Cross Blue Shield of Wyoming (WY): Blue Cross Blue Shield of Wyoming's APIs are published on the Highmark Health Interoperability Developer Portal, and no base URL for them appears in any document this project could retrieve. The portal's API catalog is browsable without an account and lists the FHIR Patient Access and Provider Directory APIs by name, but each entry's host and base path are rendered by the portal's own JavaScript and were not served to an automated client; Highmark's member-facing CMS and ONC interoperability page names the entity and prints no address either. The portal's Getting Started page names three APIs for what it calls the BCBS Wyoming Organization, one of them a Patient Access API, and gives BCBS Wyoming its own registration code separate from Highmark's.
Not yet reviewed
43 organizations, in the states this project has not reached. Each state-issuer's documentation has to be found and read by a person, which is why cohorts are published per state as they are completed rather than all at once. Until a state is reviewed its issuers are carried here and nowhere else, and never rendered as publishing nothing. See the sampling frame.