Mapping MEDITECH extract to US Core Patient: Field Reference
MEDITECH MAGIC PATIENT.MIS extract (CSV). Maps PT_ID, PT_NAME parts, PT_DOB, PT_SEX, address, phone into US Core Patient.
Field-by-field mapping
Every rule in the Interoperall template is shown below: the source field, the FHIR target path it populates, and the transform applied. This table is generated from the live template, so it matches exactly what runs when you fork it.
| Source | FHIR path | Transform |
|---|---|---|
| (literal "usual") | Patient.identifier[0].use | Copied directly |
| (literal "MR") | Patient.identifier[0].type.coding[0].code | Copied directly |
| column PT_ID | Patient.identifier[0].value | Copied directly |
| column PT_NAME_LAST | Patient.name[0].family | Copied directly |
| column PT_NAME_FIRST | Patient.name[0].given[0] | Copied directly |
| column PT_NAME_MID | Patient.name[0].given[1] | Copied directly |
| column PT_DOB | Patient.birthDate | Date reformat %Y%m%d → %Y-%m-%d |
| column PT_SEX | Patient.gender | Value-set lookup (M→male, F→female, O→other, U→unknown, …; fallback "unknown") |
| column PT_ADDR_1 | Patient.address[0].line[0] | Copied directly |
| column PT_CITY | Patient.address[0].city | Copied directly |
| column PT_STATE | Patient.address[0].state | Copied directly |
| column PT_ZIP | Patient.address[0].postalCode | Copied directly |
| (literal "phone") | Patient.telecom[0].system | Copied directly |
| (literal "home") | Patient.telecom[0].use | Copied directly |
| column PT_PHONE_HOME | Patient.telecom[0].value | Copied directly |
Source extract (CSV row shown as JSON)
The sample input this template is designed to handle:
{
"PT_ID": "M00012345",
"PT_NAME_LAST": "DOE",
"PT_NAME_FIRST": "JOHN",
"PT_NAME_MID": "A",
"PT_DOB": "19800101",
"PT_SEX": "M",
"PT_ADDR_1": "123 MAIN ST",
"PT_CITY": "CITYTOWN",
"PT_STATE": "WA",
"PT_ZIP": "98101",
"PT_PHONE_HOME": "555-555-0100"
}Common gotchas
- Vendor extract column names are not standardized, so verify the exact header in your export (Clarity vs. Caboodle, MAGIC vs. Expanse, CCL report vs. HealtheIntent) before trusting a template.
- Numeric-coded columns (Epic `_C` category columns, MEDITECH numeric flags) need a lookup to the correct FHIR code, and the lookup table is site-configurable, so confirm the codes against your own build.
- Identifier `system` URIs/OIDs are organization-specific. The OID in a template is a placeholder; substitute the OID your facility actually publishes for that identifier namespace.
- Date columns vary between `YYYYMMDD`, ISO timestamps, and locale strings. Normalize to ISO-8601 with a date-format or split transform so the FHIR value is schema-valid.
Target profile
This mapping targets http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient. After mapping, validate the output against the profile — the template populates the Must Support elements, but required elements missing from your source data will still fail. Score it against US Core.
Frequently asked questions
How do I convert a MEDITECH CSV extract to a FHIR Patient?
Map each CSV column to a FHIR element. Coded columns need a value-set lookup, identifier columns need a real system URI/OID, and date columns must be normalized to ISO-8601. The field table on this page shows the exact column-to-path rules; fork the template to adapt the column names to your own export.
Is this Patient mapping US Core compliant?
It targets http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient. The template populates the elements US Core marks as Must Support, but you should always validate the output against the profile. Required elements that are absent in your source data will still fail.
Can I customize this mapping?
Yes. Fork the template in the Mapping Builder to get an editable copy, then add, remove, or re-target rules, for example to handle repeating segments, extra identifiers, or a different value set.