[DOCS] Health AI Suite - Release Notes article (open-edge-platform#1886)

Co-authored-by: Wiktor Iwaszko <wiktorx.iwaszko@intel.com>

Author: kblaszczak-intel

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/README.md

@@ -1,4 +1,4 @@
-## Initial Application: Multi-Modal Patient Monitoring
+# Initial Application: Multi-Modal Patient Monitoring
 
 The Multi-Modal Patient Monitoring application helps medical AI developers and systems engineers at medical OEMs/ODMs (GE Healthcare, Philips, Mindray) evaluate Intel® Core™ Ultra processors for AI‑enabled patient monitoring. It demonstrates that you can run **multiple AI workloads concurrently on a single Intel‑powered edge device** without a discrete GPU.
 
@@ -15,29 +15,26 @@ The solution is intended to:
 
 - Showcase multi‑modal AI capabilities of Intel Core Ultra
 - Run on Ubuntu 24.04 with containerized workloads
-- Be startable with a **single command** from a clean system
-	(end‑to‑end setup and launch targeted in ≤ 30 minutes)
+- Be startable with a **single command** from a clean system (end‑to‑end setup and launch targeted in ≤ 30 minutes)
 
 Secure provisioning (for example, Polaris Peak integration) is not part of the initial implementation, but the architecture is intended to be extensible for future security integrations.
 
----
 ## Get Started
 
 To see the system requirements and other installations, see the following guides:
 
 - [Get Started](./docs/user-guide/get-started.md): Follow step-by-step instructions to set up the application.
-- [System Requirements](./docs/user-guide/system-requirements.md): Check the hardware and software requirements for deploying the application.
+- [System Requirements](./docs/user-guide/get-started/system-requirements.md): Check the hardware and software requirements for deploying the application.
 - [Run the application](./docs/user-guide/run-multi-modal-app.md): Run Multi-Modal Patient Monitoring application.
 
 ## How It Works
 
 At a high level, the system is composed of several microservices that work together to ingest patient signals and video, run AI models on Intel hardware (CPU, GPU, and NPU), aggregate results, and expose them to a UI for clinicians.
 
-![System design](./_assets/system-design.png)
+![System design](./docs/user-guide/_assets/system-design.png)
 
 ## Learn More
 
-For detailed information about system requirements, architecture, and how the application works, see the 
-
--  [Full Documentation](docs/user-guide/index.md)
+For detailed information about system requirements, architecture, and how the application works, see the
 
+- [Full Documentation](./docs/user-guide/index.md)

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/docs/user-guide/get-started.md

@@ -14,7 +14,6 @@ ensure your environment meets the recommended hardware and software prerequisite
 
 If you have not already cloned the repository that contains this workload, do so now:
 
-
 ```bash
 git clone --no-checkout https://github.com/open-edge-platform/edge-ai-suites.git
 
@@ -44,7 +43,7 @@ To configure these:
 1. Open `configs/device.env` in a text editor.
 2. Locate the entries for `ECG_DEVICE`, `RPPG_DEVICE`, `MDPNP_DEVICE`, and `POSE_3D_DEVICE`.
 3. Set each to the appropriate device string supported on your system (typically `CPU` or
-`GPU`, and `NPU` where available and supported).
+   `GPU`, and `NPU` where available and supported).
 
 When you run `make run` or `make run REGISTRY=false`, the compose file reads
 `configs/device.env` and passes these values into the corresponding services so that each
@@ -102,9 +101,9 @@ The rPPG service provides a simple HTTP control API (hosted by an internal FastA
 start and stop streaming:
 
 - **Start streaming:**
-	- Send a request to the `/start` endpoint on the rPPG control port (default 8084).
+  - Send a request to the `/start` endpoint on the rPPG control port (default 8084).
 - **Stop streaming:**
-	- Send a request to the `/stop` endpoint on the same port.
+  - Send a request to the `/stop` endpoint on the same port.
 
 Exact URLs and endpoints may differ slightly depending on how the control API is exposed in
 your environment; refer to the rPPG service documentation for details.
@@ -116,14 +115,14 @@ the `metrics` directory on the host, and may also expose summarized metrics via
 
 - Inspect raw logs under the `metrics` directory mounted in the compose file.
 - Combine these metrics with the rPPG output and UI dashboards to evaluate accelerator
-utilization and end‑to‑end performance.
+  utilization and end‑to‑end performance.
 
 ## Next Steps
 
 - Learn more about [How It Works](./how-it-works.md) for a high-level architectural overview.
 - Experiment with different `RPPG_DEVICE` values to compare CPU, GPU, and NPU behavior.
 - Replace the sample video or models with your own assets by updating the `models` and `videos`
-volumes and configuration.
+  volumes and configuration.
 
 <!--hide_directive
 :::{toctree}

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/docs/user-guide/get-started/system-requirements.md

@@ -10,94 +10,91 @@ This section lists the hardware, software, and network requirements for running
 ## Hardware Requirements
 
 - **CPU:**
-	- 4 physical cores (8 threads) or more recommended.
-	- x86_64 architecture with support for AVX2.
+  - 4 physical cores (8 threads) or more recommended.
+  - x86_64 architecture with support for AVX2.
 
 - **System Memory (RAM):**
-	- Minimum: 16 GB.
-	- Recommended: 32 GB for smoother multi‑service operation and development work.
+  - Minimum: 16 GB.
+  - Recommended: 32 GB for smoother multi‑service operation and development work.
 
 - **Storage:**
-	- Minimum free disk space: 30 GB.
-	- Recommended: 50 GB+ to accommodate Docker images, models, logs, and metrics.
+  - Minimum free disk space: 30 GB.
+  - Recommended: 50 GB+ to accommodate Docker images, models, logs, and metrics.
 
 - **Graphics / Accelerators:**
-	- Required: Intel CPU.
-	- Optional (recommended for full experience):
-		- Intel integrated GPU supported by Intel® Graphics Compute Runtime.
-		- Intel NPU supported by the linux‑npu‑driver stack.
-	- The host must expose GPU and NPU devices to Docker, for example:
-		- `/dev/dri` (GPU)
-		- `/dev/accel/accel0` (NPU)
+  - Required: Intel CPU.
+  - Optional (recommended for full experience):
+    - Intel integrated GPU supported by Intel® Graphics Compute Runtime.
+    - Intel NPU supported by the linux‑npu‑driver stack.
+  - The host must expose GPU and NPU devices to Docker, for example:
+    - `/dev/dri` (GPU)
+    - `/dev/accel/accel0` (NPU)
 
 ## Software Requirements
 
 - **Docker and Container Runtime:**
-	- Docker Engine 24.x or newer.
-	- Docker Compose v2 (integrated as `docker compose`) or compatible compose plugin.
-	- Ability to run containers with:
-		- `--privileged` (for metrics‑collector).
-		- Device mappings for GPU/NPU (for rPPG and metrics‑collector).
+  - Docker Engine 24.x or newer.
+  - Docker Compose v2 (integrated as `docker compose`) or compatible compose plugin.
+  - Ability to run containers with:
+    - `--privileged` (for metrics‑collector).
+    - Device mappings for GPU/NPU (for rPPG and metrics‑collector).
 
 - **Python (for helper scripts and tools):**
-	- Python 3.10 or newer recommended.
-	- Used primarily for asset preparation scripts and local tooling; application containers
-	include their own Python runtimes (for example, Python 3.12 in the rPPG service image).
-
+  - Python 3.10 or newer recommended.
+  - Used primarily for asset preparation scripts and local tooling; application containers
+    include their own Python runtimes (for example, Python 3.12 in the rPPG service image).
 
 - **Git and Make:**
-	- `git` for cloning the repository and managing submodules.
-	- `make` to run provided automation targets (e.g., `make run`, `make init-mdpnp`).
+  - `git` for cloning the repository and managing submodules.
+  - `make` to run provided automation targets (e.g., `make run`, `make init-mdpnp`).
 
 ## AI Models and Workloads
 
 The application bundles several AI workloads, each with its own model(s) and inputs/outputs:
 
 - **RPPG (Remote Photoplethysmography) Workload:**
-	- **Model:** MTTS‑CAN (Multi‑Task Temporal Shift Convolutional Attention Network)
-	converted to OpenVINO IR (`/models/rppg/mtts_can.xml`).
-	- **Input:** Facial video frames (RGB) from the shared `videos` volume.
-	- **Output:** Pulse and respiration waveforms, heart rate (HR) in BPM, and respiratory
-	rate (RR) in BrPM.
-	- **Target devices:** Intel CPU, Intel integrated GPU, or Intel NPU via OpenVINO
-	(`RPPG_DEVICE`).
+  - **Model:** MTTS‑CAN (Multi‑Task Temporal Shift Convolutional Attention Network)
+    converted to OpenVINO IR (`/models/rppg/mtts_can.xml`).
+  - **Input:** Facial video frames (RGB) from the shared `videos` volume.
+  - **Output:** Pulse and respiration waveforms, heart rate (HR) in BPM, and respiratory
+    rate (RR) in BrPM.
+  - **Target devices:** Intel CPU, Intel integrated GPU, or Intel NPU via OpenVINO
+    (`RPPG_DEVICE`).
 
 - **3D‑Pose Estimation Workload:**
-	- **Model:** `human-pose-estimation-3d-0001` from Open Model Zoo, converted to OpenVINO
-	IR (`/models/3d-pose/human-pose-estimation-3d-0001.xml`).
-	- **Input:** RGB video of a person in motion (`face-demographics-walking.mp4` under
-	`/videos/3d-pose` has been provided for demonstration purposes).
-	- **Output:** 3D human keypoints and pose estimation, streamed to the aggregator for
-	visualization.
-	- **Target devices:** Intel CPU and GPU via OpenVINO.
+  - **Model:** `human-pose-estimation-3d-0001` from Open Model Zoo, converted to OpenVINO
+    IR (`/models/3d-pose/human-pose-estimation-3d-0001.xml`).
+  - **Input:** RGB video of a person in motion (`face-demographics-walking.mp4` under
+    `/videos/3d-pose` has been provided for demonstration purposes).
+  - **Output:** 3D human keypoints and pose estimation, streamed to the aggregator for
+    visualization.
+  - **Target devices:** Intel CPU and GPU via OpenVINO.
 
 - **AI‑ECG Workload:**
-	- **Models:** OpenVINO IR models for ECG rhythm classification located under
-	`/models/ai-ecg`, for example:
-		- `ecg_8960_ir10_fp16.xml`
-		- `ecg_17920_ir10_fp16.xml`
-	- **Input:** Preprocessed multi‑lead ECG time‑series segments of supported lengths (e.g.,
-	8960 or 17920 samples).
-	- **Output:** Rhythm classification labels (e.g., Normal sinus rhythm, Atrial Fibrillation,
-	Other rhythm, or Too noisy to classify) with associated waveforms and timings.
-	- **Target devices:** Intel CPU, GPU, or other OpenVINO‑supported devices configured via `ECG_DEVICE`.
+  - **Models:** OpenVINO IR models for ECG rhythm classification located under
+    `/models/ai-ecg`, for example: - `ecg_8960_ir10_fp16.xml` - `ecg_17920_ir10_fp16.xml`
+  - **Input:** Preprocessed multi‑lead ECG time‑series segments of supported lengths (e.g.,
+    8960 or 17920 samples).
+  - **Output:** Rhythm classification labels (e.g., Normal sinus rhythm, Atrial Fibrillation,
+    Other rhythm, or Too noisy to classify) with associated waveforms and timings.
+  - **Target devices:** Intel CPU, GPU, or other OpenVINO‑supported devices configured via `ECG_DEVICE`.
 
 ## Network and Proxy
 
 - **Network Access:**
-	- Local network connectivity to access the UI (default: `http://<HOST_IP>:3000`).
-	- Optional outbound internet access to download Docker base images, models, and assets
-	(if not pre‑cached).
+  - Local network connectivity to access the UI (default: `http://<HOST_IP>:3000`).
+  - Optional outbound internet access to download Docker base images, models, and assets
+    (if not pre‑cached).
 
 - **Proxy Support (optional):**
-	- If your environment uses HTTP/HTTPS proxies, configure:
-		- `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` in the shell before running `make`.
-	
+  - If your environment uses HTTP/HTTPS proxies, configure:
+    - `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` in the shell before running `make`.
+
 ## Permissions
 
 - Ability to run Docker as a user in the `docker` group or with `sudo`.
 - Sufficient permissions to access device nodes for GPU and NPU (typically via membership in
-groups such as `video` or via explicit `devices` configuration in Docker Compose).
+  groups such as `video` or via explicit `devices` configuration in Docker Compose).
 
 ## Browser Requirements
 

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/docs/user-guide/how-it-works.md

@@ -26,11 +26,11 @@ The **patient-monitoring-assets** service is responsible for preparing all AI as
 by the workload:
 
 - Downloads or generates AI models (for example, the MTTS‑CAN model used by the rPPG service)
-and converts them to OpenVINO IR format.
+  and converts them to OpenVINO IR format.
 - Downloads reference video assets and places them in shared volumes (for example, the `videos`
-volume consumed by rPPG).
+  volume consumed by rPPG).
 - Writes models into a shared `models` volume, making them available to downstream services
-without embedding them directly in each container.
+  without embedding them directly in each container.
 
 This service typically runs to completion at startup and then exits once all artifacts are
 prepared.
@@ -40,10 +40,10 @@ prepared.
 The **patient-monitoring-aggregator** service is the central gRPC endpoint for vital signs:
 
 - Exposes gRPC APIs that accept waveform and numeric vitals from producer services such as
-rPPG.
+  rPPG.
 - Maintains per‑patient (or per‑device) state, including time‑series histories of vitals.
 - Computes or stores aggregated metrics that can be consumed by the UI or other downstream
-components.
+  components.
 
 In the default configuration, the aggregator listens on a gRPC port (for example, 50051) and
 is reachable by all AI producer services over the host network.
@@ -53,15 +53,15 @@ is reachable by all AI producer services over the host network.
 The rPPG service performs remote photoplethysmography on patient video streams to estimate heart rate (HR) and respiratory rate (RR):
 
 - **Video ingestion:** Reads frames from the shared `videos` volume (for example, `sample.mp4`)
-using `VideoHandler`, with optional looping and frame‑rate adaptation.
+  using `VideoHandler`, with optional looping and frame‑rate adaptation.
 - **Preprocessing:** Crops a region of interest (ROI) on the face and resizes frames to the
-model input size using `Preprocessor`. Frames are accumulated into batches.
+  model input size using `Preprocessor`. Frames are accumulated into batches.
 - **AI inference:** Runs the MTTS‑CAN OpenVINO model using the `InferenceEngine`, targeting
-Intel GPU or NPU (`RPPG_DEVICE`) with automatic fallback to CPU when needed.
+  Intel GPU or NPU (`RPPG_DEVICE`) with automatic fallback to CPU when needed.
 - **Post‑processing:** Converts raw model output into pulse and respiration waveforms and
-derives numeric HR and RR estimates using `SignalPostprocessor`.
+  derives numeric HR and RR estimates using `SignalPostprocessor`.
 - **Streaming to aggregator:** Packages results into waveform and numeric vitals and streams
-them to the patient‑monitoring‑aggregator via the `RPPGGRPCClient`.
+  them to the patient‑monitoring‑aggregator via the `RPPGGRPCClient`.
 
 The rPPG service also exposes a small HTTP control API to start/stop streaming, allowing dynamic control during demos or testing.
 
@@ -71,11 +71,11 @@ The **metrics-collector** service gathers hardware and system metrics from the h
 observability of AI workloads:
 
 - Runs in a privileged container with access to host devices (for example, `/dev/dri`,
-`/dev/accel/accel0`) and system paths under `/sys` and `/proc`.
+  `/dev/accel/accel0`) and system paths under `/sys` and `/proc`.
 - Collects GPU, NPU, CPU, memory, and power statistics from telemetry tools and kernel
-interfaces.
+  interfaces.
 - Writes raw logs (for example, qmassa JSON and NPU CSV) into a shared metrics directory, and
-can expose summarized metrics via its own API.
+  can expose summarized metrics via its own API.
 
 These metrics are useful for validating that AI workloads are correctly utilizing Intel
 accelerators and for performance benchmarking.
@@ -86,7 +86,7 @@ The **ui** service provides a web‑based dashboard for clinicians or developers
 
 - Connects to the patient‑monitoring‑aggregator to retrieve current and historical vitals.
 - Visualizes waveforms (e.g., pulse and respiration) and numeric vitals (e.g., HR, RR) in real
-time.
+  time.
 - May also integrate system‑level metrics from the metrics‑collector to show hardware utilization alongside clinical signals.
 
 The UI is typically exposed on a configurable HTTP port (for example, 3000) and accessed via a standard web browser.
@@ -96,14 +96,14 @@ The UI is typically exposed on a configurable HTTP port (for example, 3000) and
 Putting the pieces together:
 
 1. **Assets initialization** – patient-monitoring-assets populates the shared `models` and
-`videos` volumes.
+   `videos` volumes.
 2. **RPPG inference** – the rPPG service reads video frames, preprocesses them, and runs the
-MTTS‑CAN model on Intel hardware (CPU/GPU/NPU) via OpenVINO.
+   MTTS‑CAN model on Intel hardware (CPU/GPU/NPU) via OpenVINO.
 3. **Vitals aggregation** – rPPG streams waveform and numeric vitals to
-patient-monitoring-aggregator over gRPC.
+   patient-monitoring-aggregator over gRPC.
 4. **Monitoring and observability** – metrics-collector continuously records hardware
-utilization and other system metrics.
+   utilization and other system metrics.
 5. **Visualization** – the UI queries the aggregator (and optionally metrics endpoints) to
-present vitals and system status to end‑users.
+   present vitals and system status to end‑users.
 
 This modular architecture allows each component to be developed, deployed, and scaled independently while sharing common assets and infrastructure.

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/docs/user-guide/index.md

@@ -17,27 +17,27 @@ consolidated monitoring for a virtual patient.
 It combines several AI services:
 
 - **rPPG (Remote Photoplethysmography):** Contactless heart and respiratory rate estimation
-from facial video.
+  from facial video.
 - **3D-Pose Estimation:** 3D human pose detection from video.
 - **AI-ECG:** ECG rhythm classification from simulated ECG waveforms.
 - **MDPNP:** Getting metrics of three simulated devices such as ECG, BP and CO2
 - **Patient Monitoring Aggregator:** Central service that collects and aggregates vitals from
-all AI workloads.
+  all AI workloads.
 - **Metrics Collector:** Gathers hardware and system telemetry (CPU, GPU, NPU, power) from
-the host.
+  the host.
 - **UI:** Web-based dashboard for visualizing waveforms, numeric vitals, and system status.
 
 Together, these components illustrate how vision- and signal-based AI workloads can be orchestrated, monitored, and visualized in a clinical-style scenario.
 
 ## Supporting Resources
 
 - [Get Started](./get-started.md) – Step-by-step instructions to build and run the application
-using `make` and Docker.
+  using `make` and Docker.
 - [System Requirements](./get-started/system-requirements.md) – Hardware, software, and network requirements, plus an overview of the AI models used by each workload.
 - [How It Works](./how-it-works.md) – High-level architecture, service responsibilities, and
-data/control flows.
+  data/control flows.
 
-> This application is provided for development and evaluation purposes only and is *not* intended for clinical or diagnostic use.
+> This application is provided for development and evaluation purposes only and is _not_ intended for clinical or diagnostic use.
 
 <!--hide_directive
 :::{toctree}
@@ -46,6 +46,7 @@ data/control flows.
 get-started.md
 how-it-works.md
 run-multi-modal-app.md
+release-notes.md
 
 :::
 hide_directive-->

health-and-life-sciences-ai-suite/multi_modal_patient_monitoring/docs/user-guide/release-notes.md

@@ -0,0 +1,16 @@
+# Release Notes - Multi-modal Patient Monitoring
+
+## Version 1.0.0
+
+**Release Date**: 2026-03-25
+
+This is the initial release of the application, therefore, it is considered a preview version.
+
+### New
+
+The initial feature set of the application is now available:
+
+- monitoring heart and respiratory rates
+- Integration with medical devices
+- Pose estimation with joint tracking
+- ECG analysis with 12-lead classification