# Select Software/Component(s)
## 
**Select Software/Component(s)**
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](https://ohie.org/framework/) 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:
1. Ability to support the platforms that the tool runs on
2. 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.
{% hint style="success" %} 
**References:**
* [Example Tool Evaluation Sheet for Demonstration / Interview Discussion ](https://docs.google.com/document/d/19XlZHaOrixnOVO2UqvL1TkIzgK1MpNTOvkfnBWgzqxw/edit)
* [Outline for Tool Demonstration](https://docs.google.com/document/d/1szBCgu8QO4lwVFiDorhHez_iKC1kYObnLJfUzR5TpZk/edit#heading=h.pmbpp94xcyj1); [OpenHIE Reference Technologies ](https://wiki.ohie.org/display/documents/Reference+Technologies)
* [OpenHIE Architecture Specification](https://ohie.org/framework/)
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://guides.ohie.org/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/select-software-component-s.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.