Page tree
Skip to end of metadata
Go to start of metadata

Submitting WG/Project/Implementer Group

  • Orders & Observations

Justification and Objectives

Validate the representation for non-quantitative IVD tests' result values mappings to LOINC and/or SNOMED towards the next, second version of LIVD Implementation Guide.  

This track will use what version of FHIR.

  • FHIR R4 (and possibly the R5 Connectathon snapshot)

Clinical input requested (if any)

  • Input from Lab Device Manufacturers, Laboratory IT and those performing the IVD Tests' result values to LOINC and/or SNOMED mapping are essential.

Related tracks

  • Terminology Services

Proposed Track Lead

Expected participants

  • 4-5

Track Orientation

  • Friday, January 17, 2020, 1-2pm ET
  • Friday, January 24, 2020, 1-2pm ET

Online Meeting Link: https://join.freeconferencecall.com/ord
Online Meeting ID: ord

If not on FCC (e.g., in a car) or not wanting to use VOIP, use the following dial-in:

Dial-in Number (United States): (515) 739-1430 Access Code: 294586

International Dial-in Numbers: https://www.freeconferencecall.com/wall/ord#international

FAQ’s, tips and other helpful information regarding FreeConferenceCall.com is available at www.HL7.org > Resources > Tools and Resources  > FreeConferenceCall.com Tip Sheet.

System Roles

  • Device Manufacturer
    • The Device Manufacturer creates a Bundle for their LIVD Publication and make that available at least as a file (e-mail, Direct, CD, website link) or FHIR server (although latter is not expected to be interacted with in the current state).
  • Laboratory
    • The Laboratory, LIS or separate system, will receive the LIVD Bundle and present the content in a readable form, which may be a spreadsheet, online view, or otherwise.
  • Middleware/Device Connectivity
    • A middleware solution may be used to configure the test analyte mappings on behalf of an LIS as results flow from device to LIS. This role is therefore expected to be very similar, if not that same as that of a Lab/LIS, but separated for now to validate whether that is correct.
  • Intermediary Third Party Library
    • A third party collecting all manufacturer's data and making it available through a FHIR server for others to access. This could be completely independent (e.g., a standards organization or terminology library), as part of an LIS or Middleware/Device Connectivity.

Scenarios

  • Scenario 1 - The manufacturer creates a LIVD Publication Bundle and makes it electronically available to a receiver. The receiver uses the LIVD Publication Bundle to render the content in their preferred format (e.g., spreadsheet, in-line with configurator, UI display).
  • Scenario 2 - Multiple manufacturers create a LIVD Publication Bundle and make it electronically available to a receiver. The receiver populates a FHIR server and makes APIs available to access these across manufacturers. Another party uses an App to obtain the data from that intermediary.
  • Scenario 3 - Multiple manufacturers create a LIVD Publication Bundle (including manufacturer codes for observations, a LOINC code system fragment and one or more ConceptMap resources).  This content will be loaded (via a FHIR REST endpoint or otherwise) to a server with terminology service capabilities, which will make the content available to a receiver via FHIR terminology service operation endpoints. The receiver (client) will use the FHIR terminology service API to access the data in the context of specific identified client needs.
  • Scenario 4 - Use the Terminology Services content delivery mechanism to enable distribution of a LIVD publication.  Evaluate use of the $translate operation for returning specific test and result code mappings. 

TestScript(s)

  • While we have test data, there is not a test script at this point, particularly as we are not communicating directly between a client and a server.
  • Focus is on qualitative test examples to ensure they are properly represented in the FHIR profiles.

Security and Privacy Considerations

  • None


  • No labels