MiniProjects and not so mini projects

Before embarking on a mini-project, please email the gnumed-devel list to check whether anything has changed to affect it.

Available projects:

• KOrganizer link
  • write a high-level Python API wrapping DCOP access to KOrganizer (python-dcop already available)
  • required: detect_KOrganizer()
    • detect whether KOrganizer is available
    • useful in cross-platform clients
    • can start KOrganizer (but not required)
  • required: raise_KOrganizer()
    • raises KOrganizer to the top of the desktop window hierarchy
    • must start KOrganizer if available and not already running
  • required: set_appointment(date, time, duration, type, text, force, data)
    • date: the data for the appointment
    • time: the start time
    • duration: how long it is anticipated to take (alternatively: end-time)
    • type: the type of appointment, must exist in KOrganizer
    • text: the text to display in KOrganizer
    • force: whether or not to forcibly "squeeze in" the appointment regardless of overlap with other appointments/out-of-hours/etc.
    • data: a piece of data to be associated with the appointment, say, a string, KOrganizer should not care what this is but rather simply return it whenever the appointment is retrieved programmatically
    • returns: a statuscode indicating success or what went wrong (overlap, out-of-working-hours, etc)
  • required: remove_appointment(start, type)
    • only succeeds if start and type match exactly
    • might ask for confirmation from within KOrganizer (thus being beyond the control of GNUmed itself)
  • required: get_appointments(start, end, type)
    • start / end: the range inbetween appointments returned are supposed to begin
    • type: if set, constrain returned appointments to that type (type must be configured in KOrganizer)
    • returns list of appointments with full metadata:
      • start, end, type, text, data, overlap=yes/no
  • optional: find_next_slot(earliest, latest, duration)
    • earliest / latest: range in which to search for an appointment slot of length
    • duration: allow setting to 0 to find slots of any length
    • returns: a timestamp at which the appointment could start
    • since KOrganizer doesn't really do resource handling (yet ?) there is no need for a type argument in this function
  • future: consider adding resource handling
    • locations, time slots, equipment, people, ...
    • but would broaden the scope of KOrganizer significantly
    • perhaps better use a workgroup management tool for that ? Kollab ?

• lab import/display framework
  • a lot of code is already there

• vaccination handling framework
  • pretty much done, needs polishing/integration

• write a small tool to manage images embedded in python files
• Confirmation of correct patient
• support to be able to dump (and import) the entire records of just individual patients (see archive
• script which parses the CVS for the maintainer of a file
• tool to make dtd, write xslt transforming gnumed xml into hl7 cda
• background standalone integrity checker for the GnuMed backend
• FaxDaemon integration
• Artwork Handling - the basics are pending, see gnumed-devel list from approx March 15, 2005
• Link Gnumed to Argus - use eclipse to run it.
• explore creating CDA docs (use Chetah) from within GNUmed to link to DecisionSupport
• write a check the -yet to be written- external integrity check daemon to look for staledrug database links on cache entries)

• merge gmGuidelines, gmManual et al. into a wxpython/gmHTMLBrowser.py adapted to the GnuMed framework
  • then make the previous browsers use the unified browser
  • posted by Karsten via list, Nov 10, 2004

• pg_dump-like utility

• unit testing
  • Write more unit tests for the middleware (see client/business/ and client/testing/).

• merge widget
  • Our business objects (middleware) can detect concurrency errors the database reports. Think of two doctors editing the same piece of data at once... Whoever tries to save his changes later will experience a concurrency violation. Our middleware detects and reports that. It also offers all three states of data (original, own intended changes, conflicting changes of other user). What we lack is a widget to allow the user experiencing the problem to merge changes into a final version. The easiest and most simple solution would be to display all three versions and let the user choose one or supply a fourth version to eventually be saved back into the database.

• search EMR
  • Our clinical data is saved in a clinical context. It is part of an encounter between a patient and a healthcare professional. It is also part of an episode of healthcare. Now, we need functionality to do searches across all the free text that has ever been entered into the medical record of a given patient. There are appropriate views aggregating the narrative for searching. What we lack is a widget to display any matches in context: For each match found retrieve the encounter and episode of care and render this information to the screen. This is a bit like a context diff or grep, eg a few "surrounding" lines are displayed along with the actual match.

• clean-up
  • it is acknowledged that the size and positioning of screens (windows) which the client will open in front of the main GNUmed screen is not standardized. A suggestion as to what the screens may look like, and how they may be positioned, are on [[http://lists.gnu.org/archive/html/gnumed-devel/2009-07/msg00000.html][this post] in the -devel archive.

• semi-automate generation of a per-patient, per-problem cumulative profile
  • start with a per-problem view in which rows of a specifiable type would be filterable
  • in this way, facilitate a view on just the Assessments, or just on the Plans, going back over many encounters
  • enable the selection, from among these rows, of all rows of interest, and post-process these, auto-concatenating the content
  • output opens as an optionally-editable note to serve as a "digest" of the problem.

• hack up a small wxapp that would display and onscreen keyboard (see devel posting and follow-on thread

Previous mini-projects:

• Merging duplicate patients
• AsciiExport
  • now incorporated into the RoadMap
• Progress Bar
  • wxWidgets now already has one
  • Original posting
• LoginDialog
  • done (Hilmar)
• wxPython 2.6
  • Install wxPython 2.6. Make sure GNUmed release 0.1 runs on it. Then make sure everything being developed keeps running on it.
  • done (is default now)