Accumedic EHI Export Format

This document describes the structure and syntax of the electronic health information (EHI) exports produced by Accumedic EMR and Accumedic PM. It is the export format documentation for ONC Health IT Certification criterion 45 CFR 170.315(b)(10) Electronic Health Information export: the single-patient export (§170.315(b)(10)(i)) and the patient population export (§170.315(b)(10)(ii)). Every export package includes a link to this page.

01The two exports

Accumedic EMR (clinical records) and Accumedic PM (scheduling, billing and practice management) share one database for each practice. An export contains the EHI that the two products store: demographics, clinical documentation, problems, medications, allergies, immunizations, orders and results, treatment plans, assessments, opioid treatment program dispensing, messages, scheduling, insurance, claims, payments and statements. It also contains stored documents and images.

Both exports use the same package structure, file formats and conventions. Records that were deleted in the application but are still stored (for example, encounters marked as deleted) are included in both exports.

02How an export is produced

Single-patient export.

• An authorized user creates it from within Accumedic EMR. It can be run at any time, with no Accumedic involvement (§170.315(b)(10)(i)(B)).
• Steps:
  1. Open the patient's Demographics and select EHI Export.
  2. Select Create EHI export.
  3. The export runs in the background and the user receives a message when it is ready.
  4. Download the ZIP file from the same page.
• Completed exports remain available for download for a period set by the practice (7 days by default).
• Who can create one (§170.315(b)(10)(i)(C)(1)): only users who have been given the Export Patient EHI privilege. Practice administrators assign it to specific users or roles. No user has it until it is assigned, and it is not available in emergency-access sessions.
• Creating and downloading exports are recorded in the application's access audit log.

Patient population export. The practice requests it from Accumedic support. Accumedic produces the export with its export tool and delivers the ZIP file to the practice securely.

03Package structure

An export is a single ZIP file. ZIP64 is used for packages larger than 4 GB.

The C-CDA summary is included for convenience and human readability. Everything it contains is also in data/.

04CSV conventions

• One file per table, named data/<TABLE>.csv. Table and column names are upper case, and columns appear in the source table's order.
• RFC 4180, comma-delimited, UTF-8 without a byte-order mark, CRLF line endings, with a header row.
• Missing values: an unquoted empty field means no value (NULL). A quoted empty field ("") means an empty text value.
• A field that contains a comma, a double quote, a line break, or leading or trailing spaces is enclosed in double quotes. Embedded double quotes are doubled.
• A table with no rows for the patient is still present, as a header-only file.

Every column has a logical type, given in the data dictionary and in manifest.json:

Text flag columns use the values stored by the application, typically Y/N.

05manifest.json

{
  "formatName": "Accumedic EHI Export",
  "formatVersion": "1.0",
  "formatSpecification": "https://patient-export-docs.accumedic.com",
  "exportType": "single-patient",
  "generatedAtUtc": "2026-10-06T14:03:22Z",
  "generator": { "name": "Accumedic EMR", "version": "1.0.0.0", "linkageManifestVersion": "2026-10-06" },
  "source": { "practice": "Example Practice" },
  "consistency": "Tables are read one after another from the database; ...",
  "patientKey": { "table": "PATIENTS", "column": "ACCOUNT" },
  "patients": [ { "account": "000123", "lastName": "Doe", "firstName": "Jane", "dateOfBirth": "1980-01-31" } ],
  "tables": [
    {
      "name": "AR_LINE_ITEMS",
      "category": "patient",
      "domain": "Billing: encounters, A/R, claims, remittance",
      "description": "Charge lines on an invoice: procedure, diagnosis pointers, dates and units.",
      "patientLink": "(INVOICE) -> ACCOUNTS_RECEIVABLE(INVOICE)",
      "patientLinks": [ { "type": "via", "table": "ACCOUNTS_RECEIVABLE", "join": [ { "column": "INVOICE", "references": "INVOICE" } ] } ],
      "primaryKey": ["INVOICE", "LINE_NO"],
      "file": { "path": "data/AR_LINE_ITEMS.csv", "rows": 42, "bytes": 5120, "sha256": "…" },
      "columns": [
        { "name": "INVOICE", "type": "integer", "sqlType": "int", "nullable": false },
        { "name": "DATE_OF_SERVICE", "type": "datetime", "sqlType": "datetime", "nullable": true }
      ]
    }
  ],
  "codeLists": { "AR_TRANSACTION_KIND": { "description": "…", "values": [ { "code": "0", "meaning": "Charge" } ] } },
  "documents": { "count": 17, "totalBytes": 48211122, "files": [ { "path": "documents/PAT_IMAGES/000123_4/referral.pdf",
      "table": "PAT_IMAGES", "column": "IMAGE_BODY", "rowKey": "000123_4", "mimeType": "application/pdf",
      "originalFileName": "referral.pdf", "bytes": 182044, "sha256": "…" } ] },
  "tablesNotIncluded": [ { "name": "…", "category": "audit", "reason": "…" } ],
  "warnings": []
}

06Linkage and attribution

Patient identifier. ACCOUNT (text, up to 12 characters) identifies a patient in both products.

• PATIENTS lists the accounts that are patients.
• PEOPLE holds names, addresses and other demographic details. It holds them for patients and also for related persons, such as an insurance subscriber or guarantor.

How a row relates to a patient. Each patient table's patientLinks gives one or more ways a row can relate to a patient. A row relates to a patient if any of them applies:

• {"type": "column", "column": "X"}: the row's column X holds the patient's ACCOUNT.
• {"type": "via", "table": "T", "join": [{"column": "A", "references": "B"}]}: the row's column A equals column B of a row in table T, and that row relates to the patient. Apply T's own patientLinks the same way.

The data dictionary shows the same information in words. Common keys that link records:

Related persons. In a few tables ACCOUNT identifies someone other than the patient:

• In ACCOUNTS_RECEIVABLE and ELIG_REQUESTS, ACCOUNT is the responsible party or insured; PATIENT_ACCOUNT is the patient.
• In INSURANCE_POLICIES, ACCOUNT is the policy holder. A patient covered as a dependent is linked to the policy through PAT_INSURANCES.
• In PAT_STATEMENT_DATES, ACCOUNT is the statement recipient.

Shared records. Some records belong to more than one patient: a claim batch, an electronic remittance (835) file, a group-therapy group, or a contact person linked to several patients. A single-patient export includes such a record when the patient's records refer to it, but never the other patients' rows. In a population export a shared record appears once, and it relates to every patient whose records refer to it.

Attribution in a population export. To find all rows for one patient, start from PATIENTS.ACCOUNT and apply each table's patientLinks as described above. Reference tables are not attributed to patients.

07Documents and images

Scanned and uploaded documents, photographs, signatures, rendered encounter notes, laboratory result documents and message attachments are written to documents/ in their original file format:

documents/<TABLE>/<row key>/<file name>

• <row key> is the row's primary-key values joined with _.
• <file name> is the original file name when the application recorded one. Otherwise it is the column name plus an extension matching the file's content, for example IMAGE_BODY.pdf.
• When a row has more than one file column, files from the additional columns are prefixed with the column name, for example IMAGE_THUMB_intake.pdf.
• The row's column in the CSV holds the same relative path. manifest.json lists every file with its MIME type, size and SHA-256.
• Where the application stored a file inside a ZIP wrapper, the export contains the original file. ZIP files and Office documents that were uploaded as such are exported unchanged.

08Codes and clinical forms

Code values.

• Many columns hold codes from standard code systems: ICD-10-CM, CPT/HCPCS, SNOMED CT, RxNorm, LOINC, CVX and NDC.
• Practice-defined codes are decoded by reference tables included in the export, for example the lookup tables whose names begin with V_, and directories such as PROVIDERS, PAYORS and LOCATIONS.
• A few code lists are defined by the application itself. They are listed on the code lists page and in manifest.json (codeLists), and are referenced by the columns that use them.

Clinical forms. Clinical documentation is entered on configurable forms.

• Each encounter is a row of EMR_ENCOUNTERS. Its MASTER_TEMPLATE_ID identifies the form used, and the form is described in EMR_MASTER_TEMPLATES.
• The values entered on a form are stored in tables whose names begin with EMR_ENCOUNTERS_ (for example EMR_ENCOUNTERS_PROGRESS_NOTES and EMR_ENCOUNTERS_SOAP). These rows are keyed by ENCOUNTER_ID, plus SEQUENCE_NO for repeating entries.
• EMR_DATA_ELEMENT_MASTER describes each form field: its name, description and units, and the TABLE_NAME and COLUMN_NAME where its value is stored.
• The signed note is also included as a PDF (EMR_ENCOUNTERS.IMAGE_BODY).

09What is not included

Exports contain the EHI the products store. The following are not included:

Audit trails and interface logs are not part of the designated record set. They are excluded from single-patient exports, and are included in a population export only when the practice requests them:

AUDIT_ACTIVITY, AUDIT_FIELD_CHANGES, AUDIT_FORM_ACCESS, AUDIT_HL7_MESSAGES, AUDIT_REPORT_ACCESS, EMR_DRFIRST_ERROR_LOG, EMR_ENCOUNTERS_AUDIT_LOG, EXCHANGE_SYNC_LOG, HL7_RECEIVER_LOG, INTERFACE_LOG_PAT, RCM_INTERFACE_LOG, RCM_PAYMENT_LOG, STOCKAMP_SERVER_LOG

Records that contain other patients' data, such as complete claim transmission files, are included in population exports only:

CLAIM_BATCH_MESSAGES, CLAIM_BATCH_REPORTS, CLAIM_BATCH_TRANSMISSION

Each export's manifest.json lists, under tablesNotIncluded, the tables with patient-related data that are not in that export, and why.

10Stated limits

The export declares the following limits about itself.

11Reading an export

1. Unzip the package, using a tool that supports ZIP64 for large population exports.
2. Read README.txt, then manifest.json. Check exportType, and for a single-patient export, patients.
3. For each entry in tables, load file.path with an RFC 4180 CSV parser, as UTF-8. Treat unquoted empty fields as missing values, and convert values using the column types (section 4).
4. Optionally, verify each file against its sha256.
5. Relate rows to the patient with patientLinks (section 6), and join tables on the keys described in the data dictionary.
6. Decode codes using the reference tables and codeLists (section 8).
7. Open documents from the paths in the CSV columns or in documents.files.

12Versioning and currency

• The format version is in manifest.json (formatVersion). Adding tables or columns does not change the major version, so consumers should ignore columns they do not recognise. A change to the meaning or representation of existing data increments the major version, and the documentation for earlier versions remains available.
• This documentation and the data dictionary are generated from the product's database schema. They are republished whenever a product release changes the export format (§170.315(b)(10)(iii)).
• manifest.json in each export is generated at the time of export, so it always describes that export exactly.

13Contact

Questions about an export can be sent to Accumedic support through the practice's usual support channel.