Syrius : Système de recueil de l'information des urgences
Table des matières
Système de recueil d'information des urgences
1. Présentation générale du projet de remontées des RPU
2. Mise en place du dispositif
4. Organisation régionale du dispositif
6. Manuel d'utilisation de l'application Syrius
Circuits
des remontées des données
Le
code retour du service upload
Comment
procéder pour l'envoi des données vers l'application Syrius (ATIH)
Fournir
de la liste des ES de votre région
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.
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.
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.
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.
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.
Le manuel de l'utilisation de l'application Syrius est disponible ici.
Système actuellement
en place :
L'ajout de l'ATIH (et
suppression de la transmission directe établissement vers OSCOUR) :
Les différents rôles (GF : gestionnaire des fichiers) et les fonctionnalités disponibles pour chacun d'eux :
Le schéma actuel est basé sur une transmission par région englobant l'ensemble des établissements (à discuter).
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.
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 :
Le code Java et les dépendances Maven ont été mis à jour suite à la montée de version de sécurité (TLS 1.2) du serveur Syrius. Attention il faut utiliser désormais le Java 8 pour que ce code fonctionne. Voici le nouveau code Java pour pouvoir transmettre en TLS 1.2.
import java.io.BufferedReader;
import java.io.File;
import java.io.InputStreamReader;
import javax.net.ssl.SSLContext;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.conn.ssl.NoopHostnameVerifier;
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.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.ssl.SSLContextBuilder;
import org.junit.Test;
public class HAT {
public String uploadSyriusData() throws Exception{
String CODE_UPLOAD_OK = "1";
// 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) ;
SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, (certificate, authType)
-> true).build();
CloseableHttpClient
client = HttpClients.custom()
.setSSLContext(sslContext)
.setSSLHostnameVerifier(new NoopHostnameVerifier())
.build();
final HttpPost post = new HttpPost(uploadUrl);
post.setEntity(multipart);
final HttpResponse response = client.execute(post);
final HttpEntity entity = response.getEntity();
System.out.println(response.getStatusLine().toString());
final BufferedReader reader = new BufferedReader(new InputStreamReader(entity.getContent()));
String line = null;
final StringBuffer sb = new StringBuffer();
while ((line = reader.readLine()) != null) {
sb.append(line);
sb.append("\n");
}
reader.close();
System.out.println(sb.toString());
}
}
Pour l'exécuter vous avez besoin de ces dépendances Maven :
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.1</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.5.1</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
</dependencies>
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. Attention suite à la montée de version de sécurité (TLS 1.2) du serveur Syrius, le paramètre CURLOPT_SSLVERSION a été modifié en 0 (au lieu de 3 dans le code précédent).
Voici le code PHP corrigé pour être compatible TLS 1.2.
$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, 0);
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;
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.
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>
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
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.
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 [email protected]. 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.
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.
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