The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.

Ophthalmology Standards

Introduction

Ophthalmology is a hugely diverse therapeutic area, where endpoints and conventions can differ from study to study - let alone across companies. Notwithstanding this, there exist cases where alignment is possible; this page indexes the occurrences in which {admiralophtha} suggests the adoption of a certain standard way of doing things.

Applying the standards below is by no means mandatory, but will help in leveraging the tools (templates, functions, etc.) provided by {admiralophtha} as well as lower the barrier of entry for programming in your study. Additionally, this page can function as guidance for programmers starting to dip their feet in ophthalmology ADaM programming.

Dataset Subdivision

Due to the aforementioned high complexity and diversity of ophthalmology data, it is discouraged to funnel all records from the OE SDTM dataset into a single ADOE dataset, as this will result in an overly complicated program/dataset pair. {admiralophtha} instead suggests the following partition:

Subdividing the ADaM datasets in a study as above will ensure that wherever custom efficacy programming is required, this will automatically be limited to the data of interest. For instance, if a study has various endpoints of the form Gain of between x and y letters relative to baseline (or similar) then each will likely require a criterion variable/flag pair (see the Criterion Flag section for more detail). If the BCVA data were stored in ADOE, then these criterion variable/flag pairs would be blank and irrelevant for most of the data in the dataset, save for the BCVA records. Conversely, collecting the BCVA data in ADBCVA ensures the criterion variable/flag pairs are more relevant, and the resulting dataset is more readable.

Criterion Flags

{admiralophtha} suggests the use of criterion variable/flag pairs CRITx/CRITxFL where possible for endpoint programming. If implemented correctly, this is a very transparent approach as the condition for CRITxFL can be clearly encoded in CRITx, without having to view any documentation. When appropriate, the condition in CRITx should be represented programmatically rather than in words to reduce possibility of confusion. For instance, for an endpoint such as Gain of between x and y letters relative to baseline, one would set CRIT1 = "x <= CHG <= y".

Note: Though allowable according to ADaM standards, it is generally discouraged to use the same criterion flag/variable pair for more than one criterion across multiple parameters in an ADaM dataset, as this renders the dataset confusing to scrutinise.

For BCVA change endpoints, provides the function derive_var_bcvacritxfl to add them en masse. Additionally, the function automatically populates CRITx in the programmatic manner described above.

Affected Eye Derivation

{admiralophtha} function derive_var_afeye follows the standard derivation: Set to “BOTH EYES” when Study Eye Selection [ADSL.STUDYEYE] is not missing, and Laterality [xxLAT] is equal to “BILATERAL”. Else set to “STUDY EYE” when Study Eye Selection [ADSL.STUDYEYE] is either “RIGHT” or “LEFT”, and matches Laterality [xxLAT] for the observation record. Else set to “STUDY EYE” when Study Eye Selection [ADSL.STUDYEYE] is “BILATERAL”, and Laterality [xxLAT] is not missing for the observation record. Else set to “FELLOW EYE” when Study Eye Selection [ADSL.STUDYEYE] is either “RIGHT” or “LEFT”, and [xxLAT] is not missing and does not match Laterality [xxLAT] for the observation record. Else set to null.

If the standard values of Location [xxLOC] = “EYE” and Laterality [xxLAT] = “LEFT”, “RIGHT”, “BILATERAL” are not the same for your study this can be updated as inputs in the function, otherwise this is also expected for AFEYE to be derived, and a warning will be returned if any other values are found.

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.