Go to AIH-HSP AI Modules

Function
Ref. Model
I/O Data
SubAIMs
JSON MData
Profiles
Ref. Software
Conformance
Performance

1 Functions

The Health Front End (AIH‑HFE) AIM enables the End User to:

  1. Register with the Health Back End.
  2. Use Health Devices to collect various types of Health Data.
  3. Provide a Model Licence to each Health Data collected.
  4. Request the Health Front End to Process AIH Data.
  5. Send AIH Data to the Health Back End.
  6. Request the Back End to Process AIH Data.

The Health Front End:

  1. Keeps AIH Data, as a combination of Model Licence and Health Data, in the Private Storage of the AIF, through the storage API of the AIF.
  2. Processes AIH Data.
  3. Adds Anomaly and Risk Alerting (ARA) Data, if present, to each AIH Data and outputs it as ARA Data.
  4. Receives requests for trained NN Models from the Health Back End.
  5. Sends its trained NN Models to the Health Back End for Federated Learning.
  6. Checks, with Watermark Extraction (NNW-WEX) of MPAI-NNW-NNT V1.2, the watermark of the NN Model in the AIM it downloads from the MPAI Store, and inserts a watermark in the NN Model, with During-Training Watermark Insertion (NNW-DWI), while the NN Model processes AIH Data and learns. These AIMs may be in its AIM Repository.

The End User owning the Front End is not bound by the Model Licence.

What the Health Front End does depends on the User Profile it ingests with the registration (6 Profiles). It sends its registration and its requests to the Health Back End, and receives the Health Back End’s answers, through External Ports: the exchange is between the Controllers of the Health Front End and of the Health Back End, which establish trust first (MPAI-AIF V3.0, Communication 9).

2 Reference Model

Figure 1 depicts the Reference Model of the Health Front End (AIH‑HFE) AIM.

Health Front End AIH-HFE AIM

Figure 1 – Reference Model of the Health Front End (AIH‑HFE) AIM

3 I/O Data

Table 1 specifies the Input and Output Data of the Health Front End (AIH‑HFE) AIM.

Table 1 – I/O Data of the Health Front End (AIH‑HFE) AIM

Input Description
Register Request End User’s request to Register.
Register Response Data in response to a request to Register.
Federated Learn Request Request to provide an NN Model.
AIH Data Process Request End User’s request to process specific AIH Data.
AIH Data Process Response Response to End User’s request to process specific AIH Data.
Health Data Data from End User’s health device.
Model Licence Data describing End User’s Licensing Terms and Conditions.
Output Description
Register Request Register Request forwarded to Health Back End.
Register Response The Health Back End’s answer to the registration, with the Tokens, given to the End User’s User Agent.
AIH Data Process Request End User’s request to process specific AIH Data forwarded to Health Back End.
AIH Data Process Response Response to End User’s request to process specific AIH Data.
Federated Learn Response Response to the request to provide an NN Model.
ARA Data Alerts of Anomaly and Risk Alerting on the AIH Data.

4 SubAIMs

4.1 Reference Model

Figure 2 depicts the Reference Model of the Health Front End (AIH‑HFE) Composite AIM.

Health Front End AIH-HFE Composite AIM

Figure 2 – Reference Model of the Health Front End (AIH‑HFE) Composite AIM

4.2 Operation

The AIH‑HFE AIM operation develops as follows:

  1. End User registers with HFE and HBE.
  2. End User acquires Health Data with a Health Device.
  3. End User attaches Model Licence to Health Data.
  4. Model Licensing produces AIH Data (including Health Data and Model Licence), which AIH Data Processing keeps in the Private Storage of the AIF.
  5. End User processes AIH Data locally.
  6. End User stores AIH Data to HFE.
  7. End User processes AIH Data remotely.
  8. HFE downloads from the MPAI Store the AIM that contains the watermarked NN Model and checks the watermark with Watermark Extraction (NNW-WEX).
  9. While the NN Model processes AIH Data and learns, During-Training Watermark Insertion (NNW-DWI) inserts the watermark in it.
  10. HFE receives Federated Learn request.
  11. HFE sends to HBE the AIM that contains the trained and watermarked NN Model.

4.3 Functions of SubAIMs

Table 2 specifies the functions of the Health Front End (AIH‑HFE) SubAIMs.

Table 2 – Functions of the Health Front End (AIH‑HFE) SubAIMs

SubAIM Function
Model Licensing Adds Model Licence to Health Data.
AIH Data Processing Processes AIH Data.
Anomaly and Risk Alerting Discovers anomalies and signals risks in AIH Data.

4.4 I/O Data of SubAIMs

Table 3 gives the Input and Output Data of the Health Front End (AIH‑HFE) SubAIMs.

Table 3 – I/O Data of the Health Front End (AIH‑HFE) SubAIMs

SubAIM Input Output
Model Licensing Health Data
Model Licence		 AIH Data
AIH Data Processing Federated Learn Request
AIH Data Process Request
AIH Data Process Response
AIH Data
ARA Data
Register Request
Register Response		 Federated Learn Response
AIH Data Process Request
AIH Data Process Response
AIH Data
Register Request
Register Response
Anomaly and Risk Alerting AIH Data ARA Data

4.5 AIMs and JSON Metadata

Table 4 provides the links to the AIM specifications and JSON schemas. AIM1 indicates the Composite AIM and AIM2 its SubAIMs.

Table 4 – AIMs and JSON Metadata of the Health Front End (AIH‑HFE)

AIM1 AIM2 Name JSON
AIH‑HFE Health Front End X
AIH‑MDL Model Licensing X
AIH‑HDP AIH Data Processing X
AIH‑ARA Anomaly and Risk Alerting X

5 JSON Metadata

https://schemas.mpai.community/AIH1/V1.1/AIMs/HealthFrontEnd.json

6 Profiles

There is one Health Front End. What it does depends on the User Profile it ingests with the registration. The two Profiles below are defined here; they are not Profiles in the sense of MPAI-PRF.

  1. End User Profile: a User Profile of an individual. The Health Front End makes the End User’s AIH Data from the Health Data and the Model Licence, keeps it in the Secure Data Vault, discovers anomalies and signals risks, trains on it when the Health Back End asks, and has the Health Back End keep, process, de-identify, anonymise and audit it. It works on the End User’s AIH Data only, which needs no control of the Model Licence.
  2. Third-Party User Profile: a Third-Party User Profile, or a User Profile of an individual who is a member of an organisation (Membership). The Health Front End makes and keeps no AIH Data and does not train. It asks the Health Back End to process AIH Data, as the Model Licence of each AIH Data prescribes. A request to store, de-identify, anonymise or audit is refused.

7 Reference Software

Under development.

8 Conformance Testing

Table 5 provides the Conformance Testing Method for the Health Front End (AIH‑HFE) AIM. Conformance Testing of the individual SubAIMs is given by the individual AIM specifications.

If a schema contains references to other schemas, conformance of data for the primary schema implies that any data referencing a secondary schema shall also validate against the relevant schema, if present, and conform with the Qualifier, if present.

Table 5 – Conformance Testing Method for the Health Front End (AIH‑HFE) AIM

Receives Register Request Shall validate against Register schema.
Register Response Shall validate against Register schema.
Federated Learn Request Shall validate against Federated Learn schema.
AIH Data Process Request Shall validate against AIH Data Process schema.
AIH Data Process Response Shall validate against AIH Data Process schema.
Health Data Shall validate against Health Data schema.
Model Licence Shall validate against Model Licence schema.
Produces Register Request Shall validate against Register schema.
Register Response Shall validate against Register schema.
AIH Data Process Request Shall validate against AIH Data Process schema.
AIH Data Process Response Shall validate against AIH Data Process schema.
Federated Learn Response Shall validate against Federated Learn schema.
ARA Data Shall validate against ARA Data schema.

9 Performance Assessment

Not part of this specification.

Go to AIH-HSP AI Modules