Template talk:Infobox medical condition (old)/Archive 3

Nomination for merging of Template:Infobox medical condition

Template:Infobox medical condition has been nominated for merging with Template:Authority control. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. Alakzi (talk) 21:51, 25 February 2015 (UTC)

Before nominating for a merge can you explain why? What problem does this solve? What will the final product look like? Changes to the primary template of Wikiproject medicine (which is on nearly 5000 of our most viewed articles) needs significant discussion. Doc James (talk · contribs · email) 01:20, 26 February 2015 (UTC)

It would look exactly like {{Authority control}}. There's been plenty of discussion above (#Perhaps this infobox should not be the primary medical condition infobox, #Adding further parameters and #This infobox is incomprehensible). We can continue the discussion at TfD. Alakzi (talk) 01:24, 26 February 2015 (UTC)

Discussion yes. Consensus for changes no. Taking this discussion off to some poorly watched none medical page is not appropriate. Discussion should be here or at WT:MED. Doc James (talk · contribs · email) 01:25, 26 February 2015 (UTC)

(a) I've not claimed that there's consensus for any particular change. (b) That's not very convincing. I left a note about the proposal right—well, here. I will do so at WT:MED as well. Why stir up a fuss about the venue? Alakzi (talk) 01:41, 26 February 2015 (UTC)

Alakzi, can we not start a new discussion on yet another page? A fragmented discussion is less likely to reach a consensus. I suggest keeping all discussion here for now ... — Martin (MSGJ · talk) 09:14, 26 February 2015 (UTC)

Martin I agree with you that it would be better to have some discussions closed before we start new ones, but I completely disagree that discussing a merge of templates should be done here rather than on templates for discussion. What do you believe templates for discussion is for if not discussing templates? Martijn Hoekstra (talk) 10:17, 26 February 2015 (UTC)

(ec; this also replies to Martijn H) I do not see any advantage in discussing such a merge at TfD. TfD is more confrontational and technical, and less suited for ideas development. (This template only just returned on the TfD discussion to "merge" that was not feasible and not fleshed out in the first place). The topic is so overwhelming in content (say, parameter meanings) for both templates, that I'd like to hear from people in the know first. For example, would the TfD close with a "merge", I predict big issues with adding the first non-person's authorities in there. This imposing a merge (yes I know) on a template is not the way to go. -DePiep (talk) 10:26, 26 February 2015 (UTC)

Technical details of a merge are a perfect fit for talk page discussion, and don't really belong on a wider community discussion at templates for discussion IMO, though they're not unwelcome there. It's exactly the wider content discussion that templates for discussion is for. Martijn Hoekstra (talk) 10:39, 26 February 2015 (UTC)

I add: opening a TfD while this page has a discussion going is forumshopping. -DePiep (talk) 11:57, 26 February 2015 (UTC)

I earnestly prepared a more concrete proposal, which built on the preliminary discussion we've had here. I posted it on the forum where proposals of the sort are discussed. This is unequivocally not "forum shopping". Alakzi (talk) 12:41, 26 February 2015 (UTC)

Didn't say any non-earnestness is involved. I'm saying is is not the best route to discuss the topics involved. Also, it is not because of wikilawyering I mention the forumshopping word, I mention it because it has inherent problems: discussion split over multiple pages and simultaneously. And I note that the discussion here was not finished, nor preliminary. -DePiep (talk) 13:05, 26 February 2015 (UTC)

This is the point Martin makes above, and which Martijn has already addressed. Alakzi (talk) 13:17, 26 February 2015 (UTC)

Yes, one of my points was mentioned above. That is why this sub thread is indented as it is. And no #1, Martijn H did not address forumshopping issue I explicitly mention. And no #2, I was responding to your newer points too. -DePiep (talk) 14:57, 26 February 2015 (UTC)

You recognise that TfD is apparently confrontational, but you're—indeed—fuelling the confrontation by responding in this manner. I put forth a proposal, which you could've critiqued; instead, we're arguing about imaginary fragmentation (the two discussions are not concurrent, and, though they do overlap to some degree, the former is a brainstorm; the latter, an implementation proposal) and "forum shopping" (an original proposal was posted at what seemingly is the appropriate venue; and there was no deceit on my part). Alakzi (talk) 15:25, 26 February 2015 (UTC)

I can offer no more than that I disagree this is forum shopping. Martijn Hoekstra (talk) 16:05, 26 February 2015 (UTC)

I don't see this as "forum-shopping," which often carries an implication of bad-faith stretching of the rules to gain access to a forum that is more likely to render an opinion more favorable to one party or the other. In this case, I don't see either the TfD or the template talk page as more advantageous to the proposal, and I certainly don't see any bad faith on Alakzi's part. So, perhaps we should just focus on the merits of the proposal and where we should have that discussion on the merits. Dirtlawyer1 (talk) 17:53, 26 February 2015 (UTC)

The topic now is split over multiple places. Whatever you may think of that, is does not produce a good discussion. Full stop. Dirtlawyer1, above I already refuted the BF suggestion, and I pointed out that there are true factual and practical issues with a multiple-place discussion. I see no use in your re-opening a BF suggestion. -DePiep (talk) 20:05, 26 February 2015 (UTC)

I've pulled the nom; you can leave me alone now. Alakzi (talk) 20:40, 26 February 2015 (UTC)

• The issue is closed without fringes by now. I suggest this be archived. -DePiep (talk) 19:56, 8 March 2015 (UTC)

Perhaps this infobox should not be the primary medical condition infobox

Hypertension
Automated arm blood pressure meter showing arterial hypertension (shown a systolic blood pressure 158 mmHg, diastolic blood pressure 99 mmHg and heart rate of 80 beats per minute)

The primary infobox for medical conditions has historically been Template:Infobox disease. There was recently a bit of confusion about why this infobox had been applied to medical conditions, like pregnancy, when pregnancy is not a disease. Obviously the answer is that when something works on Wikipedia then it gets reused beyond the purpose for which it was designed. So for the part of the problem where Infobox disease seems to have a use which does not match its name, I proposed a rename, but that is a small thing and I tell this only as background to a bigger issue.

Infobox disease has historically been used to present mostly authority control identifiers. See the hypertension infobox disease that I am sharing here for an example. Some people have questioned that the primary infobox for medical conditions should contain a set of sorting numbers and external links, when elsewhere on Wikipedia it is more expected that the infobox be readable by humans and to exist for the purpose of summarizing the data essential for understanding a thing.

I assert that the current infobox disease is not serving the purpose of a traditional infobox. Because of this, it is not serving Wikipedia readers in the way that they expect to be served. Beyond this, it is my opinion that few readers are interested in the kind of data currently presented here, and that these boxes would be better placed with less prominence in the articles. The most natural place for this kind of information is, in my opinion, the external links section of an article.

If infobox disease were redesigned to meet what I believe are reader expectations, then I think it should be modeled after other Wikipedia infoboxes, like perhaps the well-developed ones of WikiProject Military History, the sports Wikiprojects, or company infoboxes. None of those projects make boxes analogous to medical conditions, but at least none of those are mostly library cataloging numbers and external links.

As a model for new medical condition infoboxes to replace the cataloguing info boxes currently being used, I think Wikipedians should look at what Google has just introduced in their Knowledge Graph. On 10 February 2015 Google announced on their blog that Knowledge Graph would now cover health conditions. Google gets their information from various sources and Wikipedia might do well to consider this service as a competitor for audience. I expect that the way that they are covering medical issues is backed by extensive market research and the opinions of smart people, and my opinion is that they modeled what they are doing off the precedent established by most Wikipedia infoboxes other than the ones currently used for diseases and medical conditions. I think that it would be prudent to consider following Google's lead. In the long term I would like to see the medical condition infobox most prominently featured in the article to be populated with items from Wikidata, so that translation of terms can happen in Wikidata and then all Wikipedia articles in all languages can have the same basic infobox propagated out to give coverage of health conditions in all languages on all Wikipedias. I am not certain what information should be in this box, but probably authority controls are not best.

In the past, others have asked questions about this infobox which I feel are related.

• A lot of people have asked for additional identifiers and authority control systems to be added to this box. [1] [2] [3] In retrospect, I think that many of these requests were refused because of the high value of real estate this box has so long as it is the primary medical condition box and the limited space it has in this location, and if it were elsewhere on the page, then perhaps the listings for authority controls could be added more freely.
• In 2007 Tatterfly asked that this box contain "basic clinical information on the disease infobox, such as symptoms, causes, and treatments. This would help someone who is visiting the page just to obtain that info to get it instantly." Davidruben replied saying that this would be difficult to do.
• deletion discussion about Infobox medical condition, September 2013
• In September 2013, Remember, Beeswaxcandle and RDBrown discussed populating boxes like this with Wikidata. I agree that this should happen when it is possible.
• Bhny said that this infobox is incomprehensible and Pigsonthewing, WhatamIdoing commented. Further discussion about adding human readable information to the box got comment from Doc James, CFCF, Bakerstmd, Johnbod, Mike Peel, and SandyGeorgia.

One proposal for responding to the people who want reform could be as follows:

1. Move the current infobox disease, which is not human readable and contains cataloguing information and external links, out of the top of the Wikipedia article to make it less prominent
2. Somehow consider making a new primary medical condition infobox, which contains information which is human readable. This could be based on other Wikipedia infoboxes and Google's competing medical Knowledge Graph "infobox". It will not be obvious to determine what kind of fields should go into such a box, and likely a mess will be created in designing this. Still, Google thinks it is a good idea, and I think I do also.

Thoughts from others? Blue Rasberry (talk) 16:36, 18 February 2015 (UTC)

I'm not sure your proposal solves the problems. No matter where we place it in the article, the infobox introduces inaccurate information to articles. I'd support a proposal to delete the infobox, though. SandyGeorgia (Talk) 16:59, 18 February 2015 (UTC)

What wrong information does the hypertension infobox disease contain? Doc James (talk · contribs · email) 17:10, 18 February 2015 (UTC)

Sorry, Doc, I was speaking generally, not specifically. And even more generally, almost all infoboxes (not just medical) introduce potentially intolerable errors ... My point was it doesn't matter if we imbed the box or use it at the top, same problem. SandyGeorgia (Talk) 20:31, 18 February 2015 (UTC)

Did you mean "almost all infoboxes introduce errors", or did you mean "it is possible to introduce an error to almost any infobox"? WhatamIdoing (talk) 00:17, 19 February 2015 (UTC)

A few clarifications

The current box contains a) name of condition b) picture and caption c) disease identifiers d) links to other sources

The google box contains a) name of condition b) picture and caption c) definition d) frequency in the US d) links to other sources. When one clicks further details appear

Doc James (talk · contribs · email) 17:09, 18 February 2015 (UTC)

We could split out the disease identifiers and put them in a box in the diagnosis section. However we do not really have anything to replace it with. Doc James (talk · contribs · email) 17:19, 18 February 2015 (UTC)

Doc James I think that everything below "Classification and external resources" should not be on the top of the page. This includes the ICD links to the MeSh links. None of that should be at the top.

I do not entirely like the Google layout, but I like that humans can read it. In the case of hypertension, Google says things like "very common, treatable by a doctor, requires a diagnosis, chronic, no obvious symptoms, can be treated with (lists drugs) and (lists lifestyle changes)". That could be one model for change. SandyGeorgia is correct that infoboxes introduce inaccurate information, and Doc James is right that we do not have anything to replace the current system because we lack the data to populate infoboxes in a new way. If the problem is reducing inaccurate information, then removing the infobox works. If the problem is not meeting audience need, then I would tolerate inaccurate information so long as there is a plan and schedule to improve it. I saw Google's infoboxes and mostly liked them. Blue Rasberry (talk) 17:25, 18 February 2015 (UTC)

Sure Wikipedia contains inaccurate data and not just in the infobox. The request was WHAT inaccurate data does the hypertension disease infobox contain?

I have already found inaccurate info in googles boxes. Their treatment of strep throat is not that good. Doc James (talk · contribs · email) 17:41, 18 February 2015 (UTC)

BTW the medication infobox contains even more identifiers. And the elements infoboxes contain a lot as well. Doc James (talk · contribs · email) 17:44, 18 February 2015 (UTC)

Hypertension

Automated arm blood pressure meter showing arterial hypertension (shown a systolic blood pressure 158 mmHg, diastolic blood pressure 99 mmHg and heart rate of 80 beats per minute)
Speciality	Cardiology
Signs and symptoms	Often no symptoms
Duration	Chronic
Diagnosis method	Blood pressure measurements usually over several visits
Lifestyle treatment	Exercise, dietary changes, quitting smoking, weight lose
Drug treatment	Thiazide diuretics, beta blockers, ACE Inhibitor/ARBs, calcium channel blockers, alpha blockers
Disease frequency	Very common (> 10%)

Nothing is inaccurate about the current infobox disease. It all can be kept. I just think it should be moved to the external links section. Here is a model of something that I would like at the top of the article.

Since the medicine and elements infoboxes are also not human readable, maybe they should be changed also. Blue Rasberry (talk) 18:56, 18 February 2015 (UTC)

Perhaps this infobox could be made to look like {{Authority control}} and placed underneath navboxes, so that the new medical condition infobox would take its place at the top of the article. Alakzi (talk) 19:04, 18 February 2015 (UTC)

Alakzi Yes, that is what I am imagining. Blue Rasberry (talk) 19:34, 18 February 2015 (UTC)

If we decide to go with this design the ordering of sections should at least match that of the articles. However this infobox contains inaccuracies. "doctor consultation" not needed for the diagnosis for example. Have made some corrections. Doc James (talk · contribs · email) 20:12, 18 February 2015 (UTC)

I have no opinion about what should be covered or in what order. I took this content from Google's Knowledge Graph infobox. Whatever inaccuracies this may have contained was the best information that Google could present on the topic. With you so directly challenging Google's health information I wonder on what other points anyone might disagree with Google's service, and I wonder how it could compare with Wikipedia's quality. I think that also shows that making these would not be easy. Blue Rasberry (talk) 20:18, 18 February 2015 (UTC)

Google Knowledge is basically Mayo Clinic info and US centric.

We will also need to define: very rare, rare, uncommon, common, and very common. We have these definitions for side effects from medications [4]. I think the same can be applied to diseases. Doc James (talk · contribs · email) 20:26, 18 February 2015 (UTC)

For the US at least there is a legal definition of "rare": "A rare disease or disorder is defined in the U.S. as one affecting fewer than 200,000 Americans", per the Rare Diseases Act of 2002. Johnbod (talk) 03:20, 19 February 2015 (UTC)

Other questions:

1. should we reference this? IMO yes.
2. should we keep some of the links to simple language content? one of the criticisms we often receive is that our content is too complicated, maybe one UK and one US such as pubmed and patients.co.uk if they are not poor
3. were should we put the identifiers? IMO a box in the diagnosis section is best.
4. how should this be rolled out? If acceptable to the wider community IMO slowly by gradually replacing the current version with this one. Maybe put together 10 or so as examples of what they would look like. The Google ones are not of very high quality

Doc James (talk · contribs · email) 20:55, 18 February 2015 (UTC)

My two cents: first of all, many proposed paramteres, such as Signs and symptoms, Duration, Diagnosis and Disease frequency would essentially repeat what's already contained in the authority identifier entries, as well as what's already in the article's lead summary (thus inflating the infobox, as I assume the identifiers aren't that prone to linkrot/deadlinking). Also, the Drug treatment parameter may tread on medical disclaimer and may be viewed as a pharmacological advertisement. And burying the identifiers under the external links isn't a good idea, IMO. But I support renaming the infobox to Infobox Medical condition or something like that, the current name is quite narrow. Brandmeister^talk 23:56, 18 February 2015 (UTC)

The infobox should repeat information found in the article. You can think of infoboxes as a structured summary of the article or its lead. Alakzi (talk) 00:08, 19 February 2015 (UTC)

Yes so that is the question. Should we have a lead that is a summary of the article and than an infobox that is an ultra short summary of the lead? I am not sure. But yes that is what is being proposed here. Doc James (talk · contribs · email) 00:54, 19 February 2015 (UTC)

Per Wikipedia:Manual_of_Style/Infoboxes#Purpose_of_an_infobox ("wherever possible, present information in short form, and exclude any unnecessary content") I would stay with the current parameters, with possible additions of other authority identifiers. Brandmeister^talk 00:59, 19 February 2015 (UTC)

Did you not read the first sentence? "When considering any aspect of infobox design, keep in mind the purpose of an infobox: to summarize key facts that appear in the article." An authority control listing isn't the purpose of the infobox. Alakzi (talk) 01:11, 19 February 2015 (UTC)

• It's tricky. I don't like having so many classification links, but I don't think they should go to the bottom of the page. Could they go into a show/hide box? Do we really need all of them? They are jumbled up with the patient info links of MedLine Plus and emedicine=Medscape (has it changed its name?). These are both American - personally I think for patient info NHS Choices (Hypertension Intro page) is probably better than either of these. I'd be for a summary that (only) described in very broad terms what the condition is or does, how serious it is, and how common. That's it. The rest (causes, symptoms, treatment) is all way too complicated for a box, and that's the job of the lead. A line for other names, then maybe 2-3 patient info external links, and a show/hide box with the classification links. Something like that. Johnbod (talk) 03:20, 19 February 2015 (UTC)

Show / hide links are discouraged by the accessibility people. They do not function well with screen readers.

Yes eMedicine has changed its name to Medscape. Both bought by WebMD.

How would we classify the severity of a disease?

Yes NHS choices is fine aswell. Doc James (talk · contribs · email) 03:28, 19 February 2015 (UTC)

Also, the Show/hide option is not present in mobile view at all. Mobile users always see the Show. (btw, from a desktop screen one can always check the mobile view via a link on the very last row of a wikipage). -DePiep (talk) 16:02, 23 February 2015 (UTC)

Cool thanks for that User:DePiep. Doc James (talk · contribs · email) 23:12, 6 March 2015 (UTC)

(arbitrary break)

If we are going to do this new formatting of the infobox I propose we do it via wikidata. In other words the parameters we decide on are added there and than auto linked into the box. Doc James (talk · contribs · email) 17:19, 21 February 2015 (UTC)

Support pause pending Wikidata modeling I see no reason to replace the current template until we have something better. It would be a huge amount of work to replace this with something better, and the way forward will eventually be importing parameters from Wikidata. Anyone could do that now, but learning the Wikidata import template functions is still difficult as will be identifying appropriate Wikidata properties to import. If someone had a model template and 3-4 properties to populate it then I think this could be modeled, and not before then. I do not think it would be useful to trial this only with content on English Wikipedia, and would like to wait for a Wikidata solution. I estimate that this this may take up to two years. Blue Rasberry (talk) 19:36, 23 February 2015 (UTC)

In May 2013 we created a module that would import Wikidata into infoboxes (Module:Wikidata) and I was able to demonstrate a simple auto-populating infobox at Template:Infobox video game series/Wikidata in August 2013, so there's already quite a bit of work done. I've just made a first draft demo at Template:Infobox disease/Wikidata. You can see the sort of thing that's already possible by pasting {{Infobox disease/Wikidata}} into any section of any medical article and previewing it (please don't save!). It allows any parameter to be overwritten by a local value. I'd need to write extra Lua calls to deal with the multiple values in ICD-9 and ICD-10 and the way that the current eMedicine parameters don't match the values stored in Wikidata, but taking Hypertension as an example:

{{Infobox disease/Wikidata
|  ICD9           = {{ICD9|401}}
}}

That will display the template with the single value of ICD-9 as it appears in Hypertension at present, rather than the three values that are fetched from Wikidata.

You need to look at what is being stored in Wikidata (e.g. d:Q41861 is hypertension) to see what parameters are available to fetch from Wikidata. These are mainly the ones used in the current infobox - which is no surprise as Wikidata is largely populated by bots scraping the contents of infoboxes.

I'm all in favour of Mike's suggestion of having an infobox that succinctly summarised the key points of a condition, but you won't be able to auto-fetch that data from Wikidata until somebody/somebot puts it there. --RexxS (talk) 21:18, 23 February 2015 (UTC)

re Blue Rasberry. Two years is a long time to keep a bad infobox. And more important, I don't think it is wise to wait for wikidata to produce the infobox content. We don't want to be dependent on a thing that is out of our (enwiki) reach. Sure technically properties can be read (as RexxS notes). But I still have not seen a wikidata-fying process complete. The repeated add-source-improve-edit steps that make wiki pages grow better is not yet happening in wikidata. I have no feeling with its quality control. Instead, we one could add better parameters to this infobox, to be edited old style locally. Then when d: does have detail info, it can take over. (And, inversely, a bot can read enwiki infobox data and put it in wikidata). Some background: last December we edited the 36 Template:Medicine_navs (from abbr & codes into readable text). There was no support from wikidata in sight (as a database; nothing about the d:people ;-) ). Note: I am working with {{drugbox}} and {{chembox}} these days, and I see similar issues. Including the questions with external links & authority, lots of data that better be below, and article maintenance. -DePiep (talk) 21:50, 23 February 2015 (UTC)

I do not object to someone else drafting better infoboxes here on English Wikipedia, but I am not ready to endorse or promote such a project. If someone volunteers to do that then fine, but when I think of that project, I think of a large amount of very boring data entry that will have to be re-done as soon as it is possible to migrate the information into Wikidata.

RexxX's proposal might be viable now. If that model can be used to bring only a few properties here from Wikidata, then that would be the first step to a permanent solution to this problem, and I expect that it would be no more difficult and probably even easier to do the data entry in Wikidata than it would be to do it into English Wikipedia. I am not convinced that it would be easier to start in English Wikipedia then have a migrate migrate entries from here to there.

In my opinion, the biggest barrier for making an infobox either here in English Wikipedia or in Wikidata is finding good sourcing. Ideally, some database already exists which could act as a reference for a given property of many diseases, but otherwise, perhaps these things would need to be referenced individually. If they are referenced individually then that would be a lot of work in any case, but if they can be referenced with a dataset it would be a lot easier to use Wikidata.

I see no way to immediately go forward with Wikidata or English Wikipedia, because I am not so interested in using individual sources. Is that what you were imagining doing? That would take at least hundreds of hours, and I am almost sure that some spreadsheet should exist somewhere which has already compiled this kind of information. Blue Rasberry (talk) 15:49, 24 February 2015 (UTC)

As RexxS described, it is not an 'either here or there' (en: or d:) choice. The setup is: fetch a d: value, or a local (enwiki) parameter value will overwrite that in the article's infobox. Then four times a year a bot comes by and copies all local data to wikidata. (all can be v.v., when we choose to set it up that way: d: could lead). This way: al available data is used, and additions are used right away. There is no need to wait till site d: or en: is 'ready' with data. As for the sourceing (-quality): yes, that is a point. Either way. (Elsewhere I have introduced parameters like: |decription=, |description_ref= that allows a bot to grab the reference bare handed). What would go wrong if we add say five parameters to the box (descriptive ones, as is discussed here)? -DePiep (talk) 17:09, 24 February 2015 (UTC)

No matter what happens, nothing would go wrong with anyone adding 3-5 parameters to an English Wikipedia infobox for about 10 articles as a trial. I predict that if the outcome is minimally workable then it would get community support almost immediately (within 2 weeks?) for a broader trial to the extent that anyone wants to make more infoboxes for more articles. I support the idea of infoboxes of this sort being tested; the uncertainty for me is the extent to which I want to endorse the idea of volunteers investing time in a system which may not be lasting. I very much would like to see someone trial anything, though. Blue Rasberry (talk) 17:26, 24 February 2015 (UTC)

Sounds good. That would be a template "infobox disease/extra" for 10 articles then? I won't initiate it, I'm just trying to get rid of that 'let's wait for wikidata' idea. (And I'm anxious to see how such an enwiki—wikidata co-development would roll). Maybe RexxS likes to give it a try. Candidate parameters? -DePiep (talk) 19:32, 24 February 2015 (UTC)

Sure if someone want to create "infobox disease/extra" and then trial it on 10 articles we can discuss further with a wider audience. I do suggest that we use Wikidata for at least some of it. Doc James (talk · contribs · email) 21:54, 24 February 2015 (UTC)

Issues

I have presented some issues with a few of the possible parameters below. Yes google is doing this but they have a single box for symptoms and one for treatments that one navigates between by clicking separate tabs. Per accessibility we do not do this. Doc James (talk · contribs · email) 07:20, 3 March 2015 (UTC)

Disease frequency

If we go this route what exactly will we put in the box for this? The incidence (number of cases per year), the point prevalence (the percentage of people affected any given point in time), the lifetime prevalence (the percentage of people affected at some time in their life)? Are we going to go with only global numbers? Are will we also going to go with numbers from a specific country? Often only one or none of these exist. Some of the best data in the English world is in the United States but I think it reflect poorly on us as a global encyclopedia to give that data this prominence. Google Knowledge boxes of course just went with US data. They might regionalize eventually based on peoples IPs and they have the ability to do so. This is going to be the first problem with summarizing this sort of information in a couple of words. Next what do we do with conflicting estimates? Wikidata can handle all these particulars. I guess we could organize them there as a hierarchy. Take A first if it exists, if not take B, if neither exist take C, etc. But we would need an army of people willing to do data entry based on high quality sources. Doc James (talk · contribs · email) 07:05, 3 March 2015 (UTC)

I think that we'll need to label whatever numbers we do add. Different articles might take different approaches, depending on what information is available. For hundreds of articles, I think that just saying "it's a rare disease" is going to be sufficient. WhatamIdoing (talk) 00:13, 6 March 2015 (UTC)

Yes agree. We will need a clear definition of what this means though. But doable. Doc James (talk · contribs · email) 04:45, 6 March 2015 (UTC)

Acute versus chronic

Is hep C acute or chronic? While it is both. And it is now mostly curable if you are rich enough. With HIV, there is an acute infectious phase followed by a chronic phase. What about cancers? Some are acute and curable sometimes and other times not. Even strep throat can be followed by chronic problems. Lyme disease of course is famous for this. We have some that are easy like the common cold but that is the minority.Doc James (talk · contribs · email) 07:13, 3 March 2015 (UTC)

I guess we could just label those diseases that are potentially chronic with just that. Doc James (talk · contribs · email) 07:30, 3 March 2015 (UTC)

Signs and symptoms

How will we include the signs and symptoms of SLE or syphilis? What about those of cancer? These are hard enough to cover in a paragraph let alone with a few words. Doc James (talk · contribs · email) 07:13, 3 March 2015 (UTC)

In those cases, it's maybe best to either just use various, possibly with an anchor link to the symptoms section of the article if it exists, or to omit it. I have a mild preference for the former. Martijn Hoekstra (talk) 12:30, 10 March 2015 (UTC)

Contagious

I think this one would be doable. For those condition that are contagious one fills in a parameter for contagious with how it is so. So for HIV/AIDs = Mainly sexual contact. Hep C = Mainly IV drug use

Google however gets Hep C wrong here [5] Hep C is almost never spread by sexual contact Doc James (talk · contribs · email) 07:26, 3 March 2015 (UTC)

Description

Wikidata has a "short description" system that adds information similar to what we put on a disambiguation page. We could suck those descriptions down to our infobox, which would have two benefits: we'd get "information" in the "info"box, rather than just numbers, and we'd find it easier to keep an eye on the Wikidata descriptions. What do you think? WhatamIdoing (talk) 00:13, 6 March 2015 (UTC)

You mean like definitions? What would this look like? Can you put together a mock up. Doc James (talk · contribs · email) 04:44, 6 March 2015 (UTC)

If you copy and paste this {{#invoke:Sandbox/RexxS/Concat|getDescription|FETCH_WIKIDATA}} into a short section of any en-wp article and preview it (please don't save!), it will fetch the Wikidata description in the local language - i.e. English. So for example Tuberculosis gives:

• Infectious disease caused by the bacteria Mycobacterium tuberculosis

Looking forward, I've allowed it to look at descriptions in other languages if they exist, so pasting {{#invoke:Sandbox/RexxS/Concat|getDescription|FETCH_WIKIDATA|de}} into Tuberculosis and previewing gives:

• Bakterielle Infektionskrankheit

which is what I would expect the first version to return if used on the German Wikipedia. Obviously I can't test that directly because the module doesn't exist in German yet. Does that help? --RexxS (talk) 18:23, 6 March 2015 (UTC)

In what part of the infobox are we suggesting to put this? For gout it says "medical condition". Not terribly useful but maybe a start. Doc James (talk · contribs · email) 22:25, 6 March 2015 (UTC)

Gout will now say "Medical condition usually characterized by recurrent attacks of acute inflammatory arthritis", but we can quickly edit the Wikidata entry d:Q133087 to whatever is thought best. --RexxS (talk) 22:57, 6 March 2015 (UTC)

Simplified it some. Doc James (talk · contribs · email) 23:21, 6 March 2015 (UTC)

Template-protected edit request on 17 June 2015

In light of the recent rebranding/domain change of Patient UK, could this template be updated in order to reflect said changes, please? Patient UK has rebranded to Patient, and the domain has changed from http://www.patient.co.uk/ to http://patient.info/

Regards, The Patient.info Web Compliance Team 81.23.53.21 (talk) 16:08, 17 June 2015 (UTC)

The relevant field is d:P1461. There is a note that says that this template uses that property, but I am not sure that it actually does. Also I see no mention anywhere of the name of the organization which manages this identifier. The Patient.info Web Compliance Team, what do you want changed? Blue Rasberry (talk) 16:18, 17 June 2015 (UTC)

I updated the url, both here, and at d:Property:P1461. However, I left the title of "Patient UK". "Patient" alone may be too ambiguous. The Wikipedia article for the site is still at Patient UK. That should be moved first, then maybe the title of this property can be renamed to something that uniquely identifies this resource. --Scott Alter (talk) 02:51, 18 June 2015 (UTC)

Confusion of ICD with ICD-CM

Apologies if this has been addressed elsewhere, I haven't been able to find anything. The current infobox layout Gives ICD 10 (hyper linked to WHO ICD-10) followed horizontally with the article specific entry for the WHO ICD-10. On subsequent the line the term ICD-9 (hyper linked to US ICD-9-CM), followed horizontally with the article specific entry for US ICD-9-CM. This is confusing because ICD-9 refers to the previous WHO-ICD edition, which in some articles is referenced in the body of the article so that the page has tow ICD-9s refreing to seperate categorisations.

The US derogation (ICD-CM) will be updated later this year from ICD-9-CM to ICD-10-CM. Is that change to be facilitated globally across the Infoboxes, or will each article have to be updated manually ? And can the ICD-CM designation be used ? It should be noted that from September the US and WHO numbering will unusually be in synq, so if the current format continues to be used there will be two ICD-10 entries one below the other but hyperlinked to differing locations and followed by differing category numbers. Also in the processof being updated the WHO ICD-11 is IIRC expected to be in place by 2017, so a further update to the infobox will need to be planned for. ICD-11 will have amore dynamic structure than ICD-10 and that may (sorry not to be clear) have implications for how the Infobox works, for example the same number category may appear under multiple disease descriptions.

Practical issue re: ICD/ICD-CM discussed at https://en.wikipedia.org/wiki/Talk:Chronic_fatigue_syndrome#Time_to_split_G93.3_and_780.71_in_to_two_separate_articles_again --In Vitro Infidelium (talk) 15:20, 2 March 2015 (UTC)

Yes ICD11 was supposed to be out in 2015 but I guess they have pushed it back a couple of years.

We typically organize our articles around the usual technical name. There can be a number of classification systems that redirect to a single technical term. So yes ICD 11 will likely be added. Doc James (talk · contribs · email) 19:31, 2 March 2015 (UTC)

The Beta draft for ICD-11 is currently undergoing field trials and is still expected for final release in 2017. However, it will be a couple of years after that before any member country implements it for either mortality or morbidity. This delay will give us time to look at the structure in more detail before implementing it into this infobox.

wrt ICD-10-CM, on the whole it's the same as ICD-10 at the third character level (there are a few differences in the disease sections mainly around the pain categories). Most of the fourth character sub-categories are also the same. The main differences come with the addition of fifth, sixth and seventh characters to the base classification. We certainly won't need to use the seventh characters in this infobox, and I doubt that the sixth characters will be required either (they are for laterality or subtypes of diseases that won't have separate articles). If it's decided that ICD-10-CM is added as a field to the infobox (either as well as or instead of ICD-9-CM), then some automation should be possible, assuming a good and public domain mapping table. Beeswaxcandle (talk) 06:40, 3 March 2015 (UTC)

Thanks, just for clarity will it be the case that the letters CM will appear in the infobox ? For non US readers this twin listing of ICD number is very confusing and having the addition of the CM as signifier would help. --In Vitro Infidelium (talk) 14:00, 3 March 2015 (UTC)

A further question - Not all the changes from ICD-9-CM to ICD-10-CM will be a simple translation, some of the old codes will branch to two new codes - will the Infobox display both new codes or will just one display and what will be the priority choice ? This has implications for WP articles because the multiple numbering will need to be explained, and if only one number appears in the infobox, that would need to be acknowledged in the article body. --In Vitro Infidelium (talk) 10:19, 7 March 2015 (UTC)

We've already got this situation with the "pure" ICD-10 codes. Multiple codes for a disease concept has been treated in two different ways: a) a range of categories (e.g. Diabetes Mellitus); b) the categories listed out (e.g. Pneumonia). A style decision should probably be made for the contiguous ranges as to which way is preferable. At present there is little to no explanation of the ICD classification system in the disease articles, and I'm not sure that there needs to be a lot of detail provided as to why a single ICD-9-CM code (or category) is now represented by multiple codes in ICD-10-CM. Beeswaxcandle (talk) 04:59, 8 March 2015 (UTC)

Thanks. I can see now how the 1:2 works, hadn't picked up on that before.--In Vitro Infidelium (talk) 12:23, 10 March 2015 (UTC)

Why doesn't "ICD-9" say "ICD-9-CM" since there is a large difference between the WHO's "ICD-9" and the US NCHS "ICD-9-CM"? Can we change this in the template? Thanks. Ward20 (talk) 23:23, 28 June 2015 (UTC)

The actual links are to the ICD-9-CM so yes, that's what the template should say. Cheers, The Jolly Bard (talk) 23:28, 28 June 2015 (UTC)

The problem Beeswaxcandle is that in the case of ME/CFS, it's not a situation of multiple codes for a disease. The ICD-10-CM moved CFS (indexed in WHO ICD-10 to G93.3) to a new, distinct code (ICD-10-CM R53.82) and added a type 1 exclude to both G93.3 and R53.82, classifying them as separate diseases. In the CFS article, if we add the ICD-10-CM code R53.82, it will link to the WHO ICD which doesn't contain this code. It seems then there needs to be a field for ICD-10 and ICD-10-CM codes, with the ICD-10-CM codes linking to http://www.icd10data.com/ or some such site as the ICD-9-CM codes are. Anal0gue (talk) 01:02, 5 July 2015 (UTC)

Template-protected edit request on 1 July 2015

Please change field "ICD-9" to say "ICD-9-CM" since that is what is referenced and there is a large difference between the WHO's "ICD-9" and the US NCHS "ICD-9-CM" Thanks. Ward20 (talk) 22:28, 1 July 2015 (UTC)

I agree, this is very confusing. Cheers, The Jolly Bard (talk) 00:17, 2 July 2015 (UTC)

Done! Plastikspork _―Œ^(talk) 21:49, 4 July 2015 (UTC)

Thank you.Ward20 (talk) 22:24, 4 July 2015 (UTC)

One other request, Wikilink should point to International Statistical Classification of Diseases and Related Health Problems#ICD-9-CM. Thanks. Ward20 (talk) 20:47, 13 July 2015 (UTC)

Human Disease Ontology - wikidata

Hello! I am part of a team funded by an NIH grant to help improve the structured content about diseases (and drugs and genes) on Wikipedia. We have thus far been working to incorporate the Human Disease Ontology into wikidata. You can see discussions and activities of the relevant bot on its wikidata page.

I would like to propose that Disease Ontology identifiers be added to the disease infobox and that this be carried out via a call to wikidata within this template. I understand the desire to rework the template so that its more informative and less of a list of external links as discussed above. I would support a modification to address that problem, but think that the DO ids have gained sufficient importance in biomedical research circles that they should be included in whatever identifier listing is settled on here. With regard to a transition to maintaining information like this in wikidata instead of directly in Wikipedia, our group is ready and willing to execute the bots that make that happen, including keeping things up to date over time. Our wikidata bot already incorporates disease ontology ids, orphanet ids, ICD-10, ICD9, MeSH, NCI and NCI thesaurus ids. For articles that have correct mappings to wikidata items, this content could be accessed from wikidata today using a template like the one proposed above by RexxS. Looking forward, one of the ways that our efforts might help improve the usability of this infobox is through automatic incorporation of content being added to the DO such as a structured representation of the symptoms associated with each disease. So, hello! and how can we help? Benjamin Good (talk) 19:03, 21 July 2015 (UTC)

There is discussion on whether we should have less indentifiers in the infobox. How about put it in the authority control such as we see at the bottom of this page Pneumonia#External_links

How are you planning on doing structured representation of symptoms? That would be more difficult but more interesting.

Doc James (talk · contribs · email) 06:18, 22 July 2015 (UTC)

I think moving identifiers into an authority control box would be good. I would also move the ICD links into that (and maybe the others as well). It seems pretty safe to assume that most readers aren't going to be too interested in the ICD10 code for the disease they are looking at and that people that do want it could find it down in such a dedicated linking box. (I would not want to lose these links from the articles). Moving these down into an authority control box maintained by wikidata bots would unclutter the articles and reduce the chance that some one would make a mistake when editing them.

The plan for symptoms is to use the human phenotype ontology (HPO) to structure them. Basically for each disease ontology term the DO/HPO teams are generating a constellation of phenotype ontology symptoms. The HPO is currently taking off as the structured way to represent this kind of information. For example, the 100,000 genomes project will be using it to capture data about all of their patients. This is ongoing work though. Right now, we are working to make the connections between Wikipedia articles and the corresponding wikidata items (via DO ids). This will make all of that work easily accessible to the Wikipedia community as it come into existence. Benjamin Good (talk) 16:08, 22 July 2015 (UTC)

I think we should move MeSH and Diseases DB along with your new one to the authority bar. I think we should have one disease identifier in the infobox, the ICD. But that is just me.

Look forwards to seeing what you develop WRT symptoms and please bring it back here when you have a prototype. Doc James (talk · contribs · email) 21:03, 22 July 2015 (UTC)

What your thoughts with respect to using data from wikidata in this template? Benjamin Good (talk) 20:46, 23 July 2015 (UTC)

I9606/Benjamin -

• Yes do it! Your project is awesome and I want to help you get the community review and support that you need
• As proposed, it is a good idea to just add the information to the existing infobox. You further propose developing and rearranging infoboxes, which is a good idea but a step beyond the most critical part of this
• As James mentioned and you acknowledged, I and others have discussed splitting the current infobox into something human readable and something with authority control links. If you have capacity to develop and trial a split of these things then I think that would be useful. I could help with a non-automated static demo and get community comments if that could lead to you considering setting up a link between Wikidata and a live working authority control box.
• I see that you have been around on Wikipedia for years but still are sort of new to things - I am available to chat by voice or video about Wiki-culture if you ever want to talk. Email me anytime.

Blue Rasberry (talk) 16:44, 27 July 2015 (UTC)

Blue Rasberry (talk) I work primarily on the Disease Ontology and am part of the group Benjamin Good talked about. First of all, the disease info boxes should only be used for actual diseases. Which means a new type of info box should be used, otherwise you get the issue where 'Pregnancy' has the same info box as 'Malaria'. An inclusion of a definition is very important, as well as symptoms. Other additions could include causative mutation (for genetic diseases). If we go the way of splitting the info boxes and including the main identifiers at the bottom of the page (authority control), then I would suggest including a 'disease classification' in the info box itself. I would definitely like to talk to you some more about that. I am currently out of the office, but will email you as soon as possible. Emitraka (talk) 22:02, 27 July 2015 (UTC)

Using another type of infobox makes things more complicated. I think leaving it as "infobox medical condition" works well and keeps things simpler.Doc James (talk · contribs · email) 11:46, 28 July 2015 (UTC)

Yes, I agree. As James said, adding the field to an existing box is the easiest and least controversial way forward. If you want to make a new box, redesign the existing one, or otherwise change other people's workflow, then that is possible and I would help you with that, but making a change which does not affect others is the easiest way forward. If you added your information, then later someone who wanted to move or relabel certain fields could do so. Blue Rasberry (talk) 20:52, 29 July 2015 (UTC)

Doc James can you document |style= added in this edit? seems like a very generic name, with a non-obvious purpose. Frietjes (talk) 16:51, 3 August 2015 (UTC)

This pulls what medical specialty the disease is in from Wikidata if not present on Wikipedia. Doc James (talk · contribs · email) 16:54, 3 August 2015 (UTC)

Doc James so why is it called |style= (note, I am not asking about |field=)? Frietjes (talk) 19:12, 3 August 2015 (UTC)

user:Ladsgroup any specific reason? Doc James (talk · contribs · email) 01:30, 4 August 2015 (UTC)

That was because of my misunderstanding of how Module:Wikidata works in English Wikipedia. I couldn't find any help. anyway. "{{{field|{{{Field|{{#invoke:Wikidata|getValue|P1995|{{{style|FETCH_WIKIDATA}}}}}}}}}}}" should change to "{{#invoke:Wikidata|getValue|P1995|{{{field|{{{Field|FETCH_WIKIDATA}}}}}}}}". In my defense I thought it's something related to style of data that is coming from Wikidata (e.g. it should be linked or not) Thanks for noticing the issue. :)Ladsgroup^overleg 08:49, 4 August 2015 (UTC)

Updated. Doc James (talk · contribs · email) 12:59, 4 August 2015 (UTC)

Add pronunciation to the infobox

I think we need to do everything possible to keep the first sentence easy to understand, in English, and to the point. As such I propose we move the pronunciation form the first sentence to the infobox.

This article does Roentgenium. Doc James (talk · contribs · email) 13:10, 13 August 2015 (UTC)

This discussion is also happening elsewhere - I propose that discussion happen at Template_talk:Infobox_drug#Move_pronunciation_to_the_drugbox. Blue Rasberry (talk) 14:07, 13 August 2015 (UTC)

Have added it as seen here for Pneumonia Doc James (talk · contribs · email) 02:02, 16 August 2015 (UTC)

Allow names with codes?

See my "ICD codes.."-section here. About the docs here: "Index number in ICD10. Multiple codes are permitted." I understand that allowing more [than codes] – something not expressly permitted – must have limitations. I'm just not sure everything not permitted is forbidden, or should be.

I don't know if there is some page in WP I should read on medical pages or if its ok to just bring this up here. Am I opening some can of worms? Doc James hasn't answered. I notice pregnancy, code: Z33 would say "Pregnant state, incidental" possibly including:
"Incl.:
Pregnant state NOS"

I can see how "Pregnant state" migh not be helpful, and "incidental" or more being just confusing.. but allowing the name with the code in the case I originally had might be ok? I'm not asking for required. comp.arch (talk) 13:48, 28 July 2015 (UTC)

@Comp.arch: I've only just seen this, hence the delay in responding. With respect to the fibromyalgia question, I don't agree with the logic expressed here (or there). The ICD, in which ever incarnation, is a statistical classification, not a nomenclature. It is enough to say that this is the code used for this disease concept in a particular classification. The fact that ICD-10 is more granular than ICD-9-CM is well understood by users of the classifications. Anyone who is pulling data on fibromyalgia presentations using ICD-9-CM should consult a nosologist first to understand what is covered by the sub-category. Then they can decide to what degree a medical record review is required. Beeswaxcandle (talk) 05:09, 3 October 2015 (UTC)

I'm not sure I follow, as there may be a misunderstanding (at least on my part). 1) First, here, I was just asking if allowing a name with the code is allowed. Note, I'm happy with the infobox at Fibromyalgia, as it ended up saying "ICD-10 M79.7 – Fibromyalgia". Note also, I'm not saying the name for ICD-10 needs be the same as for ICD-9 and the infobox in facts says "ICD-9-CM 729.1 – Myalgia and myositis, unspecified".

I though ICD-10 was (in general) just an updated ICD-9 (similar to DSM-5). Meaning sometimes no changes, but sometimes not? Such as changes for Fibromialgia classification. Are you saying ICD-10 tries to be more granular (in general)? [I was aware untill now about "-CM" ending so I disregarded ICD-9 vs. ICD-9-CM, and think that is still ok.].

2) As I said, there: "the official name for the code" - is that some misunderstanding of mine? I'm not a doctor.. I am however a database administrator, and we like to have names with codes.. :) Are there not official names for the codes of each "disease concept"? That seems to be more general than "offical" names of diseases..

3) You can disregard the e.g. "Pregnant state, incidental", I might just have complicated things by bringing it up, not saying anything more than a code would do there.. comp.arch (talk) 22:23, 3 October 2015 (UTC)

I'm a nosologist and I spend my life using and training others to use ICD. This includes people who use the classification to code health encounters, as well as end-users of the coded data. This means that I have a broad understanding of how ICD is implemented and used in many settings. I'm saying that I don't see the need for the word(s) to be beside the code in the infobox. Some of the boxes are cluttered enough as it is. If anyone wants to know what the rubric for a code is, they can just click on it. The full database record doesn't belong here on enWP. It could go on Wikidata, if it is felt that Wikimedia needs to host the WHO codes with their rubrics, date of addition/retirement, and use restrictions (sex, age range, sequencing, death). Beeswaxcandle (talk) 00:00, 4 October 2015 (UTC)

P.S. ICD-10 is a distinct classification to ICD-9. The codes are structured differently, as are some of the categories within the chapters. The whole point of moving to ICD-10 is because it is more granular and therefore has better precision. ICD-11 is better again and has a new underlying structure—but that's a story for another year. Beeswaxcandle (talk) 00:06, 4 October 2015 (UTC)

ICD-10 vs. ICD-10-CM

Is this infobox meant to display ICD-10 or ICD-10-CM codes? It's a bit confusing because it is using the US CM codes for ICD-9 (and the hyperlinks go to a US ICD-9-CM lookup site) but it appears to be meant to display WHO ICD-10 codes (hyperlinks go to who.int lookup site) versus the new ICD-10-CM codes. Now that the ICD-10-CM is in effect, there are conditions which have a new code in the ICD-10-CM that don't exist in the ICD-10. Should we be using WHO ICD-10 codes or US ICD-10-CM codes in this infobox? Anal0gue (talk) 01:10, 3 October 2015 (UTC)

It's supposed to display the WHO ICD-10 codes. I believe it should stay that way, which keeps the box international. If the infobox is changed to ICD-10-CM, then it will take on a US-bias. There are several national modifications of ICD-10 in use around the world and the users of those are coping just fine with the WHO codes. ICD-10-CM is just another national modification. [Before someone challenges me on ICD-9-CM having a US-bias, it was in use in several countries including Australia, New Zealand and Singapore before they moved to ICD-10.] Beeswaxcandle (talk) 04:55, 3 October 2015 (UTC)

ICD10 best for now. One could put the ICD10CM in Wikidata though. Doc James (talk · contribs · email) 11:32, 3 October 2015 (UTC)

Expanding on Beeswaxcandle's comment; it would probably be inappropriate to switch the template to ICD-10-CM until the publication, and wide adoption, of ICD-11. Incidentally, a similar question was asked over at the ICD10 template last month. (Aside: I wonder if there is call for clinical/medical coding task force?) Little pob (talk) 18:19, 10 October 2015 (UTC)

Template-protected edit request on 2 November 2015

Please add the following index to the Infobox medical condition:

|-
{{#if: {{{Derm101|}}}|
! [[Derm101|Derm101]]
{{!}} [http://www.derm101.com/therapeutic/{{{Derm101}}}/ {{{Derm101}}}] {{{Derm101_mult|}}}}}
|-

Gman45708 (talk) 22:21, 2 November 2015 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Qed237 (talk) 22:40, 2 November 2015 (UTC)

User:Gman45708 some parts of it requires login? [6]

There is some great images here. Would they be willing to release any under an open license? Doc James (talk · contribs · email) 07:37, 3 November 2015 (UTC)

EUROCAT codes

With reference to this version[7] of the Multicystic dysplastic kidney page; is there call to add the EUROCAT extension of ICD-10 chapter XVII?

Does there need to be a way look up (verify) the codes beyond this pdf?[8] Little pob (talk) 08:57, 26 November 2015 (UTC)

Adding Disease Ontology ID to classification

Since it seems that we have reached the point of remodeling the infobox (see above), I would like to propose to add the Disease Ontology (DO) ID to the classification field (P699 in Wikidata). It is updated maintained by the DO team and imported into Wikidata by the ProteinBoxBot. It is used to annotate data by a variety of projects, e.g. Zebrafish Information Network (ZFIN), WormBase.
Disease names, synonyms, ICD10 codes, OMIM IDs and others are constantly updated in DO and subsequently imported into Wikidata. All this information will be (is being) fed back into Wikipedia, so it makes sense to include the DO identifier into the classification field. -- emitraka (talk) 21:25, 2 December 2015 (UTC)
Publications about DO:

• The Disease Ontology: fostering interoperability between biological and clinical human disease-related data
• Disease Ontology 2015 update: an expanded and updated database of human diseases for linking biomedical knowledge through disease data.
• Disease Ontology: a backbone for disease semantic integration
• support The Human Disease Ontology is being used as the central organizing ontology for efforts to populate wikidata with medically relevant information. It would thus be valuable and sensible to have links to its identifiers available as part of the corresponding medical condition pages. --Benjamin Good (talk) 22:32, 2 December 2015 (UTC)
• support very good idea to add Disease Ontology ID to classification--Ozzie10aaaa (talk) 22:56, 2 December 2015 (UTC)
• Would support adding it to the new navbox that goes at the bottom. We could in fact add the new navbox to all medical articles with a bot before we remove it from the old infobox disease. Doc James (talk · contribs · email) 04:35, 3 December 2015 (UTC)

@Doc James Interesting idea. And yes, the thought is to add it to the navbox at the bottom of the page. -- emitraka (talk) 15:32, 3 December 2015 (UTC)

• Comment: let's do it then. I can not judge on this proposal content, but by now I think it is accepted. So I strongly suggest that Bluerasberry adds this to the proposed Medical resources box. -DePiep (talk) 18:09, 13 December 2015 (UTC)

ICD-10 version tangent discussion

• Comment Which version of ICD-10 has wikidata been populated with? The current infobox uses and links to the "2015-WHO" version.[9] — Preceding unsigned comment added by Little pob (talk • contribs) 08:43, 3 December 2015 (UTC)

@Little pob It has been populated with the ICD-10-CM version. -- emitraka (talk) 15:32, 3 December 2015 (UTC)

I appreciate that the use of ICD-10-CM codes may have been down to the data sources available, as well as ICD-10-CM being public domain, and I'm happy to accept any suggestion that there are enough medical coders in the US to argue that there is enough weight to include ICD-10-CM codes in the new box; however, there are several differences between ICD-10 and ICD-10-CM. Whilst WHO have previously given wikipedia permission to present the classification, I'm assuming that permission would have to be reaffirmed to port to wikimedia?

Anyway, I guess what I'm asking is; is the plan for the ICD-10-CM codes to be in addition to those from the base classification, or instead of the ICD-10 codes? My worry is replacing ICD-10 code with those from ICD-10-CM will reduce the usefulness of wikipedia to non-US coders (myself included). Little pob (talk) 16:30, 3 December 2015 (UTC)

I agree with Little pob here. ICD-10-CM is a derived classification (as are other national derivations such as ICD-10-AM, ICD-10-CA and ICD-10-GM). ICD-10-CM should not be the primary data item fed through to any place where an ICD-10 code is to be displayed. I have no problem with ICD-10-CM codes being made available, but not as the only or main code. Wikipedia must remain international and not have a US-bias. Beeswaxcandle (talk) 20:42, 4 December 2015 (UTC)

Reading this as an outsider: re "Which version of ICD-10" in Wikidata, it appears that that is version ICD-10-CM, which is a different version. Shouldn't Wikidata be corrected in this? About what to include: looks like we should allow for both ICD-10 and ICD-10-CM as separate entries. The -CM is of lower importance. -DePiep (talk) 09:56, 5 December 2015 (UTC)

I agree with DePiep. Both can (should) be included in Wikidata. This would mean a modification at the property level. For now there are two ICD10 properties; P494 (ICD-10) and P1690 (ICD-10-PCS). But I think this is outside the scope of this current proposal. Maybe it should be moved to a separate section? -- emitraka (talk) 18:18, 7 December 2015 (UTC)

Emitraka Thanks for the clarification. (I've also put this tangential discussion under it's own subsection.) Little pob (talk) 21:27, 7 December 2015 (UTC)

fixed mangled edit

this edit, moved the tracking category inside the parser logic. I have now corrected the problem. Frietjes (talk) 16:12, 12 January 2016 (UTC)

Field capitalization inconsistencies

So it is a pretty common thing to use "-ologies" in fields; it is also common to capitalize or leave their first letters lowercased. I feel that, perhaps, we ought to seek a consensus for a consistent case, and I think that it must be lowercased. Gamingforfun³⁶⁵ (talk) 00:19, 6 February 2016 (UTC)

Another reform proposal - split infobox into "human readable" and "non human readable" and call from Wikidata

In a variation of previous proposals, I propose moving links and catalog data contained in this infobox to the bottom of Wikipedia articles. This serves these purposes:

1. Clears the highly desirable location at the top of the Wikipedia article to make room to present human readable information. This space is currently occupied by this infobox, "Infobox medical condition", which currently presents mostly catalog data and external links.
2. Presents catalog data and external links in a way that is more standard in Wikipedia - horizontally, and at the end of the article.
3. Makes medical condition infoboxes in the lead readable by humans

I said "I propose" because I am writing the proposal, but this idea comes from lots of others and a long history of discussion with dozens of participants. Blue Rasberry (talk) 20:23, 1 December 2015 (UTC)

Summary of previous related proposals

For context, here are some related background proposals:

• At Template:Infobox drug there is Proposal to explore through 2016 - consumer information in the infobox, where I made a related proposal to present consumer information in Infobox drug.
• This infobox is incomprehensible, January 2015, a user complains about the catalog data. Thanks Bhny for commenting.
• Perhaps this infobox should not be the primary medical condition infobox, February 2015, discusses replacing catalog data and external links with consumer information
• Nomination for merging of Template:Infobox medical condition, February 2015, it is proposed to merge this template with Template:Authority control. In my opinion what is being articulated here is a desire to put catalog data at the bottom of the article. This desire builds on the precedent of the authority control template doing this with almost a million articles and having good community support.
• Human Disease Ontology - wikidata, July 2015, a team of data scientists proposes to develop both the set of catalog data/links and the consumer descriptions of diseases by helping Wikipedia better classify diseases in databases and with human readable descriptions.

Blue Rasberry (talk) 20:23, 1 December 2015 (UTC)

New proposal

Here are the conceptual points in this proposal -

1. Infobox medical condition is split into two boxes. A human readable part stays at the top and a list of links and catalog data goes into another kind of infobox at the bottom.
2. For both new boxes, data in the boxes comes from Wikidata. The catalog data and links come from Wikidata only (not live in this demo) and the box at the top of the article is a mix of Wikidata and locally edited content on English Wikipedia (live in this demo).

Here is how this proposal would be technically implemented -

1. Fields in "Infobox medical condition" are classified as human readable or not-human readable. "Not human readable" includes catalog data and external links.
   1. An example of catalog data would be information like "ICD-10 M10", where a catalog system is named then the medical condition's arbitrary unique identifier is presented. This data has no value to human readers without following the link or using a computer to access more information.
   2. An example of an external link would be information like "MedlinePlus 000422", where a publisher offers human readable information on their website through an external link in Wikipedia.
   3. Note that on Wikipedia, catalog data and these kinds of external links look the same. Both will list an external website then present an arbitrary identifier, but one links to database management tools and the other links to consumer information to be read.
2. All information that is "not human readable" is moved into a separate template.
   1. In this proposal, that separate template is at the bottom of the article in the "external links" section.
   2. The model for this is Template:Authority control. See examples at Template:Authority_control#Examples.
   3. Eventually all of this information is moved into Wikidata, then called into the template from Wikidata rather than maintained on English Wikipedia.
3. The "human readable" template remains at the top.
   1. New, amazing Some information in this template is called from Wikidata.
   2. Some localization is possible along but content from Wikidata is going to be more stable and harder to change.

Blue Rasberry (talk) 20:23, 1 December 2015 (UTC)

Demo

See also Draft:Gout for more tests. No tests in article Gout needed

(proposed version) - A human readable box at the top and a box for catalog data and links at the bottom.

Thanks to Doc James who provided {{Medical condition classification and resources}} and Emitraka who has done so much to connect English Wikipedia infoboxes to Wikidata, including developing this prototype.

See this live at this version of the gout article. Note the top infobox and the box in external links.

Top of article page

Gout (also known as podagra when Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

TOC and sections go here:

==Section(s)==
==References==
==External links==

Regular navbox for gout page:

Bottom of article page

Thanks to Mr. Stradivarius for developing this at Help talk:Template.

Note that the regular infobox in the demo page (including the picture) is an image because it pulls from Wikidata. Click show to see it rendered here.

This is what the box looks like when it is applied elsewhere. The localization can be edited in Wikipedia, while certain other kinds of data are managed in Wikidata. Infobox medical condition (old)/Archive 3 Here is code for this. Wikidata knows that gout is from the specialty "rheumatology", and that its symptom is "joint pain", so this information comes from there. Also these terms are translated in Wikidata so that all languages pulling from Wikidata get the same basic information. {{Infobox medical condition(new) | Name = Gout | Image = The gout james gillray.jpg | Alt = A small fierce creature with sharp teeth is biting into a swollen foot at the base of the big toe | Caption = ''The Gout'' ([[James Gillray]], 1799) depicts the pain of the artist's gout as a [[demon]] or [[dragon]].<ref>{{cite book---- omitted for clarity}}</ref>}} }}

Here is the traditional infobox for gout

This proposal would replace this one box with the two new ones:

Infobox medical condition (old)/Archive 3
Specialty	Rheumatology

Blue Rasberry (talk) 20:23, 1 December 2015 (UTC)

Comments?

• Support as proposer I have made lots of proposals like this and supported lots of proposals from others. I like hearing everyone's ideas for how this should work and enjoy the continued conversation and feedback that everyone gives. Blue Rasberry (talk) 20:23, 1 December 2015 (UTC)
• @Anypodetos, Opabinia regalis, DePiep, Matthew Ferguson 57, and Boghog: You all commented on a similar proposal at Template talk:Infobox drug. I thought you might have an opinion about this. Blue Rasberry (talk) 20:32, 1 December 2015 (UTC)
• readers may find this infobox more helpful. Would take a lot work to implement this however. Matthew Ferguson (talk) 20:55, 1 December 2015 (UTC)
• Support the concept of drawing from wikidata where possible; no objection to moving catalogs and other links out of the infobox; not sure on the simplified symptoms/causes/treatments thing. Also, is it just me or is the proposed replacement in a strange large font? Opabinia regalis (talk) 21:19, 1 December 2015 (UTC)

Opabinia regalis The font is within a picture. I cannot show a live version here. The template checks the article title, checks the language of the project where it is used, goes to the linked Wikidata item, then propagates itself with whatever is at Wikidata in the language where it is used. There is no Wikidata article for "Infobox medical condition" and even if there were it would not find medical data there. It has no demo mode so I used an image. You can see a live demo at gout. Blue Rasberry (talk) 22:51, 1 December 2015 (UTC)

• support, however "simplified" symptoms/causes/treatments may need tweaking...IMO--Ozzie10aaaa (talk) 21:57, 1 December 2015 (UTC)
• What is the actual proposal or question about? (If it is about the "Classification; External resources" box I could be very enthousiastic). -DePiep (talk) 23:32, 1 December 2015 (UTC)

DePiep Three parts - the first part is that "classification external resources" box. However, in making that, the original infobox becomes empty as most infoboxes only have that content. The second part is to repopulate empty original infoboxes with consumer information. The third part is that if we are redesigning infoboxes anyway, let's redesign them to call from Wikidata rather than keep the information locally. Blue Rasberry (talk) 12:33, 2 December 2015 (UTC)

Support. Great. I made some sidenotes about box positioning (see below). -DePiep (talk) 13:24, 2 December 2015 (UTC)

I urgently propose to name the new footer template (non-human) into something general, not referring to 'medicine'. The core concept of 'classification' and 'external links' is without problem expandable to bordering topics ({{Drugbox}}) and that border's border topics ({{Chembox}}). btw, I think it might have another row for 'Identification' too, there. -DePiep (talk) 20:36, 4 December 2015 (UTC)

• Support Needs more work the idea with acknowledgement that roll out will be very slow. This will be an option but does not mean the old ones will be immediately deleted. It is easy to move the prior content to the lower box. It is getting the symptoms, causes, medications, frequency, etc into Wikidata that is time consuming. We also need to have our infobox content support by references. You can see the live version at gout. The new infobox is based on this template [10] and we have a few additional parameters that are proposed. Doc James (talk · contribs · email) 07:07, 2 December 2015 (UTC)

Doc James does that 'more work' needs to be done before acceptance? If after acceptance (i.e., just a long time and many edits before all are changed), that would not be a hindrance for acceptation, is it? -DePiep (talk) 20:31, 4 December 2015 (UTC)

I still really like the idea. But we need to overcome a number of blocking bugs first. Doc James (talk · contribs · email) 03:55, 5 December 2015 (UTC)

I really like the idea of more human information in the infoboxes and moving the numbers lower. Doc James (talk · contribs · email) 22:40, 22 December 2015 (UTC)

Doc James Which? -DePiep (talk) 21:25, 22 December 2015 (UTC)

Okay now that we have fixed a few things I think it is a reasonable alternative. Doc James (talk · contribs · email) 03:08, 30 December 2015 (UTC)

Doc James, does not read like an answer really. Doc, do you know you are forking the topic instead of focusing on a discussed consensus result? You are actually pushing your proposals elsewhere eg [11]. -DePiep (talk) 07:52, 30 December 2015 (UTC)

What is the question? That was not an answer but a statement of opinion. Doc James (talk · contribs · email) 07:54, 30 December 2015 (UTC)

• Support per WP:UPFRONT. Whilst I wouldn't call the current infobox unencyclopaedic, it is mostly technical information. Little pob (talk) 09:06, 2 December 2015 (UTC)

• Follow up - Whilst still supporting updating the infobox; I'm going to make an alternative suggestion to moving the classification data to a navbox. Which is to split the infobox into sections - much like Template:Infobox drug and Template:Chembox - and have the bottom most section for classification and external resources (collapsed if need be). Using the aforementioned infoboxes, and the knowledge graph as guides; sections could be titled along the lines of overview, symptoms, and treatment. This could also allow the presentation of additional, summary information such as "first described by", "year first described", etc in something of a history section. Little pob (talk) 20:53, 17 January 2016 (UTC)

Google Knowledge Graph box for gout, mentioned by Doc James, and a comparable product to Wikipedia's infoboxes

• Neutral. I support the removal of "classification and external resources" from the opening frame of the page because it is really not very useful except for those looking specifically at external information. What I am a little bit more doubtful about is compressing the nuance of a medical condition into a few headline terms ("gout is treated with ibuprofen/prednisone/colchicine"). This is partly because it might be alarmist to those with mild symptoms, and partly because people will start self-treating (or even others-treating!) without reading the remainder of the article. Can we stick with fewer fields that don't attempt to convey complex clinical information? (I.e. only mention the specialty area, and not symptoms/causes/treatment). JFW | T@lk 12:44, 2 December 2015 (UTC)

Frequency and number of deaths globally for diseases if available can usually be simplified to a single data point. We could add "common" to symptoms.

This is what google contains [12] Doc James (talk · contribs · email) 13:38, 2 December 2015 (UTC)

• Support as member of the proposal team. Great job writing this down Bluerasberry. Doc James we also had talked about adding synonyms. They are already in Wikidata, thanks to the Disease Ontology import. I can see them either below the name of the disease or below the 'Specialty' field. emitraka (talk) 20:36, 2 December 2015 (UTC)

Yes was hoping to add the synonyms above the speciality / field but only want to add certain ones like maybe podagra and gouty athritis. Doc James (talk · contribs · email) 04:33, 3 December 2015 (UTC)

• Comment I have to take issue with the concept that the ICD codes are not human readable. I am human and I can read them. Sure, I spend a large amount of my working life in ICD-10, but I'm not the only person who looks at a code on an article and understands immediately what that code implies about the disease concept. That said, I don't object to the proposal, provided the implementation is carefully done. The same data item needs to be in the same place on all relevant articles at the same time. Having it in one box on some articles and in the other on the rest during the transition would be detrimental to the uses to which the items are being put in RL situations. i.e. the new box needs to be created and populated on all relevant articles before the data items are removed from this box. Also, as someone who finds errors in the ICD codes from time to time, will a simple way be made to correct the codes from the new box without having to understand the arcana of Wikidata? Beeswaxcandle (talk) 07:02, 3 December 2015 (UTC)

Hum yes good point. We could add these new boxes at the bottom by bot based on Wikidata data. Hopefully Wikidata will become easier to edit overtime. Are we able to put an edit button in this template that would bring people to Wikidata? Doc James (talk · contribs · email) 07:52, 3 December 2015 (UTC)

"I can read them" ICD-10's - you think you can, but what you actually can is spell them. They are a code, not a meaningful word, and as such eligible for moving downwards. -DePiep (talk) 23:20, 4 December 2015 (UTC)

@Doc James: yes, it should be possible to add some kind of "Edit" button at article, that sends people to Wikidata entry. And for correcting wrong codes here/at Wikidata - you can add tracking categories, that track such differences. --Edgars2007 (talk/contribs) 17:32, 26 December 2015 (UTC)

• Support we have already done this at WP:ANATOMY where all data was ported to Wikidata by a bot. It is a great idea to move those space-consuming links in the lead the bottom. --Tom (LT) (talk) 09:38, 3 December 2015 (UTC)

LT910001 Can you give us links to the templates and the background (-diascussion/description)? -DePiep (talk) 20:27, 4 December 2015 (UTC)

The template is {{Infobox anatomy}} and the bot request is here [13] here [14] here [15]. The discussion is here: Wikipedia_talk:WikiProject_Anatomy/Archive_9#Wikidata_and_anatomy_articles. We haven't collaborated in a while but hopefully we can again soon DePiep. Cheers --Tom (LT) (talk) 22:07, 12 December 2015 (UTC)

• Comment Have discovered a problem. This new template does not show in mobile [16] which is 63% of our traffic to this article. Doc James (talk · contribs · email) 10:56, 3 December 2015 (UTC)

Yep, see gout (mobile) vs gout. I noted this 2 hours earlier ;-), see 'About box positioning' below. Is because it is a navbox (as {{Authotrity control}} is). Navboxes do not show mobile for a reason (by meta webpage design). If we want to circumvent this, and are allowed to, we should create a similar box non-navbox (that shows in mobile), and put it in section 'External links'. That way it can be collapsed by the reader. Note that this is a very ugly box to show to the human eye. -DePiep (talk) 23:31, 4 December 2015 (UTC)

This box Template:Medical condition classification and resources shows in mobile. We now need someone who can build it so it puts many items on one line for wide screens and makes it look nicer. User:DePiep do you have that skill? Doc James (talk · contribs · email) 03:57, 5 December 2015 (UTC)

That is the human-readable box of the new pair? I'd start from the new Resources box (footer box), because it has great layout. Just need to remove the "don't show when mobile" bit. But before diving into that, I'd really like to hear whether this showing is desired both by Medicine-editors and by Wikipage-designers. (My experience especially at Chembox is that the heavy editors have a tendency to say 'always to show everything, it's important!' ;-). Just try to get one datarow removed). We can put up a careful question at the village pump. Technical creation can be done later. IMO show/noshow is not an, er, showstopper. -DePiep (talk) 08:50, 5 December 2015 (UTC)

In short, I'd like to know why this box should show in mobile while all Navboxes and Authority control do not. -DePiep (talk) 11:50, 7 December 2015 (UTC)

• Recap re show or not in mobile view. Hoping to flesh this out and remove a treshold. Navboxes and {{Authority control}} by design do not show in mobile view. This is by design (in Module:Navbox and its css class, which is also used by Authority Control). Our current demo, I call "Medicine Resources", is also such a navbox format (see gout (mobile view)). Doc James writes here that that is an undesired feature (it should show in mobile). I think no-show-in-mobile is OK, not a problem.

Some background for not showing in mobile. By wiki webpage design, a lot of stuff is not content: menus, tools, links to sister projects, and so navboxes (including {{Authority control}}). To illustrate this: these page parts also do not show in print (for the same reason). They are more like Wikipedia-internal (the word 'navigation' is a hint: to navigate WP, not the article topic). And {{Authority control}} values are not readers readable info, but codes for external links/sources. (See Van Gogh GA / van Gogh (mobile)).

Alternative: there may be information that is clearly article content (eg, melting point of a drug?), but that is too detailed for the infobox. Such information might go to a dedicated section with an article template, in a separate regular section say called ==Data sheet==. This will (must) show in both views desktop and mobile, and in m.view will nicely collapse for being a section. However, for this {{Infobox medical condition}} I see few data points that are candidate for this. -DePiep (talk) 08:32, 23 December 2015 (UTC)

A lot of people use ICD codes for billing. And use WP to pull up those codes. Thus this is content people will want to see on mobile IMO. Doc James (talk · contribs · email) 13:21, 23 December 2015 (UTC)

For billing, is that encyclopedic? Maybe the ICD codes could be in the top infobox (unlinked, and surely not externally linked), as they seem to be very commonly used. The others: down to the bottom. DePiep -15:21, 23 December 2015 (UTC)

If you didn't link you'd need to give a verifiable source. I10, for example, would just become I10 . Effectively doing the same thing, but adding a click for anyone wanting to verify the code.

Little pob (talk) 15:50, 23 December 2015 (UTC)

That's a source, not the external link we currently show. We are not a WP:linkfarm. -DePiep (talk) 16:27, 23 December 2015 (UTC)

In this case the EL is being used to provide verifiability (rather than for further reading). Now I'm not implying your point isn't valid; but (AFAIK) you will have to establish there is consensus to change the status quo. Out of respect of the current, wider discussion, a separate RfC is probably the best way to go about this. Little pob (talk) 08:50, 24 December 2015 (UTC)

"you [sic] will have to establish there is consensus to change the status quo" er, someone you or we? And why do you think I am working on this? Why do you think I created Draft:Gout to allow development & discussion, even with examples I do not support? Does not this thread already show a consensus tho change something? And anyway, to remove a linkfarm presentation we don't need RfC. -DePiep (talk) 17:02, 24 December 2015 (UTC)

I've already stated my support for the wider topic of changing the information supplied in the infobox, and moving the classification information to a navbox near the bottom.[17] WP:ELPOINTS, in the EL guideline, states "include appropriate external links ... in the appropriate location within an infobox, if applicable." This is supported by the WP:NOT policy, of which linkfarming is a part of, which summarises "policy ... that all editors should normally follow" (emphasis added). I'm sure we both know consensus can change, but it's my assumption that there would have been consensus to use links over refs when the medical condition infobox was originally set up. The reason for suggesting an RfC is multiple templates and infoboxes will be affected. (Interestingly, template:infobox drug externally links the CAS numbers but template:chembox doesn't.) Also it is worth noting that moving the classification data from the infobox to a navbox, changes the relevant section of the WP:EL guideline to WP:ELNO (specifically point 18). I'm sure the relevant templates that currently parse external links could be amended to apply the ref template instead? Either way, wikisource and wikidata could prove to be invaluable here. Little pob (talk) 12:57, 26 December 2015 (UTC)

Little pob I still get the impression that you try to teach me on consensus instead of exploring improvements (again, while I am the one opening demos etc). Meanwhile, Doc James is following a private track (Grout) -- maybe someone else needs the teaching. -DePiep (talk) 07:44, 30 December 2015 (UTC)

We have worked together to create a number of templates. There is support for moving in this direction. We are using these templates on ONE article. No one is suggesting that we expand to further article right now. I have enjoyed collaborating with you on this User:DePiep. I do not see there as being any private track. How is what is at Gout not what we have discussed here? Best Doc James (talk · contribs · email) 07:52, 30 December 2015 (UTC)

Just to clarify User:DePiep is your object to the content at gout that the external links and classifications that were in the old infobox are visible on mobile rather than hidden? Doc James (talk · contribs · email) 08:00, 30 December 2015 (UTC)

Ignoring all other arguments, DePiep; you said the links to the various classifications were a linkfarm. I'm saying having EL within infoboxes is allowed per guidelines and policy, and the classification information has yet to be removed from the current infobox. If the outcome of this discussion is they do move to a navbox (rather than a subsection of the infobox, for example), then removing the ELs is within current guidelines. (And quickest way of doing so would probably be to amend the various classification templates; rather than stripping them out altogether.) Little pob (talk) 10:22, 30 December 2015 (UTC)

• Support Suggestion, convert the emedicine links to the current numeric form omitting the leading article/, since the i.e. emerg/<<number>> etc forms are now redirects to the article/<<new_number>>. Ignore the duplication of references (i.e.) OMIM in References and bottom box as current? OMIM has a standard, short name phrase as well as the number, include both? RDBrown (talk) 10:42, 24 December 2015 (UTC)

Side notes

See also Draft:Gout for more tests & experiments

Split off: comments that are not decisive for a go/nogo. These should not trouble the main Comments talk.

• About box positreioning: As for positioning of the non-human box: {{Authority control}} says:

"See also: Wikipedia:Manual of Style/Layout. As a metadata template, the Authority control template should be placed after the external links section and navigation templates, right before the Persondata template."

Looks applicable for this one too. -DePiep (talk) 13:24, 2 December 2015 (UTC)

... but at Gout this new template now is positioned above regular navboxes. I think it looks better way below (obtrusive nonreadable data out of sight).

I note that, just as authority control and regular navboxes, this box does not show in mobile view. Seems correct handling and good meta page design indeed, and an improvement compared to the 'old' infobox. -DePiep (talk) 13:54, 2 December 2015 (UTC) (move to minor subsection "sidenotes") -DePiep (talk) 08:43, 3 December 2015 (UTC)

I think this sounds more like an external links template, and therefore it belongs in the external links section, before navboxes. WhatamIdoing (talk) 05:33, 20 January 2016 (UTC)

• Future expansion. Once this setup is deployed & stable, I am looking forward to stealing all ideas ;-) and expand the class+el box for {{Drugbox}} (like adding ACT code, Drugbank, CAS RN; 6000 pages). Simultaneously, we could add data points to cover {{Chembox}} (10k pages). This would expand the usage of the concept greatly. But let's introduce this version first. -DePiep (talk) 09:03, 3 December 2015 (UTC)

DePiep I remain interested in developing the drug box. I proposed content but that is somewhat arbitrary - I just want some kind of reform and more consumer information there, of whatever sort is appropriate. If you come to understand how these templates work well enough to steal the idea then please stay in touch with me. I want to learn too and to be able to teach others how to apply this concept elsewhere. I am not even sure that I have the vocabulary to describe what is happening here and not sure if documentation exists to explain this. Blue Rasberry (talk) 19:59, 4 December 2015 (UTC)

Well, I think drugbox does not need consumer info that urgently, but it surely needs a split off of non-human readable data (into below). First of all SMILES and InChI strings. -DePiep (talk) 20:06, 4 December 2015 (UTC)

I was thinking similarly. Sizeofint (talk) 20:47, 4 December 2015 (UTC)

• On-page link by anchor. We could add an {{anchor}} to the bottom template (say "#classifiers+el"), and add a wikilink to the top template like [[#classifiers+el|codes]]. Clicking brings the cursor to the bottom template (same as one clicks from TOC to a section). Problematic: if the bottom tempalte is not poresent, the link is idle. -DePiep (talk) 23:24, 4 December 2015 (UTC)
  • Sounds reasonable. Doc James (talk · contribs · email) 20:50, 23 December 2015 (UTC)

References

• Updates? Where are we standing with this? emitraka (talk) 16:57, 24 February 2016 (UTC)

I think gout has the latest version, see External links. Didn't see action last 2 months. -DePiep (talk) 18:03, 24 February 2016 (UTC)

Request for comments: Should the infobox medical condition contain a list of synonyms?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

No consensus for change, status quo stands, without prejudice to evolutionary change as this is at best a weak result. Guy (Help!) 08:42, 18 March 2016 (UTC)

---

In the encyclopedia, the manual of style recommends the following with regards synonyms:

[...] the title can be followed in the first line by one or two alternative names in parentheses
— Wikipedia:Manual_of_Style/Lead_section#Usage in first sentence

Alternatively, if there are more than two alternative names, these names can be moved to and explained in a "Names" or "Etymology" section; it is recommended that this be done if there are at least three alternate names, or there is something notable about the names themselves. Once such a section or paragraph is created, the alternative English or foreign names should not be moved back to the first line
— Wikipedia:Manual_of_Style/Lead_section#Separate_section_usage

Medical conditions frequently have many synonyms (e.g. Burning mouth syndrome).

The idea of including a list of synonyms in the infobox medical condition started on WT:MED (permalink here: [18]). James has kindly made a preview, seen here: Wernicke–Korsakoff syndrome. Another idea for dealing with the list of synonyms is to have them as a footnote (e.g. geographic tongue, this method discussed on WT:MED here: [19]).

If there is support for the above idea, then this raises other questions: should the list of synonyms replace entirely the list of synonyms in the lead, or elsewhere in the article? Or should the infobox be in addition to a list of synonyms in the lead or in a section within the article?

Ping to anyone who has expressed opinion on this so far. JakobSteenberg, Little pob, Johnbod, Doc James, Ozzie10aaaa, Boghog, TylerDurden8823, Looie496, Barbara (WVS). Matthew Ferguson (talk) 19:23, 9 January 2016 (UTC)

• I don't think they should be removed from the lead if they are in the infobox. Whether they are in the infobox I don't really care. If there are one or two really common synonyms they should be in the first sentence. If there is a long list of long names they should be a little lower down, perhaps at the end of para 1, bolded as redirects. Johnbod (talk) 19:56, 9 January 2016 (UTC)

That suggested layout (end of para one) seems not to follow the MOS quoted above. Matthew Ferguson (talk) 20:17, 9 January 2016 (UTC)

• Comment - My opinion is to make sure that whatever decision is made, that we keep in mind that the information on the synonyms and other possible names for the condition/disease/treatment is as easy to find as possible for the reader. Think eighth grader and where they would look. The MOS guidelines are secondary to being sure that the information is located quickly for the reader. My opinion is that a copious use of redirects accompany all such challenges. I am not often asked what I think, so thank you for the invitation to provide input. Best Regards,

Barbara (WVS) (talk) 23:45, 9 January 2016 (UTC)

• My opinion. One or two really common ones names in the first sentence. A couple of more in the infobox. And all discussed in the body if their are lots. We sort of do something similar with brandnames for medications. Doc James (talk · contribs · email) 02:17, 10 January 2016 (UTC)

I agree with the style Doc proposes immediately above my comment. Many conditions have several synonyms and eventually it bogs down the lead and readers are thinking "Okay, get to the point! What is this condition and what's causing it?!". I like the idea of the top one or two synonyms in the lead sentence and perhaps a few more in the infobox to the side for the sake of being complete. If I were reading the article, I wouldn't want a laundry list of synonyms at the end of the first paragraph, but that's just my two cents. TylerDurden8823 (talk) 02:57, 10 January 2016 (UTC)

• Put all the common names in the infobox, with a couple most common immediately visible and the rest collapsed, to provide all the information without excessive clutter. Do not modify the lead, since it should provide a summary of the subject regardless of the infobox. “WarKosign” 08:31, 17 January 2016 (UTC)
  • I hear that people with vision problems do not like stuff collapsed. Thus why I recommend putting less commmon ones somewhere in the body of the article. Best Doc James (talk · contribs · email) 08:40, 17 January 2016 (UTC)
• Comment I have no problem with having the most common synonyms in the proposed new infobox; however, I feel these should be in the article text also. (And that WP:MEDMOS should state which synonyms should go where.) Otherwise you risk having readers needing to look in 3 different places within the article to see if they've landed in the correct place (i.e. lead, infobox, body). Little pob (talk) 19:59, 17 January 2016 (UTC)

It would be worth noting at this point that although WP:MOS encourages a section in the article body where there are many synonyms (see original post), WP:MEDMOS does not include such a section in the recommended section headings. Perhaps MEDMOS should be updated to include instruction about how to manage synonyms. If this RfC comes to any clear consensus ofc. Matthew Ferguson (talk) 21:19, 17 January 2016 (UTC)

• I don't feel strongly about it. Mainly I agree with Barbara (WVS) and a few with compatible views. If the Infobox has the capacity, OK, though I am not convinced that other options would be inadequate. I'd say that if there are too many significant alternative names for offhand mention in the lede (say two or three), then simply say something like "many popular or regional names, as discussed below link to relevant section" And of course, wherever possible discuss and ref the names and confusions in that section. And create the necessary redirs. JonRichfield (talk) 14:03, 18 January 2016 (UTC)
• comment I have no opinion on the essence; but agreeing with the point that the criterion must be assessibility I would like to remind you the issue of mobile display: whether infobox or lede fit well the mobile device. So I suspect that if the list of synonyms is too long, it should be postponed via a prominent wikilink, e.g., (see synonyms). I don't see a good text which prominently say that synonyms are in the footnote (e.g. for the text "The Komodo syndrome has many synonyms^[11]", a person may interpret the footmark as pointer to external source and neglect to click). Staszek Lem (talk) 00:50, 19 January 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

KEGG DISEASE DATABASE

I am hoping KEGG disease DB to be incorporated in the table. にょろん (talk) 05:36, 4 April 2016 (UTC)

Please consider HTTPS for the OMIM, MedlinePlus, and GeneReviews links

The http://omim.org/entry/{{{OMIM}}} and http://www.nlm.nih.gov/medlineplus/ency/article/{{{MedlinePlus}}}.htm and http://www.ncbi.nlm.nih.gov/books/n/gene/{{{GeneReviewsID}}}/ links appear to support HTTPS. Given the practice of implementing HTTPS by default on Wikimedia sites and the potential for increased privacy and security for visitors, it would seem useful to use HTTPS for these links in the template by changing line 29 of the template from

| data8 = {{#if:{{{OMIM|}}}|[http://omim.org/entry/{{{OMIM}}} {{{OMIM}}}] {{{OMIM_mult|}}} }}

to

| data8 = {{#if:{{{OMIM|}}}|[https://omim.org/entry/{{{OMIM}}} {{{OMIM}}}] {{{OMIM_mult|}}} }}

instead, changing line 35 of the template from

| data10 = {{#if:{{{MedlinePlus|}}}|[http://www.nlm.nih.gov/medlineplus/ency/article/{{{MedlinePlus}}}.htm {{{MedlinePlus}}}] {{{MedlinePlus_mult|}}} }}

to

| data10 = {{#if:{{{MedlinePlus|}}}|[https://www.nlm.nih.gov/medlineplus/ency/article/{{{MedlinePlus}}}.htm {{{MedlinePlus}}}] {{{MedlinePlus_mult|}}} }}

instead, and changing line 64 of the template from

* [http://www.ncbi.nlm.nih.gov/books/n/gene/{{{GeneReviewsID}}}/ {{#if: {{{GeneReviewsName|}}}|{{{GeneReviewsName}}}|{{{GeneReviewsID}}}}}]}}}}{{#if: {{{GeneReviewsNBK2|}}}|

to

* [https://www.ncbi.nlm.nih.gov/books/n/gene/{{{GeneReviewsID}}}/ {{#if: {{{GeneReviewsName|}}}|{{{GeneReviewsName}}}|{{{GeneReviewsID}}}}}]}}}}{{#if: {{{GeneReviewsNBK2|}}}|

instead. Thanks. --Elegie (talk) 10:53, 14 May 2016 (UTC)

I requested more comments from Wikipedia_talk:Secure_server#Should_all_external_links_be_HTTPS_when_possible.3F. Blue Rasberry (talk) 13:43, 16 May 2016 (UTC)

Please see WP:MULTI and Wikipedia:Village pump (proposals)#RfC: Preferred protocol for external links. --Redrose64 (talk) 18:53, 16 May 2016 (UTC)

Wikidata parameter

I would like to propose that a new parameter be added to the infobox. It would be |Wikidata = <ref>url</ref>. This will provide a lot of good additional information like the same topic in other languages, a list of synonyms and links to other disease databases that we don't currently use in the info box. Best Regards,

Barbara Page — Preceding unsigned comment added by Barbara (WVS) (talk • contribs) 09:50, 14 June 2016 (UTC)

Propose a new parameter

I would like to propose a new parameter: Wikidata = unique Q id number linking to the url of the wikidata page about the disease</ref> These Wikdata pages provide information from other databases, a list of synonyms, the same article in other languages. With the parameter installed, some adept code writer could make this parameter entered automatically by referring to the title of the article and inserting the 'Q' link even on all the already-existing disease infoboxes. The wikidata page also provides information about the same disease on other language wikis.

Barbara (WVS) (talk) 10:00, 14 June 2016 (UTC)

Already on the left for all articles. Doc James (talk · contribs · email) 20:11, 8 July 2016 (UTC)

And there is an "edit on Wikidata" in the infobox. Doc James (talk · contribs · email) 02:12, 10 August 2016 (UTC)

Use Anatomical Location from Wikidata

Wikidata has a field for anatomical location. Currently most medical conditions don't have it but https://en.wikipedia.org/wiki/Colorectal_cancer for example has the information that Colorectal cancer is about the colon and that information could be displayed in the infobox. ChristianKl (talk) 09:55, 7 July 2016 (UTC)

Except when colon cancer metastasizes and than it can be nearly any where. Doc James (talk · contribs · email) 20:12, 8 July 2016 (UTC)

The point about metastasis is well taken, but there are probably many other conditions (besides cancers) that could use location data to good effect. For example gastritis, otitis media. Quercus solaris (talk) 02:09, 10 August 2016 (UTC)

Formatting glitch from 2016-07-23

Synonyms currently display weirdly in a typewriter-like format without a side heading. See infectious mononucleosis for an example. It seems that the edits of 2016-07-23 ("moving synonyms to subheader") messed up the formatting somehow. Can someone fix this? I cannot edit this page. Quercus solaris (talk) 02:04, 10 August 2016 (UTC)

User:CFCF? User:Quercus solaris what change are you wanting? Doc James (talk · contribs · email) 02:11, 10 August 2016 (UTC)

This was done on purpose to make the synonyms more visible. The different font style is to further differentiate it from the article name as synonyms can be more or less rare. Carl Fredrik 💌 📧 09:01, 10 August 2016 (UTC)

Ah, I see. That's good enough for me. Thanks, Quercus solaris (talk) 21:10, 10 August 2016 (UTC)

Size of images

The size of images in the infobox appears to have recently been decreased. Wondering how and if we can increase the size to 250px? Appears to be set at 220px or so. Doc James (talk · contribs · email) 02:41, 11 August 2016 (UTC)

@Doc James: I can't see any recent edit that's changed the default image size, but we already have a parameter |width= that can be used to override the default - Template:Infobox medical condition/doc #Images says that's 190px. Try adding something like |width=250px to the infobox in one of the articles that you think needs a bigger image. Ping me if that doesn't fix it for you. if you want the default to be bigger, that will need quite a bit more work (and consensus because it would make the default infobox wider), so let me know. --RexxS (talk) 01:45, 14 August 2016 (UTC)

The default used to be wider (like a few weeks ago). I do not know what changed. Probably something above this infobox. Yes would like the default set to be wider as changing it individually for thousands of pages is too much work :-) Doc James (talk · contribs · email) 01:49, 14 August 2016 (UTC)

OK - I've changed the default width to about 250px ( |upright=1.106 -> |upright=1.15 ). Does that fix the issue for you? You might have to clear the cache to see the new size. --RexxS (talk) 02:23, 14 August 2016 (UTC)

• At 250px Jaundice
• At 220px Gout
• The infobox does not change in size at 250px the image just takes up the fill width of the infobox which IMO looks better. Doc James (talk · contribs · email) 02:32, 14 August 2016 (UTC)

Thanks. I imagine this will take some time to roll out? Doc James (talk · contribs · email) 02:48, 14 August 2016 (UTC)

There's a further issue. The infobox in Gout looks different depending on whether I'm using monobook skin or vector - the image is the same size (230px) but on monobook it fills the width of the infobox (245px), while on vector it has gaps at each side of a wider infobox (271px). That is happening because the infobox width is set relative to the font size, which differs between monobook and vector. I'll need to look further. --RexxS (talk) 14:10, 14 August 2016 (UTC)

Part of the problem is that Gout uses a different infobox: Template:Infobox medical condition (new). I'd better change the default image size in that as well. Do you want 250px as default or do you want the 280px you have recently set it to (see e.g. Autism)? --RexxS (talk) 14:45, 14 August 2016 (UTC)

Why do we use upright for all images? IMHO it should only be added to infobox if the images are upright images. The default size for thumnails is 220px. Christian75 (talk) 15:29, 14 August 2016 (UTC)

Yes the default size for thumbnails is 220px. So how do you propose to answer Doc James' request to change the default for the infobox to 250px? As for |upright=, it lost its connection with portrait-aspect (upright) images years ago. It's now used as part of the WP:Image syntax only to set the image size relative to the default size of 220px (or whatever is set in your Preferences). --RexxS (talk) 17:30, 14 August 2016 (UTC)

Upright=1.25 is excellent. Doc James (talk · contribs · email) 17:38, 14 August 2016 (UTC)

I would answer that the size should be the default size. But right now it isn't. Compare the size of the images at e.g. Gout. The infobox image is smaller than the rest of images. Beacuse of the upright parameter used in the infobox template. Without the parameter the images would be the same size (default thumbnail size). Christian75 (talk) 17:46, 14 August 2016 (UTC) Striked out. Gout use upright for images too. How did that article get an GA status? But I still think images should be the default size. Christian75 (talk) 18:09, 14 August 2016 (UTC)

It received a GA following nomination just like all other GAs do.[20] Doc James (talk · contribs · email) 18:34, 14 August 2016 (UTC)

@Christian75: But why should the images in articles using {{Infobox medical condition}} have to be the default size for images used outside of infoboxes? When articles have a lead image and no infobox, they commonly have an image size of up to |upright=1.35 (nominally 300px wide) per Wikipedia:Picture tutorial #Thumbnail sizes. There's no reason that I can see why an infobox image shouldn't be as wide as 250px. --RexxS (talk) 18:41, 14 August 2016 (UTC)

And the infoboxes have had larger images for a long time. Doc James (talk · contribs · email) 18:46, 14 August 2016 (UTC)

NCBI has transitioned to HTTPS

Earlier this year, the NCBI site transitioned to HTTPS. Among other things, the page about the transition stated that HTTP URLs would be redirected to HTTPS equivalents. Indeed, accessing (as an example) the URL http://www.ncbi.nlm.nih.gov/books/n/gene/mma/ (where GeneReviewsID is mma) generates a 301 Moved Permanently redirect to https://www.ncbi.nlm.nih.gov/books/n/gene/mma/ instead. In the template, please change http://www.ncbi.nlm.nih.gov/books/n/gene/ to https://www.ncbi.nlm.nih.gov/books/n/gene/ instead. --Elegie (talk) 07:18, 28 November 2016 (UTC)

 Done -- John of Reading (talk) 08:12, 28 November 2016 (UTC)

MedlinePlus redirects to HTTPS URL

The template contains a URL for MedlinePlus. Accessing, for example, http://www.nlm.nih.gov/medlineplus/ency/article/000151.htm leads to a 301 Moved Permanently redirect to https://www.nlm.nih.gov/medlineplus/ency/article/000151.htm which leads to another 301 Moved Permanently redirect to https://medlineplus.gov/ency/article/000151.htm. In the template, please change http://www.nlm.nih.gov/medlineplus/ to https://medlineplus.gov/ (including the trailing slash) instead. Aside from reducing the number of redirects, using an HTTPS URL for MedlinePlus would provide increased privacy and security for users. Thanks. --Elegie (talk) 05:19, 7 December 2016 (UTC)

 Done here and in {{MedlinePlus2}} -- John of Reading (talk) 07:28, 7 December 2016 (UTC)

OMIM supports HTTPS

The OMIM site supports HTTPS. (In the source of this page, for example, there is a "Crawler Warning" comment which references HTTPS links such as https://omim.org/help/agreement and https://omim.org/contact.)Please use HTTPS for the OMIM link by changing http://omim.org/entry/ in the template to https://omim.org/entry/ instead. Thanks. --Elegie (talk) 10:10, 8 December 2016 (UTC)

Elegie I'd like to do this, but where does {{Infobox drug}} use that OMIM site? Which data row? Example article? -DePiep (talk) 11:40, 8 December 2016 (UTC)

The template where the OMIM link is used is Template:Infobox medical condition. Line 28 has the string {{#if:{{{OMIM|}}}|[http://omim.org/entry/{{{OMIM}}} in which the change should be made. --Elegie (talk) 12:56, 8 December 2016 (UTC)

•  Done [21] (Stange my text-search failed...). -DePiep (talk) 13:19, 8 December 2016 (UTC)

Black on grey is a bad idea

See for example [22] Carl Fredrik 💌 📧 04:46, 21 December 2016 (UTC)

So what do you propose? -DePiep (talk) 08:16, 21 December 2016 (UTC)

Black on light grey seems fine. Can you give an example that you think causes problems? — Martin (MSGJ · talk) 10:18, 21 December 2016 (UTC)

• The version enforced today by Carl was not properly discussed. This single link-a-site line cannot be read as an argument. I note that yesterday Carl did the same, so now I'm supposed not to revert again. -DePiep (talk) 12:34, 21 December 2016 (UTC)

Also, the editsummary by Carl claims the stable version (11 Dec) was "controversial" [23]. However, the version of Dec 11 was created by broad consensus after an open and long discussion, in which Carl participated. So I can say that that claim is incorrect, and I strongly ask Carl (again) to stop pushing damaging and unhelpful suggestions. -DePiep (talk) 12:43, 21 December 2016 (UTC)

• Comparing the color contrasts (by: the linked website):

	version 11 Dec [24]				version proposed
	demo	bg color	Contrast		demo	bg color	Contrast
title bar	Title text	#cccccc	13.08	AAA pass	Title text	#ededed	17.94	AAA pass
header bar	Header text	#eeeeee	18.1	AAA pass	Header text	#eeeeee	18.1	AAA pass

Notes:

1. Al color combinations pass as w3c AAA contrast. That is: no color combination is 'forbidden' for w3c accessability (readibility) reasons.
2. By semantics, the proposed colors are not different enough. (Semantics: the meaning of a bar, is it title or header? Our header here is the Classifications .. bar) In other words: the proposed similar greys do not show a difference between 'this is the title' vs. 'this is a header'. For this reason, the background color set must be rejected.

-DePiep (talk) 12:34, 21 December 2016 (UTC)

I can't believe you two are edit warring over colors on a high use template. I do hope it won't be necessary to fully-protect the template. The other alternative is removing user rights. Please act responsibly and no more changes without consensus. — Martin (MSGJ · talk) 13:13, 21 December 2016 (UTC)

I undid once, the undiscussed changes. Now, by the 'no more changes' you are rewarding the current, undiscussed version. You might consider reverting that one into the last consensus one (Dec 11). -DePiep (talk) 18:26, 21 December 2016 (UTC)

As User:CFCF has chosen not to participate in this discussion I have reverted to the status quo ante with regards to the color — Martin (MSGJ · talk) 17:03, 12 January 2017 (UTC)

MSGJ, I did participate and gave my reasons. I can also add that I find the dark gray color ugly when contrasted against black text. Carl Fredrik 💌 📧 17:26, 12 January 2017 (UTC)