This opportunity was cancelled

The buyer cancelled this opportunity, for example because they no longer have the budget. They may publish an updated version later.
Medicines and Healthcare products Regulatory Agency

Mulesoft ICSR (Individual Case Safety Report) R3 to R2 Converter

6 Incomplete applications

6 SME, 0 large

4 Completed applications

1 SME, 3 large

Important dates

Published
Thursday 18 May 2017
Deadline for asking questions
Thursday 25 May 2017 at 11:59pm GMT
Closing date for applications
Thursday 1 June 2017 at 11:59pm GMT

Overview

Summary of the work
Mulesoft
- design
- development
- testing
- early life support (1 to 3 months)
- service introduction / handover to operations.
For the conversion of XML ICSR R3 messages to
- R2
- PDF
- Attachment extraction
Upload R3, PDF and attachements into Documentum.
Latest start date
Monday 12 June 2017
Expected contract length
Location
London
Organisation the work is for
Medicines and Healthcare products Regulatory Agency
Budget range

About the work

Why the work is being done
Statutory Requirement to be able to receive and acknowledge ICSR XML messages received from the European Medicines Agency (EMA) in R2 and R3 formats.
Problem to be solved
Identify ICSR R3 messages from ICSR R2 messages, and convert ICSR R3 format messages to ICSR R2 format messages for onward processing into existing legacy systems.
Who the users are and what they need to do
Staff of the MHRA
Early market engagement
Any work that’s already been done
Project Scoping and Discovery phases are complete.
Existing team
Project team includes existing suppliers, MHRA managed services, and internal staff.
Current phase
Beta

Work setup

Address where the work will take place
151 Buckingham Palace Road, London
Working arrangements
- Resources Professional Working Day - 8 hours exclusive of travel and lunch.
- Working Week - Monday to Friday excluding UK public holidays.
- Core Office Hours - 9:00am to 5:00pm.
- Travel and Subsistence - Included in day rate within M25.
- Any expenses incurred by the Supplier must be by prior written agreement and must be in accordance with the Buyer's Travel and Expenses policy applicable at the time the expense has occurred.
Security clearance
All supplier resources must work according to the Baseline Personnel Security Standard (BPSS)

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
Every developer must have passed the Mulesoft Apdev Fundementals course
Nice-to-have skills and experience
  • Working with data standards e.g. HL7 in Pharma / Healthcare industry
  • Knowledge and understanding of Archimate modelling notations and experience with tools such as BizzDesign, Visual Paradigm
  • Knowledge of Microservices based architecture and DevOps tool sets such as Maven, Github, Jenkins
  • Experience in Agile methodologies such as SCRUM, Lean, Scaled Agile, and associated toolsets such as confluence, JIRA,

How suppliers will be evaluated

How many suppliers to evaluate
3
Proposal criteria
  • Experience with Centres of Excellence for Mulesoft within similar industry and sector
  • Technical capabilities and depth of experience with Mulesoft as an organisation and the specific individuals who will be working on this contract
  • Conformance with Mulesoft best practices
  • Start time on this project
  • Experience of ICSR R2 and R3 and HL7
  • Estimated timelines for completion of this work, by stage with effort and deliverables
Cultural fit criteria
Alignment with the values of the civil service code and MHRA
Payment approach
Capped time and materials
Assessment methods
  • Written proposal
  • Presentation
Evaluation weighting

Technical competence

50%

Cultural fit

5%

Price

45%

Questions asked by suppliers

1. Can this work can be done near shore or is on site a requirement?
This piece of work needs to be on site
2. What resource types are required?
Resources will be required to undertake the following activities
i. Low Level Design of the solution based on an existing High Level Design. Background information on ICSR and the conversion from R3 to R2 can be found on the EMA website. We have no preconceived idea as to the formation of a team to complete this work.
ii. Coding / configuration of MuleSoft
iii. Unit Testing
iv. Handover to ongoing support
3. What is the CAP T&M limit?
We have not fixed an upper limit and will evaluate suppliers on their Capped T&M proposal for this work
4. What is the length of contract?
The start date is 12th June and the solution needs to be in production by November 2017 with the option of 1 to 3 months early life support
5. How many resources will be required to deliver this project and for how long?
We have no preconceived number of resources. It will be up to the supplier to determine what level and type of resource they require. The timeframe is:- The start date is 12th June and the solution needs to be in production by November 2017 with the option of 1 to 3 months early life support.
6. Can you clarify on the required MuleSoft certification? Did you mean MuleSoft Certified Developer (MCD) – Integration and API Associate?
Yes
7. Can you share with us the outputs of the discovery and alpha phases?
The HLD contains sensitive information that we're unable to share at this time. Plus we cannot attach documents within this site.
However if you have specific questions regarding the Discovery/alpha phases we shall endeavour to answer.
8. Have you already got a MuleSoft partner supporting you? If so, how do you envisage the amount of interaction and dependency between us?
Not currently for this specific piece of work however we have engaged with a MuleSoft partner on alternative related projects.
9. Have you got an estimated budget for this project?
We do have an overall budget for delivery of the entire project but do not have a specific budget relating to the MuleSoft development activities.
10. Data Standards: we don't have experience specifically of working with the HL7 standard, however we are ISO 27001 Certified. As such the way in which we access and handle data is very much governed by this process. We also have a number of customers in the defence industry and so in addition to following the ISO Standards we also have individuals with different levels of security clearance up to SC Level. Please confirm if this would satisfy the requirement?
Experience of HL7 messaging standard is not a mandatory requirement.
11. Is experience with Archimate modelling notations with other tools apart from BizzDesign and Visual Paradigm acceptable?
Lack of experience with BizzDesign and Visual Paradigm would not exclude you from the selection process.
12. Do you have more detail as to the scope of this work?
The following is a summary of what is in scope. Routing of R3/R2 xml files after receiving decrypted files from EMA; R3 files schema validation and transformation from R3 to R2 version; Creation and upload of Documentum artefacts (R3_xml, PDF, attachment) for R3 files per ICSR messages; Reporting using MuleSoft CloudHub inherent features as per High Level Design only for MuleSoft component; Notifications to business users (Operations Team) for error scenarios in MuleSoft Integration layer; Retaining MuleSoft data for specified time as per High Level Design for operational purposes; Unit Testing of all MuleSoft components.
13. Do you have more detail as to the scope of this work?
Continued..
Liaising with incumbent System Integrator for legacy application and other partners working within the agency to undertake Integration testing of end to end solution; Configure, operate and support Mulesoft UAT environment to support User Acceptance testing; Roll-out of Mulesoft flows and services into production in line with the Service introduction processes at MHRA; These services should cater to requirements of two agencies in line with the High Level Design; House-keeping/maintenance jobs for permanently deleting files.
14. What service do you envisage being created in MuleSoft?
We have identified the following potential services:
ICSR Converter Service to Pick incoming message from FTP location & checks R2 (Message) or R3 (Message). Route R2 to legacy system.,Converts R3 message to R2 message format & routes to legacy system; and extracts attachment. Creates R3 PDF., R2 Messages will maintain the current form of wrapper.,Retaining all files across all scenarios (detailed in HLD).,Staging files for Documentum service, Send notification reports to operations team via email for all non-converted scenarios.
15. What service do you envisage being created in MuleSoft
Continued..
ICSR Documentum Service to Receive unique identifier for ICSR and Documentum location., Places the files in Documentum location after picking from staging area with the inbuilt MuleSoft node.
ICSR DocumentumError Handling Service to use a MuleSoft CRON Job for Documentum upload error scenarios and Reporting to operations team., Places un-processed staging files in specified locations., It will create a reconciliation report, on the number of R3 message requests for which the Documentum file upload failed, with their respective ICSR details.
House Keeping Jobs to remove historical ICSR data in line with the data retention policy outlined in the HLD.