Add requirement to send supporting information with order

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Highest
    • US Post Acute Orders (FHIR)
    • 0.3.0 [deprecated]
    • Orders & Observations
    • (NA)
    • 5
    • Hide

      Since 1) EHRs are just starting to implement R4 and specific Da Vinci implementation guides such as DTR which is required to assemble the necessary documentation to support an order and 2) Payers are in the early stages of implementing templates and rules required by DTR, requiring the documentation (SHALL) is impractical.  We want to encourage adoption of this IG to eliminate, where possible, Faxing and telephone calls that lead to additional labor and errors.   In future versions of the IG we can consider stronger conformance language.  We will include the requirement for supporting documentation as SHOULD.

      Show
      Since 1) EHRs are just starting to implement R4 and specific Da Vinci implementation guides such as DTR which is required to assemble the necessary documentation to support an order and 2) Payers are in the early stages of implementing templates and rules required by DTR, requiring the documentation (SHALL) is impractical.  We want to encourage adoption of this IG to eliminate, where possible, Faxing and telephone calls that lead to additional labor and errors.   In future versions of the IG we can consider stronger conformance language.  We will include the requirement for supporting documentation as SHOULD.
    • Bob Dieterle / Marti Velezis : 11-0-6
    • Clarification
    • Non-substantive

      The discussion around request information, queries for additional information on an original request, and bundling information in a request raises an ongoing issue around communication for this instance of requesting PAO that is seen in other orders that require some level information to determine if the request is supported and justifiable for payment once provided. For ease of use, known required information to support the request should be provided as a "shall" requirement so the requestor provides adequate information to satisfy the request. initially, there may be inadequate information required so that additional information is needed and, over time, that information may be added to the "shall" requirment in an interative manner. The end goal being to provide sufficient information for the request, authorization and payment in as complete a manner as possible to reduce back and forth communication threads. The challenge is to be as complete as possible so that fragmented information is avoided-so if additional information is requested, it be iterated on the original request so that a complete picture is provided as the last state rather than an initial request and fragments of communication back and forth. It appears that this is the intent of the messaging exchange here and the model should be applied evenaly across IGs wehre applicable so the goal of complete and clear communication is achieved in these requests (orders, referrals, consultations and so on) in the FHIR specificaitons.

            Assignee:
            Unassigned
            Reporter:
            klsalzman
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: