Research Definition Document (RDD)

The main resource to represent the RDD is the ResearchStudy-IEHR and it references the other resources that make up the RDD. The ResearchStudy-IEHR additionally contains some administrative information about the study.

The most important attributes of the ResearchStudy-IEHR, their meaning and handling are explained below:

• The information about from where the study can be requested is displayed as a pair of url and name in the ResearchStudy.identifier attribute.
• The title of the RDD is displayed in the ResearchStudy.title attribute.
• The purpose of the study is displayed by a code in the ResearchStudy.primaryPurposeType attribute. This code should be from the ResearchStudyPrimaryPurposeType ValueSet
• Contact details for further inquiries about the study are represented in the ResearchStudy.contactDetail attribute.
• The geographical locations where the study takes place are displayed as codes from the Jurisdiction ValueSet in the ResearchStudy.location attribute.

Important note: Only one RDD is published by the PI and this RDD contains the content in all necessary languages. Further information on the subject of translations can be found on page Translation Instructions.

Customized Data Requests - DataRequirement-IEHR

For example, suppose that for a study, only information on the incidence of certain diseases is collected. At this point, it would be redundant to request the entire resources of study participants instead of just the attributes of interest. For this purpose, the ResearchStudy-IEHR contains the DataSetDefinitionExtension-IEHR, containing one or more DataRequirement-IEHRs.

As mentioned above, a DataRequirement describes a required data item. There should be one DataRequirement for each set of data that the study wants to collect. For this, the attribute DataRequirement.type defines the type of resource, that is requested. For example if the study collects information about a disease the type would be Condition.

Data Processing Instructions

Considering the example of a study looking at the incidence of a particular disease, it is not beneficial to request entire resources. For this purpose, it is possible to give instructions to the system that collects and transmits the data as to how the data should be processed prior to transmission as part of the study. Accordingly, it is possible, e.g., to have the amount of patients with a certain disease returned directly, instead of getting all patient resources and doing the counting yourself. The instructions can be transmitted using the FunctionExtension-IEHR, an extension which in turn contains two other extensions:

• extension:Name is bond to the FunctionCodes ValueSet containing 5 codes for the supported functions (ageFromDate, count, data, summary, element). Example: When using the code count, the function returns the number of matching resources e.g. the amount of patients with a certain disease, but not the resources
• extension:Parameter is directly dependent on the used function defined in extension:Name, since not all functions need a parameter. Only ageFromDate and element require additional parameters:
  • ageFromDate: This function returns the age of the resource's subject and should only have two parameter. The first one points to the Reference of the subject and the second one to the creation date of the resource.
  • element: By using this function, the system returns only the attributes specified in the parameter extensions. Therefore, it can have any number of parameters.

To retrieve complete resources no function must be specified.

Constraining based on Content

To further constrain the transmitted data based on the resources content, the attribute DataRequirement.codeFilter is used. The codeFilter constrains the content of the resource and only resources that comply with ALL codeFilters in a DataRequirement comply with the DataRequirement and should be transmitted.

To filter by code, the codeFilter attribute (DataRequirement.codeFilter) should contain a path (codeFilter.path) that points to an attribute from the resource defined in DataRequirement.type. Additionally, the codeFilter contains either one or more codes (codeFilter.code) or a ValueSet (codeFilter.valueSet).

If codeFilter contains a ValueSet (codeFilter.valueSet), only resources that contain code from the ValueSet in the specified attribute (codeFilter.path) are accepted by the filter. Example:

• Any VitalSign is requested: A VitalSign is represented as an Observation, therefore the DataRequirement.type = Observation. Since the VitalSign profile binds a specific ValueSet to its code (Observation.code), VitalSigns can be distinguished from other Observations based on this code. Accordingly, the codeFilter.path = code and codeFilter.valueSet = VitalSigns ValueSet.

If codeFilter contains a list of codes (codeFilter.code), only resources that contain at least one of the listed codes are accepted by the filter. Example:

• Any VitalSign is requested: A VitalSign is represented as an Observation, therefore the DataRequirement.type = Observation. In addition, Vital Signs have their own category (Observation.category), with which they can be differentiated from other Observations. Accordingly, the codeFilter.path = category and codeFilter.code = Coding (Coding.system = http://terminology.hl7.org/CodeSystem/observation-category, Coding.code = vital-signs).

Constraining based on Timeframe

To further constrain the transmitted data based on the resources' timeframe, the attribute DataRequirement.dateFilter is used. Therefore, it is possible to have resources of a certain day or period of time returned.

One or more dateFilter constrain timeframes and only resources that comply ALL dateFilters in a DataRequirement will meet this DataRequirement and be transmitted.

To filter by time, the dateFilter attribute (DataRequirement.dateFilter ) should contain a path (codeFilter.path) that points to an attribute from the resource defined in DataRequirement.type. This attribute should be of type DateTime or Period, otherwise the dateFilter will reject any resource.

Additionally, the dateFilter may contain either a Date, a Period or a Duration in its value (dateFilter.value[x]). The resulting options for filtering are explained next.

• If the dateFilter contains a Date, only resources that contain exactly this date in the previously specified attribute (dateFilter.path) are returned.
• If the dateFilter contains a Period, only resources that contain a date or period in the previously specified attribute (dateFilter.path) that falls within the dateFilter’s period are returned.
• If the dateFilter contains a Duration, only resources that contain a date in the previously specified attribute (dateFilter.path) that falls within the dateFilter’s Duration before now are returned.

Note that the dateFilter refers to the time frame in which the data was actually collected. With Timing.bounds from the FrequencyExtension-IEHR, data is retrieved that was created in this time period. For example, a vaccination may have taken place several years ago, but was only digitally recorded last month. If you request all data of the last month with Timing.bounds, this vaccination is included in the data set. If you request all vaccinations of the last month with dateFilter, this vaccination will not be sent.

Handling of dateFilter using examples: dateFilter.value[x] = ...

• Retrieve resources from today (e.g. May, 30th 2022)
  • ... 2022-05-30
  • ... Duration.value = 1, ... Duration.code = days, ... Duration.system = http://hl7.org/fhir/ValueSet/duration-units (= 24h)
• Retrieve resources from the last two weeks
  • ... Period.start = 2022-05-16, ... Period.end = 2022-05-30 or
  • ... Duration.value = 2, ... Duration.code = weeks, ... Duration.system = http://hl7.org/fhir/ValueSet/duration-units

Please note that for retrieving information from the past, the dateFilter may contain dates that are in the past. In general, all resources that fall within this date will be transmitted. However, the number of resources to be returned may be additionally constrained by the frequency extension.

In combination with the frequency extension, time periods ending or even starting in the future can also be used to request regular updates. Updates can be requested on specific days in the future by simply using the future date in the filter.

Data Transmission Frequency

To receive data regularly or in certain time intervals, the FrequencyExtension-IEHR can be used. It defines how often the data should be transmitted. Since the extension's value is of datatype Timing, it includes multiple possibilities to define the frequency of data transmission.

Handling of Timings attributes using examples: If data should be transmitted ...

• ... 2 times per 1 week: frequency = 2, period = 1 and periodUnit = wk
• ... every monday and friday: dayOfWeek = mon, fri
• ... every monday at 1 pm: dayOfWeek = mon, timeOfDay = 13:00:00
• ... once at a specific date: event = 2022-06-15, repeat.count = 1

Note that the profile does not check whether these attributes are consistent with each other, and that it is the responsibility of the study creator to ensure that the values make sense. Furthermore, when timeOfDay is specified, it is inferred that the action happens every day (as filtered by dayofWeek) on the specified times. The elements when, frequency and period cannot be used as well as timeOfDay.

Please see the note on dateFilter, too.

Reference of Corresponding Questionnaires

The ResearchStudy-IEHR is designed to include as many study-related Questionnaires as necessary. For this purpose, the ResearchStudy-IEHR is extended by the QuestionnaireExtension-IEHR. To reference one or more questionnaires, a corresponding number of QuestionnaireExtension-IEHRs must be attached to the study, since one extension references only one questionnaire at a time.

Creation of a Questionnaire

As mentioned above, one QuestionnaireExtension-IEHR references only one Questionnaire-IEHR in the QuestionnaireExtension-IEHR's QuestionnaireExtension.value (Extension.extension:Questionnaire.value[x]). The url (Extension.extension:Questionnaire.url) is set to "Questionnaire". When creating a Questionnaire-IEHR, certain things need to be addressed as explained in more detail below.

The biggest difference between a questionnaire and a Questionnaire-IEHR is that the question items of the Questionnaire-IEHR do not contain text but only codes. This approach ensures that a questionnaire can be available in multiple languages without having multiple instances of the same questionnaire. In addition, this minimizes translation-related ambiguities. So how does one create a Questionnaire-IEHR?

Handling of Questionnaire-IEHR:

• A Questionnaire-IEHR must have an unique logical id (Questionnaire.id);
• The CodeSystem associated with the questionnaire is referenced using the CodeSystemExtension-IEHR. It contains the reference to the CodeSystem-Questionnaire-IEHR in it's value (extension.value[x]);
• To indicate in which publication status (draft, active, retired, unknown) the questionnaire is, the attribute Questionnaire.status is used;
• The questions and sections within the Questionnaire are stated in the item attribute (Questionnaire.item). Each item must have an unique id (item.linkId);
  • To create a question group / a section, the item type is set to "group" (item.type). The questions belonging to the group are then created under item.item. The following described attribution options of a question are also valid for the nested questions;
  • To create a question, the item type (item.type) is set to a type describing the data type of the question, i.g. boolean, string, integer ... .
  • The actual question, i.e. the text, is NOT specified in the text attribute (item.text). Each question is created as code in the questionnaire-specific code system. It may be useful to code each question by sequential numbers. For example, CodeSystem.url = url-of-codesystem, CodeSystem.code = 1.1, CodeSystem.display = Surname would be referenced in the Questionnaire as Questionnaire.item.code.code = 1.1, Questionnaire.item.code.system = url-of-codesystem; The same applies to the section name. This is also specified as code.
  • By using codes instead of text, it is easier to keep the questions in different languages, because the translations of a question can be specified as a designation in the CodeSystem. More about this can be found on the page Translation Instructions.

Some other questionnaire-relevant data can be specified in the non-mandatory attributes as described below.

• If multiple versions of a questionnaire are available, the corresponding version number should be stated in Questionnaire.version;
• The questionnaire's human friendly title may be specified in the Questionnaire.title attribute, while the computer friendly title should be located in Questionnaire.name;
• The organization or individual issuing the questionnaire can be specified in Questionnaire.publisher;
• One or more contact details of the publisher can be specified in Questionnaire.contactDetails.

Note that the profile offers further attributes, which can be found in full in the profile's snapshot table.

Further Specification of a Questionnaire

In addition to the actual questionnaire, the X can be used to add further questionnaire-related attributes.

Setting a Deadline for a Questionnaire

Since a questionnaire usually has a time for submission, the extension contains a mandatory DeadlineExtension. In this extension a deadline of the DataType dateTime can be specified.

To specify the date that represents the deadline for the questionnaire, the date must be entered in the extension's value (extension.value[x]), e.g.: 2022-05-30. For further information about dateTime's format, see HL7 FHIR Datatypes #dateTime. The url of the extension (extension.url) must be set to "Deadline".

If the deadline passes and the participant has not completed the questionnaire, they will be excluded from the study.

Setting the Reminder Frequency

To express the frequency with which patients should be reminded to fill in the questionnaire that has not yet been completed, QuestionnaireExtension-IEHR contains the ReminderFrequencyExtension.

Handling of ReminderFrequencyExtension's Timings attributes using examples: If the participant should be reminded ...

• ... 2 times per 1 week: frequency = 2, period = 1 and periodUnit = wk
• ... every monday and friday: dayOfWeek = mon, fri
• ... every monday at 1 pm: dayOfWeek = mon, timeOfDay = 13:00:00

Therefore, the meaning of these attributes is as follows: The participant should be reminded frequency times (Timing.frequency) per period (Timing.period) periodUnit (Timing.periodUnit). The dayOfWeek attribute (Timing.dayOfWeek) can be used to specify which days of the week the participant should be reminded and timeOfDay (Timing.timeOfDay) can be used to specify the exact time. This could be used to make sure the patient can immediately start with the questionnaire and does not forget it again, for example by choosing times when the participant is not working.

Please note, that the profile does not check whether these attributes are consistent with each other, and that it is the responsibility of the study creator to ensure that the values make sense.

Specification of ResearchStudy's Enrollment

To specify the period in which new participants are accepted into the study, the ResearchStudy-IEHR gets mandatorily extended with the EnrollmentPeriodExtension-IEHR. The respective time period is represented as the extension's value.

Request of Anonymized/Pseudonymized Data

Due to different types of Study, it is important to transmit the information whether certain information of the study's subjects need to be kept private or not. For this purpose the ResearchStudy-IEHR is extended by the AnonymizationExtension-IEHR. It represents how the answers to the study SHOULD be anonymized before they are sent to the research center.

The extension includes a Coding (extension.value[x]) which is bound to the Anonymization ValueSet.

Handling of the AnonymizationExtension-IEHR and Anonymization ValueSet:

• Code for removal of ALL personal information: anonymization. If a ResearchStudy is extended with the code anonymization, all personal information should be removed before data transmission.
• Code for replacement of personal information: pseudonymization: If a ResearchStudy is extended with the code pseudonymization, all personal information should be replaced with pseudonyms before data transmission.

Please note, that the AnonymizationExtension-IEHR may also be used to mark a resource as anonymized/pseudonymized in order to distinguish it from its original.

Inclusion + Exclusion criteria

By default, not all people can participate in a study. Participants are selected on the basis of certain criteria. If people with certain characteristics are grouped together, this can be referred to as a cohort. For this reason, the ResearchStudy-IEHR references a Cohort-IEHR derived from Group in the attribute enrollment (ResearchStudy.enrollment). Accordingly, the cohort contains all the characteristics that describe which people will be admitted as participants in the corresponding study.

Defining a Cohort-IEHR

• A Cohort-IEHR must have an unique logical id (Group.id);
• Since the project only addresses scenarios where studies are conducted with human participants only, the cohort's type (Group.type) is set to person.
• To add a characteristic that describe which people will be admitted as participants in the study, a characteristics (Group.characteristic) must be added containing the following information:
  • Add the characteristic's type (Group.characteristic.code) to define what kind of characteristics it is. The code should be from the ValueSet CharacteristicCodesValueSet.
  • To specify the required expression of the characteristics, the attribute value (Group.characteristics.value[x]) is used.
  • The characteristics can be seen from two sides, either as an include or exclude expression. To prevent misinterpretation, the boolean attribute exclude (Group.characteristic.exclude) can be used to specify whether only persons with the previously specified characteristics should be included in the study (exclude = false) or if this group of persons should be excluded (exclude = true).
  • For example: a study can only enroll people with the administrative gender female. In this case, Group.characteristic.code = "72143-1" (Sex [HL7.v3]) can be used to indicate that the characteristic refers to the participant's gender. To state, that the administrative gender expression should be female, a CodeableConcept containing system = http://hl7.org/fhir/administrative-gender and code = female can be used. Lastly, it needs to be specified that we want to include not exclude people with this characteristic expression. Therefore, Group.characteristics.exclude = false.

Notes about the use of Group.characterstic.valueCodeableConcept

The required expression of the characteristic can be represented, among other things, by a CodeableConcept. It is possible that a CodeableConcept contains several codes. These are interpreted with an OR connection, accordingly persons with one or the other code are counted to the cohort. This interpretation allows specifying characteristics in such a way that participants only need to be assigned one code from the list in order to participate in the study. This makes the study more general. Examples:

• If the characteristic's type (Group.characteristic.code) is Medication and the CodeableConcept contains multiple codings for different medications. Any person taking at least one of the medications has this characteristic and is considered part of the cohort;
• If a study is about heart conditions in general, the characteristic's type (Group.characteristic.code) could be Condition while the CodeableConcept contains a list of different heart conditions;
• If a study is about a group of drugs with a common active ingredient, the characteristic's type (Group.characteristic.code) could be Medication and the CodeableConcept contains multiple codings for the different medications.

If the CodeableConcept should contain a list of codes that represent a group of related codes from a hierarchically CodeSystem they might share a prefix. In this case the Operator-Extension of the Coding-IEHR can be used: the operator will be set to startsWith and the coding contains the system, the common prefix in the display attribute and an empty code attribute. This representation is equivalent to a list of all codes in the system that start with this prefix. However, this representation should only be used after ensuring that no unwanted codes with this prefix exist. Otherwise, this might add unexpected characteristics to the Cohort and wrongly include or exclude participants.