About the Convert API
The Convert API transforms your input data from one standardized format to another. This includes parsing the output, organizing it into the appropriate data types, standardizing source codings as appropriate, and outputting it in another format.
Contents
Operations
The Convert API supports the following operations:
-
CDA to FHIR (R4) converts a CDA document into a FHIR R4 bundle.
-
HL7 to FHIR (R4) converts one or more HL7v2 messages into a FHIR R4 bundle.
-
Combine FHIR (R4) Bundles aggregates information retrieved from prior Convert API requests into a single entry.
Single Patient
All Convert API operations assume the input data represents a single individual.
If data about multiple individuals is received in a single transaction, the output will be commingled. This is not recommended.
Output FHIR Bundles
Convert API operations will return a FHIR R4 Bundle containing the input data converted into FHIR resources. The bundle will be of type searchSet, equivalent to performing a Patient/$everything request against a traditional FHIR server.
Resource IDs
The convert API will generate unique logical ids for all resources that were converted from the input. Resources within a bundle may refer to other resources within the same bundle (e.g., a Condition referencing a Patient/{ID}). The convert API is stateless, and different requests are considered independent of one another. Submitting the same input information to the API multiple times will result in different logical ID elements being generated for the equivalent input concept. Business identifiers are retained if sent in the input data.
Codes/Codings/CodeableConcepts
As part of the conversion process, the API will use the Rosetta Terminology service to standardize input codes. This will result in the following enhancements to output data.
Codes
FHIR code elements represent enumerations with a set of possible values (e.g., Patient.gender, Condition.status). In these situations, the code in the FHIR bundle will be the equivalent input field translated into an equivalent value in the enumeration. An extension element will be added (e.g., Patient._gender, Condition._status) that contains the input code as sent represented as a Coding.
CodeableConcepts
In addition to the data directly present in the input, CodeableConcepts may have additional codings representing the standardized reference codes from the Rosetta Terminology service. These added codings can be identified by the userSelected: false property.
This can include the following:
- Source data coded with a reference CodeSystem OID will also result in a Coding with the appropriate system URI with a reference code and display. (e.g., a source ICD10CM code sent as “E119” with no display and system=”2.16.840.1.113883.6.90” may result in an additional Coding with code=E11.9 display=”Type 2 diabetes mellitus without complications” system=”http://hl7.org/fhir/sid/icd-10-cm” - a standardized term conformant with the FHIR specification).
- Additional reference codings may be included if they represent an equivalent concept (e.g., an input NDC code may result in several additional reference codings for equivalent NDC, RxNorm and CVX codes).
- Uncoded source data may result in a reference Coding if the textual description is sufficient to derive a representative reference Coding.
OperationOutcomes
All Convert API operations resulting in a FHIR Bundle will include an OperationOutcome resource in their output. An OperationOutcome is a collection of issue elements detailing what was parsed from the input, as well as any problems with the conversion. See Operation Outcomes for details.
