In lieu of the calls today being cancelled we wanted to raise a few thoughts here in both communities around documentation and access to information. Within the IOL community we wanted to raise the topic of “Build your own mediators” (and we could look at mirroring the thoughts with the CDA document processors when we get to it with the SHR).
The team and community has done some work in making sure that architecturally and technically we are able to leverage self built mediators in an implementation; now we need to critically review how well we are communicating that to interested parties and identify better ways of promoting this pattern.
We would like to invite constructive observations of how we are promoting this and how we could do this better.
Aaaaannnnnddddd GO!
Cheers
···
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail:carl.fourie@jembi.org
There’s a pretty good start on the OpenHIM website. There’s a nascent implementer’s mailing list, and some good starting tutorials. I was imagining having a couple of archetypes available for basic mediator functions that could be modified by end users. For example, you do a tutorial for a “pass through”, but would be great if that mediator could be packaged into a release, alongside with documentation on how it can be modified to have additional functionality.
While I think it’s great that the code allows the mediators to be represented with different programming paradigms, I think there’s benefit to having some default choices that nudge the community in a direction or two (“while we allow many different coding frameworks, we recommend and have examples for the following”). That way, you can start to seed some specific knowledge bases within the community around an approach or two.
Hope that helps,
-Paul
···
On Tue, Jun 9, 2015 at 6:00 AM, Carl Fourie carl@jembi.org wrote:
Hi All
In lieu of the calls today being cancelled we wanted to raise a few thoughts here in both communities around documentation and access to information. Within the IOL community we wanted to raise the topic of “Build your own mediators” (and we could look at mirroring the thoughts with the CDA document processors when we get to it with the SHR).
The team and community has done some work in making sure that architecturally and technically we are able to leverage self built mediators in an implementation; now we need to critically review how well we are communicating that to interested parties and identify better ways of promoting this pattern.
We would like to invite constructive observations of how we are promoting this and how we could do this better.
Aaaaannnnnddddd GO!
Cheers
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail:carl.fourie@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
I concur with Paul’s comments. A couple additional observations:
I notice that some of the mediators support the Rwanda implementation. For example, does the OpenEMPI mediator work with the latest version of OpenHIM? Or is that mediator specifically designed for an earlier version of OpenHIM? Clarification would
be helpful so that the uninitiated are clear about the current technology, and aren’t misdirected to prior versions.
The interoperability layer is an amazing piece of technology that supports inherently complex processes. While we can’t avoid complexity, I wonder if there is value in a high level introduction to “what are mediators" and “what are the strategies for
creating a new one”. The current OpenHIM mediator page does a great job of showing examples of mediators, but I’m not sure I see I general outline for the process of creating a new mediator. So, simply providing high-level, step-by-step guidance likely will
provide value.
Hope this helps,
Shaun
···
On Tue, Jun 9, 2015 at 6:00 AM, Carl Fourie carl@jembi.org wrote:
Hi All
In lieu of the calls today being cancelled we wanted to raise a few thoughts here in both communities around documentation and access to information. Within the IOL community we wanted to raise the topic of “Build your own mediators”
(and we could look at mirroring the thoughts with the CDA document processors when we get to it with the SHR).
The team and community has done some work in making sure that architecturally and technically we are able to leverage self built mediators in an implementation; now we need to critically review how well we are communicating that to
interested parties and identify better ways of promoting this pattern.
We would like to invite constructive observations of how we are promoting this and how we could do this better.
Aaaaannnnnddddd GO!
Cheers
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile:
+27 71 540 4477 | Office:
+27 21 701 0939 | Skype: carl.fourie17 E-mail:carl.fourie@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Thanks for the great feedback. I believe we do have a lot of the information that you are asking for, but perhaps it is not in a format that is easily consumable. For example the tutorials go through the details of getting your first mediator up and they do make use of yeoman for scaffolding a new project (the scaffolding supports both Java and Node/JavaScript - our default go to recommendations). Perhaps what we need is to make this more consumable rather than being buried in text in the tutorials. I’m considering doing a series of screencasts that go through the details of creating mediators and how to generate the project scaffolding. What do you think about that? Would that address some of your concerns?
@Shaun, many of the RHEA mediators will technically work with the new OpenHIM, however, they won’t make use of the latest, useful features of the new OpenHIM. Also, they will likely not be very useful outside of the RHEA project. I agree perhaps creating a better distinction between these would help. The pages that describe how to create mediators can be found here and here.
I think if we tie together some of the current documentation and provide some video tutorials that may put us in a better place. Do you guys agree or do you think we are missing some information that would make this easier to understand.
I concur with Paul’s comments. A couple additional observations:
I notice that some of the mediators support the Rwanda implementation. For example, does the OpenEMPI mediator work with the latest version of OpenHIM? Or is that mediator specifically designed for an earlier version of OpenHIM? Clarification would
be helpful so that the uninitiated are clear about the current technology, and aren’t misdirected to prior versions.
The interoperability layer is an amazing piece of technology that supports inherently complex processes. While we can’t avoid complexity, I wonder if there is value in a high level introduction to “what are mediators" and “what are the strategies for
creating a new one”. The current OpenHIM mediator page does a great job of showing examples of mediators, but I’m not sure I see I general outline for the process of creating a new mediator. So, simply providing high-level, step-by-step guidance likely will
provide value.
Subject: Re: Discussion points: Building your own mediators and content processors
Hi Carl,
There’s a pretty good start on the OpenHIM website. There’s a nascent implementer’s mailing list, and some good starting tutorials. I was imagining having a couple of archetypes available for basic mediator functions that could be modified by end users.
For example, you do a tutorial for a “pass through”, but would be great if that mediator could be packaged into a release, alongside with documentation on how it can be modified to have additional functionality.
While I think it’s great that the code allows the mediators to be represented with different programming paradigms, I think there’s benefit to having some default choices that nudge the community in a direction or two (“while we allow many different coding
frameworks, we recommend and have examples for the following”). That way, you can start to seed some specific knowledge bases within the community around an approach or two.
Hope that helps,
-Paul
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
On Tue, Jun 9, 2015 at 6:00 AM, Carl Fourie carl@jembi.org wrote:
Hi All
In lieu of the calls today being cancelled we wanted to raise a few thoughts here in both communities around documentation and access to information. Within the IOL community we wanted to raise the topic of “Build your own mediators”
(and we could look at mirroring the thoughts with the CDA document processors when we get to it with the SHR).
The team and community has done some work in making sure that architecturally and technically we are able to leverage self built mediators in an implementation; now we need to critically review how well we are communicating that to
interested parties and identify better ways of promoting this pattern.
We would like to invite constructive observations of how we are promoting this and how we could do this better.
Aaaaannnnnddddd GO!
Cheers
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile:
+27 71 540 4477 | Office:
+27 21 701 0939 | Skype: carl.fourie17 E-mail:carl.fourie@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to