Jonathan Jackson Aug 21 (5 days ago) to me, Amelia Hey Lauren, I realized never played through the HL7 question yesterday. I do think this would be a useful module to have created but could end up being an arbitrarily large amount of work and we won't be able to give good requirements on how far we should take it (at least for the particular project we need it for) since the answer is "to check a box." I'm not sure how to evaluate whether: a) its worth doing on your side or b) its worth doing on our side in MOTECH (likely not sense its not real enough to learn much from). Lauren Lavoie Aug 21 (5 days ago) to Jonathan, Amelia Hey Jon, How can I/we find out more details of what would be required to "check the box"? i.e. what version of HL7, what does the module actually need to do, etc. Also, could you remind me who the customer is that requires HL7? From our perspective, HL7 support has always been one of those things on the long term backlog that never bubbled to the top because no real customer has needed it. I don't think it would be super hard for us to develop a module that exposes an endpoint where someone can post HL7, we parse it, and we raise an event (that any implementation module could handle, or could be wired up via Tasks). There are open source libraries we could investigate that would do most of the work for us. But I don't know whether that's practically useful, or whether it would meet this particular customer's requirement. We're always hesitant to add code to the platform that no one will actually use, but we could make an exception if that checkbox really is a dealbreaker for the particular customer. And I bet this is a project we could get Bruce and his team excited about. :) Thanks, L Jonathan Jackson Aug 21 (5 days ago) to Cory, Simon, me, Amelia Hi Lauren - I agree this could be a good task for someone on Bruce's team. Would that take away from dhis2 capacity or is it more efficient to have one student one project? I've written a quick spec here: https://docs.google.com/a/dimagi.com/document/d/1fxfPHLPmkn6MNX_FsnSP2NuJlb05r-4OLQEcnsZjvRo/edit# and I'm adding a few dev team members from our end who are looking to resolve this answer. If you could review and let us know your thought, that would be great. Also, this is not particularly urgent aside form having a clear plan to provide back to the client. But if the commitment was to have HL7 integration in 6 months or later, I don't think that will be a problem. -J Jonathan L. Jackson Chief Executive Officer Dimagi, Inc | 585 Massachusetts Ave | Suite 3 | Cambridge, MA 02139 t: (617) 649 2214 | m: (617) 596 6243 web: http://www.dimagi.com/ Attachments area Preview attachment HL7 Spec Google Docs HL7 Spec Simon Kelly Aug 22 (4 days ago) to Jonathan, me, Cory, Amelia Hi Jon That spec looks good as a start. One piece that I'm still very unclear on is how and where the mapping of case data to specific HL7 elements happens. Since each project will have different case data there is no way to do a once off mapping. Perhaps for the purpose of 'checking the box' we could produce a message that contains only generic data such as date and author. Jonathan Jackson Aug 22 (4 days ago) to Simon, me, Cory, Amelia Hi Simon, I added this to the doc below. I'm under the impression that HL7 has a place where you can just dump content that you don't want to really map to HL7, like one gigantic custom field. So, it a fairly ridiculous "check the box" example, we would make sure the envelop is properly formatted, has only the generic things, and then there is one field in the custom section that is key 'commcare' data with the value of the entire xml document. - J Mapping In the case of custom code in CommCare or MOTECH, the generation of the HL7 message based on incoming data from CommCare would be completely custom card and hard coded to the specific content of that CommCare app. In the case of a generic module, there would need to be an UI or markup file that allows you to specific what field in CommCare maps to which HL7 section. If we do this in CommCare, it would likely be a dedicated screen. If we do this in MOTECH, the mapping woud be done in the tasks module connect fields from the CommCare module to fields in the HL7 module. Either way, each mapping would be unique to the CommCare app. Lauren Lavoie 1:29 PM (8 minutes ago) to Jonathan, Simon, Cory, Amelia Thanks for the spec, Jon - this is helpful in terms of clarifying what would be desired from Dimagi's perspective. It sounds like, at least for now, a MOTECH module that could create/send HL7 messages would suffice (i.e. it doesn't need to receive/parse HL7 for this use case). I agree that the Tasks module would be the right place to define the mapping. To your resourcing question - if we gave this to Bruce's team, yes it could detract from DHIS2 work depending on the timing. It also would be perfectly fine from our perspective to have SolDevelo pick this up. We can decide when we get closer to scheduling the work. In the meantime I'll create a ticket and assign it to myself to write a spec. I'm assuming based on your comments earlier in this thread that if we can't schedule this until early 2015 that will be ok. Thanks, L