dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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<https://launchpad.net/%7Edhis2-devs>
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>>
>>
>>
>
>