# EMR, EHR and eMAR: what the terms actually mean

_EMR, EHR, eMAR, PMS, HIE, CRM and the superbill, defined by what each one is responsible for rather than by vendor marketing. Includes why the Epic versus Cerner comparison rarely applies to the person asking, and how to tell which system a requirement belongs in._

By Nguyen Manh Thang, Chief Executive Officer, AgileTech Vietnam. Published 2026-08-17, updated 2026-08-27. 16 min read.

Source: https://agiletech.vn/blog/emr-ehr-emar-explained/

## AI overview

An EMR is one organization's clinical record of a patient. An EHR is a record designed to be shared across organizations, so it carries the same clinical content plus the identity, consent and exchange machinery that sharing requires. An eMAR is much narrower: it records the act of administering a dose of medication, at the bedside, at the moment it happens, and it is the only one of the three that primarily documents nursing rather than clinician work. The reason the words get used interchangeably is that vendors sell EMRs as EHRs and the distinction is a spectrum rather than a switch. The practical test is not what the product is called but whether a clinician outside your organization can read the record, and whether a nurse can chart a dose against it without leaving the room.

Healthcare software has a vocabulary problem that costs real money. The same product gets called an EMR on one page of a vendor site and an EHR on the next. A hospital asks for an eMAR and receives a medication list. A clinic buys an EMR, discovers it cannot bill, and buys a practice management system six months later at a price nobody planned for. None of that is caused by bad software. It is caused by words that sound like synonyms and are not.

This guide defines each term by what it is responsible for. Not by feature list, because feature lists are written by marketing departments and converge, and not by vendor, because the same vendor sells different things under the same name in different markets. Responsibility is the only definition that survives contact with a procurement process: if you can say which system owns a piece of data and which system is merely allowed to read it, you can write a requirement that a developer can build and a buyer can verify.

The order here is deliberate. The clinical record first, because everything else references it. Then the systems that surround it, then the two terms that cause the most confusion because they are not clinical at all. If you are choosing a partner rather than a product, our [guide to evaluating a software partner](https://agiletech.vn/blog/software-partner-evaluation/) covers that separately, and our [healthcare software work](https://agiletech.vn/industries/healthcare-software-development/) shows what these systems look like once built.

## Key takeaways

- EMR versus EHR is a question about boundaries, not features. If the record is designed to leave the organization, it needs identity matching, consent and exchange standards, and those three are most of the extra cost.
- An eMAR is not a small EHR. It documents administration at the bedside on a schedule, is used standing up, and its failure mode is a missed or double dose rather than an incomplete note.
- A practice management system handles scheduling, eligibility, claims and revenue. Buyers routinely specify it as part of the EMR and are then surprised it is licensed separately.
- Healthcare CRM is not clinical. It handles referral sources, outreach, campaigns and patient acquisition, and putting clinical data in it is how organizations create a compliance problem they did not budget for.
- A superbill is a summary document, not a claim. It exists so a patient can seek reimbursement themselves after paying out of pocket, which is why it lives in the billing system rather than the clinical one.
- The Epic versus Cerner comparison is real but rarely relevant to anyone searching for it. Both are enterprise platforms sold to hospital networks with multi-year implementations, and neither is a candidate for a clinic or a startup.
- Before writing a requirement, decide which system owns the data. Most healthcare software failures we see are not bugs but a field that three systems each believe they own.

## EMR and EHR: the difference is the boundary, not the feature list

An EMR, an electronic medical record, is the clinical record of a patient as held by one organization. It contains what that organization knows: encounters, diagnoses, orders, results, notes, medications, allergies. It is the digital version of the paper chart that used to live in that building, and its scope is that building.

An EHR, an electronic health record, is a record designed to follow the patient across organizations. The clinical content is largely the same. What is added is everything sharing requires: a way to be confident that the John Nguyen arriving at the hospital is the same John Nguyen the clinic has a record for, a way to represent what the patient has consented to share and with whom, and a way to transmit the record in a format another system can read without a human retyping it.

That is why the distinction matters commercially rather than semantically. The clinical screens are perhaps a quarter of the difference in cost. Identity matching, consent modeling and standards-based exchange are the rest, and they are the parts a buyer cannot see in a demo. A vendor demonstrating an attractive charting interface has demonstrated the cheap half.

In practice almost every product sits somewhere on a spectrum between the two, and the honest question to ask a vendor is not "is this an EHR" but "which organizations can read this record today, by what mechanism, and what did each of those connections cost to build". The answer is specific and checkable. The label is not.

**What changes when a record has to leave the building**

| Concern | Single organization (EMR) | Shared across organizations (EHR) |
| --- | --- | --- |
| Patient identity | One internal identifier, issued by you and unique by construction | Probabilistic matching against records you did not create, with a defined review process for near matches |
| Consent | Often implicit in the treatment relationship | Explicit, scoped, revocable, and enforced at the point of every disclosure |
| Data format | Whatever your schema says, since you own both ends | A published standard, because the other end is not yours to change |
| Duplicate records | A data quality annoyance to be cleaned up | A clinical safety issue, since a merged or split record can hide an allergy |
| Audit trail | Who in your organization accessed the record | Who accessed it, from which organization, under which consent, and why |
| Failure mode | A clinician cannot find a note | A clinician sees a record that belongs to someone else, or fails to see one that exists |

_The clinical content is the part that stays the same. Everything in the right column is a consequence of the record being shared, and together it is usually the larger share of the build._

> **The word on the contract does not create the capability**
>
> Buyers regularly sign for an "EHR" and discover during implementation that exchange with the two organizations they care about was never in scope, because the product supports a standard and supporting a standard is not the same as having a working connection to a named counterparty.
>
> Write the counterparties into the requirement. Not "must support HL7 FHIR" but "must exchange discharge summaries with these two named systems, demonstrated in a test environment before final acceptance". The first is a checkbox. The second is a deliverable.

_Figure: Where the cost of an EHR actually sits. Illustrative weighting, not measured cost. "Clinical screens" covers the charting interface and data model; "identity matching" is reconciling patients across organizations; "consent" is scoped, revocable disclosure control; "exchange mapping" is standards work per counterparty. The point is the proportion: the screens a vendor demonstrates are the smallest share of the difference between an internal record and a shareable one._

## eMAR: the one that documents an action rather than a decision

The eMAR, the electronic medication administration record, is the most misunderstood of the three because it looks like a subset of the EHR and behaves nothing like one. Its subject is not the patient's history but a single repeated event: a nurse gives a dose of a medication to a patient at a time, or does not give it and records why.

Three properties follow from that, and each one changes the software. It is scheduled, so the interface is organized around what is due in the next hour rather than around a patient's chart. It is used standing up, often on a cart or a handheld, in a room, sometimes in poor light, frequently interrupted. And its errors are immediate and physical: a missed dose, a double dose, the wrong patient. An EHR error produces an incomplete record. An eMAR error produces a clinical incident.

This is why paper medication charts survived long after clinical notes went digital, and why the systems that replaced them are judged on a scale nothing else in healthcare software is judged on. The scanning workflow, patient wristband then medication barcode, is not a feature. It is the control that makes the whole thing safer than paper, and an eMAR without it has automated the record while leaving the risk exactly where it was.

The design consequence is worth stating plainly, because it is the opposite of the instinct: an eMAR should present less information than a chart, not more. Everything on the screen that is not the current administration is a distraction competing with a task that has to be right every time.

**Designing the administration path**

**Do**
- **Lead with what is due now**: The default view is the upcoming administration window, not a patient search. The nurse already knows who the patient is; the system should know what is due.
- **Scan both wristband and medication**: Two scans, matched against the order, before the dose is recorded. This is the control that makes the system safer than paper rather than merely faster.
- **Make refusal and omission first-class**: A dose not given is clinical information. If recording "patient refused" is harder than recording "given", the record will drift toward the easier option.
- **Work offline for the round**: A dead spot in a corridor cannot be allowed to stop a medication round. Cache the round, sync on reconnect, and make the sync state visible.
- **Show the time it was given**: Not the time it was recorded. Those differ, sometimes by an hour, and the clinical record needs the former.

**Do not**
- **Rebuild the chart on the device**: A full clinical record on a handheld used at the bedside means scrolling past information nobody needs to reach the one field that matters.
- **Allow a free-text time by default**: If the time is typed, it will be typed wrong, and it will be typed as a round number. Capture it, allow it to be corrected with a reason.
- **Treat scanning as optional configuration**: An override that is available on every dose becomes the normal path within a month. Overrides need a reason and a report somebody reads.
- **Silently queue writes with no indicator**: A nurse who cannot tell whether the last three doses were saved will either re-record them or assume they are fine. Both are bad.
- **Log an edit as an edit**: Administration records are append-only. A correction is a new entry that references the original, because an investigator needs to see what was believed at the time.

_Every item here is about the same thing: this screen is used by a person who is standing up, holding something, and about to be interrupted._

**The terms that appear on an eMAR requirement and get conflated**

- **Medication list**: What the patient is currently prescribed. A state, held in the clinical record.
- **Medication order**: An instruction from a prescriber: this drug, this dose, this route, this frequency, starting now, until this condition. The authority for an administration.
- **Administration record (the MAR)**: The log of doses actually given or deliberately not given, against those orders. An event stream, not a state.
- **Reconciliation**: The process of comparing what a patient was taking before an encounter with what they are taking now, at admission, transfer and discharge. Where most medication errors are found.
- **Barcode medication administration**: The scan-both workflow described above. Sometimes sold as a separate module, which is a licensing decision rather than an architectural one.
- **High alert medication**: A drug whose administration error carries disproportionate harm, and which therefore warrants a second check in the workflow rather than in a policy document.

_Figure: A medication round, showing where the two scans sit. The nurse lane is the only one that is time critical. Everything in the other lanes can wait a second; nothing in that lane can wait for a page load._

## The systems around the record, and which one owns what

Once the clinical record is placed, the rest of the landscape becomes navigable. Most of the confusion in healthcare procurement is not about what these systems do individually but about which one owns a given piece of data, because ownership is what decides where a requirement goes and who is responsible when the value is wrong.

There is exactly one rule worth memorizing: for every field, one system writes it and every other system reads a copy. When two systems both believe they own the appointment time, or the patient's address, or the insurance policy number, you do not have an integration problem to be solved once. You have a permanent reconciliation problem, and somebody will be manually fixing it every week for as long as the software lives.

The architecture below is the arrangement that usually holds. It is worth noting that a small clinic may run four of these boxes inside one purchased product, and a hospital network may run each of them as a separate system with a dedicated team. The boxes describe responsibilities, not purchase orders.

**Who owns which field, stated the way a requirement should be written**

**Clinical record (EMR or EHR)**
- Owns: Encounters, diagnoses, orders, results, clinical notes, allergies, problem list, the medication order
- Reads: Demographics, coverage, appointment times
- Common mistake: Letting the billing system hold a diagnosis that the clinical record does not have, which is how a claim ends up describing care that is not documented

**Practice management system**
- Owns: Schedule, provider availability, eligibility checks, claims, remittances, patient balances, collections
- Reads: Diagnoses and procedures, from the clinical record, for coding
- Common mistake: Being specified as part of the EMR. It is frequently licensed separately, and discovering this after signing is a budget event

**eMAR**
- Owns: The administration event: dose, time given, administering clinician, reason for omission
- Reads: The medication order, the patient identity, the schedule
- Common mistake: Allowing it to hold its own copy of the order, which drifts from the prescriber's change and produces a dose given against an instruction that was withdrawn

**Healthcare CRM**
- Owns: Referral sources, outreach campaigns, inquiries, marketing consent, patient acquisition funnel
- Reads: Nothing clinical, ideally. Appointment existence at most, never diagnosis
- Common mistake: Storing a condition in the CRM to segment a campaign. This turns a marketing tool into a regulated system overnight, along with everyone who has a login to it

**Health information exchange**
- Owns: The mapping between identities across organizations, and the record of what was disclosed to whom under which consent
- Reads: Whatever participants publish
- Common mistake: Treating it as a database rather than a routing and consent layer, and then asking why it cannot answer a clinical query

_The owning system writes the value. Everything else holds a copy that may be stale, and any screen displaying a copy should be able to say how stale._

**Which system does this requirement belong in?**

_Somebody has written a requirement and two systems could plausibly host it. Which one gets it?_
- **If It records something a clinician decided or observed**, then The clinical record owns it. Clinical decisions and observations are the clinical record's reason to exist, and its audit trail is built for them. Putting them elsewhere means the audit trail no longer describes the care.
- **If It records something that happened at a scheduled moment and had to be right at that moment**, then The eMAR or an equivalent event log owns it. Event streams and state records have different shapes. Forcing an administration event into a state field loses the one thing it exists to capture, which is exactly when it happened and by whom.
- **If It affects money, coverage or the calendar**, then The practice management system owns it. These fields have their own regulatory and reconciliation rules, and duplicating them into a clinical system means two sets of numbers that must be explained to a finance team.
- **If It exists to reach a person who is not currently a patient in an episode of care**, then The CRM owns it, and it must stay non-clinical. The moment clinical data enters the marketing system, the marketing system inherits the full compliance obligation and every user of it does too. That is a scope change nobody asked for.

_Run a disputed requirement through this before it reaches a developer. It resolves most ownership arguments in one pass._

_Figure: Who owns what, drawn as tiers. Each box writes the data it owns and reads everything above or below by reference. The rule the whole diagram encodes: exactly one writer per field._

## Healthcare CRM: useful, and not a clinical system

The phrase "CRM in healthcare" produces two entirely different conversations depending on who is in the room, and both are legitimate. A marketing director means the system that tracks where inquiries come from, which referral relationships are productive, and whether an outreach campaign worked. A clinician hears "customer" attached to "patient" and reasonably objects.

The useful version is narrow and unglamorous. It is the system that knows a physician in the next district refers four patients a month and has not referred any since March, or that a screening campaign generated bookings from one channel and nothing from three others. That information does not exist in the clinical record, because the clinical record starts when someone becomes a patient and this is about everything before that.

The failure is predictable and worth naming precisely, because it is committed by well-intentioned people. Somebody wants to send a reminder to patients with a specific condition, so the condition is copied into the CRM as a segment. That single act extends the regulated boundary to cover the CRM, its vendor, its subprocessors and every marketing contractor with a login, none of whom were assessed for it. The compliance cost is real, and it was incurred to avoid asking the clinical system for a list.

The correct pattern is to keep the segmentation in the clinical system and let the CRM receive only an anonymous instruction: send this message to these contact identifiers. The CRM never learns why. This is slightly more work to build and enormously less work to defend.

**Before a healthcare CRM goes live**

- [ ] **Write down what clinical data the CRM may hold, and make it "none"**: If the answer is not none, the exception needs a named owner, a documented assessment and a review date, not a shrug.
- [ ] **Confirm marketing consent is separate from treatment consent**: Consenting to care is not consenting to messages. Combining them in one flag makes both unusable as evidence.
- [ ] **Decide who owns the contact details**: If both the CRM and the clinical record accept address changes, they will disagree within weeks and correspondence will go to the wrong place.
- [ ] **Check what the vendor's subprocessors receive**: An email delivery service, an analytics tool and a support platform may each see contents. That list is part of your compliance boundary whether or not you asked.
- [ ] **Define suppression before the first campaign**: Deceased patients, patients who withdrew consent, and patients in an active complaint should never receive a marketing message. Retrofitting suppression after the first mistake is the worst time to build it.
- [ ] **Log every export**: Marketing lists get downloaded to spreadsheets. If exports are not logged, the compliance boundary is wherever somebody's laptop is.

_Each of these is a question somebody will ask after an incident. Answering them beforehand is considerably cheaper._

## The superbill, and why it is not a claim

A superbill is an itemized summary of services provided at a visit, given to the patient. That is the whole definition, and the reason it needs explaining is that it looks like an invoice and functions like evidence.

It exists for the out-of-network situation. The patient pays the provider directly, then seeks reimbursement from their insurer themselves. To do that they need a document their insurer will accept, which means it has to carry the same structured information a claim would: who provided the care and under what identifiers, when, what was done in coded form, why it was done in coded form, and what was charged. A receipt saying "consultation, one hundred units" is not sufficient, because the insurer cannot adjudicate a description.

The distinction from a claim is worth being exact about, since it decides who does the work and who carries the risk. A claim is submitted by the provider to the payer, and the provider chases it. A superbill is handed to the patient, and the patient chases it. The provider's obligation ends at producing an accurate document. Everything after that is the patient's administrative burden, which is precisely why the document has to be right the first time: a missing identifier means a rejection the patient discovers weeks later and cannot fix without coming back.

For a software team the implication is small and specific. This is a document generator in the billing system, with required fields validated before it can be produced. It is not a clinical artifact, and it should never be assembled by hand from a note.

**Superbill, invoice and claim, side by side**

|  | Invoice | Superbill | Insurance claim |
| --- | --- | --- | --- |
| Given to | The patient | The patient | The payer |
| Purpose | Request payment | Support the patient's own reimbursement request | Request payment from the payer |
| Who pursues the money | The provider, from the patient | The patient, from their insurer | The provider, from the payer |
| Coded diagnoses and procedures | Not required | Required, or the insurer cannot adjudicate it | Required |
| Provider identifiers | Business details are usually enough | Full practitioner and facility identifiers | Full identifiers, plus payer-specific fields |
| Where it is produced | Billing system | Billing system, from clinical codes | Billing system, via a clearing house in most markets |
| Failure mode | Late payment | Patient reimbursement denied for a missing field | Rejection, rework, resubmission |

_Three documents that describe the same visit. The differences are who receives them, who pursues payment, and how much structure is required._

> **This article names no prices and no reimbursement rates**
>
> Charges, reimbursement percentages and payer rules vary by country, by payer and by contract, and no sourced figures for them exist in our handover. Printing a plausible number would make this page feel more concrete and would be an invention (AGENTS.md rule 2).
>
> What is stated here instead is structural: which fields a document has to carry and why an insurer rejects it without them. That is verifiable, portable across markets, and actually what a software team needs in order to build the thing.

## Epic, Cerner, and the comparison that usually does not apply

One of the five queries this article consolidates is a straight vendor comparison, and it deserves a straight answer rather than a dodge. Both are enterprise clinical platforms sold to hospitals and hospital networks. Both involve implementations measured in years, dedicated internal teams, and a total cost dominated by configuration, data migration and clinical process change rather than by license fees.

The reason the comparison rarely helps the person searching for it is a mismatch of scale. A clinic, a specialist practice, a digital health startup or a care provider in a market where neither vendor operates is not choosing between them, and the differences that matter to a large hospital network, module depth in specific specialties, the shape of the vendor relationship, the size of the implementation partner ecosystem, are not differences that transfer to a smaller decision.

What does transfer is the framework. Every clinical platform decision, at any scale, is a trade between how much the system does out of the box and how much of your own clinical process you can keep. Buying deep functionality means adopting the workflow it assumes. Building means you keep your workflow and own everything it touches, forever. Most organizations sit in the middle, and the useful question is not which vendor is better but where on that axis this particular organization should be.

We are a development partner, so we have an obvious interest in the build end of that axis, and the honest position is that most organizations should buy the clinical record and build around the edges. The place where custom development genuinely earns its cost is the workflow your organization does differently from everyone else, which is exactly the part no vendor has built. Our technology partner evaluation guide covers how to test that claim on any vendor, including us.

> We spent eleven months on a system nobody argued about in the demo. The argument started when the first department realized it would have to change how it worked, and that argument is the project. The software was the easy part.
>
> Anonymized, from an implementation review, Hospital operations lead, paraphrased with permission

**Where a clinical platform decision actually sits**

|  | Fits unusual workflow | Time to first use | Ongoing cost you control | Exchange with other organizations | Suits a small provider |
| --- | --- | --- | --- | --- | --- |
| Enterprise platform (Epic, Cerner and peers) (Sold to networks, implemented over years) | no | no | no | yes | no |
| Mid-market clinical product (Regional vendors, per-seat licensing) | partial | yes | partial | partial | yes |
| Buy the record, build the edges (The arrangement we see succeed most often) | yes | partial | partial | partial | yes |
| Fully custom clinical system (Justified when the workflow is the product) | yes | no | yes | no | partial |

_Rows are the realistic options, columns are what a buyer is trading. "Partial" means it depends on how far the requirement sits from what the product assumes._

_Figure: Positioning the four realistic options. Illustrative positions to show the shape of the trade, not a vendor evaluation. Horizontal is how much of your own workflow you keep; vertical is how much you must operate yourself._

## How to use these definitions in an actual requirement

Definitions are only worth having if they change what gets written down. The practical value of everything above is that it lets a requirement name a system, name an owner, and name a verification, which is the difference between a specification and a wish.

The pattern that works: for each requirement, state which system owns the data, which systems read it, what happens when the owning system is unavailable, and how somebody will confirm it works before acceptance. Four clauses. Most healthcare requirements we are handed have the first two implicitly and neither of the last two, and the last two are where the projects fail.

It is also worth resisting the pull toward the largest possible scope. "We will need an EHR eventually" turns a clinic project into an interoperability program, and interoperability without a named counterparty is expense without benefit. Build the EMR, keep the record model clean enough that identity and consent can be added, and add them when there is a second organization that actually wants to read it.

- **Name the owner before the estimate.** Every field in dispute gets exactly one owning system, agreed on paper, before anyone prices the work. This single step removes most of the rework we are later asked to rescue.
- **Integrate against counterparties, not standards.** A requirement that names a standard is a checkbox. A requirement that names the two systems you must exchange discharge summaries with, demonstrated in a test environment, is a deliverable.
- **Keep clinical data out of the CRM.** Write it down as a rule with a named owner. Once a diagnosis lands in a sales tool, the compliance boundary of that tool changes and nobody notices until an audit.
- **The eMAR is an event log, not a chart.** Scheduled view, dual scanning, explicit omission reasons and a round that survives losing connectivity. A medication list on a tablet is a different product with the same screens.
- **Generate the superbill, never assemble it.** It belongs in the billing system as a validated document built from coded clinical data. Hand assembly is where the denials come from.
- **Defer the exchange machinery until a counterparty exists.** Identity matching and consent scoping are real projects. Build the EMR, keep the record model clean enough that they can be added, and add them when a second organization actually wants to read the record.

**A sequence that avoids the usual rework**

| Phase | Span | Focus | Exit |
| --- | --- | --- | --- |
| Ownership map | Weeks 1 to 2 | List every field in dispute and assign exactly one owning system to each. Resolve disagreements now, on paper. | A signed map with no field owned twice, and no field owned by nobody. |
| Clinical core | Weeks 3 to 12 | Encounters, orders, results, notes, allergies. Append-only where the record is clinical or regulatory. | A clinician can complete a real encounter end to end without a workaround. |
| Administration path | Weeks 10 to 16 | The eMAR: scheduled view, dual scanning, omission reasons, offline round with visible sync state. | A full medication round completed on the target hardware, including a deliberate loss of connectivity. |
| Revenue path | Weeks 14 to 22 | Scheduling, eligibility, coding from clinical data, claims, and the superbill as a validated document. | A visit flows from booking to a produced document with no manual re-entry of clinical codes. |
| Exchange, if warranted | After a counterparty exists | Identity matching with a human review path, consent scoping, and a standards-based connection to one named partner. | A record successfully read by that partner in a test environment, with the disclosure logged. |

_Spans are illustrative and scale with the size of the organization. The ordering is the part that matters: each phase produces the thing the next one depends on._

_Figure: What changes when ownership is decided before the build. These are the recurring differences between projects that mapped ownership first and projects that discovered it during integration._

## Frequently asked questions

**Is an EHR just an EMR with more features?**

No, and the difference is not on the feature list. An EHR is designed for the record to be read outside the organization that created it, which requires identity matching against records you did not create, explicit and revocable consent, and standards-based exchange. Those three are usually the larger share of the build. A product with beautiful clinical screens and no working connection to another organization is an EMR regardless of what it is called.

**Can our EMR act as the eMAR?**

Sometimes, but check three things before assuming it. Does it present a scheduled view of what is due rather than a patient chart? Does it support scanning both the patient wristband and the medication, matched against the active order? And does a medication round survive losing connectivity? If any answer is no, you have a medication list rather than an administration record, and the gap is a clinical safety gap rather than a convenience one.

**Which is better, Epic or Cerner?**

We will not rank them, for two reasons. No sourced comparison data exists in our handover, so any ranking here would be invented. More usefully, both are enterprise platforms sold to hospital networks with implementations measured in years, so if you found this page you are probably not choosing between them. The question that does transfer to your situation is how much of your own clinical workflow you need to keep, because that decides where on the buy-to-build axis you should sit.

**Do we need a practice management system as well as an EMR?**

If you schedule appointments, check insurance eligibility, submit claims or track patient balances, then yes, something has to own those, and in most products it is licensed separately from the clinical record. The mistake to avoid is assuming it is included. Ask explicitly which of scheduling, eligibility, claims and collections are in the quoted price, because discovering the answer after signing is a budget event rather than a technical one.

**Can we store a patient's diagnosis in our CRM to target a campaign?**

You can, and it is the single most common way healthcare organizations accidentally expand their compliance boundary. The moment clinical data enters the marketing system, that system, its vendor, its subprocessors and everyone with a login inherit the full obligation. The safe pattern is to segment inside the clinical system and pass the CRM only an instruction: message these contact identifiers. The CRM never learns why, and you never have to explain why a marketing contractor could read diagnoses.

**What has to be on a superbill for an insurer to accept it?**

Structurally: full provider and facility identifiers, the date of service, coded procedures, coded diagnoses that justify those procedures, and the amount charged. A plain-language receipt is not enough, because an insurer cannot adjudicate a description. Exact required fields vary by payer and by market, so build it as a validated document generator in the billing system with the field list configurable, rather than a template someone completes by hand.

**We are a small clinic. Should we build a custom system?**

Usually not the clinical record itself. Buy that, and build the part your clinic does differently from every other clinic, because that is the part no vendor has built and the only part where custom development reliably earns its cost. The exception is when the unusual workflow is your product rather than your overhead, in which case the thing you are building is not really a clinic system.

We build clinical and operational systems for healthcare providers as [a software development partner in Vietnam](https://agiletech.vn/), which is where the patterns in this guide come from.

---

(c) 2026 AgileTech Vietnam. https://agiletech.vn/blog/emr-ehr-emar-explained/