The region of Catalonia has just published on the public procurement portal the award of the tender for the service of Clinical Data Repository platform in accordance with the openEHR standard for the Government of Catalonia. Here you have the link: https://contractaciopublica.cat/en/detall-publicacio/944a111e-7bec-d408-0756-42a2549aa849/200041523
The winning company has been the UTE IBM-VIEWNEXT, with a contract amount of 8,499,999.01 € (without taxes). The duration of the contract is 30 months, with the possibility of extension within a maximum of 24 additional months, being the estimated value of the contract, without taxes, of about 15.300.000,00 €.
The resolution of the award of the contract can be found in the attached PDF (in Catalan)
29_2023027L00_RE_Adj_sg_CA.pdf (296.5 KB)
Thanks for details!
- Does this contract amount include hosting of the CDR too (hardware, storage, maintenance, high availability etc)?
- Is this intended for the entire Catalan population (7-8 Million)?
If I understand this correctly the monthly average price would be € 283 333 before taxes. (Divided by 7 million inhabitants that would be a CDR cost of € 0.04 per inhabitant per month + tax)
- The service will be provided in colocation mode inside of the CTTI’s data center.
Does #1 mean that you (as healthcare providing organisation) don’t have other costs, in addition to the ones you will pay for via the contract, for keeping the server side of the CDR technically running?
The objective is to have a provider that offers the end-to-end service requested, which goes from a data repository service based on the openEHR standard, the management of this same service and all the layer of architecture and technology necessary to provide and ensure the services that are required in a transactional repository.
Congrats to Region Catalonia and IBM/Vitagroup! It will be exciting to follow your journey!
to 27. huhtik. 2023 klo 11.53 ap. Daniel Alomar via openEHR <firstname.lastname@example.org> kirjoitti:
I guess that applications, like the recently chosen medication/pharmacy support will run on top of this CDR service.
Are any of the following things included in the CDR contract?
- form-editor+renderer (or low-code tools)
- generic portal functions (for staff and for patients) where forms/UI can be used and CDR content be browsed
- patient registry/index (PIX?) e.g. for connecting openEHR’s ehr-id with other identities, name etc?
- Handling of bookings, referrals etc
If not, will they be procured or built separately?
Thanks for sharing. Where do I find details on the solution and the different companies?
What CDR are you buying, I read vitagroup so I assume ehrbase?
What roles do the other companies fulfill? IBM?
Due to confidential agreements associated with contracts with the company that won the bid, we cannot make public some details you were asking for.
- Simple queries X milliseconds response time
- Complex queries Y milliseconds response time
- Is that correct?
- Could you please share the requirement text regarding this (in Catalan or English) or point to a section in some published document, so that others can reuse your thinking/structure? (E.g. what is simple vs complex, how and where do you measure response time.)
We do not distinguish between simple or complex queries
- Response time for queries: 40 ms
- Response time for create, update and delete: 60 ms
Inside the CDR procurement, information regarding queries is located inside the following section (unofficial translation):
3.2.6 Information availability query for the extraction
Attention to requests for the availability of information for its extraction from any potential user of the repository.
An interface for the management of availability inquiry requests must be made available to system users.
To respond to these queries it will be necessary to maintain a repository with the information available on the extractions, location and their refresh frequency, being able to manage this service with an intelligent query interface.
Regarding the numbers, there are the SLA HESCDR-13 and HESCDR-14 (section 9.5) where we want to have indicators of those response time for creation/modification/delete and queries respectively. This SLA refers to a public architecture document, available at:
The information inside this PDF (catalan) is located inside table 1, performance (unofficial translator again):
Update, delete and modification operations of unique record: maximum accepted 60 ms (milliseconds), within a 95th percentile.
Query operations of unique record: maximum accepted 40ms, within a 95th percentile
Inside the transactional repository we only accept pre-stored AQL. Free AQL only on query replica with best effort service.
Thank you @Daniel.Alomar! Wonderful and very useful for general inspiration in procurements.
I ran the PDF through auto-translation at deepl.com and uploaded here:
It did not have Catalan as a choice (sorry) but auto-picked Spanish and produced a pretty readable file that I belive kan be used as inspitration, even though it will contain some fishy translation glitches like:
If I am correctly informed you’ll soon load 500 million immunisations into the system, it would be nice to hear if the requirements are met once you (and/or your provider) have tuned the system.
Let me know any section you have doubts concerning the translation, and I will give you and unofficial translation. The translation of this section would be:
2.4.3 Automatic deployment
All pieces and components of the architecture will have to be deployed automatically. Solutions that have component-based definitions of the relational database type will need to be managed by appropriate DevOps tools (Liquibase, Redgate, Flyway, DBmaestro, …). In the same way, components must be able to be deployed on the user’s workstation. Automatic deployments must also ave mechanisms to execute rollback automatically.
BTW, here there are resources to learn our beautiful language:
We are pleased to announce on November 30th, 2023, the Clinical Data Repository platform transitioned into the production stage!
You can find more info in the Jordi Piera’s LinkedIn post: