Closed tender

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

Details

Published
18 May 2017
Submission
1 June 2017

Tender description

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 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 Are the Users Staff of the MHRA Work Already Done Project Scoping and Discovery phases are complete. Existing Team Project team includes existing suppliers, MHRA managed services, and internal staff. Current Phase Beta Skills & Experience Every developer must have passed the Mulesoft Apdev Fundementals course Nice to Haves • 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, Work Location 151 Buckingham Palace Road, London Working Arrangments - 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) No. of 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 Evaluation Weighting Technical competence 50% Cultural fit 5% Price 45% Questions from 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 activitiesi. 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 MuleSoftiii. Unit Testingiv. 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.

Timeline

  1. Completed: Tender published18 May 2017
    Current notice
  2. Completed: Submission date1 June 2017

About the buyer

Medicines and Healthcare products Regulatory Agency is a public sector buyer in United Kingdom publishing tenders and awards on Stotles. Explore their procurement activity and find more opportunities like this one.

AI insights

  • Is there a preferred supplier?
  • What are the buyers pain points?
  • What has the buyer previously procured?
  • What are the key requirements?
Sign-up to enrich

Decision makers

Connect with the people behind this procurement.

Contact nameJob titlePhone numberWork email
Head of Procurement+44 •••• ••••••
Commercial Director+44 •••• ••••••
Procurement Manager+44 •••• ••••••
Category Lead+44 •••• ••••••
Senior Buyer+44 •••• ••••••
Contracts Manager+44 •••• ••••••

Related topics

Topics related to Mulesoft ICSR (Individual Case Safety Report) R3 to R2 Converter, ranked by notice volume.

View all topics
TopicCountValue
  1. 1,997
    £39.8bn
  2. 4,088
    £269.5bn
  3. 931
    £6.0bn

Related buyers

Buyers similar to Medicines and Healthcare products Regulatory Agency.

View all buyers

Win more public sector contracts

Track every UK and Ireland tender in one place — set up alerts, find decision-makers, and never miss an opportunity.