Presentation on theme: "Best Practices for Interoperable Data Exchange Using LOINC Ming-Chin (Mark) Lin, MD Stanley M. Huff, MD."— Presentation transcript:
Best Practices for Interoperable Data Exchange Using LOINC Ming-Chin (Mark) Lin, MD Stanley M. Huff, MD
Introduction Two primary use cases – Sharing data between and among different institutions for patient care – Aggregating data between and among different institutions for clinical research, quality improvement, public health surveillance, etc. (secondary use) Use LOINC codes as the lingua franca for the data sharing
Introduction (continued) Mark’s work comparing LOINC usage across ARUP, Regenstrief, and Intermountain What is truth? – If local codes from different sites are mapped to the same LOINC code, how do we know they are really the same test? – If local codes from different sites are mapped to different LOINC codes, how do we know they are really different tests? Extensional definitions – Comparison of names (substance, timing, property, specimen), units of measure, mean value, standard deviation, coded values, co-occurring tests, etc. Results: We found about a 4% error rate in mapping – And that is us! What is it like for “regular” facilities?
Introduction (continued) Analyzing the errors lead to additional questions – Can we classify the errors? – What is the ultimate goal of mapping? – Can we define “best practices” for mapping so that everyone doing mapping can achieve greater accuracy?
Principles/Goals in Choosing Best Practices Optimize for patient safety, interoperability, and secondary use of data Anticipate change - Make the process as easy as possible when new codes are created, technology changes, or when errors are corrected Make the practices understandable and reproducible Have the least possible impact on LOINC staff
Approach State best practices to encourage movement to better processes We expect this to take time Don’t try to mandate anything (we don’t have any authority to do that) Not following best practices is not considered “non compliance” to standards We may need to change some LOINC content to better support best practices
Proposed Process Create specific best practice guidelines for difficult situations and common errors Consider a few questions each meeting As agreements are made, add the best practices as a section in the LOINC manual Example issues (please contribute your issues) – Specificity of analytes – Best approach for sending method specific data – Best practice for value of quantities and interpretations – How to deal with pre and post coordinated specimen type – How to deal with pre and post coordinated challenge conditions – Use of Acnc and Titr – Use of NAR and NOM – Use of PRID and IMP – Etc.
Proposal #1 Request a new code when analyte/component details don’t match LOINC exactly
Examples A new local test is for Avian pox virus Ab.IGG – Not a match for Avian pox virus Ab A new local test is for Avian paramyxovirus 10 Ab – Not a match for Avian paramyxovirus Ab A new local test for 11-Deoxycortisol.free SCnc – Not a match for 11-Deoxycortisol SCnc Many, many examples where there is a parent-child relationship between items. These are never a match. Always request a new code.
Proposal #2 Always send method information as an independent element in the OBX segment.
“Fit for Purpose” or “Good Enough” mapping versus “Best Practice” Example: Tests where the name includes a specific method at site A are mapped to methodless tests at site B Works for the known use case – Either estimated weights or scale weights may be good enough for a particular study This represents a loss of information when data moves from A to B
Proposed Best Practice Always capture the method with the data if it is known Recommended: Map to the methodless LOINC code but send the method as part the value of OBX.17 Observation Method if it is available Related policy: The LOINC Committee will encourage and help develop a coded value set for methods Recommended: Map to the LOINC code that pre coordinates the method in the code – Specific details and sub methods can also be sent in OBX.17 Discouraged practice: mapping tests where the method is known to methodless LOINC codes
Examples Local test: Hepatitis C virus Ab.IgG by EIA Recommended: send EIA as method in OBX –OBX|1|CE|16936-7^Hep C virus^LN|…|EIA|… Recommended: Send precoordinated code for EIA method –OBX|1|CE|57006-9^Hep C virus EIA^LN|…||… Discouraged: Method not sent –OBX|1|CE|16936-7^Hep C virus^LN|…||…
Proposal #3 Always map to the Quantitative code even if the lab is only sending the interpretation.
Discussion There was a lot of discussion about what the test was approved by FDA for (e.g. tests that produce a number but the reporting is specified to always be a threshold-based "interpretation"). Clem was not in favor of the suggestion to: "Always map to the quantitative LOINC code. Related policy: The LOINC Committee will discourage or deprecate the use of nominal or ordinal LOINC codes for concentrations" What I think we had agreement on was something like: Best practice is... 1. Reporting the interpretation (e.g. positive, negative, not-detected, etc) of a test procedure that produces an approved/validated quantitative result in OBX-8. Corollaries: a) Don't report the interpretation as the (only) test result in OBX-5. b) Don't report these single-test interpretations as a separate OBX segment. There was quite a bit of discussion about whether the result/interpretation of an FDA-approved ordinal result should be sent in OBX-5 or OBX-8. Clem argued that it went against the current conventions to put the expected result in OBX-8…that flowsheets, etc would have to be re-architected to grab the "meat" of the result from OBX-8 in these cases.
Proposed Best Practice Always map to the quantitative LOINC code – Related policy: The LOINC Committee will discourage or deprecate the use of nominal or ordinal LOINC codes for concentrations Send numbers when they exist as the value of OBX 5 Send interpretations when they exist as the value of OBX 8 One or the other or both of the numeric value and the interpretation can exist in a data instance
Examples Local test: Cocaine in blood, with values of “positive” and “negative” Best: Map to Cocaine Qn and send interpretive value in OBX.8 (Interpretation, was previously abnormal flag) OBX|1|CE|72405-4^Cocaine MCnc Bld Qn^LN|||||positive| Anticipates future send of value and interpretation OBX|1|CE|72405-4^Cocaine MCnc Bld Qn^LN||4.0|ng/ml||positive| Discouraged: Map to ACnc Ord and send interpretation in OBX.5 OBX|1|CE|16633-0^Cocaine ACnc Bld Ord^LN||positive||||
Proposal #4 Pre coordinate the specimen type for common specimens, and post coordinate specimen type for uncommon specimens
Examples Local test: Cadmium mass concentration in CSF Option 1: pre coordinated specimen –OBX|1|NM|9686-7^Cadium MCNC CSF^LN||2.1|ug/gm| Option 2: Post coordinated specimen –OBX|1|NM|9687-5^Cadium MCNC XXX^LN|1.1|2.1|ug/gm| –OBX|1|CE|66746-9^Specimen Type^LN|1.2|CSF||
Degrees of Interoperability Degree I: Exact equivalence without translation – Same code, unit of measure, and value set – Data are mutually substitutable in all contexts of use Degree II: Exact equivalence after translation – Unit of measure conversion (need UCUM) – Mass concentration to substance concentration conversion (need the molecular weight) – Pre and post coordination translation Method as part of LOINC code versus method sent somewhere else in the message Peak or trough as part of LOINC code versus peak and trough sent somewhere else in the message – Data are mutually substitutable in all contexts of use after translation
Degrees of Interoperability (cont) Degree III: Context specific subsumption – A parent-child relationship exists between tests at the different institutions Method specific tests roll up to methodless tests IgM or IgG antibodies roll up to generic antibody – Data are mutually substitutable only in a specific context of use even after translation Degree IV: No interoperability – No comparable data or information exists between or among institutions