The life cycle of a health software system typically comprises:
a) concept development and requirements capture;
b) detailed design;
c) software development;
d) software verification;
e) software release/marketing;
f) system validation and deployment;
g) use;
h) decommissioning.
ISO/TS 29321 applies to all life-cycle stages in which the manufacturer is responsible; typically, these will typically be a) to c) although, depending on the contract, the customer may be involved in concept definition/design. This Technical Report applies to all those life-cycle stages for which the customer/health organization is responsible, which will normally at least include deployment, use and decommissioning, although an out-sourcing contract may place that in the hands of the manufacturer.
However “deployment” can be in the hands of the manufacturer, the health organization or both. The manufacturer is likely, for example, to be heavily involved with the first deployment of a health software product as part of a health organization system. The standard which will apply to deployment will depend primarily on which body is responsible for ensuring patient safety. Where the manufacturer and the health organization work together on deployment and perhaps share responsibility for risk analysis etc., the manufacturer may work to ISO/TS 29321 (and thereby use the experience to build on the manufacturer clinical safety case) and the health organization may work to this Technical Report (using the experience to build the organization's clinical safety case and draw on the manufacturer's deployment clinical safety case report).
Since the hand-over from implementation in the user environment to live use will often involve the manufacturer/supplier and the user, a formal user acceptance protocol should be agreed upon and documented and include:
- a procedural work-through with users;
- and a dress rehearsal.
This lifecycle does not match my experience especially with highly configurable COTS solutions. I would like to see:
ReplyDelete1. the list of phases increased to reflect user configuration phase and appropriate V& V for this.
2. recognition of user level maintenance in the lifecycle
So we might then have:
a) concept development and requirements capture;
b) detailed design;
c) software development;
d) software verification;
e) software release/marketing;
f) system validation and deployment;
User configuration requirements gathering including corrective or perfective maintenance/ reference data changes
User configuration build out
User verification / promotion promotion to live
g) use;
h) decommissioning.
The other issue I have with this section is that it does not address the need for communication and flowdown from activities in one phase to another. For example, user level configuration may introduce training requirements or have implications for service management. If these implications are safety related then how can the user community ensure that such dependencies are not broken in the future thus exposing a hazard?
ReplyDeleteIn essence, I beleive we need an agreed interface specification between each applicable phase in the lifecycle. I beleive this is particularly important between each contractual party to the supply chain.