client.implementationGuides.implementationGuides.createVersion(name, request) -> ImplementationGuideVersionDetailclient.implementationGuides.implementationGuides.getVersion(name, version) -> ImplementationGuideVersionDetailclient.profiles.profiles.list() -> ProfileListResponseclient.lang2FhirBatch.list() -> JobListResponseclient.profiles.profiles.create(request) -> ProfileSummaryclient.lang2FhirBatch.create(request) -> BatchJobclient.profiles.profiles.get(id) -> ProfileGetResponseclient.lang2FhirBatch.uploadItem(jobId, request) -> UploadItemResponseclient.profiles.profiles.update(id, request) -> ProfileSummaryclient.lang2FhirBatch.finalize(jobId) -> BatchJobclient.profiles.profiles.delete(id)client.lang2FhirBatch.cancel(jobId) -> BatchJobclient.lang2FhirBatch.get(jobId) -> JobDetailResponseclient.lang2FhirBatch.getResults(jobId) -> ResultsPageResponseclient.lang2FhirBatch.getResult(jobId, itemId) -> Map<String, Object>client.profiles.profiles.list() -> ProfileListResponseclient.profiles.profiles.create(request) -> ProfileSummaryclient.profiles.profiles.get(id) -> ProfileGetResponseclient.profiles.profiles.update(id, request) -> ProfileSummaryclient.profiles.profiles.delete(id)client.profiles.versions.list(id) -> ProfileVersionListResponseclient.profiles.versions.create(id, request) -> ProfileSummaryclient.profiles.versions.get(id, version) -> ProfileGetResponseclient.profiles.versions.delete(id, version)Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
Resource support is intentionally limited to the OMOP tables returned by - * this endpoint:
+ * Maps a FHIR R4 resource or Bundle into OMOP Common Data Model v5.4 rows, + * grouped by destination table intables.
+ * Current resource coverage:
*Patient -> personPatient -> person; deceased[x] can also produce death, and the
+ * first address can produce locationobservation_period -> one derived row per person with dated visit,
+ * clinical, or death rows, spanning those datesLocation -> location and care_siteOrganization -> care_site; its first address can produce locationHealthcareService -> care_sitePractitioner and PractitionerRole -> providerEncounter -> visit_occurrenceCondition -> condition_occurrenceProcedure -> procedure_occurrenceMedicationRequest, MedicationStatement, and
* MedicationAdministration -> drug_exposureImmunization -> drug_exposureObservation with a numeric valueQuantity, valueInteger, or
- * numeric-looking valueString (for example "<2") -> measurementObservation -> observationObservation -> measurement or observation. For coded
+ * Observations, the resolved OMOP concept domain selects the table; value
+ * form only breaks ties. For text-only Observations, numeric values route
+ * to measurement and nonnumeric values to observation.AllergyIntolerance -> observationMedication is supported only as reference data for medication
- * resources; it is not emitted as its own row because OMOP CDM has no
- * Medication table. Other reference/admin resources such as Practitioner,
- * Organization, Location, Coverage, and Claim, and clinical
- * workflow/document resources such as DiagnosticReport, ServiceRequest,
- * CarePlan, DocumentReference, Composition, Specimen, and
- * DeviceUseStatement, are currently accepted in a Bundle but are not
- * shaped into OMOP rows. Unsupported resource types are ignored rather than
- * listed under dropped; dropped is reserved for supported resource types
- * that were missing the subject/patient, code, or medication reference data
- * needed to produce a valid row.
Each resource's primary clinical coding is resolved to a standard OMOP
- * concept_id. Alongside the OMOP rows grouped by table (tables), the
- * response carries mappings (how each source coding resolved, linked back
- * to the row it produced), dropped (resources that could not be shaped
- * into a row), vocab_version (the OMOP vocabulary release codes were
- * resolved against), and a small summary of the resolution outcomes.
Medication is reference data for medication resources; it does not
+ * create its own row because OMOP CDM has no Medication table. Administrative
+ * linkages (provider, care site, and location) are best-effort and limited to
+ * references supplied in the request. Their supporting concepts, including
+ * provider specialty, country, and place of service, are not mapped.
DiagnosticReport, ServiceRequest, CarePlan, DocumentReference,
+ * Composition, Specimen, DeviceUseStatement, Coverage, Claim, and
+ * other unsupported resource types are accepted in a Bundle but ignored: they
+ * create no row and no dropped entry. dropped is reserved for supported
+ * row-producing resources that could not be shaped because the subject/patient,
+ * clinical code/text, or medication data was not usable. A single-Patient
+ * Bundle can attribute a supported clinical resource with a missing or
+ * unresolvable subject to that sole person; in a multi-Patient Bundle, that
+ * resource is dropped instead.
Coded Observation routing is selected from the resolved OMOP concept
+ * domain. Numeric and nonnumeric value[x] forms establish the preferred
+ * target only when the code is valid for both tables. A text-only
+ * Observation has no resolver target, so numeric values route to
+ * measurement and nonnumeric values to observation. Numeric values
+ * populate value_as_number in the selected row; nonnumeric values
+ * populate value_as_string for an observation or value_source_value
+ * for a measurement. valueCodeableConcept remains source text and does
+ * not populate value_as_concept_id; other unsupported value[x] forms
+ * and Observation components do not populate separate converted values. A
+ * numeric comparator (<, <=, >, >=) is represented only by a
+ * measurement's operator_concept_id; units remain source text and have
+ * unit_concept_id of 0.
A single standard OMOP concept_id is selected for each clinical row
+ * after considering all of the resource's supplied codings. Alongside the
+ * OMOP rows grouped by table (tables), the response carries mappings
+ * (an entry for every source coding, linked back to the row it produced),
+ * dropped (resources that could not be shaped into a row),
+ * vocab_version (the OMOP vocabulary release codes were resolved
+ * against), and a small summary of the resolution outcomes.
A concept_id of 0 is reported, not omitted (OMOP "no matching
* concept" semantics): it covers both a coding with no standard match
* (UNMAPPED) and an unverified suggestion for a text-only resource
- * (UNCHECKED). Only the primary clinical coding is resolved, so
- * gender/race/ethnicity/visit/value/unit concept_ids are
- * always 0; the one populated non-resolved concept is measurement
+ * (UNCHECKED). Demographic, visit, categorical-value, and unit concept
+ * fields currently remain 0; the one populated non-resolved concept is
+ * measurement
* operator_concept_id, set from a value comparator (<, <=, >, >=)
- * rather than the resolver. Each *_source_value carries the verbatim FHIR
- * coding (system#code), and *_type_concept_id is set to 32817 (EHR).
*_source_value fields
+ * preserve the selected FHIR coding (system#code, or code when no
+ * system is supplied), falling back to source text for text-only resources.
+ * Known OID-form coding systems are accepted as either FHIR OID URNs (for
+ * example, urn:oid:2.16.840.1.113883.6.1 for LOINC) or bare OIDs, and
+ * are normalized to their canonical system URLs before terminology
+ * resolution. *_source_value and mappings[].source_system report that
+ * canonical URL, so the OID and URL forms produce the same mapping. An
+ * unknown OID is not rewritten and may be UNMAPPED.
+ * Other *_source_value fields preserve row-specific raw source values,
+ * such as resource identifiers, names, units, or status codes, and
+ * *_type_concept_id is set to 32817 (EHR).
* Medication codes are resolved whether they appear inline
* (medicationCodeableConcept) or via a medicationReference to a contained,
* relative (Type/id), or bundle-entry (urn:uuid) Medication resource.
* Resources that cannot be shaped into a row — a medication with no usable
* code, resolvable reference, or display, or any clinical resource whose
* subject/patient reference cannot be tied to a person — are reported under
- * dropped rather than emitted as blank rows. The
- * bundle must contain at least one Patient resource.
dropped rather than emitted as blank rows. The Bundle must contain at
+ * least one Patient resource.
+ * All row IDs start at 1 for each request and are not stable or global.
+ * For clinical conversion rows whose resource supplies an id, mappings
+ * associates each row with that source FHIR resource ID. A person row
+ * retains the Patient ID or its first identifier value in
+ * person_source_value, when present; other reference and derived rows do
+ * not uniformly carry a FHIR resource ID. Input resources without those
+ * source identifiers cannot be correlated across responses from the
+ * returned rows alone. Consumers combining responses need to establish
+ * their own stable keys and remap every primary and foreign key together.
FHIR resources (single resource or Bundle). Must contain at least one * Patient resource. Supported row-producing resources are Patient, - * Encounter, Condition, Procedure, MedicationRequest, + * Location, Organization, HealthcareService, Practitioner, + * PractitionerRole, Encounter, Condition, Procedure, MedicationRequest, * MedicationStatement, MedicationAdministration, Immunization, * Observation, and AllergyIntolerance. Standalone Medication resources * are consumed by medication references rather than mapped to their own - * table. Other resource types are accepted but ignored.
+ * table. Unsupported resource types are accepted in a Bundle but ignored. */ @JsonSetter(value = "fhir_resources", nulls = Nulls.SKIP) public Builder fhirResources(MapThe OMOP vocabulary release the clinical codes were resolved against - * (e.g. "v20240229"), for reproducibility. Present when at least one - * coded concept was resolved.
+ *The OMOP vocabulary release returned for coded concept resolution + * (for example, "v20240229"), for reproducibility. It is generally + * absent for requests containing only text-only resources.
*/ @JsonSetter(value = "vocab_version", nulls = Nulls.SKIP) public Builder vocabVersion(OptionalCoded concepts already a standard OMOP concept (ALREADY_STANDARD).
+ *Resolution outcomes already a standard OMOP concept (ALREADY_STANDARD).
*/ @JsonSetter(value = "codes_already_standard", nulls = Nulls.SKIP) public Builder codesAlreadyStandard(OptionalCoded concepts mapped or suggested to a standard concept (MAPPED or UNCHECKED).
+ *Resolution outcomes mapped or suggested to a standard concept (MAPPED or UNCHECKED).
*/ @JsonSetter(value = "codes_normalized", nulls = Nulls.SKIP) public Builder codesNormalized(OptionalCoded concepts with no standard concept found (UNMAPPED).
+ *Resolution outcomes with no standard concept found (UNMAPPED).
*/ @JsonSetter(value = "codes_unmapped", nulls = Nulls.SKIP) public Builder codesUnmapped(OptionalShare of coded concepts not already standard ((normalized + unmapped) / total).
+ *Share of resolution outcomes not already standard ((normalized + unmapped) / total).
*/ @JsonSetter(value = "off_vocab_rate", nulls = Nulls.SKIP) public Builder offVocabRate(Optional409 Conflict until multi-version package support lands.
+ */
+ public CompletableFuture409 Conflict until multi-version package support lands.
+ */
+ public CompletableFuture409 Conflict until multi-version package support lands.
+ */
+ public CompletableFuture409 Conflict until multi-version package support lands.
+ */
+ public CompletableFuture409 Conflict until multi-version package support lands.
+ */
+ public ImplementationGuideVersionDetail createVersion(
+ String name, CreateCanonicalImplementationGuideRequest request) {
+ return this.rawClient.createVersion(name, request).body();
+ }
+
+ /**
+ * Publishes an exact package beneath this guide family. PR 2 temporarily
+ * permits one exact package version per guide family; publishing another
+ * version returns 409 Conflict until multi-version package support lands.
+ */
+ public ImplementationGuideVersionDetail createVersion(
+ String name, CreateCanonicalImplementationGuideRequest request, RequestOptions requestOptions) {
+ return this.rawClient.createVersion(name, request, requestOptions).body();
+ }
+
+ public ImplementationGuideVersionDetail getVersion(String name, String version) {
+ return this.rawClient.getVersion(name, version).body();
+ }
+
+ public ImplementationGuideVersionDetail getVersion(String name, String version, RequestOptions requestOptions) {
+ return this.rawClient.getVersion(name, version, requestOptions).body();
+ }
}
diff --git a/src/main/java/com/phenoml/api/resources/implementationguides/implementationguides/RawImplementationGuidesClient.java b/src/main/java/com/phenoml/api/resources/implementationguides/implementationguides/RawImplementationGuidesClient.java
index 524cd281..e575dbeb 100644
--- a/src/main/java/com/phenoml/api/resources/implementationguides/implementationguides/RawImplementationGuidesClient.java
+++ b/src/main/java/com/phenoml/api/resources/implementationguides/implementationguides/RawImplementationGuidesClient.java
@@ -13,14 +13,17 @@
import com.phenoml.api.core.RequestOptions;
import com.phenoml.api.core.RetryInterceptor;
import com.phenoml.api.resources.implementationguides.errors.BadRequestError;
+import com.phenoml.api.resources.implementationguides.errors.ConflictError;
import com.phenoml.api.resources.implementationguides.errors.ForbiddenError;
import com.phenoml.api.resources.implementationguides.errors.InternalServerError;
import com.phenoml.api.resources.implementationguides.errors.NotFoundError;
import com.phenoml.api.resources.implementationguides.errors.UnauthorizedError;
+import com.phenoml.api.resources.implementationguides.implementationguides.requests.CreateCanonicalImplementationGuideRequest;
import com.phenoml.api.resources.implementationguides.implementationguides.requests.UpdateImplementationGuideRequest;
import com.phenoml.api.resources.implementationguides.types.ImplementationGuideDetail;
import com.phenoml.api.resources.implementationguides.types.ImplementationGuideListResponse;
import com.phenoml.api.resources.implementationguides.types.ImplementationGuideSummary;
+import com.phenoml.api.resources.implementationguides.types.ImplementationGuideVersionDetail;
import java.io.IOException;
import okhttp3.Headers;
import okhttp3.HttpUrl;
@@ -304,22 +307,18 @@ public PhenomlClientHttpResponse409 Conflict until multi-version package support lands.
+ */
+ public PhenomlClientHttpResponse409 Conflict until multi-version package support lands.
+ */
+ public PhenomlClientHttpResponseurl|version references to builtin or custom profiles. A package can contain at most 250 references.
+ */
+ @JsonProperty("profile_refs")
+ public ListExact canonical url|version references to builtin or custom profiles. A package can contain at most 250 references.
Natural-language profile-selection context for this package.
+ */ + _FinalStage profileContext(OptionalNatural-language profile-selection context for this package.
+ * @return Reference to {@code this} so that method calls can be chained together. + */ + @java.lang.Override + public _FinalStage profileContext(String profileContext) { + this.profileContext = Optional.ofNullable(profileContext); + return this; + } + + /** + *Natural-language profile-selection context for this package.
+ */ + @java.lang.Override + @JsonSetter(value = "profile_context", nulls = Nulls.SKIP) + public _FinalStage profileContext(OptionalExact canonical url|version references to builtin or custom profiles. A package can contain at most 250 references.
Exact canonical url|version references to builtin or custom profiles. A package can contain at most 250 references.
Exact canonical url|version references to builtin or custom profiles. A package can contain at most 250 references.
Canonical FHIR ImplementationGuide URL, when the family has an exact package.
+ */ + @JsonSetter(value = "canonical_url", nulls = Nulls.SKIP) + public Builder canonicalUrl(OptionalNumber of retained exact package versions.
+ */ + @JsonSetter(value = "version_count", nulls = Nulls.SKIP) + public Builder versionCount(OptionalPresent only for guides that have stored metadata (a profile_context has been set). Omitted for guides that exist solely because a profile references them.
*/ @@ -256,7 +325,15 @@ public Builder profiles(ListCanonical FHIR ImplementationGuide URL, when the family has an exact package.
+ */ + @JsonSetter(value = "canonical_url", nulls = Nulls.SKIP) + public Builder canonicalUrl(OptionalNumber of retained exact package versions.
+ */ + @JsonSetter(value = "version_count", nulls = Nulls.SKIP) + public Builder versionCount(OptionalPresent only for guides that have stored metadata (a profile_context has been set). Omitted for guides that exist solely because a profile references them.
*/ @@ -224,7 +293,14 @@ public Builder updatedAt(OffsetDateTime updatedAt) { public ImplementationGuideSummary build() { return new ImplementationGuideSummary( - name, profileContext, profileCount, createdAt, updatedAt, additionalProperties); + name, + profileContext, + profileCount, + canonicalUrl, + versionCount, + createdAt, + updatedAt, + additionalProperties); } public Builder additionalProperty(String key, Object value) { diff --git a/src/main/java/com/phenoml/api/resources/implementationguides/types/ImplementationGuideVersionDetail.java b/src/main/java/com/phenoml/api/resources/implementationguides/types/ImplementationGuideVersionDetail.java new file mode 100644 index 00000000..28c37db5 --- /dev/null +++ b/src/main/java/com/phenoml/api/resources/implementationguides/types/ImplementationGuideVersionDetail.java @@ -0,0 +1,382 @@ +/** + * This file was auto-generated by Fern from our API Definition. + */ +package com.phenoml.api.resources.implementationguides.types; + +import com.fasterxml.jackson.annotation.JsonAnyGetter; +import com.fasterxml.jackson.annotation.JsonAnySetter; +import com.fasterxml.jackson.annotation.JsonIgnoreProperties; +import com.fasterxml.jackson.annotation.JsonInclude; +import com.fasterxml.jackson.annotation.JsonProperty; +import com.fasterxml.jackson.annotation.JsonSetter; +import com.fasterxml.jackson.annotation.Nulls; +import com.fasterxml.jackson.databind.annotation.JsonDeserialize; +import com.phenoml.api.core.ObjectMappers; +import java.time.OffsetDateTime; +import java.util.ArrayList; +import java.util.HashMap; +import java.util.List; +import java.util.Map; +import java.util.Objects; +import org.jetbrains.annotations.NotNull; + +@JsonInclude(JsonInclude.Include.NON_ABSENT) +@JsonDeserialize(builder = ImplementationGuideVersionDetail.Builder.class) +public final class ImplementationGuideVersionDetail { + private final String name; + + private final String url; + + private final String version; + + private final String profileContext; + + private final ListPatient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.
Patient identifier handling. When generating a patient (or patient-canvas) resource, US Core requires Patient.identifier (a business identifier such as an MRN). When the source text contains an identifier, it is extracted with an appropriate URI system. When the source text does not contain a detectable identifier, a synthetic one is generated with system: "urn:phenoml:lang2fhir-generated-id" and a UUID value so the resource remains FHIR-valid and US Core conformant. Callers who need a tenant-specific namespace should rewrite the synthetic system after extraction.