Drones are not a specific requirement in the PCP, but tenderers are free to suggest such elements as part of an innovative solution. It is the tenderer’s obligation to discuss the feasibility of the proposed approach and propose a solution that can be implemented (tested in phase III of the PCP) and complies with requirements imposed by national/regional laws and regulations. Please note that the feasibility of the proposed approach is expected to be one of the award criteria for the tender.
[ upd 06.7.2022] The Call for Tenders (TD1) provides all the necessary information about the existing systems and standards used by the procurers in the project. Tenderers will have to make proposals in their offers as to how to ensure interoperability of their proposed solutions with those systems. Specifically for Health Information Systems of the procurers, during the PCP process (especially in Phase II), such opportunities will be explored, so that the systems are aligned. However, full HIS integration is not a primary requirement in Phase I of the project.
The Tender Documents are available here
https://innovationprocurement.com/tenders/7/show/pre-commercial-procurement-of-innovative-triage-management-systems-strengthening-resilience-and-interoperability-of-emergency-medical-services [ upd 06.7.2022] A system that truly has an impact on the work of the emergency teams should connect the EMS practitioners with the other stakeholders in the EMS ecosystem enabling continuous and reliable communication with the EMCC and the hospital where the casualty is going to be transferred to, as well as a quick access to the casualty’s medical history. The aforementioned necessity implies that the triage system must exchange data directly with the other information systems of the EMS organisations involved. The Call for Tender provides further details about the existing systems and standards used by the procurers in the project. Tenderers will have to make proposals in their offers as to how to ensure interoperability of their proposed solutions with those systems.
The Tender Documents are available here
https://innovationprocurement.com/tenders/7/show/pre-commercial-procurement-of-innovative-triage-management-systems-strengthening-resilience-and-interoperability-of-emergency-medical-services [ upd 06.7.2022] During the preparation phase of the PCP, potential tenderers who have existing solutions at different stages technology readiness, which could be integrated as part of the envisaged iProcureSecurity PCP solutions, and who are looking for partnering with other organisations, are encouraged to share their solutions via the Innovation Procurement Platform:
https://pcp.iprocuresecurity.eu/procurementplatform/ We would like to have a sensor located on the casualty, which, for example, will record her/his posture and, thus, categorize the casualty and his/her injuries. This would allow the rescuer to decide on the casualty status and how to proceed.
[ upd 06.7.2022] The technical requirements explicitly request that a hardware device (triage tag) is provided as part of the solution (either own development or use of existing devices adapted for the purpose of the project) in order to enable the monitoring of key vital parameters. The specific requirements relating to the tag are provided in the Tender Documents (TD1), e.g., requiring the tag to be of small size and be cost-effective.
The Tender Documents are available here
https://innovationprocurement.com/tenders/7/show/pre-commercial-procurement-of-innovative-triage-management-systems-strengthening-resilience-and-interoperability-of-emergency-medical-services The minimum requirement is that a standalone solution shall be developed in each country in their official language. The envisaged solution can include a common backend infrastructure but should in this case allow countries which do not wish to participate to opt-out from this common backend.
During the PCP process (especially in Phase II), such opportunities will be explored, so that the systems are aligned with, for example, Hospital Information Systems. However, full integration is not a primary requirement in Phase I of the project.
[ upd 06.7.2022] The requirements specify that the iProcureSecurity PCP solution shall operate on mobile network technology. It shall, however, be designed in a way that it can operate independently from public mobile networks which are prone to failure in case of large-scale disasters. For example, in Germany and Austria state-owned mobile networks are in place or planned (so called “Behördenfunk”). The project will investigate how far the solution can couple with these networks and what certification requirements need to be addressed.
Yes, the requirements ask for appropriate training material for EMS staff and implementation guidelines for the procuring organisations. The solution shall enable regular staff training and support the use of the solution in exercises in a dedicated “training environment” within it.
The iProcureSecurity PCP project is looking for suppliers to develop a solution that meets the broader range of requirements as possible. The proposed solution shall encompass both hardware and software components. The evaluation will take into consideration that some requirements may not be fully covered. Thus, the consortium has prioritised the specifications which the proposed solution must cover.
As Phase III is called original development of limited volume of first test products, this corresponds to TRL levels around 7-9. Most PCP projects end with solutions that are tested extensively (in the case of our project due to the nature of the topics this can only be done through exercises) and are close to the market or even already available on the market at the end of the project.
Phase III will involve pilot testing in each procurer’s country. The solutions shall be tested in concert with the procurer’s existing systems as well as additional organisation’s systems (e.g., EMCC) in a simulated emergency exercise.
The training module is one of the key components of the iProcureSecurity PCP solution(s). Suppliers should propose a solution which includes – among others – an evaluation and training component.
More information on the structure and functionalities of the evaluation and training component, are described in the Call for Tenders.
[ upd 06.7.2022] Following the overall scopes of the Pre-Commercial Procurements, the iProcureSecurity PCP keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how this specific requirement should fit the proposed solution, taking into account the prioritization level of each requirement.
The Call for Tenders includes an overview of the project’s scope and defines which scenarios the solution shall support.The treatment phase begins as soon as the casualty is brought to the Advanced Medical Site (after being triaged) and it applies only in case a treatment is needed. The treatment phase may continue – if needed – in the ambulance, while the casualty is being transported to the hospital. The treatment phase ends as soon as the casualty is handed over to the hospital.
Scope Document Link
https://pcp.iprocuresecurity.eu/wp-content/uploads/2022/02/iProcureSecurity-PCP-Scope-Document-1.0.pdfSee Question Nr. 1.16. It is desirable to have a solution which covers all the languages, however, it is up to the supplier(s) to decide the level of the specifications of the requirements, depending on their prioritization.
This is specified in the Call for Tenders (TD1), as part of the requirements - specifically Section 1.6.1, Requirement R.5.1.1.
The requirements regarding ICT standards that have to be observed in the development of the solution are described in paragraph 3.4 (G) of TD1. In the Annex 4 the “Procurers IT Systems Checklist” reports the current systems used by the procurers, which are wished to be integrated as part of the iProcureSecurity PCP Solution. More technical details about the interoperability requirements of the systems currently in use (if feasible) and of the common APIs exist for data sharing, will be provided and analysed during the development of the phase I feasibility study.
One of the challenges of the research project objective is also to obtain interoperability with the EHR as well. More technical details about the interoperability requirements of the systems currently in use (if feasible) and of the common APIs exist for data sharing, will be provided and analysed during the development of the Phase I feasibility study. In this phase the requirements regarding ICT standards that have to be observed in the development of the solution are described in in paragraph 3.4 (G) of TD1.
One of the challenges of the research project objective is also to obtain interoperability with the existing IT systems as well. More technical details about the interoperability requirements of the systems currently in use (if feasible) and of the common APIs exist for data sharing, will be provided and analysed during the development of the phase 1 feasibility study. In this phase the requirements regarding ICT standards that have to be observed in the development of the solution are described in in paragraph 3.4 (G) of TD1.
Triage Tag Essential Information displays the colour/status of the casualty after having performed the first triage. It would be appreciated to have the following Triage Tag Extended Information:
display the heart rate; respiratory rate; display the arterial oxygen saturation; display the blood pressure.
The certification of the components as Medical Devices (MD) is not required at this stage, but if the solution involves the integration and use of software / App / Devices, already on the market, which correspond to the definition of Medical Device, then they must be certified.
PCP is a pre-commercial procurement for the research and development of an integrated “non-commercial” solution; the certification of the components as Medical Devices (MD) is not required at this stage.
But if the solution involves the integration and use of software / App / Devices, already on the market, which correspond to the definition of Medical Device they must be certified.
Furthermore, certification as a medical device is necessary for commercial or large-scale use therefore, Bidders should consider the issue of certification as a topic of their feasibility study and business plan and therefore it is important to include it as requirements within the Call for Tenders Documents.
The Tenderers are requested to offer the different communication solutions that meet this requirement: The Systems Integration (UC9) must be able to work without coverage of public networks.
The use of TETRA radio transmission is a possible solution but is not mandatory.
Following the overall scopes of the Pre-Commercial Procurements, the iProcureSecurity PCP keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how this specific requirement should fit the proposed solution, taking into account the prioritization level of each requirement and the current regulatory framework (MDR-Regulation (EU) 2017/745 & GDPR - Regulation (EU) 2016/679).
The Triage Tag should be able to recognise voice commands.
The iProcureSecurity PCP keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how this specific requirement should fit the proposed solution, taking into account the prioritization level of each requirement.
Yes, it refers to the triage history during the MCI.
With “highlight” the consortium means “to provide” photos and comments.
The consortium leaves it up to the solution providers to include environmental information.
The system should support the languages listed in the requirements to be available in the single countries.
When "other" is entered in the Interoperability Standard cell, more details have been entered in the "Interoperability Standards (NOTE)" column.
We are unable to provide further information on system interoperability at this step, more detailed clarifications will be provided during the feasibility study (Phase I).
When "most likely not open" is entered in the Interoperability Standard cell, the procurer is unable to guarantee access to its IT systems, during this phase, during the feasibility study (Phase I) we will analyse the possibility of interoperability tools with the third party software provider currently in use by the procurer.
Following the overall scopes of the Pre-Commercial Procurements, the iProcureSecurity PCP keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how to better implement the proposed solution.
Following the overall scopes of the Pre-Commercial Procurements, the iProcureSecurity PCP keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how to better implement the proposed solution
The Geolocalisation is one of the requirements listed (see Requirement 1.1.5 “Location of casualties - Geolocation”). We leave it up to the suppliers on how to apply the geolocalisation, whether from the triage tags or in different ways
The EDXL-TEP is an XML messaging standard primarily for exchange of emergency patient and tracking information from the point of patient encounter through definitive care admission or field release. Therefore the solution can use this suite of XML Messages. Moreover the PreCommercial Procurement keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how to better implement the proposed solution
The EDXL-HAVE is an XML messaging standard primarily for exchange of emergency patients. Therefore the solution can use this suite of XML Messages. Moreover the PreCommercial Procurement keeps the description of the requirements open, so that innovation and creativity from the suppliers’ side can be promoted. It is therefore up to the supplier(s) to decide how to better implement the proposed solution
R 1.2.42 refers to the capacity of creating digitalised “customizable initial MCI assessments (example METHANE Assessment)”, which should support the first responders in giving a first assessment of the MCI. It is therefore related to the UC1 for what concerns the “customisation” (KEY FUNCTIONALITY “The Central Information System (UC1) must allow customisation of main components (for example triage algorithm, initial assessment, guidance cards and checklists, user roles, terminology etc.”).
It is also related to UC6, as it will be the duty of the Category C to fill and complete the Initial MCI Assessment, as part of the Operation Site Management activities.
The R3.1.3 is one of the (Desirably) automatically measured vital parameters. It is therefore desirable to have this parameter measured automatically, via triage tag or also in different ways. We leave this decision up to the suppliers.
Similarly to question 1.39, also the R3.1.4 is one of the (Desirably) automatically measured vital parameters. It is therefore desirable to have this parameter measured automatically, via triage tag or also in different ways. We leave this decision up to the suppliers.
The casualties have to carry the most important information on themselves, so that the EMS have direct, quick, and easy access to the information. In case they need more information, they will consult the casualty profiles.
R 1.1.14 - Triage Tags - Basics - Voice Commands is thought to be part of the Triage Tag, as specified in the requirements. However, the Pre-Commercial Procurements want to foster innovation and the creativity of the suppliers. We therefore, may support alternative solutions as well.
R 2.1.10 Interoperability - Data Sharing EMS - have an integrated communication system for emergency management. It means to allow an easy, smooth, reliable and continuous communication system among the EMS and so provide a reliable platform for emergency communications between different EMS actors , to create an effective integration of emergency IT systems. We leave it up to the suppliers to decide which kind of systems.
The description refers to all the vital parameters, automatically or manually measured. Additionally, in order to foster innovation, we leave it up to the suppliers to decide on the proposed solutions.
See answer to question 1.38.
R 1.2.42 refers to the capacity of creating digitalised “customizable initial MCI assessments (example METHANE Assessment)”, which should support the first responders in giving a first assessment of the MCI. It is therefore related to the UC1 for what concerns the “customisation” (KEY FUNCTIONALITY “The Central Information System (UC1) must allow customisation of main components (for example triage algorithm, initial assessment, guidance cards and checklists, user roles, terminology etc.”).
It is also related to UC6, as it will be the duty of the Category C to fill and complete the Initial MCI Assessment, as part of the Operation Site Management activities.
See answer to Question 1.19.
This is specified in the Call for Tenders (TD1), as part of the requirements - specifically Section 1.6.1, Requirement R.5.1.1.
On this point it is necessary to provide maximum flexibility, not knowing the duration of the management process of a different type of Mass Casualty Incident. We let the suppliers decide the proposed solutions and it will be an evaluation topic during the feasibility study (Phase I).
This could be a good component of the solution, but it is not mandatory, the PreCommercial Procurement keeps the requirements description open in order to foster innovation and creativity from suppliers. It is therefore up to the suppliers to decide how to best implement the proposed solution
Yes, we confirm it. Casualty Profile Information indicates additional information through the interface of the device that reads/writes data on the triage tag.
On this point it is necessary to provide maximum flexibility, not knowing the area of a specific Mass Casualty Incident. We let the suppliers decide the proposed solutions and it will be an evaluation topic during the feasibility study (Phase I)