propose boundaries for DO

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • Patient Care
    • STU
    • DiagnosticRequest (see ServiceRequest) [deprecated]
      ProcedureRequest (see ServiceRequest) [deprecated]
    • 4.22.2
    • Hide

      DiagnosticOrder is closely related to other types of "request" resources, particularly ReferralRequest and ProcedureRequest. In fact, for some services, it may be appropriate to use any one of these resources to request that the service be performed. Which one is used may be driven by organization practice and by context. When it is unclear which to use, the following principles may be helpful:

      ProcedureRequest or DiagnosticOrder are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done.

      A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take.

      Whether an activity is deemed to be a procedure or only a diagnostic order is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line will vary by organization.

      Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist. E.g. Upon receiving a ReferralRequest a practitioner might initiate a DiagnosticOrder. The diagnostic service might then initiate a ProcedureRequest.

      The DiagnosticOrder supports references to the numerous other resources that define information about the subject, the orderer, associated encounter, specimen the bodysite and other supporting information. For example, Patient, Practitioner Specimen and Condition are all referenced in this resource. While some systems may choose to bundle up a DiagnosticOrder and this referenced information into a Document for delivery to the recipient. However, REST, Messaging and Services are also valid architectures for managing referrals and may be more appropriate where active workflow management is needed.

      The CarePlan resource can be used to describe more sophisticated requests for combinations of services and DiagnosticOrder may be referenced as part of a CarePlan. Similarily ClinicalImpression resource can ireference DiagnosticOrder as part of a followup to plan to the assessment.

      Referrals may be targeted (identifying a specific Practitioner or Organization to perform the requested care) or untargeted (merely identifying the type of care desired). The Order and OrderResponse resources may be used to help manage such workflows.)

      Note that the Diagnostic Order itself is not a request to perform the investigation - but rather a record of the fact that a request was made. To actually initiate the workflow beyond simply the existence of a Diagnostic Order may be required. This can be achieved by using an Order resource, with the Diagnostic Order referenced from the Order.details, or by using the Diagnostic Order resource in the context of an messaging or service workflow where the request is explicit or implicit."

      Show
      DiagnosticOrder is closely related to other types of "request" resources, particularly ReferralRequest and ProcedureRequest. In fact, for some services, it may be appropriate to use any one of these resources to request that the service be performed. Which one is used may be driven by organization practice and by context. When it is unclear which to use, the following principles may be helpful: ProcedureRequest or DiagnosticOrder are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done. A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take. Whether an activity is deemed to be a procedure or only a diagnostic order is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line will vary by organization. Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist. E.g. Upon receiving a ReferralRequest a practitioner might initiate a DiagnosticOrder. The diagnostic service might then initiate a ProcedureRequest. The DiagnosticOrder supports references to the numerous other resources that define information about the subject, the orderer, associated encounter, specimen the bodysite and other supporting information. For example, Patient, Practitioner Specimen and Condition are all referenced in this resource. While some systems may choose to bundle up a DiagnosticOrder and this referenced information into a Document for delivery to the recipient. However, REST, Messaging and Services are also valid architectures for managing referrals and may be more appropriate where active workflow management is needed. The CarePlan resource can be used to describe more sophisticated requests for combinations of services and DiagnosticOrder may be referenced as part of a CarePlan. Similarily ClinicalImpression resource can ireference DiagnosticOrder as part of a followup to plan to the assessment. Referrals may be targeted (identifying a specific Practitioner or Organization to perform the requested care) or untargeted (merely identifying the type of care desired). The Order and OrderResponse resources may be used to help manage such workflows.) Note that the Diagnostic Order itself is not a request to perform the investigation - but rather a record of the fact that a request was made. To actually initiate the workflow beyond simply the existence of a Diagnostic Order may be required. This can be achieved by using an Order resource, with the Diagnostic Order referenced from the Order.details, or by using the Diagnostic Order resource in the context of an messaging or service workflow where the request is explicit or implicit."
    • Eric Haas/Rob Hausam:9-0-4
    • Enhancement
    • Non-substantive
    • DSTU1 [deprecated]

      use following text borrowed from Referralrequest:

      use following text borrowed from Referralrequest:

      "

      DiagnosticOrder is closely related to other types of "request" resources, particularly ReferralRequest and ProcedureRequest. In fact, for some services, it may be appropriate to use any one of these resources to request that the service be performed. Which one is used may be driven by organization practice and by context. When it is unclear which to use, the following principles may be helpful:

      ProcedureRequest or DiagnosticOrder are typically used when the requesting clinician has and wishes to exercise the authority (and expertise) to decide exactly what action will be done.

      A ReferralRequest is used when the requesting practitioner is seeking another practitioner or organization to use their own expertise and/or authority to determine the specific action to take.

      Whether an activity is deemed to be a procedure or only a diagnostic order is typically driven by how invasive the diagnostic process is. More invasive processes are typically represented as procedures, though the dividing line will vary by organization.

      Irrespective of the guidance above, systems should be prepared for some degree of overlap between these resources and be prepared to execute searches against multiple resources in cases where differentiation cannot be guaranteed. As well, in some workflows more than one type of resource or even all three might exist. E.g. Upon receiving a DiagnosticOrder a practitioner might initiate a DiagnosticOrder. The diagnostic service might then initiate a ProcedureRequest.

      The DiagnosticOrder supports references to the numerous other resources that define information about the subject, the orderer, associated encounter, specimen the bodysite and other supporting information. For example, Patient, Practitioner Specimen and Condition are all referenced in this resource. While some systems may choose to bundle up a DiagnosticOrder and this referenced information into a Document for delivery to the recipient. However, REST, Messaging and Services are also valid architectures for managing referrals and may be more appropriate where active workflow management is needed.

      The CarePlan resource can be used to describe more sophisticated requests for combinations of services and DiagnosticOrder may be referenced as part of a CarePlan. Similarily ClinicalImpression resource can ireference DiagnosticOrder as part of a followup to plan to the assessment.

      EH depending on whether the info should reside here or in Order Orderresponse (Referrals may be targeted (identifying a specific Practitioner or Organization to perform the requested care) or untargeted (merely identifying the type of care desired). The Order and OrderResponse resources may be used to help manage such workflows.)

      Note that the Diagnostic Order itself is not a request to perform the investigation - but rather a record of the fact that a request was made. To actually initiate the workflow beyond simply the existence of a Diagnostic Order may be required. This can be achieved by using an Order resource, with the Diagnostic Order referenced from the Order.details, or by using the Diagnostic Order resource in the context of an messaging or service workflow where the request is explicit or implicit."

            Assignee:
            Unassigned
            Reporter:
            Eric Haas
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: