Submitted by jkegerize on 2023-09-20
ACLA Comment on Specimen Condition Acceptability for USCDI v5
The American Clinical Laboratory Association (ACLA) comments pertain to the burden of using the Unified Code for Units of Measure (UCUM).
ACLA believes the vocabulary standard, UCUM, should be recommended, but not required. 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. We would also recommend the ONC solicit feedback from CAP and CLIA on their stance on the need for conversion to UCUM.
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 Riki Merrick on 2023-09-20
APHL Comment on Speicimen Condition Acceptability
This field combines several aspects about the specimen and why it can or cannot be used in testing and should be split up into more data elements:
Specimen condition (SPM-24 in V2, specimen.condition in FHIR): attribute of the specimen - hemolyzed, frozen etc - should be represented using either SNOMED CT from the clincial finding hierarcy (or more specifically descendants of 441742003 | Evaluation finding) or HL70439 (https://terminology.hl7.org/5.1.0/ValueSet-v2-0493.html) used in both V2 and FHIR - this is usually not reported when the specimen is in the expected conditon and the test is performed, but it must be reported per CLIA as part of the result, when testing was performed on a specimen that was not ideal, but tested anyway to alert the provider to interpret the results with caution.
Specimen appropriatemess (SPM-23 in V2 using HL70492 ( https://terminology.hl7.org/5.2.0/ValueSet-v2-0492.html), sort of captured in FHIR in specimen.status using (https://hl7.org/fhir/valueset-specimen-status.html) this is really an attribute of the test - a specimen in a specific condition may be unacceptable for one test, but totally fine for another - vocabulary for this element is not worked out well.
Specimen reject reason (SPM-21 in V2 using HL70490 (https://terminology.hl7.org/5.2.0/ValueSet-v2-0490.html) and not in FHIR) - This is used when the testing is not performed to convey the reason why.