# Metriport raises $26 million to give clinicians insight at the point of care

## Thousands of documents in. One record out.

Work with structured data that's clean, standardized, and actionable - no matter the format at its source.

C-CDA · from an HIE<ClinicalDocument> <recordTarget> …

HL7v2 · ADT feedMSH\|^~\\&\|…PID\|1\|…^^^MR

PDF · scanned summary

**HARMONIZATION**

**Bundle · FHIR R4**

```
{
  "id": "XXXXX-XXXXXX-XXXXXX-XXXXXX",
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    {
      "resource": {
        "resourceType": "Encounter",
        "id": "XXXXX-XXXXXX-XXXXXX-XXXXXX",
        "status": "finished",
        "class": {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
          "code": "HH",
          "display": "home health"
        }
      }
    }
  ]
}
```

C-CDA · from an HIE<ClinicalDocument> <recordTarget> …

HL7v2 · ADT feedMSH\|^~\\&\|…PID\|1\|…^^^MR

PDF · scanned summary

**HARMONIZATION**

**Bundle · FHIR R4**

## Join the teams building on **data that arrives usable**, whatever shape it left the source in.

Between the source and your query

Arrives as C-CDA · HL0123456789v0123456789 · FHIR · PDF

**Harmonization Engine**

## Four stages between the source and your query.

**Source format**

- FHIR R4 output
- C-CDA 2.1
- Bundle
- HL7v2
- Encounter
- PDF

### Take data in whatever format it exists

C-CDA, HL7v2, scanned documents, and native FHIR are all converted to FHIR R4, with source references retained so nothing becomes untraceable.

### Map every code to one vocabulary

Clinical codes map to LOINC, RxNorm, SNOMED, and ICD-10, so the same concept from two sources compares as the same concept.

### Resolve one patient across every source

Records that arrive under different identifiers are matched and resolved to the one patient they describe.

### Read one record, not fourteen copies of one

Duplicates collapse on consolidation, so the record your team queries is the patient's history told once.

## Benefits

### Your team reads records, not formats.

The conversion, coding, and dedup all happened before the data reached you.

### Coded once, comparable everywhere.

Analytics, quality reporting, and risk work all start from data that is already on one vocabulary, with no per-source mapping project between your team and its first query.

### A record, not a pile of near-duplicates.

Networks return the same encounter many times in many shapes. Consolidation collapses the copies, keeps the provenance, and hands your team the history told once.

### Your own data enters the same pipeline.

Contributed FHIR resources and uploaded documents run through the same standardization as everything retrieved, so internal and external history read as one record.

## How it works

## One pipeline, both directions.

What you contribute is cleaned too.

1. **Query the consolidated FHIR record**

What comes back has already been converted, coded, resolved, and deduplicated. All four stages ran on retrieval.

2. **Contribute valid FHIR R4 resources**

Contributed data must reference the correct Metriport patient; document uploads begin with a patient-linked DocumentReference.

## Customers

## Chosen by the teams that compared.

A data layer reliable enough to treat on, an evaluation won on completeness, and records that stopped being fragments.

### FAQs

1. **What does standardization actually change?**

Returned C-CDA documents are converted to FHIR R4, and clinical codes are mapped to LOINC, RxNorm, SNOMED, and ICD-10 so the same concept from two sources compares as the same concept. Source references are retained, so nothing becomes untraceable in the process.

2. **Which FHIR R4 resources and document formats can be contributed?**

The standard public interface supports valid FHIR R4 resources and documented clinical-document uploads. Check the current contribution documentation for accepted resources, references, and file formats.

3. **How must references and patient IDs be represented?**

Contributed resources must reference the correct Metriport patient and use valid FHIR references. Document uploads begin with a patient-linked DocumentReference.

4. **When is data contribution required?**

Data contribution is generally required for exchange customers after relevant encounters. An approved on-behalf-of exception may change that obligation; confirm the applicable production requirements during onboarding.