Quality Management System for GNUmed

Establish √, document, implement √ and maintain √ an effective quality management system (QMS)

QMS Documentation

a) √ Quality Policy and Quality Objectives: see AboutGNUmed
b) Quality Manual (stub)
c) documented procedures
d) √ documents needed by the org to ensure the effective planning, operation and control of the processes
e) records
f) any other docs specified by national or regional regulations
and documents that define product specifications including the complete manufacturing process and, if applicable, installation and servicing.

Processes needed for the QMS

Within the limits of the project's resources,

Quality objective Process
Project and software capability information are kept clear, accurate and up to date After each phase of testing, the information on the software's capability is updated and (optionally) actively communicated. Any loss of capability is to be both updated and actively communicated
Project and software operate in a way that best allow providers to serve patient care design derived from list discussion
Project and software operate with a minimum of downtime, data loss, inappropriate data alteration or access, or errors via design and educated execution
Project and software operate in a way that promotes community participation to further improve the software via design, information, human interaction and systems
Project and software downtime, data loss, inappropriate data alteration or access, and errors are, where manageable, avoided by design via best practices
Project and software downtime, data loss, inappropriate data alteration or access, and errors are able to be detected, reported, made known to the user base, repaired, worked around, and resolved in a time and manner appropriate to the severity of the errors or their consequences via design, information, human interaction and systems

Sequence, Interaction (and Application) of the Processes

  1. Prior to use of any version of the software, the potential marketers, distributors or directly downloading users will take account of information that includes, but need not be limited to, the following to determine the suitability of registration with the project and/or use of the software for their intended purposes:
  2. Supplemental questions and answers about the capacities of the project, or released versions of software, or versions under development, will be shared via the developer email list.
    • Change requirements as to information on the project or software capacity will be tracked in the email of doc team members until incorporated online at the earliest opportunity.
    • Revocation or other loss or diminution of software capacity in a new or updated release will be actively communicated via the "announce" mailing list.
  3. Optimal project and software operation will be identified through discussion on the developer list. Final decisions will made by project members holding decision-making and control responsibilities.
    • Change requirements for project management will be tracked in the email of doc team members until incorporated at the earliest opportunity on the wiki ToDo.
    • Change requirements for the software will be identified on the wiki RoadMap.
    • New or materiel modified capacities in the project will be communicated on the developer list, and capacities to the software (per 2 above) via the "announce" mailing list.
  4. Errors or their consequences will normally be detected, reported, made known to the user base, repaired, worked around, and resolved in the following sequence
    • Detection
      1. will require observancy on the part of the testers and users
      2. will be assisted by the software's built-in exception handler and log files
    • Reporting
      1. via the software's built-in exception handler, which will issue an email to the project bug email list, and/or
      2. a tester or user manually-generated email to the project bug email or developer email lists, and/or
      3. a bug report manually entered into the project's downstream bug tracker at Launchpad, and/or
      4. personal communication to one of the project team AND
      5. if the organization has been established as falling under regulatory requirements to provide a report of errors or consequences to specific regulatory bodies, and has been provided with the means to manageably issue such notices, then
        • such report will be given, on the understanding that
        • such report is to be regarded without prejudice to project and software disclaimers of warrantee and liability
    • Making known to the user base
      1. issues posing limited inconvenience to users without threat to patient well-being may not be made known to the user base beyond the report originally filed
      2. issues posing considerable inconvenience to users will prompt a message on the developer list and/or an update to Known Issues
      3. issues judged clinically important, will – in addition to the above – be communicated via the "announce" mailing list
    • Work arounds
      1. any identified work arounds and methods of correction of consequences will update Known Issues and, where judged clinically important, will be communicated via the "announce" mailing list
      2. this work around process will be repeated upon availability of significant new information pending a resolution of the problem
    • Resolution
      1. root causes and factors contributing to errors will be looked for and, where possible, resolved
      2. progress will be posted to relevant entries at the Launchpad bug tracker, the Known issues page and the developer and/or "announce" email lists
      3. post-0.2.9 versions of the software, as at August 2008, possess by default ("on") the capacity to check for updates automatically

Planning, Operation and Control

Preamble: While an occasional Free / Libre and Open Source Software (FLOSS) project is commercially-owned, the present one is owned by its historical contributors under a relationship that is inconstant over time. Traditional business constructs including corporate entity, executive branches, departments, human resource managers, job descriptions, employer-employee relationships and reporting relationships are impractical and inapplicable. Moreover no contractual relationship exists either among the project owners, or between the project owners and those who would use the software.

In spite of the above, planning, operation and control by the community (developers, supporters and users) are achieved as follows:

  • Planning
    1. Planning of the quality processes was achieved in concert with the software development and the result first captured in October 2009 a posteriori
    2. Planning continues on an informal basis via the developer list
  • Operation of the quality process
    1. New project members are pointed to the quality processes
    2. Detection and reporting systems operate continuously
    3. Making known to the user base has the capacity to operate continuously
    4. Work arounds and resolution operate discontinuously, but have the potential for continuous operation depending on growth in an international developer or remunerated software support base
    5. Redundancy in the system (list and individual email), separately-hosted wiki, software's built-in exception handler, bug report and RSS subscription options at Launchpad, and automatic update-checking, and a culture and practice of open communication and collaboration all help to quickly identify any lapse in the quality processes
  • Control of the quality process
    1. Deviations from the agreed-to quality processes are dealt with first by education and redirection
    2. Constructive criticism of project (including quality) processes are dealt with as openly as possible
    3. Revision of quality processes is considered in an open, deliberative fashion
    4. Control is established and maintained primarily via a series of trusts developed over time
    5. Ultimate operational control is achieved through the management of access to alter the project's information and resources

Implementation, Evaluation and Monitoring

The actions needed to achieve the results have already been implemented and remain in place continuously.

Criteria for effective operation and control will include:
  1. stability (uptime) of the quality process subsystems
  2. statistics on bug handling, and
  3. community satisfaction, as evidenced through its communications.

Monitoring, measurement and analysis of these processes are achieved passively and auto-documented in the normal course of participation on the developer and other email lists and automatic bug notifications, and actively as a result of periodic checking of the auto-generated bug statistics at Launchpad.
Topic revision: 03 Nov 2009, 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