Quoting "Andrew N. Shrosbree" <[EMAIL PROTECTED]>: > Ian, > Your suggestion that a GUI be closely wedded to the EHR makes me > shiver. How about a design-pattern approach of having a decoupled > program layer that interacts with the data? > > This layer can be accessible by an (independent) GUI layer. It's important to separate the issues here. I fully agree there should be clearly delineated program layers, code that lays out GUI doesn't contain any SQL queries, and a clearly defined logical interface between them, this is standard practice. There's a separate issue with controlling the complexity of a 3-layered structure, but that's tangential to our point.
3 layers would allow separate Web and native client interfaces, for example, or two clients with totally separate appearances. However, users probably won't make the distinction between the appearance and higher-order behaviours of the interface, particularly when you get into the 'smart' functions that people are interested in. For example, users may want the program to learn their preferred drugs and dosages and offer them as completions next time. If you have a fixed standard database which doesn't have a table for that, then it just can't happen. This is exactly the problem with gnumed: the schema was designed as a philosophically pure excerise in representation of clinical data, with abstract classes to manipulate the data, then when time came to link it up to a GUI designed largely in parallel, it just didn't work. Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
