The LabServiceDefinition profile constrains the resource PlanDefinition to represent a laboratory diagnostic service made visible to clinicians: the potential consumers of this service.

Expresses a synonym of the laboratory service in a specified language

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.

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

When multiple useContexts are specified, in this LabServiceDefinition profile, all contexts apply to the defined laboratory service.

The presence of this slice indicates that the service is open to laboratory order entry

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 detailed description of how the laboratory diagnostic service is used from a clinical perspective.

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

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) ...

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

A brief description of the document that need to be provided alongside the order of this laboratory service

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.

used if the model of document is accessible externally

May be sufficient to specify the document expected, in cases where no pre-defined needs to be communicated to the orderer of the service.

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.

The related resource, in this case a PlanDefinition constrained by the LabServiceDefinition profile

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.

The related resource, in this case a PlanDefinition constrained by the LabServiceDefinition profile

Related bibliographic references such as documentation, justification, or citation.

kind of associated bibliographic artifact

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.

A brief description of the laboratory service, which may mention the analytical method(s) used by the laboratory

Indicates how quickly this diagnostic panel or test should be performed.

A code that provides meaning to the laboratory service

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.

The natural language expression of the trigger for the reflex laboratory procedure

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

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.

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.

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.

An Extension

This extension to PlanDefinition, MedicationKnowledge and DeviceDefinition conveys the reference to a catalog containing the extended resource

Optional Extension Element - found in all resources.

An Extension

An Extension

An Extension

An Extension

An Extension

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.

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.

The lifecycle status of an artifact.

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).

An Extension

Translation of the description of the laboratory service in a specified language

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.

Assist in searching for appropriate content.

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

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

Assist in searching for appropriate content.

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 is restricted to one gender of subject (female or male)

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

Assist in searching for appropriate content.

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.

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

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

Assist in searching for appropriate content.

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 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, there is no expectation that all or any of the contexts apply.

Assist in searching for appropriate content.

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.

A detailed description of how the laboratory diagnostic service is used from a clinical perspective.

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

High-level categorization of the definition, used for searching, sorting, and filtering.

Repositories must be able to determine how to categorize the plan definition so that it can be found by topical searches.

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.

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) ...

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.

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.

The type of relationship to 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

A brief description of the document that need to be provided alongside the order of this laboratory service

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.

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.

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 related artifact is another instance of PlanDefinition, which is a replacement for the current no longer usable laboratory service

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.

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.

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.

The type of relationship to the related artifact.

The related resource, in this case a PlanDefinition constrained by the LabServiceDefinition profile

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.

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.

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.

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.

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.

The type of relationship to the related artifact.

The related resource, in this case a PlanDefinition constrained by the LabServiceDefinition profile

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.

Related bibliographic references such as documentation, justification, or citation.

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.

kind of associated bibliographic 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.

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.

An Extension

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.

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

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

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

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.

A brief description of the laboratory service, which may mention the analytical method(s) used by the laboratory

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.

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.

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.

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.

The type of triggering event.

The type of trigger.

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.

The timing of the event (if this is a periodic trigger).

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.

Defines the grouping behavior for the action and its children.

Defines organization behavior of a group.

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

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.

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.

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.

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).

IETF language tag for a human language

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.

An Extension

This extension to PlanDefinition, MedicationKnowledge and DeviceDefinition conveys the reference to a catalog containing the extended resource

Optional Extension Element - found in all resources.

An Extension

An Extension

An Extension

An Extension

An Extension

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.

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.

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.

Allows the plan definition to be referenced by a single globally unique identifier.

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.

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.

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.

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)

An Extension

Expresses a synonym of the laboratory service in a specified language

The actual value

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.

The lifecycle status of an artifact.

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.

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.

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.

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).

unique id for the element within a resource (for internal references)

An Extension

Translation of the description of the laboratory service in a specified language

Primitive value for markdown

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.

Assist in searching for appropriate content.

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

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.