In my first week at InfoWerks, I sat in a meeting where someone said, and I’m only lightly paraphrasing, “The NDCs didn’t map cleanly from the legacy PMS, so we’ll need to validate against the flat file before decommissioning.”
I nodded. I wrote it down. I understood approximately none of it.
I came to healthcare data from a marketing background, which means I arrived fluent in SEO and completely lost in the language of this industry. Six months later, I can follow that sentence just fine, but I remember vividly what it felt like not to. Every definition I found online seemed to be written for people who already knew the answer, full of circular explanations and three new acronyms per sentence.
So this is the glossary I wish someone had handed me on day one. It’s not exhaustive, and it’s not written for engineers. It’s written for the marketer, the coordinator, the new hire, the pharmacy owner, or anyone else who keeps hearing these terms and would like them explained like a human being. I’ve grouped them the way they actually came up in my life, rather than alphabetically, because nobody learns an industry in alphabetical order.
Here’s a cheat sheet:
| If you hear… | It basically means… |
| Migration | Moving data |
| Archive | Storing data safely |
| Legacy System | Old software |
| Validation | Double-checking nothing broke |
| Mapping | Matching old fields to new fields |
The Big Picture Terms
Data migration
Moving data from one system to another. That’s really it at the core. The reason entire companies (including mine) exist to do this is that the details are brutal: the old system and the new system almost never store information the same way, the data is often decades old and imperfect, and in healthcare, none of it is allowed to get lost, altered, or exposed along the way. A useful mental picture is moving houses. Anyone can throw things in boxes. Doing it so that nothing breaks, nothing goes missing, and you can find the medication list the moment you need it in the new place is the actual job.
Data archiving
Sometimes data doesn’t need to move into a new active system. It just needs to be stored safely, stay searchable, and remain available for legal and clinical reasons. That’s archiving. A pharmacy that closes, or a hospital that retires an old software system, still has years of records they’re legally required to keep. Archiving puts those records somewhere secure and accessible without paying to keep the old software alive. If migration is moving houses, archiving is a well-organized storage unit with a very good lock and a very good index.
Legacy system
At its simplest, a legacy system is just the old software. That’s all the word really means, even though people often say it with a certain weariness. A legacy system might be a pharmacy management platform from the early 2000s or an EHR the vendor stopped supporting years ago. The tricky part is that legacy systems often still hold records nobody can afford to lose, which is exactly why they can’t simply be switched off.
Decommissioning
The formal process of shutting a legacy system down for good, once its data has been safely migrated or archived. I learned early that this step gets skipped or delayed constantly, and it’s expensive when it does. Organizations end up paying maintenance and licensing fees for software nobody uses, sometimes for years, just because the old system is still the only place certain records live.
Interoperability
The ability of different systems to exchange information and actually understand each other. Two systems can technically both “have” a patient’s data and still be unable to share it in any useful way, which is a bit like two people having the same book in different languages. A huge amount of effort in healthcare, including the standards further down this list, goes toward fixing exactly this.
The Standards Everyone Assumes You Already Know
These came up in my first week and kept coming up every week after. They’re all maintained by standards organizations, and they exist to answer one question: when health data travels between systems, what shape should it take?
HL7
Health Level Seven, both the name of a standards organization and shorthand for the messaging standards it publishes. When people say “an HL7 message” or “HL7 V2,” they usually mean the older, widely used format hospitals and pharmacies have relied on for decades to send things like admissions, orders, and results between systems. It’s not pretty to look at (picture lines of text separated by pipes and carets), but an enormous amount of healthcare still runs on it.
FHIR
Fast Healthcare Interoperability Resources, pronounced “fire,” which makes for endless conference wordplay. FHIR is HL7’s modern standard, built to work the way the rest of the internet works, using web technology that developers already know. If HL7 V2 is a fax machine that everyone has and everyone tolerates, FHIR is the smartphone the industry is gradually moving toward. If you learn only one standards acronym, learn this one, because it’s where the momentum is.
CDA
Clinical Document Architecture, another HL7 standard, this one for structured clinical documents like discharge summaries and care records. You’ll also see C-CDA, a version standardized for the US. The simplest way I’ve found to hold these three in my head: V2 is for messages, CDA is for documents, FHIR is the newer approach designed to handle both.
API
Application Programming Interface, a term from software generally rather than healthcare specifically. An API is a defined way for one program to request information from another, like a menu that tells you exactly what you can order and how. FHIR matters partly because it’s built around APIs, which is what lets a modern app pull a medication list from an EHR without anyone faxing anything.
The Pharmacy Terms
InfoWerks has deep roots in pharmacy data, so these were the words I heard most and understood least.
PMS
Pharmacy Management System, the software a pharmacy runs on day to day. It holds patient profiles, prescription records, refill history, insurance information, and more. When a pharmacy changes software vendors, or closes and transfers its files to another pharmacy, the data inside the PMS is what has to move. There are dozens of PMS products on the market, each storing data its own way, which is a big part of why pharmacy data migration is a specialized skill.
EHR and EMR
Electronic Health Record and Electronic Medical Record. People use them interchangeably in conversation, and for everyday purposes that’s fine. If you want the distinction: an EMR is essentially the digital version of one provider’s chart, while an EHR is designed to be a broader record that can travel with the patient across providers. In migration work, you’ll mostly hear EHR.
NDC
National Drug Code, the unique identifier assigned to every drug product in the US. Each NDC encodes the manufacturer, the drug and its strength and form, and the package size. That last part surprised me: the same medication in a different bottle size gets a different code. NDCs come up constantly in migration because if drug codes don’t carry over correctly, a patient’s medication history stops being trustworthy, and that’s not a small problem.
Sig
The directions on a prescription, from the Latin “signetur.” When a doctor writes “take one tablet by mouth twice daily,” that instruction is the sig, and pharmacies often store it in abbreviated codes. Sigs matter in migration because they’re free-text-ish, inconsistent between systems, and clinically important, which is a challenging combination.
Rx number
The prescription number a pharmacy assigns to each prescription. It seems trivially simple until you learn that different systems number things differently, and patients, insurers, and regulators may all reference those numbers later. Keeping identifiers traceable across a migration is a quiet but essential piece of the work.
How Data Actually Moves
This is the vocabulary of the work itself, the words you’ll hear in project meetings.
ETL
Extract, Transform, Load, the classic three-step description of a migration. Extract the data from the old system, transform it into the structure the new system expects, load it into the new system. Nearly everything else in this section lives inside one of those three verbs.
Flat file
A simple file of plain data, often just text with values separated by commas or other characters, with none of the structure of a proper database. Legacy systems frequently export their data as flat files, and sometimes a flat file is all that survives of a very old system. Part of the craft of this industry is taking a flat file that looks like alphabet soup and reconstructing meaningful patient records from it.
Proprietary format
Data stored in a structure that only one vendor’s software fully understands. This is common, and it’s one of the biggest practical obstacles in migration. When a vendor won’t or can’t hand over data in a usable form, someone has to decode the format, and experience with a particular system’s quirks becomes genuinely valuable.
Data mapping
Deciding, field by field, where every piece of data in the old system belongs in the new one. Old system calls it “Patient DOB,” new system calls it “Date of Birth,” easy enough. But what about the field the old system used for two different purposes depending on the year? Mapping is where those puzzles get solved, and in my six months I’ve come to think of it as the intellectual heart of a migration.
Data profiling
Examining the data before you move it, to find out what you’re actually dealing with. How many records are there? How many have missing fields, impossible dates, duplicate patients? Profiling early prevents ugly surprises late, which is why the best practitioners treat it as non-negotiable.
Validation
Checking, after the move, that everything arrived correctly and completely. In healthcare this goes far beyond counting records. Does the medication history match? Are the allergies intact? Do the totals reconcile? A migration without rigorous validation is just hoping, and hoping is not a compliance strategy.
Chain of custody
A documented record of who handled the data, when, and how, at every step from extraction to delivery. I knew this phrase from crime dramas before I knew it from work, and the spirit is the same: if patient records pass through multiple hands and systems, there must be a verifiable trail proving they were protected the entire way. For regulated data, chain of custody isn’t a nice-to-have. It’s part of the product.
The Compliance Terms
In healthcare, the rules aren’t a layer on top of the work. They shape the work.
HIPAA
The Health Insurance Portability and Accountability Act, the US federal law that, among other things, sets the rules for protecting patient health information. When people say something “has to be HIPAA compliant,” they mean the handling of patient data must meet the law’s privacy and security requirements. Every serious conversation about moving health data happens inside this frame.
PHI and ePHI
Protected Health Information, and its electronic form. PHI is any health information that can be tied to an individual, which covers far more than diagnoses. Names, dates, addresses, prescription numbers, and account numbers all count when connected to health data. Almost everything a migration touches is ePHI, which is why the security posture of a migration partner matters as much as their technical skill.
BAA
Business Associate Agreement, the contract HIPAA requires between a healthcare organization and any vendor that handles PHI on its behalf. If a company is going to touch your patient data and hesitates about signing a BAA, that hesitation is your answer.
Retention requirements
The laws and regulations dictating how long records must be kept, which in pharmacy vary by state and by record type, and often stretch to many years. Retention is the reason “just delete the old system” is never an option, and it’s the quiet engine behind the entire archiving business. It’s also confusing enough that we’re planning a whole separate article on it.
Audit trail
A log of who accessed or changed a record and when. Regulators and courts may ask for this years later, so a good migration or archive preserves not just the records but the ability to account for them.
What I’ve Learned From Learning the Words
Here’s the thing I didn’t expect. Learning this vocabulary wasn’t really about memorizing definitions. Each term, once I understood it, revealed something about what this industry cares about: precision, traceability, and a kind of protectiveness over patient information that I’ve come to find admirable.
I still keep a running note of terms I hear and don’t know, and it still grows most weeks. If you’re new to this world, I’d encourage you to keep one too, and to ask the questions. In my experience, the people who know this field best are remarkably willing to explain it to someone who sincerely wants to understand.
And if there’s a term you think belongs in this glossary, I’d love to hear it!
