MVS Health EHI Export Data Dictionary

This page documents how the MVS Health application exports electronic health information (EHI) so that a patient's data, or a full patient population's data, can be retrieved in a computable form. It is published as public, no-login transparency documentation.

This page describes the implemented native export behavior and is intended to support review of MVS Health's export capability. It is evidence-supporting documentation, not a certification statement, and it does not by itself assert conformance with any specific program criterion. Coverage is defined by the export catalog in the application source; where a data class cannot yet be exported, the export surfaces an explicit coverage warning rather than omitting it silently.

Export Types

MVS Health exposes two native EHI export paths.

Both paths read only tenant-scoped MVS Health data for the authenticated organization, are permission-gated, and write an audit record for each export attempt (success and failure).

• The single-patient export returns a native JSON document (format: "native-json", exportType: "single-patient") covering the same domains as the population export, scoped to a single patient. Data classes that cannot be reached from a single patient are omitted from the single-patient path rather than returned as organization-wide rows.
• The population export is the authoritative all-EHI path. It returns a manifest plus per-domain NDJSON sections for the entire tenant population.

Population Export File Layout

The population export returns a manifest and a set of per-domain section files. The manifest format identifier is:

healthos-native-population-v1

Manifest

The manifest is a JSON object with the following shape:

{
  "format": "healthos-native-population-v1",
  "exportId": "uuid",
  "exportType": "all-patients",
  "organizationId": "org id",
  "generatedAt": "ISO-8601 timestamp",
  "resourceCount": 0,
  "resourceCounts": { "Patient": 0, "Encounter": 0 },
  "domainCounts": { "coreClinical": 0, "billingRcm": 0 },
  "files": [
    {
      "path": "sections/coreClinical/Patient.ndjson",
      "format": "ndjson",
      "resourceType": "Patient",
      "domain": "coreClinical",
      "count": 0,
      "sha256": "hex digest of the section content"
    }
  ],
  "warnings": [
    {
      "id": "inventory id",
      "ehiClass": "human-readable class",
      "sourceStore": "source table",
      "status": "coverage status",
      "remediation": "what is required to close the gap"
    }
  ],
  "warningIds": ["inventory id"]
}

• resourceCounts is keyed by resourceType; domainCounts is keyed by domain. resourceCount is the total record count across all sections.
• Each entry in files carries a count (records in the section) and a sha256 (a SHA-256 hex digest of the exact section content), so a reviewer can verify each file independently.
• warnings / warningIds list coverage gaps for the export (see Coverage Warnings).

Section files

Each domain resource type is emitted as one NDJSON file (one JSON record per line):

sections/{domain}/{resourceType}.ndjson

The export can be consumed two ways:

• As the files array, where each file includes its NDJSON content inline alongside its count and sha256.
• As a bundle object containing the manifest and a sections map of path to NDJSON content.

Per-Domain Data Dictionary

The export is organized into domains. coreClinical is emitted directly; the remaining domains are emitted from the native export catalog. The resource types below are the manifest section keys.

coreClinical

coverageEligibility

documentsStorage

careManagement

clinicalExtended

communications

hieFhir

erx

billingRcm

schedulingAndIntake

Stored Documents and Sensitive Fields

Stored files (documents, fax and message attachments, consent documents, X12 claim batch files, and similar) are not emitted as raw bytes, download URLs, or storage keys. Instead, each owning record carries a computable, access-controlled reference:

{
  "storageRepresentation": {
    "hasStoredObject": true,
    "fileSize": 12345,
    "mimeType": "application/pdf",
    "status": "available"
  }
}

This preserves the fact that a stored object exists, its size, type, and status, so the export remains computable and reconcilable, while raw bytes, URLs, and storage keys are intentionally omitted. Credentials and tokens are always stripped. Free-text and narrative fields (note bodies, message bodies, transcripts, raw payloads) are redacted to computable metadata (for example { "redacted": true, "length": 128 }) so record and field structure is preserved without emitting the underlying narrative content.

Coverage Warnings

The population export never silently drops a data class. When a class is not exported as its own section, the manifest includes a coverage warning with:

• id — the inventory identifier for the data class.
• ehiClass — a human-readable description.
• sourceStore — the underlying source.
• status — the coverage status (for example metadata-only, runtime-evidence-required, scope-decision-required, or not-available).
• remediation — what is required to close the gap.

Reviewers should retain the warningIds list as the explicit set of known coverage gaps for a given export.

Authorization

Exports are available only to authorized users of the tenant.

• Single-patient export requires the patient:export permission.
• Population export requires the bulk-export:write permission.

The in-app population export action is shown only to users whose role grants bulk-export:write, and the server independently enforces the same permission on every request. Every export attempt is written to the audit log with the acting user, organization, resource counts, and outcome.

No Fee and No Information Blocking

MVS Health does not charge a fee for a patient or an authorized user to obtain that patient's EHI through these export paths, and does not impose access restrictions that would constitute information blocking. Export is a first-class, self-service capability in the application for users with the appropriate permission.

Update Process

This page is updated when the export catalog changes. Specifically, when a resource type or domain is added to, or removed from, the export catalog in the application source, the corresponding per-domain data dictionary table above is updated to match, and any change to the manifest shape or file layout is reflected here. The export catalog in source remains the authoritative definition of coverage; this page mirrors it for public transparency.