Interventions

[dih-cdisc]

Formulation missing from intervention + alignment with IDMP

See JIRA 520

Item	Ticket
Model	#443
CT	#444
API	#445
Rules	#446
IG	#447
Test Data	#448

[BSnoeijerCD]

See original Sketch for the intervention classes. We were unsure where to add formulation.

[dih-cdisc]

From @BSnoeijerCD email

Furthermore, per protocol I indicated what intervention information could not yet be stored in USDM. See the summary below:

• Packaging of the Drug (1 study)
• Dosage formulation (4 studies)
• Manufacturer/who provides medication (3 studies)
• Substance(s) within the tablet (1 study)
• Other details of the specific drug like molecular weight, pKa, pH etc (1 study)
• No option to store information on Extended release (1 study)
• No option to store information on Storage condition (1 study)
• No option to store the intervention Alias name (1 study)
• Indication whether the intervention is allowed / disallowed concomitant medication (1 study)
• Indication for treatment of expected AEs when occurring (1 study)

Based on the above, I would say that kind of a generic interventionProperty class could work for a number of these items?

Other model issues:

• Administration information is not always available in the protocol while required by the USDM relationship (1 study). (Note: Also in case on non-drug interventions you would not expect administration details)
• In case of described dose interruptions for specific situations – should DurationWillVary be set to Y? Or, since the interruption is not the standard set to N?
• If the administration duration is not fixed like for the Parkinson study then I have no quantity for duration. However, this variable is required in USDM.

[dih-cdisc]

Made this a more general ticket for interventions

[BSnoeijerCD]

Observational studies should not include an intervention. Types of interventions in Type CT we do not handle yet:

• Devices
• Dietary
• Procedure / Behavioral therapy
• Radiation To discuss whether we want to include this or in those cases leave it at the intervention level. Moving the relationship duration directly out of studyIntervention will help. Then it also applies to these other types of interventions.

[BSnoeijerCD]

@dih-cdisc : see sketch below based on the following considerations:

• Administration can be made more generic as it does not always have to be an agent. So, I like to suggest to change name to AdministrationConcept, AdministrationDetail or Administration instead with the following advantages:
  • reuse of frequency, duration and potentially also dose/route and other general attributes for non-agent administrations like questionnaires, behavioral therapy, or other types of interventions that can be specified in intervention.type
  • all information on procedures regarding the administration and corresponding processes of any intervention are then stored in the same class with the same logic.
• Based on the protocols we have reviewed there is quite a big list of potential properties of an agent or other intervention. I suggest to add a more generic class to cover this which is similar to biomedicalConceptProperties. So I called this interventionProperty. This could contain properties directly linked to the intervention like formulation, packaging, drug provider, pH/pKa, manufacturer or provider, storage condition, but also the institute that developed a questionnaire/method etc. If helpfull, we could add an extensible property type to this one. pharmacologicClass is probably then also fit to be stored in this new class.
• In some cases the drug ingredients are specified as well including strength, molecular weight etc. To align with IDMP and FHIR, I like to suggest a interventionSubstance class that then can contain those specific attributes if needed.

[BSnoeijerCD]

2 more considerations to note:

• In CPT there is a variable for current/former name(s) or alias(es). I also saw this in one of the example protocols. So how should that be stored
• Maybe we need an in-between separate class for formulation between substance and studyintervention that serves as a containter for 1 or more substances. In FHIR this is called: MedicinalProductDefinition. See https://build.fhir.org/medicinalproductdefinition.html -> I will make an updated scheme based on this.

[BSnoeijerCD]

Aligning to ISO IDMP

• The use of ISO IDMP is a regulatory requirement according to the Commission Implementing Regulation (EU) No 520/2012 (articles 25 and 26) which mandates the use of ISO IDMP for the exchange of information on medicinal products across the European Union. See https://www.ema.europa.eu/system/files/documents/other/wc500217406_en.pdf
• EMA is implementing the standards in a phased programme based on the four domains of master data in pharmaceutical regulatory processes: substance, product, organisation and referential (SPOR) master data. / Product and substance information included in regulatory submissions can be provided in an ISO IDMPcompatible format.https://www.ema.europa.eu/en/human-regulatory-overview/research-development/data-medicines-iso-idmp-standards-overview
• The EU IDMP Implementation Guide (EU IG) for the submission of data on medicinal products defines the implementation requirements of the ISO IDMPstandards for the EU. https://www.ema.europa.eu/en/human-regulatory-overview/research-development/data-medicines-iso-idmp-standards-overview/substance-product-organisation-referential-spor-master-data/substance-product-data-management-services
• Chapter 2 of the previous document defines the data elements: Data elements for the electronic submission of information on medicinal products for human use

See overview document reference above (bullet 2): ISO IDMP is composed of five separate standards. The specific standards are:  ISO 11238: Data elements and structures for unique identification and exchange of regulated information on Substances;  ISO 11239: Data elements and structures for unique identification and exchange of regulated information on pharmaceutical dose forms, units of presentation, routes of administration and packaging;  ISO 11240: Data elements and structures for unique identification and exchange of units of measurement; covered in quantity class  ISO 11616: Data elements and structures for unique identification and exchange of regulated pharmaceutical Product information;  ISO 11615: Data elements and structures for unique identification and exchange of regulated medicinal Product information. ISO IDMP standards apply to Human medicinal products and investigational medicinal products.

[BSnoeijerCD]

@dih-cdisc See here the proposal based on the IDMP / FHIR alignment (based on references above). The ingredients/substance part is complex in IDMP. The below proposal simplifies that part a bit as we do not have to include everything for a clinical study. However in this way it still can be mapped to IDMP/FHR. See also the notes below for the parts that I did not yet address.

• Packaging of the Drug (1 study) => is a whole separate part in IDMP -> we can add this / simplify by 1 text attribute or direct them to the notes for this.
• Other details of the specific drug like molecular weight, pKa, pH, storage condition etc (1 study) -> we can add this as a list of characteristics linking to a value.
• No option to store information on Extended release (1 study) -> FHIR indicates to add this as characteristics
• Indication whether the intervention is allowed / disallowed concomitant medication (1 study) -> add to role CT?
• Indication for treatment of expected AEs when occurring (1 study) -> add to role CT?

For rules: note that the EMA IDMP implementation guide indicates that the StrengthLowerLimit should always be filled and the StrengthUpperLimit only when it concerns a ratio (to be verified).

[BSnoeijerCD]

Based on scrum discussions today I did the following follow-up research:

• StudyIntervention type links to codelist C99078. This is indeed an indication that the intervention is only 1 item (a product, device, behavioral therapy etc) https://ncit.nci.nih.gov/ncitbrowser/ajax?action=create_src_vs_tree&vsd_uri=http://evs.nci.nih.gov/valueset/CDISC/C99078. So that implies that the relationship should be 0..1 for MedicinalProducDefinition instead of 0..*.
• FHIR description of an ingredient: An ingredient of a manufactured item or pharmaceutical product. https://build.fhir.org/ingredient.html
• FHIR description of a substance: A homogeneous material with a definite composition. A medication is a substance that is packaged and used as an administered medication. The medication resource uses the substance resource to represent the actual ingredients of a medication. (https://build.fhir.org/substance.html)
• Given the above I understand that an ingredient is an substance but a substance is not per se an ingredient (can also be packaging material or so). For this reason, I think we can combine it for USDM in 1 class called Ingredient (the more specific one)

[BSnoeijerCD]

Note: page 37 of chapter 2 of the EU ISO IDMP IG indicates that "medicinal products may consist of two pharmaceutical products that correspond with two different administrable dose forms (e.g., hard capsule and cream) that form individual entities which do not need combining for administering to the patient. In this case the RMS list “Combination Package” shall be used. For clinical drugs this combination is tested and more likely seen as two different interventions. Therefore, it is probably more appropriate to use the term PharmaceuticalProduct or the corresponding FHIR name AdministrableProductDefinition instead. See https://build.fhir.org/administrableproductdefinition.html. THis class includes attributes like administrableDoseForm and routeOfAdministration. I will update the proposal accordingly tomorrow morning.

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @ASL-rmarshall @czwickl : Based on the above and other insights, please see below my full proposal for the intervention part of the model. I will go through it during the scrum today.

[BSnoeijerCD]

As discussed during scrum today:

• We will leave out route/routeOfAdministration from administrableProductDefinition class since we only want to define the administration route for the current study which is already present in the administration class.
• Berber will check whether role is necessary for clinical studies. If not, we can leave it out as we expect only active ingredients will be specified.
• change valueText to text in AdministrableProductProperty class
• correct error in commentAnnotation class -> Text should be text
• Berber will check whether there is a subset of propertyTypes in the FHIR library that is useful for the administrableProduct
• We we leave out unitOfPresentation as this might be confusing and units of administration will already be specified for the administration dose .
• We will add administrableProductIdentifier which will inherit from the identifier class.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall @EMuhlbradt @czwickl : see first version of new UML below (not yet uploaded to Github). I have not yet moved pharmalogicalClass and productDesignation as I first like to dive into the fhir property types. Feel free to comment on names and referential integrity. To be continued on Monday.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall : Interesting example from a Huntington Disease study. 1 intervention can include multiple tablets of different strengths. These would be different administrableProducts which implies that there should be a 0..* relationship from studyIntervention to AdministrableProductDefinition. Also, the same administrableProduct is reused across different interventions for the same study implying that for the API this should not be nested within the StudyIntervention class. See original table and my interpretation for the USDM below.

[BSnoeijerCD]

@EMuhlbradt @czwickl : See annotated UML below for you to work with.

[EMuhlbradt]

@EMuhlbradt @czwickl : See annotated UML below for you to work with.

@BSnoeijerCD can you re-post in a different format so I can access it? I can't open png from Github for some reason.

[BSnoeijerCD]

@EMuhlbradt @czwickl Apparently the upload in the zenhub environment dose not work. Is this better?

[BSnoeijerCD]

@dih-cdisc @ASL-RMarshall @czwickl @EMuhlbradt I have gone through 7 different studies now and came to the conclusion that

• given that an intervention is in a number of these randomly selected cases a combination of active and/or placebo tablets, it is better to reference the administrableProductDefinition from the Administration class instead of the StudyIntervention class. In that way we can link an intervention to different administrations (for example: 1 placebo tablet and 2 10 mg tablets) and define for each administration the corresponding frequency, dose and product definitions. See examples in attached document.
• in case of placebo, there is an administrableProduct describing that it matches the active product but often no ingredients are defined. So the relationship to ingredients should be 0.. instead of 1...
• in case of placebo a dose is not defined (and also not for other kinds of administrations like questionnaires or psychological interventions) so the dose relationship to quantity should be 0..1 instead of 1.
• there was 1 case that defined a longer list of ingredients. so if a sponsor wants to define the accompanying ingredients it is helpful to define whether the ingredient is active. We can use maybe a limited list of FHIR and make it extensible for this.
• in all cases the provider (usually the sponsor but might be different) is specified. I will see how this best can be stored in alignment with IDMP.
  • IDMP stores a manufacturer as an organization. This might be the same as provider. But a provider is more in the context of a clinical study and might in some cases be different from a manufacturer.
• it might be helpful to have some kind of timing indication for the administration class. apart from the regimen. Like evening, morning, before breakfast etc. This is in a number of cases specified. Intervention details StudyExplore Jul24.docx

We can discuss at the scrum tomorrow and hopefully decide to make these (small) changes.

[EMuhlbradt]

@EMuhlbradt @czwickl Apparently the upload in the zenhub environment dose not work. Is this better?

Much better, thank you @BSnoeijerCD !

[BSnoeijerCD]

I made the following changes to the UML (and uploaded to Github) based on our discussions today:

• moved administrableProduct reference to administrations class
• changed cardinality for frequency, route and dose to 0..* to allow for different (partial) specifications (including observational parts). Desired property types will be further explored based on input of the scrum today.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall @EMuhlbradt @czwickl Although IDMP covers manufacturer in the medicinal product definitions this might be slightly different then the provider/sourcing that is defined in most of the protocols I tested. The provider/sourcing is directly linked how it is done in the clinical study (e.g. who makes sure you get the medication). Therefore, I would not use IDMP manufacturer for this.

However, given the many instances of protocols that are including this information item, it would be beneficial to include sourcing/provider in the model. As this links to organizations and the corresponding structure, I propose to handle the sourcing/provider part of interventions in ticket #293. We need to consider then whether this would be on the level of AdministrableProductDefinition which would be beneficial if the intervention is the testing of interaction of multiple drugs or at the higher StudyIntervention level.

[EMuhlbradt]

@BSnoeijerCD @dih-cdisc @czwickl please see the attached draft terminology for this ticket. Note that we have questions in the yellow highlighted cells. 316-444.xlsx

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @ASL-rmarshall @czwickl Based on my experiences with real-world pharmacy data I should have known that multiple specifications of strengths (lower and upper limits) are possible for 1 ingredient. I missed that before in the EMA IDMP IG. See examples below from IDMP IG (chapter 2, Page 193):

This implies that the references strengthLowerLimit and strengthUpperLimit should be 1.. and 0.. respectively and names should be changed to strengthLowerLimits and strengthUperLimits Or maybe better: strengthsLowerLimit and strengthsUpperLimit as it refers to multiple strengths not multiple limits for the same strength.

[BSnoeijerCD]

@BSnoeijerCD @dih-cdisc @czwickl please see the attached draft terminology for this ticket. Note that we have questions in the yellow highlighted cells. 316-444.xlsx

Thank you @EMuhlbradt See my reactions in the last column. 316-444_BS.xlsx

[BSnoeijerCD]

@EMuhlbradt @dih-cdisc @czwickl AdminstrableProductProperty.types that I believe should be included:

• pH (C-Code C45997)
• storage condition
• pharmacological Class (C-Code C98768 - can then be removed from studyIntervention - but needs a code attribute)
• product designation (can then be removed from studyIntervention - but needs a code attribute)
• Storage condition
• Packaging (e.g. sealed container etc) For the rest it can be extensible.

Regarding the other optional types considered:

• release form is included in the CDISC CT for administrableDoseForm so does not have to be specified separately in our model.

[BSnoeijerCD]

As discussed during scrum today:

• regarding AdministrableProductDefinition: Review and remove definition part from class name. Fhir definition: "A medicinal product in the final form, suitable for administration - after any mixing of multiple components".
• Strengths - give more examples before we change anything
• We do not move ProductDesignation to AdministravleProductDefinition as it is not a feature of the product.
• We need to explore what information goes into pharmacologicClass before we decide to move it.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall @czwickl @EMuhlbradt Regarding the administrableProductDefinition as discussed last Thursday: In IDMP this is referred to as pharmaceuticalProduct which is then presented in the FHIR Resource AdministrableProductDefinition (EMA IDMP IG, Chapter 2, page 205).

The administrable pharmaceutical form is defined as follows (EMA IDMP IG, Chapter 2, page 204): The administrable pharmaceutical form refers to the pharmaceutical form for administration to the patient, after any necessary transformation of the "manufactured" pharmaceutical form has been carried out. The latter refers more to the dosing (after preparations have taken place) which we handle by the dose attribute in USDM. Also SNOMED makes a clear distinction between the pharmaceutical product and the administrable product.

Therefore, if we like to remove definition and stay close to IDMP, I would rename the class to PharmaceuticalProduct instead of AdministrableProductDefinition.

[BSnoeijerCD]

@dih-cdisc @ASL-rmarshall @czwickl @EMuhlbradt regarding pharmacologicClass see the CDISC page regarding the terminology to be used: https://www.cdisc.org/kb/known-issues/tsparm-pharmacological-class-terminology-change It looks medication - related so could link more to the product instead of the intervention which motivates that the attribute can move to the new class. Need to check some examples of this terminology on the NCI website.

[BSnoeijerCD]

@ASL-rmarshall @EMuhlbradt @czwickl @dih-cdisc See below updated annotated UML based on the discussions today. I applied the following changes:

• renamed AdministrableProductDefinition class to AdministrableProduct
• moved attribute pharmacologicClass to AdministrableProduct (it was before in the StudyIntervention class)
• Added name, label and description attributes to the Strength class
• Made strengthLowerLimit and strengthUpperLimit plural and renamed to strengthsLowerLimit and strengthsUpperLimit

[BSnoeijerCD]

As discussed during scrum today: I moved the reference attribute from the strength to the ingredient class:

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl @ASL-rmashall Please find attached the instance examples based on 9 randomly selected studies from clinicaltrials.gov.

InstancesExamples.xlsx

Note that as administrableProducts are often repeated for different interventions, it would be good to nest them in the API at the StudyVersion level. Then they can also be reused across multiple designs with the same study drug.

[ASL-rmarshall]

@BSnoeijerCD @dih-cdisc I've been looking at the Ingredient FHIR resource. It seems that:

• You can have multiple strengths defined for the ingredient substance:
  • You can have up to 1 "presentation" strength (strength represented with respect to the "presentation unit" - i.e., "amount per tablet", "amount per capsule", etc.).
  • You can have up to 1 "concentration" strength (strength represented with respect to unitary volume or mass - i.e., "amount per ml", "amount per mg", etc.)
  • You can have multiple "reference" strengths (strength represented with respect to another specified substance)
• Each of these types of strength can be represented as one of the following:
  • A ratio, represented as a combination of:
    • A numerator amount
      • For presentation and concentration strengths, this is an amount of the ingredient substance.
      • For reference strengths, I assume this is an amount of the reference substance.
    • A denominator amount
      • For presentation and concentration strengths, this is an amount of the "parent product" (the product that contains the ingredient). I think it would be helpful for this to be represented in the same units as specified for the "parent product" dose.
      • For reference strengths, I assume this is an amount of the ingredient substance.
  • A ratio range, represented as a combination of:
    • Low and high numerator amounts of:
      • Ingredient substance for presentation and concentration strengths
      • Reference substance for reference strengths
    • A single denominator amount of:
      • Parent product for presentation and concentration strengths (ideally in same unit as parent dose)
      • Ingredient substance for reference strengths.
  • A straight quantity.
    • For presentation and concentration strengths, this would be an amount of ingredient substance.
    • For reference strengths, I assume this would be an amount of reference substance.
    • However, for any type of strength, it's not 100% clear what this would represent - possibly the amount of ingredient/reference substance per single unit of the dose unit of the dose of the parent (e.g., per single tablet if the parent product is dosed in tablet units, or per single ml if the parent product is dosed in ml units). As it's not clear, perhaps we should avoid using these.
• Presentation and concentration strengths can also:
  • Be represented as a codeable concept (though I'm not sure what this would look like)
  • Have a corresponding textual description (textPresentation or textConcetration)
• The basis attribute can be used to indicate whether the ingredient is being represented as the base or salt - which might be relevant if for reference strengths.

If my understanding/interpretation is correct, this implies that:

• An ingredient can have multiple strengths, and each strength may have:
  • Low/high numerator amounts - so the low/high links should be between Strength and Quantity (though it seems strange not to use the Range class for this) instead of between Ingredient and Strength
  • A single numerator amount (represented as a Quantity)
  • A denominator amount (represented as a Quantity)
  • Possibly a 0..* link to a "reference" ingredient - so the reference link is from Strength to Ingredient. The linked ingredient would have it's own strength, which might need to be restricted to being a concentration strength, e.g. mass per mass.
• It might be useful to define a type attribute/relationship for Strength so that it's possible to differentiate presentation, concentration and reference strengths.
• We'd need rules or modelling to define which attributes/relationships must be used in which situations.
• Do we need to consider something like basis?

[BSnoeijerCD]

@ASL-rmarshall : Note that I started with the IDMP and then linked to the corresponding FHIR resources which was the scope of this ticket. That probably results in the differences of the changes I defined for the model with what you proposed above. Did you check this in the IDMP IG? Furhtermore, I checked what is usually defined in a protocol/study definition - basis is not defined there. If needed we can always add later but I do not see this information available at the moment. The ingredient name can already indicate this for the greater part.

@dih-cdisc

[ASL-rmarshall]

@BSnoeijerCD I was originally looking at the modelling from the point of view of working out how it should be used and which rules would be required. I hadn't looked at the IDMP IG, but I have now. As discussed on 2024-08-16, the focus of the modelling is to accommodate what's needed to for a study definition, bearing in mind the EMA IDMP IG requirements and - if needed - with reference to FHIR resources.

I agree that basis is not required because it's not typically specified in a study definition. I also agree that a lot of the detailed FHIR modelling is not required.

However, I think there are some tweaks that could be applied to the modelling that would simplify things a bit, align with existing USDM modelling, make it easier to create and check for conformant data, and eventually meet the EMA IDMA requirements. The following diagram shows these tweaks: These are the 4 suggested changes:

1. Make numerator range a property of the strength instead of having two independent strength specifications. In the diagram, I've shown this as:

   • A second numerator relationship to the Range class. I changed the cardinality for the original numerator relationship from from 1 to 0..1 because numerator can be specified as either a quantity or a range. We'd need a rule to check that a numerator is specified (either as a quantity or a range). Note that I also modified the unit relationship for Range to point to AliasCode instead of Code to be consistent with the unit relationship from Quantity. An alternative would be to not use the Range class and instead have numeratorLow (1) and numeratorHigh (0..1) relationships to Quantity (similar to FHIR RatioRange), but that's less in line with existing USDM modelling.
   • Replacing the strengthsUpperLimit and strengthsLowerLimit relationships with a single strengths relationship.

   This has the following advantages:

   • You don't have independent strength specifications for ranges, meaning that:
     • You don't need a rule to check for "low" strengths corresponding with any "high" strengths (which would probably have to be based on text matching between strength names)
     • You don't need a rule to check that the same unit is used for the denominator in high and low strengths (which would again have to be matches by textual names)
   • This is more in line with how strength ranges are specified in the protocol (e.g., "95-100 mg/ml" instead of "95mg/ml-100 mg/ml" or "88-90 mg in a vial" instead of "88 mg in a vial-90 mg in a vial")
   • It aligns with FHIR but is still mappable to EMA IDMP.
2. Rename the reference relationship on Ingredient to references and change the target cardinality from 0..1 to 0..*. According to both EMA IDMP and FHIR, you can have more than one reference strength.
3. Optionally add something like a role attribute/relationship to Ingredient - see FHIR Ingredient.role and associated value set. This is not 100% necessary, but it would facilitate:
   • Checking (e.g., ingredients that are starting materials for active ingredients are expected to have a reference strength, a referenced ingredient must be an active ingredient, etc.)
   • Mapping to EMA IDMP and FHIR
4. Optionally add something like a type attribute/relationship to Strength to differentiate "presentation" and "concentration". This is not 100% necessary, but it would potentially facilitate:
   • Checking (different types of denominator unit for presentation vs concentration strengths, not more than one strength of each type, etc.)
   • Mapping to EMA IDMP and FHIR

@dih-cdisc

[EMuhlbradt]

@BSnoeijerCD @dih-cdisc @czwickl see the attached file containing what we hope is the draft final new terms and changes to existing for this ticket. @BSnoeijerCD there is one outstanding question in row 20 in the 'new' tab. 316-444_Draft final.xlsx

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl Erins question is about reference as well and relates to what Richard indicates above in point 2. The related citations from the IDMP IG are below: "Reference strength represents the strength (quantitative composition) of the active moiety of the active substance or of another substance used to express the strength of the product. There are situations when the active substance and active moiety are different resulting in different expression of the strength. For example, if an active substance is in the form of a salt or hydrate, the reference strength shall be expressed in terms of the mass [or biological activity in International (or other) units where appropriate] of the active moiety (base, acid or anhydrous material). The reference substance and reference strength of the active substance(s) contained in the Pharmaceutical product or Manufactured Item can be found in section 2. Qualitative and Quantitative Composition of the corresponding SmPC. The reference strength shall be provided for active substances and is repeatable. However, there are cases where the reference strength of the active substance may not be provided. In cases where the quantitative composition of the excipient(s) and/or adjuvant(s) of the medicinal product is not reported in the relevant product information (i.e., SmPC), the substance strength is to be left empty and the substance reference strength is to be completed."

See also examples in Chapter 8 of IDMPIG - starting on page 38

This indicates that indeed there can be more than 1 reference strength. Given what I put in bold above, I am not sure whether it should be per se the active (component of the) ingredient.

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl Based on the discussions today. See the updated UML below with the two outstanding questions indicated as well.

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl I updated the list with instances and added a number of examples from IDMP Chapter 8. See attached. InstancesExamples_v2.xlsx

Note: that there was only 1 ingredient in the examples from IDMP (and none found in the selected protocols) that had a range for strength and this was an excipient and not an active ingredient. Given that and for a better understanding of the model when not IDMP related, I am now in favor of the suggested change from strengthsUpperLimit and strengthsLowerLimit relationships to 1 strengths relationship with the option to define a minValue and maxValue (using range class) for the numerator instead of value (using quantity class). The first row of this file indicates the paths according to the model version in the comment above. The second row in this files indicates the paths when this is changed.

Note: IDMP requires a reference strength for the active substance while the original strength might be missing. This information is missing in vaccine examples in the IDMP.

[BSnoeijerCD]

@dih-cdisc @EMuhlbradt @czwickl Please see the last updated version of the UML below (also uploaded to github). The last changes are based on our discussions earlier today. I indicated all intervention changes in yellow and the new changes in orange.

[BSnoeijerCD]

@EMuhlbradt @czwickl: This is the link for the ingredient role: https://www.hl7.org/fhir/valueset-ingredient-role.html

[EMuhlbradt]

@dih-cdisc @BSnoeijerCD Final changes are ready for QC in the Github CT deliverables folder.

[BSnoeijerCD]

Thank you @EMuhlbradt @czwickl

Based on my review I have the following comments:

• AgentAdministration should be changed to Administration - The reason for this is that it can be used more broadly for other types of interventions that can be specified as well like: behavioral therapy, diagnostic test, dietary supplement, radiation, medical procedure etc.
• Since we moved it, should the definition of pharmacologic class be changes to "The pharmacological class of the administrable product"?
• With previous links to SDTM codelists you specified that in the "Has value List" column like "Y (SDTM Terminology Codelist ... )". Should the SDTM be specified for administrableDoseForm?
• referenceSubtance: do we want to be more explicit regarding what is expected here? I put it like this in the IG: "Each active ingredient specified by its substance may have a reference substance, indicating the reference strength once the product is processed in vivo."

[EMuhlbradt]

Thank you @EMuhlbradt @czwickl

Based on my review I have the following comments:

• AgentAdministration should be changed to Administration - The reason for this is that it can be used more broadly for other types of interventions that can be specified as well like: behavioral therapy, diagnostic test, dietary supplement, radiation, medical procedure etc.
• Since we moved it, should the definition of pharmacologic class be changes to "The pharmacological class of the administrable product"?
• With previous links to SDTM codelists you specified that in the "Has value List" column like "Y (SDTM Terminology Codelist ... )". Should the SDTM be specified for administrableDoseForm?
• referenceSubtance: do we want to be more explicit regarding what is expected here? I put it like this in the IG: "Each active ingredient specified by its substance may have a reference substance, indicating the reference strength once the product is processed in vivo."

1. This should be done
2. Not sure because originally Craig and I decided to keep the semantics completely aligned with the TSPARM value when the attribute was attached to the other Class. Craig and I will need to discuss this as it would require recoding the concept.
3. Fixed 2024-09-03
4. Craig and I will have a look.

[EMuhlbradt]

@BSnoeijerCD

1. Craig and I discussed QC item 2 and have agreed that we should update the semantics (C-code, preferred term, and definition) for both 'pharmacologicClass' and 'administrableDoseForm' to reflect the AdministrableProduct class.
2. Craig and I do not agree to update the relationship definition because we think that clarification belongs in the Implementation guide (i.e., it is not definitional). We think the IG is the more appropriate place to explain what is needed for the referenceSubstance relationship because the examples for this would be so varied/complex. A relationship definition would not be able to encompass all of the nuances of this term (no matter how hard we tried).

[EMuhlbradt]

@BSnoeijerCD @dih-cdisc @ASL-rmarshall I have updated the CT deliverables in 3-6-0 release to update the semantics (C-code, preferred term, and definition) for both 'pharmacologicClass' and 'administrableDoseForm' to reflect the AdministrableProduct class.