How YAKAP Claims Actually Work: XML, Validation, and Transmittals

A YAKAP claim is an encrypted XML file — one per consultation — that your EMR first sends to PhilHealth for validation, then submits for processing, receiving a unique transmittal number in return. PhilHealth rejects a second upload of the same consultation, which is why understanding this encode → validate → submit → transmittal pipeline matters for getting paid.

If your clinic is still on eKonsulta, PhilHealth Advisory No. 2026-0038 is blunt about the stakes: clinics must upload YAKAP XML files after every transaction, and "only complete and accurate claims are validated and processed." Here is what actually happens to that file after your staff clicks submit.

The Claim Lifecycle in Four Steps

Every YAKAP claim moves through the same four stages, whether it comes from eKonsulta or a certified EMR:

Encode — the consultation (FPE data, SOAP notes, diagnostics, prescriptions) is captured in the EMR and packaged into a structured XML file, encrypted before it leaves the clinic.
Validate — the file is checked against PhilHealth's business rules. Errors come back for correction; nothing is filed yet.
Submit — a clean file is formally lodged with PhilHealth for processing.
Transmittal — PhilHealth issues a transmittal number, the receipt proving that specific consultation was filed.

Each stage exists for a reason, and skipping or misunderstanding any of them is where held claims and payment gaps usually start.

Step 1: The XML Claim File

The claim itself is not a form you fill out on a PhilHealth website — it is an XML document your EMR generates from the consultation record. XML has been the backbone of this pipeline since the Konsulta era: PhilHealth Advisory No. 2023-0003 describes providers uploading Konsulta XML files through the HCI Portal and downloading the Konsulta Registration Masterlist from the same portal.

A complete claim file typically carries:

Patient identity and eligibility data, anchored to a successful PCU liveness check
The clinical encounter — subjective/objective findings, assessment, and plan
Diagnostics ordered and their results
Medicines prescribed (the same data that feeds the ePresS)
Facility and physician identifiers

The file is encrypted with a cipher key PhilHealth issues to the facility's EMR. This is also why eKonsulta migration is a hard cutover: when PhilHealth issues a cipher key to your new certified EMR provider, the eKonsulta key is automatically deactivated, so export your legacy data first. Our eKonsulta migration guide walks through that sequence.

Step 2: Validation — the validateReport Concept

Validation is a dry run: the claim is checked against PhilHealth's rules before anything is officially filed. Conceptually this is the validateReport call — the EMR asks PhilHealth's web service, "would this claim be accepted?" and gets back either a pass or a list of specific errors.

PhilHealth's Konsulta/YAKAP web service exposes named service methods that EMRs call — Advisory 2023-0003 mentions isATCValid for validating Authorization Transaction Codes, and documents real validation failures such as "No dependent record found" and pediatric Z-score checks for children aged 0–60 months. Files that fail must be corrected and re-uploaded.

The practical lesson: validation errors are normal and fixable. A good EMR surfaces them in plain language at encoding time so your staff corrects a birthdate or a missing dependent record in seconds — instead of discovering a returned claim weeks later.

Step 3: Submission and the Transmittal Number

Once a claim validates cleanly, it is submitted — the submitReport step — and PhilHealth responds with a transmittal number. That number is your proof of filing: each consultation gets exactly one, and it is what you quote when following up on a claim or reconciling your Statement of Accounts Payable.

Transmittals are not bureaucratic decoration. They tie directly to money:

First tranche. PhilHealth Advisory No. 2026-0029 makes SAP 1 payment conditional on a successful PCU liveness check with a transaction number and a conducted FPE with uploaded FPE XML data — no XML on file, no first tranche.
Second tranche. Capitation is paid in two tranches — 40% on completed FPEs, 60% the following year tied to encoded consultations, lab results and prescriptions. Every consultation without a transmittal is performance-tranche revenue left unclaimed. See how YAKAP clinics get paid for the full P1,700-per-beneficiary math.
Audit trail. Under PhilHealth Circular No. 2025-0017, PCU logs serve as the basis for capitation payment validation and fraud monitoring — your transmittals and PCU transaction numbers must line up.

Why Re-Uploads Are Rejected: One File Per Consultation

PhilHealth enforces strict deduplication: one claim file per consultation. Once a consultation has a transmittal number, uploading another XML for the same encounter is rejected. This protects the fund from double-billing, but it has a sharp operational edge — you cannot "fix" a successfully submitted claim by submitting it again.

That makes the order of operations critical:

Get it right before submitReport. Corrections are cheap at the validation stage and painful after transmittal.
Post-submission updates flow differently. Later events — a lab result encoded onto the ordering consultation, medicines dispensed against a prescription — must be attached to the existing consultation record so the claim data is rebuilt correctly, not filed as a duplicate claim.
Track submission status per consultation. Your EMR should show, at a glance, which encounters are drafted, validated, submitted, and transmitted — so nobody re-uploads a filed claim or forgets an unfiled one.

The Daily Routine PhilHealth Expects

For clinics still transitioning, PhilHealth Advisory No. 2025-0077 spells out the interim discipline: encode all data after each patient encounter, download the XML file, and submit it via the HCI Portal or your LHIO — daily, not at month-end. The same advisory requires PCU liveness checks after every encounter and the YAKAP Empanelment Slip after the first patient encounter.

A certified EMR collapses that manual loop into the consultation workflow itself — which is precisely why PhilHealth is requiring one before the December 2026 deadline, and why it certifies EMRs through a formal validation process.

How RecordKo Handles the Claim Pipeline

RecordKo is built for YAKAP end-to-end: PCU results and transaction numbers are captured at registration and before every consultation, eKAS and ePresS PDFs generate straight from the encounter, and each consultation produces exactly one encrypted XML claim — validated against PhilHealth's rules before submission, with the transmittal number stored on the record. Lab results and medicine dispensing are encoded onto the original consultation so the claim data rebuilds correctly instead of triggering a duplicate. Clinics migrating from eKonsulta can import their existing XML files and masterlist, designed for the certified-EMR era.

Book a demo ↗