Here are a few thoughts on how I try to approach solution architecture and tool selection:
I typically start with a Value Planning exercise to understand what the customers want (desired outcomes) using a discipline (combining qualitative & quantitative analysis).
The next step involves a gap analysis of capabilities mapped against the core value streams responsible for addressing the desired outcomes (via the products and services).
Next, I move on to review the processes and information needs (data, information, and knowledge) to identify opportunities for addressing the capability gaps (prior step).
This is where things get a bit complicated since we need to do detailed mapping of requirements across the models (objects, information, data, measures, process) to understand (precisely) where changes are required across all disciplines of Architecture (Business, Information, Application, and Technical). [Note: This requires Enterprise Architecture thinking and planning to ensure the solution is properly defined and the right automation decisions are made.
The example of an EHR is very complex and requires a blend set of "thinking" skills (Design, System, Lateral, Critical) to ensure the desired outcomes for the providers, practitioners, and the patients are clearly articulated and mapped against the models and artifacts throughout the development lifecycles (covering product, information, patient, system, and operations).
Note: This mapping (traceability) of desired outcomes through requirements typically starts with UML, involves use cases / scenarios, business rules, data needs, and feature decomposition across all the stakeholders and customers. This level of "Requirements Engineering" requires a high degree of discipline and oversight. Done well, it simplifies traceability, auditability, and impact analysis for planning or responding to opportunities.
Thereafter, tool selection is fairly straightforward once the above mentioned due diligence has been completed.