Most readers of this blog have some experience with designing applications. Applications are easy. You just have to account for the different ways people are going to use them.
Designing standards is a little bit different. When you design a standard, you have to take into account for the uses to which many different applications will put the standard. It requires a lot more flexibility to deal with issues, yet rigidity (because standards shouldn't be too flexible). You have to allow for cases where, for example, race and ethnicity are strongly encouraged data elements for capture (e.g., as in the US), and also for cases where it is illegal to capture and report them (e.g., as in some countries in the EU).
When you go a step further, as IHE does, in developing profiles which use multiple standards, it gets even more complex. Here, you have to work out how to solve challenging impedance matching problems between different standards that take on different roles in the environment, sometimes bending or warping things a bit as you go.
After building several profiles, you start to think like the toy maker Lego, or perhaps the A.C. Gilbert company. You'll probably have some of your favorite components that you wind up using (I prefer Lego Technic for building toys), but others have their favorites too, and eventually, you are going to have to hook them together.
I just wish there was something like this universal adapter brick for IT standards:
Or better yet, the IT standards equivalent of a 3D printer through which I could build such an adapter.
Yes, we have interface engines. They are trying to take on that role. But I could also have just put the period after the third word of that last sentence.