Para solicitudes de servicio que abordan condiciones, observaciones o metas/objetivos de los SDOH.

Muchos de los perfiles de SDOHCC se hacen referencia entre sí. Un flujo respaldado por esta IG es que las respuestas a cuestionarios resultan en observaciones que pueden utilizarse como evidencia para condiciones que pueden llevar a metas/objetivos, solicitudes de servicio y procedimientos. Sin embargo,también son posibles caminos alternativos.

Indica que el recurso está relacionado con la medición, logro o progreso hacia la meta/objetivo mencionado. Por ejemplo, una solicitud de servicio para proporcionar vales de alimentos pertenece a la meta/objetivo de lograr seguridad alimentaria.

Indica que la solicitud de servicio está relacionada con la meta/objetivo SDOHCC mencionado.

Permite que una organización (por ejemplo,una Plataforma de Coordinación) cree una solicitud de servicio para otra organización (por ejemplo,una Organización Comunitaria) basada en una solicitud de servicio SDOHCC de una fuente de referencia (por ejemplo,un proveedor o pagador involucrado en la gestión del cuidado.)

El estado está generalmente bajo el control del solicitante: ellos determinan si la orden está en borrador o activa y,después de que ha sido activada,completada,cancelada o suspendida.Los estados relacionados con las actividades del ejecutor se reflejan en el evento correspondiente o utilizando el recurso Task.

Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

Este elemento se etiqueta como un modificador porque la intención altera cuándo y cómo es realmente aplicable el recurso.Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

Un código que clasifica el servicio para fines de búsqueda, ordenamiento y visualización (por ejemplo, Educación).

Una categoría de SDOH asignada al servicio solicitado.

Códigos para categorías de SDOH de alto nivel.

Los códigos de este value set pueden usarse para asignar una o más categorías de SDOH (por ejemplo, inseguridad alimentaria, inseguridad en el transporte, etc.) a una solicitud de servicio. Se recomienda utilizar códigos de categoría de SDOH para facilitar la búsqueda de solicitudes de servicio que aborden condiciones, observaciones u metas/objetivos de SDOH.

Un código que identifica un servicio particular (por ejemplo, un procedimiento) que ha sido solicitado.

Códigos para pruebas o servicios que pueden ser realizados por un individuo, organización o servicio de salud designado.

Permite marcar una solicitud de servicio en la que el sujeto de la solicitud designa explícitamente que no desea ser contactado (por ejemplo, en casos de violencia doméstica donde el contacto puede poner en riesgo al sujeto.)

NOTA: dateTime debería ser Must Support, pero actualmente las herramientas no lo soportan.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto. Utilice el elemento CodeableConcept.text si los datos son texto libre (no codificado), como se muestra en CT Scan example.

La información representada por ServiceRequest.reasonCode puede superponerse significativamente con la información representada por ServiceRequest.reasonReference. Múltiples enfoques para representar la misma información pueden afectar negativamente la interoperabilidad. Por lo tanto, donde se pueda porporcionar información similar mediante ServiceRequest.reasonCode o ServiceRequest.reasonReference, se recomienda utilizar ServiceRequest.reasinReference para proporcionar una razón de por qué se hizo la solicitud de servicio.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio, o incluso si se realizará en absoluto. Para ser lo más específico posible, se de utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio.Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Además,consulte el comentario sobre reasonCode.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto.Para ser lo más específico posible, se debe utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio. Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Cuando una solicitud de servicio está justificada por una o más condiciones u observaciones de SDOH,ServiceRequest.reasonReference debe hacer referencia a instancias que cumplan con el perfil de Condición de SDOHCC, o una de los perfiles e Observación de SDOHCC.Sin embargo, también son posibles referencias a otros tipos de instancias.

Información clínica adicional sobre el paciente que puede influir en los servicios o en sus interpretaciones.Esta información incluye diagnósticos,hallazgos clínicos y otras observaciones.

Cuando una solicitud de servicio está respaldada por un consentimiento de SDOH, ServiceRequest.supportingInfo debe hacer referencia a instancias que cumplan con el perfil de Consentimiento de SDOHCC. Sin embargo, también son posibles referencias a otros tipos de instancias.

Para solicitudes de servicio que abordan condiciones, observaciones o metas/objetivos de los SDOH.

Muchos de los perfiles de SDOHCC se hacen referencia entre sí. Un flujo respaldado por esta IG es que las respuestas a cuestionarios resultan en observaciones que pueden utilizarse como evidencia para condiciones que pueden llevar a metas/objetivos, solicitudes de servicio y procedimientos. Sin embargo,también son posibles caminos alternativos.

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 it's narrative along with other profiles, value sets, etc.

An Extension

Indica que el recurso está relacionado con la medición, logro o progreso hacia la meta/objetivo mencionado. Por ejemplo, una solicitud de servicio para proporcionar vales de alimentos pertenece a la meta/objetivo de lograr seguridad alimentaria.

This extension is limited to subject-specific activity-related resources (events & intents). I.e. This can't be put on Goal or Patient. This association isn't for the purpose of goal management, but for things such as noting that a particular observation result, prescription or other activity is pertinent to the achievement (or possibly non-achievement) of the referenced goal.

Indica que la solicitud de servicio está relacionada con la meta/objetivo SDOHCC mencionado.

An Extension

Source of the definition for the extension code - a logical name or a URL.

The definition may point directly to a computable or human-readable definition of the extensibility codes, or it may be a logical URI as declared in some other specification. The definition SHALL be a URI for the Structure Definition defining the extension.

Value of extension - must be one of a constrained set of the data types (see Extensibility for a list).

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 manageable, 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.

Plan/proposal/order fulfilled by this request.

Plan/proposal/order fulfilled by this request.

Permite que una organización (por ejemplo,una Plataforma de Coordinación) cree una solicitud de servicio para otra organización (por ejemplo,una Organización Comunitaria) basada en una solicitud de servicio SDOHCC de una fuente de referencia (por ejemplo,un proveedor o pagador involucrado en la gestión del cuidado.)

The status of the order.

El estado está generalmente bajo el control del solicitante: ellos determinan si la orden está en borrador o activa y,después de que ha sido activada,completada,cancelada o suspendida.Los estados relacionados con las actividades del ejecutor se reflejan en el evento correspondiente o utilizando el recurso Task.

Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

The status of a service order.

Whether the request is a proposal, plan, an original order or a reflex order.

Este elemento se etiqueta como un modificador porque la intención altera cuándo y cómo es realmente aplicable el recurso.Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

The kind of service request.

Un código que clasifica el servicio para fines de búsqueda, ordenamiento y visualización (por ejemplo, Educación).

There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

Classification of the requested service.

Used for filtering what service request are retrieved and displayed.

Una categoría de SDOH asignada al servicio solicitado.

There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

Códigos para categorías de SDOH de alto nivel.

Los códigos de este value set pueden usarse para asignar una o más categorías de SDOH (por ejemplo, inseguridad alimentaria, inseguridad en el transporte, etc.) a una solicitud de servicio. Se recomienda utilizar códigos de categoría de SDOH para facilitar la búsqueda de solicitudes de servicio que aborden condiciones, observaciones u metas/objetivos de SDOH.

Indicates how quickly the ServiceRequest should be addressed with respect to other requests.

Identifies the level of importance to be assigned to actioning the request.

Set this to true if the record is saying that the service/procedure should NOT be performed.

In general, only the code and timeframe will be present, though occasional additional qualifiers such as body site or even performer could be included to narrow the scope of the prohibition. If the ServiceRequest.code and ServiceRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation.

Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

Un código que identifica un servicio particular (por ejemplo, un procedimiento) que ha sido solicitado.

Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code.

Códigos para pruebas o servicios que pueden ser realizados por un individuo, organización o servicio de salud designado.

Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.

Codified order entry details which are based on order context.

Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.

Codified order entry details which are based on order context.

Permite marcar una solicitud de servicio en la que el sujeto de la solicitud designa explícitamente que no desea ser contactado (por ejemplo, en casos de violencia doméstica donde el contacto puede poner en riesgo al sujeto.)

On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

The date/time at which the requested service should occur.

NOTA: dateTime debería ser Must Support, pero actualmente las herramientas no lo soportan.

When the request transitioned to being actionable.

The individual who initiated the request and has responsibility for its activation.

This not the dispatcher, but rather who is the authorizer. This element is not intended to handle delegation which would generally be managed through the Provenance resource.

The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.

If multiple performers are present, it is interpreted as a list of alternative performers without any preference regardless of order. If order of preference is needed use the request-performerOrder extension. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B).

An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto. Utilice el elemento CodeableConcept.text si los datos son texto libre (no codificado), como se muestra en CT Scan example.

La información representada por ServiceRequest.reasonCode puede superponerse significativamente con la información representada por ServiceRequest.reasonReference. Múltiples enfoques para representar la misma información pueden afectar negativamente la interoperabilidad. Por lo tanto, donde se pueda porporcionar información similar mediante ServiceRequest.reasonCode o ServiceRequest.reasonReference, se recomienda utilizar ServiceRequest.reasinReference para proporcionar una razón de por qué se hizo la solicitud de servicio.

Diagnosis or problem codes justifying the reason for requesting the service investigation.

Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio, o incluso si se realizará en absoluto. Para ser lo más específico posible, se de utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio.Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Además,consulte el comentario sobre reasonCode.

Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto.Para ser lo más específico posible, se debe utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio. Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Cuando una solicitud de servicio está justificada por una o más condiciones u observaciones de SDOH,ServiceRequest.reasonReference debe hacer referencia a instancias que cumplan con el perfil de Condición de SDOHCC, o una de los perfiles e Observación de SDOHCC.Sin embargo, también son posibles referencias a otros tipos de instancias.

Información clínica adicional sobre el paciente que puede influir en los servicios o en sus interpretaciones.Esta información incluye diagnósticos,hallazgos clínicos y otras observaciones.

To represent information about how the services are to be delivered use the instructions element.

Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

To represent information about how the services are to be delivered use the instructions element.

Cuando una solicitud de servicio está respaldada por un consentimiento de SDOH, ServiceRequest.supportingInfo debe hacer referencia a instancias que cumplan con el perfil de Consentimiento de SDOHCC. Sin embargo, también son posibles referencias a otros tipos de instancias.

One or more specimens that the laboratory procedure will use.

Many diagnostic procedures need a specimen, but the request itself is not actually about the specimen. This element is for when the diagnostic is requested on already existing specimens and the request points to the specimen it applies to. Conversely, if the request is entered first with an unknown specimen, then the Specimen resource points to the ServiceRequest.

Anatomic location where the procedure should be performed. This is the target site.

Only used if not implicit in the code found in ServiceRequest.code. If the use case requires BodySite to be handled as a separate resource instead of an inline coded element (e.g. to identify and track separately) then use the standard extension procedure-targetBodyStructure.

Codes describing anatomical locations. May include laterality.

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

Para solicitudes de servicio que abordan condiciones, observaciones o metas/objetivos de los SDOH.

Muchos de los perfiles de SDOHCC se hacen referencia entre sí. Un flujo respaldado por esta IG es que las respuestas a cuestionarios resultan en observaciones que pueden utilizarse como evidencia para condiciones que pueden llevar a metas/objetivos, solicitudes de servicio y procedimientos. Sin embargo,también son posibles caminos alternativos.

The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.

The only time that a resource does not have an id is when it is being submitted to the server using a create operation.

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 it's 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).

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 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, and nor can they have their own independent transaction scope.

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

Indica que el recurso está relacionado con la medición, logro o progreso hacia la meta/objetivo mencionado. Por ejemplo, una solicitud de servicio para proporcionar vales de alimentos pertenece a la meta/objetivo de lograr seguridad alimentaria.

This extension is limited to subject-specific activity-related resources (events & intents). I.e. This can't be put on Goal or Patient. This association isn't for the purpose of goal management, but for things such as noting that a particular observation result, prescription or other activity is pertinent to the achievement (or possibly non-achievement) of the referenced goal.

Indica que la solicitud de servicio está relacionada con la meta/objetivo SDOHCC mencionado.

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

An Extension

Source of the definition for the extension code - a logical name or a URL.

The definition may point directly to a computable or human-readable definition of the extensibility codes, or it may be a logical URI as declared in some other specification. The definition SHALL be a URI for the Structure Definition defining the extension.

Value of extension - must be one of a constrained set of the data types (see Extensibility for a list).

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 manageable, 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.

Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.

The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 v2) and the producer of the observations in response to the order (known as the 'Filler' in HL7 v2). For further discussion and examples see the resource notes section below.

The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest.

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest.

This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.

Plan/proposal/order fulfilled by this request.

Plan/proposal/order fulfilled by this request.

Permite que una organización (por ejemplo,una Plataforma de Coordinación) cree una solicitud de servicio para otra organización (por ejemplo,una Organización Comunitaria) basada en una solicitud de servicio SDOHCC de una fuente de referencia (por ejemplo,un proveedor o pagador involucrado en la gestión del cuidado.)

The request takes the place of the referenced completed or terminated request(s).

A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.

The status of the order.

El estado está generalmente bajo el control del solicitante: ellos determinan si la orden está en borrador o activa y,después de que ha sido activada,completada,cancelada o suspendida.Los estados relacionados con las actividades del ejecutor se reflejan en el evento correspondiente o utilizando el recurso Task.

Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

The status of a service order.

Whether the request is a proposal, plan, an original order or a reflex order.

Este elemento se etiqueta como un modificador porque la intención altera cuándo y cómo es realmente aplicable el recurso.Si bien actualmente se permiten todos los valores,puede haber una restricción en los valores en futuras versiones basadas en comentarios de implementación.

The kind of service request.

Un código que clasifica el servicio para fines de búsqueda, ordenamiento y visualización (por ejemplo, Educación).

There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

Classification of the requested service.

Used for filtering what service request are retrieved and displayed.

Una categoría de SDOH asignada al servicio solicitado.

There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

Códigos para categorías de SDOH de alto nivel.

Los códigos de este value set pueden usarse para asignar una o más categorías de SDOH (por ejemplo, inseguridad alimentaria, inseguridad en el transporte, etc.) a una solicitud de servicio. Se recomienda utilizar códigos de categoría de SDOH para facilitar la búsqueda de solicitudes de servicio que aborden condiciones, observaciones u metas/objetivos de SDOH.

Indicates how quickly the ServiceRequest should be addressed with respect to other requests.

Identifies the level of importance to be assigned to actioning the request.

Set this to true if the record is saying that the service/procedure should NOT be performed.

In general, only the code and timeframe will be present, though occasional additional qualifiers such as body site or even performer could be included to narrow the scope of the prohibition. If the ServiceRequest.code and ServiceRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation.

Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

Un código que identifica un servicio particular (por ejemplo, un procedimiento) que ha sido solicitado.

Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code.

Códigos para pruebas o servicios que pueden ser realizados por un individuo, organización o servicio de salud designado.

Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.

Codified order entry details which are based on order context.

Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.

Codified order entry details which are based on order context.

Permite marcar una solicitud de servicio en la que el sujeto de la solicitud designa explícitamente que no desea ser contactado (por ejemplo, en casos de violencia doméstica donde el contacto puede poner en riesgo al sujeto.)

An amount of service being requested which can be a quantity ( for example $1,500 home modification), a ratio ( for example, 20 half day visits per month), or a range (2.0 to 1.8 Gy per fraction).

When ordering a service the number of service items may need to be specified separately from the the service item.

On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

An encounter that provides additional information about the healthcare context in which this request is made.

The date/time at which the requested service should occur.

NOTA: dateTime debería ser Must Support, pero actualmente las herramientas no lo soportan.

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.

When the request transitioned to being actionable.

The individual who initiated the request and has responsibility for its activation.

This not the dispatcher, but rather who is the authorizer. This element is not intended to handle delegation which would generally be managed through the Provenance resource.

Desired type of performer for doing the requested service.

This is a role, not a participation type. In other words, does not describe the task but describes the capacity. For example, “compounding pharmacy”, “psychiatrist” or “internal referral”.

Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.

The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.

If multiple performers are present, it is interpreted as a list of alternative performers without any preference regardless of order. If order of preference is needed use the request-performerOrder extension. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B).

The preferred location(s) where the procedure should actually happen in coded or free text form. E.g. at home or nursing day care center.

A location type where services are delivered.

A reference to the the preferred location(s) where the procedure should actually happen. E.g. at home or nursing day care center.

An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto. Utilice el elemento CodeableConcept.text si los datos son texto libre (no codificado), como se muestra en CT Scan example.

La información representada por ServiceRequest.reasonCode puede superponerse significativamente con la información representada por ServiceRequest.reasonReference. Múltiples enfoques para representar la misma información pueden afectar negativamente la interoperabilidad. Por lo tanto, donde se pueda porporcionar información similar mediante ServiceRequest.reasonCode o ServiceRequest.reasonReference, se recomienda utilizar ServiceRequest.reasinReference para proporcionar una razón de por qué se hizo la solicitud de servicio.

Diagnosis or problem codes justifying the reason for requesting the service investigation.

Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio, o incluso si se realizará en absoluto. Para ser lo más específico posible, se de utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio.Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Además,consulte el comentario sobre reasonCode.

Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.

Este elemento representa la razón por la cual se está realizando la referencia y puede usarse para decidir cómo se llevará a cabo el servicio,o incluso si se realizará en absoluto.Para ser lo más específico posible, se debe utilizar una referencia a Observation o Condition si está disponible. De lo contrario, al referenciar DiagnosticReport, debe contener un hallazgo en DiagnosticReport.conclusion y/o DiagnosticReport.conclusionCode. Al usar una referencia a DocumentReference, el documento objetivo debe contener un lenguaje claro sobre los hallazgos que proporcione la razón relevante para esta solicitud de servicio. Utilice el elemento de texto CodeableConcept en ServiceRequest.reasonCode si los datos son texto libre (no codificado).

Cuando una solicitud de servicio está justificada por una o más condiciones u observaciones de SDOH,ServiceRequest.reasonReference debe hacer referencia a instancias que cumplan con el perfil de Condición de SDOHCC, o una de los perfiles e Observación de SDOHCC.Sin embargo, también son posibles referencias a otros tipos de instancias.

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.

Información clínica adicional sobre el paciente que puede influir en los servicios o en sus interpretaciones.Esta información incluye diagnósticos,hallazgos clínicos y otras observaciones.

To represent information about how the services are to be delivered use the instructions element.

Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

To represent information about how the services are to be delivered use the instructions element.

Cuando una solicitud de servicio está respaldada por un consentimiento de SDOH, ServiceRequest.supportingInfo debe hacer referencia a instancias que cumplan con el perfil de Consentimiento de SDOHCC. Sin embargo, también son posibles referencias a otros tipos de instancias.

One or more specimens that the laboratory procedure will use.

Many diagnostic procedures need a specimen, but the request itself is not actually about the specimen. This element is for when the diagnostic is requested on already existing specimens and the request points to the specimen it applies to. Conversely, if the request is entered first with an unknown specimen, then the Specimen resource points to the ServiceRequest.

Anatomic location where the procedure should be performed. This is the target site.

Only used if not implicit in the code found in ServiceRequest.code. If the use case requires BodySite to be handled as a separate resource instead of an inline coded element (e.g. to identify and track separately) then use the standard extension procedure-targetBodyStructure.

Codes describing anatomical locations. May include laterality.

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

Any other notes and comments made about the service request. For example, internal billing notes.

Instructions in terms that are understood by the patient or consumer.

Key events in the history of the request.

This might not include provenances for all versions of the request – only those deemed “relevant” or important. This SHALL NOT include the Provenance associated with this current version of the resource. (If that provenance is deemed to be a “relevant” change, it will need to be added as part of a later update. Until then, it can be queried directly as the Provenance that points to this version using _revinclude All Provenances should have some historical version of this Request as their subject.