Convert - FHIR R4 to Manifest

POST /convert/v1/fhirr4tomanifest

This operation generates a tabular report of clinical concepts from a FHIR R4 bundle generated by another Orchestrate convert operation (e.g., CDA-to-FHIR, HL7-to-FHIR, or multiple “to FHIR” conversions followed by Combine Bundles).

With this tabular data, you can easily scan results, run queries, and understand the value of your clinical data:

• Summarizing the volume and variety of data elements found in a set of CDAs (e.g., number of problems, procedures, labs, etc.).
• Searching for whether the CDAs described contain any relevant information about certain dates of service, codings, or providers.
• Enabling analysis of larger data sets through concatenation of individual manifests.

Inputs and Outputs

The input is a FHIR R4 Bundle containing data for a single patient from one of the other Orchestrate Convert operations.

The output is a ZIP file, so specify accept: application/zip in your request header.

The ZIP file will contain a number of Comma-Separated Value (CSV) files corresponding to clinical concepts. You can optionally override the delimiter using the query parameters.

See Manifest File Contents for details of the ZIP file contents.

Query Parameters

Field Mapping

The Convert API analyzes each FHIR resource to determine where the data belongs. For example, an Observation resource in the FHIR bundle may be reported in labs.csv, vitals.csv, or socialhistoryobservations.csv depending on the underlying data.

ID and Identifier Fields

FHIR ID columns (patient_id, provider_id, etc.) are populated from the resource ID fields in the FHIR bundle. These serve as primary keys and allow each row in the output to be connected back to the original input bundle. These fields also help link data across the individual CSV files, e.g., renderingprovider_id in encounters links to provider_id in providers file.

The identifier columns are populated with identifier fields from FHIR resources (e.g. patient.identifier, encounter.identifier, etc.) and usually represent the source identifier for a given resource.

Codings

Clinical data like conditions, procedures, etc. will have columns representing the primary code for the concept as it came from the source (the original CCDA/HL7/etc. message). For example: source_code, source_display, source_code_system.

These source values are mapped to corresponding code value(s) in standard code systems. If multiple mappings are available for the original source code, multiple columns will be populated. For example: snomedcode1, snomeddisplay1, snomedcode2, snomeddisplay2, icd10code1, icd10display1, etc.

Labs, Vitals, and Social History Values

The value for a lab, or vital sign, or social history observation can be a coded concept, a quantity, a boolean, a string, an integer, a datetime or a time period. The columns that are thus populated depends on how the data is shared in the source bundle:

Metadata

The metadata.csv file is used to convey the origin of the data in the FHIR bundle. This file will contain different information depending on the original data format. All data rows in other files will link to a row in metadata.csv by the metadata_id.

Example

FHIR Bundles and the resulting CSV files are verbose, so the example below just shows a small sample to illustrate how the data is structured. For a more complete example, try out the API in the Developer Portal Sandbox.

{
  "resourceType": "Bundle",
  "type": "batch-response",
  "entry": [
    {
      "resource": {
        "resourceType": "Patient",
        "id": "35b77437-425d-419c-90b5-af4bc433ebe9",
        ... (patient fields)
      }
    },
    {
      "resource": {
        "resourceType": "Procedure",
        "id": "7.bc640751160d4dce960769e09f6a7de1",
        ... (encounter fields)
      }
    },
    ...
  ]
}

patients.csv:

patient_id,identifier,lastname,firstname,middlename,birthdate,gender,race_code,race_display,race_string,ethnicity_code,ethnicity_display,ethnicity_string,postalcode,primarycareprovider_npi,primarycareprovider_lastname,primarycareprovider_firstname,primarycareprovider_local_identifier,primarycareprovider_id,metadata_id
35b77437-425d-419c-90b5-af4bc433ebe9,IheTestPatient,Smith,Patient,,1956-08-13,female,,,,,,,90210,,,,,,4c13de1e-3c38-4209-bd9d-5f0ad088f7fc

procedures.csv:

resource_id,performed_date,encounter_date,status_code,status_display,status_code_system,source_code,source_display,source_code_system,source_code_text,hcpcscode1,hcpcsdisplay1,hcpcscode2,hcpcsdisplay2,snomedcode1,snomeddisplay1,snomedcode2,snomeddisplay2,icd10code1,icd10display1,icd10code2,icd10display2,loinccode1,loincdisplay1,loinccode2,loincdisplay2,patient_id,encounter_id,metadata_id
7.bc640751160d4dce960769e09f6a7de1,2009-08-10T23:00:00-04:00,,completed,,http://hl7.org/fhir/ValueSet/event-status,3227,"Bronchoscopic bronchial thermoplasty, ablation of airway smooth muscle",urn:oid:2.16.840.1.113883.6.12,,,,,,,,,,,,,,,,,,35b77437-425d-419c-90b5-af4bc433ebe9,,4c13de1e-3c38-4209-bd9d-5f0ad088f7fc

etc.

Manifest File Contents

The output ZIP file contains a number of CSV files, corresponding to clinical concepts.

Clinical data elements will be extracted from the FHIR bundle and placed into the appropriate CSV file, one per row. For example, if the FHIR bundle contained 5 distinct encounters, the encounters.csv file will contain 5 rows of data (plus a header row). Details for each file can be found in the following references:

• patients.csv
• allergies.csv
• conditions.csv
• encounters.csv
• immunizations.csv
• labs.csv
• medicationrequests.csv
• metadata.csv
• procedures.csv
• providers.csv
• questionnaireresponses.csv
• socialhistoryobservations.csv
• vitals.csv