Generated Narrative: StructureDefinition LabServiceDefinition Name Flags Card. Type Description & Constraints PlanDefinition 0..* PlanDefinition The definition of a plan for a series of actions #xD; Slices for extension 0..* Extension Extension Slice: Unordered, Open by value:url #xD; extension:CatalogReference 0..* Reference(Catalog Header) Reference to a catalog exposing this service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/CatalogReference #xD; extension:ServiceBillingCode 0..* CodeableConcept A billing code associated with the service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/ServiceBillingCode #xD; extension:BillingSummary 0..1 (Complex) Textual summary of billing applied to the service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/BillingSummary #xD; extension:ScheduleSummary 0..1 string Textual summary of the schedule of the service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/ScheduleSummary #xD; extension:LimitationSummary 0..1 string Textual summary of limitations associated with the service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/LimitationSummary #xD; extension:RegulatorySummary 0..1 string Textual summary of regulations applicable to this service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/RegulatorySummary #xD; extension:ResultInterpretationSummary 0..1 markdown markdown summary of result interpretation guidance for this service URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/ResultInterpretationSummary #xD; title #xD; Slices for extension 0..* Extension Extension Slice: Unordered, Open by value:url #xD; extension:OtherTitle 0..* (Complex) Synonym in a specified language URL: http://hl7.org/fhir/StructureDefinition/translation #xD; type S 0..1 CodeableConcept panel | test Binding: Types of diagnostic services performed by a laboratory (extensible) #xD; description 0..1 markdown Natural language description of the plan definition #xD; Slices for extension 0..* Extension Extension Slice: Unordered, Open by value:url #xD; extension:OtherDescription 0..* (Complex) Translation in a specified language URL: http://hl7.org/fhir/StructureDefinition/translation #xD; Slices for useContext S 0..* UsageContext The context that the content is intended to support Slice: Unordered, Open by value:code, type:value, value:value #xD; useContext:Orderable S 0..1 UsageContext Service is orderable #xD; code 1..1 Coding Type of context being specified Required Pattern: At least the following #xD; system 1..1 uri Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/usage-context-type #xD; code 1..1 code Symbol in syntax defined by the system Fixed Value: task #xD; value[x] 1..1 CodeableConcept Value that defines the context Required Pattern: At least the following #xD; useContext:PathologistInitiative S 0..1 UsageContext Service may be added by pathologist #xD; code 1..1 Coding Type of context being specified Required Pattern: At least the following #xD; system 1..1 uri Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/usage-context-type #xD; code 1..1 code Symbol in syntax defined by the system Fixed Value: task #xD; value[x] 1..1 CodeableConcept Value that defines the context Required Pattern: At least the following #xD; useContext:OneGender S 0..1 UsageContext service restricted to one gender #xD; code 1..1 Coding Type of context being specified Required Pattern: At least the following #xD; system 1..1 uri Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/usage-context-type #xD; code 1..1 code Symbol in syntax defined by the system Fixed Value: gender #xD; value[x] 1..1 CodeableConcept Value that defines the context Binding: AdministrativeGender (required) #xD; useContext:StoreSpecimen S 0..1 UsageContext Specimens to be kept #xD; code 1..1 Coding Type of context being specified Required Pattern: At least the following #xD; system 1..1 uri Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/usage-context-type #xD; code 1..1 code Symbol in syntax defined by the system Fixed Value: task #xD; value[x] 1..1 CodeableConcept Value that defines the context Required Pattern: At least the following #xD; useContext:AgeRange S 0..* UsageContext A patient age range applicable for this service #xD; code 1..1 Coding Type of context being specified Required Pattern: At least the following #xD; system 1..1 uri Identity of the terminology system Fixed Value: http://terminology.hl7.org/CodeSystem/usage-context-type #xD; code 1..1 code Symbol in syntax defined by the system Fixed Value: age #xD; value[x] 1..1 Range patient age range applicable for this service #xD; usage S 0..1 markdown Describes the clinical usage of the laboratory diagnostic service #xD; <a href="StructureDefinition-LabServiceDefinition-definitions.html#PlanDefinition.topic" title="Descriptive topics related to the content of the laboratory service definition. Topics provide a high-level categorization of the definition that can be useful for filtering and searching. Some possible axes of categorization include laboratory specialty, kind of pathology, kind of biologic specimen tested, ...">topic S 0..* CodeableConcept categorization of the laboratory service #xD; Slices for relatedArtifact S 0..* RelatedArtifact Additional documentation, citations Slice: Unordered, Open by value:type #xD; relatedArtifact:InputDocumentExpected S 0..* RelatedArtifact Input document expected by the laboratory service #xD; type 1..1 code documentation | justification | citation | predecessor | successor | derived-from | depends-on | composed-of | part-of | amends | amended-with | appends | appended-with | cites | cited-by | comments-on | comment-in | contains | contained-in | corrects | correction-in | replaces | replaced-with | retracts | retracted-by | signs | similar-to | supports | supported-with | transforms | transformed-into | transformed-with | documents | specification-of | created-with | cite-as Required Pattern: depends-on #xD; label 1..1 string Name of the kind of document expected #xD; display 1..1 string Brief description of the related artifact #xD; document 0..1 Attachment Document model #xD; url 0..1 url url of the model of document expected #xD; title 0..1 string Title of the kind or model of document #xD; relatedArtifact:IsReplacedBy S 0..* RelatedArtifact Reference to a service replacing the current non-usable one #xD; type 1..1 code documentation | justification | citation | predecessor | successor | derived-from | depends-on | composed-of | part-of | amends | amended-with | appends | appended-with | cites | cited-by | comments-on | comment-in | contains | contained-in | corrects | correction-in | replaces | replaced-with | retracts | retracted-by | signs | similar-to | supports | supported-with | transforms | transformed-into | transformed-with | documents | specification-of | created-with | cite-as Required Pattern: successor #xD; resource 1..1 canonical(Laboratory Service Definition) What artifact is being referenced #xD; relatedArtifact:Includes S 0..* RelatedArtifact Reference to a panel or test included by the current one #xD; type 1..1 code documentation | justification | citation | predecessor | successor | derived-from | depends-on | composed-of | part-of | amends | amended-with | appends | appended-with | cites | cited-by | comments-on | comment-in | contains | contained-in | corrects | correction-in | replaces | replaced-with | retracts | retracted-by | signs | similar-to | supports | supported-with | transforms | transformed-into | transformed-with | documents | specification-of | created-with | cite-as Required Pattern: composed-of #xD; resource 1..1 canonical(Laboratory Service Definition) What artifact is being referenced #xD; relatedArtifact:Bibliography S 0..* RelatedArtifact Additional documentation, citation or justification #xD; type 1..1 code documentation | justification | citation Binding: Types of bibliographic artifacts (required) #xD; action 1..1 BackboneElement Action defined by the plan #xD; Slices for extension 0..* Extension Extension Slice: Unordered, Open by value:url #xD; extension:SpecimenRequested 0..* (Complex) Specimens required for this action URL: http://hl7.org/fhir/uv/order-catalog/StructureDefinition/SpecimenRequested #xD; description 0..1 markdown Brief description of the laboratory service and its method #xD; priority 0..1 code routine | urgent | asap | stat #xD; code S 0..1 CodeableConcept Code of the laboratory service #xD; Slices for coding 0..* Coding Code for the laboratory service Slice: Unordered, Open by value:system #xD; coding:orderCodeLOINC S 0..1 Coding LOINC code for the laboratory service #xD; system S 0..1 uri LOINC code system Required Pattern: http://loinc.org #xD; Slices for trigger S 0..* TriggerDefinition When the action should be triggered Slice: Unordered, Open by value:type #xD; trigger:Reflex S 0..* TriggerDefinition Reflex laboratory procedure #xD; type 1..1 code named-event | periodic | data-changed | data-added | data-modified | data-removed | data-accessed | data-access-ended Required Pattern: named-event #xD; name 1..1 string Name or URI that identifies the event #xD; groupingBehavior 0..1 code visual-group | logical-group | sentence-group Required Pattern: logical-group #xD; definition[x] S 0..1 canonical(Laboratory Procedure Definition) Description of the activity to be performed #xD; Documentation for this format
HL7 International / Orders and Observations
The LabServiceDefinition profile constrains the PlanDefinition resource to represent a laboratory diagnostic service for the clinicians using such services. Clinicians typically order laboratory services and use the results thereof in the course of their delivery of clinical care. A laboratory diagnostic service is a kind of clinical artifact that falls within the scope of PlanDefinition. It involves preparation of the patient, collection and delivery to the lab of biological/digital specimens , tests and panels performed on these specimens, interpretation of the results by the pathologist, and delivery of the results and diagnostic report back to the ordering clinician and possibly other recipients, including the patient. PlanDefinition conveys the general properties of the lab service. It describes the usage of the service, the contexts and situations in which this service is useful, and may also detail the goals that the laboratory service contributes to, such as screening or diagnostic of a particular pathology, monitoring of a long course treatment ... An instance of PlanDefintion, thus, represents a laboratory service. It references one or more instances of ActivityDefinition, describing the service in terms of laboratory procedures, with their input and output observations. The PlanDefinition also references the instances of SpecimenDefinition representing the kinds of specimens needed to perform the service. A service may be a panel or super-panel grouping other laboratory services that may also be ordered independently. In that case, the PlanDefinition of the encompassing service references the PlanDefinition resources representing the included services (relatedArtifact, type composed-of). Reflex tests are represented as sub-actions grouped in a logical group with behavior any, meaning that any number of members of the group may be performed. Each sub-action is associated with a trigger conveying the named event, which reflexes it. A definition of a laboratory diagnostic service conforming to this profile can be used in a laboratory compendium/catalog as well as in other contexts. A laboratory service is fulfilled through the execution of one or more laboratory procedures. The logical combinations of these procedures may be conjunctions (execute each of them) or disjunctions (execute at most one of them), or a mixture of both logical structures. The closest resource that may represent a service as a set of activities logically combined with this flexibility is PlanDefinition. PlanDefinition is therefore selected to represent a laboratory service, and the laboratory procedures needed to achieve this service are represented by instances of ActivityDefinition referenced by PlanDefinition, from logical groups defined in PlanDefinition.
The definition of a plan for a series of actions
This resource allows for the definition of various types of plans as a sharable, consumable, and executable artifact. The resource is general enough to support the description of a broad range of clinical and non-clinical artifacts such as clinical decision support rules, order sets, protocols, and drug quality specifications.
The LabServiceDefinition profile constrains the resource PlanDefinition to represent a laboratory diagnostic service made visible to clinicians: the potential consumers of this service.
Name should be usable as an identifier for the module by machine processing applications such as code generation
name.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
goalid should reference the id of a goal definition
%context.repeat(action).where((goalId in %context.goal.id).not()).exists().not()
targetId should reference the id of an action
%context.repeat(action).relatedAction.where((targetId in %context.repeat(action).id).not()).exists().not()
The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
Within the context of the FHIR RESTful interactions, the resource has an id except for cases like the create and conditional update. Otherwise, the use of the resouce id depends on the given use case.
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
A set of rules under which this content was created
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of its narrative along with other profiles, value sets, etc.
This element is labeled as a modifier because the implicit rules may provide additional knowledge about the resource that modifies its meaning or interpretation
The base language in which the resource is written.
Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
Text summary of the resource, for human interpretation
A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Contained resources do not have a narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, nor can they have their own independent transaction scope. This is allowed to be a Parameters resource if and only if it is referenced by a resource that provides context/meaning.
This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags in their meta elements, but SHALL NOT have security labels.
Must have either extensions or value[x], not both
Reference to a catalog exposing this service
This extension to PlanDefinition, MedicationKnowledge and DeviceDefinition conveys the reference to a catalog containing the extended resource
A billing code associated with the service
Optional Extension Element - found in all resources.
Textual summary of billing applied to the service
Textual summary of the schedule of the service
Textual summary of limitations associated with the service
Textual summary of regulations applicable to this service
markdown summary of result interpretation guidance for this service
May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it 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 is allowed to 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.
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R5/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the resource that contains them
Canonical identifier for this plan definition, represented as a URI (globally unique)
An absolute URI that is used to identify this plan definition 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 an authoritative instance of this plan definition is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the plan definition is stored on different servers.
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](http://hl7.org/fhir/R5/resource.html#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](http://hl7.org/fhir/R5/resource.html#meta) element to indicate where the current master source of the resource can be found.
Allows the plan definition to be referenced by a single globally unique identifier.
URL should not contain | or # - these characters make processing canonical references problematic
Additional identifier for the plan definition
A formal identifier that is used to identify this plan definition when it is represented in other formats, or referenced in a specification, model, design or an instance.
Typically, this is used for identifiers that can go in an HL7 V3 II (instance identifier) data type, and can then identify this plan definition outside of FHIR, where it is not possible to use the logical URI.
Allows externally provided and/or usable business identifiers to be easily associated with the module.
The identifier that is used to identify this version of the plan definition when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the plan definition 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. To provide a version consistent with the Decision Support Service specification, use the format Major.Minor.Revision (e.g. 1.0.0). For more information on versioning knowledge assets, refer to the Decision Support Service specification. Note that a version is required for non-experimental active artifacts.
There may be different plan definition 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 plan definition with the format [url]|[version]. The version SHOULD NOT contain a '#' - see [Business Version](http://hl7.org/fhir/R5/resource.html#bv-format).
Indicates the mechanism used to compare versions to determine which is more current.
If set as a string, this is a FHIRPath expression that has two additional context variables passed in - %version1 and %version2 and will return a negative number if version1 is newer, a positive number if version2 and a 0 if the version ordering can't be successfully be determined.
Name for this plan definition (computer friendly)
A natural language name identifying the plan definition. This name should be usable as an identifier for the module by machine processing applications such as 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.
Support human navigation and code generation.
Name for this plan definition (human friendly)
A short, descriptive, user-friendly title for the plan definition.
This name does not need to be machine-processing friendly and may contain punctuation, white-space, etc.
unique id for the element within a resource (for internal references)
Expresses a synonym of the laboratory service in a specified language
Subordinate title of the plan definition
An explanatory or alternate title for the plan definition giving additional information about its content.
A high-level category for the plan definition that distinguishes the kinds of systems that would be interested in the plan definition.
In this LabServiceDefiniton profile, PlanDefinition represents a laboratory service, which can be either a test or a panel. A test is a single measurement performed on a material/digital specimen, producing generally one result (sometimes zero, sometime more). A panel is a collection of tests and panels, performed on one or more material/digital specimens, and producing a collection of results. Therefore, the type is bound to a value set {"test", "panel"}. The original value bound to this element with binding strength "extensible" does not contain appropriate values for laboratory diagnostic services.
The status of this plan definition. Enables tracking the life-cycle of the content.
Allows filtering of plan definitions that are appropriate for use versus not. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
This is labeled as "Is Modifier" because applications should not use a retired {{title}} without due consideration
A Boolean value to indicate that this plan definition is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage.
Allows filtering of plan definitions that are appropriate for use versus not.
Enables experimental content to be developed following the same lifecycle that would be used for a production-level plan definition.
If absent, this resource is treated as though it is not experimental.
Type of individual the plan definition is focused on
A code, group definition, or canonical reference that describes or identifies the intended subject of the plan definition. Canonical references are allowed to support the definition of protocols for drug and substance quality specifications, and is allowed to reference a MedicinalProductDefinition, SubstanceDefinition, AdministrableProductDefinition, ManufacturedItemDefinition, or PackagedProductDefinition resource.
Note that the choice of canonical for the subject element was introduced in R4B to support pharmaceutical quality use cases. To ensure as much backwards-compatibility as possible, it is recommended to only use the new canonical type with these use cases.
The possible types of subjects for a plan definition (E.g. Patient, Practitioner, Organization, Location, etc.).
The date (and optionally time) when the plan definition was last significantly changed. 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 plan definition changes.
The date is often not tracked until the resource is published, but may be present on draft content. Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the plan definition. Additional specific dates may be added as extensions or be found by consulting Provenances associated with past versions of the resource. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
Name of the publisher/steward (organization or individual)
The name of the organization or individual responsible for the release and ongoing maintenance of the plan definition.
Usually an organization but may be an individual. The publisher (or steward) of the plan definition is the organization or individual primarily responsible for the maintenance and upkeep of the plan definition. 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 plan definition. This item SHOULD be populated unless the information is available from context.
Helps establish the "authority/credibility" of the plan definition. May also allow for contact.
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. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
Natural language description of the plan definition
A free text natural language description of the plan definition from a consumer's perspective.
This description provides details such as when this laboratory diagnostic service can be ordered, comments about misuse, instructions for clinical use and interpretation, literature references, examples from the paper world, etc. It is not a rendering of the plan definition as conveyed in the 'text' field of the resource itself. This item SHOULD be populated unless the information is available from context (e.g. the language of the plan definition is presumed to be the predominant language in the place the plan definition was created).
Translation of the description of the laboratory service in a specified language
The context that the content is intended to support
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 plan definition instances.
When multiple useContexts are specified, in this LabServiceDefinition profile, all contexts apply to the defined laboratory service.
Assist in searching for appropriate content.
The presence of this slice indicates that the service is open to laboratory order entry
When multiple useContexts are specified, there is no expectation that all or any of the contexts apply.
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
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.
A code that identifies the type of context being specified by this usage context.
A code that specifies a type of context being specified by a usage context.
A value that defines the context specified in this context of use. The interpretation of the value is defined by the code.
A code that defines the specific value for the context being specified.
The presence of this slice indicates that the service may be added to an existing order by the pathologist after review of the preliminary results of this order
The presence of this slice indicates that the service is restricted to one gender of subject (female or male)
The presence of this slice indicates that the specimens used to perform this service will be kept in long-time storage and available for re-testing in the future
A patient age range applicable for this service
patient age range applicable for this service
Intended jurisdiction for plan definition (if applicable)
A legal or geographic region in which the plan definition is intended to be used.
It may be possible for the plan definition to be used in jurisdictions other than those for which it was originally designed or intended. DEPRECATION NOTE: For consistency, implementations are encouraged to migrate to using the new 'jurisdiction' code in the useContext element. (I.e. useContext.code indicating http://terminology.hl7.org/CodeSystem/usage-context-type#jurisdiction and useContext.valueCodeableConcept indicating the jurisdiction.)
Countries and regions within which this artifact is targeted for use.
Explanation of why this plan definition is needed and why it has been designed as it has.
This element does not describe the usage of the plan definition. 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 plan definition.
Describes the clinical usage of the laboratory diagnostic service
A detailed description of how the laboratory diagnostic service is used from a clinical perspective.
A copyright statement relating to the plan definition and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the plan definition.
The short copyright declaration (e.g. (c) '2015+ xyz organization' should be sent in the copyrightLabel element.
Consumers must be able to determine any legal restrictions on the use of the plan definition and/or its content.
A short string (<50 characters), suitable for inclusion in a page footer that identifies the copyright holder, effective period, and optionally whether rights are resctricted. (e.g. 'All rights reserved', 'Some rights reserved').
The (c) symbol should NOT be included in this string. It will be added by software when rendering the notation. Full details about licensing, restrictions, warrantees, etc. goes in the more general 'copyright' element.
Defines the content expected to be rendered in all representations of the artifact.
When the plan definition was approved by publisher
The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage.
The 'date' element may be more recent than the approval date because of minor changes or editorial corrections. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
When the plan definition was last reviewed by the publisher
The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date.
If specified, this date follows the original approval date. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
Gives a sense of how "current" the content is. Resources that have not been reviewed in a long time may have a risk of being less appropriate/relevant.
.outboundRelationship[typeCode="SUBJ"; subsetCode="RECENT"].act[classCode=CACT;moodCode=EVN;code="review"].effectiveTime
When the plan definition is expected to be used
The period during which the plan definition content was or is planned to be in active use.
The effective period for a plan definition determines when the content is applicable for usage and is independent of publication and review dates. For example, a plan definition intended to be used for the year 2016 might be published in 2015. See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
Allows establishing a transition before a resource comes into effect and also allows for a sunsetting process when new versions of the plan definition are or are expected to be used instead.
categorization of the laboratory service
Descriptive topics related to the content of the laboratory service definition. Topics provide a high-level categorization of the definition that can be useful for filtering and searching. Some possible axes of categorization include laboratory specialty, kind of pathology, kind of biologic specimen tested, ...
Topics are usually chosen by the laboratory or the organization owning the catalog
Repositories must be able to determine how to categorize the plan definition so that it can be found by topical searches.
High-level categorization of the definition, used for searching, sorting, and filtering.
An individiual or organization primarily involved in the creation and maintenance of the content.
An individual or organization primarily responsible for internal coherence of the content.
An individual or organization asserted by the publisher to be primarily responsible for review of some aspect of the content.
See guidance around (not) making local changes to elements [here](http://hl7.org/fhir/R5/canonicalresource.html#localization).
.participation[typeCode=VRF] {not clear whether VRF best corresponds to reviewer or endorser}
An individual or organization asserted by the publisher to be responsible for officially endorsing the content for use in some setting.
A laboratory service definition may have related artifacts of three kinds: 1- documents expected from the ordering party when ordering this laboratory service. This kind is represented by the slice InputExpected, which is the only slice defined for this element. Example: Patient consent for genetic testing. 2- any kind of bibliography, justification, documentation. 3- replacement of the no longer usable current service, by another one.
Related artifacts such as additional documentation, justification, or bibliographic references.
Each related artifact is either an attachment, or a reference to another resource, but not both.
Plan definitions must be able to provide enough information for consumers of the content (and/or interventions or results produced by the content) to be able to determine and understand the justification for and evidence in support of the content.
.outboundRelationship[typeCode=DOC,RSON,PREV, DRIV, USE, COMP] {successor would be PREV w/ inversionInd=true; No support for citation}
Input document expected by the laboratory service
Document that needs to be provided alongside the order for the laboratory service
Examples of documents that should accompany an order for this service include patient consent for genetic testing, patient agreement for payment of a non-reimbursable service, insurance formal acceptation of a specific test (e.g. prenatal karyotyping) ...
documentation | justification | citation | predecessor | successor | derived-from | depends-on | composed-of | part-of | amends | amended-with | appends | appended-with | cites | cited-by | comments-on | comment-in | contains | contained-in | corrects | correction-in | replaces | replaced-with | retracts | retracted-by | signs | similar-to | supports | supported-with | transforms | transformed-into | transformed-with | documents | specification-of | created-with | cite-as
The type of relationship to the related artifact.
The presence of both sides of a relationship type (e.g. successor and predecessor) is required to support use cases where one side of a relationship is not represented in FHIR. However, this feature SHALL NOT be used to create bi-directional resource links in FHIR instances. Specifically, following the methodology of "new points to old" and "many points to one", when using related artifact elements to describe and reference FHIR resources, the type element SHALL be drawn from the fhir-related-artifact-type ValueSet.
Provides additional classifiers of the related artifact.
Additional classifiers for the related artifact.
Various kinds (or models) of documents may be expected as input to a laboratory service. This element provides an unambiguous short name for such a kind of document.
Examples of kinds of documents expected include: - the paper lab order scanned - the statement of acceptation of the service by the insurance provider (e.g. for a prenatal karyotyping) - the patient consent (e.g. for a genetic test) - the patient insurance affiliation scanned
Brief description of the related artifact
A brief description of the document that need to be provided alongside the order of this laboratory service
A bibliographic citation for the related artifact. This text SHOULD be formatted according to an accepted citation format.
Additional structured information about citations should be captured as extensions.
provides in the attachment a model for the kind of document expected
The model can be encoded in base64 in the data sub-element, with its mime type encoded in the contentType sub-element, or it can be external, accessible through the url sub-element.
Mime type of the content, with charset etc.
Identifies the type of the data in the attachment and allows a method to be chosen to interpret or render the data. Includes mime type parameters such as charset where appropriate.
Processors of the data need to be able to know how to interpret the data.
ED.2+ED.3/RP.2+RP.3. Note conversion may be needed if old style values are being used
The human language of the content. The value can be any valid value according to BCP 47.
Users need to be able to choose between the languages in a set of attachments.
The actual data of the attachment - a sequence of bytes, base64 encoded.
The base64-encoded data SHALL be expressed in the same character set as the base resource XML or JSON.
The data needs to able to be transmitted inline.
used if the model of document is accessible externally
If both data and url are provided, the url SHALL point to the same content as the data contains. Urls may be relative references or may reference transient locations such as a wrapping envelope using cid: though this has ramifications for using signatures. Relative URLs are interpreted relative to the service url, like a resource reference, rather than relative to the resource itself. If a URL is provided, it SHALL resolve to actual data.
The data needs to be transmitted by reference.
RP.1+RP.2 - if they refer to a URL (see v2.6)
Number of bytes of content (if url provided)
The number of bytes of data that make up this attachment (before base64 encoding, if that is done).
The number of bytes is redundant if the data is provided as a base64binary, but is useful if the data is provided as a url reference.
Representing the size allows applications to determine whether they should fetch the content automatically in advance, or refuse to fetch it at all.
The calculated hash of the data using SHA-1. Represented using base64.
The hash is calculated on the data prior to base64 encoding, if the data is based64 encoded. The hash is not intended to support digital signatures. Where protection against malicious threats a digital signature should be considered, see [Provenance.signature](http://hl7.org/fhir/R5/provenance-definitions.html#Provenance.signature) for mechanism to protect a resource with a digital signature.
Included so that applications can verify that the contents of a location have not changed due to technical failures (e.g., storage rot, transport glitch, incorrect version).
May be sufficient to specify the document expected, in cases where no pre-defined needs to be communicated to the orderer of the service.
May sometimes be derived from the source filename.
Applications need a label to display to a human user in place of the actual data if the data cannot be rendered or perceived by the viewer.
The date that the attachment was first created.
This is often tracked as an integrity issue for use of the attachment.
Height of the image in pixels (photo/video)
Height of the image in pixels (photo/video).
.outboundRelationship[typeCode="COMP].target[classCode="OBS", moodCode="EVN",code="<CODE>"].value
Width of the image in pixels (photo/video)
Width of the image in pixels (photo/video).
The number of frames in a photo. This is used with a multi-page fax, or an imaging acquisition context that takes multiple slices in a single image, or an animated gif. If there is more than one frame, this SHALL have a value in order to alert interface software that a multi-frame capable rendering widget is required.
if the number of frames is not supplied, the value may be unknown. Applications should not assume that there is only one frame unless it is explicitly stated.
The duration of the recording in seconds - for audio and video.
The duration might differ from occurrencePeriod if recording was paused.
The related artifact, such as a library, value set, profile, or other knowledge resource.
If the type is predecessor, this is a reference to the succeeding knowledge resource. If the type is successor, this is a reference to the prior knowledge resource.
What artifact, if not a conformance resource
The related artifact, if the artifact is not a canonical resource, or a resource reference to a canonical resource.
If both resource and resourceReference are present, they SHOULD be consistent and reference the same resource. Although relatedArtifact is intended to support references to definitional resources, there are cases where non-definitional resources can be definitional (such as Location where the kind is mode). Related artifacts SHOULD be used to reference definitional resources, and profiles SHOULD be used to make that explicit for particular use cases.
The publication status of the artifact being referred to.
Publication status of an artifact being referred to.
Date of publication of the artifact being referred to
The date of publication of the artifact being referred to.
Reference to a service replacing the current non-usable one
The related artifact is another instance of PlanDefinition, which is a replacement for the current no longer usable laboratory service
The type of relationship to the related artifact is successor, meaning that the related artifact is in this case another instance of PlanDefinition representing the laboratory service, which is substituted to the current instance.
A short label that can be used to reference the citation from elsewhere in the containing artifact, such as a footnote index.
A brief description of the document or knowledge resource being referenced, suitable for display to a consumer.
The document being referenced, represented as an attachment. This is exclusive with the resource element.
The related resource, in this case a PlanDefinition constrained by the LabServiceDefinition profile
Reference to a panel or test included by the current one
The related artifact is another instance of PlanDefinition, representing a laboratory service orderable on its own, and which is also part of the current one, either systematically or reflexed by a trigger.
The type of relationship to the related artifact is composed-of, meaning that the related artifact is another standalone laboratory service, which is also included as a sub-service of the current one.
Additional documentation, citation or justification
Related bibliographic references such as documentation, justification, or citation.
documentation | justification | citation
kind of associated bibliographic artifact
A reference to a Library resource containing any formal logic used by the plan definition.
A goal describes an expected outcome that activities within the plan are intended to achieve. For example, weight loss, restoring an activity of daily living, obtaining herd immunity via immunization, meeting a process improvement objective, meeting the acceptance criteria for a test as specified by a quality specification, etc.
Goal information needs to be captured for order sets, protocols, and care plan definitions to better describe the objectives of the protocol activities and to guide the creation of specific goals within the derived care plans and orders.
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).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Indicates a category the goal falls within.
Example codes for grouping goals for filtering or presentation.
Human-readable and/or coded description of a specific desired objective of care, such as "control blood pressure" or "negotiate an obstacle course" or "dance with child at wedding".
If no code is available, use CodeableConcept.text.
high-priority | medium-priority | low-priority
Identifies the expected level of importance associated with reaching/sustaining the defined goal.
Indicates the level of importance associated with reaching or sustaining a goal.
The event after which the goal should begin being pursued.
Identifies the types of events that might trigger the start of a goal.
Identifies problems, conditions, issues, or concerns the goal is intended to address.
Identifies problems, conditions, issues, or concerns that goals may address.
Didactic or other informational resources associated with the goal that provide further supporting information about the goal. Information resources can include inline text commentary and links to web resources.
Indicates what should be done and within what timeframe.
The parameter whose value is to be tracked
The parameter whose value is to be tracked, e.g. body weight, blood pressure, or hemoglobin A1c level.
Identifies types of parameters that can be tracked to determine goal achievement.
The target value of the measure to be achieved to signify fulfillment of the goal, e.g. 150 pounds or 7.0%, or in the case of pharmaceutical quality - NMT 0.6%, Clear solution, etc. Either the high or low or both values of the range can be specified. When a low value is missing, it indicates that the goal is achieved at any value at or below the high value. Similarly, if the high value is missing, it indicates that the goal is achieved at any value at or above the low value.
A CodeableConcept with just a text would be used instead of a string if the field was usually coded, or if the type associated with the goal.target.measure defines a coded value.
Indicates the timeframe after the start of the goal in which the goal should be met.
Actors represent the individuals or groups involved in the execution of the defined set of activities.
A description of how the actor fits into the overall actions of the plan definition.
The characteristics of the candidates that could serve as the actor.
careteam | device | group | healthcareservice | location | organization | patient | practitioner | practitionerrole | relatedperson
The type of participant in the activity.
When this element is a reference, it SHOULD be a reference to a definitional resource (for example, a location type, rather than a specific location).
The role the participant should play in performing the described action.
The concrete action or group of actions conveyed by this laboratory diagnostic service
The LabServiceDefinition profile constrains the content of PlanDefinition to be a single action at the top level. This action may be implemented by a single laboratory procedure referenced as an instance of ActivityDefinition, or may be decomposed into any level of logical groups of more granular actions, each leaf action referencing an ActivityDefinition.
A set of specimens requested as input by this laboratory service. The set is organized as a collection of one or more alternative groups (exactly one group should be chosen at specimen collection time). Each group describes one or more specimens that must all be provided, in case this group is the one chosen.
In case this element has multiple occurrence, all occurrences apply: Each set of specimen requirements represented by an occurrence of action.extension:SpecimenRequested must be fulfilled for the service described by the PlanDefinition instance.
Unique id for the action in the PlanDefinition
An identifier that is unique within the PlanDefinition to allow linkage within the realized CarePlan and/or RequestOrchestration.
User-visible prefix for the action (e.g. 1. or A.)
A user-visible prefix for the action. For example a section or item numbering such as 1. or A.
The textual description of the action displayed to a user. For example, when the action is a test to be performed, the title would be the title of the test such as Assay by HPLC.
Brief description of the laboratory service and its method
A brief description of the laboratory service, which may mention the analytical method(s) used by the laboratory
Static text equivalent of the action, used if the dynamic aspects cannot be interpreted by the receiving system
A text equivalent of the action to be performed. This provides a human-interpretable description of the action when the definition is consumed by a system that might not be capable of interpreting it dynamically.
Indicates how quickly this diagnostic panel or test should be performed.
Identifies the level of importance to be assigned to actioning the request.
A code that provides meaning to the laboratory service
Provides examples of actions to be performed.
A reference to a code defined by a terminology system.
Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.
Allows for alternative encodings within a code system, and translations to other code systems.
fhir:CodeableConcept.coding rdfs:subPropertyOf dt:CD.coding
The identification of the code system that defines the meaning of the symbol in the code.
The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should be an absolute reference to some definition that establishes the system clearly and unambiguously.
Need to be unambiguous about the source of the definition of the symbol.
fhir:Coding.system rdfs:subPropertyOf dt:CDCoding.codeSystem
The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured, and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.
Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.
fhir:Coding.version rdfs:subPropertyOf dt:CDCoding.codeSystemVersion
A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).
Need to refer to a particular code in the system.
fhir:Coding.code rdfs:subPropertyOf dt:CDCoding.code
A representation of the meaning of the code in the system, following the rules of the system.
Need to be able to carry a human-readable meaning of the code for readers that do not know the system.
C*E.2 - but note this is not well followed
fhir:Coding.display rdfs:subPropertyOf dt:CDCoding.displayName
If this coding was chosen directly by the user
Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).
Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.
This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.
fhir:Coding.userSelected fhir:mapsTo dt:CDCoding.codingRationale. fhir:Coding.userSelected fhir:hasMap fhir:Coding.userSelected.map. fhir:Coding.userSelected.map a fhir:Map; fhir:target dt:CDCoding.codingRationale. fhir:Coding.userSelected\#true a [ fhir:source "true"; fhir:target dt:CDCoding.codingRationale\#O ]
Plain text representation of the concept
A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.
Very often the text is the same as a displayName of one of the codings.
The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.
C*E.9. But note many systems use C*E.2 for this
fhir:CodeableConcept.text rdfs:subPropertyOf dt:CD.originalText
A description of why this action is necessary or appropriate.
This is different than the clinical evidence documentation, it's an actual business description of the reason for performing the action.
Provides examples of reasons for actions to be performed.
Supporting documentation for the intended performer of the action
Didactic or other informational resources associated with the action that can be provided to the CDS recipient. Information resources can include inline text commentary and links to web resources.
Identifies goals that this action supports. The reference must be to a goal element defined within this plan definition. In pharmaceutical quality, a goal represents acceptance criteria (Goal) for a given action (Test), so the goalId would be the unique id of a defined goal element establishing the acceptance criteria for the action.
Type of individual the action is focused on
A code, group definition, or canonical reference that describes the intended subject of the action and its children, if any. Canonical references are allowed to support the definition of protocols for drug and substance quality specifications, and is allowed to reference a MedicinalProductDefinition, SubstanceDefinition, AdministrableProductDefinition, ManufacturedItemDefinition, or PackagedProductDefinition resource.
The subject of an action overrides the subject at a parent action or on the root of the PlanDefinition if specified. In addition, because the subject needs to be resolved during realization, use of subjects in actions (or in the ActivityDefinition referenced by the action) resolves based on the set of subjects supplied in context and by type (i.e. the patient subject would resolve to a resource of type Patient).
Multiple steps in a protocol often have different groups of steps that are focused on testing different things. The subject of an action specifies the focus of the action and any child actions.
Open slicing on trigger with a single slice defined to represent a reflex activity.
A description of when the action should be triggered. When multiple triggers are specified on an action, any triggering event invokes the action.
This trigger introduces a reflex laboratory procedure (test or panel) represended by the ActivityDefinition referenced by the action.definition. The trigger is expressed as a named event, and may also be refined with a data requirement and a condition.
named-event | periodic | data-changed | data-added | data-modified | data-removed | data-accessed | data-access-ended
The natural language expression of the trigger for the reflex laboratory procedure
An event name can be provided for all event types, but is required for named events. If a name is provided for a type other than named events, it is considered to be a shorthand for the semantics described by the formal description of the event.
A reference to a SubscriptionTopic resource that defines the event. If this element is provided, no other information about the trigger definition may be supplied.
The timing of the event (if this is a periodic trigger).
Triggering data of the event (multiple = 'and')
The triggering data of the event (if this is a data trigger). If more than one data is requirement is specified, then all the data requirements must be true.
This element shall be present for any data type trigger.
Whether the event triggers (boolean expression)
A boolean-valued expression that is evaluated in the context of the container of the trigger definition and returns whether or not the trigger fires.
This element can be only be specified for data type triggers and provides additional semantics for the trigger. The context available within the condition is based on the type of data event. For all events, the current resource will be available as context. In addition, for modification events, the previous resource will also be available. The expression may be inlined, or may be a simple absolute URI, which is a reference to a named expression within a logic library referenced by a library element or extension within the containing resource. If the expression is a FHIR Path expression, it evaluates in the context of a resource of one of the type identified in the data requirement, and may also refer to the variable %previous for delta comparisons on events of type data-changed, data-modified, and data-deleted which will always have the same type.
Need to be able to formally describe the triggering criteria.
An expression that describes applicability criteria or start/stop conditions for the action.
When multiple conditions of the same kind are present, the effects are combined using AND semantics, so the overall condition is true only if all the conditions are true.
Applicability criteria are used to determine immediate applicability when a plan definition is applied to a given context. Start and stop criteria are carried through application and used to describe enter/exit criteria for an action.
Defines the kinds of conditions that can appear on actions.
An expression that returns true or false, indicating whether the condition is satisfied.
The expression may be inlined or may be a reference to a named expression within a logic library referenced by the library element.
Defines input data requirements for the action.
Input data elements must have a requirement or a relatedData, but not both
requirement.exists() xor relatedData.exists()
A human-readable label for the data requirement used to label data flows in BPMN or similar diagrams. Also provides a human readable label when rendering the data requirement that conveys its purpose to human readers.
Defines the data that is to be provided as input to the action.
Points to an existing input or output element that provides data to this input.
The relatedData element allows indicating that an input to a parent action is an input to specific child actions. It also allows the output of one action to be identified as the input to a different action
Defines the outputs of the action, if any.
Output data element must have a requirement or a relatedData, but not both
Defines the data that results as output from the action.
Points to an existing input or output element that is results as output from the action.
The relatedData element allows indicating that the output of child action is also the output of a parent action. It also allows the input of one action to be identified as the output of a different action
A relationship to another action such as "before" or "30-60 minutes after start of".
When an action depends on multiple actions, the meaning is that all actions are dependencies, rather than that any of the actions are a dependency.
The element id of the target related action.
before | before-start | before-end | concurrent | concurrent-with-start | concurrent-with-end | after | after-start | after-end
The relationship of the start of this action to the related action.
Defines the types of relationships between actions.
The relationship of the end of this action to the related action.
A duration or range of durations to apply to the relationship. For example, 30-60 minutes before.
An optional value describing when the action should be performed.
The intent of the timing element is to provide timing when the action should be performed. As a definitional resource, this timing is interpreted as part of an apply operation so that the timing of the result actions in a CarePlan or RequestOrchestration, for example, would be specified by evaluating the timing definition in the context of the apply and setting the resulting timing on the appropriate elements of the target resource. If the timing is an Age, the activity is expected to be performed when the subject is the given Age. When the timing is a Duration, the activity is expected to be performed within the specified duration from the apply. When the timing is a Range, it may be a range of Ages or Durations, providing a range for the expected timing of the resulting activity. When the timing is a Timing, it is establishing a schedule for the timing of the resulting activity.
Allows prompting for activities and detection of missed planned activities.
Identifies the facility where the action will occur; e.g. home, hospital, specific clinic, etc.
May reference a specific clinical location or may just identify a type of location.
Indicates who should participate in performing the action described.
A reference to the id element of the actor who will participate in this action.
Defines roles played by participants for the action.
Indicates how the actor will be involved in the action - author, reviewer, witness, etc.
The type of action to perform (create, update, remove).
.moodCode { Maybe? this is effectively Create, Update, or Delete }
visual-group | logical-group | sentence-group
Defines the grouping behavior for the action and its children.
If no grouping behavior is specified but the action has children (i.e. is a group), the grouping behavior is assumed to be `logical-group`.
Defines organization behavior of a group.
any | all | all-or-none | exactly-one | at-most-one | one-or-more
Defines the selection behavior for the action and its children.
If no selection behavior is specified but the action has children (i.e. is a group), the selection behavior is assumed to be `all`.
Defines the required behavior for the action.
If no required behavior is specified but the action has children (i.e. is a group), the required behavior is assumed to be `could`.
Defines expectations around whether an action or action group is required.
Defines whether the action should usually be preselected.
If no precheck behavior is specified but the action has children (i.e. is a group), the precheck behavior is assumed to be `no`.
Defines selection frequency behavior for an action or group.
Defines whether the action can be selected multiple times.
If no cardinality behavior is specified but the action has children (i.e. is a group), the cardinality behavior is assumed to be `single`.
Defines behavior for an action or a group for how many times that item may be repeated.
Description of the activity to be performed
A reference to an ActivityDefinition that describes the laboratory procedure to be performed, or to a PlanDefinition representing a child laboratory service, either embedded or reflexed by the current one.
The definition is present only when there is no grouping of sub-actions
A reference to a StructureMap resource that defines a transform that can be executed to produce the intent resource using the ActivityDefinition instance as the input.
Note that when a referenced ActivityDefinition also defines a transform, the transform specified here generally takes precedence. In addition, if both a transform and dynamic values are specific, the dynamic values are applied to the result of the transform.
Customizations that should be applied to the statically defined resource. For example, if the dosage of a medication must be computed based on the patient's weight, a customization would be used to specify an expression that calculated the weight, and the path on the resource that would contain the result.
Dynamic values are applied in the order in which they are defined in the PlanDefinition resource. Note that when dynamic values are also specified by a referenced ActivityDefinition, the dynamicValues from the ActivityDefinition are applied first, followed by the dynamicValues specified here. In addition, if both a transform and dynamic values are specific, the dynamic values are applied to the result of the transform.
The path to the element to be set dynamically
The path to the element to be customized. This is the path on the resource that will hold the result of the calculation defined by the expression. The specified path SHALL be a FHIRPath resolvable on the specified target type of the ActivityDefinition, and SHALL consist only of identifiers, constant indexers, and a restricted subset of functions. The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements (see the [Simple FHIRPath Profile](http://hl7.org/fhir/R5/fhirpath.html#simple) for full details).
To specify the path to the current action being realized, the %action environment variable is available in this path. For example, to specify the description element of the target action, the path would be %action.description. The path attribute contains a [Simple FHIRPath Subset](http://hl7.org/fhir/R5/fhirpath.html#simple) that allows path traversal, but not calculation.
An expression that provides the dynamic value for the customization
An expression specifying the value of the customized element.
Sub actions that are contained within the action. The behavior of this action determines the functionality of the sub-actions. For example, a selection behavior of at-most-one indicates that of the sub-actions, at most one may be chosen as part of realizing the action definition.
{InverseRelationship of Definition.partOf}
If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example "pain", "on flare-up", etc.
A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.
boolean: precondition.negationInd (inversed - so negationInd = true means asNeeded=false CodeableConcept: precondition.observationEventCriterion[code="Assertion"].value