Notes on iSantéPlus Activity and Push/Pull Architecture with SEDISH

iSantéPlus is setup to be the primary actor for all interactions with the SEDISH platform. The iSantéPlus clinic application initiates all interactions with SEDISH. The clinic pushes changes from the clinic to SEDISH and pulls all updates that it would expect from the national to local levels. We chose this architecture due to the operational environment in Haiti where the power and internet goes down regularly and we need to maintain clinic activities regardless of the availability of these services.

We have built tools that allow the clinic to query the Master Person Index and push encounters to the shared health record. If the internet is down, we have also built a queuing mechanism that stores failed messages in the iSantéPlus database and Mirth will retry the messages on a regular schedule.

This has a number of implications on the exchange of messages with other systems. We have scoped a direct clinic level integration between OpenELIS and iSantéPlus that exchanges standard HL7 v2.5.1 messages.

We have also scoped a national level integration between the iSantéPlus clinic and the national lab (LNSP) that utilizes SoftLab (SCC). This integration requires mediation by SEDISH, specifically the XDS repository, to exchange lab orders and results. When thinking through this integration, we realized that a direct connection between 100+ clinics and SCC wasn’t feasible. One item is that it would require a public IP address for each iSantéPlus clinic. Instead, we aim to package each HL7 v2.5.1 message in an XDS.b package and send it from the clinic to XDS.b repository. Once received by SEDISH, a notification will be sent to the national lab that a new document is available. The lab result works in the opposite direction, but the notification queues at a notification endpoint that sits in SEDISH and can be pulled on a regular schedule from the iSantéPlus clinic.


  • Registration Core does the registration integration with the MPI
  • Registration App displays results in the UI for end users
  • XDS Sender - packages encounters as XDS packages and sends them in realtime to the XDS.b repository
  • Outgoing message exceptions - Listens for failed events from registration core (PIX messages) and the XDS Sender. If there is a failed event, this module stores the message in the database.
  • MIrth - responsible for automatically retrying the messages that are queued in the Outgoing message exceptions module

Design Specs: The following design specifications are a work in progress and are being negotiated with partners.

FYI @nathaelf


Thanks !!!

Yes, thanks for the update @craigappl, this is great… do you have a plan for incorporating the Registration Core and Registration App forks back into master? If you have any design questions/issues around that, I think we’d be willing to provide some help as this is functionality we potentially would want to use.

It occurs to me since we have little experience with SEDISH that we might want to play around with setting up a demo version of it… any idea if this would be easy or hard or somewhere in-between? :slight_smile:

Thanks! Mark

Hi @mogoodrich,

The SEDISH demo environment utilizes docker containers and can be setup with a few commands. The repo provides instructions.

It has been my personal intention to integrate the changes in registration core and registration app back to OpenMRS. It’s a big job, primarily because we have committed all changes for the fingerprint integration and the MPI integration on our master branch. So, we would have to rebase the branch to capture all of the commits that are related only to the MPI integration.

@nathaelf and @pgesek will have to prioritize this moving forward.


Great, thanks… I will keep in touch with @nathaelf and @pgesek on this going forward!

Take care, Mark

Follow on questions for @nathaelf and @pgesek:

  1. Has it been decided yet what finger(s) will be collected as part of the national registration?

  2. Do you know what fingerprint template type you will be using?

Thanks! Mark

fyi @ball @mseaton @raphael

Has it been decided yet what finger(s) will be collected as part of
the national registration? (Not yet decided)
Do you know what fingerprint template type you will be using? (ISO)


Thanks @mogoodrich !

Can you please share more details about the format? Which ISO specification? And, I might miss something, sorry. But I’d like to know that: Is it the format that you adopted iSantePlus or will it be the one that will be used on the Master Person Index I mean for the MOH?

Hi @raphael,

I don’t know about the ISO template version. The fingerprint is collected at the clinic with a local fingerprint matching server. That fingerprint stores the template and returns a fingerprint ID from the local fingerprint server. That is the ID that’s stored in iSantePlus, not the actual template. The fingerprint template is meant to be replicated up to the national fingerprint server. The local fingerprint ID is getting pushed to the master person index in a PIX message to support linking to the national fingerprint server.


FYI @nathaelf

@craigappl @nathaelf what is the format of the fingerprint ID that you are sending to the MPI? Sounds like we are doing a similar thing in our implementation… we have a “Biometrics Reference Code” idenifier type in OpenMRS that links to the actual template in the fingerprint database. This Biometrics Reference Code is a UUID, so we shouldn’t have to worry about duplication and could potentially send it to the MPI.

Is the idea that you will send the fingerprint ID to the MPI, and then eventually the fingerprint ID and the fingerprint template could be synced up to the national fingerprint server?

We are using the Neurotechnology propriety format, but it supports converting to ISO.

fyi @raphael

Take care, Mark

Also @nathaelf @craigappl it would be great if at some point we can get the iSante branch of registration-core merged back into the main branch so when the time comes to sync with the MPI we can utilize the PIX messaging functionality you have built. :slight_smile:

Take care, Mark

Thanks, I am following.

@mogoodrich, the format is a UUID that is creates when the fingerprint is registered in the fingerprint widget. The second idea is on point, where the fingerprint ID is synced to the MPI and the local fingerprint will be sent to the national fingerprint server. Deduplication will happen at that point and the national fingerprint UUID will be created.


Thanks @craigappl!

Since we are also creating a UUID is our system, looking like we may be compatible. Any particular requirements as to the format of the UUID?

Also, if you collect multiple fingerprints is there a template per finger, or a single template for all the fingerprints. We have a single template that contains both left and right index finger.

Take care, Mark

Hi Mark,

The UUID is generated with java.util.UUID. Here’s a sample “71639b38-aa90-4ed2-943e-792e1bcd7245” Our application doesn’t have access to the fingerprint template data. The fingerprint reader is run as a service and does all of the interactions with the database and templates. We only get a registrationID.

@pgesek may have more information.


@craigappl @mogoodrich

That was actually the case with the older versions, where we didn’t have access to the biometric data and only dealt with IDs.

With the latest version of M2Sys we receive the fingerprint data in the following format:

        <Finger POS="3">Base64 Template string</Finger>
        <Finger POS="8">Base64 Template string</Finger>

Regards, Paweł

Thanks @pgesek… so does that mean there is a separate template for each finger… in our system we have a single template that combinese both left and right index fingers. I’m assuming there’d be some way to pull them apart if need be.

Take care, Mark

Yes, they are separate, and POS indicates which finger it is. However, we actually always use them together as a biometrics xml that we pass to the server.

Regards, Paweł