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
  • Establish Architecture Processes and Governance
  • Why have Architecture Processes?
  • Processes to consider
  • Audience for Architecture Processes
  1. PATHWAY 2: Architecture
  2. Pathway 2.2 - Requirements and Design

Establish Architecture Processes

Architecture Level Project

PreviousDocument the ArchitectureNextEstablish Standards

Last updated 3 years ago

Establish Architecture Processes and Governance

Why have Architecture Processes?

Unless there are processes in place to support the application and maintenance of the architecture, the designated architecture will be documentation that is placed on a shelf or used in presentations. To support the use and maintenance of the architecture, there are some processes or governance structures that need to be put in place.

Processes to consider

1. A process to support HIS project alignment with the architecture

Process to have HIS teams present or discuss their health information project with an architect, governance committee or architecture review board at project initiation and perhaps other important stages can help HIS teams align with the architecture. This process or project governance step should be structured to:

  • Ensure health project project alignment with the documented architecture principles, component and standards

  • Promote appropriate re-use existing of existing software (justification for introducing duplicative components)

Process triggers or actions that might activate this process need to be documented. These might include:

  • There is an HIS project or software project that is not yet aligned with the architecture governance process

  • A new HIS project is initiated by a funder, partner organization or any level of the health system.

  • An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software.

2. HIS Asset Inventory Update Processes

This process would ensure that the HIS project or software inventory is created and kept up to date. It may require that there are specific times when project teams or funders add items to the inventory and/or update them on a regular basis.

You may want to have a process or policy on selection of software that ensures that software aligns with the architecture and where appropriate re-uses software component investments that have already been made.

Process triggers or actions that might activate this process need to be documented. These might include:

  • There is an HIS project or software project that is not yet in the software inventory.

  • A new HIS project is initiated by a funder, partner organization or any level of the health system.

  • An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software.

  • Annual or biannual inventory update / review

3. Software Selection Process

This process would ensure that software is selected based upon a process that documents high-level business needs as well as needs for data sharing and compliance with the architecture. This process might also be designed to evaluate existing software in the inventory to see if it meets the desired needs.

Process triggers or actions that might activate this process need to be documented. These might include:

  • There is an HIS project that needs a new software component

  • A new HIS project is initiated by a funder, partner organization or any level of the health system and requires software.

  • An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software.

4. A process to review standards / update standards

To keep the standards up to date and provide a relevant and living document for project teams, it is suggested that there is some process to curate (add to / update / retire) standards and / or the architecture diagram.

Audience for Architecture Processes

When creating the architecture processes, consider the audience for the processes. The following are some key stakeholders to consider:

  • All HIS project teams creating or managing HIS software for use in capturing, processing, reporting or sharing health information in any level of the health system.

  • FMOH HITD Personnel

  • Health Architecture Governance / working group members

  • Sponsors and key stakeholders for HIS projects