Module generated 

@generated by bash scripts/operation_build.sh - do not edit.

Modules

ActivityDefinitionApply

The apply operation applies a definition in a specific context

ActivityDefinitionDataRequirements

The data-requirements operation aggregates and returns the parameters and data requirements for the activity definition and all its dependencies as a single module definition library

BackportSubscriptionEvents

This operation is used to search for and return notifications that have been previously triggered by a topic-based Subscription in R4.

BackportSubscriptionGetWsBindingToken

This operation is used to get a token for a websocket client to use in order to bind to one or more subscriptions.

BackportSubscriptionResend

This operation is used to resend notifications that have been previously triggered by a topic-based Subscription in R4.

BackportSubscriptionStatus

This operation is used to return the current status information about one or more topic-based Subscriptions in R4.

CapabilityStatementConforms

This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides both capability statements by reference, and must ensure that all the referenced resources are available to the conformance server

CapabilityStatementImplements

This operation asks the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to the canonical URL of its capability statement

CapabilityStatementSubset

This operation asks the server to return a subset of the CapabilityStatement resource - just the REST parts that relate to a set of nominated resources - the resources that the client is interested in

CapabilityStatementVersions

Using the FHIR Version Mime Type Parameter, a server can support multiple versions on the same end-point. The only way for client to find out what versions a server supports in this fashion is the $versions operation. The client invokes the operation with no parameters. and the server returns the list of supported versions, along with the default version it will use if no fhirVersion parameter is present

ChargeItemDefinitionApply

The apply operation applies a definition in a specific context

ClaimSubmit

This operation is used to submit a Claim, Pre-Authorization or Pre-Determination (all instances of Claim resources) for adjudication either as a single Claim resource instance or as a Bundle containing the Claim and other referenced resources, or Bundle containing a batch of Claim resources, either as single Claims resources or Bundle resources, for processing. The only input parameter is the single Claim or Bundle resource and the only output is a single ClaimResponse, Bundle of ClaimResponses or an OperationOutcome resource.

CodeSystemFindMatches

Given a set of properties (and text), return one or more possible matching codes

CodeSystemLookup

Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. One of the products of this operation is a full decomposition of a code from a structured terminology.

CodeSystemSubsumes

Test the subsumption relationship between code/Coding A and code/Coding B given the semantics of subsumption in the underlying code system (see hierarchyMeaning).

CodeSystemValidateCode

Validate that a coded value is in the code system. If the operation is not called at the instance level, one of the parameters “url” or “codeSystem” must be provided. The operation returns a result (true / false), an error message, and the recommended display for the code.

CompositionDocument

A client can ask a server to generate a fully bundled document from a composition resource. The server takes the composition resource, locates all the referenced resources and other additional resources as configured or requested and either returns a full document bundle, or returns an error. Note that since this is a search operation, the document bundle is wrapped inside the search bundle. If some of the resources are located on other servers, it is at the discretion of the server whether to retrieve them or return an error. If the correct version of the document that would be generated already exists, then the server can return the existing one.

ConceptMapClosure

This operation provides support for ongoing maintenance of a client-side transitive closure table based on server-side terminological logic. For details of how this is used, see Maintaining a Closure Table

ConceptMapTranslate

Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server.

CoverageEligibilityRequestSubmit

This operation is used to submit an EligibilityRequest for assessment either as a single EligibilityRequest resource instance or as a Bundle containing the EligibilityRequest and other referenced resources, or Bundle containing a batch of EligibilityRequest resources, either as single EligibilityRequests resources or Bundle resources, for processing. The only input parameter is the single EligibilityRequest or Bundle resource and the only output is a single EligibilityResponse, Bundle of EligibilityResponses or an OperationOutcome resource.

EncounterEverything

This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type “searchset”. At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources it has that: * are included in the encounter compartment for the identified encounter (have a reference to the encounter) * are referenced by the standard extenstion for associating an encounter (where no reference element exists) <http://hl7.org/fhir/StructureDefinition/encounter-associatedEncounter> * the server believes are relevant to the context of the encounter for any other reason (internally defined/decided) * any resource referenced by the above, including binaries and attachments (to make a more complete package) In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see DAF for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)

GroupEverything

This operation is used to return all the information related to one or more patients that are part of the group on which this operation is invoked. The response is a bundle of type “searchset”. At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The intended use for this operation is for a provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in US-Core. Other applicable implementation guides may make additional rules about how much information that is returned.

HasteHealthDeleteRefreshToken

Delete refresh token from the user for the client.

HasteHealthDeleteScope

Delete scope from user accepted scopes for the client.

HasteHealthEvaluatePolicy

Evaluate an Access Policy.

HasteHealthIdpRegistrationInfo

Get the registration information for an identity provider.

HasteHealthImplementationguideInstall

Install FHIR packages (implementation guides) into the current project: their profiles, extensions, ValueSets, CodeSystems, ConceptMaps, NamingSystems and SearchParameters. Name a package to fetch it from the package registry, or upload its .tgz. Each installed package is recorded as an ImplementationGuide whose id is the package name. Installing a package that is already installed replaces it with the version given. Everything is written in one transaction.

HasteHealthImplementationguideUninstall

Uninstall a package that $install installed in the current project: delete the resources it installed and its ImplementationGuide record. Packages it depends on stay installed.

HasteHealthIndexingErrors

Show resources that failed search indexing for the current tenant and project.

HasteHealthListRefreshTokens

Show list of users refresh tokens.

HasteHealthListScopes

Show list of user accepted scopes for apps.

HasteHealthSmartLaunch

Starts a SMART App Launch EHR launch of this client application for a patient, and optionally one of the patient’s encounters. Only a signed-in user can start a launch, and the same user must then authorize the app. Open the returned url to start the app.

HasteHealthTenantBranding

Get the current tenant’s display name and logo, if set.

HasteHealthTenantCustomization

Set display customization for the current tenant, such as its display name and logo.

Hl7v2Parse

Parse HL7v2 messages.

LibraryDataRequirements

The data-requirements operation aggregates and returns the parameters and data requirements for a resource and all its dependencies as a single module definition

ListFind

This operation allows a client to find an identified list for a particular function by its function. The operation takes two parameters, the identity of a patient, and the name of a functional list. The list of defined functional lists can be found at Current Resource Lists. Applications are not required to support all the lists, and may define additional lists of their own. If the system is able to locate a list that serves the identified purpose, it returns it as the body of the response with a 200 OK status. If the resource cannot be located, the server returns a 404 not found (optionally with an OperationOutcome resource)

MeasureCareGaps

The care-gaps operation is used to determine gaps-in-care based on the results of quality measures

MeasureCollectData

The collect-data operation is used to collect the data-of-interest for the given measure.

MeasureDataRequirements

The data-requirements operation aggregates and returns the parameters and data requirements for the measure and all its dependencies as a single module definition

MeasureEvaluateMeasure

The evaluate-measure operation is used to calculate an eMeasure and obtain the results

MeasureSubmitData

The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population

MedicinalProductEverything

This operation is used to return all the information related to one or more products described in the resource or context on which this operation is invoked. The response is a bundle of type “searchset”. At a minimum, the product resource(s) itself is returned, along with any other resources that the server has that are related to the products(s), and that are available for the given user. This is typically the marketing authorisations, ingredients, packages, therapeutic indications and so on. The server also returns whatever resources are needed to support the records

MessageHeaderProcessMessage

This operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more response messages.

NamingSystemPreferredId

This operation returns the preferred identifiers for identifiers, and terminologies. The operation takes 2 parameters:

ObservationLastn

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vitals signs. To ask a server to return the last n=number of observations, the lastn query uses the normal search parameters defined for the Observation resource. However, rather than their normal use, they are interpreted as inputs - i.e.. instead of requiring that the resources literally contain the search parameters, they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches.

ObservationStats

The Statistics operation performs a set of statistical calculations on a set of clinical measurements such as a blood pressure as stored on the server. This operation evaluates Observation resources having valueQuantity elements that have UCUM unit codes. Observations with a status of entered-in-error will be excluded from the calculations. The set of Observations is defined by 4 parameters: * the subject of the observations for which the statistics are being generated (subject) * which observations to generate statistics for (code and system, or coding) * the time period over which to generate statistics ’durationorperiod) * the set of statistical analyses to return (statistic`) Possible statistical analyses (see StatisticsCode): - average (“Average”): The mean of N measurements over the stated period.

PatientEverything

This operation is used to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type “searchset”. At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.

PatientMatch

A Master Patient Index (MPI ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and to store new patient details as they are encountered. MPIs are highly specialized applications, often tailored extensively to the institution’s particular mix of patients. MPIs can also be run on a regional and national basis.

PlanDefinitionApply

The apply operation applies a PlanDefinition to a given context

PlanDefinitionDataRequirements

The data-requirements operation aggregates and returns the parameters and data requirements for the plan definition and all its dependencies as a single module definition library

ProjectInformation

Get Project resource for the current project.

ResourceConvert

This operation takes a resource in one form, and returns to in another form. Both input and output are a single resource. The primary use of this operation is to convert between formats (e.g. (XML -> JSON or vice versa)

ResourceGraph

Return an entire graph of resources based on a GraphDefinition. The operation is invoked on a specific instance of a resource, and the graph definition tells the server what other resources to return in the same packaage

ResourceGraphql

Execute a graphql statement on a since resource or against the entire system. See the Using GraphQL with FHIR page for further details.

ResourceMeta

This operation retrieves a summary of the profiles, tags, and security labels for the given scope; e.g. for each scope:

ResourceMetaAdd

This operation takes a meta, and adds the profiles, tags, and security labels found in it to the nominated resource

ResourceMetaDelete

This operation takes a meta, and deletes the profiles, tags, and security labels found in it from the nominated resource

ResourceValidate

The validate operation checks whether the attached content would be acceptable either generally, as a create, an update or as a delete to an existing resource. The action the server takes depends on the mode parameter:

StructureDefinitionQuestionnaire

Generates a Questionnaire instance based on a specified StructureDefinition, creating questions for each core element or extension element found in the StructureDefinition.

StructureDefinitionSnapshot

Generates a StructureDefinition instance with a snapshot, based on a differential in a specified StructureDefinition.

StructureMapTransform

The transform operation takes input content, applies a structure map transform, and then returns the output.

TenantEndpointInformation

Get tenant endpoint information for the current tenant.

TenantInformation

Get tenant information for the current tenant.

ValueSetExpand

The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation.

ValueSetValidateCode

Validate that a coded value is in the set of codes allowed by a value set.

ViewDefinitionRun

Execute a view definition against supplied or server data.