Greg Twyford wrote: > Tim Churches wrote: >> The Internet works as well as it does because all the smarts are at the >> edges, in the applications, not in the actual Internet networking >> infrastructure itself, which is very simple (and hence reliable and >> scalable, given the immense scale of the thing). So it should be with >> clinical messaging - let the oversight function for messaging, which >> ensures its reliability and safety, be built into the clinical >> applications, and have the simplest possible transport mechanism in >> between. > > Tim, > > A couple of things come to mind from what you've said. Firstly, that we > shouldn't be seeing secure messaging as something separate from an > electronic health record at all, and the future for all the messaging > guys may be to provide the functionality for the clinical guys. Now > which one of the messaging methods is the question.
I would question why "secure medical messaging" is seen as a small industry unto itself. If there are a clear set of standards and technologies for secure messaging, then all those things can be built right into clinical applications, and an additional layer just for "secure messaging" is not needed. Just like encryption is built into your Web browser and the Web servers it talks to. There is no separate layer of applications which just does encryption of HTTP exchanges - all the necessary software libraries and layers are all built right in. The separate raft of messaging providers we have now only exist because there are no annointed standards for secure health messaging, IMHO - they are a temporary phase (so is life...). > It would also seem to mitigate against storing stuff outside the > applications, in line with your Internet analogy. Except for E-mail, of > course. Funny that. There are lots of legacies, and email is one of them. > Further, as others have said some time ago, none of this assures anyone > that the clinician has seen the relevant report. I previously menioned > that MD, at present, allows clinicians to check if there are any results > outstanding for tests ordered. The clinician then must check the list, > which seems to me entirely reasonable. > > Automated pop-ups could be added that trigger after a time if no > matching result has been received for various categories of tests. > Nonetheless, the clinician then has to initiate follow-up on the missing > result. I don't see how that can be avoided. I'm just wondering how much > more can be done at the application level? Sure, but where is the best place to build in such alerts - in the clinical application, which has access to all the necessary data, or in the secure messaging conduit software like, say, Argus Connect or the Healthlink client application? I would suggest that the former is the sensible place, along with all the other decision support and quality assurance tools that good clinical software ought to have. > The other thing this situation reminds me of is when you had to get a > copy of Trumpet Winsock if you wanted to have a dial-up Internet > connection work with Windows 3.1. Except that that we have many more > clinical software vendors with far smaller client bases, and there is no > standard functionality that can be added to all flavours of the > software, so moving onto an integrated model, will be much, much harder, > I would think. Yes, exactly like Trumpet Winsock. A passing phase. Now TCP/IP is built in every operating system, and SSL encryption is built into ever Web browser. So should standards-based secure messaging be built into every clinical application. But we do need some annointed standards... > In the meantime, maybe messaging level acks and nacks will be around for > some time yet? Sure. No need to remove them, they do no harm at all and often do good. Just supplement them with application level ACKS and NACKs as well - it is not either/or, both can co-exist. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
