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:

  • patches to remove, from the bootstrapper, the reference data which not all praxes may want
    • see here for list
    • we should factor out the items and list in the wiki as 'available'

  • 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

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

  • 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 [[][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.

Previous mini-projects:
Topic revision: 01 Sep 2011, JamesBusser
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark