dhis2-devs team mailing list archive

[Murodullo Latifov <murodlatifov@xxxxxxxxx>]

Thanks Bob, I know this, so what it adds to new module? Does it do what it is supposed to do?If it does, what it does?




________________________________
From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
To: Murodullo Latifov <murodlatifov@xxxxxxxxx>
Cc: Jo Størset <storset@xxxxxxxxx>; DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, August 4, 2009 10:04:10 PM
Subject: Re: [Dhis2-devs] DHIS OpenMRS integration




2009/8/4 Murodullo Latifov <murodlatifov@xxxxxxxxx>

Hi Bob,
>
>Output of module would be what we are using for import into DHIS now, so no need to create it in DHIS again. 

This is what is being called DXF.

Cheers
Bob
  

Yes, it would be same ids coming back with value assigned. Changing XML to look like IXF/DXF or SDMX-HD is not a big issue, we can do it in many levels before output.
>
>
>regards,
>murod
>
>
>
________________________________
From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>To: Murodullo Latifov <murodlatifov@xxxxxxxxx>
>Cc: Jo Størset
> <storset@xxxxxxxxx>; DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
>Sent: Tuesday, August 4, 2009 6:40:11 PM
>
>Subject: Re: [Dhis2-devs] DHIS OpenMRS integration
>
>
>>Thanks.  It is very similar to existing dxf (which has the same problematic use of IDs).  What about the data going the other way?  Is it also like DXF?
>
>Regards
>Bob 
>
>
>2009/8/4 Murodullo Latifov <murodlatifov@xxxxxxxxx>
>
>>>Hi Bob,
>>
>>Here is my XML file. I have ids on it, and its problematic as ids differ from implementation to implementation. 
>>
>>regards,
>>murod
>>
>>
>>
>>
________________________________
From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>To: Murodullo Latifov <murodlatifov@xxxxxxxxx>
>>Cc: Jo Størset <storset@xxxxxxxxx>; DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
>>Sent: Tuesday, August 4, 2009
>> 5:31:29 PM
>>
>>Subject: Re: [Dhis2-devs] DHIS OpenMRS integration
>>
>>
>>>>Hi Murod
>>
>>Do you have an example of the XML you are using?  I want to see how far it might be from the DXF we are already using, should it be incorporated or what ... I remember seeing a small snippet but would be good to share a file or two.
>>
>>Regards
>>Bob
>>
>>
>>2009/8/3 Murodullo Latifov <murodlatifov@xxxxxxxxx>
>>
>>Hi,
>>>
>>>
>>>
>>>
>>>>Discussion was mainly around IXF/DXF standards for representing data, which I ignored on my initial implementation, and likely will do so for now. I am concentrated to make systems talk, after we can think of standards. This was agreement with OpenMRS people, who insisted on standards, but after long debates I made them agree to go my way. I am actually using XML for data exchange, which is standard in a sense. Will come back to discussions while progress is made.
>>>
>>>This was not really my impression.  There was a breakout discussion of me, Ola, Murod and Paul (from OpenMRS).  Maybe there were long debates afterwards which I missed.  Anyway the prevailing view was that before we look at a new ad hoc way of doing things we need to be sure that there is not an existing standard way which is adequate.  There was nobody who thought creating a new xml representation just for this openmrs-dhis integration is a good idea.  Unfortunately Ola and I also had not seen Murod's work in advance so it was difficult to present a comon dhis view.  Murod can you share more of what you have done to the wider group? 
>>>
>>>Main issue was and is to map DHIS data to OMRS data. None of listed standards currently provide it. There should be a medium to dictate standard and uniform keys, names, and other attributes for both systems, from all available standards only SDMX-HD has some sample data and is good candidate to provide such service. Parsing is not an issue, validity of content is. That is where systems talk. This standardization is multy step and long process. omrs should follow ICD10 and dhis - SDMX-HD, there should be mapping between SDMX-HD and ICD10. This is my view of standards and might not be correct. Project I created is intended to link two systems in closest possible way, not to build standards or discuss standards. Taking this into account the rest of messages from this line onward are void. When there is proper standard and implementation instructions we can easily shift. 
>>>
>>>
>>>In terms of discussion, the following options were considered regrading
>>> data format:
>>>
>>>1. SDMX_HD - Paul had not been aware of the deficiencies which I had pointed out.  He was also at pains to insist that OpenMRS was not committed to this format yet, but like us, felt that it is better to align with a WHO effort if is feasible.  If its not, he's happy not to go that way.  I asked him to get a second opinion on some of the concerns I had raised from the OpenMRS team.
>>>
>>>2.  IXF - Paul said that IXFv2 did not have the problem which SDMX has - that is that new codes and codelists translate to new attributes in the data exchange schema.  Given that we have both already implemented IXF parsers this might still be the basis of future interoperability.  Ola mentioned that Lars had implemented IXF parser in DHIS but that he cursed it often :-)  Lars you would know best whether this is a good idea or not.
>>>
>>>3.  DXF - we didn't discuss much.  A pity, but time was short. This, or an enhanced version, will be a fallback if 1 and 2 above are not workable.
>>>
>>>4.  Merger of 2 and 3 - this was quite an interesting thought.  One of the problems with SDMX HD is that it is based on an ISO standard.  Meaning that there is only a certain amount of scope to change things for the health domain - much of the rest is fixed by the ISO parent SDMX.  IXF on the other hand can be taken and fixed, developed and improved by its stakeholders.  It might be possible to take DXF and new ideas which have been suggested for DXF2 including elements of Murod's schema for example and develop these as IXFv4. 
>>>
>>>Paul felt we need to create some sort of grid showing the pros and cons of these approaches and discuss on that basis.  There was some possibility of making this interoperability problem a topic of the September OpenMRS implementors meeting in Cape Town.
>>>
>>>Of course all of the above is only formats - there is more to it than that.  Murod did identify the minimum information set that would need to form part of an exchange to get data from OpenMRS into DHIS.  That is useful.  And the idea of writing an OpenMRS module to do the job - rather than waiting for OpenMRS folk to do it - makes standards less critical, but an expensive way to consider interop in general.  Though Paul had some suggestions around how the OpenMRS inference engine should be used which was a bit beyond "beginner" OpenMRS.  And Saptarshi had some thoughts around using the OpenMRS cohort builder to assist with aggregation which I didn't fully understand, but it sounded convincing :-).  We are all agreed that aggregation happens on the OpenMRS side.
>>>
>>>Its a pity we didn't get much to web services and REST.  I guess we used Murod's work as the catalyst for discussion and ended up having lengthy debates on standard vs ad hoc xml instead. 
>>>
>>>Regards
>>>Bob
>>>
>>> 
>>>
>>>
>>>>
>>>>>>>>murod
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>>>Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>>>Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>>>More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>
>>
>
>