Example of workflow instance.

An absolute URI that is used to identify this example scenario when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this example scenario is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the example scenario is stored on different servers.

Allows the example scenario to be referenced by a single globally unique identifier.

Can be a urn:uuid: or a urn:oid: but real http: addresses are preferred. Multiple instances may share the same URL if they have a distinct version.

The determination of when to create a new version of a resource (same url, new version) vs. defining a new artifact is up to the author. Considerations for making this decision are found in Technical and Business Versions .

In some cases, the resource can no longer be found at the stated url, but the url itself cannot change. Implementations can use the meta.source element to indicate where the current master source of the resource can be found.

A formal identifier that is used to identify this example scenario when it is represented in other formats, or referenced in a specification, model, design or an instance.

Allows externally provided and/or usable business identifiers to be easily associated with the module.

Typically, this is used for identifiers that can go in an HL7 V3 II (instance identifier) data type, and can then identify this example scenario outside of FHIR, where it is not possible to use the logical URI.

The identifier that is used to identify this version of the example scenario when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the example scenario author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence.

There may be different example scenario instances that have the same identifier but different versions. The version can be appended to the url in a reference to allow a reference to a particular business version of the example scenario with the format [url]|[version].

A natural language name identifying the example scenario. This name should be usable as an identifier for the module by machine processing applications such as code generation.

Support human navigation and code generation.

The name is not expected to be globally unique. The name should be a simple alphanumeric type name to ensure that it is machine-processing friendly.

The status of this example scenario. Enables tracking the life-cycle of the content.

Allows filtering of example scenarios that are appropriate for use versus not.

A Boolean value to indicate that this example scenario is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage.

Enables experimental content to be developed following the same lifecycle that would be used for a production-level example scenario.

Allows filtering of example scenarios that are appropriate for use versus not.

The date (and optionally time) when the example scenario was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the example scenario changes. (e.g. the 'content logical definition').

Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the example scenario. Additional specific dates may be added as extensions or be found by consulting Provenances associated with past versions of the resource.

The name of the organization or individual that published the example scenario.

Helps establish the "authority/credibility" of the example scenario. May also allow for contact.

Usually an organization but may be an individual. The publisher (or steward) of the example scenario is the organization or individual primarily responsible for the maintenance and upkeep of the example scenario. This is not necessarily the same individual or organization that developed and initially authored the content. The publisher is the primary point of contact for questions or issues with the example scenario. This item SHOULD be populated unless the information is available from context.

Contact details to assist a user in finding and communicating with the publisher.

May be a web site, an email address, a telephone number, etc.

The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate example scenario instances.

Assist in searching for appropriate content.

When multiple useContexts are specified, there is no expectation that all or any of the contexts apply.

A legal or geographic region in which the example scenario is intended to be used.

It may be possible for the example scenario to be used in jurisdictions other than those for which it was originally designed or intended.

A copyright statement relating to the example scenario and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the example scenario.

Consumers must be able to determine any legal restrictions on the use of the example scenario and/or its content.

nullFrequently, the copyright differs between the value set and the codes that are included. The copyright statement should clearly differentiate between these when required.

What the example scenario resource is created for. This should not be used to show the business purpose of the scenario itself, but the purpose of documenting a scenario.

This element does not describe the usage of the example scenario. Instead, it provides traceability of ''why'' the resource is either needed or ''why'' it is defined as it is. This may be used to point to source materials or specifications that drove the structure of this example scenario.

Actor participating in the resource.

ID or acronym of actor.

should this be called ID or acronym?

The type of actor - person or system.

The name of the actor as shown in the page.

Cardinality: is name and description 1..1?

The description of the actor.

Cardinality: is name and description 1..1?

Each resource and each version that is present in the workflow.

The id of the resource for referencing.

The type of the resource.

A short name for the resource instance.

Human-friendly description of the resource instance.

A specific version of the resource.

The identifier of a specific version of a resource.

The description of the resource version.

Resources contained in the instance (e.g. the observations contained in a bundle).

Each resource contained in the instance.

A specific version of a resource contained in the instance.

Each major process - a group of operations.

The diagram title of the group of operations.

A longer description of the group of operations.

Description of initial status before the process starts.

Description of final status after the process ends.

Each step of the process.

Nested process.

If there is a pause in the flow.

Each interaction or action.

The sequential number of the interaction, e.g. 1.2.5.

The type of operation - CRUD.

The human-friendly name of the interaction.

Who starts the transaction.

Who receives the transaction.

A comment to be inserted in the diagram.

Whether the initiator is deactivated right after the transaction.

Whether the receiver is deactivated right after the transaction.

Each resource instance used by the initiator.

Each resource instance used by the responder.

Indicates an alternative step that can be taken instead of the operations on the base step in exceptional/atypical circumstances.

The label to display for the alternative that gives a sense of the circumstance in which the alternative should be invoked.

A human-readable description of the alternative explaining when the alternative should occur rather than the base step.

What happens in each alternative option.

Another nested workflow.