Healthcare IT Solutions, LTD

Resources

Service documents, troubleshooting guides, project checklists and reference material for the IT teams, vendors and managers we work with. Use them freely, and contact us when you need a second pair of eyes.

Jump to:DocumentsTroubleshooting guidesChecklistsGlossaryStandardsFAQ

Service and technical documents

Our standard documents, ready to print or save as PDF and share with your procurement team or vendors.

  • Service agreement

    Standard Service Level Agreement

    Support hours, severity levels, response targets, escalation steps, responsibilities and reporting for every support plan.

    Open the SLA

  • Technical specification

    HL7, FHIR and DICOM Conformance Statement

    The messages, resources and DICOM services our interfaces support, with transport, character sets and identifier mapping.

    Open the statement

  • Checklist

    Integration project readiness

    What to gather before an interface or system project starts, so the work begins on day one instead of week three.

    Open the checklist

  • Checklist

    Go-live readiness

    The checks we complete with you before switching any interface or system over to live patient traffic.

    Open the checklist

  • Free tool

    HL7 message viewer

    Paste an HL7 v2 message and see every segment and field named and explained, with common codes decoded.

    Open the viewer

  • Free tool

    DICOM connectivity checklist

    Twelve interactive checks for when a modality cannot send to PACS or see its worklist.

    Open the checklist

  • Free fintech tool

    ISO 20022 message viewer

    Paste a pacs, pain or camt message and see its payments, statuses and every element explained.

    Open the viewer

  • Free fintech tools

    Reconciliation comparer and IBAN/BIC checker

    Compare two CSV exports by reference, and check IBAN and BIC formats and checksums.

    Open the tools

Troubleshooting guides

Step-by-step checks for the faults we see most often. Each guide starts with the quickest test and works towards the root cause.

HL7 · Mirth ConnectConnection refused, but the network looks fine: where to look in Mirth

When a Mirth Connect channel reports connection refused, the destination machine answered the connection attempt and turned it down. That tells you the network path works as far as that machine, but nothing there accepted the connection on that address and port. This is different from a timeout, where nothing answers at all.

Work through these checks in order.

  1. Test from the Mirth server itself. A test from your own computer proves nothing, because different machines have different routes and firewall rules. On Windows, run this on the Mirth server, using the host and port from the channel:
    Test-NetConnection -ComputerName host -Port 6661
    On Linux, use nc -zv host 6661.
  2. Compare the channel with what you tested. Check the host, the port, and whether the channel uses a name that resolves to a different address on the Mirth server than on your computer.
  3. Confirm the receiver is listening on the right interface. A listener bound only to a local address, or to another network card, refuses connections arriving from elsewhere even though the service is running. The receiving team can check this.
  4. Check allow-lists and connection limits. Some receivers and firewalls refuse connections from addresses they do not know, or once their maximum number of connections is reached.
  5. Look at keep-alive. If the destination keeps its connection open, a connection the receiver has closed can cause failures on the next send, usually shown as a reset or broken connection. Restart the destination, or turn the setting off, and see whether behaviour changes.
  6. Match the timestamps. Take the exact time of the error from the channel log and look for the same moment in the receiving system’s log. Two logs that agree usually point straight at the cause.

Still stuck? Send us the connector settings and the log lines and we will help you narrow it down.

HL7Reading HL7 acknowledgements: what AA, AE and AR are telling you

Every HL7 v2 message should be answered with an acknowledgement. The code in MSA-1 tells you whether the receiver took the message, and the ERR segment tells you why not.

  1. AA, application accept. The message was received and processed. Nothing to do.
  2. AE, application error. The receiver understood the message but could not process it, for example an unknown patient, an order number it does not recognise, or a code missing from its tables. Correct the data and resend.
  3. AR, application reject. The receiver refused the message itself, usually because of the message type, event, version or processing ID in MSH. Correct how the message is built before resending anything.
  4. No acknowledgement at all. This is a timeout, not a rejection. Check the connection, the receiver’s service and the response timeout on the sending channel.

Common error codes (HL7 table 0357)

CodeMeaningUsually means
100Segment sequence errorSegments in an order the receiver does not expect
101Required field missingA mandatory field is empty in the mapping
102Data type errorFor example a date in the wrong format
103Table value not foundA code the receiver does not have in its tables
200–203Unsupported message type, event, processing ID or versionCheck MSH-9, MSH-11 and MSH-12 against the receiver’s specification
204 / 205Unknown or duplicate key identifierThe patient, visit or order is not found, or already exists
207Application internal errorA fault inside the receiving system: raise it with the vendor

A frequent cause of sudden rejections is MSH-11 set to T (test) when the live system expects P (production), or the reverse, after a system has been moved between environments.

DICOM · PACSA scanner cannot send images to PACS: DICOM connectivity checks
  1. Run a DICOM echo. Use the verification (C-ECHO) button on the modality to test the PACS node. It tests the whole DICOM path, not only the network.
  2. Compare the four values on both sides. The modality’s own AE title, the PACS AE title, the PACS IP address and the port must match exactly at both ends. AE titles are up to 16 characters and should be treated as case-sensitive.
  3. If the association is rejected, the PACS usually does not recognise the calling AE title or address. Add or correct the modality in the PACS list of known devices.
  4. If the echo works but images fail, the PACS may not accept that image type or compression. Check the PACS log for the SOP class and transfer syntax it refused, a common case with tomosynthesis and compressed images.
  5. If images arrive but cannot be found, check for a patient ID or accession number mismatch, or studies held in an unverified or quarantine queue.
  6. Check the network last. A firewall between the modality and server networks, or a closed port, gives a timeout rather than a rejection. Test the port from a machine on the modality network.
DICOM · RISThe modality worklist is empty or missing patients
  1. Confirm the order exists. Check that the order reached the RIS with a scheduled status, and that the order message passed through the interface engine without errors.
  2. Check what the modality asks for. Worklist queries are often filtered by scheduled station AE title, modality and date. If the RIS maps the procedure to a different modality or station, the patient will not appear.
  3. Test the worklist provider. Run a DICOM echo from the modality to the worklist server, and confirm its AE title, address and port.
  4. Look at names and characters. Accented names or an unexpected character set can make some modalities drop entries. Check the Specific Character Set returned by the worklist.
  5. Check dates and time zones. Exams scheduled near midnight, or a server clock in a different time zone, can push entries outside the modality’s “today” filter.
Patient safety · HL7Results landing on the wrong patient, or not matching at all

Treat a result on the wrong record as a patient-safety incident first and a technical fault second. Report it through your facility’s incident process before changing anything.

  1. Contain it. Stop or hold the affected interface if more results could be misfiled, and identify every message affected since the problem started.
  2. Correct the records in the source and receiving systems, following your clinical governance process.
  3. Find the cause in the identifiers. Typical causes are several identifiers in PID-3 with the wrong one selected, a missing assigning authority between facilities, leading zeros removed, or a patient merge (ADT A40) that was not sent to every system.
  4. Fix the mapping and add a safeguard, such as a check on date of birth and sex before a result is filed, then replay corrected messages.

Project checklists

Printable lists we use on every project. Working through them early is the single best way to avoid delays.

Healthcare IT Solutions, LTD

Integration project readiness

  • A list of every system involved, with its version and the person responsible for it
  • Vendor contacts, and confirmation that support contracts are active
  • Each vendor’s interface specification or conformance statement
  • A test environment for each system, or an agreed plan for testing without one
  • Network details: IP addresses, ports, AE titles, VPN access and your firewall change process
  • De-identified sample messages and studies
  • Code tables for procedures, tests and locations, and who owns them
  • An agreed patient identifier strategy across sites
  • A preferred go-live window, and your downtime procedures
  • The people who will sign off testing and go-live

Healthcare IT Solutions, LTD

Go-live readiness

  • End-to-end test results signed off by every system owner
  • Monitoring switched on, and alerts tested by triggering a real failure
  • A rollback plan, with the point at which it would be used
  • Users and departments told what changes, when, and who to call
  • Super-users briefed and available on each site
  • Downtime forms and procedures printed and in place
  • Vendors on standby for the cutover window
  • A plan for messages queued during the cutover
  • Checks booked for one hour, one day and one week after go-live

Glossary

Plain-language definitions of the terms that come up in integration and imaging projects.

ACK
The acknowledgement a receiving system sends back to confirm, or refuse, an HL7 message.
ADT
Admission, discharge and transfer: HL7 messages that keep patient details and visits in step across systems.
AE title
The name a DICOM device uses to identify itself on the network, alongside its IP address and port.
Accession number
The identifier for an imaging order, used to link the order, the images and the report.
DICOM
The international standard for medical images and the way imaging devices exchange them.
EMR / HIS
The electronic medical record and the hospital information system: the main clinical and administrative systems.
FHIR
HL7’s modern standard for exchanging health data through web APIs, built around resources such as Patient and Observation.
HL7 v2
The most widely used standard for messages between hospital systems, such as orders, results and registrations.
ICD-10
The WHO classification of diseases, used to code diagnoses.
IHE
Integrating the Healthcare Enterprise: profiles that describe how to combine standards for common workflows.
Interface engine
Software in the middle that receives, translates, routes and monitors messages between systems, such as Mirth Connect.
LIS
The laboratory information system, which manages lab orders, samples and results.
LOINC
A universal code set for laboratory tests and clinical observations.
MLLP
The simple framing protocol used to send HL7 v2 messages over a TCP connection.
Modality
An imaging device, such as a CT or MRI scanner, an X-ray unit or an ultrasound machine.
MPPS
Modality Performed Procedure Step: the modality telling the RIS that an exam has started or finished.
MWL
Modality worklist: the list of scheduled exams a modality downloads, so patient details are not typed again.
PACS
Picture archiving and communication system: stores images and makes them available for reading.
RIS
Radiology information system: manages imaging orders, scheduling, worklists and reports.
SLA
Service level agreement: the support hours, response targets and escalation rules we commit to.
VNA
Vendor-neutral archive: long-term image storage that is independent of any single PACS.
Interoperability
The ability of different systems to exchange data and use it correctly: technical (connection), syntactic (structure) and semantic (shared meaning).
Health information exchange (HIE)
Sharing clinical information between organisations so it follows the patient from one provider to the next.
MPI
Master patient index: links the different identifiers one patient has in each system or facility.
ISO 20022
The international standard for financial messages, used for payments, statements and status reports.
STP
Straight-through processing: transactions that flow from start to finish with no manual handling.

Standards and official references

The primary sources behind our work. They open on the publisher’s own site.

Frequently asked questions

What does an authorized RamSoft reseller do for me?

We supply the software, set it up, connect it to your other hospital systems and support it afterwards, so you deal with one local team instead of several. Contact us for product details, licensing options and pricing.

Do you only work with RamSoft?

No. Our integration, equipment and support work covers other systems too, as long as they support standard protocols such as HL7, FHIR and DICOM.

Can you work remotely?

Yes. Most work is delivered remotely over secure VPN connections. In Mauritius we can also be on site, and visits elsewhere in Africa can be arranged where a project needs them.

How do you protect patient data?

Patient data is handled under your own policies and in line with the Mauritius Data Protection Act 2017. We prefer de-identified samples for testing, connect only through secure channels such as VPN, and ask for the minimum access needed to do the work.

What do you need from us to get started?

A list of the systems involved and who looks after each, contact details for the vendors, access to a test environment where one exists, and a few de-identified sample messages. If you do not have all of that, we can help you gather it.

What are your support hours?

Monday to Friday, 08:00 to 17:00 Mauritius Time (UTC+4), excluding Mauritian public holidays. Out-of-hours and weekend work is available by arrangement.

How is pricing worked out?

We quote against the number of sites, users, interfaces and systems you run, so you pay for what you need. Send us those details and we will reply with a written quote.

Can you work alongside our own IT team and vendors?

Yes, and we prefer to. We coordinate with your IT staff and your vendors, document what we build and train your team, so you are never dependent on us for routine tasks.

Which countries do you serve?

Mauritius and the rest of Africa. Mauritius time overlaps comfortably with East and Southern Africa, the Middle East and Europe.

How do we get started?

Email, call or message us on WhatsApp with a short description of what you need. We will arrange a call, ask the right questions and follow up with a plan and a quote.

Do you provide an SLA and a conformance statement before we sign?

Yes. Our Standard Service Level Agreement and our HL7, FHIR and DICOM Conformance Statement are published above and can be printed or saved as PDF. The signed agreement and the project interface specification confirm the details for your sites.

Can you write the interface specification for our vendors?

Yes. We document every interface we build, with message structures, field mappings, code tables, test cases and runbooks, and share them with your vendors and IT team.

Need a guide we have not written yet?

Send us the error, the log lines or the question, and we will help you narrow it down.

Ask us

Ressources

Documents de service, guides de dépannage, listes de contrôle de projet et documentation de référence pour les équipes informatiques, fournisseurs et responsables avec qui nous travaillons. Utilisez-les librement, et contactez-nous lorsque vous avez besoin d’un second avis.

Aller à :DocumentsGuides de dépannageListes de contrôleGlossaireNormesFAQ

Documents de service et techniques

Nos documents standards, prêts à imprimer ou à enregistrer en PDF et à partager avec votre service achats ou vos fournisseurs.

  • Accord de service

    Accord de niveau de service standard

    Heures de support, niveaux de gravité, délais de réponse, étapes d’escalade, responsabilités et rapports pour toutes les formules de support.

    Ouvrir l’accord

  • Spécification technique

    Déclaration de conformité HL7, FHIR et DICOM

    Les messages, ressources et services DICOM pris en charge par nos interfaces, avec le transport, les jeux de caractères et la correspondance des identifiants.

    Ouvrir la déclaration

  • Liste de contrôle

    Préparation d’un projet d’intégration

    Ce qu’il faut réunir avant le démarrage d’un projet d’interface ou de système, pour que le travail commence dès le premier jour et non à la troisième semaine.

    Ouvrir la liste

  • Liste de contrôle

    Préparation de la mise en production

    Les vérifications que nous réalisons avec vous avant de basculer une interface ou un système sur le trafic patient réel.

    Ouvrir la liste

  • Outil gratuit

    Visionneuse de messages HL7

    Collez un message HL7 v2 et voyez chaque segment et chaque champ nommés et expliqués, avec les codes courants décodés.

    Ouvrir la visionneuse

  • Outil gratuit

    Liste de contrôle de connectivité DICOM

    Douze vérifications interactives lorsqu’une modalité ne peut pas envoyer au PACS ou voir sa liste de travail.

    Ouvrir la liste

  • Outil fintech gratuit

    Visionneuse de messages ISO 20022

    Collez un message pacs, pain ou camt et voyez ses paiements, statuts et chaque élément expliqué.

    Ouvrir la visionneuse

  • Outils fintech gratuits

    Comparateur de rapprochement et vérificateur IBAN/BIC

    Comparez deux exports CSV par référence, et vérifiez le format et la clé des IBAN et BIC.

    Ouvrir les outils

Guides de dépannage

Des vérifications pas à pas pour les pannes que nous rencontrons le plus souvent. Chaque guide commence par le test le plus rapide et remonte vers la cause réelle.

HL7 · Mirth ConnectConnexion refusée, mais le réseau semble correct : où chercher dans Mirth

Lorsqu’un canal Mirth Connect signale connection refused (connexion refusée), la machine de destination a répondu à la tentative de connexion et l’a rejetée. Cela indique que le chemin réseau fonctionne jusqu’à cette machine, mais que rien n’y a accepté la connexion sur cette adresse et ce port. C’est différent d’un dépassement de délai, où rien ne répond du tout.

Passez ces vérifications en revue dans l’ordre.

  1. Testez depuis le serveur Mirth lui-même. Un test depuis votre propre ordinateur ne prouve rien, car des machines différentes ont des routes et des règles de pare-feu différentes. Sous Windows, exécutez ceci sur le serveur Mirth, avec l’hôte et le port du canal :
    Test-NetConnection -ComputerName host -Port 6661
    Sous Linux, utilisez nc -zv host 6661.
  2. Comparez le canal avec ce que vous avez testé. Vérifiez l’hôte, le port, et si le canal utilise un nom qui se résout vers une autre adresse sur le serveur Mirth que sur votre ordinateur.
  3. Confirmez que le destinataire écoute sur la bonne interface. Un service d’écoute lié uniquement à une adresse locale, ou à une autre carte réseau, refuse les connexions venant d’ailleurs même si le service fonctionne. L’équipe du destinataire peut le vérifier.
  4. Vérifiez les listes d’autorisation et les limites de connexions. Certains destinataires et pare-feu refusent les connexions provenant d’adresses inconnues, ou une fois leur nombre maximal de connexions atteint.
  5. Examinez le maintien de connexion (keep-alive). Si la destination garde sa connexion ouverte, une connexion fermée par le destinataire peut provoquer des échecs à l’envoi suivant, généralement affichés comme une réinitialisation ou une connexion rompue. Redémarrez la destination, ou désactivez ce paramètre, et observez si le comportement change.
  6. Faites correspondre les horodatages. Relevez l’heure exacte de l’erreur dans le journal du canal et cherchez le même instant dans le journal du système destinataire. Deux journaux qui concordent désignent généralement la cause.

Toujours bloqué ? Envoyez-nous les paramètres du connecteur et les lignes du journal et nous vous aiderons à cerner le problème.

HL7Lire les accusés de réception HL7 : ce que signifient AA, AE et AR

Chaque message HL7 v2 devrait recevoir un accusé de réception. Le code dans MSA-1 indique si le destinataire a accepté le message, et le segment ERR explique pourquoi il ne l’a pas fait.

  1. AA, acceptation applicative. Le message a été reçu et traité. Rien à faire.
  2. AE, erreur applicative. Le destinataire a compris le message mais n’a pas pu le traiter : par exemple un patient inconnu, un numéro de demande qu’il ne reconnaît pas, ou un code absent de ses tables. Corrigez les données et renvoyez.
  3. AR, rejet applicatif. Le destinataire a refusé le message lui-même, généralement à cause du type de message, de l’événement, de la version ou de l’identifiant de traitement dans MSH. Corrigez la construction du message avant de renvoyer quoi que ce soit.
  4. Aucun accusé de réception. Il s’agit d’un dépassement de délai, pas d’un rejet. Vérifiez la connexion, le service du destinataire et le délai de réponse du canal émetteur.

Codes d’erreur courants (table HL7 0357)

CodeSignificationIndique généralement
100Erreur de séquence de segmentsDes segments dans un ordre inattendu pour le destinataire
101Champ obligatoire manquantUn champ obligatoire est vide dans le mappage
102Erreur de type de donnéesPar exemple une date au mauvais format
103Valeur absente de la tableUn code que le destinataire n’a pas dans ses tables
200–203Type de message, événement, identifiant de traitement ou version non pris en chargeVérifiez MSH-9, MSH-11 et MSH-12 par rapport à la spécification du destinataire
204 / 205Identifiant de clé inconnu ou en doubleLe patient, la venue ou la demande est introuvable, ou existe déjà
207Erreur interne de l’applicationUn défaut dans le système destinataire : à signaler au fournisseur

Une cause fréquente de rejets soudains est un MSH-11 réglé sur T (test) alors que le système de production attend P (production), ou l’inverse, après le déplacement d’un système entre environnements.

DICOM · PACSUn scanner n’arrive pas à envoyer les images au PACS : vérifications de connectivité DICOM
  1. Lancez un écho DICOM. Utilisez le bouton de vérification (C-ECHO) de la modalité pour tester le nœud PACS. Il teste tout le chemin DICOM, pas seulement le réseau.
  2. Comparez les quatre valeurs des deux côtés. L’AE title de la modalité, l’AE title du PACS, l’adresse IP et le port du PACS doivent correspondre exactement aux deux extrémités. Les AE titles comptent jusqu’à 16 caractères et doivent être considérés comme sensibles à la casse.
  3. Si l’association est rejetée, le PACS ne reconnaît généralement pas l’AE title ou l’adresse appelante. Ajoutez ou corrigez la modalité dans la liste des équipements connus du PACS.
  4. Si l’écho fonctionne mais que les images échouent, le PACS n’accepte peut-être pas ce type d’image ou cette compression. Cherchez dans le journal du PACS la classe SOP et la syntaxe de transfert refusées, un cas fréquent avec la tomosynthèse et les images compressées.
  5. Si les images arrivent mais sont introuvables, vérifiez une incohérence d’identifiant patient ou de numéro d’accession, ou des examens bloqués dans une file non vérifiée ou de quarantaine.
  6. Vérifiez le réseau en dernier. Un pare-feu entre le réseau des modalités et celui des serveurs, ou un port fermé, provoque un dépassement de délai plutôt qu’un rejet. Testez le port depuis une machine du réseau des modalités.
DICOM · RISLa liste de travail de la modalité est vide ou incomplète
  1. Confirmez que la demande existe. Vérifiez qu’elle est arrivée dans le RIS avec un statut planifié, et que le message de demande est passé par le moteur d’interfaçage sans erreur.
  2. Vérifiez ce que la modalité demande. Les requêtes de liste de travail sont souvent filtrées par AE title de la station planifiée, par modalité et par date. Si le RIS associe l’examen à une autre modalité ou station, le patient n’apparaîtra pas.
  3. Testez le fournisseur de liste de travail. Lancez un écho DICOM depuis la modalité vers le serveur de liste de travail, et confirmez son AE title, son adresse et son port.
  4. Regardez les noms et les caractères. Des noms accentués ou un jeu de caractères inattendu peuvent faire ignorer des entrées par certaines modalités. Vérifiez le Specific Character Set renvoyé par la liste de travail.
  5. Vérifiez les dates et fuseaux horaires. Des examens planifiés vers minuit, ou une horloge serveur dans un autre fuseau, peuvent placer des entrées hors du filtre « aujourd’hui » de la modalité.
Sécurité patient · HL7Des résultats sur le mauvais patient, ou qui ne correspondent à aucun dossier

Traitez un résultat classé sur le mauvais dossier d’abord comme un incident de sécurité patient, puis comme une panne technique. Déclarez-le selon la procédure d’incident de votre établissement avant de modifier quoi que ce soit.

  1. Contenez le problème. Arrêtez ou suspendez l’interface concernée si d’autres résultats risquent d’être mal classés, et identifiez tous les messages concernés depuis le début du problème.
  2. Corrigez les dossiers dans les systèmes source et destinataire, selon votre processus de gouvernance clinique.
  3. Cherchez la cause dans les identifiants. Causes typiques : plusieurs identifiants dans PID-3 avec le mauvais sélectionné, une autorité d’attribution manquante entre établissements, des zéros initiaux supprimés, ou une fusion de patients (ADT A40) qui n’a pas été envoyée à tous les systèmes.
  4. Corrigez le mappage et ajoutez un garde-fou, par exemple un contrôle de la date de naissance et du sexe avant le classement d’un résultat, puis rejouez les messages corrigés.

Listes de contrôle de projet

Des listes imprimables que nous utilisons sur chaque projet. Les parcourir tôt est le meilleur moyen d’éviter les retards.

Healthcare IT Solutions, LTD

Préparation d’un projet d’intégration

  • La liste de tous les systèmes concernés, avec leur version et leur responsable
  • Les contacts des fournisseurs, et la confirmation que les contrats de support sont actifs
  • La spécification d’interface ou la déclaration de conformité de chaque fournisseur
  • Un environnement de test pour chaque système, ou un plan convenu pour tester sans
  • Les détails réseau : adresses IP, ports, AE titles, accès VPN et votre processus de modification du pare-feu
  • Des messages et examens d’exemple anonymisés
  • Les tables de codes des examens, analyses et lieux, et leurs responsables
  • Une stratégie d’identification des patients convenue entre les sites
  • Une fenêtre de mise en production souhaitée, et vos procédures en mode dégradé
  • Les personnes qui valideront les tests et la mise en production

Healthcare IT Solutions, LTD

Préparation de la mise en production

  • Résultats des tests de bout en bout validés par chaque responsable de système
  • Surveillance activée, et alertes testées en provoquant une vraie panne
  • Un plan de retour arrière, avec le moment où il serait déclenché
  • Utilisateurs et services informés de ce qui change, quand, et qui appeler
  • Super-utilisateurs briefés et disponibles sur chaque site
  • Formulaires et procédures de mode dégradé imprimés et en place
  • Fournisseurs en astreinte pendant la fenêtre de bascule
  • Un plan pour les messages mis en file pendant la bascule
  • Des vérifications prévues une heure, un jour et une semaine après la mise en production

Glossaire

Des définitions en langage clair des termes rencontrés dans les projets d’intégration et d’imagerie.

ACK
L’accusé de réception qu’un système destinataire renvoie pour confirmer, ou refuser, un message HL7.
ADT
Admission, sortie et transfert : les messages HL7 qui maintiennent les données patient et les venues à jour entre les systèmes.
AE title
Le nom qu’un équipement DICOM utilise pour s’identifier sur le réseau, avec son adresse IP et son port.
Numéro d’accession
L’identifiant d’une demande d’imagerie, qui relie la demande, les images et le compte rendu.
DICOM
La norme internationale des images médicales et de leur échange entre équipements d’imagerie.
DPI / SIH
Le dossier patient informatisé et le système d’information hospitalier : les principaux systèmes cliniques et administratifs.
FHIR
La norme moderne de HL7 pour échanger des données de santé via des API web, organisée autour de ressources comme Patient et Observation.
HL7 v2
La norme la plus utilisée pour les messages entre systèmes hospitaliers, comme les demandes, résultats et admissions.
CIM-10
La classification des maladies de l’OMS, utilisée pour coder les diagnostics.
IHE
Integrating the Healthcare Enterprise : des profils décrivant comment combiner les normes pour des flux courants.
Moteur d’interfaçage
Un logiciel intermédiaire qui reçoit, traduit, achemine et surveille les messages entre systèmes, comme Mirth Connect.
SIL
Le système d’information de laboratoire, qui gère les demandes, prélèvements et résultats.
LOINC
Un jeu de codes universel pour les analyses de laboratoire et les observations cliniques.
MLLP
Le protocole d’encadrement simple utilisé pour envoyer des messages HL7 v2 sur une connexion TCP.
Modalité
Un équipement d’imagerie : scanner, IRM, appareil de radiographie ou échographe.
MPPS
Modality Performed Procedure Step : la modalité informe le RIS qu’un examen a commencé ou s’est terminé.
MWL
Liste de travail de modalité : la liste des examens planifiés que la modalité télécharge, pour éviter de ressaisir les données patient.
PACS
Système d’archivage et de transmission d’images : stocke les images et les met à disposition pour la lecture.
RIS
Système d’information radiologique : gère les demandes, rendez-vous, listes de travail et comptes rendus d’imagerie.
SLA
Accord de niveau de service : les heures de support, délais de réponse et règles d’escalade auxquels nous nous engageons.
VNA
Archive neutre vis-à-vis des fournisseurs : stockage d’images à long terme indépendant d’un PACS particulier.
Interopérabilité
La capacité de systèmes différents à échanger des données et à les utiliser correctement : technique (connexion), syntaxique (structure) et sémantique (sens partagé).
Échange d’informations de santé
Le partage d’informations cliniques entre organisations pour qu’elles suivent le patient d’un prestataire à l’autre.
MPI
Index patient maître : relie les différents identifiants d’un même patient dans chaque système ou établissement.
ISO 20022
La norme internationale des messages financiers, utilisée pour les paiements, relevés et rapports de statut.
STP
Traitement de bout en bout sans intervention : des transactions qui circulent du début à la fin sans manipulation manuelle.

Normes et références officielles

Les sources primaires de notre travail. Elles s’ouvrent sur le site de leur éditeur.

Questions fréquentes

Que fait un revendeur agréé RamSoft pour moi ?

Nous fournissons le logiciel, l’installons, le connectons à vos autres systèmes hospitaliers et en assurons ensuite le support : vous avez affaire à une seule équipe locale plutôt qu’à plusieurs. Contactez-nous pour les détails produits, les options de licence et les tarifs.

Travaillez-vous uniquement avec RamSoft ?

Non. Notre travail d’intégration, d’équipements et de support couvre aussi d’autres systèmes, dès lors qu’ils prennent en charge des protocoles standards comme HL7, FHIR et DICOM.

Pouvez-vous travailler à distance ?

Oui. L’essentiel du travail est réalisé à distance via des connexions VPN sécurisées. À Maurice, nous pouvons aussi intervenir sur site, et des déplacements ailleurs en Afrique peuvent être organisés lorsqu’un projet l’exige.

Comment protégez-vous les données des patients ?

Les données des patients sont traitées selon vos propres politiques et conformément au Data Protection Act 2017 de Maurice. Nous privilégions des échantillons anonymisés pour les tests, nous nous connectons uniquement par des canaux sécurisés tels que le VPN, et demandons l’accès minimal nécessaire au travail.

De quoi avez-vous besoin pour démarrer ?

La liste des systèmes concernés et de leurs responsables, les coordonnées des fournisseurs, l’accès à un environnement de test s’il en existe un, et quelques messages d’exemple anonymisés. Si vous n’avez pas tout cela, nous pouvons vous aider à le rassembler.

Quelles sont vos heures de support ?

Du lundi au vendredi, de 08 h 00 à 17 h 00, heure de Maurice (UTC+4), hors jours fériés mauriciens. Les interventions hors horaires et le week-end sont possibles sur demande.

Comment le tarif est-il établi ?

Nous chiffrons en fonction du nombre de sites, d’utilisateurs, d’interfaces et de systèmes que vous exploitez, afin que vous ne payiez que ce dont vous avez besoin. Envoyez-nous ces informations et nous vous répondrons avec un devis écrit.

Pouvez-vous travailler avec notre équipe informatique et nos fournisseurs ?

Oui, et nous le préférons. Nous coordonnons avec votre équipe informatique et vos fournisseurs, documentons ce que nous construisons et formons votre équipe, afin que vous ne dépendiez jamais de nous pour les tâches courantes.

Quels pays servez-vous ?

Maurice et le reste de l’Afrique. L’heure de Maurice recoupe confortablement celle de l’Afrique de l’Est et australe, du Moyen-Orient et de l’Europe.

Comment démarrer ?

Écrivez-nous par e-mail, appelez-nous ou envoyez-nous un message WhatsApp avec une courte description de votre besoin. Nous organiserons un échange, poserons les bonnes questions et reviendrons vers vous avec un plan et un devis.

Fournissez-vous un SLA et une déclaration de conformité avant signature ?

Oui. Notre accord de niveau de service standard et notre déclaration de conformité HL7, FHIR et DICOM sont publiés ci-dessus et peuvent être imprimés ou enregistrés en PDF. Le contrat signé et la spécification d’interface du projet confirment les détails pour vos sites.

Pouvez-vous rédiger la spécification d’interface pour nos fournisseurs ?

Oui. Nous documentons chaque interface que nous construisons : structures de messages, correspondances de champs, tables de codes, cas de test et guides d’exploitation, et les partageons avec vos fournisseurs et votre équipe informatique.

Besoin d’un guide que nous n’avons pas encore rédigé ?

Envoyez-nous l’erreur, les lignes du journal ou la question, et nous vous aiderons à cerner le problème.

Nous écrire
WhatsApp usWhatsApp