FHIR Client Registry Synchronization Mediator

[Carl Leitner]

Hi All,

For a project in Zambia we have to setup a synchronization service between a Client Registry and a Point of Service (Immunization Registry) application.  As I suspect that this would be generically useful, I thought it would be good to implement this as a mediator for OpenHIM and discuss with this group some of the priority features and expected future features.  

The first workflow what we will want to concentrate on at first would be a mediator that runs on a routine (e.g. nightly, hourly basis)

• meditator make a request to a Point of Service application to get a list of changed patient resource records using the _history operation.  Some notes here:
• the mediator would request the patient resources in pages.   
• because an initial data load could result in a large number of records, we may want to loop through the paged results sequentially so we don't get a "too many open files" error
• the mediator would transform each page of results into a transaction to submit to a Client Registry 
• because we are going to rely on timestamps to keep track of changes
• if all transactions are run successfully we update the time timestamp
• we need a place to store the timestamp of the last time that the synchronization was run.   In our case we are using DHIS2 Tracker as our Point of Service application which allows us to use the Data Store API.  This will meet our short term needs, but limits this mediator to work only with DHIS2.   Are there are any plans to add a similar type of service to hold mediator specific metadata to the OpenHIM Core?

Some future needs that we will want to consider:

• We may want the synchronization service to work on one or more different resources
• We may want to easily add a hook to perform a translation of the individual resource.  For example we may need to do a translation from a FHIR DSTU resource to a STU3 Resource, as the CR we are looking at  MedicCR only supports DSTU while for DHIS2 we are targeting STU3.   We will start with a HAPI server in lieu of MedicCR as it can already support STU3. 
• At some point we will want to point the mediator to a second (and more) source of client demographics from other points of service.   Would it be better to have multiple instances of the same mediator or use the same mediator that can handle multiple sources of information.
• At some point, we will want to use identified duplicate records on the CR to trigger merge of clinical information in POS application.  I think this is likely this is one (or more) different mediators.  

I would appreciate your thoughts on this setup, a recommend a good starting point within the OpenHIM mediator documentation as well as any examples of mediators that may be similar.

On a related note, do you have any recommendations for a testing environment for the mediators?   

Finally, have you found any of the node.js FHIR module (e.g. this one) useful?

Gerard, one of our developers, will be doing a lot of this work.  I hope that you will be able to extend to him some guidance and suggestions.   

Thanks all!

Cheers,

-carl

[Ryan Crichton]

Hi Carl,

This sounds great and an OpenHIM mediator sounds like a good approach to this. I really like the idea to make this sync generic to FHIR resources. That fits with our goal to create a deduplicattion registry as well. Using the _history operation sounds like a good approach to me.

For getting started with OpenHIM mediator we have some tutorials that show the basics - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

We can help with more advanced features like mediator config as well.

For FHIR we haven't really found any npm module useful as it's easy enough to work with JSON in native js.

I'm not quite sure what you are asking about a testing environment for mediator however we mostly use node.js for our mediators with normal unit test then we write integration tests that startup mock services and tests the end-to-end functionality. We usually set these to run automatically on travis-ci for open source projects.

This works sounds very interesting and perhaps we could get involved under the OpenHIE work we are doing.

Cheers,

Ryan

--

You received this message because you are subscribed to the Google Groups "OpenHIM-Implementers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-implemen...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ryan Crichton

Lead Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

[gérard Bisama]

Thank you Ryan for the link, I will go through it and will let you know if there is some issue.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-implementers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ryan Crichton

Lead Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

--

Gérard Bisama
Tel:+243810890810

[Carl Leitner]

Thanks Ryan,

I am looping in Luke and Ally as well.   Hopefully we will have a FHIR version of CSD with our “Mobile Care Services Discovery” proposal to IHE.  In there, we are proposing to use the _history transaction for the  “Query for Updated Services (QfUS)” transaction.   We should probably add this transaction as a potential use case to synchronization mediator.

Cheers,

-carl

[gérard Bisama]

Hi Ryan,

I went throught the OpenHIM tutorial and I was able to create mediator and perform all the operation (format adaptation, orchestration) but I had some problem with nodeJs mediator because I was not able to launch the mediator with grunt serve. It seems as if the structure of the generated mediator by yo has changed. Even though I have added some file manually (Gruntfile.js), I am not able to start the mediator.

below is the error message:

server-hit@server-hit:~/Documents/openHIM/tutorialmediator$ grunt serve
Warning: Task "serve" not found. Use --force to continue.
Aborted due to warnings.

Thank you,

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-implementers+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ryan Crichton

Lead Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

--

Gérard Bisama
Tel:+243810890810

[Carl Leitner]

Hi,

Just wanted to point out that this mediator could also be used in an entity matching service use case:

   https://wiki.ohie.org/display/documents/OpenHIE+Entity+Matching+Service

in particular as a part of arrows 1-4 in the workflow diagram.

Looping in Ally as we discussed a facility/health worker matching service on the ILR today:
   https://wiki.ohie.org/display/resources/2016-10-12+InterLinked+Registry+Community+Call

Cheers,

-carl

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-implementers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ryan Crichton

Lead Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

--

Gérard Bisama
Tel:+243810890810