FHIR Tooling Extensions IG
1.1.2 - Release 1.1 International bandera

FHIR Tooling Extensions IG, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 1.1.2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/FHIR/fhir-tools-ig/ and changes regularly. See the Directory of published versions

OperationDefinition: ValueSet Comparison

URL oficial: http://hl7.org/fhir/tools/OperationDefinition/ValueSet-compare Versión: 1.1.2
Standards status: Informative Nivel de madurez: 1 Nombre computable: ValueSetCompare
Otros identificadores: OID:2.16.840.1.113883.4.642.40.1.33.2

Determine the set relationship between the memberships of two value sets: whether they contain the same codes, whether one is a subset or superset of the other, whether they overlap, or whether they are disjoint. The comparison is over what the value sets mean (the set of codes each includes), not over the structure of the ValueSet resources.

The two value sets are referred to as 'this' and 'other'. At the type level (POST /ValueSet/$compare), supply each one as either an inline resource (thisValueSet / otherValueSet) or as a canonical URL the server resolves (thisUrl / otherUrl). At the instance level (POST /ValueSet/[id]/$compare), the value set addressed in the URL is 'this', and only 'other' need be supplied.

The server decides from the value set definitions (the compose) wherever it can — this is cheap and exact, and is version-aware. Where the definitions are too complex to compare directly, it expands both value sets and compares the resulting code lists. Either way the answer is reported in the result output parameter. When the relationship cannot be established — for example a value set has no compose, an expansion is unclosed or infinite, an expansion fails, or the definitions combine in ways the server cannot soundly reason about — the result is indeterminate rather than a guess.

If the diagnostics parameter is true, the server additionally reports the codes that differ (common-codes, missing-codes, extra-codes) and whether it had to expand the value sets to reach its conclusion (performed-expansion). This operation does not change server state.

Language: es

URL: [base]/ValueSet/$compare

URL: [base]/ValueSet/[id]/$compare

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INthisUrl0..1uri

The canonical URL of the first value set ('this'), which the server resolves. Used at the type level as an alternative to thisValueSet. Not used at the instance level, where the value set in the request URL is 'this'.

INthisValueSet0..1ValueSet

The first value set ('this'), supplied inline. Used at the type level as an alternative to thisUrl. Not used at the instance level.

INotherUrl0..1uri

The canonical URL of the second value set ('other'), which the server resolves. An alternative to otherValueSet.

INotherValueSet0..1ValueSet

The second value set ('other'), supplied inline. An alternative to otherUrl.

INvalueSetVersion0..1string

The business version to use when resolving a value set supplied by URL.

INtx-resource0..*Resource

Additional code systems and value sets the server may need in order to perform the comparison — for example, code systems referenced by the value sets but not otherwise known to the server. These may also be supplied via the terminology cache; see the $cache-control operation.

INversion-policy0..1code

Controls whether code system versions are significant when comparing membership:

  • always — versions always matter: a code counts as the same member in both value sets only if its code system version matches on both sides;
  • as-needed — (the default) versions matter only where they need to: when either code system declares versionNeeded = true, or where a filter is involved (a filter such as is-a can select different codes in different versions, so the version always matters there);
  • never — versions never matter: codes are compared by system and code alone, ignoring version. The caller takes responsibility for this, including where filters are present.

If omitted, as-needed applies.

INdiagnostics0..1boolean

If true, the server includes the diagnostic output parameters (performed-expansion, common-codes, missing-codes, extra-codes) where it can. Diagnostics are best-effort and may be omitted.

OUTresult1..1code

The relationship between the first value set ('this') and the second ('other'), stated from the perspective of 'this':

  • same — both value sets contain the same codes;
  • subset — every code in 'this' is in 'other', and 'other' has more;
  • superset — every code in 'other' is in 'this', and 'this' has more;
  • overlapping — each value set contains codes the other does not, but they share some codes;
  • disjoint — the value sets share no codes;
  • empty — both value sets are empty;
  • indeterminate — the server cannot determine the relationship (e.g. a value set has no compose, an expansion is unclosed or infinite, an expansion failed, or the definitions are too complex to compare). The message parameter explains why.
OUTmessage0..1string

A human-readable explanation of the result, suitable for display. Always present for indeterminate and empty, where it gives the reason.

OUTperformed-expansion0..1boolean

Present when diagnostics were requested: true if the server expanded the value sets to determine the result, false if it decided from the definitions alone.

OUTcommon-codes0..1string

Present when diagnostics were requested and the value sets are not identical: a comma-separated list of codes present in both value sets.

OUTmissing-codes0..1string

Present when diagnostics were requested: a comma-separated list of codes present in the first value set ('this') but not the second ('other').

OUTextra-codes0..1string

Present when diagnostics were requested: a comma-separated list of codes present in the second value set ('other') but not the first ('this').