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 1^er 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

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>

<groupId>org.apache.httpcomponents</groupId>

<artifactId>httpclient</artifactId>

</dependency>

<groupId>org.apache.httpcomponents</groupId>

<artifactId>httpmime</artifactId>

</dependency>

<groupId>org.apache.commons</groupId>

<artifactId>commons-io</artifactId>

</dependency>

</dependencies>

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. 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;

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

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 :

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>

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