Template talk:Infobox drug

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Drugbox)
Jump to: navigation, search
WikiProject Pharmacology (Rated NA-class)
WikiProject icon This template is within the scope of WikiProject Pharmacology, a collaborative effort to improve the coverage of Pharmacology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 NA  This template does not require a rating on the project's quality scale.

Add defined daily dose (DDD)[edit]

We have a nice database of them here. Should go under clinical data. Maybe right before route of admin. Will need to have a ref. Doc James (talk · contribs · email) 19:03, 8 September 2017 (UTC)

sure. Everything you think of is infobox relevant and must be in Clinical data section. Sigh. -DePiep (talk) 00:15, 9 September 2017 (UTC)
I don't think it's worth adding since I don't see how this metric would be at all useful to the vast majority of readers of any drug article. I imagine only medical/pharmacology researchers would benefit from including it. Seppi333 (Insert ) 15:23, 10 September 2017 (UTC)
It is actually one of the most common requests from the 100,000 or so people using our offline app. Doc James (talk · contribs · email) 10:47, 7 October 2017 (UTC)
How many requests have you received out of those 100,000? Seppi333 (Insert ) 18:30, 7 October 2017 (UTC)
If DDD is relevant, encyclopedically speaking, then the DDD will be noted in the article body already. So please link these articles, and {{Infobox drug}} will welcome it :-). However, {{Infobox drug}} will not add data that is not in the article. Per WP:INFOBOX. -DePiep (talk) 19:05, 7 October 2017 (UTC)
There is a lot of stuff in the infobox that is not in the body of the article. So what you say is not correct in practice. Doc James (talk · contribs · email) 12:31, 13 October 2017 (UTC)
No, wp:otherstuffexists is not an argement to include something. Ever. Because it can also lead to the opposite outcome: remove that other stuff, equally correct. -DePiep (talk) 12:45, 13 October 2017 (UTC)
WP:OTHERSTUFFEXISTS notes it can at times be a valid argument. It is an invalid logical argument, but a valid Bayesian argument. I think it is useful in certain cases as a supplemental inductive argument to bolster a case, though it shouldn't be the main argument.
Assuming good practices tend to persist longer and be more prevalent, if you're trying to argue X is probably a good idea (which is often the case because certainty is hard) then showing X has been implemented on many pages for long periods of time increases the a priori probability that X is a good idea. In other words, what is P(X is a good idea|X is widespread)? Sizeofint (talk) 18:23, 13 October 2017 (UTC)
Doc James did not (ever) claim this exception. So please speak for yourself, while Doc James can and should speak for themselves. -DePiep (talk) 22:43, 13 October 2017 (UTC)
Anyway still need to work on a few other things to get this proposal ready. I will at that point in time start a RfC. Doc James (talk · contribs · email) 04:28, 14 October 2017 (UTC)


Okay DDDs are now within WD. Next will be to get the notification system in place to make keeping an eye on all of them easy. Doc James (talk · contribs · email) 00:44, 22 December 2017 (UTC)

DDD: defined daily dose (Q1182681), P4250.
Example: amoxicillin: 1.0 gram[1]
-DePiep (talk) 16:48, 29 December 2017 (UTC)
Add to infobox the DDD read from Wikidata, then
Clinical data
Defined daily dose 1.0 gram[1] Edit this at Wikidata

We can read the DDD directly from Wikidata, and publish it in the drugbox (see aAmoxicillin demo). This is automated, and does not require any parameter. Any WD reference is added, and the pencil-link to edit WD.

I do not understand the tracking & checking Doc_James has in mind. An extra check on Wikidata? Note that it is possible to track Wikidata edits in your personal watchlist.

Note that already, {{Infobox drug}} publishes the Wikidata value for E number and ECHA Infocard ID (see Vitamin C, Category:Chemical compounds and Wikidata). -DePiep (talk) 17:58, 29 December 2017 (UTC) @Doc James:. -DePiep (talk) 18:00, 29 December 2017 (UTC)


Infobox identifier discussions[edit]

I've unarchived some of the threads on this topic and created this super-thread to keep all of the threads together when they're archived; I've moved all of the talk page sections pertaining to this discussion to a corresponding level 3 sub-section below. Seppi333 (Insert ) 20:47, 4 January 2018 (UTC)

Move non human readable identifiers out of infobox[edit]

With {{Infobox medical condition (new)}} we have moved (some of) the identifiers to the 'External links' section and placed them in {{Medical resources}}. Does anyone have thoughts about doing the same here (and likely for {{Chembox}} as well)? I think this would help cut down on the length of the infobox while still leaving them accessible for the (relatively small) group of readers who find them useful. Sizeofint (talk) 00:21, 9 September 2017 (UTC)

Which are you suggesting moving? Doc James (talk · contribs · email) 00:29, 9 September 2017 (UTC)
| CAS_number        = 
| CAS_supplemental  = 
| PubChem           = 
| PubChemSubstance  = 
| IUPHAR_ligand     = 
| DrugBank          = 
| ChemSpiderID      = 
| UNII              = 
| KEGG              = 
| ChEBI             = 
| ChEMBL            = 
| PDB_ligand        =
| NIAID_ChemDB      =
and possibly
| Drugs.com = 
| MedlinePlus = 
The IUPAC name could be moved to the clinical data section. Sizeofint (talk) 00:42, 9 September 2017 (UTC)
"The IUPAC name could be moved to the clinical data section" -- Oh please shut up. We are an encyclopedia, not a helpdesk for clinics. -DePiep (talk) 00:53, 9 September 2017 (UTC)
I agree it would be good to group the various names for a substance together. Doc James (talk · contribs · email) 00:55, 9 September 2017 (UTC)
Is not what I asked for. -DePiep (talk) 00:57, 9 September 2017 (UTC)
If we move the identifiers, my thinking is that since it is a chemical name it would make sense to place the IUPHAR IUPAC name near the other other synonyms. It doesn't link to an external site so I don't think it would be appropriate to move it with the others. Sizeofint (talk) 00:59, 9 September 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Yes, we should move data out of the infobox into lower article sections.
That could & should affect {{Chembox}}, {{Infobox drug}}, {{Infobox element}}, ... Whether into 'external links' or '[new] data sheet' is not that important. The real problem is: heavy-weight editors do not want their pet-data to be removed. (example: {{Chembox}} has a ~dozen external links in top. See Aspirin). -DePiep (talk) 01:28, 9 September 2017 (UTC)
IMO the ATC codes should also be moved lower along with the other identifiers. Would be fine with seeing MedlinePlus moved aswell. Our article however miss a lot of details so support keeping drugs.com were it is. Doc James (talk · contribs · email) 14:14, 9 September 2017 (UTC)
This is exactly illustrating the point I made one paragraph earlier: so what information is to be kept in the infobox is not based on being a summary of the article. Infobox is degraded into a linkfarm and overview, links at hand, to be useful for a non-general reader and not encyclopedic. We need self-restriction by high-end editors (confirming to WP:INFOBOX for starters). -DePiep (talk) 14:31, 9 September 2017 (UTC)
And no, ATC could be in the infobox (when spelled out), as it is a classification. -DePiep (talk) 14:31, 9 September 2017 (UTC)
Yes, I think we have had discussions about the ATC code before. IMO it is more of a classifier than an indentifier so I think it is more appropriate to keep it under clinical data. I'm fine with leaving the drugs.com link. Sizeofint (talk) 17:09, 9 September 2017 (UTC)

Sure we should move out

| smiles = 
| StdInChI =
| StdInChIKey =

right? Being extremely non-human readable. -DePiep (talk) 14:34, 9 September 2017 (UTC)

As I understand, they are more than identifiers - really shorthand ways of describing a chemical structure - so I wasn't really thinking about including them in this discussion. They aren't external links so I don't think it would be appropriate to place them in that section. Besides making a special template to put them in a 'Chemistry' section I can't think of what else to do with them. I'm fine with leaving them where they are for the moment. Sizeofint (talk) 17:26, 9 September 2017 (UTC)
You lost me. Even before your idea is fleshed out, you (and Doc J) already claim exceptions for personal preferences? -DePiep (talk) 21:12, 9 September 2017 (UTC)
What I mean is that they contain structural information about a molecule which makes them dissimilar to the other identifiers which are just database keys. I believe they may fall under your IN-2 point below. Sizeofint (talk) 01:32, 10 September 2017 (UTC)
OK, they are not external database keys. But I've pulled the topic wider: there are more reasons to move data out of the infobox. Such as: not useful as article summary.Believing they should be an IN-2 exception: that's the ugly road I'm trying to avoid. Already 'believing' is not a strong argument; and it is pulling the pet-data argument at first instance. If we (involved editors) can not be self-critical and restrictive about the infobox, this excercise is going to be fruitless, resulting in a equally chaotic information presentation. -DePiep (talk) 08:55, 10 September 2017 (UTC)
But I've pulled the topic wider Okay, I didn't realize you wanted to to broaden the scope of this discussion beyond the external database links. Sizeofint (talk) 17:36, 10 September 2017 (UTC)
I think we can only improve something by thinking from WP:INFOBOX first. Not individual parameters, not even groups like those external links. We should make the infobox best & strong. Then, issues from that ("what to do with data point x, with data set y?"), must be accomodated elsewhere in the article (or deleted). In that order. Infobox design first really. -DePiep (talk) 17:48, 10 September 2017 (UTC)
They are out of place in an infobox. And sure, they are inhuman. -DePiep (talk) 21:08, 9 September 2017 (UTC)
I can't read them but according to Simplified molecular-input line-entry system and International Chemical Identifier they are intended to be human readable (to a savvy chemist at least). Sizeofint (talk) 01:32, 10 September 2017 (UTC)
Yes they are ASCII-characters only, but that does not make them readable as in: meaning something to the reader. And that savvy chemist: is not our Reader. Again, why not move them down into the article body (say section Data sheet)? What is the reason to add them to the infobox at all? (Please read WP:INFOBOX to get the design aim of it). -DePiep (talk) 08:55, 10 September 2017 (UTC)
why not move them down into the article body (say section Data sheet)? I imagine some editors thought the information should be compactly together in the infobox. If we add a "Data sheet" section, shouldn't all the IN-2 data end up there? Sizeofint (talk) 17:36, 10 September 2017 (UTC)
Hard to argue with your imagining other editors thoughts. Those editors should come forward by themselves. As for IN-2: I meant this route for extreme and undisputed exceptions (like melting point). Not for (allow me to say so) pet data. If involved editors like us keep pushing pet data into the infobox, who is guarding the overall size & relevance of it? (even more important in mobile view, one cannot skip or fold the infobox there!). -DePiep (talk) 17:56, 10 September 2017 (UTC)
  • More general: why include, why exclude data from infobox?
To include
IN-1. Data is summary of article, already mentioned in body text (per WP:INFOBOX)
IN-2. Data is udisputed major fact, while not reasonably expected in body text (example: melting point)
To exclude
OUT-1: Is external link
OUT-2: No information (e.g., just a code number, or external id)
OUT-3: Encyclopedic info, but not in body text and not of infobox relevance
  • Where to put it then?
External links could go in section ==external links==
A new, standard section could be added: ==Data sheet== (working sectiontitle).
This could contain a wide list of data, including the external links and inhuman texts.
-DePiep (talk) 21:08, 9 September 2017 (UTC)
We could also punt it off to Wikidata. Sizeofint (talk) 01:42, 10 September 2017 (UTC)
This does not make sense. The question is: should it be in the article, and then where? (irrelevant whether the article has it in its source, or that it is read from Wikidata). -DePiep (talk) 08:43, 10 September 2017 (UTC)
I mean don't have it in the article at all and just direct interested readers to WikiData (e.g. at the bottom of the infobox put "More data available on WikiData" linking WikiData to the appropriate page). A data sheet section may work but some editors may oppose it on grounds of WP:INDISCRIMINATE. Sizeofint (talk) 17:36, 10 September 2017 (UTC)
A Wikidata page is hardly the informative webpage, its more data facts only (no page design for readers). Wikidata is for pulling data out of it, but not for showing. -DePiep (talk) 19:00, 10 September 2017 (UTC)

Or: collapse identifiers block in infobox[edit]

I very strongly prefer that all of the identifiers remain in the drugbox; however, I think it would be prudent to collapse the entire identifiers section for the sake of navigation. If people want external links to relevant databases in infoboxes (e.g., someone like me; I use the PubChem, IUPHAR, and DrugBank links very frequently in drug articles that have those included in the drugbox), then retaining these in a collapsed form retains their utility while reducing clutter for other readers who don't use those links. Seppi333 (Insert ) 06:47, 28 September 2017 (UTC)

Edit: I actually just came here to propose collapsing the identifiers section due to the size of the drugbox in some articles, but read this thread first. I probably would've created a new section to make my proposal otherwise. Seppi333 (Insert ) 06:53, 28 September 2017 (UTC)

@Sizeofint, Doc James, and DePiep: How do you feel about this alternative? Seppi333 (Insert ) 07:19, 28 September 2017 (UTC)
  • re. First and foremost, collapsing in infoboxes is not a serious design option. Because: mobile view does not know 'collapse' (show/hide) such parts. The only collapse mobile view knows, is section headers. So to support mobile viewing, we must design infoboxes as being uncollapsible/uncollapsed (collapse is an extra in desktop view). This is by m.wiki page design. The reason I've learned is, that TOC/sections/pagenavigation in mobile requires a different approach.
(If any collapse would be added to mobiles, I'd propose to make the whole infobox (all of them, enwiki wide) collapsible like a sub/section; notice how infobox appears in mobile: after the first paragraph btw).
  • re 2: I still think those identifiers do not have a place in the WP:INFOBOX. They are not summarizing the article, they add no information, they are external links (each one of these alone is killing). Once removed, the "size" issue is reduced as an welcome effect of better infobox setup. Not unexpected: "too long" (size) already indicates "too much data" (design).
The reason why they are still there is illustrated by Seppi333 above: "Someone like me; I use the PubChem, IUPHAR, and DrugBank links very frequently". But that 'someone like me' is not the target reader, and the '... use them frequently' is not a good inclusion-in-infobox reason. I call this pet-data: only heavy users (involved editors like us) are keeping in the infobox because "I" use it often, "I" find it easy to have nearby. It is exactly these editors (we) that need to apply restriction wrt infobox content. If we keep evading this (pushing individual data into the box, but not taking responsibility for the overall box view), no infobox improvement is to be reached. All this while the answer is easy: move those external ID el's to External links, systematically. -DePiep (talk) 07:49, 28 September 2017 (UTC)
Straying off-topic a bit, what is the CSS-ish magic that makes sections collapsible on mobile and why can't that be replicated as a more generally available container? DMacks (talk) 07:58, 28 September 2017 (UTC)
I don't know, but keep in mind that it is by design, that is: Wikipedia level (MediaWiki?). -DePiep (talk) 08:34, 28 September 2017 (UTC)
One technical concern with collapsing is the visibility to external search engines. As much as we can be a starting point with pointers to external database sites, we can also be discoverable by searching for the compound itself--database tokens are useful beyond the original database sites. I just checked and at least Google search by SMILES and InChI does find chembox articles where those fields are collapsed. So that's good.
If we really do want to have smaller infobox, I would prefer collapsing rather than moving certain fields elsewhere. Some of the fields being discussed are inter-related. For example, SMILES is structural not database token, but is often usable as a database search term. But it also is how the Jmol VR model is generated, which is definitely user-oriented content and not solely niche readership. That means SMILES needs to be in the same template as the Jmol, which blurs the distinction between machine-readable/niche-readers and general-readership. DMacks (talk) 07:53, 28 September 2017 (UTC)
As I described above, collapsing does not reduce infobox size. Instead, it shows stresses that there is unneeded data in there. -DePiep (talk) 09:19, 28 September 2017 (UTC)
I'm aware that mobile viewing doesn't allow for collapsible content, but I still think that it should be collapsed. A lack of improvement on mobile and a general improvement on desktop is still an improvement, at least pending further changes for improved mobile viewing (i.e., while we're discussing what to do, some drugboxes remain excessively long in part because of their identifiers section - my proposal is at the very least a temp-fix for desktop viewers). Seppi333 (Insert ) 08:12, 28 September 2017 (UTC)
Again: the reason(s) you want it collapsed it the same reason it does not belong in the infobox. Please respond to my move-to-article-body point. -DePiep (talk) 08:34, 28 September 2017 (UTC)
I'm okay with systematically moving them all to the external links section. However, that will take time to implement (i.e., someone needs to write a script for a bot which will then need to execute that across a bajillion drug articles), whereas adding a collapse tab to the section takes as long to implement and come into effect as it took me to write this response. Seppi333 (Insert ) 08:59, 28 September 2017 (UTC)
It's not an implementation problem, nor the other technical knots ahead. (We could easily have a bot move certain infobox sections elsewhere in the article, in a new appropriate template). Even worse, making a "quick fix" now (collapsing against design) will ensure that a true improvement will not be supported at all. Because: this quick fix is rewarding the pet-data claims into concrete. It's the non-support that is the bottleneck. I've encountered this issue of 'pet-data' (both external IDs and loads of trivial data rows being added) in {{Infobox drug}}, {{Chembox}}, {{Infobox element}} by many involved editors. Note that already in this half-a-day talk, two seriously involved editors keep wiggling out of my suggestion by ignoring it. For this reason, from those three infobox encounters, I do not even find energy to start the much-needed RfC. -DePiep (talk) 09:19, 28 September 2017 (UTC)
I've already said I support your proposal because I acknowledge mine has flaws. I don't know why you're acting like I'm opposed to your idea. All I'm proposing here is simply analogous to covering up a disgusting wound on an arm that needs to be amputated before amputating it. Seppi333 (Insert ) 09:45, 28 September 2017 (UTC)
Anyway, I don't really feel like having an argument over this, so I'm ok with your solution without collapsing it in the meantime as long as your proposed solution (i.e., moving drugbox identifiers to the EL section) is implemented sometime in the near future. Seppi333 (Insert ) 09:48, 28 September 2017 (UTC)
1. You're right, I struck. 2. I expect/predict, collapsing 'for now' will make a true improvement further out of reach (collapsing has be advocated before). 3. Note that 'involved editors' are also the good to very good editors. I'm just having trouble getting the talk to be about infobox design. -DePiep (talk) 10:08, 28 September 2017 (UTC)

Strong oppose Better to collapse identifiers section than to split up the infobox. Boghog (talk) 22:27, 28 September 2017 (UTC) ──────────────────────────────────────────────────────────────────────────────────────────────────── But as DePiep says, collapsing is not possible on mobile, the platform swiftly becoming the dominant way of accessing WP (if it is not already). I also agree with his assessment that a desire to collapse perhaps indicates the content shouldn't be in the infobox at all. We successfully moved the database links to the external links section in {{Infobox medical condition (new)}}. What makes this template different such that keeping the database links is justified? Sizeofint (talk) 23:59, 28 September 2017 (UTC)

Collapsing is not currently possible on mobile web browsers, but should be in the future. There was a request that was merged into this request to make it collapsible. Even better solution would be to collapse all infoboxes by default which is currently done in the Wikipedia mobile apps. For example, the iOS Wikipedia app, collapses the drugbox with the heading "Quick Facts: Clinical data, Pronunciation ...". On the desktop, the infobox does not need collapsing because it is displayed on the righthand side. It is better to keep all these links in one place rather than split them between two infoboxes, one at the top and one at the end of the article. This also applies to {{Infobox medical condition (new)}}. Boghog (talk) 06:06, 29 September 2017 (UTC)
Were it technically possible, that still does not merit inclusion of all that data in the infobox in the first place. (Only argument so far, by involved editors:, is like "nice to have it nearby" — I call this "pet data"). That's not what WP:INFOBOX is designed for. Also, if you want to collapse something, it shouldn't be in the infobox in the first place. An could you engage in this point: we, editors, need to restrict ourselves in adding data to the box (i.e., take responsibilitry to remove data from it), to improve the infobox as a whole page element. -DePiep (talk) 07:42, 29 September 2017 (UTC)
It is better to keep all these links in one place rather than split them between two infoboxes, one at the top and one at the end of the article. So why not just put them all at the end? You know... in the "External links" section... because they're external links. Sizeofint (talk) 06:09, 30 September 2017 (UTC)
Because they are more conveniently accessed in the infobox. The WP:EL guideline specifically allows external links in infoboxes and there is a long tradition of including them. Boghog (talk) 08:26, 30 September 2017 (UTC)
While it is more convenient for finding these links, the more we stuff in the infobox the less convenient the infobox becomes overall because it takes more time to identify the facts one is interested in. We need to balance this. The infobox is becoming too long and collapsing sections, even if implemented on mobile, is not likely an option for accessibility reasons. Asking editors to not fill in fields to keep the length down has never been effective; as long the parameter is available somebody eventually wants to fill it. Therefore something needs to be removed. Because there is a clear alternative location for the database links I think moving these is a good option. Sizeofint (talk) 17:45, 30 September 2017 (UTC)
Re the "pet data" comments: we don't have any Wikipedia readers who are not editors here to comment as to the usefulness of what I call "useful identifiers", so it hasn't been established that said links are only useful to editors. Seppi333 (Insert ) 18:31, 30 September 2017 (UTC)
Yep. The only thing we know for sure is that editors cannot restrict themselves to keep Infobox small. -DePiep (talk) 23:18, 1 October 2017 (UTC)

Move External links from infobox to new EL box[edit]

@Sizeofint and Doc James: Unless either of you, or anyone else for that matter, has any qualms with the solution proposed here, I think it'd be prudent to start moving the identifiers listed below to the EL section in their respective external link templates (e.g., {{Pubchem}}) within the next week or two (note: every identifier except the IUPAC name is an external link and a "data sheet" section would create issues with the manual of style's guidance on not placing external links elsewhere in the article body - MOS:Layout#External links). The length of drugboxes has been an issue for a while and this seems to be the only practical solution. Seppi333 (Insert ) 14:41, 28 September 2017 (UTC)

List of "identifiers" (database links) to move to an "External links" section
 | PubChem           = (useful EL)
 | PubChemSubstance  = (fairly useless EL IMO)
 | IUPHAR_ligand     = (useful EL)
 | DrugBank          = (useful EL)
 | ChemSpiderID      = (useful EL)
 | UNII              = (completely useless EL IMO)
 | KEGG              = (useful EL)
 | ChEBI             = (useful EL)
 | ChEMBL            = (useful EL)
 | PDB_ligand        = (fairly useless EL IMO)
 | NIAID_ChemDB      = (completely useless EL IMO)
Edit: the "ECHA InfoCard" identifier is imported from Wikidata via data88 and label88 in this template - that is also a completely useless EL IMO and it should just be cut from the templated

Note that I haven't listed the CAS number here because that, along with the IUPAC name, really should stay in the drugbox. The CAS registry number and IUPAC name of a drug are the only two actual chemical identifiers in the current identifiers section; the rest are just database links. Seppi333 (Insert ) 14:41, 28 September 2017 (UTC)

Thanks User:Seppi333 for the ping. I support moving the list of items you mention here.
I can also get built a gadget that does the moving if people want. If we could get the move done by bot that would be even better. Some of tricky bits are how to do the move if no "external links" heading currently exists in the article. Doc James (talk · contribs · email) 15:48, 28 September 2017 (UTC)
Support as well. Sizeofint (talk) 18:54, 28 September 2017 (UTC)

Strongly oppose. I still think collapsing portions of the navbox makes more sense than splitting it. Boghog (talk) 22:08, 28 September 2017 (UTC)

see previous discussion. This is not a !vote question. -DePiep (talk) 22:15, 28 September 2017 (UTC)
It is now. There is no consensus in the above section that we should proceed with this proposal. There is even less consensus after my no vote. Boghog (talk) 22:25, 28 September 2017 (UTC)
see prev talk for arguing. This section is exploring. over there you'll find replies to your point. -DePiep (talk) 22:56, 28 September 2017 (UTC)
From what I understand from User:RexxS hiding content is a problem for people using screen readers and thus the practice is not recommended.
Agree we will likely need a formal RfC. Doc James (talk · contribs · email) 06:18, 29 September 2017 (UTC)
Yes, we should start an RfC. Sizeofint (talk) 17:59, 30 September 2017 (UTC)
  • Boghog. Many months and many fora (talks) we have met over this. I still don't get: why should those external links, adding no information, being not part of article body text, be in the infobox at all. (And once they are in, you want to collapse them into invisibility...?). I note that this question likely will appear in an RfC too. -DePiep (talk) 00:02, 30 September 2017 (UTC)
adding no information – you are contradicting yourself. Above you have characterized many of the external links as useful. How can an external link be both useful and add no information? Boghog (talk) 03:36, 30 September 2017 (UTC)
It provides a pointer to other resources but contains no content itself. Basically data vs. metadata Sizeofint (talk) 06:18, 30 September 2017 (UTC)
Many of the external links not only contain metadata, but also information themselves. For example, the PubChem link page for aspirin contains a extensive amount of information directly in the page as well as links to other sources. Boghog (talk) 08:24, 30 September 2017 (UTC)
I was talking about the link itself. Not the content the link points to. Sizeofint (talk) 17:27, 30 September 2017 (UTC)
re Boghog: I mean "information" as in: meaningful statement, related to the topic. (while 'data' is a fact too, but not necessarily relative nor saying something). Then, applied for these external links: the external identifier is not a statement, so is not information. And yes, I find them useful data for the article, as external link. But not in WP:INFOBOX per WP:INFOBOX. They have a place in section ==External links== (or ==Further reading==).
Now could you answer the question about your own opinion: why in the WP:INFOBOX and not elsewhere? -DePiep (talk) 08:50, 30 September 2017 (UTC)
Data and information are practically synonymous. While information is sometimes defined as processed raw data, many of these external links contain more than raw data, they also contain information. Including external links in infoboxes has a long tradition and is specifically allowed by the WP:EL guideline. Infoboxes provide a quick overview of the subject and including key external links is an essential part of that overview. Having these links in the infobox is more accessible than in an external link section at the end of an article. Boghog (talk) 09:23, 30 September 2017 (UTC)
I described how I used the words 'information' versus 'data', as an answer to your question. As I said, they are not synonyms (esp in this encyclopedia), and you redefining my opinion does not help you understanding me (wp:idonthearyou). And yes I know they contain information, but they are not information by themselves (reading that identifier says nothing about the topic).
WP:EL does not allow or promote el's in infoboxes (instead, it strongly points to the EL section and references). And tellingly, you do not refer to WP:INFOBOX which should be the first place to go, right? (note that even companies can have only one, official, el in their infobox, btw usually as a readable url. One el). Also, being a 'tradition' is not that convincing, given that wp is a developing project based on continuous argued improvement. Now on that "quick overview" and "more accessible": well, the el does not add to any overview, being an abstract identifier. Yes it is closer at hand, but exactly that is why the EL section is placed near the bottom: that's by wiki page design. It shows the relevance of el's wrt the article. I get the impression that you perceive the infobox as a mini article page for the way you personally use the drug articles (as more involved editors want to use it, themselves). Understandable, but not what the reader expects (maybe onkmowingly expects). What I ask is that we, editors, re-approach the infobox from the encyclopedic view as it was designed. Now the infobox is too long, because there is too much data in there. -DePiep (talk) 09:49, 30 September 2017 (UTC)
Information is data + context. Context is provided internal wikilink that proceeds the external link. The identifiers in the identifiers section (e.g., CAS Number, DrugBank, etc) are every bit as information containing as the identifiers in the clinical data or legal sections (MedlinePlus, ATC codes, Legal status). Contrary to your assertion, WP:EL does allow external links in infoboxes by specifically stating that external links may be included in an appropriate location within an infobox. I never said WP:EL promotes links in infoboxes. By their wide spread adoption, many readers have come to expect that appropriate external links are included infoboxes. I agree that many of these infoboxes have become too long, but I think the infobox template itself should retain the option of including these parameters to allow contributors exercise editorial judgement on a article-by-article basis. For example, the relative importance of some of these links differ depending on whether the drug is investigational or approved. Boghog (talk) 10:47, 30 September 2017 (UTC)
Again, you are redefining what I said, then drawing conclusions to your like (isn't that called a strawmnan?). I said, and meant to say: "information is meaningful data". "MedlinePlus: a682878" is not. Next, you keep referring to WP:EL, but not once mention WP:INFOBOX. Strange. Anyway, WP:EL is already very clear and strict about official websites; why expand that to dozens of non-offical websites? Plus, the word 'appropriate' is key: per WP:INFOBOX, these links are not appropriate in an infobox (not article summary, not information by themselves, external link). And no, readers do not expect these el's in infoboxes: their spread is couter-design and so are wrongfooting readers. By design, el's are not to be expected in infoboxes (with few, limited exceptions). The drugbox does not show & act as an wp:infobox, so the reader is not helped but confused. Receiving information is a subtle process, too easily broken. -DePiep (talk) 12:08, 30 September 2017 (UTC)
I am not re-defining, only clarifying using generally accepted definitions. Hence not a straw-man. MedlinePlus: a682878 (database accession number) is meaningful information as the internal wiki link provides context. The accession number is displayed to provide a clickable link to the corresponding MedlinePlus external link. The external link is rich in relevant information. WP:EL allows and WP:INFOBOX does not prohibit external links in infoboxes. Full stop. Boghog (talk) 16:20, 30 September 2017 (UTC)
"a682878" is not information and so not fit for an infobox. -DePiep (talk) 23:51, 30 September 2017 (UTC)
Then we will have to agree to disagree. Boghog (talk) 02:23, 1 October 2017 (UTC)
DePiep I think you have completely missed the point of these links. The visible link that is displayed in the infobox (in this case a database accession number) is not nearly as important as the target of that link and I think there is general agreement that at least some of these external links are useful. To argue that external links should not be included in infoboxes because you object to how the link is displayed in the infobox is absurd. How else to display a link to a specific entry in an external database than to use the entries accession number? We perhaps could use something like "MedlinePlus database entry for aspirin", but is this really an improvement over "MedlinePlus: a682878"? Finally the accession number is information as its meaning is made clear by the internal wiki link that proceeds it. Boghog (talk) 13:21, 1 October 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── If it is the case that the accession number is not important then we should really rename the 'Identifiers' section 'External links' (and move the actual identifiers like the IUPAC name to another section of the infobox). This then raises the question of why we split the external links across two locations instead of placing them all together. Sizeofint (talk) 17:30, 1 October 2017 (UTC)

RfC question wording[edit]

How ought we phrase an RfC question (or multiple RfC questions) to discuss the issues raised above? And what would the scope of such an RfC be (Drugbox only or Drugbox + Chembox)? Sizeofint (talk) 08:50, 1 October 2017 (UTC)

  • (WP:RFC). Thoughts: I'd suggest a single simple question like:
"In articles with {{Infobox drug}} or {{Infobox chemical}} (aka {{Drugbox}} and {{Chembox}}), should the external links be in the infobox or in section External links (+an indication of which el's)".
I'd like to include both infoboxes. They are very similar in this, but it will pull this broader in many ways, and so could easilier not reach consensus/answer: I prefer a thorough result; YMMV. (Maybe invite WT:CHEMS already for this preparation talks?) Also, I think it should not be just a technical question (possibilities, wikilawyering), but more about our page design (how to present information). In the consideration, mention MOS:INFOBOX, WP:EL, MOS:LAYOUT. -DePiep (talk) 09:26, 1 October 2017 (UTC) (Added box names to the question, as it must stand on its own without title). -DePiep (talk) 09:33, 1 October 2017 (UTC)
I add: personally, I can imagine this option is acceptable too: create a new section ==Data sheet== in the articles to contain both these ELs and minor data like InChI string (data not fit for infobox). A 'data sheet' is quite common in chemistry. However, this might complicate the RfC into three-way options, which is not effective (will not produce a convincing result). -DePiep (talk) 12:20, 1 October 2017 (UTC)
Yes, comes to mind, but tooo easily and tooo uselessly. Negatives: AC is a crude class=navbox, i.e. not visible in mobile (and not printed). That's for a reason. AC IDs are not information, they are just checking keys. Not information: keys. Just to connect to other DB's (ID confirmation). As an article fact, they are useless and meaningless. Even more so then, for the article infobox. -DePiep (talk) 23:37, 1 October 2017 (UTC)
  • Create an example of what the proposal is proposing and than ask whether we should roll out such a change widely. Doc James (talk · contribs · email) 21:56, 1 October 2017 (UTC
Better not talk about a demo. Would lead us all into technical and detail issues. Main textual question is better: "Where should the ELs be". -DePiep (talk) 22:42, 1 October 2017 (UTC)
More thinking done: Agree, a demo would be good (it could point out issues). Hope I can make one shortly. (I'm thinking about a "EL-box" template). Doc James@ -DePiep (talk) 11:50, 2 October 2017 (UTC)
Thanks User:DePiep sounds good. Doc James (talk · contribs · email) 04:04, 4 October 2017 (UTC)
It's more complicated. There are those subtleties wrt ELs, like "This actually is a source". Working on this. We have time, don't we? -DePiep (talk) 19:13, 7 October 2017 (UTC)
Changing the "medical condition" template took a few years of discussion, a number of mockups, and than another year for gradual rollout that is far from complete. Yes there is no hurry. Doc James (talk · contribs · email) 22:04, 7 October 2017 (UTC)
Did I really sign up for a three year job? Good to know ;-) -DePiep (talk) 00:11, 8 October 2017 (UTC)
LOL. 718smiley.svg Seppi333 (Insert ) 03:48, 13 October 2017 (UTC)

Typo causing stray span tag in Collagenase clostridium histolyticum?[edit]

A recent change to this template or a subtemplate appears to have caused a stray exposed span tag in Collagenase clostridium histolyticum. DePiep, can you please take a look? Thanks. – Jonesey95 (talk) 16:10, 25 October 2017 (UTC)

will look later on. Thx. -DePiep (talk)
I fixed the incident, but it was a <br> in parameter drug_name ??? Pls check all names involved, in that article. Also pls update me. DePiep (talk) 20:34, 25 October 2017 (UTC)
I add: EMA search fails b.c of bad names. One can use param ema_inn or so. DePiep (talk) 20:39, 25 October 2017 (UTC)
I did not cause the problem, nor do I know how to fix it. A change to the template appears to have corrupted article rendering. If that is the case, the template should either be reverted or should be modified to detect and categorize pages that have bad input so that they can be fixed. Another example is Wikipedia:WikiProject Medicine/Translation task force/RTT/Simple Testosterone. – Jonesey95 (talk) 22:37, 25 October 2017 (UTC)
No one said you 'caused' anything. -DePiep (talk) 23:14, 25 October 2017 (UTC)
  • Fixed. You are right wrt the proper handling. I note that in both error cases, the input has unexpected code (<br/> hard line break), which is incorrect input for |drug_name= per {{Infobox drug/doc}}.
So the error is gone, but the intended link may still disfunction because it searches the EMA site with a wrong drug name (not INN, or unexpected code). If that drug name cannot be improved somehow, one can use |INN_EMA= with the correct search term in case. -DePiep (talk) 15:13, 26 October 2017 (UTC)

Gene therapy[edit]

As we now have a few gene therapies approved, how should this box be appropriately used? It's not a drug in the classic sense, and there are some parameters that could probably be added if "gene therapy" was a defined type. Natureium (talk) 16:40, 20 December 2017 (UTC)

We can build this, of course. I like to hear from others. Is it a drug? A therapy? Experimental only? -DePiep (talk) 00:12, 21 December 2017 (UTC)
The technology may be experimental, but some are not "experimental drugs", because they've been approved by the FDA (voretigene neparvovec and tisagenlecleucel). Natureium (talk) 20:58, 21 December 2017 (UTC)
Over the next decade or two, I'd expect the number of FDA-approved gene therapies to markedly increase relative to the current number, so it's probably worth adding functionality for this class of therapeutics in the drugbox. Seppi333 (Insert )
I think they are close enough to have a version of this template used for them. Doc James (talk · contribs · email) 00:43, 22 December 2017 (UTC)
New parameters needed for this? New section header even maybe? -DePiep (talk) 16:24, 29 December 2017 (UTC)
New section and new parameters. Parameters would probably need to specify the gene(s) that are targeted by the therapy, the therapy transfer method (viral transduction vs transfection) and the specific type of transduction (i.e., the viral vector that is employed – e.g., the adeno-associated viral vector or lentiviral vector) or transfection method (I'm not sure what transfection methods are used clinically; however, I've read about someone "self-administering" an experimental non-clinical gene therapy using electroporation while a physician was watching – i.e., the individual electrocuted himself). Seppi333 (Insert ) 23:16, 29 December 2017 (UTC)
Then do make a sketch please (LH labels, RH data examples, section header). However. I stil am in doubt on why a therapy should have a drugbox. There is not an {{Infobox therapy}}? -DePiep (talk) 01:25, 30 December 2017 (UTC)
Ah, found {{Infobox medical intervention}}. So why not expand that one for gene therapy? -DePiep (talk) 01:28, 30 December 2017 (UTC)
Agree with User:DePiep suggestion as that being a better place. Doc James (talk · contribs · email) 06:44, 30 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Why? A gene therapy – "the therapeutic delivery of nucleic acid into a patient's cells as a drug to treat disease.[1]" – is a drug. The only difference between a gene therapy and other common types of pharmaceuticals is that a gene therapy is not a small molecule drug; rather, a specific gene therapy is just genetic material (i.e., a relatively large molecule) coupled with a specific delivery vector to facilitate administration/absorption; this is analogous to a drug like amphotericin B being encased in solid lipid nanoparticles to enhance oral bioavailability – that's an example of a small molecule drug coupled to a specific delivery vector. Moreover, gene therapies are often referred to as drugs because they act like drugs (i.e., they satisfy the strictest definitions of a drug and a pharmaceutical drug, hence why all gene therapies are classified as biopharmaceutical drugs) and go through the USFDA drug approval process. The USFDA also requires that drug prescribing information be published for all gene therapies, e.g., this is the Rx info for the gene therapy that was mentioned above, voretigene neparvovec (trade name: Luxturna): [1].[note 1] As is evident from this drug's prescribing information, a number of existing drugbox fields are applicable to a gene therapy; so, why should we duplicate a large number of existing drugbox parameters in another template AND add a small number of additional required parameters relevant only to gene therapies in that template rather than to just add the small set of parameters to the drugbox in order to enable it to provide the relevant data for gene therapy pharmaceuticals?

FWIW, a gene therapy should not be put into an infobox that cover a "therapy" instead of the drugbox simply because the word therapy is included in the name in "gene therapy". That simply isn't a valid/sound argument. If it were, template:infobox drug should be merged into whatever infobox gene therapies are covered in because all pharmaceutical drugs are a form of pharmacotherapy. Seppi333 (Insert ) 22:32, 30 December 2017 (UTC)

Sounds like the wording "gene therapy" is not correct then. Isn't this confusing (mixing up) therapy and drug? Like "viral therapy" for vaccin. Or "radioactive therapy" for radioactive drug treatment. Anyway, any boilerplate setup still wellcome (new params, data examples, etc.). -DePiep (talk) 22:49, 30 December 2017 (UTC)
What about chemotherapy? Clearly a drug, not a procedure. Natureium (talk) 17:16, 2 January 2018 (UTC)


  1. ^ Quote: "LUXTURNA is an adeno-associated virus vector-based gene therapy indicated for the treatment of patients with confirmed biallelic RPE65 mutation-associated retinal dystrophy. Patients must have viable retinal cells as determined by the treating physician(s)."
    Notice that this prescribing information includes a clinical pharmacology section with pharmacodynamics and pharmacokinetics subsections on pages 10–11, which only pertain to drugs. Compare this to an example FDA-approved medical device product label for the Axium Neurostimulator System.


  1. ^ Ermak, Gennady (2015). Emerging Medical Technologies. World Scientific. ISBN 978-981-4675-81-9. 

New LHS/RHS fields relevant to a gene therapy[edit]

  • LHS: "Gene delivery method"
    • RHS: this should have only two possible outputs: use either the pair "viral" and "non-viral" or the pair "Viral transduction" and "Transfection" as possible outputs for the RHS field.
      Note on RHS: Both of these pairs are equivalent in meaning, so "viral", "viral transduction", "non-viral", and "transfection" would be acceptable inputs for whatever is used for the parameter output (in other words, you could code this so that one of the output pairs is produced for either of the relevant inputs. I.e., if you decide to use the pair "Viral transduction" and "Transfection" as outputs, then you would have the following input–output maps:
      Input: viral → Output: Viral transduction
      Input: viral transduction → Output: Viral transduction
      Input: non-viral → Output: Transfection
      Input: transfection → Output: Transfection
  • LHS: Delivery vector
    Note on LHS: if "viral transduction" or "viral" is specified as the input in the preceding parameter, then this could also be listed/linked as "Viral vector". If you wanted to do something similar for transfection vectors when "transfection" or "non-viral" is specified as the input in the preceding parameter, then you could modify the piped link on "Delivery vector", which is pipe-linked to the Vectors in gene therapy article, to target the section Vectors in gene therapy#Non-viral methods.
    • RHS: User-specified value
      Note on RHS: There are probably too many possible viral transduction and transfection vectors to exhaustively list. Vectors in gene therapy covers only some of these. Moreover, new gene delivery vectors are developed on a fairly regular basis; so, if the output values were restricted to a pre-defined set of possible values, keeping that list of outputs up-to-date would just create an unnecessary workload/task for template editors.
  • LHS: Gene target
    • RHS: User-specified value
      Note on RHS: There are around 20,000 protein-coding human genes, although likely only a very tiny fraction of those have the capacity to cause disease in isolation – the disease-causing genes in that tiny minority are the perfect/ideal candidates for gene therapies.

Seppi333 (Insert ) 23:18, 30 December 2017 (UTC)

Edit: since gene therapies are typically only designed as a treatment for exactly one medical condition, you could also consider adding "Indication" as an LHS field and a user-specified medical condition as an RHS field for that parameter. Seppi333 (Insert ) 23:24, 30 December 2017 (UTC)

Also, all of these parameters are applicable to the "Clinical data" heading. Seppi333 (Insert ) 00:15, 31 December 2017 (UTC)

@Boghog and Jytdog: Do either of you have any comments/thoughts on these parameter or suggestions for other additions? Both of you are are familiar with gene therapy-related concepts, so I figured I'd ping you. Seppi333 (Insert ) 00:33, 31 December 2017 (UTC)
  • holy cow gene therapy products are drugs, just like mAbs are. You have to submit an IND to start testing them in which you have to discuss tox and CMC, and if you want to market you have to submit a BLA. They are extremely well-defined pharmaceuticals.
A lot of popular media called Tisagenlecleucel a gene therapy drug but it really isn't - it is Adoptive cell transfer where you take a person's cells, genetically engineer them (which is gene-therapy-like), then give them back. Each person gets their own "batch", manufactured just for them. These kinds of therapies (and they are therapies as they are individualized) do need to be treated differently.
This is really, really different from Voretigene neparvovec where the product (a viral vector) is manufactured and sold, just like a mAb or small molecule. We can use the regular drug-box for these, if we add a few parameters. More on this below. Jytdog (talk) 00:53, 31 December 2017 (UTC)
A viral vector is really just a delivery vehicle for genetic material, which is the component of a gene therapy which acts as a drug following delivery into a cell. As described in the section above, an analogy for a viral vector and the genetic material that it carries is solid lipid nanoparticles (analogous to the viral vector) serving as a delivery vehicle for amphotericin B (analogous to the genetic material carried by the vector). Transfection doesn't involve the use of a viral vector as a delivery vehicle, but it does still involve the delivery of genetic material (i.e., the actual "drug" in a gene therapy); the difference is that it's delivered via a non-viral method. Like you said, adoptive cell transfer is a distinct concept from gene therapy or even a drug; it's analogous to an organ transplant on a cellular level, so we wouldn't include those therapies in a drugbox. Seppi333 (Insert ) 01:50, 31 December 2017 (UTC)
Will make a demo soon. Drug articles using these new dedicated parameters will be categorised.
Two questions: should we make this gene therapy drugs a new |type=, next to compound, mab, vacc, comb? Best is: only when absolutely needed (hard exclusion check is needed of other parameters). If I understand this well, parameter usage needs editors who know about this, so will not use senseless parameters (plus this being wiki, an next editor will improve such situations).
Second question: sure this is under "Clinical data"? We should take care to not group everything under this. Does clinical use need to know say vector mechanism and target gene ID at all? In my lay mind, a top-header like "Gene therapy data" looks more applicable. -DePiep (talk) 11:05, 31 December 2017 (UTC)
@DePiep: Yes, I think it's probably worth including a new |type= for gene therapies since they're an entirely different class of pharmaceutical relative to a compound/mab/vaccine/combo; given that we're also creating a specialized set of parameters for this class of therapeutics, it's appropriate to create a new |type= for that reason as well. W.r.t. the question about clinical data, we could create a new section heading for this data if you'd prefer. I only stated that it should go under clinical data because that was the most relevant existing drugbox heading for that data. IMO, there's no reason that we shouldn't create a new heading for that data if you think that would be a better approach. Seppi333 (Insert ) 23:04, 31 December 2017 (UTC)
The FDA definition of gene therapy is somewhat broader that what has been outline above (see What is Gene Therapy?) and includes bacterial vectors. Gene therapy products are defined by the FDA as biologics (i.e., biopharmaceuticals), hence they could reasonably be included in the drugbox. It is unclear why it is necessary to distinguish inputs from outputs. The inputs clearly differ, but unless I am missing something, the output would be identical (an edited gene). I assume that LHS means "left hand side" (parameter name) and RHS means "right hand side" (parameter value). Correct? The standard pharmacokinetic parameters for bare DNA can be measured. However it is not clear that pharmacokinetics for viral or bacterial vectors is even relevant as both have the potential to replicate after administration! (although I guess replication deficient vectors are preferred). Boghog (talk) 13:53, 31 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── OK, after reading the template documentation, I now understand what input/output refers to. To make things more explicit, the following are suggested parameters for Voretigene neparvovec:

| type              = gene_therapy
| gene_therapy_type = viral_vector
| viral_vector      = adenovirus serotype 2
| delivery_method   = 
| gene              = [[RPE65]]

gene_therapy_type defines one of the following types of gene delivery/editing systems:

gene_therapy_type output comment
Viral vector Viral vector
Bacterial vector Bacterial vector
naked DNA Naked DNA
DNA plasmid DNA plasmid
zinc finger nucleases Zinc finger nucleases example: SB-913
siRNA siRNA not strictly gene therapy, but closely related

delivery_method defines one of the following types of gene delivery systems:

delivery_method output
Lipofection Lipofection

These are my initial thoughts. Boghog (talk) 21:45, 31 December 2017 (UTC)

@Boghog: Thanks for your response! Most of my knowledge of gene therapy pertains to viral vector-based gene therapies; since you're more knowledgeable of this subject area as a whole than I am, I appreciate your feedback. I have a question about your revised set of parameters: is "delivery_method" only relevant to transfection-based therapies? Seppi333 (Insert ) 23:19, 31 December 2017 (UTC)
@DePiep: I would suggest using Boghog's proposed parameter set in the drugbox/demo instead of mine. Seppi333 (Insert ) 23:19, 31 December 2017 (UTC)
Hi Seppi. I am not really that familiar with this area either, but have done some quick reading. In answer to your question, I think "delivery_method" applies only to non-viral transfections. Viral vectors have a built-in delivery method (viral capsid fusion, endocytosis, or penetration into cell membrane). Also it is important to point out that "delivery_method" should not be confused with "routes_of_administration". By definition, all therapies, regardless of type, have "routes_of_administration". I thought a bit more about this, and for completeness, I think it will be necessary to also specify two additional parameters, "nucleic_acid_type" and "editing_method". Below is an outline of the proposed parameters (based in part on Gene Therapy Clinical Trials Database). Boghog (talk) 11:57, 1 January 2018 (UTC)

Proposed drugbox parameters for gene therapy (revised, Jan 1st)

Boghog (talk) 11:57, 1 January 2018 (UTC)

Existing drugbox fields for a small molecule drug that are relevant/irrelevant to a gene therapy[edit]

Based upon the existing fields in amphetamine's drugbox and this Rx info:

  • Clinical data: this entire section is applicable to gene therapies with exception for the dependence/addiction liability parameter. However, hard-coding an exclusion for that parameter probably isn't necessary since most people won't fill that in anyway.
  • Legal status: this entire section is applicable to gene therapies.
  • Pharmacokinetic data: "Bioavailability", "Protein binding", "Metabolism", "Metabolites", and "Biological half-life" aren't really relevant to gene therapies. "Onset of action", "Duration of action", and "Excretion" are applicable though. I don't think any new pharmacokinetic parameters are absolutely necessary for gene therapies, although you could consider adding "Biodistribution" (analogous to drug distribution) which would state the tissues that the gene therapy has been found to affect in clinical populations; the biodistribution of a gene therapy vector corresponds to how well-targeted a gene therapy is; e.g., see the entry for "Cell type specificity" listed under Viral vector#Key properties of a viral vector.
  • Identifiers: I'm not 100% positive that all of these identifiers are irrelevant to gene therapies, although I'm certain that most of these identifier parameters aren't applicable since gene therapies wouldn't be classified in most of the chemical databases. KEGG, IUPHAR, and DrugBank might be the exceptions.
  • Chemical and physical data: not relevant at all Edit: Only relevant for some gene therapies.

Seppi333 (Insert ) 00:08, 31 December 2017 (UTC)

I disagree about PK, bioavailability, metabolism, metabolites, etc. Please see the label for the Luxtura (true) gene therapy product. yes additional fields for the vector type (AAV, Ad, lenti, etc), components, including payload (which could code for a gene being replaced, or something to knock down a gene, or something to edit a gene), promoters, etc) would be great. Jytdog (talk) 00:53, 31 December 2017 (UTC)
The body doesn't really "metabolize" a viral vector (that would be analogous to the body metabolizing a virus into something else – instead, the body either just attacks and kills or ignores viruses; viral vectors are normally engineered so that they are largely or entirely ignored by the immune system, otherwise they trigger an immune response) or the delivered genetic material like a typical small molecule drug in the sense that the body doesn't produce metabolites from either. The genetic material delivered by a viral vector or via a transfection method is processed within the cell and translated into a viable protein, but that's a little different than what's normally meant to be indicated in those drugbox fields. The content that you could put into that metabolism field about the translated protein is also sort of redundant with input for the new "Gene target" parameter proposed above; this is because we normally cover genes and gene products (e.g., proteins) in the same article. Seppi333 (Insert ) 01:21, 31 December 2017 (UTC)
W.r.t. bioavailability, the term "efficiency" is typically used to describe how well a cell uptakes and utilizes/translates the delivered genetic material. I'm not sure whether a therapy's efficiency is more relevant to the pharmacodynamics or the pharmacokinetics of the gene therapy though; that term describes a phenomenon that involves both an action by the therapy on the body (pharmacodynamics) and an action by the body on the therapy (pharmacokinetics). Neither the word "bioavailability" nor "efficiency" are included in that prescribing information though, so that's probably not something that's going to be easy to find+list in a drugbox. Seppi333 (Insert ) 01:41, 31 December 2017 (UTC)
See also my "Two questions" I just wrote above (11.05). For this here: is there any check or action required by the template code wrt parameters? As far as I can follow this, this is expert editor's knowledge and so will be applied when editing the drugbox. Documentation will have an extra section. -DePiep (talk) 11:13, 31 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I agree with DePiep that decisions on which parameters to use should probably be made a case-by-case basis and rely on expert editor's knowledge . For example Pharmacokinetic data may appropriate to include for naked DNA/plasmids, but less likely to be appropriate for viral vectors. Similarily, Chemical and physical data would not be relevant for a viral vector, but may be appropriate for a naked DNA/plasmids. There are biopolymer drugs such as insulin (medication) with specific molecular weights which are listed in drugboxes. This should also be possible for naked DNA/plasmids. Boghog (talk) 20:03, 31 December 2017 (UTC)

@Boghog:: The drugbox currently has 8 parameters that can be displayed under the pharmacokinetics heading: |bioavailability=, |protein_bound=, |metabolism=, |metabolites=, |onset=, |elimination_half-life=, |duration_of_action=, and |excretion=. I stated above that the pharmacokinetic parameters |onset=, |duration_of_action=, and |excretion= are relevant to all gene therapies (for fairly obvious reasons: all therapies have an onset/duration of action and a pharmacotherapeutic agent either is excreted or it isn't – the means of excretion or lack thereof should be specified either way), but I figured the following 5 were not: |bioavailability=, |protein_bound=, |metabolism=, |metabolites=, and |elimination_half-life=. Which of those 5 parameters are relevant or likely relevant to non-viral methods? I suppose there's no harm in leaving all of the pharmacokinetic parameters as allowed inputs when |type=gene therapy is specified if it's not clear which ones are relevant at the moment. Also, you made a good point about including chemical and physical data. Seppi333 (Insert ) 23:51, 31 December 2017 (UTC)
Hi Seppi333. As you suggest, some of the pharmacokinetics parameters are probably more relevant than others to gene therapy. Again, this may vary by type of therapy, hence I think it would be OK for the time being not to add any restrictions and leave it to expert editors to decide on a case-by-case basis. We might want to revisit this in future as we run into more examples. Boghog (talk) 17:25, 1 January 2018 (UTC)
@DePiep:: W.r.t. a parameter check, I don't think that will be necessary given Boghog's reply about non-viral therapies. The only section of the drugbox that I thought shouldn't be displayed for gene therapies was chemical/physical properties; but, per Boghog's reply, that clearly is relevant for certain non-viral therapies. Given that the majority of the parameters in the current drugbox for a small molecule are relevant for at least one sub-class of gene therapy, hard-coding an exclusion for certain parameters or parameter sets when |type=gene therapy is specified doesn't seem prudent at the moment. The only parameter that I know for certain is unequivocally irrelevant to all gene therapies is |addiction_liability=. Seppi333 (Insert ) 23:51, 31 December 2017 (UTC)
Very useful all of this. Will happen, but I need a few more days off, interesting RL issues :-) -DePiep (talk) 13:56, 4 January 2018 (UTC)
@DePiep: Thanks. Face-smile.svg Hope all is well with you off-wiki. Seppi333 (Insert ) 20:49, 4 January 2018 (UTC)

Route of administration[edit]

This parameter should probably be displayed under the heading "Pharmacokinetic data" instead of "Clinical data" since RoA is an aspect of pharmacokinetics. What do others think about moving this field? Seppi333 (Insert ) 16:24, 1 January 2018 (UTC)

It has to do with both: (1) how it is normally administered in the clinic and (2) under which conditions the pharmacokinetic parameters were measured. If there is one predominate route of administration, it is assumed unless otherwise specified that all the pharmacokinetic parameters refer to that route. If there is more than one route of administration, then each of the pharmacokinetic parameter should specify the route of administration under which it was measured (e.g., bioavailability by mouth, rectal, IM, or IP, etc; note that IV bioavailability is by definition 100%). In short, I think it is fine as is, as long as ambiguous cases are disambiguated. Boghog (talk) 16:53, 1 January 2018 (UTC)

licence_US parameter no longer works[edit]

The FDA appears to have changed their drug product search engine, since |licence_US= now just takes you to the search page instead of the results page for the parameter value/input. I'm not really sure how to fix this. Seppi333 (Insert ) 17:10, 12 February 2017 (UTC)

eg warfarin. I can't find the change notice on their site. Anyone? -DePiep (talk) 19:45, 12 February 2017 (UTC)
I figured out several possible solutions, the most feasible of which I completely implemented externally to validate that it would work, but when I looked at implementing it on Wikipedia, I quickly realized that it would be impossible to do because the <form> tag is essentially blacklisted on Wikipedia. The remaining solutions are extremely hackish workarounds that would not be preferable at all. I think we're screwed on this one unless we get into contact with the FDA and ask them to reenable search queries via GET instead of only via POST (good luck with that - the amount of bureaucratic bullshit you'd have to deal with on both sides if you did that formally is a nightmare to even start thinking about). Otherwise, well, I can always build one of those extremely hackish workarounds, but I'd need tools lab access (which I don't have) and the trouble involved to get a tools lab account and set this thing up is not really worth the bother to me, especially after having invested time into a much less hackish working solution. Garzfoth (talk) 06:32, 14 February 2017 (UTC)
Thanks for the effort, good to know this. Look like it is useless to autolink now (maybe the searchpage link in the lefthand label only). I note that |DailyMedID= is available. -DePiep (talk) 12:26, 14 February 2017 (UTC)
I wrote up and sent a detailed email to the FDA describing the entire issue (and a UX issue with their new-form search results), as well as what steps should be taken to fix it. I operated directly (using my own private email address) as opposed to involving the WMF as I am hoping to avoid a significant amount of the potential bureaucratic bullshit by doing this, but due to operating directly, I don't have anywhere near the same clout as the WMF does and thus I have no idea if the FDA will actually listen to me. Ah well. Hopefully something comes of this.
I have changed my mind and am now willing to write a redirection proxy to temporarily solve the issue if the FDA does not reply within a few days to a week and if I can get tools lab access for it. This is a hackish but relatively effective solution for the problem. If the FDA can fix the issue, I don't want to invest the time to build this only to have it rendered worthless by the FDA's fix, so that's why I'm delaying.
I reviewed the drugbox template and changed a couple of things related to the clinical data section, most notably identifying and fixing an error with the DailyMed URL (it was also broken but unlike Drugs@FDA they still allow GET requests for their search page, so it was a simple enough fix, if slightly inelegant). I also changed the previous way of having only the DailyMed link appear if the DailyMed and FDA params were both defined to have both links display when both are defined - it's much more sensible this way, especially so as these are entirely different databases.
I would like to add Health Canada's drug product database to the page, but I would need to edit the main template to add an additional parameter for licence_CA, and I do not have the ability to edit template-protected pages so I cannot do that. I still ended up adding (and fully testing!) licence_CA anyways, it works great, so I need to find someone with template editor permissions who can copy the entire contents of Template:Infobox_drug/sandbox to Template:Infobox_drug. @DePiep:, you're a template editor, are you willing to do this for me? I can (and will) update Template:Infobox_drug/doc to reflect all changes/additions made after I can get my licence_CA changes into Template:Infobox_drug since Template:Infobox_drug/doc isn't protected. Thanks! Garzfoth (talk) 17:33, 14 February 2017 (UTC)
@DePiep: Thank you! I did notice that for the changelog year you put "2007" instead of "2017", so you might want to fix that ;). I don't know if you want to use the sandbox page again but I'm done using it for now, so feel free to revert to your prior revision on there if you want to (I was going to do it but realized that I don't know if you were still using it and also it would be out of sync with the main page again so I wasn't sure what to do). I'll revise the documentation next... Garzfoth (talk) 18:02, 14 February 2017 (UTC)
 Done, saw the edits. Q: Canada does not write licenSe right? Otherwise we could add |license_CA= as for US. (Minor: please note that each edit in the subtemplate /licence went live right away and caused 7400 pages into the Jobqueue for refreshing - each time. If you want ease of working, using /sandboxes can help. And of course if I were actually working in the main sandbox you would not have interrupted that would you ;-) I will do the revert, and keep your edits). -DePiep (talk) 18:07, 14 February 2017 (UTC)
You should probably add the param to avoid confusion. The Canada linking ended up being screwed up due to issues with their site - I have written an email explaining what's wrong and sent it to some people at Health Canada, I'm hoping they can fix the issue because otherwise we're going to have to remove the licence_CA param entirely (it works perfectly as long as you visit [2] before loading the search page, but otherwise does not - there is a cookie issue with their source code). For now please leave the licence_CA param in the template, given that the FDA link is also broken and unlike the other links it isn't used yet this shouldn't pose an issue short-term and it'll make it easier for us if Health Canada patches their website. I'm very sorry about the jobqueue, I got distracted with how many pages I had to modify, wasn't sure which pages were triggering live edits, and forgot to do the work in the sandbox in the process - I'll try to remember to use it much more in the future now that I have a better understanding of which pages are and aren't live. Thank you for your help and advice! Garzfoth (talk) 00:25, 15 February 2017 (UTC)
  • I had to revert CA, see #licence_CA below.
  • I have prepared the #2 sandbox for this licence developments:
Template:Infobox drug/sandbox2
Template:Infobox drug/licence/sandbox
Template:Infobox drug/testcases2
This way, we will not interfere. We must communicate when something goes live.
  • Later on I will add the |licenSe_CA, _EU= options carefully. Not now.

-DePiep (talk) 07:19, 15 February 2017 (UTC)

I've unarchived this thread since it's still a current issue. Seppi333 (Insert ) 20:30, 4 January 2018 (UTC)


  • I have reverted (partially) the new external HC link by |licence_CA= [3]. As Garzfoth noted above, it does not work yet: it leads to a frozen page, which is unacceptable. The infobox now shows the Canadian HC ID word unlinked (FWIW; only added yesterday so not much traffic anyway).
The difference with the kept licence_US (@FDA) link is, that the US link leads to a usable searchpage.
For now, we need to get the Canadian link working correctly before re-introducing. I strongy suggest to use the {{Infobox drug/sandbox2}} setup for develop & testing (so as not to interfere with ongoing changes in /sandbox #1). -DePiep (talk) 07:13, 15 February 2017 (UTC)
I'm fine with that. I had no clue about the issue until after completing all of my primary testing/addition/documentation work, so it was just really really bad timing for their stupid delayed issue to show up all around. Will use the other sandbox when needed. Thanks. Sorry about any trouble this has caused. Garzfoth (talk) 11:55, 15 February 2017 (UTC)
You mean they changed it that recently? Anyway, no need to say sorry, things happen. And I did not click that testlink either ;-). Just think: editing in the sandbox gives a relaxing pace to it. btw, would it be an improvement to move the DailyMed to below? -DePiep (talk) 12:00, 15 February 2017 (UTC)
Health Canada didn't change anything recently (that would be the FDA), the issue is that there is a flaw with the Health Canada Drug Product Database site's code that is completely unnoticeable because of the series of actions taken by me (which were not abnormal in any way either for what I was trying to accomplish!). The exact issue is an extremely unusual type of issue that you normally would never encounter with virtually any website's search service in this context and so I had no reason to do the kind of extended testing that would have discovered the issue immediately (normally you would not do any form of extended testing for this kind of work because it would be a complete waste of time to do so). I've received an initial reply from Health Canada, but they seem to have completely misunderstood what I was trying to do so I had to explain everything again in a hopefully easier to understand way and now I'm waiting for a response to that. No response from the FDA yet. I think dailymed belongs in the licensing section so I don't think moving it outside of there is a good idea unless you have a good argument to the contrary that you want to make (assuming that moving it outside the section is what you meant), but if you actually meant moving it around within the licensing section then please explain in more specific detail what you mean. Garzfoth (talk) 06:23, 16 February 2017 (UTC)
I drop my DailyMed question. (It was about the within-licences-ordering, but I don't know why any more.) -DePiep (talk) 07:14, 16 February 2017 (UTC)
Status updates on the two emails related to both CA/US drug product database issues:
  • Health Canada: The developer is now being brought directly into the discussion, but they are currently on vacation until next week so I have to wait for them to return to the office.
  • FDA: I was informed that they've forwarded my email to unspecified experts within the agency "for input and assistance", who may respond directly or indirectly to me, with no defined time frame for response (but with a warning that response time frames can be variable).
Both agencies seem more-or-less amenable to making the necessary changes so far, but I suspect bureaucratic barriers may be encountered, and the process is already as slow as I expected it would be. Still, there's some progress. Garzfoth (talk) 10:42, 22 February 2017 (UTC)

Swap {{keypress}} with {{button}}[edit]

Replace {{keypress|Preview}} and {{keypress|Save}} with {{button|{{int:showchanges}}}} and {{button|{{int:publishchanges}}}}. There's no "Save" key on my keyboard and Legal wants to standardize on Publish changes. — Dispenser 04:09, 8 March 2018 (UTC)

 Done, with other message adjustments [4]. -DePiep (talk) 08:59, 8 March 2018 (UTC)