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
  • IICC - IVD Industry Connectivity Consortium
  • 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 - Patient Demographics 
  • PHA - Public Health Authority
  • PID - Patient Identification Segment
  • RE - Required but may be Empty (Must support)

...

  • 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. - QUESTION: it does not have a slot for it (I thought that's what the Equipment (to be renamed to Product) UID is for) - or that information is not currently provided in that slot?  HJB: Still TBD in R2 to finalize location, either ObservationDefinition or DeviceDefinition.
  • Deployed lab order implementation guides do not include the 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.
  • Deployed lab reporting implementation guides do not include the 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 PD1, 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.

...

The following updates need to be made in the base implementation guides for a next version to include the short-term Implementation Guidance provided in the next section.

  • LIVD
    • Add the device identifier for the test kit in the correct resource (DeviceDefinition or ObservationDefinition?)
      •  Need a product reference uid to identify the ObservationDefinition OR is it really on the DeviceDefinition?
        • If on the ObservationDefintion, need to re-include ObservationDefinition.identifier 0..*
          • identifier.type = "product-reference-identifier"
          • identifier.system = TBD (for uid)
        • If on the DeviceDefinition .....
    • Add the assigning authority as well.  This is particularly important for OBX-18.3 if the identifier is not an official device identifier.
  •  eDOS
    • Add new AOEs to master list, but nothing needed for the rest
  •  LOI LOI
    • None?
  • LRI
    • Add guidance on how to convey device identification information
      • Can be sent in OBX 3 as a result for "reagent identifier" build as a test result in the panel reporting COVID results.
      • Can also be sent in PFT 15 (I think)
      • Can be sent in SPM (field?)

...

  • Immediately
    • Orders - Any HL7 v2 ORM or OML message in place between ordering provider and Laboratory as well as Laboratory and Reference Laboratory where the tests are outsourced.
      • Use LOI Rn Section X, YR1 STU 3 Section 1.4.10X, 6.15, Z for specification on how to add AOEs using pre-adopted OBX capabilities.
      • Include Profile ABC in TBD, but a new profile in MSH-21 so receiving system recognizes it may contain OBX segments that are based on HL7 v2.8.12
      • Use eDOS Rn Section X, Y, Z for master R2 STU 3 Appendix A for an initial list of AOEs PLUS [whatever list Riki is adding if maintained separately for now]
        • eDOS would be electronic version of CLIA Specimen Collection Manual
      • Use Mapping Spreadsheet below for PID and OBR fields that are RE if not R.
    • Results - Any ELR to PHA
      • Use LRI Rn Section X, YR1 STU 3 Section 8.11, 13.3.3, Z for specification on how to add/forward AOEs with the result  result using OBX segments that are based on HL7 v2.8.2  (AP note:  AOEs become/are results and their values in OBX 3/5 messages sent to providers and PHA via ELR.  HJB: clarified in both Orders and Results.  Thank you!)
      • Use Mapping Spreadsheet below for PID, OBR, and OBX fields that are RE if not R.
      • Use Device Identifier guidance below
  • Strongly Recommended
    • Adopt LIVD as quickly as possible to stay informed on latest LOINC mappings and device identification information
    • Adopt eDOS as quickly as possible to stay informed on latest AOEs per test.
    • Adopt LOI Rn as quickly as possible to enable most consistent and complete communication of Lab orders.
    • Adopt LRI Rn as quickly as possible to enable most consistent and complete communication of ELR.  (AP Note:  LRI is separate form ELR and ELR is required by law, while LRI is not technically required anymore, but was for stage 2 MU of hospital labs only.)

...

  • Some of the AOEs may be able to be answered based on knowledge in the system (e.g. is patient hospitalized = Patient class is inpatient in encounter)
    • We should do an analysis of which of these HHS questions are available in the EHR-s (and in what format) and then decide on the best way to share that data, e.g., use PID/PD1/PV1/PV2/NK1 (occupation) - I got some feedback, that UNLESS the element is already in ELR R1 (like PV1-2), OBX segments will be easiest in the short term to add to the surveillance system.
    • Understanding is some drive up/drive through COVID testing sites are using paper requisitions for ordering, so data elements would be required on paper req to performing lab, who would enter them into their results reporting to PHA ELR message (if provided!).
  • Options for differentiating OBX for AOE vs OBX for results:  (AP Note:  The AOE question and response, would be represented as a result and result value.  The LOINC is likely the same for the AOE question and result in most cases.  However, they may have an order ID/identifier for the AOE, and a result ID for the result field to distinguish the two uses of the same data item.)
    • LOINC code  
    • ELR R1 expects OBX after SPM for patient age - could put others there
    • Use a separate OBR for EPI important information
    • OBX-29 in LOI/LRI
  • While communication of a .csv or flat file from performing lab to PHA, if the above guidance cannot be implemented in time, is out of scope of HL7 to define format, we could make some suggestions on what to include to match with the ELR transaction that it needs to match up with.  
    • 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)
    • Suggest to allow for Direct Messaing to convey the file.
    • Why not just use ELR in xml format via Direct?
  • What shall we point to for LIVD latest guide?

Resources for Background

...