Настольный дизайн о наборах элементов сбора данных

Question

Дайте мне знать, если вам нужна дополнительная информация, так как это мое первое сообщение на форумах.

Дизайн предназначен для клинических исследований. Самый простой способ объяснить - дать пример сценарию, который применяется ко всем исследованиям/протоколам в какой-либо форме или форме. Скажем, у меня есть:

• study1, Study2, Study3
• study1 имеет протокола1, протокола2, протокол3
• Каждый протокол имеет «сбор данных» (набор форм, вопросы и примеры коллекций, которые могут пересекаться в разных исследованиях и/или протоколы)
• Все эти сборники данных планируется завершить в клиниках.

Я могу построить все отношения между Исследованием, Протоколом и Вопросами, подобными структуре дизайна вопросника/обследования. Однако это, где это становится сложнее с определениями протокола и как связать протоколы обратно к пунктам сбора данных, некоторые примеры:

• протокола1 имеет форму, которая должна быть заполнена каждые 3 месяца после регистрации до 24 месяцев , затем каждые 6 месяцев.
• Протокол 1 имеет образец коллекции в 6 месяцев, 15 месяцев, 27 месяцев, а затем ежегодно.
• протокола1 имеет другую коллекцию образцов, который должно произойти в возрасте 4, 5 и 6.
• Некоторые сбора данных элементы в регистрации, некоторые из них каждый визит, и т.д ..

Я хочу иметь «список дел» для посещения этой клиники для конкретного пациента на основе всех взаимосвязей между исследованием-протоколом datacollection, но я не уверен, как определить эти условные критерии для протоколов на внутреннем сервере, чтобы быть можно запросить? или я пытаюсь сделать что-то нереалистичное?

** Я использую SQL Server, кстати

Answer 1

Создав аналогичные схемы сам я бы порекомендовал вам принять подход генерации всех будущие дат графика и сохранения их в виде таблицы, связанной с пациентом, а не пытаться вычислите их «на лету». Я думаю, что это сэкономит вам много головных болей и сложных запросов. Например, вы могли бы иметь таблицу, определенную так:

CREATE TABLE PatientSchedule 
(
    PatientId INT, /* foreign key into Patient table */ 
    ProtocolId INT, /* foreign key into Protocol table */ 
    StudyId INT, /* foreign key into Study table */ 
    DataCollectionId INT, /* foreign key into DataCollection table */ 
    SampleCollectionId INT, /* Foreign key into sample table */ 
    ScheduleDate DATE 
) 

(вы, очевидно, нужно адаптировать это на основе ваших конкретных отношений, но, надеюсь, вы получите идею).

Эта таблица может быть предварительно заполнена для конкретного пациента, когда они регистрируются для конкретного исследования/протокола, вставляя все запланированные даты до любой даты, которая может быть реалистичным максимумом в будущем.

Для конкретной клиники визита «To Do List» запрос должен затем быть столь же простым, как что-то вроде:

SELECT * FROM PatientSchedule 
WHERE PatientId = ?? 
AND ScheduleDate = <clinic visit date> 

Если даты графика изменены по какой-либо причине в будущем оно не должно быть слишком трудно для обновления таблицы PatientSchedule.