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.
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:
Make “Eyes Examined” non-mandatory, will usually be mandatory on template-level.
->done
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)
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
They don’t really need to be children of the “results details”
→ moved them to be direct children of “data”
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
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.
Remove 0..4 limitation from corrections
→ it’s 0…* now
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.
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?
We didn’t get to all elements because there is just so much to cover
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
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)
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..
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.
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.
@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:
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:
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 and Left eye Position, 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) and retrospective (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 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.
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?
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.
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.
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?
