OpenMRS Leadership Call 2016-01-07

Hi All,

We have a leadership call scheduled for this Thursday, January 7. If you normally attend but can not this week please let me know. Also if there are any additional topics or updates you would like to see on this agenda or a future agenda please let me know.

Agenda

Parking Lot (Due to insufficient time some topics have been moved to a future call. If you feel like something should be made a priority for this weeks agenda please post to this thread.)

Notes: http://notes.openmrs.org/LeadershipCall-2016-01-07

If members from the community would like to see a specific agenda item added to the topic queue or would like to join an upcoming leadership call please reach out to @jthomas

Hi Jamie,

We have an all-day meeting at work, so most likely I can not attend.

Thanks,

Jonathan

Hi Jamie I am still on annual leave and won’t be on the call this week. I should be able to attend next week. All the best Chris

A quick reference point for the conversation today on licensing:

https://www.fsf.org/blogs/licensing/mpl-2.0-release

This approach to license compatibility is cleaner and more consistent than releasing software under multiple licenses. It can easily scale to support even more licenses—and MPL 2.0 does that by adding compatibility with AGPL version 3 or later. By making compatibility the default policy, it encourages other projects using the MPL to follow Mozilla’s lead (though they have the option to opt out if they wish).

…and:

1 Like

I won’t be able to attend this week or next, but from the 21st I should be able to attend regularly again since I’ll be on Pacific Time.

Monthly CDC call today so I can make only the first 1/2 hour of the OpenMRS call

Bill

Thanks Paul - I think this supports what you posted above.

Here’s GNU’s take on compatibility with MPL (scroll down). http://www.gnu.org/licenses/license-list.en.html

And FSF’s. https://www.fsf.org/blogs/licensing/mpl-2.0-release

As near as I could tell, out additional disclaimer to MPL 2.0 does not contain any language restricting secondary licensing (see GNU comments - that is the one possibility that makes GPL incompatible w MPL 2) http://openmrs.org/license/

1 Like

I see I left off my conclusion - my conclusion (based on a very superficial read) was that there’s nothing to prevent Bahmni from incorporating the OpenMRS MPL 2.0 code, and since that code doesn’t have any restrictions on secondary licensing…

There then is nothing to prevent TW from re-licensing the incorporated OpenMRS code with Bahmni code under AGPL.

In which case, anyone can use and relicense the Bahmni code (including that incorporating OpenMRS) under the AGPL terms.

That implies that the terms of using Bahmni w/ OpenMRS change from MPL 2 to AGPL, at least the way I understand it.

Hi all, per our conversation today:

The EMR concept note: https://docs.google.com/document/d/1d0qogJUcwpGaqbpl8M-3QxnGPZZdVwfRO8MBX96AnQY/edit

The case-based surveillance concept note: https://docs.google.com/document/d/1GZIqWrWiyfeBGpMIHBjDLS1Cw85QeOfZALiJIkJ8DDc/edit#heading=h.qxz1babitxel

…and the email:

Greetings Patient-Centered Surveillance and EMR Teams!

Congratulations, your concept notes have been identified to move forward to the next stage of the Health Information Systems Interoperability collaborative design process!

In the coming weeks, I will be your point of contact for further collaboration, iteration, and merging of your concept notes. Please note that this is hopefully the ONLY email you will receive from me! Let’s move the rest of this discussion and process to Slack! Right now I am only emailing the people who were involved in the original development of the concept notes as well as those who expressed interested in joining. I have created a private Slack channel and will be adding this group to it for starters. However, please note that many other people have expressed interest in the co-development of this note and we plan to include at least some of them on future communication. More to come on this …

To get your note ready to move to the Peer Review Board, I would like you to start taking it from note/ outline form to a more formal proposal. Let’s plan to work collaboratively on this process - we are taking the lead for now because we know the process and what potential donors are looking for, but consider us a participant in this next process, since our primary role is as your advocate.

Our team has come up with the following questions for you to answer in the document / consider as you flesh out your concepts:

Merging

As noted above, after consideration on the technical merit as well as the “fundability” of concept notes, we believe merging these two notes would lead to the best outcome. We see Patient-Centered Surveillance as having the most compelling idea, with a clear demand for IDSR in the region by both national ministries and regional bodies and EMR as having a more established technology platform that can influence and potentially innovate on the struggles of accomplishing digital IDSR. Our initial ask is to fold the EMR idea into Patient-Centered Surveillance, with more detailed technical questions / suggestions listed below.

Specific to Patient-Centered Surveillance: You mention developing tools that will expand the OpenHIE framework. Can you elaborate more on the tools that you are proposing to develop? In “assumptions” you write: The country will have the ability to make evidence based decisions on a more real-time basis using a richer source of information. and Other HIS systems are able to absorb patient level data. Where does the patient-level data come from and how will it be richer? We are inclined to think this is about digital patient records as a component of the HIS ecosystem in a country, and see a benefit towards linking this to EMR elements that may already exist or need to be further developed at a national or county/district level. “Community health workers and facility will be able to track patients”: Again, how would one do this differently? This is where the strength of merging with the EMR concept note could really shine through and make this concept note more competitive. If you disagree, please quickly provide more detailed alternatives as this is the ‘meat’ of the proposal. The technical/regional working group (mentioned in stakeholders) is a tried and true solution, but slow to move - how can you innovate on this model slightly to increase its effectiveness? Is an extra assessment of ICT infrastructure really a necessary activity, given the co-authors’ knowledge of tools deployed in the region, resources presented by the Ministries, and the developed capacity of the different MoH requirement for buy-in all potentially available to alleviate the need/burden for additional assessment work? “Digitize existing data” - how and where? Again we are thinking this is where the strength/linkage to the EMR proposal would be most optimal. The further development of EMR tools to fulfill the IDSR-service gaps is compelling. “Providing an improved ICT infrastructure”: what is meant here? - can we be more specific around equipment versus connectivity infrastructure, etc? Do you anticipate this to be software development support to integrate HIS systems versus physical ICT equipment and capacity? Does it require both? What is the budget you ball-park estimate in relation to all of the activities outlined in this proposal? “Providing standard for continuous ICT assessment.” Is this about measuring ‘up-time’ of a system? Can this be elaborated on more?

Specific to EMR: This proposes the adoption a ‘new system’ versus proposing interoperability within already exiting HIS and MRS systems. How can this instead be built into already deployed or existing systems, while ensuring integration and interoperability with other systems? For the record, HDX already exists but is currently the “Humanitarian Data Exchange” by UNOCHA, although there is a lot of health data (including facilities, workforce, and event-data) currently in their for specific scenarios. Pls do a bit more research into this and expand on how this is different / how your proposed plan would interact with HDX. There was a lack of clarity on how the EMR system would align the Principles of Digital Development in building off of what already exists and participating in the Community of Practice with the existing HIS Technical Working Groups for each of the Ebola Affected Countries. What other members of those deploying systems in these countries and communities were able to contribute/review this note? A compelling incentive for EMR development in a country could really make a difference with regards to digitization/EMR. The IDSR use-case could benefit from the ‘lower-level’ technology and interoperability themes outlined in this concept note. We are thinking merging the ‘application’ of IDSR with the ‘platform’ of EMR could make a compelling case to the review board - if it is done in such a way that champions interoperability towards the greater HIS ecosystem in a country versus the stove-pipe eDEWS and pre-existing digital eIDSR tools already deployed.

Other general considerations: Any thoughts on a rough budget (i.e. a high-level number with a few specific line items) Scope, are there specific countries where these technologies are already maturely deployed and could fuse the need for IDSR and further development of EMR systems? If so, how does the stakeholders list change and what contacts, groups, or resources would be added? Sustainability considerations - how will this concept be carried forward?

Let’s plan to do this over Slack and Google Docs for now and tentatively plan for a phone call in the coming 2 weeks. Please begin by posting your availability for a call in that time frame on Slack.

So, in summary! Next steps: Let me know if you are not able to access Slack so I can send you a personal invitation. Start responding to the above questions to merge and flesh out the concept notes further. Find a time for a phone call over the next two weeks to discuss. A member of the USAID team will join as well.

Thanks again for your collaboration and I’m looking forward to pushing this note forward to the Peer Review Board with you!

This was my comments to the Slack channel this morning:

some quick comments regarding Rebecca’s email to us on January 5th:

I helped found OpenMRS and OpenHIE, so biased from those historical perspectives…

I have never directly participated in IDSR activities, but from what I understand… they involve collecting and sharing fairly discrete clinical information about an at-risk individual’s health as well as relating that individual to a collection of contacts

different individuals collect different parts of this “virtual record” at different points in time

everyone seemingly would benefit from access to this virtual record while it’s being developed

so there are likely a collection of data generators and variable technologies that would be used to all participate in this collection process

one way to think about this, IMO, is to think of a foundational data model (that is Ebola agnostic) for the IDSR record… I think the 11+ years of community experience around clinical record data models from OpenMRS could be useful here… in fact, I’d be surprised if IDSR couldn’t be 100% supported with the OpenMRS data model.(edited) 1

additionally, it would be important to come up with some standardized transactions from these data generating apps that could consistently augment these IDSR records as they’re being developed, and query the existing data… this is something that OpenHIE tries to facilitate for the global health community through it’s work with IHE and other standards development organizations

I can’t tell whether the awards being contemplated here are for actual implementations within the three Ebola-affected countries, or for foundational technical work to enable implementations downstream

if it’s the latter (which seems more likely), then I’d argue for starting with some pre-existing data sharing workflows already released by OpenHIE:

https://wiki.ohie.org/display/documents/Save+patient-level+clinical+data+workflow+-+V1.0

and: https://wiki.ohie.org/display/documents/Query+patient-level+clinical+data+workflow+-+V1.0

I suspect that they could be somewhat simplified for this use case, but there’s a lot of good work already done here which could be helpful

additionally, I’d find a way to work with some key applications which already exist in the affected countries to have the technical capacity to send and receive these kinds of standardized messages 1

Hope this is helpful!

1 Like

Sorry, folks. Missed today because of a last minute all day meeting at IMO :frowning: