Dear everyone,
I would like to open up a discussion about how VA Charts and Optotypes can be represented in SNOMED CT.
Background: I have recently joined a team that would like to improve the openEHR Visual Acuity Test Archetype.
Our goal is to and to try and align the archetype and a FHIR Observation profile with one another (Prototype here), ideally to facilitate 1:1 mapping between their elements.
This will likely require us to keep the different concepts involved in VA testing in seperatent coded elements, so that they can be flexibly recombined (as we do in real life).
Problems: Lots of different types of VA charts and other methods to display optotypes (Projectors, Digital Displays) have entered the market in the last decades.
This means that the same optotypes are often used across different methods of presentation (Chart/Near Card/Projector/Display), especially when using digital devices.
Currently, the charts and optotypes involved in VA testing are partly represented as physical objects as children of (400912000 | Visual acuity test equipment), and partly as Procedures as Children as (36228007 | Ophthalmic examination and evaluation (procedure)),
I Think there are several areas for Improvement:
1. The more modern methods of displaying Optotypes (Projectors, Digital Displays) are missing,
2. There is no family of terms for Optotypes, which would be needed to be able to code them independently of the presentation method used.
3. Some procedure terms reference things that may be better classified as physical objects (285805006 | Cardiff acuity cards (procedure) )
3. Some of the terms used have lost their specificity as their use has changed over time. (ETDRS)
Example: While it used to be the case that "ETDRS Chart" was a term that was specific for one of these Charts which all used Sloan Letter Optotypes, the term "ETDRS" is now just used as a trademark to sell logarithmic VA Charts with all sorts of different Optotypes, which were not used in the original ETDRS Study. All of these optotypes are also used by digital displays or projectors. Just to illustrate that we need some way to independently represent Optotypes themselves as , non-physical "things" indepentend of the type of chart they are shown on.
Proposal:
Italic: moved
Bold: New
I hope this way of proposing changes is helpfull for discussion, i could move it to an excel sheet if you wish:
Charts and other Physical objects:
Changes:
1. Include Digital Visual Acuity Chart Displays, Visual Acuity Chart Projectors are physical objects, in 400912000 | Visual acuity test equipment (physical object).
2. For some of the Visual acuity test equipment, a family structure may be beneficial.
3. While I would think it would be optimal not to reference any Optotypes (like HOTV) at this point at all, but don't think it will do harm to keep them.
4. Term "Potential Acuity Meter" is ambiguous, as it may either refer to any type of device that measures potential acuity, or or more specifically to the Guyton and Minkowski Potential Acuity Meter.
Parent: 400912000 | Visual acuity test equipment (physical object).
Children:
- Accommodative rule (physical object)
- Visual Acuity Chart Projector (physical object)
- Digital Visual Acuity Chart Display (physical object)
- Near card (physical object)
- HOTV cards (physical object) {or maybe deactivate, as it mixed optotype and card concept?}
- Allen cards (physical object) {or maybe deactivate, as it mixed optotype and card concept?}
- Potential acuity measurement device (physical object)
- Laser inferometer (physical object)
- Guyton and Minkowski Potential Acuity Meter (physical object) {more specific}
- Handheld Retinometer
- Visual acuity chart (physical object)
- Snellen chart (physical object) {Widespread use, usually implies use of Snellen Letter Optotype ?}
- LogMAR Visual Acuity Chart (physical object)
- Early Treatment of Diabetic Retinopathy Study visual acuity chart (physical object)
- Bailey-Lovie Visual Acuity Chart
- Golovin-Sitsev table (physical object) {apparently widely used in post-Soviet States}
- Monoyer Visual Acuity chart (physical object) (from France, also used in italy, i think the optotypes may be non-standard)
- Preferential Looking Test Cards (physical object)
- Cardiff preferential looking test acuity cards (physical object) { specify PLT use, move from procedures?}
- Keeler preferential looking test acuity cards (physical object) {specify PLT use, move from procedures?}
- Teller preferential looking test acuity cards (physical object) {specify PLT use, move from procedures?}
Optotypes:
Here is my current collection of Optotypes which I think we may want to consider, I linked some resources where available:
| Landolt C Optotype | normative by European Norm EN ISO 8596 for VA test |
| Sjogren's Hand Optotype | I think this may not be used much anymore |
| Lea Symbol Optotype | very important for testing Visual acuity in Children, widespread |
| Sloan letters Optotype | most widespread letter optotypes, used in many different charts. |
| Cyrillic letter Optotype | Still in use in Russian-Speaking countries as far as I know. |
| Snellen Letter Optotype | widely used |
| Tumbling E | widely used |
| HOTV Letters | widely used |
| LVRC Letters | outdated? |
| 1968 British Letters | outdated? |
| 2003 British Letters | not sure if widely used, comments from UK? |
| European-Wide Letters | |
| Cardiff Acuity Test Symbols | widely used, but may not be necessary to include as these only occur on the Cardiff PLT test cards as far as I know, |
| Kay Pictures | Already there! 258042006 | Kay pictures (physical object) |
| Patti Pics | widely used |
| Allen Figures Optotype | still in use in Germany at least. |
| Auckland Optotypes | relatively new |
| Amsterdam Picture Optotypes | mostly used in Netherlands |
| Precision Vision Number Optotype | at least some use. |
| Lea Number Optotype | charts still being sold, not sure how widely used |
I am uncertain as to which category these would best belong to, as they are not physical objects (esp. when displayed digitally)
I was wondering which may be most suitable, because there does not relly seem to be a category for symbols:
- Observable Entity? (they are some sort of entities and certainly are observable)
- Procedure? as in the act of displaying a type of optotype to the patient being a procedure?
or maybe even as a group of "Special concepts"?
Proposed family structure:
(Those with uncertain amount of use are shown in brackets)
- Optotype
- Letter Optotype
- Sloan Letter Optotype
- Cyrillic Letter Optotype
- Snellen Letter Optotype
- HOTV Letter Optotype
- LVRC Letter Optotype
- (1968 British Letter Optotype)
- 2003 British Letters
- (European-Wide Letter Optotype)
- Number Optotype
- Precision Vision Number Optotype
- Lea Number Optotype
- Precision Vision Number Optotype
- Orientation-Type Optotype
- Landolt C Optotype
- (Sjogren's Hand Optotype)
- Tumbling E Optotype
- Pictogramm Optotype
- Lea Symbol Optotype
- Kay Pictures (move from 278211009 | Printed material (physical object)
- Allen Pictures
- Auckland Optotypes
- Amsterdam Picture Optotypes
- Letter Optotype
I think it would be usefull to use this structure, because there may be instances where the precise type of optotype is not known, only the fact that it is a number optotype.
I hope that this is helpful for a start, but I sure that there are some more optotypes in use worldwide, especially in regions which don't use the latin alphabet.
I would be very gratefull for everyone's thoughts on this!
Lars
9 Comments
Ian Rodrigues
Lars Fuhrmann This is fantastic work! I think your suggestions for the revised structure and terminology seem very sensible.
I'm by no means an expert in this area, but I do not see anything that comes across as being potentially controversial. It would be great if anyone else in the CRG would also be able to kindly review this proposal and if we have agreement, the next steps would involve working with Elaine Wooler and the SNOMED team to start getting these changes authored in SNOMED. Many thanks
Anthony Khawaja
Thanks Lars and Ian. I agree, this definitely looks like a very thoughtful update for an examination finding that has developed considerably over time. We had quite some discussion over whether SNOMED codes should be pre- or post-coordinated, and agree post-coordination was the only way to sustainably handle things like this. As well as all the charts/conditions, you have different distances, corrected, presenting, pinhole etc.
Would it make sense to have optotype as another coded part of a post-coordinated visual acuity set of codes? We would need "Unspecified" and "Unknown" as well. So, a post-coordinated VA would include:
e.g. Left visual acuity
Scale - e.g. LogMAR, Snellen, fraction
Chart type- e.g. illuminated, digital etc
Distance
Optotype
Best-corrected?
Presenting?
Pinhole?
What does everyone think?
Thanks
Lars Fuhrmann
Hi Ian and Anthony,
I'm glad that you think this useful, Many thanks for your feedback!
Sorry this turned into another essay:
About the discussion of pre- vs. post-coordination: am i right in thinking that most of this controversy is based on the assumption that the entirety of a VA test needs to be modelled via a single (pre- or post-coordinated) expression?
If so I think it is worth considering that this assumption applies neither to openEHR nor to FHIR.
Both offer the opportunity model VA data by associating the value of the test result with a multitude of coded and quantitative(!) elements .
I may be a bit biased about this because I have spent the last months building both a prototype FHIR VA profile and (more recently) a prototype for a revised openEHR archetype this way.
The mindmap view of the archetype draft may be most informative, you can already find the proposed optotypes in there...
I think that as long as we are thinking about data that is still to be used clinically for the benefit of individual patients, seperating out the concepts into multiple data elements like that offers quite a few benefits, including:
- allowing us to model continuous components (such as Lens powers, Distances, Brightness, Contrast) while maintaining a pre-defined relation to the VA result.
- flexibly model multiple corrections for a single eye, or different corrections for each eye for binocular tests
- not have to worry about a carthesian explosion of complicated pre-coordinated terms
- specify cardinalities for each element of the VA test within the FHIR/openEHR syntax
- Build a maximalist model without having to draw a line between the testing parameter combinations that are "needed" and those that are not, leaving the person performing the VA test free to pick and mix as they see clinically fit.
- once the models are mature we could have the balloting of a standard implementation occur within widely recognized open standardization communities (HL7 international/openEHR)
- our requests to SNOMED or loinc will be simple and "clean" and thus hopefully easily agreeable, because we do not need to pre-coordinate different types of concepts (not even laterality!)
- the openEHR Archetype modelling typically works like this anyway
- I think it would be extremely challenging to build valuesets post-coordinated visual acuity terms in FHIR, and to get these to work with the FHIR validation algorithms.
There are downsides:
- Most proprietary EMR/EPR currently only have one identifier per "type" of VA test (but this could be mapped to multiple elements in FHIR i would think)
- It is challenging to implement multiple elements being generated for each VA test in terms of data entry, but i think this is solvable with good UI design (not 10 drop-down menues per VA test, please)
- Not sure if this approach can be extended 1:1 to OMOP, which would be great to discuss with Sally Baxter , Kerry and Michelle (just to reiterate that it would be great to have the latter two in the CRG as well!)
- Even if a multi-element openEHR/FHIR standard would have to be mapped to a 1 VA test = 1 Expression system for OMOP et al: because we are ideally building a standard maximalist data models only one such mapping definition would be needed per version of the standard not hundreds of ETL pipelines fitted to proprietary data models, so is may have to put this point to the upsides.
_________
A bit of my motivation is that I think communicating the "components" or testing parameters of a VA test may be just as important as the result itself, and in a perfect world any VA test would be documented in a way that allows other colleagues to replicate the exact same test in order to be confident that any change in VA is due to the patient..
This may not be as important for aggregate, secondary data, but I think especially data models used for inter-provider data exchange should be able to serve as instructions for replicating the VA test in all aspects which are relevant.
Regarding the VA Units, this is my current "collection":
Are you aware of any that I have missed?
Both openEHR and FHIR would expect units to be coded in UCUM, which I would prefer as well, but I am not sure if all are appropriate for inclusion there.
I did request the inclusion of LogMAR, Decimal and VAS there a while ago, but have not yet gotten a response..
Am I alone in thinking that it is surprising that there is not a single unit of visual acuity in UCUM? I mean, the "Krunkel Unit" made it in there..
Do you know anyone involved in vision science that should invite for feedback on the proposal?
This may be a good ressource to get an idea of who may have special expertise concerning VA testing, if you think it's appropriate I can see who I can invite to participate from germany.
+ Regarding the "unknown": not sure if needed within the Optotype collection or if generic 261665006 | Unknown (qualifier value) | would suffice? Maybe Elaine Wooler could advise?
Many thanks!
Elaine Wooler
Hi Lars Fuhrmann 261665006 | Unknown (qualifier value) | should suffice if the answer to an observable question - Optoptype used (observable entity) which can be post-coordinated with the specific optotypes or 261665006 | Unknown (qualifier value) I think these will probably still fit best as Physical Objects given that although they can be in digital form they can also be physical objects but I will also discuss this with my colleagues.
Lars Fuhrmann
Thank you!
regarding "physical object": I thought about that a bit more I don't have any objections to putting in the Physical Object family
At least I can't come up with a scenario where that would be problematic.
What would you suggest the next steps should be regarding the optotypes and Charts - should we try and invite Vision Science/Pediatric ophthalmology experts to review? (Optotype choice tends to be most important for children)
I'd also be open to starting a visual function working group as Anthony suggested, so that may be a good step anyway.
Lars Fuhrmann
Hello Elaine,
Anthony Khawaja
Thanks Lars. The downsides you mention are important as it can impact implementation. I don't know the correct answer, and maybe our SNOMED friends can share any examples of how EMRs have handled fields which require post-coordination of multiple codes.
Perhaps Lars can start a visual function working group of the CRG and invite others to join? We initially wanted to wait till glaucoma phase 1 was finished (nearly there!) but given your momentum, I think you should kick start this.
Ian Green - have we added Kerry and Michelle (I think previously requested by email)?
Lars Fuhrmann
I just had another idea:
I think it makes sense to differentiate near cards by whether they depict optotypes or whether they are reading cards with segments of text.
Reading visual acuity is something different than VA measured with optotypes, so there should be some way to keep this apart in terms of the instrument (the near card) used.
maybe 2 more children of the near card (physical object):
- Optotype Near Card (physical object)
- Reading Card (physical object)
Thoughts?
Elaine Wooler What would you suggest we do next to move these requests forward?
Many thanks!
Elaine Wooler
Hi Lars Fuhrmann to move the requests forward, we would need agreement on the final list of required concepts. You have already been helpful with references which is one of the requirements for submissions for addition to SNOMED CT. I can then see clearly what is required and be in a better position to advise on next steps and possible timescales.
It might be helpful for you to speak with a member of the SNOMED Implementation Support team, so I will reach out to them to highlight your work and the challenges you have described.