Edit: Not a doctor/in health care. Just basing this on the link above.

Of these links, there are four duplicate pairs, at least. Two of these sets of pairs lead to indistinctly named pages (/Home/InteroperabilityGuide and /Home/Interoperate)

I would start by having all of these links be at the top, and adding some descriptive text to each of the fields in the main body, as opposed to meaningless graphics/marketing numbers.

Addendum: Also, I wouldn't want to do the split in thirds thing that occupies the majority of the page. Each of those can get a description of at least a paragraph, and go one after the other. If there's not enough info to fill a paragraph, then they probably need to be merged.

Edit: ambiguously -> indistinctly

There's a legitimate case for high-density, specialized interfaces that aren't focused on usability in the sense that you might find in more consumer-targeted software: the end users of these systems don't necessarily need something that's easy to learn or that presents only important info up front. Arguably they need the opposite: something that packs a lot of complex functionality and dense information into a small space is _good_ when your users are highly-specialized and frequently run through similar complex workflows. It's akin to a phone camera interface and a camera designed for professional photographers: the former eschews having ALL THE THINGS for accessibility, whereas the latter eschews accessibility for high info density and rapid access to tools because its users are okay putting in the time to learn something complex when getting over the learning curve will afford them a high degree of control and quick feedback.

Where things break down is customizability: expert tools, and especially expert software tools, suffer from "the user knows best, they can design their own UX" syndrome: this is true to a degree, but in the case of shared tools oft turns into one user (team lead X, who's been doing this shit for years! they know their shit!) designing something that works for them, or that replicates an existing workflow from elsewhere (just make it EXACTLY like the old paper charts! why would you do anything else? what do you mean the design considerations for a paper system might not perfectly transfer to a computer system?) in total ignorance of things they fail to do well. Computer systems, I think as an artifact of their relative novelty, lead users to believe they're experts in UX design by virtue of having (a) experience in the field the system serves and (b) having used a computer interface at some point in the past (and, in America, (c), broader cultural hubris about individual competency across disciplines based on competency in some unrelated highly-skilled field). Designing a truly good interface requires a dialog between user and designer, but we too often tend towards a "skilled user must be right, they're good at SOMETHING and therefore good at EVERYTHING" mindset. Enterprise software design provides customizability to a fault--we hear users want it, don't have enough time to actually sit down and try workflows with them, and they say they're skilled enough to do it themselves independently, so let em have at it.

I sometimes wonder what it'd be like in a world where "cars" were sold to ENTERPRISE DRIVING CABALS, full of VERY SKILLED DRIVERS, where the "car" in question ended up being a pile of sheet metal and control surfaces, a collection of engine and power train components, a big tub of asphalt, and a rough map of places people need to go, entrusted to a multitude of very experienced horse carriage drivers who each sought out to build their own bespoke personal vehicles and interstate highway system as they saw fit based on their own intuition and cunning, with nary a notion of needing to design something that worked for anyone else or wanting to take advantage of the new tech's more novel features. I doubt it would be a good one, but it would probably be hilarious to look at having driven on a somewhat saner system in a more thoughtfully designed vehicle.