Select Software/Component(s)
Component Level Project and Exchange Level Project
Based upon the requirements documented, your team will need to evaluate and select software solutions. When selecting software, it is important to understand the current state of your eHealth architecture. If there is an architecture in place, you will want to select a solution that aligns with the architecture or the future direction of the architecture.
We recommend documenting a high-level process to follow. The following steps may be helpful:
1. Landscape assessment of tools
This can be done through a landscape assessment to determine the tools that are out in the field and how they align with your strategy. You may want to categorize in a meaningful way that helps you think about the field. One example is to use a two-by-two grid to help categorize the tools in some way.
General Use, High Initial Investment | Health Specific Use, High Initial Investment |
General Use, Low Initial Investment | Health Specific Use, Low Initial Investment |
2. Narrow the list
Narrow the list of possible tools to ones that align with your strategy and architecture. Look at factors such as your ability to support the underlying technology, the maturity of the tool / references from other projects / deployment strategies, ability to support your security needs, ability to support data exchanges and standards and your contextual needs to narrow the list to tools you will evaluate more closely. Document the criteria you used to narrow the field as this may be needed to support your decision or if suitable tools are not found in further review stages. Methods for helping narrow might be looking at their websites, sending some email questions and / or having a quick phone conversation.
3. Assess business requirements
Once you have chosen a few tools to look at more closely, you will need to have a list of high -level business requirements and needs for the tool assessment. We recommend having the tool creator to demonstrate and / or sketch out how they would tackle one of your business challenges (use cases) to allow your team to make an effective evaluation. The OpenHIE Architecture Specification contains a list of based component requirements as well as data exchange requirements for each of the architecture components. You may want to use this as a base for documenting the requirements for the components that you’ll need.
You’ll want to think about the following when looking at the available tools:
Ability to support the platforms that the tool runs on
Ability to support and deploy the tool
4. Document your process
We recommend documenting your selection process and the results of the process so that you can communicate the reasoning for the decision.
You will want to complete some type of an evaluation process for each of the components you need to select.
Last updated
