Syrius : Système de recueil de l'information des urgences

Table des matières

Système de recueil d'information des urgences 2

1. Présentation générale du projet de remontées des RPU. 2

2. Mise en place du dispositif 2

3. Contenu des RPU. 2

4. Organisation régionale du dispositif 3

5. Plateforme Syrius 3

6. Manuel d'utilisation de l'application Syrius 3

Circuits des remontées des données. 4

Use cases. 4

Transitions d'état 5

Workflow. 5

Exemples de code. 7

Java. 7

PHP. 9

Le code retour du service upload. 10

Format des données. 10

Comment procéder pour l'envoi des données vers l'application Syrius (ATIH) 16

Obtenir un compte Plage. 16

Fournir de la liste des ES de votre région. 18

Présentation de Syrius. 18

Support utilisateurs. 18

 

 

Système de recueil d'information des urgences

1. Présentation générale du projet de remontées des RPU

L’arrêté du 24 juillet 2013 relatif au recueil et au traitement des données d'activité médicale produites par les établissements de santé publics ou privés ayant une activité de médecine d’urgence et à la transmission d'informations issues de ce traitement dans les conditions définies à l'article L.6113-8 du code de la santé publique et dans un but de veille et de sécurité sanitaires a rendu obligatoire la transmission des résumés de passage aux urgences (RPU) des établissements de santé aux ARS, puis des ARS au niveau national.

La finalité de ce recueil est notamment d’améliorer la connaissance de l’activité des structures des urgences et de permettre la mise en place d’une base de données nationale sur les urgences.

2. Mise en place du dispositif

Le dispositif de production et transmission de RPU est d’ores et déjà opérationnel, vers l’InVS, sur la base du volontariat et à des fins de veille sanitaire, pour 433 structures d’urgence qui représentent 65% des passages aux urgences en France. Au 1er avril 2013, l’ensemble des régions françaises, y compris ultramarines, compte au moins une structure d’urgence dans le cadre du réseau OSCOUR® (Organisation de la Surveillance Coordonnée des Urgences) en charge de la surveillance des urgences pour l’institut de veille sanitaire (InVS).
L’arrêté précité relatif aux RPU identifie l’ATIH comme destinataire des données et comme étant en charge de leur hébergement et de la production de fichiers anonymisés à destination des services de l’Etat qui en font la demande, ainsi que de tableaux type PMSI à destiné des établissements. Afin de ne pas déstabiliser l’existant, la possibilité pour l’InVS de recevoir également les RPU et d’héberger la base de données est maintenue.
En conséquence, les établissements qui transmettent déjà leurs RPU continuent de le faire dans les conditions habituelles, sous réserve de respecter les dispositions de l’arrêté précité relatif aux RPU et notamment le rôle de l’ARS. Une montée en charge progressive du dispositif est admise pour les établissements qui ne produisent pas encore de RPU et qui ne disposent pas des moyens techniques nécessaires.
Toutefois, et au plus tard pour le 1er juillet 2014, la transmission de la totalité des RPU est attendue. Il convient de souligner que la qualité et l’exhaustivité des données sont essentielles dans la mesure où les éléments transmis seront utilisés pour décrire l’activité des urgences.

3. Contenu des RPU

Afin d’harmoniser les données transmises au niveau national, l’arrêté fixe la liste des variables que doit, au minimum, contenir le RPU.
Les établissements de santé ou les régions qui le souhaitent peuvent mettre en place un RPU comportant d’autres variables, mais seules celles mentionnées dans l’arrêté sont obligatoires. Si des RPU plus détaillés sont élaborés au niveau de l’établissement, ce dernier prend l’attache de l’ARS pour convenir des variables à transmettre au niveau régional.

Pour appuyer les structures des urgences dans le remplissage des RPU, un thésaurus de médecine d’urgence, validé par la SFMU, est disponible sur son site, partie référentiels d’évaluation. Il a pour objectif de faciliter et d’homogénéiser le remplissage des RPU.
L’arrêté relatif au RPU ne prévoyant pas, à ce stade, de recueillir les données contenues dans les RPU à des fins de facturation, ces dernières ne relèvent pas du PMSI et des obligations afférentes.

L'arrêté prévoit que les données RPU doivent être anonymisées dans le cadre de la transmission à l'ATIH de la manière suivante :
- Suppression du nom de la commune de résidence ;
- Code postal remplacé par un code géographique de résidence (dans les conditions habituelles du PMSI) ;
- Date de naissance remplacée par l'âge exprimé en années et calculé à la date de passage aux urgences.

Les établissements de santé ou les agences régionales de santé qui traitent déjà les RPU ou ceux qui souhaitant les traiter (et les conserver) à leur niveau respectif, doivent faire une déclaration en ce sens auprès de la Commission nationale de l'informatique et des libertés dans les conditions habituelles.

4. Organisation régionale du dispositif

En lien avec les ARS, les réseaux OSCOUR®, les observatoires régionaux des urgences (ORU) ou les structures apparentées déjà existantes qui assurent le suivi et l’analyse de l’activité des urgences ont un rôle essentiel à jouer dans la mise en oeuvre du dispositif de transmission obligatoire des RPU.
En effet, l’arrêté précité relatif aux RPU laisse les ARS libres d’organiser le système de recueil et de transmission des RPU de la manière la plus pertinente et efficiente pour leur région, l’objectif étant d’éviter tout doublon dans les circuits de transmission et de s’appuyer sur les organisations régionales déjà existantes dans le champ de l’urgence et du suivi de l’activité des services. Ainsi, tout en restant l’échelon compétent responsable de la constitution de fichiers anonymisés et de la transmission au niveau national, les ARS qui le souhaitent peuvent, par convention, confier cette mission à une structure régionale chargée de la gestion et de l’analyse des données d’activité des urgences dans le respect des règles de protection et de confidentialité des données.
Il appartient à l’ARS, ou à la structure avec laquelle elle a passé convention, de consolider les données reçues et de procéder à leur envoi journalier à l’InVS d’une part et mensuel, après anonymisation, à l’ATIH d’autre part.

5. Plateforme Syrius

L’ATIH met à disposition une plateforme internet ayant les fonctionnalités suivantes :
- Récupération des données transmises par les serveurs régionaux : les données transmises mensuellement comprennent les données de tous les établissements du 1er janvier à la fin du mois de transmission.
- Lancement automatique des traitements : Dès la réception des données des traitements automatiques sont réalisés produisant des tableaux par établissements permettant l'analyse de la cohérence des données, ainsi que des analyses simples.
- Visualisation des résultats : Les utilisateurs ayant les habilitations de lecture des tableaux au niveau régional peuvent visualiser les tableaux produits par le traitement pour tous les établissements. Ceux qui ont une habilitation au niveau des établissements peuvent visualiser les données de leur établissement.
- Validation des données : cette validation n'a pas d'autre effet que de mettre à disposition les données au niveau national. Elle peut être faite sur la page de présentation des établissements pour une période donnée.

Au niveau régional, les ARS doivent disposer d’un système permettant de consolider les fichiers issus des RPU et de veiller à leur anonymisation avant envoi à l’ATIH.

6. Manuel d'utilisation de l'application Syrius

Le manuel de l'utilisation de l'application Syrius est disponible ici.

 

Circuits des remontées des données

Système actuellement en place :

 

L'ajout de l'ATIH (et suppression de la transmission directe établissement vers OSCOUR) :

Use cases

Les différents rôles (GF : gestionnaire des fichiers) et les fonctionnalités disponibles pour chacun d'eux :

 

Transitions d'état

Le schéma actuel est basé sur une transmission par région englobant l'ensemble des établissements (à discuter).

Workflow

A l'état actuel des choses le WF peut facilement être imaginé à partir des use-cases. La transmission se fait de façon automatique par le serveur régional vers le serveur e-PMSI hébergeant l'application Syrius. Chaque envoi comprend les données d'un ES de la région, cumulées depuis le 1er janvier de l'année. On appelle cela une "période" : la période M1 correspond au mois de janvier, M2 au janvier + févier, M3 au janvier + février + mars, … et M12 à toute l'année. Chaque envoi écrase le précédent envoi de la même période (pour le même établissement et le même numéro d'ordre). Ceci est très important, car d'une part cela implique que seule la dernière transmission compte (les précédentes sont perdues), et d'autre part la plate-forme de production peut servir de tests de transmission, sachant que tout disparaîtra avec le dernier (bon) envoi.

 

·         userId : identifiant Pasrel du gestionnaire des fichiers Syrius de niveau régional

·         userPwd : son mot de passe

·         finess : en principe il correspond au finess entité géographique. Faire la correspondance avec l'IPE

·         year : année

·         period : de 1 à 12

·         ordre : plusieurs services des urgences peuvent exister au sein du même établissement, ce numéro d'ordre les distinguera

·         rpuCount : le nombre des RPUs contenus dans le XML envoyé. Sert à vérifier et valider le fichier envoyé

·         check : 0 ou 1. Si 1, cela veut dire que l'appel ne contient pas le fichier RPU et sert à un premier passage pour voir si le système est prêt à recevoir la transmission. Si la réponse du serveur est favorable, l'appel est suivi immédiatement par un autre dont la valeur de check est à 0 et qui envoi le (potentiellement volumineux) fichier *.rpu.zip.

·         theFile : le fichier

Le fichier transmis doit être un fichier zip, contenant un fichier dont l'extension doit être *.rpu.xml : 

La transmission de M12 est scellée nationalement vers le mois de mars de n'année n+1.

Lors de la réunion du 2/10/2013 il a été décidé de

·         Supprimer l'étape validation par le valideur régional (rôle qui a également été supprimé).

·         Avoir des tableaux de bord simple, menant vers des résultats des ES plus détaillés.

·         Mettre en place la partie "télétransmission" avant la fin du mois pour permettre aux serveurs régionaux de commencer les développements et les tests. La partie traitement SAS et résultats sera abordée lors de la prochaine itération.

Exemples de code

Un premier service de télétransmission a été mis en ligne et testé avec succès. Voici les codes clients qui ont permis de réaliser une transmission :

Java

import java.io.BufferedReader;

import java.io.File;

import java.io.InputStreamReader;

 

import org.apache.http.HttpEntity;

import org.apache.http.HttpResponse;

import org.apache.http.client.HttpClient;

import org.apache.http.client.methods.HttpPost;

import org.apache.http.entity.mime.MultipartEntity;

import org.apache.http.entity.mime.content.FileBody;

import org.apache.http.entity.mime.content.StringBody;

import org.apache.http.impl.client.DefaultHttpClient;

 

public class HAT {

 

    public String uploadSyriusData() throws Exception{

 

        String CODE_UPLOAD_OK = "OK";

 

        // URL du service ATIH

        String uploadUrl = "https://www.epmsi.atih.sante.fr/syriusUpload.do";

 

        // Paramètres HTTP inclus dans l'appel

        String userId = "xxxxxx";

        String userPwd = "xxxxxx";

        String year = "2013";

        String period = "12";

        String finess = "xxxxxxxxx";

        String rpuCount = "xx";

        String check = "0"; // 1:sans transmission de fichier; 0:avec fichier

        String ordre = "1";

 

        // Le chemin local vers votre fichier de données

        String dataFilePath = "/epmsi/data/rpu.syrius.zip";

 

        MultipartEntity multipart = new MultipartEntity();

 

        multipart.addPart("userId", new StringBody(userId));

        multipart.addPart("userPwd", new StringBody(userPwd));

        multipart.addPart("year", new StringBody(year));

        multipart.addPart("period", new StringBody(period));

        multipart.addPart("finess", new StringBody(finess));

        multipart.addPart("rpuCount", new StringBody(rpuCount));

        multipart.addPart("ordre", new StringBody(ordre));

        multipart.addPart("check", new StringBody(check));

        FileBody fileBody = new FileBody(new File(dataFilePath), "application/octect-stream") ;

        multipart.addPart("theFile", fileBody) ;      

 

        HttpPost post = new HttpPost(uploadUrl);

        post.setEntity(multipart);

 

        HttpClient client = new DefaultHttpClient();

        HttpResponse response = client.execute(post);

 

        HttpEntity entity = response.getEntity();

        System.out.println(response.getStatusLine().toString());

        BufferedReader reader = new BufferedReader(new InputStreamReader(entity.getContent()));

 

        String line = null;

        StringBuffer sb = new StringBuffer();

        while ((line = reader.readLine()) != null){

            if (line.equals(CODE_UPLOAD_OK)) {

                Assert.assertTrue(true);

                return;

            }

            sb.append(line);

            sb.append("\n");

        }

        reader.close();

        Assert.assertTrue(sb.toString(), false);

        System.out.println(sb.toString());

    }

}

 

Pour l'exécuter vous avez besoin de ces dépendances :


           
<dependency>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpmime</artifactId>
                <version>4.1.2</version>
            </dependency>

 

            <dependency>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpclient</artifactId>
                <version>4.1.3</version>
            </dependency>

 

PHP

Merci à Emmanuel Cervetti de l'ORU de PACA d'avoir fourni et corrigé ce code pour l’adapter à l’évolution du PHP 5.5, et à Clément Garrigou de l’ATIH pour nous avoir mis sur la bonne piste :

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'https://www.epmsi.atih.sante.fr/syriusUpload.do');

curl_setopt($ch, CURLOPT_TIMEOUT, 86400);

$data = array(

    'userId' =>  $login,

    'userPwd' => $passwd,

    'year' => $year,

    'period' => $period,

    'fileType' => 1,

    'ordre' => $indicateurEtabSupp,

    'order' => $indicateurEtabSupp,

    'check' =>  0,

    'rpuCount' => $nbRPU,

    'finess' => $finess

);

 

if (version_compare(PHP_VERSION, '5.5.0') >= 0) {

    $data['theFile'] =  new CurlFile($urlLocalZipFile, 'application/octet-stream') ;

    curl_setopt($ch, CURLOPT_POST, 1);

} else {

    $data['theFile'] =  "@$urlLocalZipFile;type=application/octet-stream" ;

}

curl_setopt($ch, CURLOPT_POSTFIELDS, $data);

curl_setopt($ch, CURLOPT_SSLVERSION, 3);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

if (defined('PROXY')) {

    curl_setopt($ch, CURLOPT_PROXY, PROXY);

}

$rep = curl_exec($ch);

if (curl_errno($ch))

    $msg = curl_error($ch);

else

    $msg = $rep;

curl_close($ch);

echo $msg;

 

Le code retour du service upload

Dans la réponse du serveur, il y a deux parties :

1.     Le code retour http du serveur

2.     Le retour de l'application proprement-dit

Si le flux http parvient bien à l'application Syrius via le serveur et Syrius renvoie une réponse (quelle qu'elle soit), le code retour http sera :

  HTTP/1.1 200 OK

 

Sinon on aura d'autres codes retours selon l'erreur produite. Ce message est indépendant de l'application Syrius.

Du côté de Syrius, si tout va bien il renvoie la chaîne de caractères OK. On aura donc :

HTTP/1.1 200 OK

OK

RTC=OK

 

Comme on peut le constater la réponse du serveur contient deux lignes : OK et RTC=OK. Au début la réponse du serveur ne contenait que la ligne OK, mais ceci posait un problème sémantique dans le sens où ce n'était pas précisé à quoi se reportait ce OK. La deuxième ligne contenant RTC (pour Return Code) a été ajoutée plus tard pour pallier à ce problème. La première ligne a été conservée pour compatibilité avec les programmes existants. Si vous devez développer, il vaut mieux rechercher la ligne RTC=OK pour être sûr de bien localiser la réponse du serveur.

En cas de problème applicatif, OK n'est renvoyé par Syrius, mais un RTC=ERROR suivi par le message d'erreur. Exemple :

HTTP/1.1 200 OK

RTC=ERROR

Le fichier que vous essayez de re-transmettre est en cours de traitement actuellement.

Envoi du fichier en erreur : Le fichier que vous essayez de re-transmettre est en cours de traitement actuellement.

 

Les anciens programmes qui se basent sur l'absence de OK en première ligne continueront à fonctionner correctement.

On voit bien dans les codes Java et PHP que le code attendu est bien "OK" qu'on cherche dans le message HTML et non pas dans l'entête http.

Format des données

Voici le format du fichier XML que nous proposons, inspiré du cahier des charges d'Oscour :

Voici le format du fichier XML :


     <SYRIUS>

  2    <ETABLISSEMENT>

  3        <FINESS> 

  4            numéro finess géographique de l’établissement

  5            Format : 9 caractères       

  6        </FINESS>

  7        <ORDRE>

  8            numéro d’ordre donné par l’établissement

  9            Format : 1 caractère (=0 si un seul envoi par établissement) 

 10        </ORDRE>

 11        <EXTRACT>

 12            date et heure d’extraction de l’information

 13            Format : JJ/MM/AAAA hh :mm :ss

 14        </EXTRACT>

 15        <DATEDEBUT>

 16            date de début de la période couverte

 17            Format : JJ/MM/AAA       

 18        </DATEDEBUT>

 19

 20        <DATEFIN>

 21            date de fin de la période couverte

 22            Format : JJ/MM/AAAA       

 23        </DATEFIN>

 24    <ETABLISSEMENT>

 25    <PASSAGES>

 26        <PATIENT>

 27            <CODEGEO>

 28                Code géographique

 29                Format : 5 caractères

 30            </CODEGEO>

 31            <AGE>

 32                Age en années

 33                vide correspond à incertain   

 34            </AGE>

 35            <AGE_JOURS>

 36                Age en jours, si AGE inférieur à 1

 37                vide correspond à incertain   

 38            </AGE_JOURS>

 39            <SEXE>

 40                sexe

 41                Format : 1 caractère

 42                Codes :

 43                    M - masculin

 44                    F - féminin

 45                    I - inconnu       

 46            </SEXE>

 47            <ENTREE>

 48                date et heure d’entrée

 49                Format : JJ/MM/AAAA hh :mm     

 50            </ENTREE>

 51            <MODE_ENTREE>

 52                Mode d’entrée PMSI 

 53                Format : 1 caractère

 54                Codes :

 55                    6 - mutation

 56                    7 - transfert

 57                    8 - domicile       

 58            </MODE_ENTREE>

 59            <PROVENANCE>

 60                Provenance PMSI

 61                Format : 1 caractère

 62                Codes :

 63                    1 - mutation ou transfert du MCO

 64                    2 - mutation ou transfert du SSR

 65                    3 - mutation ou transfert du SLD

 66                    4 - mutation ou transfert du PSY

 67                    5 - PE autre qu’organisationnelle

 68                    6 - PE organisationnelle     

 69            </PROVENANCE>

 70            <TRANSPORT>

 71                Mode de transport

 72                Format : 5 caractères

 73                Codes :

 74                    PERSO - moyen personnel

 75                    AMBU - ambulance publique ou privée

 76                    VSAB - véhicule de secours et d’aide aux blessés

 77                    SMUR - véhicule de Service Mobile d’Urgence et de Réanimation

 78                    HELI - hélicoptère

 79                    FO - force de l’ordre     

 80            </TRANSPORT>

 81            <TRANSPORT_PEC>

 82                Mode de prise en charge pendant le transport

 83                Format : 7 caractères

 84                Codes :

 85                    MED - médicalisée

 86                    PARAMED - paramédicalisée

 87                    AUCUN - sans prise en charge   

 88            </TRANSPORT_PEC>

 89            <MOTIF>

 90                motif de recours aux urgences

 91                Format : alphanumérique

 92                Codes : thésaurus SFMU       

 93            </MOTIF>

 94            <GRAVITE>

 95                classification CCMU modifiée

 96                Format : 1 caractère

 97                Codes : 

 98                    1 -  état  lésionnel  ou  pronostic  fonctionnel  jugé  stable  après  le

 99                    premier  examen  clinique  éventuellement  complété  d’actes

100                    diagnostiques réalisés et interprétés au lit du malade, abstention

101                    d’actes complémentaires ou de thérapeutique

102                    P -  idem  CCMU  1  avec  problème  dominant  psychiatrique  ou

103                    psychologique isolé ou associé à une pathologie somatique jugée

104                    stable

105                    2 -  état  lésionnel  ou  pronostic  jugé  stable,  réalisation  d’actes

106                    complémentaires  aux  urgences  en  dehors  des  actes

107                    diagnostiques  éventuellement  réalisés  et  interprétés  au  lit  du

108                    malade et / ou d’actes thérapeutiques

109                    3 -  état  lésionnel  ou  pronostic  fonctionnel  jugé  susceptible  de

110                    s’aggraver aux urgences sans mettre en jeu le pronostic vital

111                    4 -  situation  pathologique  engageant  le  pronostic  vital  aux

112                    urgences  sans  manœuvre  de  réanimation  initiée  ou  poursuivie

113                    dès l’entrée aux urgences

114                    5 -  situation  pathologique  engageant  le  pronostic  vital  aux

115                    urgences  avec  initiation  ou  poursuite  de  manœuvres  de

116                    réanimation dès l’entrée aux urgences

117                    D -  patient  décédé  à  l’entrée  aux  urgences  sans  avoir  pu

118                    bénéficier  d’initiation  ou  poursuite  de  manœuvres  de

119                    réanimation aux urgences    

120            </GRAVITE>

121            <DP>

122                diagnostic principal

123                Format : CIM 10          

124            </DP>

125            <LISTE_DA>

126                <DA>

127                    Diagnostic associé

128                    Format : CIM 10          

129                </DA>

130                ...

131            </LISTE_DA>

132            <LISTE_ACTES >

133                <ACTE>

134                    Acte réalisé aux urgences

135                    Format : CCAM           

136                </ACTE>

137                ...

138            </LISTE_ACTES>

139            <SORTIE>

140                Date et heure de sortie

141                Format : JJ/MM/AAAA hh :mm       

142            </SORTIE>

143            <MODE_SORTIE>

144                Mode de sortie PMSI

145                Format :

146                1 caractère

147                Codes :

148                    6 – mutation

149                    7 – transfert

150                    8 – domicile

151                    9 – décès         

152            </MODE_SORTIE>

153            <DESTINATION>

154                Destination PMSI

155                Format : 1 caractère

156                Codes :

157                    1 – hospitalisation MCO

158                    2 – hospitalisation SSR

159                    3 – hospitalisation SLD

160                    4 – hospitalisation PSY

161                    6 – hospitalisation à domicile

162                    7 – structure d’hébergement médicosociale 

163            </DESTINATION>       

164            <ORIENT>

165                Orientation précision

166                Format : 5 caractères

167                Codes :

168                    HDT – hospitalisation sur la demande d’un tiers

169                    HO – hospitalisation d’office

170                    SC – hospitalisation en Unité de Surveillance Continue

171                    SI – hospitalisation en Unité de Soins Intensifs

172                    REA – hospitalisation en Unité de Réanimation

173                    UHCD – hospitalisation dans une Unité d’Hospitalisation de Courte Durée

174                    MED – hospitalisation en unité de Médecine hors SC, SI, REA

175                    CHIR – hospitalisation dans une unité de Chirurgie hors SC, SI, REA

176                    OBST - hospitalisation dans une unité d’Obstétrique hors SC, SI, REA

177                    FUGUE – sortie du service à l’insu du personnel soignant

178                    SCAM – sortie contre avis médical

179                    PSA – partie sans attendre la prise en charge

180                    REO – réorientation directe sans soins      

181            </ORIENT>

182        </PATIENT>

183    </PASSAGES>

184</SYRIUS>

Et voici le XSD correspondant :


  <?xml version="1.0" encoding="UTF-8"?>

 2<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

 3    <xs:element name="SYRIUS">

 4        <xs:annotation>

 5            <xs:documentation>Les RPUs d'un établissement</xs:documentation>

 6        </xs:annotation>

 7        <xs:complexType>

 8            <xs:sequence>

 9                <xs:element name="ETABLISSEMENT">

10                    <xs:complexType>

11                        <xs:sequence maxOccurs="1">

12                            <xs:element name="FINESS" type="xs:normalizedString" />

13                            <xs:element name="ORDRE" type="xs:int" />

14                            <xs:element name="EXTRACT" type="xs:normalizedString" />

15                            <xs:element name="DATEDEBUT" type="xs:normalizedString" />

16                            <xs:element name="DATEFIN" type="xs:normalizedString" />

17                        </xs:sequence>

18                    </xs:complexType>

19                </xs:element>

20                <xs:sequence maxOccurs="1">

21                    <xs:element name="PASSAGES">

22                        <xs:complexType>

23                            <xs:sequence maxOccurs="unbounded">

24                                <xs:element name="PATIENT">

25                                    <xs:complexType>

26                                        <xs:sequence maxOccurs="1">

27                                            <xs:element name="CODEGEO" type="xs:normalizedString" minOccurs="0"/>

28                                            <xs:element name="AGE" type="xs:int" default="0"/>

29                                            <xs:element name="AGE_JOURS" type="xs:int" default="0"/>

30                                            <xs:element name="SEXE" type="xs:normalizedString"  minOccurs="0"/>

31                                            <xs:element name="ENTREE" type="xs:normalizedString"  minOccurs="0"/>

32                                            <xs:element name="MODE_ENTREE" type="xs:int"  default="0"/>

33                                            <xs:element name="PROVENANCE" type="xs:int"  default="0"/>

34                                            <xs:element name="TRANSPORT" type="xs:normalizedString"  minOccurs="0"/>

35                                            <xs:element name="TRANSPORT_PEC" type="xs:normalizedString"   minOccurs="0"/>

36                                            <xs:element name="MOTIF" type="xs:normalizedString"   minOccurs="0"/>

37                                            <xs:element name="GRAVITE" type="xs:normalizedString"   minOccurs="0"/>

38                                            <xs:element name="DP" type="xs:normalizedString"   minOccurs="0"/>

39                                            <xs:element name="LISTE_DA">

40                                                <xs:complexType>

41                                                    <xs:sequence maxOccurs="unbounded">

42                                                        <xs:element name="DA" type="xs:normalizedString"  minOccurs="0"/>

43                                                    </xs:sequence>

44                                                </xs:complexType>

45                                            </xs:element>

46                                            <xs:element name="LISTE_ACTES">

47                                                <xs:complexType>

48                                                    <xs:sequence maxOccurs="unbounded">

49                                                        <xs:element name="ACTE" type="xs:normalizedString"  minOccurs="0"/>

50                                                    </xs:sequence>

51                                                </xs:complexType>

52                                            </xs:element>

53                                            <xs:element name="SORTIE" type="xs:normalizedString"   minOccurs="0"/>

54                                            <xs:element name="MODE_SORTIE" type="xs:int"  default="0"/>

55                                            <xs:element name="DESTINATION" type="xs:int"  default="0"/>

56                                            <xs:element name="ORIENT" type="xs:normalizedString"   minOccurs="0"/>

57                                        </xs:sequence>

58                                    </xs:complexType>

59                                </xs:element>

60                            </xs:sequence>

61                        </xs:complexType>

62                    </xs:element>

63                </xs:sequence>

64            </xs:sequence>

65        </xs:complexType>

66    </xs:element>

67</xs:schema>

Comment procéder pour l'envoi des données vers l'application Syrius (ATIH)

Pour envoyer vos fichiers RPU vers l'application Syrius, hébergée sur la plate-forme e-PMSI de l'ATIH, il vous faut deux choses :

1.     Avoir le droit de vous connecter et d'envoyer les fichiers (avoir un compte Plage avec le bon rôle)

2.     L'établissement dont les données sont à envoyer doit être inscrit dans la base Syrius

Obtenir un compte Plage

La plate-forme de gestion des compte utilisateur (Plage : pour plus de détails voir ici) est conçue pour fournir un identifiant unique aux utilisateurs leur permettant l'accès à toutes les applications de l'ATIH (Single Signe On). Pour accéder à l'application Syrius, il faut avoir un compte :

·         Du niveau régional

·         Avec, dans le domaine Syrius, le rôle de Gestionnaire de Fichiers (pour pouvoir transmettre des fichiers et consulter les résultats), ou le rôle de Lecteur (pour consulter les résultats uniquement)

·         Avec accès au champ MCO :

 

 

Si vous n'avez pas encore de compte Plage, il peut vous être créé par les administrateurs de votre région (voir avec votre ARS). Si vous avez déjà un compte Plage, il faut demander à votre ARS de vous ajouter le rôle et le champ nécessaires.

Fournir de la liste des ES de votre région

Quand vous transmettez les RPUs d'un ES, il faut que celui-ci soit enregistré dans notre base. Nous vous invitons à nous fournir la liste de vos services d'urgence en complétant le fichier Excel disponible ici et de nous le retourner à l'adresse syrius@atih.sante.fr. Nous allons vérifier et compléter vos informations en y ajoutant l'IPE (identifiant Permanent d'Etablissement) avant de les insérer dans la base Syrius.

Présentation de Syrius

Une documentation détaillée de l'application Syrius est disponible ici. Vous pouvez télécharger la présentation de Syrius en cliquant ici.

Support utilisateurs

Pour toute question, si vous avez déjà un compte plage, veuillez utiliser le forum Agora > Thème Syrius disponible à cette URL (L'accès à Agora nécessite une identification via un compte Plage).

 

 

Document mis à jour le 17/07/2014 13:20

alireza.banaei@atih.sante.fr