my apologies, I assumed that because BP didn't export into the format recognized by MD import, it didn't have export facilities, even though it can import from MD's native database format. BP is probably exporting into a human readable export format like xml, and is awaiting the great switchboard application that has the xslt scripts that transform between those application that export ( and one would hope import) their own native xml export format.
On Tue, 2007-04-03 at 08:08 +1000, Cedric Meyerowitz wrote: > Syan, You wrote: "BP don't want MD3 export, because of the usual captured > audience incentive". Absolute Bullsh*t. BP has got an export program. MD3 > hasn't got an import program for BP. Where do you get your misinformation > from ?? > > Cedric > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of syan tan > Sent: Monday, 2 April 2007 8:28 PM > To: General Practice Computing Group Talk > Subject: Re: [GPCG_TALK] backup! - FOSS databases vs entrenched solutions > > > MD3 wouldn't want a BP import , because it might encourage people to try to > export into BP, knowing they could import back to MD3 ( the no back-out > disincentive). BP don't want MD3 export, because of the usual captured > audience incentive. BTW, anyone know if the vendors allow third party > importer-exporters, or how to look at their schemas ? On Mon, 2007-04-02 at > 07:42 +0800, Richard Hosking wrote: > > They did it for business reasons - it had nothing to do with govt > > funding You dont see a BP -> MD3 transfer for the same reason > > > > R > > > > Cedric Meyerowitz wrote: > > > > >Tim > > > > > >These transfers of notes in Australia is possible not due to > > >government funding, but because some software developers did it > > >because we asked. Also MD2 to BP transfers can occur with individual > > >patients. Thirdly as mentioned to Horst, the data from MD3 to BP > > >that don't transfer is things like recalls. And the reason why is > > >not because BP can't, it is an MD3 export problem. Thus so far as > > >MD2 exporting goes you can either do the whole datyaset or individual > > >patients. > > > > > >Cedric > > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] > > >[mailto:[EMAIL PROTECTED] > > >On Behalf Of Tim Churches > > >Sent: Sunday, 1 April 2007 5:14 PM > > >To: General Practice Computing Group Talk > > >Subject: Re: [GPCG_TALK] backup! - FOSS databases vs entrenched solutions > > > > > > > > >Cedric Meyerowitz wrote: > > > > > > > > >>Horts & Greg > > >> > > >>BP will export & import patient files from BP. BP will fully > > >>convert > > >>a whole MD2 dataset from MD2 & import it (& does it so easy and > > >>perfect, that you don't need some-one to hold your hand), BP will > > >>import patients singly from MD3 with all past notes etc present. A > > >>few items don't convert like recalls (because of HCN problems). Now > > >>the opposite does not apply. MD2 won't import patients from BP, nor > will > > >> > > >> > > >MD3 import MD2 as far as we know. > > > > > > > > >>MD3 can't import BP data as far as we know. So some players have tried > > >> > > >> > > >to > > > > > > > > >>make things work, but others hasn't. > > >> > > >>As you know some other players also have conversion programs from > > >>MD2 > > >>to theirs, but the reverse again doesn't apply. > > >> > > >>We were all given a link to an article from the UK. I give the link > > >>again. http://www.ehiprimarycare.com/news/item.cfm?ID=2546 > > >> > > >>Now some feedback from the UK says & I quote: "I guess any good news > > >>has to be promoted by NPfIT but the GP2GP figures don't make as good > > >>reading when you realise it only includes EMIS and INPS systems and > > >>80% of those are EMIS. Where's TPP, iSOFT, etc? OK if you transfer > > >>from on EMIS practise to another but not if you move to a non-EMIS > > >>practise". > > >> > > >>So in Australia if a patient moves from BP practice to BP practice - > > >>we are okay, if from MD2 to BP and a few others, then we are better > > >>than the UK as coversions from MD2 to a few software packages already > > >>exist(in UK currently only has 2 systems involved). And if patient > > >>moves from MD3 to BP we are also okay - and this is without government > > >>funding. Yet this list got rather excited about the UK development, > > >>forgetting that here down under things are not so bad. > > >> > > >> > > > > > >Cedric, > > > > > >If I am reading what you say above correct, it seems that *no* > > >heterogeneous pair of Australian GP clinical systems can completely > > >transfer data for a single patient from one to the other: > > > > > >MD2->BP: whole database only > > >MD3->BP: single patient data transfer possible but not everything is > > >transferred. > > >BP->MD2 or MD3: nope > > > > > >So how exactly is that better than the UK? > > > > > >BTW, whole database conversions between other packages in the UK do > > >also exist - however the GP2GP programme is all about on-demand > > >transfer of all data about an individual patient, via the NHS network > > >backbone, and the completeness and integrity of the transfers is > > >independently and fairly exhaustively tested and validated by the NHS > > >IT authority. > > > > > >Tim C > > > > > > > > > > > >>-----Original Message----- > > >>From: [EMAIL PROTECTED] > > >>[mailto:[EMAIL PROTECTED] > > >>On Behalf Of Greg Twyford > > >>Sent: Thursday, 29 March 2007 4:31 PM > > >>To: General Practice Computing Group Talk > > >>Subject: Re: [GPCG_TALK] backup! - FOSS databases vs entrenched > solutions > > >> > > >> > > >>Horst Herb wrote: > > >> > > >> > > >> > > >>>There is choice as long as you are not locked in - and currently > > >>>virtually every single GP you ask when questioned why not chnagng > > >>>the product they seem to detest so much is that there is no safe > > >>>and easy migration path to alternatives > > >>> > > >>> > > >>Horst, > > >> > > >>This is an interesting but depressing observation in the context of > > >>the > > >>discussion in hand. > > >> > > >>What you have really touched on is the stagnation of the GP clinical > > >>system marketplace because a real path forward can't be identified. > > >>All the paths on offer seem to risk leading back to a similar > > >>quagmire. > > >> > > >>I think that any new players will have to look very carefully at > > >>what they offer, and it seems to me that if Simon's two new players > > >>end up producing two new versions of the 'same-old, same-old', then > > >>their chances of surviving are very poor indeed. > > >> > > >>Every new player claims revolutionary new features and unparalleled > > >>functionality and stability, but I think the market has become jaded > > >>by such claims, which they've heard ad nauseam, hence the > > >>stagnation. > > >> > > >>Contrary to what Simon has asserted, a really radical FOSS solution > > >>might work in gaining market share, but that leaves us wondering > > >>where it will emerge from. > > >> > > >>Greg > > >> > > >> > > > > > >_______________________________________________ > > >Gpcg_talk mailing list > > >[email protected] > > >http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > > > > > >_______________________________________________ > > >Gpcg_talk mailing list > > >[email protected] > > >http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > > > > > > > > _______________________________________________ > > Gpcg_talk mailing list > > [email protected] > > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > _______________________________________________ > Gpcg_talk mailing list > [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
