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
