Tony Eviston wrote: > Tim Churches wrote: > >> 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. > > Will the application from which a test is ordered or a referral made > always be the application which consumes the report? > I think the way of the future is less monolithic (which is virtually > synonymous with closed systems at present) and more modular.
Sure, we should really be thinking of clinical "meta-applications" which are a collective of modules which all have access to a common data store. Secure messaging would be just one of those modules, along with alerting, decision support, the main point-of-care clinical interface, the reception/admin interface module and so on. That's always been the promise of modular software, but it never seems to happen in practice. In the meantime, we have monolithic applications, or at best suites of plug-in modules from individual vendors. CORBA and CORBAmed was an attempt to make such modularity a reality, but it never took off - too complex for small developers and the larger vendors all realised that it might actually work, which would have been curtains for their market shares. SOAP and derivatives have not really filled the shoes of CORBA, although they are more popular - but still much too complex, without the advantages of CORBA. Hence the rise of "Web 2.0" lightweight, easy to understand and implement interfaces, like JSON and other AJAX microformats. Not in medical Web applications yet, but they will arrive soon, I suspect. > It would be nice to be able to stream returning data to more than one > application or even to purposefully block reports being consumed by an > application which won't allow secondary use of the data. Yes, a "switchboard" to stream messages is still needed. But as discussed, a particular message might look good to one application but look invalid to another, so one message is then both ACKed and NACKed. Nothing is simple. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
