# 2026 CMS Interoperability Rule: Audit Before Building a FHIR Claims API

Dr. Amira Hassan · November 12, 2026

> This guide explains why a FHIR Claims API is not the default for 2026 clinic leaders despite claims of a 20% patient-access lag. The answer changes only after a

This guide explains why a FHIR Claims API is not the default for 2026 clinic leaders despite claims of a 20% patient-access lag. The answer changes only after a 30-day local audit proves a claims-data access gap that exceeds portal and call-center failures.

![misty dawn over glass and steel hospital campus corridors glowing](https://static.mm-ais.com/article-images-ai/2026-cms-interoperability-rule-audit-bef-ai-0a079a48.jpg)
misty dawn over glass and steel hospital campus corridors glowing

## How the Patient Access API Moves Claims

Before you commit budget to a vendor-labeled “FHIR Claims API,” open the CMS-9115-F deep-read table of contents and trace the four distinct surfaces: Patient Access API, Payer-to-Payer Data Exchanges, Provider Directory API, and Compliance and Testing. A sales deck that collapses all four into a single “claims API” line item is misrepresenting the regulation and will force re-work when auditors ask which surface you actually implemented.

Next, verify which rule track your contract references. Confirm the cited rule number against the named CMS materials before any integration ticket moves forward; in this article, CMS-9115-F is the grounded source for the Patient Access API surfaces. If a statement of work cites a different rule, ask for the document name, page, and publication date and check it before the first sprint begins.

With the correct surface identified, extract the FHIR resource and data-element list directly from CMS-9115-F. Do not accept a vendor matrix that adds or omits fields to simplify mapping. Each element you fail to expose becomes a failed retrieval later; each element you add without regulatory basis risks a compliance finding. Treat the published list as the ceiling and floor simultaneously.

Run the 30-day measurement cycle described in the reader rule: count eligible members, access requests, failed retrievals, and PDF conversion volume. If failures cluster in claims-data fields and exceed your portal or call-center baseline, the gap is real and the API is justified. If failures are scattered across scheduling, demographics, or document conversion, the fix lies in those systems, not in a claims endpoint.

Remember that none of the three grounded rule or FAQ documents publishes a 20% patient-access lag figure. Because no audited baseline exists, the measurement-first hybrid is the only defensible path: it converts an unverifiable industry claim into your own audited denominator set, protects you from over-building, and produces the evidence base required for the next cycle of investment.

![How the Patient Access API Moves Claims — 2026 CMS Interoperability Rule](https://static.mm-ais.com/article-images-ai/2026-cms-interoperability-rule-audit-bef-ai-5e311ae1.jpg)

## Evidence: No CMS-Sourced 20% Lag

This section makes one claim and then stops: across the three grounded CMS rule and reference reads behind this article, none publishes a 20% patient-access lag. That is a statement about those documents, not about the world. The practical test it gives you is a citation check. When a vendor deck, a consultant's business case, or a trade article hands you a lag figure, ask for the document name, the page, and the publication date, then open the source. If the number traces to a summary, a vendor blog, or an unsourced secondary post rather than to a CMS rule text or FAQ, treat it as an assertion, not a benchmark.

The first read is the CMS-9115-F deep read on edit.cms.gov: 26 pages, published June 10, 2021, issued by CMS's Office of Burden Reduction and Health Informatics. Its table of contents runs from a general overview into Patient Access API, Payer-to-Payer Data Exchanges, Provider Directory API, and Compliance and Testing of the Required APIs, then continues through medical loss ratio, NPPES digital contact information, and a proposed rule on prior authorization. Read the table of contents first. It tells you what a document is for. This one is rule-making material: it establishes surfaces payers must operate and how conformance is tested. Nowhere in it is a lag benchmark, so it cannot anchor a business case that assumes one.

The second read is the CMS Interoperability and Patient Access final rule FAQ on cms.gov. It opens with a scope question, not a performance one: whether impacted payers must convert large unstructured documents such as portable document formats (PDF) to FHIR to support clinical data. That question is useful for deciding whether document conversion belongs in your project boundary at all. It is silent on how long members wait for anything. A document that answers "must we" is not a document that answers "how long," and treating the first as the second is how a scope check gets misread as a delay rate.

The third read is CMS's interoperability resources page on qhpcertification.cms.gov, which points to CMS interoperability resources and application materials. It is an index, not a measurement instrument, and it carries no lag rate either. Three reads, three different document types, one shared absence.

State the limit of this finding plainly, because it will be quoted back at you. Absence in three documents is not proof that no such figure exists anywhere; it is proof that you cannot source one from the CMS material you are required to comply with. That leaves the lag number to be produced locally, by your own count, on your own population, over your own measurement window. Any figure that arrives without that provenance is a placeholder, and a placeholder is not a baseline.

![Evidence: No CMS-Sourced 20% Lag — 2026 CMS Interoperability Rule](https://static.mm-ais.com/article-images-pixabay/2026-cms-interoperability-rule-audit-bef-da3581fb.jpg)

## Options Compared: Claims API or Lag Fix

For 2026 clinic leaders, the choice is not between a FHIR Claims API and a lag fix; it is between building on an unverified assumption and building on a 30-day audit. Option A, the FHIR Claims API build, closes claims-data portability but requires the CMS-9115-F Patient Access API resource scope plus the CMS FAQ PDF answer on whether large unstructured documents like PDFs must be converted to FHIR. Option B, access-lag remediation, closes portal, call-center, and PDF friction using your own request log. Option C, the measurement-first hybrid, runs a 30-day audit of eligible members, access requests, failed retrievals, and document-conversion volume before targeting either build or process.

| Option | Closes | Requires | Trigger to Proceed |
| --- | --- | --- | --- |
| A. FHIR Claims API build | Claims-data portability | CMS-9115-F Patient Access API scope; CMS FAQ PDF on PDF-to-FHIR conversion | Failures cluster in claims-data fields, not portal/call/PDF friction |
| B. Access-lag remediation | Portal, call, and PDF friction | Your access-request log and failure taxonomy | Failures cluster in portal/call/PDF friction |
| C. Measurement-first hybrid | Both, conditionally | 30-day audit of eligible members, requests, failed retrievals, PDF volume | Winner when no audited baseline exists |

Do not compare a vendor quote to a rule section. Compare the quoted API bundle to the specific CMS-9115-F surface it claims to implement. A vendor-labeled "FHIR Claims API" may bundle the Patient Access API, Payer-to-Payer Data Exchanges, Provider Directory API, or Compliance and Testing surfaces, and only the Patient Access API surface is the one that supports member-facing claims retrieval. If the bundle does not map to that surface, the quote is not a claims-API quote and Option A is not available.

The default is Option C because no grounded CMS source publishes a 20% patient-access lag figure. Across the CMS rule and reference reads, that percentage is absent, so any business case built on it is speculative. Instead, measure your own denominators for 30 days: eligible members, access requests, failed retrievals, and document-conversion volume. If failed retrievals cluster in claims-data fields and exceed your portal and call baselines, proceed to Option A. If they cluster in portal, call, or PDF friction, proceed to Option B.

Until that audit exists, treat the hybrid as the winner. It converts an unverified national claim into a local threshold, and it prevents a 2026 budget from being spent on a surface the vendor cannot prove maps to CMS-9115-F. Measure first, then build.

![Options Compared: Claims API or Lag Fix — 2026 CMS Interoperability Rule](https://static.mm-ais.com/article-images-pixabay/2026-cms-interoperability-rule-audit-bef-d9b65942.png)

## Costs and Numbers That Matter

Before any budget request for a FHIR Claims API, clinic leaders must collect four denominators over a fixed 30-day window: eligible members, access requests, failed retrievals, and document-conversion volume. These numbers are the only defensible basis for a business case, because the alternative is borrowing a vendor percentage that no grounded CMS source supports. The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) establishes the required surfaces, but it does not publish a 20% patient-access lag figure; that absence is precisely why the audit must be local.

Start with eligible members, counted by plan type. Not every commercial plan falls under the mandate, so verify the impacted-payer scope against CMS-9115-F and the CMS FAQ rather than assuming universal coverage. The FAQ explicitly addresses which payers are required to comply with and implement payer-to-payer data exchange requirements, and the rule itself distinguishes the Patient Access API from other surfaces. Count only members whose plans are confirmed in scope, because an inflated denominator will make every subsequent failure rate look artificially low.

Next, compute failed retrievals per 1,000 requests from your own portal or call logs over the same 30-day window, and record the observation date alongside the rate. Do not substitute a vendor percentage for this figure. A failure rate is only meaningful when the numerator (failed retrievals) and denominator (total requests) come from the same system and the same period, and when the observation date is documented so the baseline can be re-measured later.

Price the cost categories that actually drive the decision: internal FTE hours for API testing, any payer integration fees if quoted, PDF conversion handling, and member support. The CMS FAQ raises the question of whether impacted payers must convert large unstructured documents like PDFs to FHIR to support clinical data, which means conversion handling is a real line item rather than an abstraction. Member support costs rise when members cannot retrieve claims through existing channels, so track call volume and resolution time during the audit window.

| Denominator | Source | Threshold for API Justification |
| --- | --- | --- |
| Eligible members | Plan roster, verified against CMS-9115-F and CMS FAQ | Confirmed impacted-payer scope only |
| Access requests | Portal or call log, 30-day window | Fixed observation date recorded |
| Failed retrievals | Own logs, not vendor percentage | Clusters in claims-data fields |
| Document conversion | PDF volume, per CMS FAQ scope | FTE hours plus conversion handling |

The decision rule is simple: build the FHIR Claims API only if failed retrievals cluster in claims-data fields and exceed your own portal and call baselines. If the audit shows failures are concentrated in process or portal failures rather than in the claims data itself, the correct move is a measurement-first hybrid that fixes the access path before adding API infrastructure. This keeps the clinic from spending on a solution that does not address the actual bottleneck.

![Costs and Numbers That Matter — 2026 CMS Interoperability Rule](https://static.mm-ais.com/article-images-pixabay/2026-cms-interoperability-rule-audit-bef-90c89f34.jpg)

## What the Evidence Does Not Establish

Before treating the 20% patient-access lag as a settled fact, clinic leaders must recognize the specific conditions under which that premise dissolves. The CMS-9115-F rule targets a defined set of regulated entities, not every organization that handles claims. If your clinic operates as a provider-only organization with no payer API obligation, the regulatory lag premise does not apply to you; your measurement should instead rely on EHR and portal logs rather than a claims-data access audit. Similarly, if your payer mix is dominated by plans outside the CMS-9115-F scope, the rule's requirements and any associated lag assumptions break down, yet a local lag audit remains the correct diagnostic tool.

A third edge case involves clinics where claims arrive predominantly as PDFs. The CMS FAQ on interoperability and patient access poses the conversion of large unstructured documents like PDFs to FHIR as an open question rather than a settled universal mandate. This distinction is critical: do not convert a FAQ question into a hard deadline or a conversion guarantee. Before building any FHIR Claims API, verify whether your payers actually deliver structured data or whether the workflow is still dominated by document retrieval.

| Edge Case | Why the 20% Lag Premise Breaks | Recommended Action |
| --- | --- | --- |
| Plan not in CMS-9115-F scope | Regulatory lag premise does not apply to excluded payers | Still run local lag audit |
| Provider-only clinic | No payer API obligation exists | Use EHR and portal logs |
| PDF-heavy claims | CMS FAQ poses conversion as a question, not a mandate | Verify before build |

Furthermore, no trial or participant-level study in the available sources literature links a FHIR Claims API to a 20% reduction in access lag. The absence of such evidence means the figure cannot serve as a justification on its own. Instead, the decision must rest on your own measured reality: count eligible members, access requests, failed retrievals, and PDF volume over a full 30-day period. Only if failures cluster specifically in claims-data fields and exceed your portal and call-center baselines does the API become the right investment.

Until that audit is complete, the default position is a measurement-first hybrid. This approach preserves the ability to fix process and portal failures, which are often the true source of delay, while keeping the FHIR Claims API option available for when the data proves it necessary. Building on an unverified percentage risks spending budget on a solution for a problem that may not exist in your specific payer mix.

![What the Evidence Does Not Establish — 2026 CMS Interoperability Rule](https://static.mm-ais.com/article-images-pixabay/2026-cms-interoperability-rule-audit-bef-1dda13ef.jpg)

## 10,000-Member Lag Audit

To size a local lag audit, count eligible members, access requests, failed retrievals, and PDF volume over a fixed 30-day window. Report failed retrievals per 1,000 requests and per 100 eligible members, and calculate PDF handling time from your own measured minutes per PDF. The audit produces a local lag estimate against a denominator you can defend, plus a staff-time figure for the workarounds those failures force.

The lag estimate is the third row: 100 ÷ 500 × 1,000 = 200 failed retrievals per 1,000 requests. Restated against membership, the same 100 failures are 100 ÷ 10,000 × 100 = 1 failed retrieval per 100 eligible members per 30 days. Carry both forms, because they answer different questions — the per-1,000-requests figure describes the retrieval path, the per-100-members figure describes how much of your population that path touches. The PDF row stays separate on purpose: 40 × 10 = 400 minutes, or 6 hours 40 minutes of staff time inside the window. CMS's Interoperability and Patient Access FAQ document takes up whether impacted payers must convert large unstructured documents such as PDFs to FHIR to support the Patient Access API, which is why PDF volume is a worksheet field rather than a footnote.

Record three checkpoints instead of waiting for day 30. At day 10, log observed access requests and compare against a pro-rata share of the 30-day count — the illustrative 500 over 30 days implies roughly 167 by day 10 (500 ÷ 3 = 166.7). At day 20, log observed failed retrievals against roughly two-thirds of the 30-day count, about 67 of the illustrative 100. At day 30, log PDF volume and multiply by your measured minutes per PDF, not the worksheet's assumed 10.

Two comparisons then decide what the counts mean. First, sort failed retrievals by field: losses concentrated in claims-data fields point at the retrieval path, while losses spread across enrollment, demographic, or provider-directory responses point somewhere else. Second, set that failure count beside your own portal and call-center baseline for the same 30 days. A claims-data cluster that stays below the volume your staff already absorbs through existing channels does not clear the bar; one that exceeds it does. The worksheet supplies the number for that comparison — it does not settle it.

## Worked Example: Run the Numbers

To work the arithmetic, use your own observed counts for eligible members, call-center requests, portal attempts, and failed retrievals over the same 30-day window. Separate failures caused by portal or call-center process from failures caused by incomplete, malformed, or missing claims-data fields. Compare the two clusters directly; only a claims-data cluster that exceeds your portal and call baselines supports a FHIR Claims API build.

Use the audit's total access requests as the denominator. Separate portal and call-center process failures from claims-data field failures. Compare the two clusters directly; if the claims-data cluster is larger and exceeds your portal and call baselines, the FHIR Claims API build is justified. If process failures dominate, fix the access path first.

Now apply the threshold. The rule for this audit is that a FHIR Claims API is justified only when claims-data field failures cluster and exceed the portal/call baselines. In this example, the claims-data failures (60) do not exceed the process failures (150). Therefore, the winner for this scenario is not a new API build; it is a measurement-first hybrid that fixes the portal timeout and call-center navigation first. The break-even trigger for this example would require the claims-data failures to rise above 150, or for the process failures to drop below 60 while claims-data failures remain at 60.

This arithmetic illustrates why the default posture for 2026 leaders is measurement-first: before any vendor-labeled FHIR Claims API is commissioned, run the local 30-day audit and compare claims-data failures with portal and call-center baselines.

 plan must collect the four denominators: eligible members, access requests, failed retrievals, and PDF volume. The CMS Interoperability and Patient Access Final Rule FAQ notes that payers are not required to convert large unstructured documents like PDFs to FHIR solely to support clinical data, which means PDF volume is a distinct metric that must be weighed separately from structured claims failures. If the audit shows the process failures dominate, as in this example, the investment returns nothing until the portal and call-center baselines are corrected.

Only when the claims-data failure cluster crosses the process baseline does the business case flip. In this worked example, that flip requires a minimum of 151 claims-data failures within the same 30-day window, or a proportional reduction in process failures. Until that trigger is met, the plan should continue measuring, fixing process, and re-auditing, rather than committing budget to an API that addresses a symptom the local data does not yet support.

## Decision Rules for Clinic Leaders

For 2026 clinic leaders, the decision to fund a FHIR Claims API is not a technology choice but a measurement outcome. Before any vendor contract, run a 30-day audit capturing four denominators: eligible members, total access requests, failed retrievals, and PDF volume. This local baseline is the only defensible threshold, because no grounded CMS source publishes a 20% patient-access lag figure to serve as a budget trigger.

Apply the first if/then rule directly to your audit results. If failed retrievals per 1,000 requests exceed your own portal and call-center baseline, and those failures cluster specifically in claims-data fields rather than authentication or navigation, then scope a FHIR Claims API fix. If the failures are distributed across the portal or resolve through phone support, the correct action is portal and call-center remediation, not API development.

Scrutinize every external statistic before it enters your business case. If a 20% lag figure appears only in a vendor deck and cannot be located in CMS-9115-F or the CMS Interoperability and Patient Access FAQ, label it unverified and exclude it from your budget thresholds. The FAQ explicitly addresses whether impacted payers must convert large unstructured documents like PDFs to FHIR to support clinical data, but it does not quantify a patient-access lag percentage.

Verify regulatory scope before citing compliance deadlines. If your payer is not an impacted payer under CMS-9115-F, do not claim a regulatory deadline to justify the investment. Instead, rely on contract leverage and your local audit to build the case. The final rule distinguishes the Patient Access API from Payer-to-Payer Data Exchanges, Provider Directory API, and Compliance and Testing surfaces, so confirm which surface actually governs your arrangement.

| Audit Finding | Failure Pattern | Action |
| --- | --- | --- |
| Failed retrievals above portal/call baseline | Clustered in claims-data fields | Scope FHIR Claims API fix |
| Failed retrievals above portal/call baseline | Distributed across portal or resolved by phone | Portal/call remediation |
| 20% lag cited | Vendor deck only; absent from CMS-9115-F or FAQ | Label unverified; exclude from budget |
| Regulatory deadline cited | Payer not an impacted payer under CMS-9115-F | Use contract leverage and local audit |

When no audited lag baseline exists, the measurement-first hybrid remains the default. It captures your own denominators, isolates whether the problem lives in claims-data fields, and prevents a technology purchase from being driven by unverified vendor claims or misapplied regulatory deadlines.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Run the 30-day audit across your member population: log eligible members, access requests, failed retrievals, and PDF volume before making any build decision. | The FHIR Claims API is justified only after a local audit shows a real claims-data access gap — not before. |
| 2 | Bucket every failed retrieval by data field, separating claims-data fields from enrollment, formulary, and provider-directory fields. | The build case exists only if failures cluster in claims-data fields; scattered failures point to a different fix. |
| 3 | Set your own portal and call-center baseline for the same window and compare failed-retrieval counts against it. | The API must exceed your existing portal/call baseline to earn its cost — no external benchmark can make that case for you. |
| 4 | Do not wire the 20% figure into any compliance trigger; confirm your obligations against CMS-9115-F and the CMS Interoperability and Patient Access Final Rule FAQ. | No grounded CMS source publishes that patient-access lag figure, so it cannot gate your decision. |
| 5 | Apply the decision gate: build the FHIR Claims API only if failures cluster in claims-data fields and exceed your portal/call baseline; otherwise run the measurement-first hybrid. | This ties spend to a demonstrated gap instead of an assumed one. |
| 6 | Confirm your entity type — payer, Medicaid, CHIP, or Medicare Advantage plan — and map your payer-to-payer data exchange and Patient Access API obligations for 2026. | The rule's requirements attach to these specific entities, so scope the build to what actually applies to you. |

## Frequently Asked Questions

**What proof do we need before we stop considering a FHIR Claims API for our clinic?**

The answer changes only after a 30-day local audit proves a claims-data access gap that exceeds portal and call-center failures.

**How many distinct data surfaces does the CMS guidance identify for claims access?**

CMS-9115-F traces four distinct surfaces: Patient Access API, Payer-to-Payer Data Exchanges, Provider Directory API, and Compliance and Testing.

**What should we do if our vendor's sales deck combines all claims-related APIs into one line item?**

A sales deck that collapses all four into a single "claims API" line item is misrepresenting the regulation and will force re-work when auditors ask which surface you actually implemented.

**What should we verify before an integration ticket moves forward?**

Confirm the cited rule number against the named CMS materials before any integration ticket moves forward.

**What if our statement of work cites a different CMS rule?**

If a statement of work cites a different rule, ask for the document name, page, and publication date and check it before the first sprint begins.

**How should we handle vendor FHIR mapping when fields are added or omitted?**

Do not accept a vendor matrix that adds or omits fields to simplify mapping; extract the FHIR resource and data-element list directly from CMS-9115-F.

## Quick answers

| Why is a FHIR Claims API not the default for 2026 clinic leaders despite claims of a 20% patient-access lag? | The answer changes only after a 30-day local audit proves a claims-data access gap that exceeds portal and call-center failures. |
| --- | --- |
| What four distinct surfaces should be traced in the CMS-9115-F deep-read table of contents? | The four surfaces are the Patient Access API, Payer-to-Payer Data Exchanges, Provider Directory API, and Compliance and Testing. |
| What risk does a sales deck face if it collapses all four surfaces into a single claims API line item? | It is misrepresenting the regulation and will force re-work when auditors ask which surface you actually implemented. |
| What is the grounded source for the Patient Access API surfaces mentioned in the article? | CMS-9115-F is the grounded source for the Patient Access API surfaces. |
| What should a clinic leader do if a statement of work cites a different rule than the named CMS materials? | Ask for the document name, page, and publication date and check it before the first sprint begins. |

Also worth reading: **Prior Authorization API Deadline: CMS-0057-F Jan 2027 FHIR Testing vs ePA Fallback**: [Prior Authorization API Deadline: CMS-0057-F](https://getpulse.care/blog/prior-authorization-api-deadline-cms-0057-f-jan-2027-fhir-testing-vs-epa-fallback.php) · **2026 Referral Interoperability: Verify 48-Hour Completion and 31% Fax Reduction Claims**: [2026 Referral Interoperability: Verify 48-Hour](https://getpulse.care/blog/2026-referral-interoperability-verify-48-hour-completion-and-31-fax-reduction-claims.php) · **Remote Patient Monitoring Billing 2026: Device Code (CPT 99454) 16-Day Bill or Miss**: [Remote Patient Monitoring Billing 2026:](https://getpulse.care/blog/remote-patient-monitoring-billing-2026-device-code-cpt-99454-16-day-bill-or-miss.php)

### Related reading

- [COVID-19 Vaccine in Pregnancy: How to Verify Current Guidance](https://getpulse.care/blog/covid-19-vaccine-in-pregnancy-how-to-verify-current-guidance.php)
- [RSV Shot in Pregnancy: Give at 32–36 Weeks or Hold Until September?](https://getpulse.care/blog/rsv-shot-in-pregnancy-give-at-3236-weeks-or-hold-until-september.php)
- [Carpal Tunnel at 6 Weeks: Night-Splint Escalation vs Watchful Waiting](https://getpulse.care/blog/carpal-tunnel-at-6-weeks-night-splint-escalation-vs-watchful-waiting.php)
- [2026 Referral Interoperability: Verify 48-Hour Completion and 31% Fax Reduction Claims](https://getpulse.care/blog/2026-referral-interoperability-verify-48-hour-completion-and-31-fax-reduction-claims.php)
- [Respiratory Virus Vaccination Uptake: 2026 Standing Orders vs Clinician Prompts](https://getpulse.care/blog/respiratory-virus-vaccination-uptake-2026-standing-orders-vs-clinician-prompts.php)
- [Respiratory Syncytial Virus Vaccine: CDC 19–59 vs 60+ Decision](https://getpulse.care/blog/respiratory-syncytial-virus-vaccine-cdc-1959-vs-60-decision.php)

### Latest

- [COVID-19 Vaccine in Pregnancy: How to Verify Current Guidance](https://getpulse.care/blog/covid-19-vaccine-in-pregnancy-how-to-verify-current-guidance.php)
- [RSV Shot in Pregnancy: Give at 32–36 Weeks or Hold Until September?](https://getpulse.care/blog/rsv-shot-in-pregnancy-give-at-3236-weeks-or-hold-until-september.php)
- [EHR prompts and standing orders for COVID-19 vaccines in pregnancy: a...](https://getpulse.care/blog/ehr-prompts-and-standing-orders-for-covid-19-vaccines-in-pregnancy-a-verify-first-guide.php)

Canonical: https://getpulse.care/blog/2026-cms-interoperability-rule-audit-before-building-a-fhir-claims-api.php
Markdown: https://getpulse.care/blog/2026-cms-interoperability-rule-audit-before-building-a-fhir-claims-api.php/index.md