# Document the Architecture

## <img src="https://3308277642-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MaFTi2cXYF3MOUIP8lR%2F-MeQAtSh-tYl-ykSPgMz%2F-MeQFKJY93qQnWxH0Zk9%2Fdocument-folder.svg?alt=media&#x26;token=032fcb9d-6208-4360-bcb5-b0e8ad2b6e60" alt="" data-size="line"> Document the Architecture

### Content to Consider&#x20;

When developing your health architecture, you may want to consider including the following content: &#x20;

* Information about the health system context&#x20;
  * You may want to include linkages to key health system documents or priorities
* [Architecture principles](https://guides.ohie.org/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-principles)
* Architecture diagram / components&#x20;
  * you may want to reference the OpenHIE Architecture here. &#x20;
* [Standards](https://guides.ohie.org/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-processes) or a reference to standards&#x20;
  * Consider of the data exchange standards and / or terminology standards are stored in the Architecture document, an appendix or a separate standards document. &#x20;
* Guidelines for application may be included in the architecture or other documentation for health information teams to follow.  These may include expectations such as: &#x20;
  1. Project teams must create documentation of system assets (for example, requirements, design, installation process)
  2. Applications that share data must/should have APIs
  3. Application purchases or selection must be done via an evaluation process where the criteria and decision are documented
  4. Applications should be designed in a way that support data standards&#x20;
  5. Any source code developed specifically for MOH should be stored in the MOH source code repository
  6. &#x20;Interoperability layer should be used for data exchange (No new point-to-Point)
  7. Project teams must complete an HIS project Alignment (processes outlined in this document)&#x20;
  8. Additional guidelines...

The following are some examples of how the architecture has been documented. &#x20;

{% hint style="success" %} <img src="https://3308277642-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MaFTi2cXYF3MOUIP8lR%2F-Me6FCaymA0hPSnuCVe3%2F-Me6G6QqCYm4wLGJYCDm%2Fbook.png?alt=media&#x26;token=41c72f52-4856-49b2-a201-07e2ca52e137" alt="" data-size="line"> **References:**

* [Kenya Health Architecture ](https://www.data4sdgs.org/sites/default/files/services_files/Kenya%20Health%20Information%20Systems%20Interoperability%20Framework.pdf)
* [Tanzania 2012-2018 Strategy](https://www.who.int/goe/policies/countries/tza_ehealth.pdf)
* [Uganda](https://health.go.ug/sites/default/files/National%20e_Health%20Strategy_0.pdf)
  {% 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-2-architecture/phase-2-requirements-and-design/document-the-architecture.md?ask=<question>
```

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.