# Visual Acuity Archetype Discussion **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2025-02-09 16:42 UTC **Views:** 946 **Replies:** 29 **URL:** https://discourse.openehr.org/t/visual-acuity-archetype-discussion/6308 --- ## Post #1 by @Lars_Fuhrmann Hi everyone! Many thanks to everyone who took part in Monday’s call on archetype development for ophthalmology—especially @heather.leslie @ian.mcnicoll and @bna for sharing their insights. Our consensus was that further development of the (not yet published) ophthalmological archetypes is necessary. We agreed to start with the Visual Acuity (VA) archetype, which has been in suspended review for more than 10 years, but make sure we don’t treat it in isolation. I know my approach may not be standard for archetype revisions, but a few months ago I prototyped an “archetypical” VA FHIR profile, which we evaluated it using ophthalmologists’ descriptions of “complicated” VA testing scenarios. I learned a lot from that, so I used that information model as a basis to build a draft VA Test archetype revision, before Heather had the chance to warn me that I am “jumping the gun” by doing that - apologies! Nonetheless, we agreed it would be useful to upload my draft into the Ophthalmology Collaboration Incubator and discuss it here. I recognize that, as I’m new to this process, not all my suggestions may align archetype conventions—but I hope that at least some of them will help us discuss and progress. Side note: I have encountered a bit of pessimism among some ophthalmologists about whether it’s even possible to build international agreement on data models for concepts like VA testing. I think it would be amazing to demonstrate that capability, and I hope that this would encourage more eye care professionals to join in on the modelling efforts. Below are the most significant differences between the [previous version](https://ckm.openehr.org/ckm/archetypes/1013.1.1291) and [my current draft](https://ckm.openehr.org/ckm/archetypes/1013.1.7723) of the VA Test Archetype: 1. **Reducing the scope to a single VA test** * **Change:** I reduced the archetype’s scope to a single VA test with a single result per event by lowering the cardinality of the results details cluster from 0..2 to 0..1. * **Reason:** It’s not uncommon for the protocol or state to differ between the right and left eye (for example, one eye may have unilateral blepharospasm or another type of correction, especially shortly after cataract surgery). Presuming that two VA tests are "joined" by the same state and protocol may induce ambiguity if we are not certain whether this was actually the case or if it is an artefact of two VA tests being in the same event. Concerning the "Overall Interpretation" of multiple tests... 2. **I adjusted the Comment and Interpretation elements.** * **Reason:** Previously, each result cluster had an “interpretation” element but no dedicated “comment” element. Meanwhile, overall interpretation and comment were recorded at the event level, applying to up to two tests. In my experience comments are either about a specific VA test or about all VA tests performed within an encounter. For the latter, maybe it would be suitable to add an Evaluation event and "overall Interpretation" text element to the "[Visual Acuity Study](https://ckm.openehr.org/ckm/archetypes/1013.1.2143)" Archetype? This way we the overall Interpretation could be about any number of VA tests. 3. **Units/Scales** * **Change:** My Draft uses a single element for the VA result value and a separate coded text element to indicate the unit or scale, rather than having one element per unit/scale. * **Reason:** This could simplify querying, the downside is that specifying range and precision for each unit might not be possible. I’m not sure about this, as I haven’t seen other archetypes handle it this way. What will matter to users at the application level is that manually choosing the unit for every VA test would be terrible for the usability and should be avoided. Just as an inspiration, [here is my sketch of an app](https://larfuma.github.io/VA-ui-prototype/) that reactively recognizes the unit before the VA test is saved, although something like this could also be adapted to a model using one element per unit/scale model. 4. **Reworking Refraction:** * **Change:** I moved the refractive correction from the state section to the protocol section. * **Reason:** * Refractive correction is under the direct control of the optometrist/ophthalmologist and is actively adjusted during the test - using a phoropter, for instance, or even just by telling the patient whether or not to keep their glasses on. * It’s common to perform multiple tests on the same patient with varying corrections (e.g., without glasses, with glasses, with subjective refraction, with subjective refraction plus pinhole). Adjusting the refractive correction is, in my view, an intentional part of the testing protocol, rather than a part of the patients "state" * The previous archetype allowed 0..2 refractive correction clusters without an element to specify which correction applied to which eye, not sure how this was meant to be used. * **Additional points about Refraction/Lens Specification** 4.1 I propose we use the position in front of an eye as the cluster slot, because this gives us the versatility we need to model different (or multiple) things being in front each eye. It is not all that unusual to put multiple "things" in front of the same eye (Contact Lens overrefraction/Own glasses+Pinhole occluder). For binocular tests a unilateral post-operative state or contact lens may also necessitate the capability to model different "types" of correction between the right and left eye at the same time. I could not yet think of a scenario with 3 things in front of the same eye, so i put the the cardinality to 0..4 for now. 4.2 There’s a tradeoff between having a single slot with an element to designate eye position like my draft, or separate slots for right and left eye corrections like this: ![image|357x206](upload://fA4h47GRfIyQXwVF0qjgjT8YVKw.png) In my current draft, for monocular tests it would be possible to "imply" that the correction used was in front of the eye being tested without explicitely using the "Position in front of the left or right eye" element, but I'm not sure which way is better. 4.3 I propose we model the measurement of refractive error (i.e. “Refraction”) distinct from the specification of lenses, using two seperate archetypes. Previously, the same cluster called "[Refraction Details](https://ckm.openehr.org/ckm/archetypes/1013.1.1292)" was used both within the [refractive assessment Archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.1399) to describe a measurement of refractive error and within the VA test Archetype to specify the values of the lenses used during testing. Instead, I would propose a new archetype called "[Lens specification](https://ckm.openehr.org/ckm/archetypes/1013.1.7730)", to describe lenses in whichever context they are used. This way the archetype can include elements to describe a Lens that go beyond what is measured as part of a refraction, such as prism correction, near addition, base curves, diameters (in case or ontact lenses) This should be useful when modelling lenses which are part of devices or lensmeter measurements as well. Within the (narrow) context of a VA test, we are **not** measuring a refractive error, but we are using a refractive correction, ie specific lenses during the test. Therefore, the “Lens Specification” archetype would be appropriate here to model the lens details used during VA test. Using two "position in front of eye" clusters in front of the same eye, it would be possible to model contact lens overrefraction, including all lens parameters. 5. **Removed of the “[Pupillary Exam](https://ckm.openehr.org/ckm/archetypes/1013.1.2772)” Cluster Slot** * **Reason:** In practice, a pupillary exam is often performed before or after the VA test rather than during it. Such findings could be captured in a separate evaluation or at the template level. I would suggest that relevant aspects (like medically induced mydriasis) of the pupil state could be recorded in the “Patient Circumstances affecting Result” element. In my experience, noting the (dilated) pupil state as a comment about the VA test is usually done if the pupil state is *transiently* altered, usually due to dilating eyedrops . In patients with permanent Pupil alterations i think this state would be documented elsewhere and not typically need to be repeated in the context of a VA test. 6. **I reordered the elements describing the method/charts.** * **Reason:** There is a high but finite number of charts and optotypes in use which may need to be specified in some use cases. The coded terms that I added align with [my proposals in the SNOMED eye care CRG](https://confluence.ihtsdotools.org/display/OCRG/Visual+Acuity+Charts+and+Optotypes). Maybe we could simplify further by may eventually allow merging the general method and chart elements. 7. **Handling “Best Corrected Visual Acuity” (BCVA):** * **Change:** I separated the BCVA designation into an isolated boolean element. * **Reason:** This term is popular for secondary data uses, but it is insufficiently standardized, and often it is used interchangeably with actual specific types of correcting a refractive error, which is problematic. If I tell you that Usain Bolt won a gold medal wearing "the best" shoes, you will not know which shoes to give him if you want to replicate the run to see if he is still as fast. For secondary data uses it may be sufficient to know that the performer thinks it was the best correction, but for individual patients the exact correction which was used is much more important. While the only thing I would personally call a "BCVA" is a VA test with a correction based on a subjective refraction (performed on the same day) [not everyone adheres to that, even in scientific publications.](https://onlinelibrary.wiley.com/doi/10.1111/opo.12310) You can probably tell that I'm not a fan of the term, but I expect there to be cases where a BCVA designation is wanted. I just think everyone is better off if this is dealt with in a separate element, so that it does not collide with elements that describe what objectively happened during the VA test or which correction was actually used. 8. **Minor Elements:** There are some smaller things or elements which will rarely be used such as ambient lighting, background luminance or contrast, maybe worth following up on after we sorted out some of the above points. I hope you don't mind my suggestions even if some may seem bit radical. I’m very hopeful that we can refine the VA archetype to a publishable level at some point! I would really appreciate your feedback and, again, sorry for jumping the gun! ;) --- ## Post #2 by @SevKohler 1. Agree. 2. Yes, I think this should go to the acuity study if it’s naturally used there. Is there no possible interpretation linked to single elements? If there is the possibility that people need that, I would add it. An interpretation is something else than a comment, after all. 3. Hard to judge, but as far as I can see here, there are DV_Quantities and CODED_Texts as results. I guess we need an additional Unit field for the coded text answers (DV_Quantity itsefl has a unit) ? About the app, in general, this is something the front-end can solve. I wouldn’t model this into the model just because of that. The ability to cover as much as possible is much more important. 4. In-front of eye: I would use 0..n here. People can constrain that down to whatever they like in the template. 4.2 I can’t judge. 4.3 Sounds useful. 5. Why not add the pupillary exam cluster to https://ckm.openehr.org/ckm/archetypes/1013.1.2143 ? This would make it more similar to the laboratory_test_result (in addition to the overall interpretation) that has analytes. Otherwise, template-level is always a solution. Another possibility would be to link it, if it would act more like a reason for the test being done. 6. I think this makes sense. If there’s a need for more, we can still expand the archetype. I would suggest either leaving this as an open CODED_TEXT or trying to cover it as good as possible. 7. Too clinical for me, havent explored ophthalmology yet. --- ## Post #3 by @chrisschulz Great work Lars. I agree with all of your points. 4.2 I think it makes sense to separate out into each eye. Let the front end deal with it. But imagine a scenario (although rare) where you are testing binocular VA with a contact lens in one eye and a lens in front of the other eye. --- ## Post #4 by @Lars_Fuhrmann Thank you Severin! 2. OK, I agree, should be fine to have both "comment" and "Interpretation" elements per single visual acuity test, I'll add it in the next version 3. Clinically, i think the coded test answers like "sees hand movements" would not need a unit as they are qualitative observations in the same way as "the patient is able to stand on one leg" would not need one. However, maybe they need one here anyway because the "Unit of Result" element may have to be be 1...1? For example, a Result of "0.5" could be either logMAR or decimal Unit, and therefore be ambiguous if "Unit of Result" is empty. Is this something that is typically mandated to be 1...1 on the Archetype level? Regional Conventions about this are often strong enough that the unit is omitted, just "0,5" would nearly always be interpreted as decimal in Germany, but as logMAR in the USA as far as I know. In case "Unit of Result" is 1...1 then the coded answers like "Sees Hand Movements" would need to have some option for it, maybe " Coded Qualitative Observation" or something. I think i might include something like that just in case "Unit of Result" is set to 1...1, even if it is just the template level. Regarding DV_Quantity already having a unit: True, but if we try to capture the unit within DV_Quantity in a coded manner, wouldn't UCUM be expected there? I don't think we can rely on UCUM for VA scales; as the most important units are defined in terms of the visual angle, which is (apparently) dimensionless and therefore hard to get into UCUM. So I think we may have have to solve this using LOINC or SNOMED, not sure how that would work within DV_Quantity? 4. OK, I'll put 0..n in the next version 5. I'm not sure if I would expect the Pupil examination cluster in the Visual Acuity Study either, I think I'd be in favor of leaving it to the templates (other than a coded "Mydriasis" option in the "Patient circumstances affecting result") I don't think links are needed as I would not typically consider a VA test to be a reason for a pupil function test or the other way around, they are both basic parts of a general ophthalmic assessment. 6. OK, I would think I would just leave it open for now and expand coverage including SNOMED requests. If some super specific chart is not included, there is still just "Visual acuity Chart" in the "general method" element. Again many thanks for taking the time to comment! --- ## Post #5 by @Lars_Fuhrmann Hi Chris, Thanks for your kind feedback! regarding 4.2: my idea was that in a scenario like a binocular VA test with different correction in front of each eye this would work by having 2 clusters of "Position in front of an eye", as it is 0..4 (and will be 0..n) : One with "Position in front of right or left Eye" = "Right Eye Position", and one with "Position in front of right or left Eye" = "Left Eye Position", and each with different "Type of correction/etc.." But If it makes more sense to split it up as shown in the screenshot then I'll do that! Edit: Just noticed I had already changed the element name to "Type of Correction", even if it contains a coded text for "fogging lens", which is used to do blur the vision. So it's not *really* a correction if we are being super precise... but I think it's neither worth an element of it's own nor a renaming of the "Type of Correction element", objections? --- ## Post #6 by @siljelb Hi Lars, and thank you for taking a lead in progressing this archetype! We're preparing for a likely order for functionality to support outpatient intravitreal injection therapy, and visual acuity is one of the archetypes we'll need for this purpose. So I'd like to participate in this work. I agree with several of your proposed changes, but one change I'm not enthusiastic about is splitting the magnitude and unit from the DV_QUANTITY data type into two separate elements. This is problematic both from the generic openEHR POV and from an implementation POV: * Generically, in openEHR the magnitude and units of a quantity are expected to be found at their assigned paths within a single instance of DV_QUANTITY, and splitting them up into different elements would complicate querying. * When implementing solutions using low code tools, these tools expect quantities to be expressed as DV_QUANTITY data types as specified, and trying to split them into separate archetyped elements would complicate implementations. Regarding the issue of units, I saw your proposal for adding these units to UCUM, and ideally this would be the way to get these units represented. However, my impression is that UCUM isn't staffed to handle requests like this, even less than openEHR is. We recently had a discussion about this issue [here](https://discourse.openehr.org/t/ucum-dependence-governance/6153). One thing we could do to handle the issue though is to add our own UCUM-compatible notation to [our own units file](https://github.com/openEHR/specifications-TERM/blob/master/computable/XML/PropertyUnitData.xml) which is used by Archetype Designer. See for example [this commit](https://github.com/openEHR/specifications-TERM/pull/20/commits/abd8fb5a6b2bcdf6ca25e088865feb567dfaa42e) to add some units variations used in audiology. --- ## Post #7 by @ian.mcnicoll I agree Silje. Lars i can jnderstand what you are trying to do here but i dont think that ucum extensions are either desirable or feasible. It would be desirable to have a single element for the visual acuity score but you risk losing knowledge from the archetype which has then to be documented and applied elsewhere in the development. I wonder if we could find a middke road. --- ## Post #8 by @Lars_Fuhrmann Hi Silje and Ian! Thank you both very much! I think this is a key issue of VA-weirdness where ophthalmologists really need your expert help, so i am glad you picked this up. I also think it is great that you have figured out a way to not depend on UCUM all of the time. Please know that I'm not super-enthusiastic about my suggestion (1 result + 1 coded unit element) either - I just thought it was worth considering. Ill just try to rephrase our challenges first to see if you agree with my understanding of them: 1. Ensuring templates can handle multiple different units of VA, because which units ophthalmologists use depends on clinical circumstances. 2. Minimizing the risk that VA compositions contradict themselves, which they may if they contain multiple "result" elements with unequal values 3. Keep querying as generic as possible. 4. Keep the unit handling as generic as possible - which would be in the DV_Quantity instance itself 5. Handle the fact that snellen ratios are ratios of meter or feet distances, even if DV_Proportion does not support units (conventionally 20/x is 20ft/x ft and 6/x is 6m/ x m but I think it needs some explicit handling, as sometimes things like 1m/35m are used for patiens with low VA) Am I right in thinking that there is no generic solution for point 5? Maybe that can lead us to the "least non-generic" solution! I can think of three solutions to keep feet ratios and meter ratios apart: 1. **Separate elements per unit, including two DV_Proportion elements for ft and m snellen ratios,** [like in the previous Archetype "Notation" Cluster](https://ckm.openehr.org/ckm/archetypes/1013.1.1291) * requires enforcement that only one result element is used somewhere else (application level?) * Not that easy for querying because we would need OR statements for each unit like: *Snellen_Meter_Ratio_Result magnitude > 0.5 OR logMAR_Result magnitude <0.3* right? (both would mean better than 20/40 Vision), and a method to ensure both the VA result and it's unit are retrieved. * low code tools would expect there to be no unit for DV_Proportion elements, but maybe this could be handled that via the element being defined in terms of being a ft or m ratio? As long as the user sees "meter snellen ratio" it is preferable to display 6/6 and not 6m/6m * no adaptation of low-code tools needed for elements using DV_Quantity, as long as we can use the ucum-compatible notation you mentioned 2. [My version](https://ckm.openehr.org/ckm/archetypes/1013.1.7723) **where a single "unitless" DV_Proportion is annotated by a coded text "unit of Result" element** * enforcement of unique results is handled by 1...1 of "Result" element. * Difficult for querying: I guess we would need nesting like: (Result magnitude < 0.3 AND Unit Result = logMAR) OR (Result Magnitude > 0.5 AND Unit_Result = Snellen_Meter_Ratio), right? I'm not very familiar with AQL yet. * Would need low code tools to adapt more, because it's all non-generic. 3. Like solution number 1 (old archetype version with many result elements), but not using DV_Proportion for snellen ratios and instead **splitting the ratios up into "Snellen Ratio denominator" and Snellen Radio numerator" DV-Quantity elements.** * great in terms of generic unit handling * difficult, but doable for querying? the actual ratio could be calculated in the WHERE clause before comparing, right? * need 4 elements (meter numerator/denominator, ft numerator/denominator) if specific element bindings to SNOMED are desired for ft/meter * difficult to enforce that 2 result elements are OK as long as they are numerator and denominator of either ft or m. I think my key questions is this: Is it OK to rely on applications to enforce that there should only be one unique result per event across multiple result elements? If yes then after writing this i would tend towards having one element per type of unit too (solution 1), unless you would additionally prefer the ratios to be split up into DV_Quantity for numerator and denominator. Many thanks! EDIT: I edited the draft to have 1 element per type of unit, in addition to some of the changes that were suggested before. Do you think [something like this version](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGQxMzM4YjFlMjJkYzQ3ZTdiNDYwOTk1MWY2ZTA4NjE3) would be more suitable? --- ## Post #9 by @Lars_Fuhrmann brief clinical background why ophthalmologists may need approximately 5 different units in the same template, or at least the same application: Ophthalmologists in Germany use decimal notation in the range of 2.0 (best)-0.05(worst), but we can't go lower that because bigger letters *physically do not fit* into the optotype projection area. That means if a patient is unable to recognize the 0.05 optotype, we take a [physical chart like this](https://www.oculus.de/de/produkt/oculus-sehprobentafel-buchstaben-in-plastik-eingeschweisst-v-01-125/) and holt it at 1m distance from the patient. We then use meter snellen notation to denote the smallest line that the patient was able to read, however, because the numerator is the distance at which the test was performed the result is something like 1m/35m, or 1/35 (not 6m at the start which is usually the standard for meter snellen ratios) If the largest (1/50) Optotype is not recognized we use qualitative measures such as "Counting fingers" or "Hand movements" Except when we perform VA tests in clinical studies! That's when we usually use Logarithmic Charts such as the ETDRS Charts and often denote the result in "Letters Read" or logMAR. Hope that helps in case anyone is wondering whether this complexity is just theoretical.. I'm afraid it's not. --- ## Post #10 by @Colin_Sutton It seems to me you need multiple templates, e.g 6m snellen, 1m snellen etc. --- ## Post #11 by @Lars_Fuhrmann Hi Colin, Thanks for the feedback I know I brought this up myself, but now I'm not sure if we should actually worry about how people will template this as long as the archetype itself is unabiguous? What I meant to say was that the units used may depend on the clinical circumstances, and applications will have to accomodate that - whether by seperate templates per unit or by some application logic that always only uses one of the unit elements per composition - right? --- ## Post #12 by @Lars_Fuhrmann Many thanks to everyone for your valuable feedback! While a lot of decisions still have to be made i think we have been rather successfull in finding issues that warrant further discussion. So I think this would be a great time to **plan another online meeting.** I would suggest we focus on: * what changes and arrangements need to be made to the draft before we transition into the CKM Review process for the VA Archetype * Outlining the relationships to other Archetypes (Refraction, Lens Specification, Vision Prescription(?), Lensmeter Measurement (?)), even if we might not immediately start developing these. * Ways to make ophthalmic archetype modelling more sustainable, in terms of people, resources, projects... **If you are interested please indicate your availability in [this doodle](https://app.rallly.co/poll/4JprGwJrlZLH),** [This](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGQxMzM4YjFlMjJkYzQ3ZTdiNDYwOTk1MWY2ZTA4NjE3) is the current Archetype draft, with changes as suggested by @SevKohler @chrisschulz @siljelb I'll clean it up a bit more in terms of spelling, add some more bindings and upload it to the CKM soon. Or does it make sense to open a git repository for this? I know UI mock-ups are not typically part of Archetype development, but I think they are quite important to demonstrate to clinicians that a complex VA model with many elements does **not** have to result in horrible user interfaces. So feel free to play around [with this mock-up](https://larfuma.github.io/VA-UI-Prototype-2/), it looks simple, but it supports all units, default and explicit distances, chart types, optotypes, multiple corrections/pinhole occluder per eye and specification of lens powers. --- ## Post #13 by @Lars_Fuhrmann Thank you very much for taking part in the Poll! We'll settle on an monthly meeting time for what we could call a little "Ophthalmic Archetype Modelling Group" soon. I'll be on the last Thursday of each month, open for anyone to join in of course. I'll post a link here. _______ 2 weeks ago we already had a very productive meeting with @siljelb , @SevKohler , Michelle Hribar, Sarju Athwa and myself, here are the changes of the VA prototype we discussed: 1. Make “Eyes Examined” non-mandatory, will usually be mandatory on template-level. ->done 1. Worry about SNOMED codes (right eye proper vs. right eye region) a bit later, -> OK, but I want to keep in mind that it may be a good idea to use “region” generously when we just care about the laterality and not what is or is not part of the actual eyeball) 2. We agreed that the result details structure (1 element per notation type) is generally OK, but that I should check if all of them are needed -> removed those I have not seen in clinical use myself 1. They don’t really need to be children of the “results details” -> moved them to be direct children of “data” 2. Check for which ones it is realistic that they will be the product of a derivation -> removed those where I would consider that unlikely such as Jaeger or N-Font size 3. Rename “Patient circumstances affecting result” to “confounding factors”, even if some of them specifically indicate high reliability/cooperation. (Esp in children it may be important to note good cooperation to indicate that lack of cooperation does not explain a low VA) ->done, but specified what may be included in description. 4. Remove 0..4 limitation from corrections -> it’s 0…* now 5. Keep correction in front of right eye and correction in front of left eye as separate elements, but move them to state, as they are very likely to change from test to test. -> Moved to state. Whether these are to be merged to one cluster containing an element indicating laterality will discussed between @siljelb and @ian.mcnicoll *Note: This was also in state in the “old” version, Initially protocol felt like a better fit to me but Silje showed me that state makes more sense as the correction is very likely to change between events.* 6. Rename the old “refraction details” archetype to something like “lens specification” and have it fill that role, while (once their is a use case) a new archetype will be needed for Measurement of refraction. -> I tried that, but renaming the archetype breaks the archetype history, here is the current lens specification archetype - **any ideas?** 7. We didn’t get to all elements because there is just so much to cover 8. Both in Norway and in Germany there may be use cases for the Intraocular Pressure Archetype, I’ll have a look at that soon, @siljelb cautioned not to jinx it by saying it will be easier than VA, so I won't ;) 9. General advice from @siljelb : When figuring out the structure of the archetype, esp. What’s in state/protocol/data it is very helpful to experiment with how templates would be designed (can be done within the archetype designer software) You can find the current Archetype Draft [here](https://ckm.openehr.org/ckm/archetypes/1013.1.7723/mindmap) ________________ Side Note: I recently got to talk about openEHR and the Archetypes to clinicians and vendors an ophthalmology conference in Germany. I was quite surprised how quickly everyone got the basic idea of it and how many of them **want** to re-use internationally agreed-upon data models - they're just assuming that that's not an option, partly because **nobody** had heard of openEHR before.. Awareness of openEHR + "we already have a good VA Archetype"= Use cases will pop up I think.. --- ## Post #14 by @heather.leslie Hi Lars, Thanks for all your good work here. It is looking much better from an Editorial/CKA point of view, particularly aligning each quantitative result type with its' respective unit. Given I won't be able to participate in the next meeting, some thoughts/questions: * Concept description - this relates to the concept of the test, not a definition of visual acuity and usually in simple terms. Consider something more like: 'An assessment of the clarity or sharpness of an individual's vision.' * Purpose - I'd suggest that we document this to reflect that this archetype is to capture a result from a single examination, whether left, right or both, rather than a single test which could still be construed as an entire test which includes both eyes. * Editorial comment - we universally refer to 'an individual' rather than a patient or subject in archetypes. * Editorial comment - use Sentence case for all data element names, except where we need to include acronyms. * Editorial comment - there are many descriptions that will be needed before the archetype can go out for review. [quote="Lars_Fuhrmann, post:13, topic:6308"] Make “Eyes Examined” non-mandatory, will usually be mandatory on template-level. ->done [/quote] * In the quote above, I assume this means that you have identified a use case where this data element will not be required as the 'index' element? Can you please explain what this is?, and if this is agreed, it will be worth adding a comment explaining why this is not mandatory. From my understanding and looking at the archetype as is, identification of which eye or both eyes if fundamental for any safe and accurate documentation of any result, interpretation or 'test not done' status. * The 'Position in front of the eye' modelling is much better, although maybe the naming could be made clearer. In some of the Hearing project archetypes the phrase 'Aided status' is used to document a similar concept, and which could then be localised to left and right eye aids. * With respect to the notion of a single cluster vs one per eye, I think it may be helpful to combine them only if there is an additional requirement to record 'both eyes' when the aided status is identical. Otherwise keep them specific and separate. * Confounding factors usually relates to things that affect the interpretation of the result, not the carrying out of the test. In some of the hearing archetypes there is a 'Reliability' data element in the Protocol which was intended to capture an indication of the cooperation of the tested individual in the test process eg actively participating adult vs a distracted or distressed child. * Question: S How to make it obvious that the 10 data elements after 'Eye(s) examined' are all results. Should we consider separating the single 'Qualitative result' all of the quantitative results using a Quantitative result cluster? Should we add result to the end of each data element name? * The BCVA/BRVA tag may need some more thinking. It is not a typical way we model. Keep up the good work and kind regards Heather --- ## Post #15 by @Lars_Fuhrmann Hi everyone! @heather.leslie thank you! I'll get back to you comments soon! I just wanted to announce that based on the poll **our little "Ophthalmic Archetype Modeling Group" will meet on the last Thursday of each month at 2pm Central European Time.** I hope this is the least inconvenient choice overall, I'll update this thread as we go so that it is easy to stay in the loop even if you can't make it to the meetings. Unfortunately google calendar does not allow link sharing unless everyone's email adresses are public, which Is not great.. I'll problably move to Teams soon. You should be able to import the calendar file below which contains the link to the meeting: [Ophthalmology Archetype Modeling Group Meeting invite.ics|attachment](upload://d4TPnes4YeEyeH9zL1uPf0lCs0d.ics) (2.7 KB) Our next meeting would be on the 24. of April, I look foward to seeing you online, I'm sure there will be plenty to discuss! Kind Regards and many thanks to everyone for your help! Lars --- ## Post #16 by @Lars_Fuhrmann Hi Heather, sorry for the late reply . Thank you very much for your suggestions! * Concept Description: Changed it to: "*A test to quantify an individual's ability to resolve small objects as a measure of the clarity or sharpness of vision.* " * Purpose: Changed it to: "*For recording the results of one single visual acuity examination per event. This is normally measured by testing the individual's ability to recognize symbols at a defined distance using either the right, left or both eyes*". * Why per event? After @siljelb explained to me how protocol and state work across events, I think it maybe the best compromise is to have 1 VA test per Event (R/L or Both eyes) with a single result. Because we moved the correction to state, the archetype could contain multiple events which differ in terms of the eye being tested and the correction used, but share a common protocol in terms of what the patient was looking at and the testing distance. This seems to me to be a good compromise in terms of being able to re-use the protocol data across a tests as long as what the patient is looking at is not changing. At least from my experience it is more common for multiple VA tests performed on the same patient to differ in terms of the eye(s) tested and correction used - while sometimes our tests do differ in terms of the type of chart or testing distance but overall that variation is a bit less frequent Of course, the "protocol" variations do happen when we test far vs. near vision or crowded vs. uncrowded optotypes in a child or in patients with unilateral low vision (count fingers/hand movements tested at 1m) ., but I think it would be OK for that to require another instance of the Archetype with another protocol? As far vs. near is quite common, maybe there an argument to be made to move the test distance to "state"? Unilateral qualitative low vision results (i.e. Right eye = hand movements, Left Eye=20/20 ) innapropriately having a "chart type = snellen Chart" element in the shared protocol instead of only in the left eye test protocol does not really seem problematic from a clinical perspective because it is perfectly obvious that the chart was not actually used to determine the vision in the right eye. I know this is a bit of a shift from my earlier position of 1 Archetype = 1 Test, and I still think multiple tests per event would not be a great Idea, but maybe 1 Event = 1 Test is a good middle ground if carefully implemented? Example Template with 2 VA tests as 2 events that share a protocol: ![image|383x500](upload://dNsnHPfh7gSR8C3EmKaDYedsx14.png) * Re: Editorial comments, Thank you, will adjust and add descriptions as we go along. * Re: Making "Eyes Examined"-Element non-mandatory: I agree that this would have to be mandatory in 100% of cases at the point when an examination is documented, which is why I initially made it (or left it) mandatory. However, @siljelb suspected there may be cases where legacy data may not contain that information, lets say to integrate datasets from a studies that are "per eye" and not per patient and do not contain whether they were right or left eyes. I also considered whether there may be cases where information on which eye was tested may need to be removed so as to not break anonymization or (double)- blinding. I'm neither sure nor opinionated about this to be honest. As I understand it, it would be a breaking change to make it mandatory after it has been non-mandatory, but not the other way around, so maybe we could make it mandatory until we encounter a use case where that is a real problem? Will discuss this with @siljelb in the meeting. * Re: Renaming "position in front of right/left eye", I agree the name is not great, but I'm pretty sure we need this repeating cluster to represent the "space" where one or multiple lenses/pinhole occluders can be positioned in front of the eye. I don't think "Aided Status" would work well here as i worry that "Status" implies a single status and this may suprise people when the "Status" occurs multiple times in front of the same eye. I thought about "right/left eye lens slot"? like a virtual version of the the slots of a trial frame, where we may put things of different types such as lenses or a pinhole occluder: I mean trial frames like this one: https://www.reichert.com/en/products/trial-frame Of course we don't put contact lenses in these frames... One of the reasons i liked "position" is that there is already a LOINC code for [Right eye Position](https://loinc.org/29073-4/) and [Left eye Position](https://loinc.org/29074-2/), which would seem useful when parts of this model are used outside of the openEHR, i.e. FHIR/OMOP. I renamed it to "Right/Left eye *aid position*" for now, but I am open to suggestions... * Re: Confounding factors: I see that one could separate confounding factors and reliability, but I am not sure if there is a use case that requires these to be in two different elements. Ophthalmologists will always want to minimize the time needed for data entry, so I worry that different implemetations may just end up choosing to use one of the two for *everything* in order minimize the number of entry fields per VA test, especially if we allow text. So maybe better to keep all of them in one element, and rely on the values contained to indicate whether they concern a confounding factor or the reliabiltity? If you look at the values I am suggesting as coded text, many of these would have some relevance as a confounding factor, but also on reliability, and i think it would be ok to leave it to clinicians to interpret. So I'm just asking myself what the content or value of such an element would have to be in order for us to gain useful information by learning whether it was the value of the "confounding factors" or "reliability" element? At least, I am not currently aware of any EHR/EMR Systems that use both a "reliability" and a "confounding factors" element at the same time, most of them just have a free text comment that gets used to document these things. * Re: Making it obvious to only use one result element: I was hoping to do that via the Use/Misuse fields, but I also added "result" to the end of each data element name. Concerning moving the qualiatative results to a new cluster I'm not sure if I understand why we would want to do that. * Regarding BCVA/BRVA: I'm not a fan of these terms either as they are commonly used without a clear definition of how to arrive at the "best" correction for BCVA, or a lack of clarity which VA tests are compared in order to establish which was was the "best recorded" (i.e. does that include VAs with pinhole?, best recorded within which timeframe?). However, they are extremely important endpoints in [prospective (BCVA)](https://pubmed.ncbi.nlm.nih.gov/?term=BCVA) and [retrospective (BRVA)](https://pubmed.ncbi.nlm.nih.gov/?term=BRVA) studies, so there is no way around them. My feeling is that at least BCVA is seeping into primary documentation where it is sometimes used in place of describing the actual correction used, which is not great. BCVA = 0.1 logMAR is nice for statisticians, but does not tell us about what lenses where used for the correction, nor how we got to their lens power values (manifest refraction i hope), nor why we think they are the "best". So the one thing I am certain of is that we should not do is represent these terms within a 0..1 choice of the the types of specific correction. Having to choose between "corrected with own glasses", "corrected based on manifest refraction" or "best corrected" would keep us from able to model both where we got the corrective lens values from and whether or not we consider them a "best correction". High quality prospective studies use [rather complex protocols](https://nictu.hscni.net/wp-content/uploads/2018/09/DIAMONDS-BCdVA-and-Refraction-Guideline_v1.0_Final_01.12.16.pdf) of refraction and VA testing to produce the BCVA in a tightly controlled manner, but i found an editorial noting that [what authors call the BCVA can vary quite strongly from study to study](https://onlinelibrary.wiley.com/doi/pdfdirect/10.1111/opo.12310). I am guessing that a BCVA "Tag" is not really standard nomenclature and we don't just need to represent whether a VA is deemed to be "best corrected", but also elements where the definitions of BCVA/BRVA that are being used can be represented. So how about this? ![image|502x260, 75%](upload://rJKZ4HzHdMBVyDIZkETpBoV67so.png) [Here](https://ckm.openehr.org/ckm/archetypes/1013.1.7723/mindmap) is the current Archetype draft. Thank you for yor help, I'm really looking foward to more of our discussions :slight_smile: --- ## Post #17 by @Colin_Sutton RE: " I also considered whether there may be cases where information on which eye was tested may need to be removed so as to not break anonymization or (double)- blinding." I suggest all information should be recorded; blinding would be a feature of data retrieval depending on authorisation of the retriever. --- ## Post #18 by @siljelb [quote="Colin_Sutton, post:17, topic:6308"] I suggest all information should be recorded [/quote] I certainly agree that it *should* be recorded. However, making the any element or container mandatory means that it always *has to* be recorded, even if you don't have the data. In this case you'd have to make something up in order to be able to submit the data. Generally we only make elements mandatory *in archetypes* where missing data would make any other data contained in an archetype meaningless. An example of this is that a missing 'Problem/diagnosis name' would make 'Date/time of onset' and 'Severity" meaningless. It can always be made mandatory in any template, where required. Of course, if everyone agrees that there are *no scenarios whatsoever* where a valid VA test result could be recorded without specifying the tested eye(s), it would be fine to make it mandatory. --- ## Post #19 by @siljelb [quote="Lars_Fuhrmann, post:16, topic:6308"] Re: Making it obvious to only use one result element: I was hoping to do that via the Use/Misuse fields, but I also added “result” to the end of each data element name. [/quote] I vaguely recall discussing this in our last meeting, but I can't remember the conclusion: Do you *ever* record more than a single type of result / result unit? --- ## Post #20 by @Colin_Sutton I phrased that badly. I should have said "No information should be removed". --- ## Post #21 by @heather.leslie Hi Lars, Great progress. A few more thoughts, if I may... One of the key considerations in designing this archetype is how we define and represent a single ‘test’. The answer may vary depending on clinical expectations versus implementation and data sharing needs. From my first principles perspective, a single test should include all variations and results for each eye assessed under a shared protocol or method—captured as multiple events representing each eye/state combination. While this may result in numerous events, it preserves the integrity of one coherent test result set conducted using a single, consistent protocol. That said, I’m also not an expert in eye testing, so maybe we do need to adapt the approach as you suggest. I remain concerned, conceptually, that modelling each eye as a separate test instance is counterintuitive. It adds complexity for implementers, risks confusion by fragmenting related results, and could compromise clinical safety if test components derived from the same method are stored across separate instances. Ultimately, what would other ophthalmologists expect? How would a single test typically be recorded on paper? And from a data extraction and querying perspective—particularly for national health records or shared care—what structure would be safest and most intuitive to use at scale? The original archetype draft included a ‘Test name’ that effectively identified the selected protocol configuration. This ensured results were captured in a clearly defined context, supported coherent ordering and display in user interfaces, and provided essential context when shared with other systems or providers. I think there is value in adding this back in, if it is possible to create a relevant value set. It also fits with other test result archetype design patterns. The protocol should therefore capture the fixed context or configuration for the test (e.g., chart used). If the chart changes, that likely constitutes a different test altogether. What other protocol-level elements would trigger a new test result definition, as opposed to simply recording parameter variations within a single test? Within this structure, the 'state' attributes could then describe the variable conditions under which each result is captured. And each full named test result could then comprise multiple events—each event recording results for a particular configuration of the 'state' variables, per eye tested. Silje and I have had similar discussions with a group working on hearing test data—it’s complex! It’s not easy to explain in writing, so hopefully Silje can help convey the idea more clearly when you next meet in person. [quote="Lars_Fuhrmann, post:16, topic:6308"] Re: Making “Eyes Examined”-Element non-mandatory: I agree that this would have to be mandatory in 100% of cases at the point when an examination is documented, which is why I initially made it (or left it) mandatory. [/quote] I would strongly push for the Eye examined to be mandatory - it makes no sense to record results without stating what eye was examined. If each eye has identical results in a legacy system, even if the eye examined is not identical, then perhaps it could be recorded using a null flavour. However if the results are vary and we are not sure what the results mean, it may be better to record the legacy data simply as a text blob. Remember this archetype is designed for use in all contexts. If anonymisation of the eye examined for research needs to occur then getting the research data set fit for use should be managed by an external export/process which would include removal of the eye examined data [quote="Lars_Fuhrmann, post:16, topic:6308"] Renaming “position in front of right/left eye”, [/quote] Again from first principles, so please correct me if I'm wrong, the terms 'right eye position' or 'left eye position' feel ambiguous to me—*position* may also refer to the anatomical alignment and orientation of the eye, particularly in relation to the other eye, Also the notion of standard gaze 'positions'. Do we need to create a cluster with all the parameters/adjustments described in the trial frame spec you suggested and each type of lens used. Does 'Trial frame' need to be included as part of the naming? Is it considered a recording of subjective refraction results? [quote="Lars_Fuhrmann, post:16, topic:6308"] So maybe better to keep all of them in one element [/quote] If we design the archetype to separate the concepts it does not preclude implementers to present them in a single UI widget. However to conflate value sets for quite separate concepts into a single data point in the archetype is problematic if we need to become more specific in the future. I'd advise against this. If this was only free text recording against 'Confounding factors', this is not such an issue. In principle, the issue of the reliability of the participant is often critical to interpretation of the results eg a child who is distracted or a patient with early dementia. In this situation, the reliability is relevant for the whole test and possibly should be recorded in protocol rather than state! Hope this is useful food for thought... Regards Heather --- ## Post #22 by @Lars_Fuhrmann Hi Heather, thank you for your very helpful reply! I'll make sure we prioritize these issues today's meeting and will get get back to you. About the "Test Name": I'm just worried about trying to broadly categorize a test that like VA that is inheritely "pick and mix" regarding it's different components, as trying to pick which concepts should or should not be part of the category definition and pre-coordinating their combinations is a rabbit hole that would be great to avoid. If I had to choose just 2 concepts to combine with each other in the "test name" categories they would be "Type of Correction" and "Test Distance", to have categories like "Far Distance vision with own glasses", but even that may become difficult in cases with 2 correction types such as own glasses + pinhole. Plus we already have 2 seperate elements for these Correction Type and Distance, the latter of which es even able to distance as a quantity and not just "Far". Another way to explain my thinking: In my mind each VA test is a Lego house made up of 5-8 components "bricks" and there are many different ways to *partly* take it apart, so that it is very difficult to agree upon which bricks should "stick together" when being categorized. Depending on the clinical circumstances ophthalologists disagree which combinations of concepts are the "important" ones and should be part of categorical definitions like "Test Name", i don't really see any consensus about that is useful to us at the moment. There was an attempt to design an ophthalmic data exchange standard in the 90s in Germany that came up with 34 different pre-coordinated "Test names" vor VA testing, not ideal if you ask me, and very difficult to agree on whether we should sort VA tests into 4, or 34, or 120 Categories. So my approach with the Archetype was to completely split the VA test up into the "atomic" bricks as these are much easier to agree upon than combinations.. I hope that makes sense. And if Implementers want a drop down menu of exactly 10 different "types" of VA test by combining 3 concept elements, can't they construct that on an application level, and each combination is assigned to a specific combination of the 3 elements in the composition? Or maybe I just need to understand better how such a "Test name" categorization could harmonize with more specific "one-concept"-data elements within the same archetype? Will keep you up to date on the discussions again, many thanks, i really appreciate your advice and will rack my brain trying to come up with compromises. --- ## Post #23 by @heather.leslie Hi Lars, Again, great discussion [quote="Lars_Fuhrmann, post:22, topic:6308"] About the “Test Name”: I’m just worried about trying to broadly categorize a test that like VA that is inheritely “pick and mix” regarding it’s different components [/quote] Happy to withdraw that suggestion if it makes no sense to you. The thought was generated by a previous iteration of the archetype containing 'Test name' but it actually was a category and may be best represented by events! *Test Name (Optional): The name of the exact visual acuity test performed. This generally represents a broad category of applied refraction. Specific refraction details can be described using 'Refractive Correction'.* *Comment: Details of the exact correction applied, or where multiple corrections should be captured via 'Refractive Correction*'. *Choice of:* ** Pinhole visual acuity [The test is performed with pinhole refraction applied.] ** Usual corrected visual acuity [The test is performed with the patient's usual refractive correction i.e spectacles or contact lenses.] ** Best corrected visual acuity [The test is performed with the patient's optimal refractive correction.] ** Unaided visual acuity [The test was performed without visual aid.] I assume these concepts are also being considered? Another way to consider this is to add a 'Test label' - ie something the clinician user or system wants to label a particular or commonly used configuration of the 'bricks' you describe so that all test configurations of the same kind can be queried or displayed. Perhaps this is heading in the same direction as your comment below... [quote="Lars_Fuhrmann, post:22, topic:6308"] And if Implementers want a drop down menu of exactly 10 different “types” of VA test by combining 3 concept elements, can’t they construct that on an application level, and each combination is assigned to a specific combination of the 3 elements in the composition? [/quote] We haven't got an example of this in any other archetype, but may be a useful consideration. Regards Heather --- ## Post #24 by @Lars_Fuhrmann Hi everyone! Sorry it took me so long to post the protocol! I thought the call at the end of April was, again, very interesting and constructive and I was especially happy that we had a few more people joining in for the first time, with many different combinations of Clinical/Informatics-Backgrounds. I just came back from the ARVO conferene in Salt Lake City, where I presented my earlier work on an archetype-like FHIR profile, but as some of you know my conclusion is that the agreement on a common, learning semantic model of things like VA is really the key, independent of which syntax we use to sent the elements back and forth. So I am very happy about anyone willing to argue semantics here, it is exactly what is moving us fowards. Because clinicians tended to have to leave the call a bit earlier why in the future, **I would suggest we discuss the most clinical/semantic questions first**, and keep the geeky architectural or syntax-related discussions towards the end - as fun as they are. Protocol - I did a 10 minute Intro Presentation on “Why ophthalmic Archetypes”, which I hope to record as an intro video for others to see before they join in for the first time, just have not gotten around to that - Discussed that we should only have notation types in there that we are really sure how to define, these must not be ambiguous - Agreed to make which eye mandatory for now, because there are workarounds for legacy data without that info, and making it non-mandatory in the future would not be a breaking change - Discussed event structure again, agreed that whatever could reasonably be expected to change between two tests of the same eye should be moved to state, including the chart and Optotypes, as we care more about the behaviour of “state” for repeat measurements than what state semantically represents. - Discussed BCVA/BRVA, agreed these are not types of correction but something else, should not conflict with actual types of corrections. Better to have as Coded than as Boolean. Move definitions of BCVA/BRVA to protocol. - Discussed “Test name” and i expressed my hesitancy about that, in the call I think we sort of settled on using it but only for something very simple, non-repeatable and non-expandeable like “corrected” or “uncorrected”. I would personally rather not have the element in there but I can’t estimate the difference it makes. Following @heather.leslie's last reply I think I may hold off on adding it right away, as removing an element is a breaking chance and only adding it is not, maybe it is the best way foward if we wait for a use case to actually need it? - We discussed how to deal with derived Values, whether these should get a new composition with a coded element saying “I’m derived”, but I am sort of sceptical of whether that would cause problems in terms of the timeprints, i don't think i would clinically care when exactly the derivation was performed. Also that would nearly have to be mandatory or a boolean, as an empty “I am derived” element may be ambiguous. I will leave derived elements cluster in there for now, I think it is a good idea to have them side by side in the archetype, was similar for original archetype, although Ian mentioned that that was for some other reasons specific to an implementation in London. Do remind me in case I forgot something important! I'll implement the changes to the Archetype soon and repost it. Next meeting is on the 29. May, 14:00 CET, see .ics file above. Hope we can also have a first new look at the Intraocular Pressure Archetype then. Best regards and thank you for all your help! Lars --- ## Post #25 by @ian.mcnicoll Thaks Lars, Just a wee bit of clarification on what I recall to be the idea behind the 'Derived score'. This came from the Moorfields openEes system, where, as I recall, as well as the usual Metric Snellen, logmar VA scores, low visual acuity codes, they had a local algorithm which converted all of these into an equivalent numeric score. So this was not about e.g. expressing Snellen as logMar, or vice-versa. It was implemented in openEYES but I will check if it is still used, as it may be redundant now, or superseded. --- ## Post #26 by @Lars_Fuhrmann Hi Ian, thanks for the info1 I was not aware that that was reason behind the derived score elements before you told me, but regardless I think there is very good reason to have the elements for "derived logMAR", "derived Decimal" etc in the Archtype. And that is because, as I mentioned earlier, people tend to use multiple different notations depending on the level of the Visual acuity (germany: Decimal, Meter snellen, Qualitative), but both diagram representations or computations based on these values would require conversion (derivation) to another notation, often logMAR. (It is a little bit controversial in which cases this is ok to do) I know multiple ophthalmic softwares that do this, so they have to store their "derived logMAR" somewhere. I don't think it would be a good idea to just put them in the normal "Logmar Result" element, as that could make it ambiguous whether that was actually the initial notation used or not. So I quite like the idea of the derived results having their own data elements, this way there is no ambiguity which original recorded value belongs to the derived result, and the "description of derivation" could be used to document how the derivation was performed. If you or anyone thinks this is a bad idea please do tell me ;) --- ## Post #27 by @Lars_Fuhrmann So [here](https://ckm.openehr.org/ckm/archetypes/1013.1.7723/mindmap) is the newest version, And here is the list of changes I ended up making, note that the last one is not something we talked about in the meeting but that came from my attempts to map synthetic data to a template - Changed Eye(s) examined to Eye examined - Changed my mind and removed Fixation Testing (Central, Steady, Maintained?) and other pre-verbal tests, because these 1. Are not really measures of VA. 2. Are not mutually exclusive and 3. Are better off in an own Archetype, - Constrained Snellen Ratios to be either Ratio or Fraction - Changed “1m-Baseline ETDRS Letters Score” to “ETDRS Letters score”, as “1m Baseline” is in Description/Comment - Added “Arbitrary Unit” to numerical results elements, so that I could add reasonable range+decimal place limits – I don’t expect all of these to be accepted to UCUM? Any objections? - Removed “Derived Minimum Angle of Resolution – not sufficiently sure if anyone would use it. - Moved description of derivation to protocol, but changed occurences to 0...*, to account for multiple derivations (i.e. from decimal to both LogMAR and meter Snellen ratio) - Removed “Visual Acuity Score – not sufficiently sure if it would be used, could be added without an issue in the future. - Allowed for coded Text in “Comment” Element in addition to free text. - Changed BCVA/BRVA comparative classifiers to coded text element instead of Boolean, moved their definitions to protocol. - Moved the Following to state, as they can vary from one test to the next: Testing distance, General method, Chart or Card type, Optotype, Optotype presentation modifiers - Because we discussed that Booleans are usually not a great idea I reworked the glare light to ancillary lighting coded element, intensity element and ancillary lighting device. This way Brightness Acuity Testing can be recorded. - Not great to have just one “device details” element when multiple devices are routinely details, so i suggest this: 1. Aid device details (what are you looking through) 2. Stimulus device details (what are you looking at) 3. Ancillari lighting device details (what is being use to shine light at the eye to make it harder) - Added Coded Text option to Ambient lighting element (scotopic/mesopic/photopic), as quantification is often not possible. - Added Refractometer-Integrated test to general method, especially as these can be especially unreliable test in my experience. - Changed my mind again regarding the “Aid position” clusters. Trying to map synthetic data to these was so unnecessary complex because both the elements as well as the contained values were “hard coded” to be duplicated for R/L. 95-99% of VA tests are monocular, and for all these it is perfectly safe to assume that the correction was in front of the same eye that was being tested. We never say “Right eye corrected with the right part of the own glasses positioned in front of the right eye”. So I joined these back into one cluster and added a “same as eye being tested” coded value to the “in front of which eye” element that can serve as the assumed/default value for 95-99% of VA test. This really cuts down on the complexity, while still supporting explicit right/left handling for binocular tests. Makes the vast majority of tests simpler while not actually adding any real complexity to the binocular ones. Any objections? I'll try and work out what is worth discussion in the next meeting, thanks to all for the help, I for one do think we are making progess! --- ## Post #28 by @Lars_Fuhrmann I hope my emails reached everyone about us rescheduling the monthly online meetings to be at **12:00 noon CEST each last Thursday of the month:**, so the next one is still the 25th of june but two hours earlier than we initially planned. Here is the new .ics-file: [invite.ics|attachment](upload://15kn3MKMuOqc063xn0A1F7YxD9o.ics) (2.9 KB) [Here](https://ckm.openehr.org/ckm/archetypes/1013.1.7723/mindmap) Is the link to the most recent Draft of the VA Archetype, after the changes mentioned below. I also started keeping my Archetype drafts in a [github Repository](https://github.com/larfuma/openEHR-eyecare-collab). Please do get in touch if you want to collaborate there, or in case you think there are better existing repos to add them to? So here is my belated update on the last meeting, we were a bit decimated due to public holidays, but had very interesting clinical discussions and an exiting open ophthalmic EHR demo by @Poornachandra **Condensed Minutes from online Meeting on 29.5.2025** 1. **Testing Distance:** We agreed that categorical description of testing distance (near/intermediate/far) is so widespread that even if we may prefer the precision of a quantitative measure, the Archetype should be able to include coded text for near/intermediate/far. Does not make sense to be mutually exclusive with quantitative measures, as it may be sensible to record both "35cm" test distance, and the fact that this was classified as "near". -> Split up the testing distance into two elements, one coded text (near/intermediate/far) and one quantitative (m/cm/ft/in) 2. **ETDRS Letter Score:** We figured out there may be competing definitions for this term, depending on what distance is seen as the "baseline". As demonstrated in [this table.](https://michaelbach.de/sci/acuity.html). -> Adjusted that elements description+comment to this: > **Element Name** ETDRS Letter Score **Description** The number of optotypes correctly identified by the patient on a logMAR/ETDRS Chart, including those that are presumed to be readable due to being larger than the smallest line that was read entirely. This includes letters presumed readable at 1m distance. **Comment** Commonly used in study settings. This score describes either the number of optotypes identified (letters read): 1. Out of 30 at 1m distance. Or 2. Out of 70 at 4m distance. In which case the 30 letters from the 1m distance are added to the result as they are presumed readable. Typically, an ETDRS letter score of 85 is equivalent to 20/20ft, 1.0 decimal, 0.0 logMAR. Conversion of this notation requires precise understanding of testing procedures and intended meaning. 3. **EHR demo from Medblocks:** @Poornachandra shared their experience implementing their openEHR-based ophthalmic EHR that is already in active use in a well-frequented clinic in rural India. It was extremely interesting to see their software, and thereby the previous archetype versions in action, really pioneering work! We also talked about the challenges, some due to room for improvement in the Archetypes and some due to ophthalmologists preference for free-text entry... so both of that is sort of on us clinicians I guess ;) It was also very encouraging to hear him say he would like to use the revised versions in the future... Many thanks again for sharing! 4. **"Partial Line" documentation**. Usually VA is scored based on the smallest line where the patient could still read 60% (sometimes 50%) of letters in that line, that's what the charts are typically designed for. So it is actually expected that smallest line that still "counts" as bening read may not be not read completely. It adds little information to record "missed a letter in the last line!" explicitely as there is a degree of randomness involved. I used to think that adding a little "p" for "partial" to the result in case of a missed letter is just a habit of some german ophthalmologists. But surprisingly the doctors using the Medblocks openEHR in India have been doing the same thing! I know that it may *feel* more precise to record the result based on a single letter being read or not, but it it is not part of the standard scoring algorithm (or ISO norm). This has led to problematic data modelling decisions in softwares in the past as it keeps ophthalmologists wanting to enter letters (p) in the data entry fields for VA, leading to a lot of free text results fields that interpret 0.6p as a string.. I think there are two options: Just have that p go into a coded or free text comment (would be fine) OR I realized this sematically overlaps with the "Letter Termination Adjustment" element in the previous archetype version (p for partial = negative Letter Termination Adjustment score). In that notation 20/20 -2 means 2 Letters were missed from 20/20 line, but the line still counts as read. Again I think this is non-standard, but people want to use it and it does not hurt anyone as long as it is in a seperate element from the actual result (and not in one string together with it). If "20/20 -2" ≈ "1.0p" why not have an element that accounts for this concept of "missed a letter", whether it is in numerical or "p" form? -> As a suggestion; I integrated both of those concepts into a "Letters missed or read in addition to scored line"-Element, which can have either a positive or negative count, which is the same as the "Letter Termination Adjustment", or a "partial" coded text from the old Archetype. This whole concept is not pleasing to purists, but If ophthalmologists in at least three different nations **want** to document a similar concept, who am I to say they shouldn't, as long as it does not result in the main result being free text? _________________ There are still a few less clinical issues that may be more interesting for @ian.mcnicoll @heather.leslie @ian.mcnicoll @siljelb @SevKohler than for most clinicians: - @ian.mcnicoll mentioned "referencing" as a way we could maybe deal with the similar definitions of "result" and "derived result" elements. - Whether it is better to have two "aided by" Clusters (seperate clusters for left/right) or one with a default value of "the eye being tested" being corrected in monocular tests. - Whether we need able to resolve hirarchies between different coded text values in the same element (landold C being a "child" of orientation optotype, sloan letter being a "child" of letter archtype, own glasses being a "child" of the less specific "corrected" value ) perhaps via the SNOMED bindings which we will hopefully have in the future? - referencing actual refraction/lensmeter/prescription compositions which may have been recorded in another encounter as the source of the lens values used I hope it's OK if we try to not have those technical issues fill out all of thursdays meeting... I do have a few clinical things i would like to discuss beforehand, and would like to start looking closer at the intraocular pressure Archetypes as well. I'll sugggest an agenda ahead of time, but I'm totally open for anyone to suggest things we should discuss! Many thanks to all! ;) --- ## Post #29 by @ian.mcnicoll Hi Lars, Sorry I will not make this call as I am on holiday. I'm not particularly pushing to use archetype references, as this is a pretty obscure part of ADL that we have never found very useful in the past. It was designed so that a set of constraints (like those for VA 'scores' could be reused in a different context without duplicating the whole constraint. So actually quite a good fit for this use case but I suspect my modeller colleagues would not be keen, just because it is so obscure. I don't have strong feelings either way on the other 'modelling/technical issues' that you described. --- ## Post #30 by @Lars_Fuhrmann Quick Update: You can find the Meeting Minutes and Recording of the last Meeting [here](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/3038970119/Meeting+Minutes) As discussed there we will gravitate towards having a confluence page as the main page for this collaboration and from now on I will post the minutes there, but we want to do the Issue tracking using Jira. I'll set up those pages soon. By the way: we do want to get the VA Archetype into a formal CKM review, but we figured it may be a good idea to push for the IOP Archetype to go through that process fist as I do think it will be a bit less complex and offer valuable review experience. So the next Meeting on the 31.7.2025 will focus more on the IOP Archetype (12:00 CEST). I'll see if I can finish up a draft revision and reach out to glaucoma specialists. --- **Canonical:** https://discourse.openehr.org/t/visual-acuity-archetype-discussion/6308 **Original content:** https://discourse.openehr.org/t/visual-acuity-archetype-discussion/6308