Establish Architecture Processes

Architecture Level Project

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