PHT Architecture Components

The Tübingen implementation of the PHT has several central services which are used to submit, control and execute trains. Our current implementation relies on the manual acceptance of each train before it can be executed at a hospital. Details regarding our implementation are described below. 

Overall worflow

  1. User is redirected to associated hospital local IAM
  2. Send Auth Code to UI
  3. Exchange Auth code for access token
  4. Sign hash from files during train submission
  5. UI sends building message to Message Broker
  6. Train Builder receives message queue
  7. Post route of train to Vault
  8. Receive public keys of stations
  9. Build train and push in incoming repository
  10. Send event for incoming train
  11. Publish train event to Train Router
  12. Receive route of train in Vault
  13. Move trains according to route and execution status
  14. Pull image
  15. Execute train at station locally
  16. Push executed train with encrypted results
  17. Result service receives executed trains
  18. Extract encrypted results
  19. Decrypt results locally
PHT Submission

Central User Interface and train submission​

Execution at stations

The execution of a train is separated in 3 Phases:

  • Security pre_run protocol
  • Train execution
  • Security post_run protocol

During first phase a validation check for manipulation of the algorithms and decryption of the model with envelope encryption is made. The run phase executes the train image including all software requirements wrapped within the container to run the algorithm at one station. The third and last phase encrypts the train results and prepares the train for the departure. Only encrypted results are hosted centrally and must be decrypted locally. The execution (currently using the airflow interface) of a train can be seen in the video on the right.

Download results and decryption