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.
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
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?
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
