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.
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…
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” Archetype?
This way we the overall Interpretation could be about any number of VA tests.
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 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.
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:
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” was used both within the refractive assessment Archetype 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”, 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.
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.
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. Maybe we could simplify further by may eventually allow merging the general method and chart elements.
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.
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.
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!
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.
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.
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.
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.
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.
Too clinical for me, havent explored ophthalmology yet.
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.
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
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?
OK, I’ll put 0…n in the next version
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.
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.
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?
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. One thing we could do to handle the issue though is to add our own UCUM-compatible notation to our own units file which is used by Archetype Designer. See for example this commit to add some units variations used in audiology.
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.
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:
Ensuring templates can handle multiple different units of VA, because which units ophthalmologists use depends on clinical circumstances.
Minimizing the risk that VA compositions contradict themselves, which they may if they contain multiple “result” elements with unequal values
Keep querying as generic as possible.
Keep the unit handling as generic as possible - which would be in the DV_Quantity instance itself
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:
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
My versionwhere 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.
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 would be more suitable?
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 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.
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?
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,
This 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, 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.
