Like when you say, PatientName will always be PatientName, your approach makes no sense, why would you store bindings in a database? I have never seen this before. You store the data in the database, access it using a webservice, then the client application's job is to display this data.

If you'd store binding-declarations in the db, you could very easily break your application, without any additional gain, but only problems and difficulities, starting at you essentially giving up all the tooling and debugging related to bindings, not even having any additional flexibility, since bindings cannot really change.

One approach, that if the source can change, eg. different table, I recommend creating a ViewModel representing for example the patient, that has always the same properties, and when loading your data you can just map from whichever table to the properties of that viewmodel. And then you just bind to it.

But I would not store specific mappings in the db, you should keep the schema clean and consistent, so if you have different tables being displayed by the same view, they should have the same column names. If you need to be really dynamic, you could theoretically store the whole XAML files in the db or the formulars and their fields that will generate a XAML.