Hi Josh,

I can can see that argument, but I'd say this:

1. there is no place whatsoever in an EHR view where we actually retain the full DB path as a name. In every single place I have needed to override the table/column name b/c it just makes more sense. That is fine for pre-configured, saved views; however, the on-the-fly column changes made possible by the new customize view UI still create confusing column names.

2. at least in the EHR, the name-conflict scenario is fairly rare.

3. If a user adds a column via a lookup, they are the person who did it. I think we can rely on people to have at least some understanding of the data they're looking it. Even if the column names are identical, usually data is distinct and provides information.

4. if a person is saving a view, and there is a name conflict, they can just rename one of them. it's really not the end of the world if you have 2 columns w/ the same name. I'd say this situation is more rare than a name conflict.


As noted in the above post, the full DB path name, especially without any delimiter, very rarely makes sense without some concept about the DB structure. Having the customize view UI somehow enforce distinct column names isnt a terrible idea; however, I think in practice that becomes complex when you think about: lots of complex lookups, the order in which columns are added, etc.