This is an archive of past discussions about Template:Infobox drug. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I propose to add subheader Legal status for the legal data (one data block). Today, it is under 'Clinical data' which is not quite correct. Comments? -DePiep (talk) 00:24, 29 February 2016 (UTC)
(sandbox version as of 00:24, 29 February 2016 (UTC))
For a lot of drugs, legal status is relevant to clinical data. E.g., Rx-only pharmaceuticals have been approved for a particular medical indication. I don't really have an opinion about this proposal though. Seppi333 (Insert 2¢) 02:05, 29 February 2016 (UTC)
Sounds OK at first, but the divisions are not just "is clinically relevant/is not clinically relevant"? Would take only those two subsections in Drugbox. -DePiep (talk) 00:32, 4 March 2016 (UTC)
Another splitter: Clinical is about drug product, legality is about drug substance. (I find this quite decisive). -DePiep (talk) 00:35, 4 March 2016 (UTC)
Seppi333, Aethyta. Done, a bit premature. This proposal was in the sandbox, and went accidentally live with other changes (see CAS RN linking etc). I do think it could stay this way, because I was about to conclude here:
While Seppi333 is right that is it related to Clinical data, I don't think it is clinical data by itself. Tis is supported by the notion that legal status is about the drug substance, not the drug product. -DePiep (talk) 11:13, 10 March 2016 (UTC)
Now that I see the effect: maybe move to below section "Pharmacokinetics"? The kinetics section should be nearer Clinical data. -DePiep (talk) 08:51, 11 March 2016 (UTC)
INN tracking category
@DePiep: Hey, would you be willing to create a tracking category for pages that use the INN parameter? I think it'd be useful to have a continuously updated list of drug articles which have a page title that differs from the drug's INN (provided that it has one). Seppi333 (Insert 2¢) 09:06, 2 April 2016 (UTC)
I think that the investigational name should have a field in the Infobox.
Many drug articles have the investigational name in the introduction. I can't imagine anyone using the investigational name unless they were doing a bibliographic search into the history of the drug. It clutters up the introduction and would be better placed in the Infobox.
Is that some preliminary name? Does it relate to the drug product or the drug substance? [1]? Do you have any example articles at hand? Thanks. User:DePiep -16:14, 10 March 2016 (UTC)
Yes, but we should split synonyms in a. tradename synonyms (drug product) and b. trivial names (chemical substance). I don't know where this name should go. Also, looks temporal (discarded when drug is approved?). Anyway, what would it link to, where is that name defined (the FDA IND link does not mention it IIAC)? -DePiep (talk) 19:08, 10 March 2016 (UTC)
The one that made me post this was Imatinib. Drug companies investigate hundreds of substances for every drug approved, and when they start the investigation they number them in sequence. Imatinib started out as STI-571, which means that STI is an abbreviation for the original developer or project (I don't know exactly who that was, maybe something to do with Sandoz, but you can look it up), and it was the 571st substance that they were working on. Naming a drug is an involved process, which requires FDA approval, so they don't give it a name until they have some promising studies. In the original studies, before they name it, they refer to the investigational name, like STI-571, and the papers using STI-571 are searchable on PubMed forever. They also mention it in the patents. I don't know what the authoritative source is for the investigational name, but these Wikipedia pages must have gotten it from somewhere, probably the early articles. There seems to be a consensus for including it in Wikipedia entries; the question I'm raising is, would it be better in the Infobox? --Nbauman (talk) 19:38, 10 March 2016 (UTC)
IMO, no. Drugs are supposed to have their alternative names listed either in the first sentence of the lead or in a note attached to the drug name at the beginning of the lead (e.g., as in amphetamine and psilocybin). There's generally no good reason to repeat these in the infobox. Seppi333 (Insert 2¢) 21:41, 10 March 2016 (UTC)
Seppi333, what about moving it from lede into the infobox, in the synonyms parameter? The STI-571 example seems fit for this. Nicely prevents listings in the lede. -DePiep (talk) 21:54, 10 March 2016 (UTC)
Not sure that this is needed since interested readers can view the many (many) synonyms of drugs can be readily found by clicking on the already present "Identifiers" links within the Infobox, e.g. PubChem or IUPHAR/BPS. (PubMed also has useful MeSH terms, like this http://www.ncbi.nlm.nih.gov/mesh/?term=imatinib). i.e. there seems little point adding extra content into the infobox since the info is mostly there already - it just needs a little digging. (Interestingly, some drugs may still be recognised or referred to by their investigational name, such as RU486 from Roussel-Uclaf but, as mentioned by DePiep, these names are discarded when the product gets closer to commercialisation). Mangofast (talk) 11:40, 11 March 2016 (UTC)
Just to clarify, I agree that the investigational name does not need inclusion in the article body (unless of course it is still an investigational agent, or the name is somehow important in the context of that particular article). I don't think it needs a specific entry in the infobox. Mangofast (talk) 11:52, 11 March 2016 (UTC)
The "go to PubChem" route is not the answer. It is not about: "what are the synonyms?". It is about: "I see name STI-571 mentioned in my literature, what does WP say about it?" (and so should lead to the article). So in general, if such a name is still seriously in use somewhere, it better be added to |synonyms= without further ado (no separate data row though). BTW, what is the link for a definition of the 'investigational name' (onwiki, offwiki)? -DePiep (talk) 15:10, 11 March 2016 (UTC)
What about its many other names that are also mentioned in the literature such as CGP 57148, CGP57148B, etc that are also synonyms. By extension of logic shouldn’t these also be added to synonyms= ? If you do this for one investigational name you should probably do it for others too. However, pragmatically, if there is strong feeling, it could be done like this on the basis that only the most recent investigational drug name - just prior to its commercialisation - is used. (This would help avoid cluttering ‘synonyms’ with multiple other, even more obscure investigational names). As I say, for certain older drugs especially, including the one you mentioned, LSD, I have no particular opinion whether it’s in or out of the article body since it may be subtly important in the context of that particular article. However, for drugs developed over recent decades, inclusion of investigational names are probably best left out of the article body. Not aware of any good definitions for investigational drug names. This is from a commercial site: https://www.bmsstudyconnect.com/s/US/English/USeninvestigational_drugs And this following article has some very general info about “in house” naming conventions: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3086110/Mangofast (talk) 23:12, 11 March 2016 (UTC)
Answer: yes. Every relevant name can be listed in |synonyms=. This serves everyone and everything. Please explain why this is not OK in this name situation.
I don't see any reasoning (not even here, now) for this 'investigational name' to have its own data row in the infobox. We still don't have a label-link, i.e. what should the lefthand text link to? It's a redlink: Investigational name. -DePiep (talk) 23:32, 11 March 2016 (UTC)
Sure - every relevant name can be listed and this is fine but it essentially re-creates existing sites/links where the same information is already detailed and maintained. It also clutters the infobox needlessly. Don't think 'investigational name' needs to have its own data row in the infobox - these are adequately described in the links under 'identifiers'. Mangofast (talk) 00:12, 12 March 2016 (UTC).
Misunderstanding? Adding plain |synonyms=..., LSD-25, ... does not link anything. What cluttering? It just adds a serious name to the infobox -- OK with me. Aren't you mistaking *external links* for wikipedia facts? -DePiep (talk) 00:33, 12 March 2016 (UTC)
I don't disagree here. Most people will not enter all synonyms here eg at |synonyms=..., LSD-25, ... - only the common ones or the ones they think are relevant will likely be entered. Just be aware that the number of synonyms for other drugs can be very large [spanning investigational names, trade names, chemical names, etc] - hence potential for cluttering - especially when synonyms are already represented in authoratative links contained within the Infobox. Mangofast (talk) 01:41, 12 March 2016 (UTC)
Many, or most, drug articles have investigational names. Maybe they don't belong in the article at all, but if they do, I think it would be better for them to be "cluttering up" the infobox than to be cluttering up the introduction. --Nbauman (talk) 15:35, 12 March 2016 (UTC)
Mostly, investigational names won't need to be in the article. Agree that they can go into infobox as this seems the favoured option in this discussion. (This is not my preference for reasons previously mentioned). If it does go into the inbox, I have no strong opinion about where it goes - whether as part of synonyms, or as a new field. The benefit of using a new field would be that people that want to know the investigational name(s) can quickly find it (as it would now be designated), otherwise they may need to wade through a heap of synonyms which may or may not include the investigational name. Conversely, many older drugs will not have an investigational name so the field entry, if templated as such, would in many cases be blanked "not applicable", or similar. [Not sure exactly how template might work but this could be fine]. Mangofast (talk) 00:12, 13 March 2016 (UTC)
The infobox uses parameters |StdInChI= and |StdInChIKey= for InChI data. These parameters are also tracked by the verification bot.
Probably from history, some 4000 articles also have parameters added |InChI=, |InChIKey=. But these are not used at all (not shown). I am preparing to mass-remove parameters InChI, InChIKey, controlled. The first batch will remove: those that are blank or that repeat the already present StdInChI, StdInChIKey values. (That is, the same InChI-wise so e.g. the prefixes 1/ - 1S/ may differ for the same substance). In this batch, no information will be lost.
Y 333 articles left with non-easy situations for InChI, InChIKey. WIll remove them anyway with a check.
I must refine: removing a non-standard InChI actually does remove infomation, because that 1/... form InChI is not present any more on the page (for a search to be found). Considerations on why this is not that bad: 1. it is not visible and not maintained today, 2. Could be unseen anyway by a search bot b/c not visible, 3. non-standard InChI's are not supported in {{Drugbox}} in general, and not by wikidata. -DePiep (talk) 07:50, 5 April 2016 (UTC)
To make this topic complete: I'd rather have kept universal parameter name |InChI= instead of our construction |StdInChI=, but today the verifying bot only knows the Std one and this cannot be changed simply overall. -DePiep (talk) 18:11, 7 April 2016 (UTC)
I would just like to compliment and thank whoever shepherded the "_comment" parameters into creation and use. For 99% of WP readers, it is much more useful in the infobox to read "Pregnancy category: US: C (Risk not ruled out) (no adequate human studies)"—which clearly and briefly explains exactly what C means and the reason why—than it is to read just "Pregnancy category: US: C", which would leave the user to go hunt elsewhere for what C meant (and most likely to make assumptions about why). Someone was really using their brain. Nice to see. Quercus solaris (talk) 01:03, 7 April 2016 (UTC)
I did edit in this area, so I do enjoy the compliment :-) :-). While you are at it: your US example has the predefined clarification after "C": "US: C (Risk not ruled out)". Do you have suggestions for those of AU(stralia)? -DePiep (talk) 17:53, 7 April 2016 (UTC)
In {{Chembox}}, we show a Jmol link (to an interactive 3D model). By default, it is created from the existant SMILES input data. Should we show that here too? (Looks like this is of chemical interest only, not clinically).
Crude demo for MDMA:
I think including this link is useful. After all, drugs are chemicals. I also think showing a static 3D image of an arbitrarily selected orientation and conformation is of limited value and is arguably misleading. Finally many of the 3D images shown in both chem and drug boxes IMHO are ugly. This may be controversial, but I would be in favor of replacing the static 3D images in the drugbox an the external link. The advantage would be to decrease the size the infobox which would be especially useful in the mobile view. Boghog (talk) 10:55, 9 April 2016 (UTC)
Support for adding the link is noted. Further: it is external, so it can not replace the image. The argument of size reduction is too much ad hoc. It even has a notch of contradiction, b/c you say that an image is highly relevant, while at the same time proposing to remove one. -DePiep (talk) 11:16, 9 April 2016 (UTC)
I wrote that the external link is useful while the static 3D image is debatable. There is no contradiction. Complaints about the large size of the drug infoboxes have been brought up multiple times by various editors and removing the 3D image would significantly decrease the size of the infobox. There is general agreement that the 2D images should be shown but much less agreement about the usefulness 3D images. So this is hardly an ad hoc argument. Replacing the static 3D image with an interactive image is a win-win solution. It decreases the size of the infobox for those who do not care about chemical structures and it provides a more useful view for those that do. The best possible solution IMHO would be to display an interactive JMol image directly in the infobox in a default collapsed state, but this is not technically possible at the moment. Boghog (talk) 15:06, 9 April 2016 (UTC)
This is not a proposal to remove images from the infobox. Sure incorporating Jmol could be nice, but not at hand. Then, removing anything can be argued with the boxsize-argument, but that does not have any convincing weight. -DePiep (talk) 15:16, 9 April 2016 (UTC)
I agree that removing the 3D picture may be controversial and probably should be handled on a case by case basis. However I think the argument in favor of removing 3D images cary a lot of weight. A static 3D depiction (1) has limited usefulness (a single static orientation may obscure parts of the structure), (2) may be misleading (an arbitrarily selected conformation which may not be the biologically active conformation), (3) questionable aesthetics, and (4) takes a lot of space. Much better to link to a more useful external dynamic representation than devote valuable screen space to one that is suboptimal. Boghog (talk) 16:28, 9 April 2016 (UTC)
I am dead serious. What specifically is deficient about the four arguments that I listed? I admit, argument #3 is subjective, but the rest are not. The strongest argument is probably #4. These 3D images take a lot of space and space does matter, especially in the mobile view. Boghog (talk) 21:50, 9 April 2016 (UTC)
Both issues deal with 3D images and the external link might be considered redundant if a 3D image already exists in the infobox. The second issue may also affect where the external link is placed. Hence the two issues are closely related. Boghog (talk) 22:25, 9 April 2016 (UTC)
Could be fine, but is a bit generic. Then, what data can we expect? so far, looks like a prose is needed because no standard terms or quantifications are used. Does this prose belong in the infobox? -DePiep (talk) 07:43, 5 April 2016 (UTC)
We can add this, but I'd like to hear some more supporting 'Yeahs!' here. We don't want to end up with a parameter used in only one article. -DePiep (talk) 18:05, 7 April 2016 (UTC)
Given that tolerance and sensitization are both necessary processes for the development of dependence and addiction, I don't see the point in a tolerance parameter. It's basically reflected in the dependence/addiction liability. If the point of the parameter is to indicate the development of tolerance to the therapeutic effect of the drug, then I don't think it'd be particularly useful to have in the infobox since this could vary by medical indication. Seppi333 (Insert 2¢) 19:11, 7 April 2016 (UTC)
PLease reply to the points made in this talk. If you change your proposal, add new description, wikilink, expected data, and examples. -DePiep (talk) 13:18, 11 April 2016 (UTC)
usable term
add parameter usable period — Preceding unsigned comment added by M-G (talk • contribs) 12:16 am, 11 April 2016 (UTC+2)
Would it be possible to add the drug's class (category) to this template? For example, antidepressant, antihypertensive, beta blocker. As a pharmacy student, I think it would be very helpful to be able to look in the same spot on each drug's article and quickly find its class. Lmp883 (talk) 23:54, 11 April 2016 (UTC)
Q: Can we use ATC code for that (e.g., mention the top ATC level(s) in wording)?
From drug class: "A drug class is a set of medications that have similar chemical structures, the same mechanism of action, a related mode of action, and/or are used to treat the same disease. In several dominant drug classification systems, these four types of classifications form a hierarchy."
Q: So there are multiple classification systems - must we choose one? Q: Also, what level of the hierarchy would you expect in this paramater (1, 2, 3, or 4 levels deep)? -DePiep (talk) 02:02, 12 April 2016 (UTC)
Expect multiple-input per class (one drug can be in multiple classes, even within one classification-system).
Input options should be narrowed down, can't have any-input-goes. Maybe options: |FDA_class= must be from [2], and |PubMed_class= must be from [3]. This way, reducing mentioning of unsourced classes.
btw, we have ~2000~200 combination drugs that have a class added (in this category). How are these classes sourced (ie, from which classification system)? -DePiep (talk) 07:44, 12 April 2016 (UTC)
I think the ATC code is probably good enough... it'd be really ugly to have a drug class parameter for drugs with like 6+ different ATC codes. Seppi333 (Insert 2¢) 16:34, 12 April 2016 (UTC)
I don't think this is what the original poster meant. ATC codes are useful, but are entirely pointless for the average reader. I think what the poster wanted is some sort of simplification, not more pointless numbers that belong on Wikidata and not in article-space. CFCF 💌📧18:00, 17 April 2016 (UTC)
Most people are probably most interested in what the drug is used for. This would correspond roughly to the ATC level two (therapeutic main group) identifier. We already have the code that is buried in the identifiers section. What would be useful is to display what the code stands for (e.g., N02B – analgesic) near the top of the clinical data section. We already have |type= that apparently is only used for biopharmaceuticals. Adding |therapeutic class= or something similar might be appropriate. Boghog (talk) 18:45, 17 April 2016 (UTC)
Sure adding human readable classnames would be an improvement. What I do not want is making it freetext, inviting to write "helps against .." (snake oil) sales talks. So I'd like to limit the input to recognized classnames (examples and classification systems still welcome here).
And yes the template can nicely add some ATC level verbose. btw, Boghog, your example is level three right (4 characters), not level two (3 chars)? N02B (WHO) would give "other analgesics and antipyretics". And I'm thinking of a new sectionheader "Classification" for this (incl ATC code). Clinical data section is easily overloaded. -DePiep (talk) 19:00, 17 April 2016 (UTC)
Roughly corresponds to ATC level two. A subgroup (level three) may be more appropriate, but for others, may be too detailed (e.g., C03A (WHO) low-ceiling diuretics). Also keep in mind, that many drugs have more than one use. Hence some flexibility is needed. Boghog (talk) 19:28, 17 April 2016 (UTC)
Sure a feetext input must be possible for |class= (like legal_status has).
I plan to make a demo this week: expand existing ATC input into verbose class. More later.
Now you all help creating that other list of reasonable classnames (out of ATC world) ;-) . So entering (new parameter) |class=antidepressant will see Antidepressant. -DePiep (talk) 19:52, 17 April 2016 (UTC)
I'm not sure if this has been discussed before, but: What are people's thoughts on adding "street names" (alternatively, "slang terms," "nicknames," "other names," "common slang terms") to the template? I could the see the potential for unsourced additions, but, if properly sourced, I think street names could be a helpful addition to the infobox template, especially considering that, in many cases, these names are more frequently used than the clinical, pharmaceutical, or INN names. Furthermore, it would only really apply to those drugs that are used recreationally enough to have developed street names, so it wouldn't even be an intrusive addition in most cases. Madreterra (talk) 19:47, 29 April 2016 (UTC)
Pregnancy category -> pregnancy
I do not find that the clarification of pregnancy to pregnancy category is required and that it is implied by common sense in the same way that WP:The sky is blue… I have shortened it in this infobox, together with a number of other parameters that seem equally non-contentious. The infobox is ridiculously long and we need to shorten it — for starters this can be done by removing excess text that serves no purpose. What do you think Doc James? Carl Fredik 💌📧10:22, 25 May 2016 (UTC)
I had reverted it, so you can not claim that it is "non-contentious". I already noted (in the es [4]) that we should not reduce texts into jargon code-words: the label should clarify to The Reader (not just the expert) what the data is about (a point you do not address here). The opinion that the box is "ridiculously long" is not usable as an argument, let alone that it leads to removal of relevant text (reducing size should be talked at a general level, not as an ad hoc argument to remove incidental text). Let me nullify that argument by stating the text is "ridiculously short". Anyway, since this change is not discussed we should go back to the pre-status.
This revert by you have not even discussed. As I said in my es: the class is not "S9 Prohibited", "(prohibited)" is a clarification, again to prevent coded wording. Reduce overall size by corrupting the wording is not the route. btw, in mobile view the <small> tags do not work (fontsize is not reduced). Not discussed, no consensus, no change. -DePiep (talk) 11:05, 25 May 2016 (UTC)
RoA and pregnancy category should be written out in full since I don't think the average person from a non-medical field would associate the contraction with the full label. I also don't think that people will click the left-handed links if they're piped to an article on a topic they're already familiar with, like piping pregnancy category to pregnancy; MOS:PIPE also says not to do this unless the context is clear, which it isn't here.
The "CAS Number → CASRN" seems ok since the latter is a shorter synonym, but there should be a space between CAS and RN (i.e., "CAS RN") if the contraction is used - [5]. Seppi333 (Insert 2¢) 23:20, 25 May 2016 (UTC)
Even with the (obvious) space, CAS_RN is code not legiuble. "CAS Number" says it. And for the legal codes: I maintain that "S9 Prohibited" is not correct, as described. btw, I'd expect CFCF would revert and continue talk here, instead of imposing statements & acts. -DePiep (talk) 23:34, 25 May 2016 (UTC)
The point is that CAS Number is used rarely enough that anyone who knows what CAS Number is ought also to know what CASRN should stand for and the format of the number.
As for pregnancy category — I don't think that is more clear for the lay reader. If we wanted to clarify we could use something such as Use in pregnancy.
Lastly for legality, I find that the explanation took too much space, and making it small fixed this. If <small> tags don't work on mobile we could just as well use <div style="font-size:0.5em;">
Done — <span style="font-size:0.8em;"> solved it for mobile as well.
No consensus established for changes. I'll revert to pre-discussion (i.e., the version that is to be discussed). I find this quite astonishingly behaviour by CFCF. Actually not based on discussion or consensus. (More like sole thinking: 'I think this is a good idea, so I'll edit it into this'. Three times by now). CFCF, this can be seen as edit warring. ping Seppi333. -DePiep (talk) 18:29, 29 May 2016 (UTC)
Looks like being complementary to the UK drugs law. So we can simply extend |legal_UK= with this option? -DePiep (talk) 17:48, 30 May 2016 (UTC)
How do we know when a substance is covered by this law? It seems like this law is similar to the ones discussed at WT:PHARM#Drug laws. We didn't have a very clear conclusion to that discussion. Sizeofint (talk) 21:42, 30 May 2016 (UTC)
As always, can list a drug under this when there is a RS confirmation. If the law is vague, we cannot improve that. And I agree right away, this law is even more vague than the 1971 drug law (and childishly improfessional. What were the UK lawmakers using themselves at the time? Expect children with a bright red lollypop to be prosecuted). AFAIK since no list is published, must we expect listing-by-trial/jurisprudention only.
Of course jurisdiction area is UK only. The other relevant UK law Misuse of Drugs Act 1971 options are here, options are GSL, P, POM, CD, CD specified. We could add option |legal_UK=psychoactive to show like Pshychoactive Subst Act. As said, the Misuse act and Psychoactive Act are mutually exclusive (a drug van be in one list only), so no new parameter is needed. -DePiep (talk) 08:22, 31 May 2016 (UTC)
Currently, the drugs template does not provide readers with critical information about the range of effective doses, the range of toxic or lethal doses, and the therapeutic or safety index.
I propose that the template add the following fields as mandatory (i.e. they will show up as blank, with a message requesting that they be filled in).
The fields should accept "unknown" or "inapplicable", with appropriate display. (E.g. "LD50: unknown".) Inf should also be accepted, e.g. for the LD50 of LSD in humans, if the drug has been studied / used enough that no known number indicates that there is no such number, rather than just a lack of adequate information.
For psychoactive and/or recreational drugs: rename to "threshold" (minimum), "common" (ED50), and "heavy" (maximum tolerated). See e.g. Erowid MDMA dosage info:
Optional: Certain safety factor, calculated automatically as:
if TD1 and ED5099 present: TD1/ED5099
elsif LD1 and ED5099 present: LD1/ED5099
else manual
For all of the above, there should be a mandatory parameter indicating the animal model from which the measurement is derived, with "human" suppressed by default (to be enabled e.g. if the drug is not intended for human use).
The template should handle the existence of multiple animal models, e.g. if there are separate known LD50 (mouse) and LD50 (human). If multiple models exist, un-suppress "human" label, and put it first.
There should be an optional parameter for ref-name(s) on each number to indicate citation source. (A full inline ref would be cumbersome; it can be added at the bottom of the infobox.)
Finally, there should be an optional parameter for conditional situations — for instance, LD50 or ED50 of drugs taken together with the ED50 of an MAOI, when administered to children, etc, if separate numbers are available. Sai¿?✍11:29, 25 June 2016 (UTC)
We don't normally include therapeutic dosing information per MOS:MED/MOS:PHARM. The LD50 isn't always available either. I'm not opposed to including some of these; however, considering that we don't currently have any fields that are forced to display when the parameter isn't assigned a value, I'm opposed to adding that functionality with these parameters if they're added. Seppi333 (Insert 2¢) 12:13, 25 June 2016 (UTC)
The TD is necessary to be able to show a theraputic index. Of course, TD can list a range (which I proposed). This should be interpreted as toxicity information, not recommended dose for anyone. The reason for making it auto-display is simply to get people to fill it in; it should be suppressible if there isn't available info. Sai¿?✍12:16, 25 June 2016 (UTC)
How can you make something mandatory that often is not available? This makes no sense. Also taking ratios between human therapeutic and animal lethal doses can be quite misleading as there are often large between species variations in these values. Regulatory approval of drugs implies there is an adequate estimated safety margin as long as the recommended dose is administered. Why should we report ratios that may be very misleading at best? For recreational use? This would run afoul of WP:NOTHOWTO and WP:NOMEDICAL. Hence I am skeptical for the need to display these ratios. Boghog (talk) 12:57, 25 June 2016 (UTC)
Human data for these is not available for most drugs, and varies heavily depending on age, body weight, metabolism, tolerance and what not. LD50 in humans is an entirely useless number (half the party is dead now)! Wikipedia is definitely not the right place to provide medical advice, as others mentioned already above. Terrible idea. Aethyta (talk) 00:35, 26 June 2016 (UTC)
No. We do not require fields (mandatory infobox input) this way. Also, 'critical infomation' should be specified. (To be honest, I can not imgine any thing to be critical by Wp). -DePiep (talk))
re these required fields "will show up as blank, with a message requesting that they be filled in": this is not a good practice. We should not show in the content space (the readers article) an editorial help. If a missing value is that much important, we can add an [error tag] or, more relaxed, a hidden tracking category like Category:Infobox drug articles without a structure image. -DePiep (talk) 08:54, 26 June 2016 (UTC)
Deuterium in the chemical formula
appears to be slightly buggy, the short form | C=20 | H=21 | D=4 | N=1 | O=4 results in an unknown parameter name error (it refuses to take the D) and won't calculate the molar mass either, however the old | chemical_formula = C20H21D4NO4 works (although mass isn't calculated here either). Not exactly common (I think there're only articles for Beta-D, 4-D and 6β-Naltrexol-d4), but nonetheless it's a small bug that shouldn't be hard to fix. Aethyta (talk) 00:19, 26 June 2016 (UTC)
No objections here, especially as there was discussion before implementation. I also agree that "D" is preferable to "2H" since it is more common to use the former than the later in chemical formulas. As far as I know, there are no deuterated drugs currently on the market, but several are in clinical trials [for example deutetrabenazine (SD-809) and AVP-786, CTP-786 (formerly deuterated dextromethorphan)]. Boghog (talk) 06:01, 1 July 2016 (UTC)
Thank you both for the compliments. You know, I'd never dare concluding anything any more without explicit comment. As you have said: silence is not approval, and even an edit is not approval, so I'll start asking 100.000 editors before each edit. Arguments need not apply. -DePiep (talk) 17:40, 3 July 2016 (UTC)
I'm not sure what the motivation for doing this is, but I don't think this is an improvement for most drug articles on small molecules. This formatting looks awkward/ugly in the drugbox. Seppi333 (Insert 2¢) 14:46, 2 July 2016 (UTC)
Its already done for SMILES and other formats - the formatting looks the same as it used to. It ends up being unusable on large molecules, and if that is the price to pay, ugly>unusable. Carl Fredrik 💌📧15:09, 2 July 2016 (UTC)
C'mon, CF. Let's do better. There might be crisp improvements in there, but it is not inviting having to go through all editsummaries & changes to understand what happened. -DePiep (talk) 17:33, 3 July 2016 (UTC)
But the only edit I reinserted was moving the IUPAC down to the bottom of the page and making it collapsible. I didn't apply the others.Carl Fredrik 💌📧21:24, 4 July 2016 (UTC)
I have refined {{drugs.com}} to show the external link symbol (as other data rows here do), and other edits. See Template talk:drugs.com.
In {{Infobox drug}} I have removed the "ASHP" text, because its article (nor the drugs.com site) seems to make any relationship. (Maybe the articles need improvement in this?).
Yes, technically the name of the website is different from the url. Just like Erowid is the name of the website at www.erowid.org. Sizeofint (talk) 22:24, 7 June 2016 (UTC)
Boghog re-inserted the label to be "AHFS/Drugs.com". [7]. The es clearly referred to my motivation above (to remove AHFS), but no talk was started. Anyway, nor articles AHFS, Drugs.com nor the site [www.drugs.com] define AHFS as defining for the institute Drugs.com. Actually, they don't even mention the AHFS-Drugs.com connection. Or is it in the small print on the website? Anyway, it is not defining or clarifying, so we can leave it out of the label here without any harm. -DePiep (talk) 19:35, 15 June 2016 (UTC)
@DePiep: The proper way to do this is to first ask if there are any objections to removing a link that has been in the drug box for a very long time. Above you announced that you were going to remove this link and less than two hours latter you went ahead and removed the link had removed the link after the fact without allowing time for others to respond. Your attitude needs to change. The reason why this link to ASHP was included in the first place is because of the drug.com monographs. The drugs.com monograph links are the preferred links, and hence it was and still is appropriate to include the ASHP wikilink. Boghog (talk) 19:58, 15 June 2016 (UTC)
Yes, that's called Bold, while still opening and elaborating a talk. Four editors got involved in this very label text, and clearly none objected to that removal. We can read acceptance in there, and the intention to talk. I don't see a problem in there, nor improperness.
Back to the argument: AHFS is not the defining institute, so is not needed in the infobox label to clarify for the reader. Quite a lot of database-links we provide this way do not specify the maintaining institute (and forget about if it is just one of the data suppliers). -DePiep (talk) 20:15, 15 June 2016 (UTC)
@DePiep: The majority of the links are to content that originated with the ASHP (see statistics above) and all of the highest quality links are to ASHP supplied content. The slash in "ASHP/Drugs.com" means "and/or". Hence the link to ASHP is defining and should be restored. Boghog (talk) 20:48, 15 June 2016 (UTC)
This talk flow shows that I did engage in constructive discussion (I loyally edited to change after a discussion my initial proposal -- what is your problem?). Anyway, Boghog you still have to make your first content argument. And don't forget: if I had proposed it only here, and waited a full week -- you'd be late too. Why don't you just come over with arguments that you would have had entered a week ago? -DePiep (talk) 21:31, 15 June 2016 (UTC)
Sure, I did, but lots of distractions happen. To your 19:58 post I responded at 20.15. And already at 19.35 I laid out the basic reasoning. -DePiep (talk) 21:55, 15 June 2016 (UTC)
Restatement of arguments in favor of restoring the ASHP link
The reason why this link to ASHP was included in the first place is because of the drug.com monographs. The drugs.com monograph links are the preferred links, and hence it was and still is appropriate to include the ASHP wikilink.
Some statistics: The {{drugs.com}} template is transcluded into 1,503 article out of which 933 contain the monograph parameter.
The majority of the links are to content that originated with the ASHP (see statistics above) and all of the highest quality links are to ASHP supplied content. The slash in " ASHP/Drugs.com" means "and/or". Hence the link to ASHP is defining and should be restored.
The topic is a label in an infobox. That should be as crisp as possible for the reader to recognize the data issue. However tempting, is is not a good idea trying to explain or describe the item in the label.
Now I think that "Drugs.com" is easily enough for the purpose here. While ASHP may be associated with it, is does not help any clarification to add that info. Even it were fully in control of Drugs.comn, there is no need to add that info. Even stronger situations where we keep the info more to the point: the site is named "IUPHAR/BPS Guide to Pharmacology", but we label it "IUPHAR/BPS". Fine. The CAS Registry Number a subsidiary of the American Chemical Society, but we simply label it "CAS Number". No misunderstandings, no overkill of info.
Even if all of Drugs.com links we provide were to the Monograph, adding ASHP is not needed.
The reason why this site was added in the first place is that it derived a lot of its data from ASHP which gave the data legitimacy. In addition:
does not help any clarification to add that info – WP:V
there is no need to add that info – if the ASHP wikilink is not added, then the drugs.com external link should be deleted entirely
no misunderstandings – others have already commented that this site appears spammy and have suggested its removal, removing the explanatory wiki link removes the justification for including the external link
The ASHP link is defining and therefore should be restored. You also removed this link without prior discussion. Finally no one else above has commented on the ASHP link. Silence is not consensus. I have since broken the silence with an objection. My objection demonstrates there is not as yet consensus for this change. Boghog (talk) 19:31, 16 June 2016 (UTC)
To put it another way, the reason this external link was added was not that the material came from drugs.com, rather is came from ASHP (see history). The original suggestion to add the ASHP link was from none other than User:Doc James. The external link would not have been added without the association with the ASHP. There was and still is strong justification for retaining the ASHP link. To remove the ASHP wikilink while leaving the drugs.com wikilink is bizarre. For that reason, the ASHP link should be restored. Boghog (talk) 14:11, 17 June 2016 (UTC)
The content we are typically linking to is created by the AHSF. Drugs.com is just hosting it. When AHSF info is not available we than link to other stuff. I think keeping AHSF is a good idea. Doc James (talk · contribs · email) 18:41, 17 June 2016 (UTC)
Re Boghog: "none other than Doc James" -- is this authority as an argument? After consultation with my wikilawyer, I claim that that inclusion did not have consensus.
Since you Boghog keep spinning, there is no use in arguing. You keep complaining about the process and misconstruing obvious consensus (here and on my talkpage). The fact is: in this post and by actual edit to the template, there was consensus between all involved editors: DePiep, Christian75, Seppi333 and Doc James (who now mysteriously claims he did not agree with his own statement-by-edit btw). None of them even mentioned the removal (not even your authority Doc James). I state that is consensus. Then eight days later you com along to enforce your opinion (but not by talking btw). Simple reasoning says: after seven days I could have concluded consensus and edit the template anyway. You should have gone to the talkpage and talkpage only to reopen the discussion. Instead, you started wikilawyering to enforce your point. -DePiep (talk) 05:20, 18 June 2016 (UTC)
Doc James All fine, you are free to change mind 10 days later. But don't imply there was no consensus. You were part of it. Proper route would be: reopen a talk here. Not you, not Boghog (8 days) did. -DePiep (talk) 01:36, 21 June 2016 (UTC)
Re DePiep: Next time, please ask if there is consensus before making a potentially controversial change to this template. You first removed the link, and then didn't ask, but announced that you had removed the link. This is backwards. Also you are confusing silence with consensus. You didn't ask if there was consensus and no one specifically commented on the removal of the AHSF link until Doc James' comment above. Boghog (talk) 06:02, 18 June 2016 (UTC)
Boghog You keep flip-flopping. When I add an argument, you change into some procedureal detail, and when I kill that, you start about something else. Simple: there was consensus, then eight days later (8) you come along to make late trouble. You have spoiled any serious discussion about this thing. (and btw, labeling each and every drugs.com el ASHP is dead wrong).
If you want to add quality: please prove 'consensus' for that earlier Doc edit you mentioned. Until now, there wars none. -DePiep (talk) 01:46, 21 June 2016 (UTC)
DePiep – I repeat. There was no consensus for the removal of this link. The original consensus to add this link was established in 2011. This link has continuously remained in the template for the last five years. A few weeks ago, you unilaterally removed the link without asking if there was consensus to do so. This is not a minor procedural disagreement. This is a serious abuse of your template editing privileges. You then didn't ask if this change was OK, you only stated that you made the change. You then mistakenly assume because no one initially objected to your announcement, there was consensus for your change. The way consensus is established is to first ask a question and then allow others time to respond yes or no. You never asked the question. You only tried to justify you bold edit after the fact. Furthermore you should not be making bold edits to protected templates. Consensus is required before making these types of edits.
Returning to the issue at hand, you argued that the link was not defining. I have supplied counter arguments why it is defining. You then state labeling each and every drugs.com el ASHP is dead wrong. The slash in "ASHP/Drugs.com" means "and/or" so how can this be "dead wrong"? Boghog (talk) 06:02, 21 June 2016 (UTC)
What use in discussing this with you, when you choose to re-construct this into a "there was no consensus" as you like? What if consensus would be re-establised shortly, that you won't again take another wikilawyering approach to enforce your opinion? You have made some weird statements. -DePiep (talk) 08:19, 24 June 2016 (UTC)
Insisting that consensus should be obtained before making a potentially controversial change to a protected template is not wikilawyering, it is policy. Furthermore, no one else has explicitly supported your removal of the link, hence it is not weird, but quite logical to conclude that there was no consensus for your edit. Two editors have now objected to the removal. Even if consensus previously existed for removal, it certainly doesn't exist now. It is time to WP:DROPTHESTICK. Boghog (talk) 08:50, 24 June 2016 (UTC)
You only keep hammering on it because it serves your own preference. In any other case you would not resort to wikilawyering. It is simple: you were 8 days late, and you wiklawyer on an immaterial point. Then arguing "Silence is not consensus" and "none other than Doc James" shows how desparate you are for some reasoning - any reasoning. Methinks you are not in a position to advise on stickdropping. -DePiep (talk) 21:39, 4 July 2016 (UTC)
Its not "wikilawyering". Its consensus. When the community voted for the template editor right, it was a big concern that it would be misused. Therefore, you have to ask before making any non-trivial edits, because ordinary users can't revert it. Christian75 (talk) 23:41, 4 July 2016 (UTC)
mab source can be veterinarian?
For mab drugs, we can use |source= to add the mab_type like e, i, o, u, zu. (see documentation). Now
Tyranitar Man recently added option source=vet option to show source = Veterinary medicine[9]. However, to me this looks like a mistake ("source" is not meaning "where does it come from"; and vet is not listed in the list). Can people comfirm/deny that |source=vet is correctly added for mab? -DePiep (talk) 15:55, 3 July 2016 (UTC)
Fab is not a |source=, it's a |mab_type=. However, I don't know what Tyranitar Man intended, and "veterinary" doesn't fit the function of the |source= parameter, which is for describing the species from which the peptide sequence comes. --ἀνυπόδητος (talk) 18:39, 3 July 2016 (UTC)
Now see what those weirdos come up with 10 days later on. They'll claim there was "no concussion" or whatever. -DePiep (talk) 00:06, 7 July 2016 (UTC)
Developmental name
I couldn't find anyplace in the template to put a developmental name. Many of the WP entries start out by giving the developmental name in the narrative summary (e.g. "(trade name Yervoy, formerly known as MDX-010[1] and MDX-101)". This seems like a waste of a prime location in the article. The introduction is supposed to help readers understand the rest of the entry, but the developmental name doesn't help. The few people who will actually need to know the developmental name can find it as easily if it's in the infobox. Is there some way to include the developmental name in the infobox? If not, do people agree that it would be a good addition to the infobox? --Nbauman (talk) 15:41, 30 July 2016 (UTC)
Like |tradename= or |synonyms= ? Retroactively changing that for thousands of articles and enforcing it in future ones is very unrealistic though. Also not worth the effort. Besides, many drugs don't have a INN, which means that their trade/brand/development names are the only available options. For example, Rapastinel was titled GLYX-13 for many years - the development name is certainly worth keeping here. If the names in your example above however are not really used in the references, you could always remove them on a case-by-case basis (remember to create redirects!) or discuss it on the articles talk page first. But there's no blanket solution that applies to all articles. Aethyta (talk) 18:47, 30 July 2016 (UTC)
IMHO, the developmental name is a synonym and hence belongs in the lead sentence, particularly for newer drugs where an INN has not yet been assigned. In addition, |synonyms= but not |tradename= would be an appropriate parameter to also store the developmental name. Boghog (talk) 19:03, 30 July 2016 (UTC)
What value or use does the developmental name have after the generic (and brand) name have been assigned? When would anybody ever look it up and use it? --Nbauman (talk) 19:13, 30 July 2016 (UTC)
It probably doesn't always need to be in the lede. Whether or not it should be there should be handled on a case by case basis like we do with other synonyms. Sizeofint (talk) 22:41, 31 July 2016 (UTC)
Sure it is a |synonyms= not a |tradename=. We can add |developmental name= to the input list, and show it listed together with the synonyms. Once irrelevant, it should be removed from the infobox though. -DePiep (talk) 22:32, 31 July 2016 (UTC)
I'd suggest should just be in the normal synonyms section. Realistically, if you have the Developmental name field it's unlikely that it will be removed (and I can see an argument that the Developmental name never stops being the Developmental name just because other names are given and thus it is never irrelevant). In the end it is just another identifier and I'm not certain that it warrants a special field. --The chemistds (talk) 14:11, 1 August 2016 (UTC)
Germany seems to have a well-defined categorization system for safety during pregnancy (Pregnancy_category#Germany, although it doesn't have a ref). Since we've added the German legal status why not add the pregnancy categorization as well? Sizeofint (talk) 23:27, 16 August 2016 (UTC)
Yes I'd like to see more sourcing and background in there. Then, how to describe the 11 groups? We surely want to add info like:
Parameter for citing entries in the density parameter
How do others feel about creating a parameter like |density_notes=, analogous to |melting_notes= and |boiling_notes=, so that it's possible to cite the density parameter? I imagine it's fairly simple to find and confirm this value for a large number of compounds, but for a minority, I think this would be a useful addition for facilitating WP:V. Seppi333 (Insert 2¢) 04:45, 25 August 2016 (UTC)
As this content is very specific I am wondering about moving it to a separate box that would go in the physical properties section of the medication article. Doc James (talk · contribs · email) 04:49, 25 August 2016 (UTC)
Sounds fine to me. Separating out the physical/chemical properties is a topic that should probably be raised separately. DePiep won't be around for a few months to implement it so someone else would have to make any changes. Sizeofint (talk) 03:48, 30 August 2016 (UTC)
I agree that adding |density_notes= sounds fine. I think what Doc meant was to move all the chemical data to a new infobox and this box would be placed in the chemistry section of the drug article. I think this would create a lot of work for little gain. An alternative would be to collapse the chemical data section of the drugbox. Boghog (talk) 04:33, 2 November 2016 (UTC)
Will add density_notes. Doc suggestion not blocked this way. btw, time to align the various suffixes "_note", "_notes", "_comment", "_cmt" into one (future) standard? -DePiep (talk) 10:57, 2 November 2016 (UTC)
@Anypodetos: Changed in sandbox. Will be deployed shortly. Same issue with type=vaccine. Synonyms are ok with combo and vaccine, as that data is in the "Identifiers" section (not in the chemical substance section). -DePiep (talk) 23:47, 1 November 2016 (UTC)
I would like to suggest adding a link to an interactive 3D model to drugbox. Obviously I don't want to touch this on my own. I believe, though, that it might be a pretty simple operation, and I am hoping that it would automatically implement on pages.
The problem has always been that not all the 3D structures of drugs are at places like PubChem or NCI/CADD. However, RCSB does have ligand models, and the idea is to use the PDB_ligand item for this. The way this would work is that an entry such as
All this is doing is adding an additional link, which goes to the same page that chembox goes to currently for those pages. This link is to a page that displays a JSmol model (JavaScript/HTML5 only, not Java) based on a PDB id.
Is this possible?
EDIT: Alternatively, if one doesn't want the full capability of Jmol (VDW surfaces, charges, 3D printer models, etc.) then a simpler change could be made. The current links to EBI and RCSB are to protein searches. How about just changing those to ligand pages such as https://www3.rcsb.org/ligand/60C ? Those pages have very nice NGL models.
Right -- and that is fully operational in ChemBox (and has been for some time) -- my suggestion is that something similar be done for the drug box now. If nothing else, the PDB page needs to go to the correct ligand page. Perhaps that is sufficient. Hansonrstolaf (talk) 22:42, 30 October 2016 (UTC)
The linked proposal is slightly different than what is currently implemented in Chembox. In any case this seems like it could be an improvement. Sizeofint (talk) 03:18, 31 October 2016 (UTC)
Boghog: in the box as an image (not an el) would be great, but beyond my powers. Also, then it should go in the images top section. -DePiep (talk) 07:54, 2 November 2016 (UTC)
Yes, and it would obviate us needing to create structures for every chemical. I have some very long-range plans to mock something up in this direction. Welcome back DePiep, you have been missed! Sizeofint (talk) 14:12, 2 November 2016 (UTC)
Follow up question: if Jmol for the interactive image is too problematic to embed in WP, is there a site that gives a static (fixed) image based on SMILES? -DePiep (talk) 14:41, 4 November 2016 (UTC)
This is input for a single chemical, and does not apply to the combination. Also, each of the individual drugs is mentioned and linked, and so can be reached right away for individual properties. Btw, these input values are not shown in a |type=combo drugbox. -DePiep (talk) 12:04, 21 November 2016 (UTC)
I propose to reorder sections and data. Some demo's are in /testcases and /testcases6.
In general, I want to move chemical/physical data to below, and medical data to top. Exception: the images stay in top.
Systematic IUPAC name: move from top section into section Chemical data. The header name changes into a label (ie, lefthand text).
Because this is chemical data only, and very technical at that. And it's just a name, no need for separate header.
Sections Chemical data and Physical data merge into one header 'Chemical and physical data'. Reduction of headers, split not that useful. Physical data appears right above the long SMILES InChI data (these are still at the box bottom). The Jmol image link, being general, moves near the top of this section.
ATC code moves from section 'Identifiers' to the section 'Clinical data'. Sure ATC is not an identifier (it's a class), and it is clinical, not chemical. A more natural position I'd say.
Didn't notice this until now. Isn't the chemical/physical data already located at the bottom and medical data already located at the top? Moving the ATC code and merging chemical+physical data sounds fine to me. I think the IUPAC name should remain where it is though, since it uniquely identifies the compound. Seppi333 (Insert 2¢) 23:16, 16 November 2016 (UTC)
Yes, sections chemical and physical data are at the bottom already, in that order. After the merge, I've changed the row order: 1. keep long SMILES and InChI strings in the very bottom. This esp important in mobile view (see #Test1), because then they are not collapsed ever. 2. Put Jmol 3D datarow near section top, because of more general relevance.
re "Keep IUPAC name in top, because uniquely identifies'the compound": yes for the identification part (absolutely correct), but no for the relevance in a drug article. Moving that name downward does not change its identifying purpose, while that move gives more attention to the medical aspects. IOW, it is essential but not important. (If it were really top-priority, shouldn't we change the article name into the IUPAC name or put that name in the article intro?). -DePiep (talk) 07:07, 17 November 2016 (UTC)
The most appropriate name for a drug is the International nonproprietary name (INN) if one has been assigned. This name uniquely defines the drug and hence the IUPAC name is less essential if an INN is available. Also per Template:Infobox_drug#Infobox_title_and_INN, the |drug_name= should be the INN which will displays above the structure. If an INN is available, then it is appropriate to move the IUPAC name to the chemical/physical data section. Boghog (talk) 09:59, 17 November 2016 (UTC)
INN and infobox title (-options) are not affected by this proposal. Change would be: move IUPAC name from below-the-images to way below in section "Chemical and Physical data"; as a datarow, not with its current sectionheader. (My note on articlename change is for the sake of argument only, as an extreme). -DePiep (talk) 10:14, 17 November 2016 (UTC)
I never said that INN that was affected by this proposal. What I said was because we have an INN at the top, the IUPAC name becomes less essential and can be moved down. Boghog (talk) 11:05, 17 November 2016 (UTC)
Sandbox needs improvement: it appears that Chemical & Physical data shows while not a single chemical. While this trackable input (and so can be corrected=removed), there better be a prevention. CVurrently this error shows in the testpage (for the three non-single drug types). Will work on this. -DePiep (talk) 13:03, 17 November 2016 (UTC)
Second thoughts. Maybe the more correct position for the IUPAC name is in section 'Identifiers', not 'Chemical and physical data'. In Identifiers, top row. (Still nicely would be in the lower half of the box, i.e. where the external links+chemical info gathers. Not in top medical info half). Let's first see where the #Synonyms position talk below ends. -DePiep (talk) 09:20, 22 November 2016 (UTC)
Synonyms position
Perhaps move the "Synonyms entry" to the top or close to the top. I expect more reader will be interested in the synonyms than the other identifiers. Sizeofint (talk) 06:07, 22 November 2016 (UTC)
Recapture: the three name sets. Sketch pointing out the three namesets in drugs (some minor details are outdated) I've reread the Archive talk, esp the parts concerning name (eg Christian75 @12:59, Boghog @15:01; I'm getting it). The synonyms question better be solved by the main outline, not just as an simple parameter issue.
A. Drug nomenclature and so {{Drugbox}} has three name sets: 1. INN (+ article title, pronounce); 2. drug product (+ formulation name, trade names, non-proprietary names); 3. active drug substance (+ chemical name, IUPAC name, active ingredient, chemical trivial name).
B. Today in {{Drugbox}}, below title & images, all medical data is gathered in the top half, and all substance data in the bottom half. This major grouping also applies to the names, mostly. So the three namesets are helpfully distinguished visually and systematically (by placement and by section structure); see image. I think this makes a good info presentation. (Minor improvements, that is within a part like title or top half or bottom half, can still be made but do not disrupt this setup).
C. About |synonyms=. The problem is that is covers two name-types together: the parameter can list both product names and substance names (formulation and chemical). I propose to split this parameter in two. Let's create two parameters, one will show under trade names (=drug product synonyms), the other under IUPAC name (=drug substance synonyms).
D. Possible parameter names and labeltext (lefthand text in the infobox):
|nonproprietary synonyms=, label "Synonyms" under trade names? "Also named"?
|trivial names=, label "Trivial name" under IUPAC name. Trivial name is well-understood in chemistry. Clear enough for the drugbox-editors?
|synonyms= Deprecate. Edit articles to confirm into new parameter(s). For now, treat as product or substance name?
Here I'm not sure. Helpful labeltexts? Use plurals? Use easy & correct parameter names? Move IUPAC name into identifiers asap? I note that the IUPAC name is missing in non-single drugs (combinations, vaccines, mab). Still these can have trivial names.
TL;DR; Following the major distinction between drug product names and drug substance names, |synonyms= should be split into two parameters to allow synonyms for each those two name-sets. INN-title name(s) unaffected. New parameter names and labeltexts to be decided. -DePiep (talk) 10:34, 22 November 2016 (UTC)
Ehh, that big IUPAC name into clinical section? Or, trade names out of clinical section? Do you really oppose the separation of substance and product? Seems like a loss of infomation, just indiscriminate lists. -DePiep (talk) 18:08, 22 November 2016 (UTC)
Perhaps keep the human readable names under clinical data and the database identifiers and IUPAC under identifiers. If we're splitting the information this way, perhaps title the "Identifiers" section "Other identifiers". Hopefully at some point we can just refer readers to Wikidata to get the other identifiers.Sizeofint (talk) 23:57, 22 November 2016 (UTC)
I was more responding to Doc James' comment about keeping everything in one place. I think your suggestion about separating products and substances may also make sense. Wherever they end up, the human readable names should be prioritized in placement. Sizeofint (talk) 00:27, 23 November 2016 (UTC)
I object to lumping those all names together. No advantage has been described, except that we, editors, can be more careless giving the information less structured (=we omit answering 'what is this name actually?'). And yes I am pissed off that my analysis has not been digested. I'll resort to spoonfeeding. -DePiep (talk) 07:36, 23 November 2016 (UTC)
Simplified proposal. For now, I propose:
'Systematic name (IUPAC)' (|IUPAC_name=) - move to top of Identifiers section (fix mistake positioning it under 'Chemical data', made last week).
'Synonyms' (|synonyms=) - move to right under 'Systematic name (IUPAC)'
Postponed: adding parameters (may be discussed later; no prejudice now).
Support – as I have previously argued, it makes sense to split the names between the clinical section (tradename of drug product because that is what is used in the clinic), and the identifier section [IUPAC name of the drug substance (also known as the API) because this is how it is identified in chemical databases]. Boghog (talk) 08:55, 23 November 2016 (UTC)
You must be joking. Boghog (talk) 21:08, 25 November 2016 (UTC) An extra entry in your watch list is more important than a coherent post? Your priorities are seriously screwed up. Boghog (talk) 21:11, 25 November 2016 (UTC)
I propose to extract the E number (EU additive classification) from wikidata (wd). For exceptions (when wd does not fit), the local |E_number= can be used (overrwriting wd requires a source |E number ref=).
The articles will be added to tracking categories, eg
{{Chembox}} already has, see the category. No local entry option (no local enwiki parameter).
I plan to add this, since |E number= already is a {{Infobox drug}} parameter (i.e., already available in the infobox). -DePiep (talk) 11:32, 24 November 2016 (UTC)
As we know, for years both {{Drugbox}} and {{Chembox}} are twinned by their data rows (individual data values are treated alike). And for sure, their outer infoboxes are not. All fine so far.
I propose to add usage the central d:Wikidata data to feed the infoboxes. Not just local input any more.
Over at Talk:Chembox I proposed to "add Wikidata *external link* to the Identifiers". See you there. -DePiep (talk)
Not sure about a separate link to Wikidata, but feeding in all the identifiers, chemical data and so on would sure be an improvement. --ἀνυπόδητος (talk) 17:23, 2 December 2016 (UTC)
And, I have removed the background color into purple. It was defined as "navbox-style" (class), but that is not appropriate in this infobox. I understand the color has no meaning, and may be changed. Headers now are with bg color grey. Also added the Wikidata link, if there is one. -DePiep (talk) 08:24, 8 December 2016 (UTC)
ECHA InfoCard is an infocard publi by ECHA (EU Chemicals Authority). What is an Infocard pdf (Warning: with me, a blockingly slow pdf? DePiep). It primarily shows hazards and industrial data.
If the external link id exists in Wikidata, we can add this InfoCard automatically to the infobox. No parameter needed. For example Ketamine would have link 100.027.095.
{{Chembox}} already has this feature, and some 6000 out of 10000 articles are linked, see Category:ECHA InfoCard ID from Wikidata. Drug articles would be added too that category too. For drugs, some 2500/6500 articles would hit. To be clear, there will be no parameter for this, just an automated Wikidata reading (same as E number eg in Vitamin C).
In the Template:Infobox drug template, on line 97, please change http://www.nlm.nih.gov/medlineplus/druginfo/meds/ to https://medlineplus.gov/druginfo/meds/ instead. On line 233, please change http://chemdb.niaid.nih.gov/CompoundDetails.aspx?AIDSNO= to https://chemdb.niaid.nih.gov/CompoundDetails.aspx?AIDSNO= instead, and on line 234, please change http://chemdb.niaid.nih.gov/CompoundDetails.aspx?AIDSNO= to https://chemdb.niaid.nih.gov/CompoundDetails.aspx?AIDSNO= instead. Thanks. --Elegie (talk) 15:22, 9 December 2016 (UTC)
@DePiep: Can you be a little more constructive in your criticism. The all the links that I checked did in fact redirect as specified, and I added the double span because the old span name no longer applied, but I didn't know what might be relying on it. Nested spans are perfectly valid HTML. --Ahecht (TALK PAGE) 23:10, 9 December 2016 (UTC)
Per WP:EDITREQUEST: "describe exactly what changes you propose". Do you really think the OP request here did that? On top of this, you (Ahecht) have added the stacking titles, but that was not in the proposal (and bad anyway). So I had to analyse and simplify, below, the proposal and the edit to understand them. That is why my criticism sounds rude, and right. -DePiep (talk) 23:28, 9 December 2016 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The purpose of this edit is to provide increased privacy and security for users by using HTTPS for the links to DrugBank. The DrugBank site supportsHTTPS. In this template, please change http://www.drugbank.ca/drugs/{{{DrugBank}}} on line 207 to https://www.drugbank.ca/drugs/{{{DrugBank}}} instead and change http://www.drugbank.ca/drugs/{{{DrugBank2}}} on line 208 to https://www.drugbank.ca/drugs/{{{DrugBank2}}} instead. Thanks. --Elegie (talk) 09:33, 12 December 2016 (UTC)
Please use HTTPS links for the PDB_ligand and PDB_ligand2 identifiers
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The purpose of this edit is to provide increased privacy and security for users by using HTTPS URLs for the links to the Protein Data Bank in Europe in the case of the PDB_ligand and PDB_ligand2 identifiers. In the template, please change http://www.ebi.ac.uk/pdbe-srv/PDBeXplore/ligand/?ligand={{{PDB_ligand}}} to https://www.ebi.ac.uk/pdbe/entry/search/index?compound_id:{{{PDB_ligand}}} instead and change http://www.ebi.ac.uk/pdbe-srv/PDBeXplore/ligand/?ligand={{{PDB_ligand2}}} to https://www.ebi.ac.uk/pdbe/entry/search/index?compound_id:{{{PDB_ligand2}}} instead. Thanks. --Elegie (talk) 08:33, 16 December 2016 (UTC)
There are numerous examples of hormone and neurotransmitters that are also drugs. Because of conflicts between WP:MCBMOS and WP:PHARMOS, several articles (as discussed here) have recently been split (see for example testosterone / testosterone (medication), oxytocin / oxytocin (medication), norepinephrine / norepinephrine (drug)). The question is what infobox should be used in the hormone/neurotransmitter specific articles. One suggestion was to use {{Infobox neurohormone}}. However these is quite a bit of overlap between {{Infobox neurohormone}} and {{Infobox drug}}, hence it might be better to merge the unique field from the former into the later. Then depending on whether the infobox is in the drug or neurotransmitter article, we could suppress the display of the pharmacology or clinical section respectively. Below is a side-by-side comparison of the current drugbox (left), the proposed merged infobox (middle), and the current neurotransmitter box (right). Thoughts? Boghog (talk) 16:09, 13 December 2016 (UTC)
Yes, more or less. There might be a few additional fields that I have not thought of yet.
Yes, possibly. This type field then might be used to suppress the display of the clinical or pharmacology sections as appropriate. However it would be simpler just to exclude the fields. Furthermore they may be occasions (for example, for an article that has not been split), where one might want to display both sections.
No problem adding these for illustration, but these sections are less relevant for a hormone/neurotranmitter article. Boghog (talk) 17:15, 13 December 2016 (UTC) I apologize for not being clearer. Legal issue only apply to exogenously supplied drugs, not natural hormones that are biosynthesized within the body. Some (half-life and protein binding) but not all (oral bioavailability) is relevant to the natural hormone. Hence I have removed the legal section from the hormone example above. Boghog (talk) 19:12, 13 December 2016 (UTC)
The point is: compare-same-input. Next: only use input that is relevant. Top: use same-input-over-all three examples. -DePiep (talk) 20:40, 13 December 2016 (UTC)
Why confuse things? For a proof-of-concept mockup, the same input is irrelevant. Focus only what is relevant at this discussion stage (i.e., to compare and contrast how the hormone vs. drug versions of the template will look in their respective articles). Same input is only relevant for testing/debugging. Boghog (talk) 20:50, 13 December 2016 (UTC)
I do support merging {{Infobox neurohormone}} into {{Drugbox}}. C'mon.
Great! I don't have any objections to a |type=hormone setting, but I would like to know what are the implications of irregular input checking and how it would be implemented. I think it is important to allow for some flexibility for special cases. Boghog (talk) 08:22, 14 December 2016 (UTC)
The new data is illegible to me. Only one English word in there. Is this data useful for the general reader, in top of the top infobox? -DePiep (talk) 10:24, 15 December 2016 (UTC)
IMHO, the "source and target tissues" are English terms and reasonably clear. The pharmacology section (what the hormone does to the body and what the body does to the hormone) is arguably of more interest to the general reader than the identifiers and chemical property sections. Boghog (talk) 11:38, 15 December 2016 (UTC)
OK, "central nervous system" I can get. The data list is: posterior pituitary, central nervous system, oxytocin receptor, carbetocin, demoxytocin, lipo-oxytocin-1, merotocin, atosiban, barusiban, epelsiban, retosiban, oxytocin-neurophysin 1, magnolysin, oxytocinase. -DePiep (talk) 14:00, 15 December 2016 (UTC)
Each one of those is linked to a Wikipedia article that provides explanation for what entry means. The "posterior pituitary" is where oxytocin is produced (i.e., source tissue). The "oxytocin receptor" is where oxytocin exerts its effects. "Carbetocin, demoxytocin, ..." are oxytocin receptor agonists, etc., etc. So I do not understand what the problem is. Boghog (talk) 18:37, 15 December 2016 (UTC)
The problem is that you are not following the links. Each of those terms is a proper noun. They include anatomical locations, international nonproprietary names (INNs), and enzymes and each and everyone is linked. How else would describe these terms? Boghog (talk) 21:02, 15 December 2016 (UTC) The INNs, like trade names are proper nouns. If you object to including a list of INNs, then you should also object to including lists of trade names (in this case, Pitocin and Syntocinon). Boghog (talk) 21:14, 15 December 2016 (UTC)
(ec) No, the problem is they are weird WP:JARGON. Try any link. I did follow a link. It says: "Retosiban (GSK-221,149-A) is an oral drug which acts as a selective, sub-nanomolar (Ki = 0.65 nM) oxytocin receptor antagonist with >1400-fold selectivity over the related vasopressin receptors and is being developed by GlaxoSmithKline for the treatment of preterm labour." And this is just its lede. Now don't blame me I cannot simplify this to our Reader. -DePiep (talk) 21:23, 15 December 2016 (UTC)
These lead sentences could and should be simplified, but are still relatively clear. The essential part is "Retosiban is a drug which acts as an oxytocin receptor antagonist". Also I think you are being a bit unfair in focusing on this particular example instead of the template. Boghog (talk) 21:29, 15 December 2016 (UTC)
I really do not understand what the confusion is about. The infobox is very clear. Retosiban, as the infobox states, is surprise, an antagonist! An antagonist of what, and again surprise, of the receptor for oxytocin! Pretty clever. Don't you think? Boghog (talk) 19:23, 16 December 2016 (UTC)
No one said 'confusion'. It is plain problematic. The data, in top of the infobox, is weird WP:JARGON. Then you said: "you are not following the links" -- well I did, and got the (examplary) Retosiban lede. This is not accessible for our target readers. -DePiep (talk) 21:30, 16 December 2016 (UTC)
Focus on the heading antagonist, not the Retosiban entry. This is not weird jargon, it is an example of a drug that can antagonize the effects of oxytocin. The problem is with the Retosiban lead, not with the infobox. The infbox contains a clear description of what these entries mean and hence appropriate for our target audience. Boghog (talk) 05:01, 17 December 2016 (UTC)
To be fair, most of what goes into our infoboxes is jargon. E.g., intravenous administration is jargon for "administered into a vein", buccal administration is jargon for "administered through the mucous membranes in the mouth", rectal administration is jargon for "administered up the butt", the terms "bioavailability" and "protein binding" are jargon terms with numerical entries, and pretty much any input for the drug metabolism and metabolite parameters will contain technical terms/jargon as well.
That said, we can't forego parameters like these for a drug infobox or those parameters for a neurotransmitter infobox simply because the parameter labels or their entries are complicated or specialized topics. That kind of information (i.e., pharmacokinetic data for drugs; biosynthesis, metabolism, and biomolecular target information for biomolecules) should be contained in an infobox for each type of article (i.e., drugs and biomolecules respectively), because it's directly relevant to and allows for a succinct summary of the most important information about the topic. Seppi333 (Insert 2¢) 00:45, 17 December 2016 (UTC)
Infobox width
As the sandbox4 proposal is now (diff), the infobox width is hardcoded to be 300px. This has two issues:
I don't think that should be part of this merge proposal. Width setting is an independent choice (one can decide to merg independently of choice to set a width).
And, I don't think it is wise to hardcode is (in px even). Infoboxes should be left to default values unless there are compelling reasons to deviate. (In this case, 22em in desktop is default per common.css IIRC). Because, when overwritten it might break the layout(-design) in skins, mobile view, and other situations.
I agree with you completely about potential issues with mobile and other situations. The sandbox is for experimentation and that is exactly what I was doing, experimenting. I have not made any specific proposals about changing the width as yet. The experimentation was triggered by this discussion, more specifically a desire to decrease the number of line breaks. One possibility is that width change would only be invoked if "pharmacological" data were present. Boghog (talk) 18:29, 15 December 2016 (UTC)
This doesn't just affect oxytocin. If you set the amphetamine infobox image widths to 250px, the infobox shrinks horizontally but markedly expands vertically by much more than 50px. The image width parameters shouldn't be setting the width of the infobox along with the images. Seppi333 (Insert 2¢) 00:53, 17 December 2016 (UTC)
To describe the change in the size of the amphetamine drugbox as it appears in my browser (based upon the html element data from my browser): with the default image width of 300px, the infobox renders as a "table" with dimensions 311.2px by 1855.88px. When the image width is set to 250px, the infobox renders as a "table" with dimensions of 270.4px by 2071.07px. Seppi333 (Insert 2¢) 01:00, 17 December 2016 (UTC)
There are two |width= parameters. The first is in the transcluded infobox that effects the width of the image. The above discussion is not about that width, rather it is about a width parameter (|bodystyle=width:300px) that is set within the template code itself. I set this second width parameter in an attempt to reduce the number of line breaks in the infobox headings. I now see this is more complicated since the heading width appears to be dynamically adjusted based on the length of the labels and the content. Fixing the label width to a fixed percentage of the width of the window (e.g., |labelstyle=width:33%), might be a better option. Boghog (talk) 05:32, 17 December 2016 (UTC)
I replaced |bodystyle=width:300px with |labelstyle=width:42%, this removed the line break from most but not all headings. For some reason, the label "3D Model (Jmol)" is split over two lines inspite of the fact that there looks to be plenty of room for it to be displayed on one line. Any idea why this happens? Boghog (talk) 05:35, 17 December 2016 (UTC)
Don't know about Jmol, but now is is single-line here so OK in both d-boxes (desktop).
re Seppi333: extra length is OK: box length is the unrestricted direction for an {{infobox}}. Width is the restricted (or set) direction. Best is to leave all this over to the infobox & HTML rendering (on your device). Bad example: setting a width in px (pixels), easily introduces the need for horizontal scroll bars (esp in mobile view). Better: set width in % (as Boghog did wrt label width), or maybe in em (=font related, so scales with the text). Still, any enforced setting overwrites a skin and local preference (css) and infobox-design-setting. Natural layout rendering should be preferred. Let it flow!
I still would like to know which issue Boghog you are trying to solve? Is the image used in the demo here too detailed? You think too often texts are spread over multiple lines?
We could leave the ~40% in there, an no further width setting. If that is not enough, we could add a width within the infobox for the images (i.e., in {{InfoboxImage}}) of 200px or 250px. Then, in exceptional articles, the width can be overwritten by parameter (for example, when the image is so detailed). This should be an exception. (My experience: in {{Chembox}} I introduced this some years ago, and no complaints so far. Default there is 200px, overwriting applied usefuly in general). -DePiep (talk) 10:28, 17 December 2016 (UTC)
I support this. I suggest: |class=, to show right above (or below?) ATC code. Label (lefthand text): Drug class. Let it be free text (input shown unedited). Any editing advice or restrictions beforehand? -DePiep (talk) 13:15, 16 December 2016 (UTC)
MOS:PHARM and MOS:MED currently say only to mention initial trade names in the lead (which is the consensus as far as I'm aware, and I agree), but there does not seem to be a policy for the drugbox's tradename field. Any comments on adding the same rule for this field in the drugbox documentation and/or on the MOS pages? (See [13] for a current example of the kind of IMO undesirable edit.) --ἀνυπόδητος (talk) 10:40, 5 January 2017 (UTC)
That's |tradename= in header Clinical data then. I'd support such a guideline (or described common practice), but I cannot formulate it. this talk is from 2011. -DePiep (talk) 12:36, 5 January 2017 (UTC)
Good thing there are people like you who've got a better long-term memory than me :-) So it's a decision whether to collapse the trade name field, discourage secondary trade names, or leave it as is? What do others think? --ἀνυπόδητος (talk) 12:56, 5 January 2017 (UTC)
There will be more earlier talks about this, but I might have used the wrong searchwords. Keep in mind that these are other names: |drug_name, INN, IUPAC_name, synonyms=, they show elsewhere in the box (because they mean something else). As I said, structurally limiting the list is good. -DePiep (talk) 13:21, 5 January 2017 (UTC)
I propose to add option |PubChem=[Nn]one, similar to |CAS number=[Nn]one. The input will show, unlinked. Pages will be categorised by this. Would be in tandem with {{Chembox}} (proposal).
Background: We want to crosscheck our chemicals with Wikidata. Recently, Wikidata has imported the PubChem source database, and so PubChem CID is a first candidate to check. One of the subdivisions of chemicals is "does not have a PubChem CID, so nothing to check". That is what this option "none" would add, using Category:PubChem CID tracking categories. -DePiep (talk) 13:36, 10 February 2017 (UTC)
Can we improve links in PDB ligands?
I am not familiar with PDB ligands. So I just ask.
Could we improve the label text for PDB ligand? Maybe link the label ligand?
The PDB lists only a limited number of ligands (ACE CD CL EOH EPE K MG MN MPD NA SPD SR ZLD ZN) [14]. Is it useful to autolink these inputs to a wikipage? If an abbr, add expansion? -DePiep (talk) 14:49, 11 February 2017 (UTC)
I propose to make the following changes to the infobox. Most are background changes, and related to formatting, prepare for Wikidata comparision, and second chemical (index=2).
Accept |PubChem=None,none for 'not a PubChem CID assigned' (as distinct from: not entered, unknown). Categorised. See also #earlier announcement. The word '[Nn]one' will show.
Also: |PubChemStructure= (SID) will show when entered (was: hide when PubChem (CID) was entered).
Multiple chemicals (aka: use index#2 like in |CAS_number2=), kept parallel with {{Chembox}} when possible:
Format as {{Unbulleted list}}, not by <br/> any more.
Same behaviour for all.
Distinction between main parameter and index parameter when useful (e.g., catgorisation).
The following categories have been renamed. Current pages in the old name categories are added by {{Chembox}}. {{Chembox}} will follow this renaming later on. Old category pages will be deleted when empty.
Done -DePiep (talk) 11:13, 10 March 2016 (UTC)
Preparing. -DePiep (talk) 12:15, 2 April 2016 (UTC)
.png)
Done -DePiep (talk) 22:53, 25 November 2016 (UTC)
