The only way to do this is going to be to create either a custom entity or at least a custom table with Views integration. Views is designed to list one record per entity (or "row" of data).
Custom code solution:
Create a table that actually has multiple rows per node. It would need at least 2 fields: nid and title, and you'd have to maintain the data in that table by implementing hook_node_update, hook_node_insert, and hook_node_delete. Then you'd need to expose that data to views either by defining a custom entity type based on that table, or by writing the Views integration directly.
Field Collection Approach:
You could store your titles on another entity in the system. A Field Collection is probably the best due to the fact that it won't clutter up any other parts of the interface.
The general idea would be to add a Field Collection field (field_alternate_titles?) to your disease entity. The Field Collection itself really only needs a single field (field_alternate_titles_title?) with cardinality equal to 1. You're not using Field Collection because of its ability to let you group fields together, but rather because it creates separate entities for each of your values that you can use Views to query against. You can set the cardinality for the Field Collection field (field_alternate_titles) to 2 or, if you want to allow an arbitrary number of alternate titles, unlimited.
You could stop now and keep things really simple. Your users would have to enter all of the titles that they'd possibly want for the disease in this field. This would require them to re-enter the node title as an additional entry in the Field Collection field, but it would save you from writing any code.
If you want a slicker user experience then you would probably want to do the following:
- Hide the Field Collection field on the disease node edit form by
using the available widget type of "hidden" (rather than
"embedded"). You don't want your users seeing or touching the field
in the edit form as you'll be maintaining the values for them.
- Maintain the values in that field by implementing hook_node_presave
and creating and relating your node to Field Collection entities
according to the values entered for the node title and short title.
Whether you write the code to auto-populate the Field Collection values or not, you'll now need to build your view based on Field Collection as the base table rather than the Content (node) table. You can add a relationship to the host node entity so that you can grab whatever info you need from the node.
Search Index Approach:
Another possible approach would be to use something like Search API which maintains a separate index of your content which you can muck about with when content is sent to the index. So you could create separate index entries for every title you want to be able to search/list by. You may find it helpful to use this module as a starting point as it does denormalization, which is what you're after: https://www.drupal.org/project/search_api_grouping