Struct ValueSetExpansion 

pub struct ValueSetExpansion {

    pub id: Option<String>,
    pub extension: Vec<Extension>,
    pub modifier_extension: Vec<Extension>,
    pub identifier: Option<String>,
    pub identifier_ext: Option<FieldExtension>,
    pub next: Option<String>,
    pub next_ext: Option<FieldExtension>,
    pub timestamp: DateTime,
    pub timestamp_ext: Option<FieldExtension>,
    pub total: Option<i32>,
    pub total_ext: Option<FieldExtension>,
    pub offset: Option<i32>,
    pub offset_ext: Option<FieldExtension>,
    pub parameter: Vec<Option<ValueSetExpansionParameter>>,
    pub parameter_ext: Vec<Option<FieldExtension>>,
    pub property: Vec<Option<ValueSetExpansionProperty>>,
    pub property_ext: Vec<Option<FieldExtension>>,
    pub contains: Vec<Option<ValueSetExpansionContains>>,
    pub contains_ext: Vec<Option<FieldExtension>>,
}

Sub-fields of the expansion field in ValueSet

Fields

id: Option<String>

Unique id for inter-element referencing

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

extension: Vec<Extension>

Additional content defined by implementations

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

modifier_extension: Vec<Extension>

Extensions that cannot be ignored even if unrecognized

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element’s descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

identifier: Option<String>

Identifies the value set expansion (business identifier)

An identifier that uniquely identifies this expansion of the valueset, based on a unique combination of the provided parameters, the system default parameters, and the underlying system code system versions etc. Systems may re-use the same identifier as long as those factors remain the same, and the expansion is the same, but are not required to do so. This is a business identifier.

Typically, this uri is a UUID (e.g. urn:uuid:8230ff20-c97a-4167-a59d-dc2cb9df16dd).

identifier_ext: Option<FieldExtension>

Extension field.

next: Option<String>

Opaque urls for paging through expansion results

As per paging Search results, the next URLs are opaque to the client, have no dictated structure, and only the server understands them.

Clients SHOULD use the next link, if present, to page through expansion results in preference to using the offset and count parameters. Due to the optional nature of the next link, its absence does not necessarily indicate that it is the last page of results. Instead, as the offset and count parameters SHALL be populated when paging, clients can reliably use the count/offset parameters to determine whether the whole expansion is returned.

next_ext: Option<FieldExtension>

Extension field.

timestamp: DateTime

Time ValueSet expansion happened

The time at which the expansion was produced by the expanding system.

This SHOULD be a fully populated instant, but in some circumstances, value sets are expanded by hand, and the expansion is published without that precision.

timestamp_ext: Option<FieldExtension>

Extension field.

total: Option<i32>

Total number of codes in the expansion

The total number of concepts in the expansion. If the number of concept nodes in this resource is less than the stated number, then the server can return more using the offset parameter.

Paging only applies to flat expansions.

total_ext: Option<FieldExtension>

Extension field.

offset: Option<i32>

Offset at which this resource starts

If paging is being used, the offset at which this resource starts. I.e. this resource is a partial view into the expansion. If paging is not being used, this element SHALL NOT be present.

Paging only applies to flat expansions. If a filter is applied, the count is the number of concepts that matched the filter, not the number of concepts in an unfiltered view of the expansion.

offset_ext: Option<FieldExtension>

Extension field.

parameter: Vec<Option<ValueSetExpansionParameter>>

Parameter that controlled the expansion process

A parameter that controlled the expansion process. These parameters may be used by users of expanded value sets to check whether the expansion is suitable for a particular purpose, or to pick the correct expansion.

The server decides which parameters to include here, but at a minimum, the list SHOULD include all of the parameters that affect the $expand operation. If the expansion will be persisted all of these parameters SHALL be included. If the codeSystem on the server has a specified version then this version SHALL be provided as a parameter in the expansion (note that not all code systems have a version).

parameter_ext: Vec<Option<FieldExtension>>

Extension field.

property: Vec<Option<ValueSetExpansionProperty>>

Additional information supplied about each concept

A property defines an additional slot through which additional information can be provided about a concept.

property_ext: Vec<Option<FieldExtension>>

Extension field.

contains: Vec<Option<ValueSetExpansionContains>>

Codes in the value set

The codes that are contained in the value set expansion.

contains_ext: Vec<Option<FieldExtension>>

Extension field.

Implementations

impl ValueSetExpansion

pub fn builder() -> ValueSetExpansionBuilder

Start building a new instance

Trait Implementations

impl Clone for ValueSetExpansion

fn clone(&self) -> ValueSetExpansion

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ValueSetExpansion

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for ValueSetExpansion

fn deserialize<__D>( __deserializer: __D, ) -> Result<ValueSetExpansion, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for ValueSetExpansion

fn eq(&self, other: &ValueSetExpansion) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for ValueSetExpansion

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for ValueSetExpansion