Struct CapabilityStatementRestResourceBuilder

pub struct CapabilityStatementRestResourceBuilder { /* private fields */ }

Builder for CapabilityStatementRestResource.

Implementations

impl CapabilityStatementRestResourceBuilder

pub fn id(self, value: String) -> CapabilityStatementRestResourceBuilder

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.

pub fn extension( self, value: Vec<Extension>, ) -> CapabilityStatementRestResourceBuilder

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.

pub fn modifier_extension( self, value: Vec<Extension>, ) -> CapabilityStatementRestResourceBuilder

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.

pub fn type(self, value: String) -> CapabilityStatementRestResourceBuilder

ResourceType; A resource type that is supported

A type of resource exposed via the restful interface.

pub fn type_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn profile(self, value: String) -> CapabilityStatementRestResourceBuilder

System-wide profile

A system-wide profile that is applied across all instances of the resource supported by the system. For example, if declared on Observation, this profile is the “superset” of capabilities for laboratory and vitals and other domains. See further discussion in Using Profiles.

All other profiles for this type that are listed in .rest.resource.supportedProfile must conform to this profile.

pub fn profile_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn supported_profile( self, value: Vec<Option<String>>, ) -> CapabilityStatementRestResourceBuilder

Use-case specific profiles

A list of profiles representing different use cases the system hosts/produces. A supported profile is a statement about the functionality of the data and services provided by the server (or the client) for supported use cases. For example, a system can define and declare multiple Observation profiles for laboratory observations, vital sign observations, etc. By declaring supported profiles, systems provide a way to determine whether individual resources are conformant. See further discussion in Using Profiles.

Supported profiles must conform to the resource profile in the .rest.resource.profile element if it is present. The resource profile is a system-wide profile applied across all instances of the resource supported by the system. A supported profile is a statement about the functionality of the data and services provided by the server (or used by the client) for a particular set of use cases and will not necessarily apply to all data consumed or exposed by the server.

pub fn supported_profile_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn documentation( self, value: String, ) -> CapabilityStatementRestResourceBuilder

Additional information about the use of the resource type

Additional information about the resource type used by the system.

pub fn documentation_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn interaction( self, value: Vec<Option<CapabilityStatementRestResourceInteraction>>, ) -> CapabilityStatementRestResourceBuilder

What operations are supported?

Identifies a restful operation supported by the solution.

In general, a Resource will only appear in a CapabilityStatement if the server actually has some capabilities - e.g. there is at least one interaction supported. However interactions can be omitted to support summarization (_summary = true).

pub fn interaction_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn versioning( self, value: ResourceVersionPolicy, ) -> CapabilityStatementRestResourceBuilder

ResourceVersionPolicy; no-version | versioned | versioned-update

This field is set to no-version to specify that the system does not support (server) or use (client) versioning for this resource type. If this has some other value, the server must at least correctly track and populate the versionId meta-property on resources. If the value is ‘versioned-update’, then the server supports all the versioning features, including using e-tags for version integrity in the API.

If a server supports versionIds correctly, it SHOULD support vread too, but is not required to do so.

pub fn versioning_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn read_history(self, value: bool) -> CapabilityStatementRestResourceBuilder

Whether vRead can return past versions

A flag for whether the server is able to return past versions as part of the vRead operation.

It is useful to support the vRead operation for current operations, even if past versions aren’t available.

pub fn read_history_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn update_create( self, value: bool, ) -> CapabilityStatementRestResourceBuilder

If update can commit to a new identity

A flag to indicate that the server allows or needs to allow the client to create new identities on the server (that is, the client PUTs to a location where there is no existing resource). Allowing this operation means that the server allows the client to create new identities on the server.

Allowing the clients to create new identities on the server means that the system administrator needs to have confidence that the clients do not create clashing identities between them. Obviously, if there is only one client, this won’t happen. While creating identities on the client means that the clients need to be managed, it’s much more convenient for many scenarios if such management can be put in place.

pub fn update_create_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn conditional_create( self, value: bool, ) -> CapabilityStatementRestResourceBuilder

If allows/uses conditional create

A flag that indicates that the server supports conditional create.

Conditional Create is mainly appropriate for interface engine scripts converting from other formats, such as v2.

pub fn conditional_create_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn conditional_read( self, value: ConditionalReadStatus, ) -> CapabilityStatementRestResourceBuilder

ConditionalReadStatus; not-supported | modified-since | not-match | full-support

A code that indicates how the server supports conditional read.

Conditional Read is mainly appropriate for interface engine scripts converting from other formats, such as v2.

pub fn conditional_read_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn conditional_update( self, value: bool, ) -> CapabilityStatementRestResourceBuilder

If allows/uses conditional update

A flag that indicates that the server supports conditional update.

Conditional Update is mainly appropriate for interface engine scripts converting from other formats, such as v2.

pub fn conditional_update_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn conditional_patch( self, value: bool, ) -> CapabilityStatementRestResourceBuilder

If allows/uses conditional patch

A flag that indicates that the server supports conditional patch.

Conditional Patch is mainly appropriate for interface engine scripts converting from other formats, such as v2.

pub fn conditional_patch_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn conditional_delete( self, value: ConditionalDeleteStatus, ) -> CapabilityStatementRestResourceBuilder

ConditionalDeleteStatus; not-supported | single | multiple - how conditional delete is supported

A code that indicates how the server supports conditional delete.

Conditional Delete is mainly appropriate for interface engine scripts converting from other formats, such as v2.

pub fn conditional_delete_ext( self, value: FieldExtension, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn reference_policy( self, value: Vec<Option<ReferenceHandlingPolicy>>, ) -> CapabilityStatementRestResourceBuilder

ReferenceHandlingPolicy; literal | logical | resolves | enforced | local

A set of flags that defines how references are supported.

pub fn reference_policy_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn search_include( self, value: Vec<Option<String>>, ) -> CapabilityStatementRestResourceBuilder

_include values supported by the server

A list of _include values supported by the server.

Documenting _include support helps set conformance expectations for the desired system. Still, it is a level of detail that might not be exposed by production servers or clients when using CapabilityStatement to describe an actual implementation. If this list is empty, the server does not support includes. Support for iterative (a.k.a., recursive) _include is communicated by listing the iterative includes values supported by the server in the searchInclude element of the “root” resource type. For example, to support the following search:

GET [base]/CarePlan?_include=CarePlan:activity-reference:DeviceRequest&_include:iterate=DeviceRequest:device

These values would be listed as part of capabilities for “CarePlan”:

“searchInclude” : [“CarePlan:activity-reference:DeviceRequest”,“DeviceRequest:device”],

pub fn search_include_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn search_rev_include( self, value: Vec<Option<String>>, ) -> CapabilityStatementRestResourceBuilder

_revinclude values supported by the server

A list of _revinclude (reverse include) values supported by the server.

See CapabilityStatement.rest.resource.searchInclude comments.

pub fn search_rev_include_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn search_param( self, value: Vec<Option<CapabilityStatementRestResourceSearchParam>>, ) -> CapabilityStatementRestResourceBuilder

Search parameters supported by implementation

Search parameters for implementations to support and/or make use of - either references to ones defined in the specification, or additional ones defined for/by the implementation.

The search parameters should include the control search parameters such as _sort, _count, etc. that also apply to this resource (though many will be listed at CapabilityStatement.rest.searchParam). The behavior of some search parameters may be further described by other code or extension elements, or narrative within the capability statement or linked SearchParameter definitions.

pub fn search_param_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn operation( self, value: Vec<Option<CapabilityStatementRestResourceOperation>>, ) -> CapabilityStatementRestResourceBuilder

Definition of a resource operation

Definition of an operation or a named query together with its parameters and their meaning and type. Consult the definition of the operation for details about how to invoke the operation, and the parameters.

Operations linked from CapabilityStatement.rest.resource.operation must have OperationDefinition.type = true or OperationDefinition.instance = true.

If an operation that is listed in multiple CapabilityStatement.rest.resource.operation (e.g. for different resource types), then clients should understand that the operation is only supported on the specified resource types, and that may be a subset of those listed in OperationDefinition.resource.

pub fn operation_ext( self, value: Vec<Option<FieldExtension>>, ) -> CapabilityStatementRestResourceBuilder

Extension field.

pub fn build(self) -> Result<CapabilityStatementRestResource, BuilderError>

Builds a new CapabilityStatementRestResource.

Errors

If a required field has not been initialized.

Trait Implementations

impl Default for CapabilityStatementRestResourceBuilder

fn default() -> CapabilityStatementRestResourceBuilder

Returns the “default value” for a type.