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.

Contents

Inputs and Outputs
Field Mapping
- ID and Identifier Fields
- Codings
Labs and Vitals Values
Data Source
Example

Inputs and Outputs

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

Note
Due to the data uplifts performed, only bundles from other Orchestrate Convert operations will generate a comprehensive manifest.

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:

conditions.csv
encounters.csv
immunizations.csv
labs.csv
medicationrequests.csv
metrics.csv
patients.csv
procedures.csv
providers.csv
vitals.csv

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).

Tip
Although each FHIR bundle and set of CSV files is for an individual patient, you can combine multiple CSV files for downstream analysis (even for multiple patients).

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 the labs.csv or vitals.csv depending on the underlying data.

Fields in the CSV files are extracted from the corresponding FHIR fields. For example, lastname in patients.csv corresponds to name.family in the Patient resource.

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., facility_provider_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_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 and Vitals Values

The value for a lab observation or vital signs 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:

Type of Data	Columns Populated
Coded Concept	`value_source_code`, `value_source_code_system`, `value_source_display`
Quantity	`value`, and optionally: `unit_display`, `unit_code_system`, `unit_code`
Other (string, integer, boolean, datetime or time period)	`value_string` (for time period type values, `value_string` will have the start and end values separated by a hypen)

Data Source

For a bundle converted to FHIR using the Orchestrate Convert API, the datasource field will reflect the original source of the data (e.g., CCDA, HL7, etc.) before it was converted to FHIR.

Example

Try It
Try out the operations, with examples, in the Developer Portal Sandbox.

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.

Sample Input

{
  "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)
      }
    },
    ...
  ]
}

Sample Output

patients.csv:

patient_id,identifier,lastname,firstname,middlename,birthdate,gender,race_code,race_display,race_string,ethnicity_code,ethnicity_display,ethnicity_string,postalcode
35b77437-425d-419c-90b5-af4bc433ebe9,IheTestPatient,Smith,Patient,,1956-08-13,female,,,,,,,90210

procedures.csv:

resource_id,procedure_date,encounter_date,status_code,status_display,status_code_system,source_code,source_display,source_code_system,hcpcscode1,hcpcsdisplay1,hcpcscode2,hcpcsdisplay2,snomedcode1,snomeddisplay1,snomedcode2,snomeddisplay2,icd10code1,icd10display1,icd10code2,icd10display2,loinccode1,loincdisplay1,loinccode2,loincdisplay2,patient_id,encounter_id,datasource
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,,http://rosetta.careevolution.com/identifiers/CareEvolution/MRN/1.3.6.1.4.1.37608_1.3.6.1.4.1.37608

etc.