Quality Management System certification requirements

What should be their application to the producers and users of free software with specific reference to medical care?

We consider the care of children important, yet apply different standards to those who are paid to attend children, than to those who provide help or supervision free of charge in their own homes, despite that these can be the same children. Regulatory efforts are therefore not a cut and dry system of applying rules purely and solely to achieve a uniform outcome but, in many cases, in the aim of achieving a "generally right thing".

In the context of Patient Management Software (PMS), including Electronic Medical Record (EMR) software, I would offer the considerations below.

I am hoping that any Regulatory agency striving to foster quality would do so without an unduly expensive process that stands to extinguish the type of diversity and innovation seen with small and notably free software projects. Projects which can ill-afford the expensive hoops better-survived by large institutions, to the latter's eventual and strategic benefit.

Concepts and principles:

  • producer and consumer (as opposed to community sharing)
    • traditional expectations of producers:
      • receipt of payment (thereby a contractual relationship)
      • no legal requirement (only a competitive one) to warrantee against problems or fix them
      • secrecy or at least non-disclosure over how the product was made, or works
      • retention of total product control (limiting consumer capacity to fix the problem)
    • traditional expectations of consumers:
      • a warrantee
      • quality of service
      • product works as described / promised / required

In the case of "products", we customarily regulate quality mainly, if not purely, only up to the original point of sale to the consumer. Only extra-ordinarily is there an expectation of still meeting the original standard at the point where a product is secondarily redistributed. Some goods like pre-owned automobiles, despite that they may have suffered a decline in quality, remain adequately examinable by any consumer who would acquire it.

The quality management system (QMS) standard is, in the case of Electronic Medical Record (EMR) systems, a proxy for the actual inspection, and testing, and any repair or other alteration of the software which – in a free (liberated) open source software or "FLOSS" model – is a freedom fully accessible to the consumer. This has been largely if not entirely unavailable to users of non-free, closed-source "proprietary" software, at least traditionally.

For convenience, and despite that not all of the last-named above fits the following description, let us in the worst case scenario refer to it hereafter as opaque lock-in software (OLIS). Let us also take the view that despite such a label, a well-managed OLIS could achieve a high-level QMS and could surely help to achieve quality health care delivery, albeit at costs that can be substantial.

Setting aside all contractual relationship elements, and focussing only on quality, and in a scenario where the producers of a particular FLOSS or even OLIS software version would not have made explicit (nor obtained certification of) their quality management system, the question becomes whether the deployment and usage of the software by the end-users would be any different than if the end-users had written their own software.

The Regulator must therefore ask itself whether it will outlaw all end-user modification of generic tools which would then serve these users' own needs, since typical EMRs – despite being "packaged" – already combine "off the shelf" component tools which combine a database, a programming language, a connection server and a graphical user interface. To argue that the end-user who built their own EMR from a word processor (which within it may have or link to database and sort and manipulate functions in addition to internal programming languages) is a false argument.

The Regulator must then consider that – if it will not outlaw these uses – then on what basis would it disallow the sharing of copies of such software systems among such users with common needs. The next extension is the concept of multiple individuals or groups within a community, each deploying a copy for their own use. If such a group put everyone's record in a single giant database used by all – not that we should – there would be no distribution from its point of origin. This form of EMR, despite that it would be a giant EMR, would presumably be exempt. This is, in fact, what some government facilities do, and the reasoning under which government bodies can write or multiply-deploy software exempt from government's own Medical Device QMS requirements bears re-examination.

Regulators can fail to appreciate that in designating software divorced from hardware to be a Medical Device, they are bringing under Regulatory control either virtual devices or, in the case of centrally-deployed and remotely accessed systems, software as a service which the regulators risk defining as then regard as out of scope. What will be the regulatory stipulations when medical practitioners would subscribe to a service hosted outside of Canada, where not already precluded by privacy legislation? What then of the public who might choose to host their personal health information on a system like Google Health. Surely this is a Patient (Health) Management Software, therefore shall Google Health be multinationally regulated to require certification and licensing?

There is a danger that the Regulator would here be seen as not exercising quality requirements that place accountability where it lay. In the case of consumers of traditional OLIS, their accountability for using the software is shifted upstream to the locus of control because, as consumers, they can only try to influence, but cannot control, their source of manufacture, nor be helped to discern any of its failings through internal inspection. That forms the basis for a Regulator to require of the OLIS manufacturer a certification for the QMS as a the proxy to safe and effective function of the software.

Where however a patient management software is made available to those who could come and help themselves to it, whether on an internationally-available server computer or through point-to-point sharing within a user community per any of the scenarios above, the accountability should be on the users, except where they would have conjointly assigned an upstream QMS proxy that accepted and undertook this responsibility. In the case of a FLOSS software, this could be a community-supported non profit corporation, but there exist presently mainly just appeals to principle for such investments.

In absence of such an arrangement among a user base, and where their EMR had not achieved ISO 13485 certification (be the EMR of type OLIS or FLOSS), each user group – for example, each medical practice – should be responsible to document their own QMS.

There is a precedent for this, in the existing requirement for doctors working in the private sector to establish their privacy policies and privacy practices. These, any patient can request to be shown. So too should it be for any medical device(s) that are in use. One can argue that it could be transformative for the public, as patients, to be more-transparently provided with evidence of QMS processes which, in many practices, may commonly be inadequately defined.

The benefit of such an approach would be to drive medical practices to higher levels of collaboration and co-operation and adoption of quality practices, whether those would be through such work at the community collaborative level, or whether it would be achieved on their behalf through a proxy of a non-profit organization (where they would build one to achieve the certification) or through an OLIS or FLOSS entity.

Even while we want satisfactory QMS in place, whether this be a case of the consumer inferring it, from an EMR having ISO 13485 certification, or a case of a QMS that is demonstrable by its users absent the formality of certification, may be less important to quality delivery. Here seems the important point – where any medical users would have the capacity to use any non-certified software, the objective should not be to obstruct the use of the software, but to require the users to develop and make available documentation for their own QMS. This approach would place the pressure where it should reside. One could even extend the argument, by asserting a duty on doctors to document a QMS around their _non_-electronic patient record system. Their need for better quality patient information management, and care delivery, would create a movement to adopt EMR functionality where, and how, it would add quality and value. This would drive adoption of EMR functionality for the right reasons!

Medical practices which would rather align inside an established quality system, such as a certified OLIS or community-supported FLOSS entity might provide, would achieve part of their work done for them. Many doctors do tell me "I would rather just pay somebody the extra, to provide me something that has already been worked out, than to have to do it myself". Many would find it simpler to just go with a certified OLIS "vendor". But we should also look to ways to get the medical community to abide or support the costs of OLIS and FLOSS softwares that did not yet get certified. That would make them better softwares, which should be the point of all this.

The Regulator-approved registrars could be approached to identify a process in which medical offices which use computers for anything more than billing and scheduling – and arguably (per above) even those who don't – should have to provide QMS documentation as to their records management, including any electronically-assisted care components that are not ISO 13485 certified. The impact on the practice must be non-injurious. In any one practice, in any one year, it should be limited to something like a half day of time for the doctors in the practice, and a cost of maybe $200 per full time doctor-equivalent capped at $1000 per practice. This could be deployed under a random audit system, with an intensity that fell within the joint capacity of Registrars and Colleges of Physicians and Surgeons – the long-standing regulatory bodies for care delivered by doctors – with whom such a process development should naturally reside.

Short of such a system, I cannot see that the Regulator could come up with an approach that would take account of the fact that doctors who use self-made systems, and those which don't, may also be using many other electronic patient management tools independent of what may or may not be an ISO 13485 certified EMR.
Topic revision: 20 Aug 2010, 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