Quoting David Guest <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > In response to Tony's pondering we are doing soemthing that is > related. > > Although let me say this is a research project where we are trying to > push > > the boundaries rather thatn satisfy a specification. It may not be > > everyone's cup-of-tea. > > We call the project Generative Hospital Information Systems and it has > that > > name because we consider it is system to generate special purpose > > information systems. Some of its philosophical features are; > > 1. The users define the the nature of the data they want to collect ( > with > > the help of a generic data dictionary) > > > A necessary start. > > > 2. The users define the screen layouts and formats for collecting that > > data. > > > For my vote I would want free text fields with auto-expansion of hot key > short cuts. > Tabbing around is too difficult in general practice for history taking > and probably most examinations. This is avaiable from our "generator" as athe user defines what characterisitcs they want the presentation field ot have. Note that we distinguish between the data layer and the presenation layer > > > 3. The patient's information is a story stored in a document > repository > > rather than a record repository, hence reteival is of a form > previously > > populated by someone else. > > > Jon, I think I understand the first bit but not the second. Can you > expand? Our focus has been on the hospital setting where many differnt Departments use many different forms. Once a user defines a form then it is held in a forms repository and can be changed at any time so the repository is a Forms Version Control System. When a clinician populates a form with patient data then the data and form version is stored together (in XML). Anyone who wishes to do a retreival of the patient story sees all the forms filled out for that patient and chooses whichever ones they want- so this is a mimic of the paper system -of course any user could redesign their paper form into a web presentation if they want to but that assumes they are prepared to give up their current data layout. So part of our consideration is about what creates the least disruption to current paper systems and thereby easing migration from paper to screen. Importantly each "department' can design their own "information system" but everyone can "see" everyone else's data on the original forms used to collect the data. > > > > 4. The fundamental objective of the system is to support analytics, > > everything else comes as an adjunct to that objective. This is > justified > > on the basis that clinicians purposive use of an IS is to get it to > answer > > questions as distinct from just retreiving patient hi-stories. > > > And this is why they will come. > > The next generation of medical software should do two things in addition > to storing the data. It should support analytics as Jon is undertaking > and it should support fine grained access to the shared medical record. > With the continuing change in medical practice and the acceptance of > general practice as the repository for the nation's medical data this > has become critical. I hope my description above conveys the right picture that our system should give access to data at whatever granularity one wants to define. Certainly one can get at the finest granulairty of the data captured at point of care. Anything above that is a matter for the analytics system. The research question for us is how to create and provide that granularity in a systematic and automatically revisbale way, that is, it is not defined in some arbitraty way by an arbitray authority. One of our ideas is to use SNOMED CT but we have no evaluation yet of just how sensible or non-sensical that might be. We also have to consider that certain specialities will have their own favoured terminology/onotolgy/classification (TOC) so how do we build a general terminology server for all TOCs - that is an Honours project this year. The basic model for the Analytics system is to have description language (practitioners descriptions of patients things- ala SNOMED CT but also clicnial notes where we automatically generate SNOMEDCT) surrounded by a "shell' of an analytics language, that is all the types of things anlaysts want to generalise about. That's conceptually a bit like SQL where the Data Manipulation Language is separate to the application data model - but we are NOT buidling an SQL - it will look very different. > > > > Our first attempt will be to replicate the processes in the ED at a > western > > sydney hospital. We spent 3months there last summer doing a process > > analysis which we now have on a piece of paper covering the better > part of > > a small wall. If we hit the spot we will have something that at least > > performs up to the current EDIS but can do better with functionality > for > > clinicians, greater flexibilty to re-engineer and potentially much > > superior analytics. We won't have analytics functioning for the first > > release. > > > > Code is written in Python and C# (some compromises made). Linux server > - > > windows client. > > > Are wxpython and C# stable in routine use for GUI development.
no problems yet - fingers-crossed We started with C# (reluctantly ) as we were loaned a Tablet PC for experimentation for handwritten input - that has worked reasonably well (in the lab) and we convert the handwriting to SNOMED CT in real-time. > > David > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
