Getting Started Guide
OHIE.orgDiscourseWikiAcademy
1.0-Beta
1.0-Beta
  • Getting Started Guide: Paths to Data Exchange
  • Select a Pathway
  • PATHWAY 1: Component and Data Exchange Projects
    • Pathway 1.1 - Governance, Value, and Scope
      • Identify Stakeholders
      • Determine and Document Roles and Responsibilities
      • Establish or Define Governance Structures
      • Determine Project Scope
      • Document the Expected Value of the Project
      • Establish a Project Plan
    • Pathway 1.2 - Requirements and Design
      • Establish Training Programs
      • Determine Resources and Identify Constraints and Environmental Factors
      • Analyze the Environment and Context
      • Identify System Constraints
      • Document Requirements
      • Select Software/Component(s)
      • Testing
    • Pathway 1.3 - Implement, Support, and Scale
      • Establish a Support Plan
      • Implement a Scalability Plan
      • Communication and Roll Out
  • PATHWAY 2: Architecture
    • Pathway 2.1 - Governance, Value, and Scope
      • Identify Stakeholders
      • Determine and Document Roles and Responsibilities
      • Establish or Define Governance Structures
      • Determine Project Scope
      • Define Value of Health System Architecture
      • Establish a Project Plan
    • Pathway 2.2 - Requirements and Design
      • Inventory Existing Tools
      • Document Use Cases
      • Establish Architecture Principles
      • Document the Architecture
      • Establish Architecture Processes
      • Establish Standards
    • Pathway 2.3 - Implement, Support, and Scale
      • Communication and Roll Out
  • How to Provide Feedback / Input
  • Change Log
Powered by GitBook
On this page
  • Select Software/Component(s)
  • 1. Landscape assessment of tools
  • 2. Narrow the list
  • 3. Assess business requirements
  • 4. Document your process
  1. PATHWAY 1: Component and Data Exchange Projects
  2. Pathway 1.2 - Requirements and Design

Select Software/Component(s)

Component Level Project and Exchange Level Project

PreviousDocument RequirementsNextTesting

Last updated 3 years ago

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 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.

References:

;

Example Tool Evaluation Sheet for Demonstration / Interview Discussion
Outline for Tool Demonstration
OpenHIE Reference Technologies
OpenHIE Architecture Specification
OpenHIE Architecture Specification