Ian Haywood wrote: > Can I draw you out on this a little, john? > > What sort of interfaces would need to exist at your end? What > platforms? Would you have a daemon/service that scans a directory for > files dumped by a local app (essentially the reverse of the GP > system)? What sort of files? Do local path systems produce PIT > directly? Is the MLLP (simple HL7 over TCP) used at all? Or would you > need some form of GUI for your typist to enter in reports directly? > Or does the typist insist on Word? (as for other specialists) > > > Ian _______________________________________________ Gpcg_talk mailing > list [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >
Sure, my end is a proprietary software system running in a virtual machine on an obscure database (pick 3/raining data/ D3NT). Recently I had to get the coders involved to add "page1/2" on the bottom of the report (no small feat as it turned out). Theres not a lot I can do, and support costs roughly $140 per hour inc gst. Its delicate, somewhat buggy and when altered generally a 2 steps forward one back kind of situation. Rather than word, the text based lims has been extended with a TxTextcontrol ocx extension and some custom delphi using that tool to make a miniword bolt on that reports get entered into. With this I use dragondictate to enter my reports. I had some "issues" about whether the ability to produce PIT and HL7 came with the system or was an extra$$ addon. Lets say I made it clear from the first call PIT and HL7 production were expected as part of the core system and have stood firm... All reports are "in the lims, and report generation is very separate from delivery" and the sytem handles all the billing, copy to reports etc. Its quite complicated to set up a Dr to be either HL7 or PIT in report formats and each get dumped into either an HL7 directory or a PIT directory. They are generated by tagging drs as electronic and or paper and setting them for either HL7 or PIT (its not quite that simple but thats close enough). For Pit: the files are tagged with a unique filename containing the surgery code of the target (which I chose to be easy to parse). The pit files then get magically parsed and a recipient header line added at the beginning of the file (i wrote the ghetto python code to do this to bridge the LIMS and delivery application) to suit the third party delivery app, moved into a directory over a network share and sent out hourly by the third party app. I have some logging in this but its not collated (all the electronic results for practices are duplicated in hardcopy at present and the party line is "hardcopy is the gold standard"), electronic is nice but on trial and shouldnt be trusted. For HL7 (been trialling a few weeks now): reports just get picked up and sent out in minutes/seconds by Medical Objects when it polls the directory, and the HL7 files are placed into a firebird database locally running on my server (meaning all sent results via MO are in a local searchable database in compliant HL7 totally separate to the LIMS = insurance policy) and they are tracked to the target machine and available for me to monitor review etc in the MO viewing suite Meridian in a couple of mouse clicks. As a bonus I have windows fax services running on the server,have dumped the Dr database into a windows address book and can fax any report in a few mouseclicks via windows print to fax (not automatic but not fully manual). Im in the process of migrating to MO fully. For me its easier. I cannot write my own, the LIMS has a suite to do the same job which is also proprietary and also an autofax option etc but also buying both those would push the costs of software alone to date over $50k for one specialist (and Im cash poor at present). At the time I was looking I couldnt find any alternatives cost wise or infrastructure wise. The system is in fact a fully capable LIMS system, needs to interface to things such as blockwriters, zebra printers etc and is capable of interfacing chemistry analysers etc. You cannot just "go genie" or similar if you need to speak to these instruments. Its old old code but has a track record. At my end in an ideal world, the report status will get fed back into the lims with an audit trail of the movements of the report. My world aint ideal at present and I dont think thats likely to happen short term. Certainly tracking is available within MO that does this. I think MO will be holding that data separately for a while. Also, my world is waaaaay less complicated than the Big Firms IT systems and unlike like me they are trying to satisfy all those end users PLUS they are also trying to satisfy a multitude of systems in house across diverse locations and not lose stuff. Certainly my architecture is shallow in comparison and their mainframes cost a fortuna (already invested and ongoing). Problems come with having multiple delivery methods going but it would be doable. Basically polling a PIT directory would work. The PIT files are standard pit (finally - another long IT story), with multiple Drs and reports in batches. I could split the Pit with different headers into say PMsurgery and OPGPsurgery and alter the python code to parse out the various header choices and then handle those methods as appropriately thus including an OPGP email handler. But thats too far for me technically (newbie) and I have no time. Also, ideally those files should be tracked and married with an ack and reports generated about non acked batches. So suddenly Im looking at a second (PIT report) database to manage that and the project climbs an order of magnitude plus code wise to do those things. And then, it would be nice to have some smarts between here and there so I could test if "there" is alive or not. Plus it has to be tested and a client end interface sorted. Of course I realise there is nothing that money in buckets cannot achieve. Send me some buckets ;) gotta run late JD -- ================================================= dr john dooley mbbs frcpa aka "ron" _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
