Following The Swedish openEHR platforms and tools RFI 2023 by seven Swedish regions, Karolinska University Hospital is coordinating a procurement for several organisations active in Region Stockholm and Region Gotland. Listed organisations besides Karolinska are: Södersjukhuset AB (SÖS), Södertälje sjukhus AB, Danderyd Sjukhus AB, Tiohundra AB, St Eriks Ögonsjukhus, Ambulanssjukvården i Storstockholm AB (AISAB), Hälso- och sjukvårdsförvaltningen (HSF), Stockholms läns sjukvårdsområde (SLSO), Region Gotland. The official EU-tender call is available at Services - 555615-2023 - TED Tenders Electronic Daily that in turn links to the call at the procurement portal: Mercell TendSign. Anybody interested in actually responding to the tender should register there (for free) to get notifications of changes and responses to questions. The documents will very likely get updated several times and the copies attached to the Wikipage https://openehr.atlassian.net/wiki/spaces/resources/pages/416514052/Procurement+of+openEHR-related+systems+and+services may be out of date and erraneous by the time you read this. Following this forum thread is no guarantee to get all updates, instead subscribe to updates in the portal. Framework agreement period is 2+1+1 years. Estimated start of (framework) contract is 2024-02-01. Phase 1 (qualification) closes 2023-10-12 23:59 Estimated total value 154 000 000 SEK (all areas added together, over the full length of framework agreements) A simplified explanation of the process and scope follows (it is not necessarily a legally correct description, see the procurement portal for the real thing. There are three areas. openEHR-based Software. With subcategories: 1a. Software for storage and management of openEHR-based data (CDR etc) 1b. Software for fine-grained access control 1c. Software for fast development, publication and maintenance of openEHR-based applications 1d. Software Services Software for openEHR content Creation and Transformation Consulting Services Note that many actors/providers will likely be interested in responding to only to one or two of the three areas, and thus do not need to bother about the details of the other areas. There are several phases (following each other in time) [image] The first Phase published today, closes October 12. It’s purpose is to qualify and reduce number of candidates allowed to make bids for framework agreements. If you pass this you get an invitation (activity #2 above) to submit a framework tender/bid. When the framework has started (activity #5 above) and any of the organisations behind the agreement (for example Karolinska or Södersjukhuset) actually need to buy e.g. platforms, tools or services from any of the three “areas”, every supplier that has won a framework agreement for that area gets a chance to bid for that specific item in a relatively simple and fast process. Also the requrements, for example for a consultancy assignment, tool or platform, will be specific for the task at hand which makes the process easier for everybody involved. Personally I would recommend starting by reading relevant parts of Appendix 2, the “Area description”. A snapshot version is available at https://openehr.atlassian.net/wiki/download/attachments/416514052/Karolinska-DHP2023-Appendix%202%20Area%20description.pdf?api=v2

[image] fredriklinden: jag tror att igrant.io LCubed AB borde vara med You are sadly a couple of hours late. The qualification phase closed 23:59 yesterday as annouced previously in this thread.

Thanks for all procurement responses in phase one. There is healthy competition within all three procurement areas. We are now preparing for phase two of the process and qualified participants from phase one will recieve an invitation to it.

We’d like to remind all responders to continously watch/read procurement portal messages, in case you during the process get questions or requests for clarifications etc. that sometimes may have fairly tight reponse deadlines.

The first phase of the procurement and its evaluation is now finished, and an invitation to submit tenders for framework agreements has been sent out to a number of potential tenderers within all three earlier mentioned procurement areas, a healty competition remains in all areas. (That invitation contains a lot of requirements that we hope to be able to later also publish in this thread for potential reuse by others.) Last day to respond in this phase is January 17, but the opportunity to ask questions and ask for clarifications closes earlier, so make sure to check all documents and dates in the procurement portal.

The companies that will be awarded framework agreements were announced via the procurement portal yesterday. There is now a period of 10 days that needs to pass before contracts may be signed (due to procurement rules). Companies in the three procurement areas, alphabetically ordered within each category: 1. openEHR-based Software (CDR+PMI+Form/UI solutions etc.) Better d.o.o Medblocks Tietoevry AB 2. Software for openEHR content Creation and Transformation (tools, auxillary systems etc). Information about offered products from each vendor within Area 2 will be published after contracts have been signed and publication detalis have been discussed. Better d.o.o Cambio Healthcare Systems AB Cuviva AB Eweave AB Medblocks Ocean Informatics UK Limited Service Well AB Tietoevry AB 3. Consulting Services Better d.o.o Cambio Healthcare Systems AB CGI Sverige AB Eweave freshEHR Clinical Informatics Ltd Medblocks MedMod AB Ocean Informatics UK Limited Service Well AB Tietoevry AB Congratulations to all! Information about most of these suppliers can be found on the list of OpenEHR Industry Partners This part of the procurement, coordinated by Karolinska University Hospital on behalf of several organisations active in Region Stockholm and Region Gotland will be concluded when the framework agreement contracts are signed. During the following framework agreement period (2+1+1 years) call-offs of different products and services can be done by the following organisations jointly or separately. Procurement groups at these organisations can get acccess to detailed responses and ceiling prices of products and consultancy rates: Karolinska University Hospital, Södersjukhuset AB (SÖS), Södertälje sjukhus AB, Danderyd Sjukhus AB, Tiohundra AB, St Eriks Ögonsjukhus, Ambulanssjukvården i Storstockholm AB (AISAB), Hälso- och sjukvårdsförvaltningen (HSF), Stockholms läns sjukvårdsområde (SLSO), Region Gotland.

This morning the following was sent out to framework agreement partners of Tender Area 1, by Espen Sigvartsen (Manager department Datastorage and Application Development, Karolinska University Hospital). I am resharing it here with his permission: For your information Karolinska University Hospital is planning a first call-off on the framework agreement Digital health platform. The first call-off will be in Tender Area 1 Open EHR- based Software. Our plan is to publish the call-off week 19 in May 2024 [the week that starts with May 6], with a response required within two weeks. We are planning to ask for the following (but not limited to): An openEHR-based Clinical Data Repository (CDR) initially delivered as a service (SaaS), with possibility to change to on-prem during the contract period. Collaboration project regarding configuring and developing functionality for fine-grained access control. Services related to the above. There will also soon be another call-off for informatics expert consultancy within Tender Area 3 regarding integration (openEHR modeling and mapping) from our legacy EHR (TakeCare) to openEHR, initially in the form of a PoC (Proof of Concept). One of the first domains to map will be medications, several other medical domains will follow. For Tender Area 2 we have not yet scheduled a call-off.

[image] erik.sundvall: Collaboration project regarding configuring and developing functionality for fine-grained access control. Hi Erik, I’m also working on access control for openEHR. Would be great to discuss maybe in a seperate topic? Design an acces policy language for openEHR ‘resources’ based on nuts verifiable credentials opened 01:15PM - 23 Apr 24 UTC (UTC) [joostholslag] joostholslag Authorization In order to be flexible in creating many use cases where nuts facilitates trust …in sharing openEHR formatted data, it is useful to define a language to describe access policies for openEHR formatted data based on verifiable credentials (VC). A specific policy could be: all doctors (proven by BIG number VC) have acces to any COMPOSITION.ACP for any patient. The generic (non-openEHR specific) requirement is described by @woutslakhorst in the April 2024 community Meetup. https://www.youtube.com/watch?v=TXS0I7D2GeM This language must be human readable and should be computer interpretable. Computer executable is a nice to have. The policies must be implementable by different openEHR platform vendors in a way that systems from different vendors will work together based on a shared understanding of the policies. One of the key requirements is the language should concisely identify an openEHR ‘resource’ scope. Similar to how HL7 FHIR describes it in smart app launch: https://www.hl7.org/fhir/smart-app-launch/2021May/scopes-and-launch-context.html#clinical-scope-syntax Possible openEHR resource scopes (compartiment X resource expression X permission) are listed here: https://specifications.openehr.org/releases/ITS-REST/latest/smart_app_launch.html#_scopes_for_openehr_rest_api E.g. ‘patient/template- .r’ : Permission to read a template with The other key requirements is a definition of a VC that gives the access to the resource. E.g. “doctor”, “employee relationship with care organisation” “organisational membership of a network”, “ura” “uzi” etc. In a PDP the following needs to happen: - The "Trust" package from NUTS - The "data" from the resources - Some kind of "shared business logic" to translate the "Trust" info into a decision based on the above. There are multiple attribute types of trust: - The organization: - Membership credential - Role - permission database / dataset / rulebase - The person - Identity (UZI) - Global role (BIG) - Role in organization (URA - rolcode) - The Shared Care Planning information. This implies the following checks on the PDP - The organization is a valid member - This the person identified with the right attributes - Relational checks: 1. Relation: Professional > Organization: The the access profile matches the role of the person _in the organization_ 2. Relation: Patient > Professional > Organization: The Shared Care Planning (Patient > CarePlan >* CareTeam > Member > Professional(Role,Org)) relationship role matches the access_profile. Which might materialize to (Patient > Professional(Role,Org)) The question is if the relational check is done before the call is make, checked by the requester, and materialized as proof or that the check should be done by the PDP? Rego, the language used by Open Policy Agent is a language to describe (AB) access control policy, but it’s generic and it doesn’t natively support identification of openEHR resource scopes nor nuts VCs. Also the language is quite low level (‘if’ statements) so it’s human (other than developers) readability is limited. (Do we need this?). it is interpretable and executable only by (open source) OPA software. The only known (to this project) alternative is XACML. But apparently it’s dead. And it’s not really human readable. So the rules it out as a candidate. edit: new topic access control for openEHR 'resources'

Please, let me know where this topic will be discussed. I am also interested on.

Hi, would also be very interested in keeping up to date on how the discussion for this proceeds. Had some debates regarding an implementation of this recently and was quite astonished to see that even for the underlying mechanism, there is a trend to also push the access control/consent management to smart contract implementations.

Karolinska/Stockholm procurement of Digital health platform (CDR, tools, services, consultants)

Community Procurements

birger.haarbrandt 26 April 2024 09:38 20

@joostholslag please keep us in the loop how things are going for OPAL. Our architects made an evaluation and then decided to go with XACML 3.0 instead of OPAL, but I don’t have the details.

access control for openEHR 'resources'

Topic		Replies	Views
Swedish openEHR procurements & RFIs Procurements	27	7665	7 February 2024
Procurement requirements for an openEHR native forms tool Procurements	25	746	24 October 2024
The honest story about implementing openEHR as an EHR-vendor New to openEHR?	11	2273	8 October 2026
Join or comment CDR Catalyst initiative from Karolinska General Discussion integration , cdr , interoperability , ai	11	1627	1 October 2026
Data extraction from openEHR - a demanding and challenging task? Implementation	25	819	19 August 2025
How to start Technical (archive)	26	154	15 August 2013
Relationship openEHR/CIMI Clinical (archive)	17	106	30 October 2014
lessons from Intermountain Health, and starting work on openEHR 2.x Technical (archive)	30	192	8 October 2012
Echocardiography - Change of "Imaging result" CLUSTER archetype? Reuse lab analyte design pattern for nested/repeated clusters? Clinical archetype , template , aql	14	1118	28 May 2025
Approaches to Learning openEHR Clinical (archive)	14	92	6 April 2016

Karolinska/Stockholm procurement of Digital health platform (CDR, tools, services, consultants)

Related topics