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 <murodlati...@yahoo.com> > 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@lists.launchpad.net >> Unsubscribe : >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> More help : https://help.launchpad.net/ListHelp >> > > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
