Dans ce document nous spécifions l'organisation du modèle autour des process subis par le échantillons et les protocoles utilisés pour ces process. L'objectif est de connaitre, pour un échantillon donné, l'ensemble et la chronologie des process qu'il a subi. Dans cette perspective, il semble logique que tout traitement rentre sous cette notion de process.

A chaque échantillon est donc associé une table qui décrit les différents traitements subis par l'échantillon ainsi que l'ordre dans lequel cela a été fait. Pour chacune des étapes, donc pour chacun des protocol_application, les informations générales suivantes sont renseignées : La date du traitement, la personne qui l'a réalisé, l'index dans l'ensemble des process, le protocole (voir chapitre suivant) qui a été suivi ainsi que les éventuelles modifications faites à ce protocole.

Afin d'avoir par ce biais, l'ensemble des traitements subis par l'échantillon au cours de sa vie, il faut intégrer les données suivantes sous la notion de protocol_application :

• Run robot
• Séparation
• Acquisition
• Préparation
• Mix

Néanmoins, les demandes de passage au robot ou en masse ne sont pas considérées comme des protocol_application puisque ce sont des données non persistantes. Enfin, certains protocol_application, tel que le mix ou le run robot, ont en entré plusieurs échantillons. Par conséquent ils doivent pouvoir être associés à plusieurs treatments. L'ajout d'une table d'indirection est donc nécessaire :

Schéma du modèle associé aux traitements

Les protocoles associés aux traitements et aux process permettent de décrire leur réalisation. Les contraintes suivantes sont à considérer:

• Le protocole associé au treatments doit permettre de connaitre quels sont les étapes(protocol_application) qui doivent être réalisées
• Le protocole (ou étape de protocole) associé à un process décrit la réalisation de ce process qui peut être également divisé en plusieurs étapes.

La première idée qui consiste à définir, d'une part, les protocoles et, d'autres part, les étapes de ce protocole pose quelques problème :
Schéma du modèle version 1 associé aux protocoles

• Dans le cas ou on définit un protocol pour un treatment, on définit donc un ensemble d'étape donc des protocol_step. Il n'est pas possible de définir un enchainement de protocoles
• Si pour une étape on utilise un protocol_step que l'on souhaite ensuite détaillée, on est obligé de définir un protocol, identique à un “précédent” protocol_step….

Une solution est de ne pas définir deux niveaux mais un seul : le protocol pouvant être composé d'autres protocoles… Ainsi, quelque soit le niveau de détail auquel on souhaite aller, il sera possible pour un protocole donné de le fractionner … (voir le schéma donné dans le chapitre 'Traitements subis par l'échantillon').

Nous avons donc une table protocol_step qui décrit si un protocole est une étape d'un autre. Dans cette table “step” désigne le protocole étape et “described_protocol” le protocol dont il fait partie (le protocol
Schéma du modèle final associé au protocole

Pour un échantillon donné, sample_A, on souhaite qu'il subisse les traitements suivants : passage sur robot et acquisition en masse.

Diagramme d'instance : les protocol_application réalisés sont bien ceux demandés, donc les même protocoles sont utilisés par protocol_step et par run_robot/acquisition

A tout échantillon on associe un support. Par défaut, le support est un tube. A chaque étape de traitement d'un échantillon, il est possible que celui-ci soit déplacé d'un support à un autre. Afin de garder cette trace et de savoir sur quel support ou tout au moins quel type de support se trouve l'échantillon on définit des “transferts”. Un transfert est associé au protocol_application qui a entrainé le changement de support. Lors d'une préparation par exemple, un échantillon va passer d'un tube à un autre. (voir le schéma donné dans le chapitre 'Traitements subis par l'échantillon').

Lors d'un run robot, l'échantillon est déplacé (voire même aliquoté !) plusieurs fois. En effet, il y a d'abord un transfert du support d'origine vers un ou plusieurs puits d'une plaque. Puis à la fin du run, l'échantillon est de nouveau transféré (voire regroupé si nécessaire) dans un tube (ou support de même type que celui d'origine).

Dans le cas où le load_count est supérieur à 1 (échantillon répartit entre plusieurs puits) on aura plusieurs transfert “d'un coup” ce qui entrainera la présence dans la base de plusieurs support ayant le même rang (support_seq_rank) pour un échantillon.