On Sat, 2003-09-20 at 04:03, Thomas Beale wrote on the openhealth-list: > what you can define is the models of the pieces - > medication list, problem list, care plan, etc etc. Then the discharge > summary is a kind of generic "bag" that can carry any/all of these. The > key is to try and model the components in an interoperable way, and > allow the whole to be a flexible container. > > Doing this is not that hard - it is just the approach that needs to be > accepted.
It is with great joy I read this email. <vbg> Though this information has been available in the GEHR / openEHR (openEHR http://www.openehr.org) documents as well as in the discussions and design of FreePM / TORCH, it is good to see it stated in such a clear manner. The second part to it though is to have the ability to locate those 'pieces' across the many 'bags' contained in the EHR. TORCH currently has those tools but it is difficult to get users to learn this when they already know SQL and don't understand why they can't use 'standard' tools to extract their queries. Fortunately, the FOSS building block concept works and APE (Adaptable Persistence http://hathaway.freezope.org/Software/Ape ) promises to deliver the best of both for TORCH by allowing storage of selected attributes in PostgreSQL tables while maintaining their relationship in the object hierarchy. While the above paragraph is a "blowing my own horn" kind of statement, I invite you to look at the online demo of TORCH or better yet; install a copy and browse the object tree in the Zope Management Interface. You can then see how the various class instances are contained in the appropriate 'bags' with the attribute of every instance fully addressable via a URI using the Domain Name System FQDN as part of that unique pointer. If not exposed to the Internet then local network naming policies dictate how the URI's are constructed. Using current tools, queries can be made that extract any desired level of detail across one or more EHRs (or even across groups of servers) for any set of instances and their attributes. In the upcoming TORCH2, the class definitions are being developed from UML definitions and the shell archetype is automatically generated from a python application that reads the ArgoUML XMI output. I am investigating modifying the code generator to include the specifics required for TORCH2 instead of hand modifying each class. This would create a too that would be fairly easy to teach techie end-users to use to develop their own classes. By default the basic Zope and Plone classes are inherited as well as the Dublin Core. The Dublin Core (http://dublincore.org) meta-data subset includes workflow management (not to be confused with workflow itself) as well as document management. The DC meta-data will assist int he ability to interface data across multiple information management domains. As described here, TORCH represents the essence of open source development due to the fact it is built out of blocks that engage a wide range of end users and developers. This allows us to leverage the efforts of thousands (hundreds of thousands?) to continue improving all of the pieces. At any time development stops or diverges to our detriment (not likely) on a particular piece we still have all the source code from which to continue development. The "real trick" to all this as has been noted by the openEHR project is to manage the versioning for interoperability between applications. There has been talk and I assume it will come to pass that there will eventually be openEHR certified applications at each version level. -- Tim Cook (President, Open Paradigms,LLC) <[EMAIL PROTECTED]> Public Key - 1024D/9ACDB673 available from: http://www.openparadigms.com/timcook_publickey.asc Key fingerprint = C7BB 675B BDCA B87D 83F0 A002 BBDC C7B8 9ACD B673
