Clinical Model Development
Process Overview
Phase | Description | Notes on $ cost and timing of development |
Demonstration | A demonstration system is installed, presented and left with the customer for clinical review to take place. | |
Review | The customer reviews the demonstration system and accompanying system specifications. | |
1st Scope of Work | Feedback is recorded into a Scope of Work template – supplied by K2MS. The Scope of Work is jointly signed off by K2MS and the customer. | This is your main opportunity to request new changes to the system – all changes are billed at the standard K2MS daily rate minus the first 100 hours of development/ localisation. |
Clinical Modelling 1st Round | The K2MS Clinical Modelling team will make the modifications to the system in line with the agreed Scope of Work. | Please remember that your Scope of Work will be queued for development in line with other customer commitments. In many cases this is based on a 1st in, 1st out basis. |
Round 1 Review & (possible) 2nd Scope of Work | Customer reviews modified system using Scope of Work and submits any areas of misunderstanding to K2MS. If deficiencies exist, a 2nd Scope of Work may be required and will be jointly signed off. | K2MS will accommodate up to 10% of the total time estimate from the first Scope of Work for new requests, in case items were overlooked by the customer. These will be charged at the standard K2MS daily rate. Bug fixes / areas of misunderstanding from the first round will not be charged. |
(possible) Clinical Modelling 2nd Round | The K2MS Clinical Modelling team will make the modifications to the system in line with the agreed 2nd Scope of Work. | |
(possible) Round 2 Review & sign off | Customer reviews modified system using Scope of Work and submits any areas of misunderstanding to K2MS. Scope of Work is jointly signed off. | During this development round, there is no further provision for new requests for change. |
K2 Validation | The software is put through a stringent validation process to provide assurance that the software can be used in the live clinical setting. | |
Pilot | The software is piloted and exposed to the live clinical environment by the customer (This is often referred to as the customer's User Acceptance Test (UAT)). | |
Go-Live | The system is released to production. | The project's final milestone payment and first year of software support licence becomes due. |
First Scope Of Work (SoW)
The first review of the system is the customer’s main opportunity to request changes to the system before go-live. It is very important that this first process is undertaken thoroughly – as Scope of Work 2 will only accommodate a very small amount of new requests for change (i.e. items that are not bugs or reasonable misunderstandings from the first Scope of Work). A third Scope of Work will not accommodate any new requests.
This stance is to protect both the customer and K2MS from unnecessary project delays brought about by limitless iteration loops. The most economical place to request changes is here – so don’t skimp on this first part of the process!
The method that K2MS recommends for reviewing the system has three approaches:
When the Scope of Work is submitted to K2MS it will be estimated and returned to the customer with an analysis of whether or not each change is Sufficiently Defined. Any areas of misunderstanding will be highlighted – with each request of this nature flagged as Open Query. These requests need to be clarified in conjunction with K2MS until they become fully defined.
Localisation Vs. Development
Localisation | Development |
A request for modification to an existing screen to meet Hospital requirements – examples include, a new field; list item; validation message alteration; bug and so on. | Where the customer raises requests for whole new areas of functionality – these will enter a separate development queue within K2MS. Such requests are subject to a more stringent approval, prioritisation, specification and development process than localisation. They may or may not be accepted into the scope of the system and will generally take more time to develop and be considered for a subsequent post go-live phase of the project. |
Do’s & Don’ts when Compiling Your Scope of Work
Do Describe Each Change Fully • Don't assume K2MS staff will fully understand clinical abbreviations - describe your request in as great a detail as possible. • Provide clinical context as necessary. | Don't Combine Requests • If you require more than one change to a screen - do not list these changes under the same request/row in the Scope of Work - they should be listed separately. For example: the request to add two new fields should be listed as two rows. |
Do Complete Each Column As Requested • Spend time reviewing the guidance information contained beneath each column in the Scope of Work. • Specify the Type of Request by selecting an option from the drop down list (for example - New Field, New List Option). | Don't Attach Hospital Guidelines Without Context • Guidelines can be supplied to provide context but should not be supplied with instruction to "make system reflect our guideline". • Where guidelines are included they should be accompanied with specific requests for change (i.e. add new field called x). |
Do Use Punctuation • We aren't trying to insult your intelligence here! It really helps if you can express a request clearly - for example using speech marks for options. For example: Add new field called "Labour Diagnosis" with options "In Established Labour", "Not In Established Labour". | Do Not Include Images On Main Requests Sheet • Screenshots are much better handled in a seperate document with a reference back to the ID in the Scope of Work. • If including screenshots in the Scope of Work - these should be added to a new tab and reference to the relevant ID. |
Do Submit A Final Version Having Checked It First • This is particularly relevant if you are consolidating change requests from multiple people. • Please check over the final version and ensure that it is free of duplication and reads as clearly as it can. |
Related Articles
Remote Viewing Service (Clinical Web Portal)
This web based service allows consultants to view what is going on in each of the birth suite rooms from their smartphone/ tablet or laptop. The remote viewing service (Clinical Web Portal) runs as a web application on a web server within the ...K2MS Guardian Implementation Project Overview
K2MS Australia use an online Project Management service called Zoho Projects. On initiation of a project with your organisation you will be invited to join our online workspace. A guide to using Zoho Projects can be found ...Guardian Software Update Process
Your Guardian System may require updating in one of three ways: Updates to your Hospital or Health Service's Clinical Model and (more rarely) the underlying database structure (through the addition of fields and/ or tables). Updates to either ...Issue Reporting, Classification and Response (SLA)
Schedule B -Vendor’s Service & Support Responsibilities B1. Service Coverage B1.1. The period during which the Vendor provides Software Support are set out in the Customer's Service Level Agreement Schedule A. B1.2. A current Software Support ...Site Survey Overview
Upon receipt of a completed Site Survey, the Customer is required to confirm that it is an accurate summary of the current and projected state of the Customer's IT and facilities infrastructure designated to support the K2 Guardian system. This is a ...