On Friday 13 June 2003 16:37, you wrote: > quote from Adrian's letter to BMJ: (leaving out the very nice > FUD busting parts :-) http://bmj.com/cgi/eletters/321/7267/976#10466 The FUD-bust is the main point of that, but I don't mind branching out of course.
> ----------- begin quote > EMIS, Meditel System 5 and 6000, Torex Premiere and IPS Vision > all have scripting languages or reasonable susbtitutes. The > Exeter System has the ability to have macros > ... > GPASS-2 with its open API (half a level of virtue down from > the apex that is Open Source code) allows third parties > including competent users to write widgets that add items to > the medical record > ... > ------------- end quote > I agree with you that customizability by clinicians is an > important feature and many UK systems have tried to provide > this feature. They have _undoubtedly succeeded_ . remember that when the Exeter System was first capable of allowing GPs to discard paper for records, I was programming in Fortran 4 by punching cards. That nowadays I would hope to write scripts in Python or another VHL programming language, and that there might even be pick and mix interfaces to help form the grammar doesn't suggest they should be replaced although it may mandate the addition of a layer of translation on top of the potent horror that is M. > 1) Were the "scripting languages" easy enough to learn and > use? EMIS provided two systems:- "templates" which allow the production of a form which is populated from the existing contents of the database and allows entry in an organised fashion with I believe some constraints (BP=1600/80 think again) and I think some underlying intelligence (if the last BP was normal and within a month don't ask for another one) These as I understand are easy to draw, needing only a clear idea of what one is trying to achieve, the form the form should be in, and having the manual open to the correct page. "protocols" which prompt in some instances (on entry of a Read code G20 run HT protocol) allow the user to choose to submit to or escape from an enforced series of steps, with branching logic. This is a formal programming task, IMHO, and cannot reasonably be expected to be _easy_ but it is clear that of the 40% of the UK's 30 000 GPs who use EMIS, there are at least more who have tackled this task than there are of us on the OpenHealth list. Meditel in System 5 and 6000 and moving on into the Torex products provided a means of programming SOPHIES in the Sculptor toolkit for the underlying C language and proprietary database. Again, this is not the sort of thing that one would expect to be _easy_ but is the sort of thing that is immensely powerful. A number of GPs for each of whom I have respect, but who I do not regard as intellectual giants beyond our common touch, have written major components of their practice automation, drug company research automation and the like, and an unguessed number more have made widgets to ensure something is done in a particular way. Examples of the latter include a single key entry of an Influenza immunisation producing a suitable record, a prescription, and a claim for payment. The M- based Exeter GP system has the facility to add new screens, some of which can be defined by the user - since they have all the source code if they know M nobody can stop them from adding whatevr they feel like, but in practice M is hard enough that I doubt this happened often. The company, being originally owned by the practices that commissioned the system, was responsive to requests, but any individual request for elaboration might fail to get attention if only one practice wanted it - a common failing of any collaborative enterprise. The old Clipper and DOS-based system I used had a facility to produce templates, and as time went on I added certain external programs to look at the information saved from those templates, or as one might say "forms" - however, in common with all of these systems every item going into these forms was either defined as a shared term with all other UK GPs, a feature that nobody who has worked in this field can overstress the value of, or was explicitly a user-created ad hoc data-type... which again, is something that has value, but the precise extent of that value and the dangers of mistaking or failing to convert one for the other is crucially important in the long run. Other systems I know less about. > 2) Were the resulting scripts and macros portable across > sites and installations - allowing re-use and collaborative > development? Yes. The manner in which these moved varied from system to system and among user-communities in ways which are neither interesting nor important. The specific point worth learning is in the handling of ad hoc data types created in order to use a particualr template or script. Clearly these had to be exported and imported, and the ways in whcih these are linked to or supplement the clinical terms thesaurus (CTT) and if they have lasting value are imported into the CTT is complex, administratively difficult and requires careful thought and diplomatic activity. > 3) Were these systems disseminated and developed as Free > software - allowing modification of the scripting language > itself and execution engine over time? This is a discussion of proprietary systems, raised initially to point out that the FUD element of "anyone may modify the algorithms" is no more a problem for FLOSS than it has been for 30 years for Proprietary systems in use by 30 000 GPs in 10 000 Practices. (IE no, and there is no difference in the liability aspect. Whether there is a difference in the desirable features _except_ lockin to a single system may be worth exploring, but seems to me to be a very theoretical excursion) I roughed out a specification " a program should exist which" reads the existing protocols, SOPHIEs, Premiere equivalent, Vision Guidelines etc into a metalanguage and displays that as a Visio type interface (Meditel produced such an interface for editing SOPHIEs), and can write out a script edited in itself into each of the forms. This would allow one person to write common protocols for all practices in an area, whcih has some benefits. The companies involved maintained a studious silence, and I suspect that if anyone in the NHS noted it they relegated it to the "hard things" folder. However, it would reduce the combinatorial explosive elemnts of scripting to a degree, and naturally, tend toward re-use of the common metalanguage as a language for each system and new systems, another drop in the step to introicution of something new. -- From the Linux sofa or garden swing of Dr Adrian Midgley http://www.defoam.net/
