Laboratory
Representing Laboratory Test Ordered

Comment

Submitted by jkegerize on

ACLA Comments on Representing Result Values

The American Clinical Laboratory Association comments pertain to the burden of using the Unified Code for Units of Measure (UCUM).

ACLA agrees that the vocabulary standard, UCUM, should not be required, but may be represented. Laboratories should be allowed to use units of measure other than UCUM. The unit of measure provided by the instrument manufacturers, including FDA authorized, cleared, or approved method, is the standard that laboratories need to adhere to for result reporting. We recommend conversations and adoption from instrument manufacturers is incumbent for the adoption of UCUM to be viable.

The UCUM can be a preferred standard, but it should not be required for all tests. Currently, there is a large base of units of measure that are in use across trading partners. To convert these units to UCUM would be problematic, difficult to achieve and time consuming.

While ACLA acknowledges UCUM as an option for standardized vocabulary for units of measure it is crucial to recognize and understand the limitations of the UCUM coding system and the impact of key issues identified by ACLA prior to universal adoption.

  • UCUM has codes for ALL US customary units (e.g., UCUM guide §35 U.S. survey lengths, and §37 U.S. volumes). However, these will not necessarily have the same string representation that a given laboratory uses (see UCUM GUIDE http://unitsofmeasure.org/ucum.html). It also includes codes for all non-arbitrary unit of measure (UoM), includes many arbitrary UoM such as Somogyi units, and has a way to include strings (which will not be computable for any arbitrary units -- but arbitrary units are never computable in the sense that they can be interconverted).
  • There are issues with transmission of unusual or unrecognizable characters (e.g. ‘*’ or ‘^’, and descriptions sometimes use ‘#’ and ‘&’) which cause errors in some sending and receiving systems. These are restricted characters that cause issues in data exchanges including HL7.
  • Some recommended UCUM units exceed the HL7 prescribed field lengths for the coded element of 20 characters (e.g. nmol{BCE}/mmol{creat}, %{normal_pooled_plasma}). For example, some state public health systems are unable to accept more than 20 characters in the unit of measure HL7 field.
  • The mandate to report all units of measure in a UCUM format could impact patient safety. 
    • There may be a potential for discrepancies between the units of measure directed by instrument and/or reagent vendors in their package insert/operator’s manual for result reporting of a particular test vs. the UCUM units identified for that test. 
    • The instruments that process the specimens may or may not use UCUM standard units. There is a risk in converting results into a unit of measure that is different than the original unit of measure. 
      • Conversions cannot always be achieved to equivalency.
      • Even if it is accurately converted, it does not ensure that providers will always interpret it correctly.
      • It is common for conversion algorithms to encounter errors. While the problem with that is self-explanatory, a second issue may not be.  The value and the units of message occupy two separate HL7 fields.  Should a numeric value encounter an error, and the translation process choses to handle the issue by leaving the value as it was received but incorrectly modifies the units of measure (assuming the value algorithm performed correctly), there could be a disconnect between the value and units of measure that could greatly impact the interpretation of the results, and by extension, the health of the patient.
    • At present, units can be very confusing and unpredictable and almost impossible to use for computer purposes like decision support and quality assessment. We have seen more than 30 different representations of units for the number RBCs e.g.  10^12/Lit  bill/liter,  10*12/liter., etc.

 

 

 

Submitted by jkegerize on

ACLA ISA comment re: clarification to section title, ‘actors’, a

The title of this section is more limited than what is covered in this section; please clarify the actors this section applies to, e.g., Electronic Health Record (EHR) systems, Laboratory Information Systems (LIS), laboratories, exchanges, etc.  Refer to the IHE LAW and LTW profiles “Intended Audience”; is the target audience the same for this section?

Some of these statements should be in the “Content/Structure” section of the ISA, not the “Vocabulary/Code Set/Terminology” section; there is overlap with the “Exchanging InVitro Diagnostics (IVD) Test Orders & Results” Content /Structure section of the ISA.

Please clarify the term “harmonization status”.  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory values/results or provider’s EHR system laboratory values/results?

Do these terms, such as “standard scales” or “grading schemes” represent the end result of using of standard terminology such as LOINC or SNOMED CT? Please clarify.

 

 

Submitted by gldickinson on

Preserving Clinical Context

General Comments: USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.