What Is the eKAS? The YAKAP Konsulta Availment Slip, Explained

The eKAS (Electronic Konsulta Availment Slip) is the printed record PhilHealth requires a YAKAP clinic to generate after every single patient encounter — it lists which of the 13 covered lab/diagnostic services were performed, gets signed by the beneficiary, and doubles as the paper trail behind that encounter's claim. If a service isn't on the eKAS, it effectively didn't happen as far as PhilHealth's records are concerned.

What the eKAS Actually Is

The eKAS is not optional documentation — it's a compliance requirement. Under PhilHealth Circular No. 2024-0013, providers must "generate and print the Electronic Konsulta Availment Slip (EKAS) or its equivalent immediately after each patient encounter," alongside the ePresS for any prescribed medicines. It functions as three things at once:

A services checklist — proof of which diagnostics/labs were actually performed at that visit
A beneficiary receipt — something the patient signs and takes a copy of
A feedback instrument — a short satisfaction survey PhilHealth collects in aggregate

It is generated per encounter, not per patient or per year — a beneficiary who visits three times in a quarter should have three eKAS slips.

When the eKAS Is Generated

The eKAS is printed immediately after each patient encounter — meaning after the consultation is complete and any diagnostics for that visit are known, not at registration and not days later. This applies across the availment sequence: a First Patient Encounter, a regular consultation, and a follow-up visit each produce their own eKAS. Note that the FPE itself is explicitly not a medical consultation — it's the annual health-data-gathering step described in PhilHealth Circular No. 2025-0017 — but it still triggers an eKAS because it's a patient encounter. For the full mechanics of that visit, see The First Patient Encounter (FPE): Step-by-Step Guide for YAKAP Clinics.

What's on the eKAS: The Services Grid

The official Annex H template (PC 2024-0013 Annex H) has two parts: a facility/patient header and a services grid.

Facility and patient header fields:

HCI Name and HCI Accreditation No.
Case No. and Transaction No.
Patient PIN, name, age, and contact number
Membership Category and Membership Type (member/dependent)
Authorization Transaction Code (ATC)

The services grid lists 13 diagnostics, each with three columns — Performed (check/X), Date Performed, and Performed by:

CBC with platelet count
Lipid profile
FBS (fasting blood sugar)
OGTT (oral glucose tolerance test)
HbA1c
Creatinine
Chest X-ray
Sputum microscopy
ECG
Urinalysis
Pap smear
Fecalysis
Fecal occult blood test

Only the diagnostics actually done at that encounter get checked — an eKAS with nothing marked is still valid for a visit where no labs were ordered. This 13-item grid is a subset of the broader 15-item Konsulta/YAKAP benefit table (which also includes mammogram and additional ultrasound categories); the eKAS grid specifically reflects what PC 2024-0013's Annex H template enumerates.

Who Signs It and Who Keeps It

Under PC 2024-0013, the beneficiary must provide feedback and sign the eKAS after every transaction — a thumbmark if they're unable to write, or a parent/guardian's signature for a minor. The patient-facing section of the slip asks two things: whether the services/medicines were actually received (Yes/No), and a satisfaction rating (Happy/Neutral/Sad).

The slip then splits in two directions:

The reply portion (the signed feedback + anonymized satisfaction data) goes back to PhilHealth — submitted on or before the 10th working day of the month following the applicable quarter.
The rest of the slip is given to the beneficiary as their own record of the visit.

Practically, this means your clinic needs a workflow that both prints a beneficiary copy on the spot and retains/batches the reply data for quarterly submission — not just a one-off printout.

How the eKAS Connects to Consultations and Claims

The eKAS isn't a standalone form — it's downstream of the same encounter data that builds your PhilHealth claim. A consultation's SOAP data, its diagnostics, and its eKAS should all trace back to one transaction number, because:

The services grid is only credible if it matches what was actually encoded for that consultation's diagnostic results.
PhilHealth's own data system — historically eKonsulta, described in PC 2024-0013 as the interim reporting system "for encoding the client's encounter data/consultation records to include diagnosis, diagnostic tests done with corresponding results and prescribed/dispensed medicines" — expects the same facts the eKAS shows on paper.
Lab utilization isn't just documentation. It's one of four weighted indicators (worth 30%) in the year-end performance factor that determines your clinic's second-tranche capitation payment — so an eKAS that under-records what was actually performed can quietly cost you at settlement.

The eKAS therefore sits next to two other slips clinics need to keep straight: the ePresS, which documents prescribed medicines with the physician's PRC/PTR/S2 details (see ePresS: How Electronic Prescriptions Work Under YAKAP), and the YAKAP Empanelment Slip (YES), which documents the Mutual Care Agreement at FPE rather than a service (see The YAKAP Empanelment Slip (YES): When You Need It and How It Works). All three, plus the PCU liveness check that should precede every encounter (see The PhilHealth PCU Liveness Check: What It Is and How to Do It Right), make up the paper trail PhilHealth expects per visit. How that trail rolls up into actual capitation is covered in How YAKAP Clinics Get Paid.

Common eKAS Mistakes

Generating one eKAS for multiple visits instead of a fresh slip per encounter.
Marking a service performed on the eKAS that wasn't actually encoded in the consultation's diagnostic data — the two records need to match.
Skipping the beneficiary signature or feedback rating, which is a stated requirement of PC 2024-0013.
Losing track of the quarterly reply-slip deadline (10th working day of the month after the quarter) because copies were handed out but never batched for submission.
Treating the eKAS as separate paperwork rather than a direct reflection of the SOAP/diagnostic data already encoded — duplicate entry invites mismatches.

How RecordKo Handles the eKAS

RecordKo generates the eKAS directly from the same consultation record used to build the PhilHealth claim — no separate re-encoding. The services grid auto-populates from whatever diagnostics were actually recorded on that consultation, the transaction number matches the encrypted XML claim, and the PDF renders instantly in the browser for printing and signing at the point of care. Because it's built for YAKAP end-to-end, the same consultation also drives the ePresS, feeds the performance-factor lab indicator on your capitation dashboard, and — for clinics migrating off eKonsulta before its shutdown — imports prior XML batches so history isn't lost.

Book a demo ↗