We’re working on the ETL for visual acuity. For one given measurement ID in the measurement table, is it possible to add multiple measurement_source_value entries? This was suggested as a way to record multiple concepts about a single measurement that describe how the visual acuity was measured (i.e. distance, w/wo correction, which chart). Creating pre-coordinated concepts that fully represent all the options has been deemed prohibitive by both SNOMED and LOINC, so we’re looking for an alternative way to record details about the measurement that avoids using an extension table.
@MPhilofsky
1 Like
Hello @hribarm,
I’m going to need a little more information about the source data. And you might have already explained this is in the HSIG meeting, but I don’t remember the details if you did 
For the visual acuity test you mention, is this a standard concept_id? Does the visual acuity test result in one “answer” or “result”? Are all the items you mention, i.e. distance, which chart, etc., about how the measurement was recorded actual coded values? Or do these data come across as free text strings or categorical? These items you mention sound more like Observations than actual Measurements. They are attributes about a test, but are not the actual visual acuity test.
It is possible to add multiple measurement_source_value entries per measurement_concept_id. You can put anything you want into measurement_source_value since it is not used in standardized analytics. However, this is not ideal. Speaking from experience, shoehorning data into a field is ugly for the end user.
Hi @MPhilofsky.
Thanks for your response. Visual acuity is entered into EHR fields that are typically labelled with the type of visual acuity measured along with the laterality. So there are multiple visual acuity fields, for example, a field for distance corrected visual acuity left eye, another for near uncorrected visual acuity right eye, and all other permutations. These “modifiers” will need to be extracted during the ETL process based on the field ID and could be converted to strings or concepts.
The value itself (say “20/20”) should be stored in the measurement table as a concept or converted to a logMAR float value (this is what we’re leaning towards). We can use an existing concept ID for the measurement–“LogMAR visual acuity left eye”, but we don’t have fully pre-coordinated concepts that include the distance and correction, which is why we want to store that information somewhere. One idea is to use measurement_event_id to link to a procedure whose concept is “visual acuity testing, distance corrected”, but one site has used multiple measurement_source_value concepts to store distance and correction.
Would it be better to enter observations about these visual acuity modifiers and link them to the measurement using the same event_id?
Thanks,
Michelle
I checked Athena for “distance corrected visual acuity left eye” and “near uncorrected visual acuity right eye”. And there are many standard concept_ids which almost represent the full term. And these are all in the Measurement domain, so utilizing the measurement_event_id and meas_event_field_concept_id fields to connect the two terms to fully represent the one source value. However, this isn’t ideal because you need to decide to put the result in both records which de-normalizes the data AND leaves the data open to not being fully understood because the concept_id doesn’t fully represent the data or only put the result in one record and leave the analyst to guess which record contains the data AND also leaves the data open to not being fully understood because the concept_id doesn’t fully represent the data. There’s a lot to consider. And probably more considerations than the ideas I post above. I suggest you discuss the vocabulary concerns with the vocabulary team. They might have further ideas on how to fully represent these data.