1. Provider
Who is billing? Who rendered the service? Where did service happen if a facility location is needed?
Lesson 0002
Map EMR Data to an 837P
The practical product skill: look at an encounter and decide whether the billing workflow has enough data to create a professional claim.
Your Tangible Win
After this lesson, you should be able to name the five claim-readiness buckets an EMR workflow must collect before an 837P can go out: provider, patient, payer, diagnosis, and service-line data.
Primary source to read after the lesson: CMS MLN Essential Claim Fields.
The Core Idea
An 837P is the professional claim transaction, but your product should not start by thinking in X12 segments. First ask: does the EMR have the data needed to tell the payer who billed, who received care, which coverage applies, why care was provided, and what was done?
CMS organizes successful CMS-1500 and 837P submission data into health care professional or supplier information, patient information, and payer information (CMS MLN Claim Completion). CMS then treats billing information as its own layer: diagnosis, procedure, service dates, charges, days or units, and amount paid (CMS MLN Billing Information).
The Five Buckets
2. Patient
Who received care? Can the payer match name, date of birth, sex, address, and relationship to subscriber?
3. Payer
Which payer and plan should receive the claim? Which subscriber/member ID and coverage should be used?
4. Diagnosis
Why was care provided? CMS says diagnosis codes should be reported to the highest level of specificity for the date of service (CMS MLN Essential Claim Fields).
5. Service Line
What was done, where, when, how many, and for how much? CMS lists dates of service, place of service, procedures, charges, and days/units as billing information (CMS MLN Billing Information).
Optional Details
Some workflows need extra data, like outside lab information, NOC descriptions, attachments, prior authorization, or coordination of benefits.
Mini Case
A therapist completes a visit note. The EMR knows the patient, insurance card, clinician, date of service, CPT code, ICD-10 diagnosis, place of service, and charge. The clearinghouse still rejects the claim because the rendering provider NPI is missing.
Product diagnosis: this is not a payer denial. It is a claim-readiness failure in the Provider bucket. The product should route it to provider setup or claim correction, not denial management.
Design Rule
Build your claim workflow around missing-data workqueues before submission. Most claim screens should answer three questions:
| Question | Example Signal | Likely Bucket |
|---|---|---|
| Can the payer identify every party? | Missing NPI, subscriber ID, or patient DOB. | Provider, Patient, Payer |
| Can the payer understand medical necessity? | No diagnosis or diagnosis pointer. | Diagnosis |
| Can the payer price the service line? | Missing POS, units, charge, modifier, or CPT/HCPCS code. | Service |
Retrieval Practice
For each missing item, type the one bucket it belongs to: provider, patient, payer, diagnosis, or service.
What to Ask Me Next
Ask follow-up questions whenever a bucket feels fuzzy. Good next questions: "What is the difference between billing and rendering provider?", "What is a diagnosis pointer?", or "How should I model service lines in a database?"
For review, keep the 837P data checklist nearby.