The practice of purchasing software with ownership of the source codes is obsolete and exposes the public administration to various risks.
On the one hand there is the principle of software as a product with all that this entails in terms of supplier liability and certification. On the other hand, the idea that the possession of source codes can make you independent from the supplier thus avoiding the lock-in phenomenon. Even today, in many tenders and specific contracts, attempts are made to reconcile these two aspects by requesting, for example, MDR certified software, perhaps class IIA, the willingness to modify it according to the needs of the healthcare company, with the consequent recertification, and the possession of the source codes.
All of this is a puzzle for suppliers and the lawyers they call on to unravel the intertwining of rules and responsibilities. In this regard, a question that was posed to Consip in the context of the clarifications to the digital health tender 4 and which I report in full is very interesting:
Request
Ref. General Technical Specifications Par. 4.3 “Regulatory context”
The General Technical Specifications in paragraph 4.3 in relation to the certification as a medical device of the software platforms being implemented reports the following: “It should be noted that where compliance with the purpose of use is mandatory, the implemented software platforms must be recognized as medical devices ( MDR certification) CE marked on the basis of Regulation 2017/745 is
entered into force on May 26, 2021 by repealing Directive 90/385/EEC (AIMDD) and Directive 93/42/EEC (MDD).”
In this regard, we ask you to confirm that:
The possession of the MDR certification, where applicable, of the platform being implemented is not a requirement for participation in a Specific Contract or response to a Supply Order, but must be achieved during the project execution and within the software compliance verification preparatory to the respective commissioning. This also in consideration of the fact that both in the case of the adoption of a market solution and in the case of ad hoc creation, the commissioning of the platform being implemented generally requires customizations and integrations with respect to the context of the single project which would in any case imply the activation of a specific certification process.
If the ownership of the platform being implemented is of the single adhering Administration
to the QA and not of the Supplier, also in the respective source codes, the responsibility for obtaining the MDR certification both of the adhering Administration itself, which being the Holder is identifiable in accordance with the MDR regulation as the Manufacturer of the platform itself, without prejudice to the Supplier’s commitment to comply with the minimum requirements established by the MDR regulation in the software production process.
Answer
Answer to question 1) in the case of Specific Applications, the MDR certification requirement is delegated by the contracting Administration, only in the case of acquisition of a market solution through ancillary services, in other cases such as for example for the Supply Order ( Direct Order) the certification can never be a requirement for participation but must be achieved during the project execution and within the verification of conformity of the software preparatory to the respective commissioning. Answer to question 2) is confirmed
The answer to the second question of the question states the principle that, for Consip, it is the administration that becomes responsible for obtaining the MDR certification as the owner and therefore manufacturer of the software platform. But can an administration assume this role? Does it meet the requirements that derive from it? Are you willing to take on this responsibility?
The merit of this answer is to have made it clear that it is not possible “have your cake and eat it too”. Software is a product or a service that must be chosen carefully, not a semi-finished product that adapts to your needs and then becomes its owner. This is not how you avoid lock-in or save money. How many cases are there of successful and convenient management of complex software by third parties and not by the same vendor who developed it (excluding basic software)?
Lock-in can be avoided or reduced by adopting truly micro-service architectureschoosing ad software high configuration and parameterization capacity, decoupling the different logical levels, adopting standard formats for the persistence and data access (e.g. HL7 FHIR or better yet, openEHR).
We leave the source codes to those who, by profession, develop and evolve them over time.
I like:
Like Loading…