Data from a health record (HL7 FHIR R4)

A patient's FHIR Bundle from the hospital's system: labs, vital signs, conditions and medications into the eCRF, checked and confirmed by the site.

Many hospital systems export a patient's record in HL7 FHIR R4, the common standard of health records in the US and Germany. YouEDC Capture reads such a file and lays its lab results, vital signs, conditions and medications out on the study's eCRF. You check every value against the record and confirm it; nothing goes into the eCRF without your confirmation, and the history of each value names its FHIR source.

The preview: each value with its FHIR source on the left and its place in the eCRF on the right. The creatinine came in mg/dL and was converted into the field's µmol/L; the original stays next to it.

Before the first import: the mapping

A study manager or a data manager sets once where the data of a record go: eCRF builder › FHIR mapping.

• Lab results and vital signs by LOINC. Each LOINC code goes into a field (or a row of a lab grid). Add the default map proposes codes for the common tests of the form library: blood count, clinical chemistry, lipids, HbA1c, urine albumin and the vital signs, each into a field of the same test whose unit converts, in a log form first. Change any row, or add the laboratory's own code of a test.
• Conditions and medications. Each Condition becomes a new record of the form you choose for conditions (a medical history log), each MedicationStatement or MedicationRequest a new record of the medications form (a concomitant medication log). The fields of the form are matched by their CDASH codes (MHTERM, MHSTDAT, CMTRT, CMDOSE…); check them and change them if needed.
• Allergies (AllergyIntolerance) go into the conditions' form only when you tick it.

The mapping in the eCRF builder: a LOINC code, our short description of the test, its usual unit and the field it goes into.

How to import a patient's record

1. Open the patient's card and click From the health record (FHIR). Whoever enters data at the patient's site sees the button.
2. Choose the file the hospital system exported: a FHIR Bundle in JSON, a single resource, or NDJSON (one resource a line), up to 5 MB. One file is for one patient.
3. Values of visit forms (vital signs, for example) go into the scheduled visit whose window holds the date of the measurement. To put them all into one visit, choose it under Values for the forms of visits.
4. The preview opens. Nothing is saved yet.

The preview

The preview lists every value that can go into the eCRF, form by form: the FHIR resource with its id and date, the code (LOINC, ICD-10, ATC…), the value as the record gives it, the field of the eCRF and the value for the field.

• New: the place is empty. A new record (a day's lab results, a condition, a medication) is ticked as a whole; a value of an existing form is ticked one by one.
• Would change a saved value: the value saved now is shown next to it. Such a value is not ticked: tick replace only after checking which is right, and give the reason, as for any change of saved data.
• Already in the eCRF: the eCRF has the same value; nothing to do.
• Not imported and Not usable, below the forms, with the reason for each resource: a preliminary result, a code that is not mapped, a unit that cannot be converted, a condition marked refuted, a medication not taken, a resource of another kind (Encounter, for example), or a record imported before.

Above the list the preview compares the record's sex and year of birth with the patient's card. If they differ, a red notice asks whether this is the patient's record: drop such an import with Drop the import.

Confirm

1. Compare the values with the health record and untick what should not go in.
2. Tick This is the health record of patient … and I compared the values above with it. If you replace saved values, give the reason.
3. Click Confirm and save into the eCRF. The values are saved through the same edit checks as typing; a value the form refuses is not saved and the result says why. A new record that misses a required field is saved as a draft.

After the confirmation: the form names the FHIR source of each imported value and links to the import.

A value that someone changed in the eCRF after the preview was opened is not saved: the result says so, and you can upload the file again to see the new state.

From the hospital system through the API

The hospital system can post the same file through the write API with its key: POST /api/v1/studies/<study>/fhir?subject=<patient ID>. By default the import waits on the patient's card and in the study's list Health records (FHIR) for the site to check and confirm it. A key may also save at once (mode=save) the values that fill empty places and the new records; a value that would change a saved one is never saved that way. The audit trail names the key, on behalf of the person who made it.

Units and codes

• Units are converted into the field's unit when the conversion is certain: mg/dL of creatinine, glucose or urea into µmol/L or mmol/L, g/dL into g/L, pounds into kilograms, °F into °C. Spellings of the same unit (UCUM, English, Russian) are the same unit. A unit that is missing or unknown is never guessed: the value is shown with the reason and not saved.
• Codes of conditions and medications (ICD-10, SNOMED CT, ATC, RxNorm) are kept as the record gives them. YouEDC uses no dictionary to change them and contains no SNOMED CT content.
• LOINC. This material contains content from LOINC (https://loinc.org). LOINC is copyright © 1995-2026, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license at https://loinc.org/license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc. YouEDC keeps only the codes of its default map with its own short descriptions, not the LOINC table.

Patient data and audit

• Only what the study needs is kept. Of the Patient resource only the sex and the year of birth are read, to compare them with the card. Names, addresses, phone numbers and identifiers (insurance, passport, medical record numbers) are never read or stored, nor the doctors, notes and encounters of other resources. Neither the file nor its name is stored: only its SHA-256 fingerprint and the preview (152-FZ, GDPR, HIPAA minimum necessary).
• Audit. Reading a file is written to the audit trail with the number of the import (FH-1, FH-2…), the confirmation with what was saved. Each saved value has its own record with source “import”, the person who confirmed it (or the API key on behalf of its owner), the reason when it replaced a saved value, and its FHIR source: “FHIR import FH-1: Observation/lab-creat-1 of 05.10.2026” (ICH E6(R3), 21 CFR Part 11).
• Who may do what. Those who enter data at the patient's site upload and confirm; monitors and data managers see the preview and the list; only the eCRF builder's people change the mapping.

Try it. The import page has a Sample FHIR file to download: an invented patient with labs in US units, blood pressure, conditions and medications. In a demo project the button Read the sample for this patient reads it at once, with the sex and the year of birth of the demo patient’s card. The kidney disease cohort demo already holds a confirmed import (FH-1) and a corrected result posted by the hospital system that waits for review (FH-2).