Regarding sections 2.5.1 “Versions of openEHR supported by form authoring
tools” or 3.5.2 “Authoring environment” make sure to add another reqirement stating that the tools need to expose and make it possible to use also unconstrained parts of the RM that have not neccesarily been mentioned in the template. The same goes for AQL authoring tools, sections 3.6.1 and/or 3.6.2 - they also need to expose/support unconstrained parts of the RM.
These things become obvious when using tools in varied and realistic scenarios and are thus usually available in mature openEHR tools, but certain newly created tools on the market have been found to not support this from the start.
This is essential, and it needs to go even a bit further, for example to enable app builders to be able to represent on forms:
demographic references and/or data
(optionally) version-related elements like VERSION.lifecycle_state - i.e. to be able to control whether data saved (e.g. a discharge summary) is draft, complete, deleted and so on.
Another area of necessary support is for the Instruction State Machine (ISM), such that templates based on Instruction and Action archetypes have the state machine behind them, and that for any given pathway step of some particular Action, it is visualisable which next state transitions (and therefore which next pathway steps) are available from that point.
Another tip regarding things to make sure your procured openEHR form authoring tool should support, that is not currenlty available in every openEHR form tool on the market:
At runtime letting the user add more instances of a form section based on a repeatable (n…m, e.g. 0…*) template subtree.
continued example of implementation in a form tool (by Better) - edit mode - nothing special needs to be done by form author, multiplicity correctly picked up from template:
Indeed, multiplicity is extremely useful and necessary when designing templates for histopathology. The examples below are taken from the wonderful work Erik did in the project in Stockholm and other regions of Sweden re implementation of openEHR templates and forms (with embedded SNOMED CT of course) and the exchange of generated data between different CDR’s.
I updated the title of this thread (removed dates etc) in order to better fit new things…
There are rumours that several Swedish regions and organisations are again interested in doing RFIs and/or procurements regarding openEHR platforms and tools in the beginning of 2023. Also for some organisations existing openEHR-related contracts are due for reevaluation before possible renewal (or ending) before the summer.
I believe it would be clever for many/all Swedish actors to collaborate regarding RFI questions so that system vendors/suppliers do not need to answer many different actors.
When it then comes to actual procurement it may be harder to procure together and I believe vendors/suppliers would be smart to already now prepare for also providing their offerings via already existing Swedish framework agreements as described above in post 19: Swedish openEHR procurements & RFIs - #19 by erik.sundvall (That means you need to talk to framework actors listed at e.g. avropa.se)
The latest openEHR RFI in Sweden that I know of is the one described in The Swedish openEHR platforms and tools RFI 2023. It is finished, videos of meetings with suppliers and a final report are availabe in that thread.
After that RFI, Region Stockholm and Gotland started a procurement, coordinated by Karolinska University Hospital. It is now underway and framework agreements are expected to be signed in February or March 2024, followed by call-offs over time when different needs arise. See info about that procurement in the thread Karolinska/Stockholm procurement of Digital health platform (CDR, tools, services, consultants)
