Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • AOE - Ask at Order Entry
  • eCR - Electronic Case Report
  • eDOS -  Electronic Directory of Services implementation guide or transaction according to that guide
  • ELR - Electronic Lab Reporting implementation guide or transaction according to that guide
  • LOI - Laboratory Order Interface implementation guide or transaction according to that guide
  • LRI - Laboratory Results Interface implementation guide or transaction according to that guide
  • O - Optional
  • PD1 - 
  • PHA - Public Health Authority
  • PID - 
  • RE - Required but may be Empty

Current Challenges

When ELRs are sent to PHA it does not contain sufficient demographic, ask-at-order-entry data, and device information as is necessary to enable further analysis.  While some of that data could be part of a subsequent eCR, if the data is already available at time or order and ELR transmission before an eCR is available (or the next eCR is available) helps accelerate the process.

...

Currently the specific challenges in that area are:

  • Device identification data is not included in device/test documentation
    • The latest LIVD guide does not include an ability for the relevant identifier for each test kit.
  • Deployed lab order standards implementation guides do not have include the ability guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently.
    • The latest eDOS guide has the commonly used set of AOEs with standard LOINC codes and where applicable answer sets, but is not complete to cover the latest updates.
    • The latest LOI guide addresses the ability to communicate all relevant data, including any AOEs, but is not deployed in active use.
    • Upgrading to the latest LOI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation

Just copied across, not in the right place:

  • Is the following accurate interpretation of intent as we know it so far:
    • Enhance electronic order flow as much as possible that:
      • Ordering systems are capable of asking for and including all applicable AOEs with the order to the lab, particularly where that lab runs on a different system and even more so if that lab is external to the provider’s organization.
      • Users are strongly encouraged to include all known information at the time of ordering, recognizing that in a number of situations that information would not be available at time of order.
  • The ask is NOT to send an order for test related to a reportable condition to a PHA directly.
  • Enhanced ELR content to include all relevant demographic data received from the ordering provider AND all AOEs in the ELR transmission, whether done by the performing lab or perhaps the ordering provider as well based on local requirements
    • .
  • Deployed lab reporting implementation guides do not include he guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently, nor the relevant device information, nor sufficient clarity on minimum desired demographic data (some fields may need to be marked RE rather than O, or X).
    • The latest LRI guide (that now includes ELR) accommodates the ability to send any relevant AOEs, but may need more specificity on other patient demographic data already available in PID or PD2, while it does need guidance on how to convey the relevant device/test kit(s) used to perform the test.
    • Upgrading to the latest LRI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation.

As indicated before, there are many other challenges to ensure that data if fully, accurate, and consistently documented and communicated, including use of encoded standard vocabulary (at least along with any local coding that remains relevant), but that is not addressed here.  Our goal is to provide guidance on how to address the above challenges in the necessary implementation guides that can be deployed as quickly as possible and as consistent as possible across ALL jurisdictions.

We understand that there may be a desire/need to send the original order to PHA directly as well to get earlier insight into certain tests ordered including PHI, particularly during an emergency (as that may invade patient privacy unnecessarily during "normal" situations), but when that interest becomes a requirement, the guidance for the ordering flow is sufficient as the starting point and being extended based on local PHA emergency mandates on how much (or not) PHI is to be removed before forwarding it.  That guidance should be as consistent as possible as well, but we will address that when an actual requirement in any jurisdiction is raised.


Requirements

The following data set is desired to be made available as part of an ELR as much is is available upon placing the order and to the extent that the Laboratory has access to any additions before the ELR is sent.


 
Excellentable
excellentableId240cf068-d911-4b73-99b6-fbfe7f869dd8

Use this spreadsheet to collect options and comments around the proposed mapping of the HHS elements to various places in Order and result messages.


  • If accurate, then the ways to achieve this are:

...

      • Ideally we would like adoption of the latest LRI IG that includes ELR capabilities
      • That is not likely to happen, so similar as above, pre-adoption of the relevant sections in the LRI IG that is then included in the existing ELR transactions
      • Since ELR is subject to certification and the provider is supposed to use the certified version, there must be clarity that pre-adoption of the AOEs according to the latest LRI IG sections is permissible.
      • If neither of the above can be put in place, then the submitter is to send a .csv file according to a defined template preferable to a Direct Address (most stakeholders support that and has higher opportunity of automation in batches) or a portal for manual submission.
        • APHL is creating a flatfile format for this purpose (not csv, but rather tab delimited) - the elments in this flatfile are all mapped to the respective ELR R1 location, so that transformation could occur at the sender or receiver side (conversion tooling for the PHAs is being discussed)

...

excellentableId240cf068-d911-4b73-99b6-fbfe7f869dd8

Use this spreadsheet to collect options and comments around the proposed mapping of the HHS elements to various places in Order and result messages.

...

Straight from today's LIVD call, needs to be cleaned-up and merged with above where appropriate

...