Date
Attendees
Bolded names were present
...
Topic | Notes |
|---|---|
Reviewing minutes from the last call - Action Item Follow up |
|
Call Schedule | Riki out on travel 1/15 and 1/22; at HL7 WGM 1/29 No call 1/15, Hung will run 1/22 and 1/29 |
Review LIDR White Paper | For next call (1/22) review the written sections - add inline comments or edit directly (use strikethrough instead of deletion for content sections) and include initials or name with the comment / edits |
Renaming LIDR | FDA had requested to change the word represented by the “R” in LIDR from Repository to something else - see email text from Keith: LIDR acronym has bugged me because the R = repository, which is implying instance data rather than metadata or knowledge. I propose a tweak that preserves the LIDR acronym, but substitutes some words that work better for me: Laboratory Interoperability Data Record Or Laboratory Interoperability Device Record Suggestion: Laboratory Interoperability Device Reference Laboratory Interoperability Device Record Or even combine: Laboratory Interoperability Device Reference Record Discussion: Device is too constraint Repository is a place you put stuff Laboratory Interoperability Data Reference (if folks then add “repository” it still works Laboratory Interoperability Data Reference library = LIDR library Keep Repositiory = 5 Change to Reference Library = 1 |
Google Sheet review and discussion | For Full meaning of test / comparability would need: Specimen Type, Specimen Source (site or organ system), Specimen Collection Fields also need to know which are FDA approved vs LDTs What if we want to exclude the specimentype in LOINC (XXX) but that is not encoded in SNOMED - should be a value that is the high level applicable code in SCT LOINC has a project to replace XXX with values that would be globally legal - create a {valueset drawn from SCT} Is LIDR representing the meaing of the test or what is to be shared in the message - we have to keep both in mind, but they may not exactly be the same example you would be tissue as a higher level code. how will it differentiate between type (entire ear submitted as specimen) vs source (swab from ear, where ear is the source site) - where type would probably be Swab (rather than all the pre-cooridnated specimen types) - in specimen CMT we should lean towards use of prototype term - for wound culture would be swab or aspirate (or maybe just “specimen”) When source is not needed here - use the organ system instead of the actual location of where the needlestick was done, since there is no difference in the blood if it is collected from left or right arm veins - so for ser/plas = type collected is whole blood SCT defintion for type - what is collected SCT defintion for source - where is it collected from dealing with derived specimen is another issue altogether - source is often used to capture that how to indicate what to populate for source:
What if there is only “albumin” in the data exchange - MUST have the type (urine/blood/serum) many EHR-s have dictionary values that are comingled for specimen type and source - The https://aphlinformatics.atlassian.net/wiki/spaces/LMCOPL has been working on a solution for representing single field netires and mulit-field entires for speicmen attributes for the different domains for a long time - strugling with how to publish it https://aphlinformatics.atlassian.net/wiki/download/attachments/1852900247/20200601_CBR_SCM_OnePager_v04_final_cleared.pdf?api=v2 In LIDR - type and source are needed fields depending on type of test we need type / source, but it may not be as important in some cases (when type is swab, source becomes very important)  ANDREA POST_Call Comment on the image: It looks to me (but needs to be confirmed), the Specimen Type is likely the top "Blood," while the Specimen Source is the next row, "Blood, Unspecified Source" and the Specimen Collection Procedure is "Venipuncture." As such I'd initially read that the High Sensitivity Troponin I is performed on Blood, as a Specimen Type of Serum or Plasma is not indicated. Looking at LOINCs for Troponin I, we see the following codes. Based upon the Blood specimen type, I'd be inclined to map to the blue LOINC: https://loinc.org/42757-5 You'll note there are no high sensitivity method LOINCs on blood though, so this would be the best map. However, if the specimen type is truly serum or plasma analyzed, then the best LOINC map would be in yellow aligned with the units, reflecting the HS method, etc. which is LOINC https://loinc.org/89579-7 Would need to confirm with the performing lab as the source of truth. If this is UNL  Is this from UNL? Let's assume it is for argument's sake, their hsTropI on their lab test menu is here: https://www.testmenu.com/nebraska/Tests/276610 You'll note on the first tab, they perform testing on plasma. The last tab indicates their LOINC is 89579-7, which matches the specimen type, method, troponin i, etc., which I'd agree with. If you are receiving Blood for the Specimen Type, it appears there is an error somewhere in the information flow process. Is it with which Specimen Type Catalog term is being associated with Troponin Test and it needs to be updated to Plasma for allignment? Less commonly, it could be what is in the HL7 message or in an interface hub that is applying Blood, or potentially in the receiving EHR system. If the latter two, these are the types of issues the Sequoia Lab Tiger team members are also noting as lab data receivers. Once we establish what should be occurring (accurate/complete info), we may want to work on Best Practices/recommendations if it is due to content builds/mapping in individual LIS and EHRs, so labs can fix these and improve data quality and ensure accurate/quality info is available for end users. If it is due to functionality in LIS/EHRs, then that may be addressed from a certification aspect. Maybe some HIT vendors are unable to apply specimen type or source to some tests (while others have no issue). It may be ensuring all are on the same playing level so to speak. Detective work is needed to try to determine the root cause as part of the complexities with lab data interoperability are different or multiple factors may be involved with what is seen. Another aspect of today's discussion reveals there are different definitions for Specimen Type, Specimen Source, and perhaps Specimen Collection method. This is common across the healthcare space for the last decade or so. Same terms with slightly different meaning have been used across different federal regulations too (CLIA vs ONC over the years vs HHS/CMS). Then HL7 and SNOMED CT have their meanings for the terms too (which is what I was describing). There may be some EHR/LIS data dictionary descriptions for these items that may have used older terms and not updated for customers in the last decade resulting in some putting the "wrong terms" in the wrong dictionaries and thus they are encoded with the wrong SCT hierarchy codes, placed in the wrong HL7 message field for receivers like PH. Thankfully, most jurisdictions have a process to check these before widespread production messages start. They are often caught and corrected. Often the same terms/codes are used in exchanges with EHRs/others LISs/HIEs, etc. too. Are there other needs as we think about the future state/needs? It shows how one aspect can have widespread impact. That said, I'm glad we agree on the need for Specimen Type and Specimen Source fields in LIDR. Did we end with agreement on how to indicate if say Specimen Source is not as vital for the meaning of a Potassium row? (I've been using the term N/A or not applicable which may not be the best words to use. Feel free to jump in with better terms to communicate if the field is required for Potassium, a nice to have, etc.) Maybe I should rephrase to say does it contribute/is it needed for the full meaning of our Potassium row? I'd argue Specimen Source does not, but Specimen Type does. Is that the discussion we want to have in two weeks? |
ACTION ITEMS | Please see the action items at top of this page - Next deliverable is White paper outline by end of this year And we need to prioritize the use cases, so that we can finalize the requiements for the first phase of LIDR, which need to be included in the White paper |
Next call | Monday 1/22/2024 9 - 10 AM ET |
Adjourned |
|
Chat:
Recording:
Action items
Quick decisions not requiring context or tracking
...