# Procurement requirements for an openEHR native forms tool **Category:** [Procurements](https://discourse.openehr.org/c/procurements/24) **Created:** 2024-10-18 12:31 UTC **Views:** 559 **Replies:** 25 **URL:** https://discourse.openehr.org/t/procurement-requirements-for-an-openehr-native-forms-tool/5818 --- ## Post #1 by @jpieraj Dear colleagues, Imagine you would like to procure an openEHR native forms tool. What would you ask for? So far, this is what we have assembled. Thoughts are welcome :slight_smile: ## Core openEHR Functions 1. Template Management * Support for OPT 1.4 and 2.0 templates * Conversion tool from OPT 1.4 to 2.0 versions 2. openEHR Resource Utilization * Ability to use openEHR RM resources (e.g., Event-Context) for querying and updating data 3. AQL Integration * Integration of AQL for retrieving information * Advanced functions for AQL building and management ## General Functionalities ### 1. User Interface * Drag-and-drop designer with point-and-click approach * Predefined forms, reports, and dashboards * Chart and graph generator using JavaScript libraries ### 2. Interoperability * Support for code generation platforms * Connection with relational and non-relational data sources * Integration with FHIR tools ### 3. Security * Data encryption capabilities * Access security through JWT token management ### 4. Collaborative Development * Integration with offline and online collaboration tools * Support for multiple form repositories sharing the same templates ### 5. Scalability and Performance * Architecture supporting user and data volume scalability * Advanced usage reporting for developments ### 6. Business Logic * Rule engine with graphical and textual environment * Dynamic workflow generation based on user interactions * Approval process management ### 7. Application Building * Integration with open tools for real-time code generation * Deployment support on open platforms * Management of inter-form interactions ### 8. Additional Integrations * Event management tools (e.g., Kafka) for listening and generation * AI tools for application assistance and usage analysis ## Open Environment The tool should provide at least basic functionalities in an open environment, promoting accessibility and community involvement. Jordi --- ## Post #2 by @jake.smolka [quote="jpieraj, post:1, topic:5818"] Integration with FHIR tools [/quote] Hey Jordi, As backend dev, I have super limited experiences with procurements etc. But what does "integration with FHIR tools" mean here in detail? --- ## Post #3 by @Eugene_Kolah Hi Jordi, This is intresting, and very possible indeed. It would help knowing the targeted end user profile. --- ## Post #4 by @Koray_Atalag Hi Jordi, I've been involved in quite a few procurements for enterprise health IT projects in NZ. It's been a long time but I'd break requirements into functional and non-functional plus a separate commercial one (e.g. pricing breakdown, licences, warranties etc.). Here's a sample list: ### Functional Requirements: 1. **User Management**: Ability to create, edit, and delete user accounts. 2. **Data Import/Export**: Capability to import and export data in various formats (e.g., CSV, Excel). 3. **Reporting**: Generation of customizable reports based on user-defined criteria. 4. **Integration**: Compatibility with other systems and software (e.g., PAS, EMR). 5. **Security**: User authentication, authorization, and data encryption. 6. **Scalability**: Ability to handle increased load and user base. 7. **Customization**: Options for customizing the user interface and workflows. 8. **Support**: Availability of customer support and service level agreements (SLAs). 9. **Backup and Recovery**: Regular data backups and recovery options in case of data loss. ### Non-Functional Requirements: 1. **Performance**: Response time and system throughput. 2. **Availability**: Uptime and reliability of the service. 3. **Scalability**: Ability to handle increased load and user base. 4. **Security**: Data encryption, user authentication, and access control. 5. **Usability**: Ease of use and user experience. 6. **Maintainability**: Ease of maintaining and updating the system. 7. **Portability**: Compatibility with different devices and platforms. 8. **Interoperability**: Ability to work with other systems and software. 9. **Disaster Recovery**: Procedures for data recovery in case of system failure. 10. **Compliance**: Adherence to relevant industry standards and regulations (e.g., GDPR, HIPAA). Hope this is helpful. I'd be happy to provide more details if needed. --- ## Post #5 by @HPORRASG Qué tenga integraciones con servidores de terminología, de preferencia FHIR. Que tenga un módulo donde se puedan probar los templates generados. Que permita documentar de manera fácil el template y/o arquetipos generados. --- ## Post #6 by @Alvin_Marcelo Thanks for these - Jordi's list plus Korey's looks formidable. Should we also ask for certified experts from the company? Since this is an openEHR list, would certifications from suppliers help improve the success of the project? If yes, what might these be? --- ## Post #7 by @Daniel.Alomar Hi Jake, Perhaps this graphic will help explain our approach and the integrations we believe this tool should include ![Forms_1.drawio_ENG.drawio|672x500](upload://69WP2nwJ5QDEEgdZNuxlxF7bq3I.png) --- ## Post #8 by @pablo [quote="jpieraj, post:1, topic:5818"] ## Core openEHR Functions 1. Template Management * Support for OPT 1.4 and 2.0 templates * Conversion tool from OPT 1.4 to 2.0 versions [/quote] Hi @jpieraj I think the Template Management is not part of the forms solutions because it's a different concern, so it's kind of violating the separation of concerns design principle. Though I know the forms solution should *use* templates, so it might be better for the architecture to have integration with a Template Management component than having the Template Management inside the forms solution. It also maker your architecture more solid since you can use any Template Management solution from the forms solutions you buy, so if tomorrow you need to change or even use many at the same time, you won't have any issues. But when you have that inside your solution, you might not be able to change that component. Best, Pablo. --- ## Post #9 by @erik.sundvall @jpieraj and @Daniel.Alomar I hope you have already found https://openehr.atlassian.net/wiki/download/attachments/416514052/Karolinska-2024-A1C1-Appendix%202%20Requirement%20Specification.xlsx?api=v2 that is linked from https://discourse.openehr.org/t/karolinska-stockholm-procurement-of-digital-health-platform-cdr-tools-services-consultants/4457/26?u=erik.sundvall there you in especially in"chapter" 4 find things related to tools for forms, AQL etc. screenshot below shows the start of that chapter, but that chapter is _a lot_ longer than what fits in to a screen... ![image|690x466](upload://xorwLI62pLjkNomAakxrHnOH5Tt.png) --- ## Post #10 by @mikael I think that integrated terminology and ontology services (including ICD, SNOMED CT and other) also should be included. --- ## Post #11 by @jpieraj Thank you all for your comments. We are processing them and will come with a refined list :slight_smile: --- ## Post #12 by @Koray_Atalag Further to my generic list, which doesn't add much value to functional requirements for openEHR based form tool, here's an exhaustive list of FHIR based form tooling: https://confluence.hl7.org/display/FHIRI/SDC+Implementations In terms of creating model based UI forms IMHO there is a lot commonality which might be useful to expand on requirements. Having done research on UI generation off openEHR models (templates - .opts) there is a need for additional properties to drive usable automated UI generation. I called them as "GUI Directives" and added as annotations to Templates (in Ocean Template designer - which still comes with the setup!). [HERE is the link to paper](https://www.researchgate.net/publication/268923302_From_openEHR_Domain_Models_to_Advanced_User_Interfaces_a_Case_Study_in_Endoscopy). There was some disagreement at that time ( 2012 or earlier) whether this GUI related properties should be part of templates or a separate artefact. I believe with good tooling it should be separate but for practical reasons maybe best as part of Templates as they are use case specific and meant to drive building Apps. Here's some other requirements to consider: 1. able to work with terminology service (FHIR presumably) and support given operations (as @mikael mentioned) 2. (semantic) versioning of forms (e.g. 1.2.4) to ensure the right version of a form is used to create UI (that is separate from content model - which is already covered in CKM process). In addition a CKM lite kind of forms lifecycle and publishing functionality would be essential to manage a large number of forms across many users/orgs. 3. For collaborative form development a RBAC to set permissions at form and/or data element level as to who has edit access vs read etc. 4. Not sure whether the purpose of the forms App will be provider or patient facing (presumably both) so will need to render for each device appropriately. You may also consider specifying front end tech like React Native and ability to support Lambda functions for good scalability and performance. Also consider a store and forward type support for web app (e.g. PWA) in case there's internet connectivity issues so entered data is not lost. 5. For mobile app (if any required) it's important to consider web app (e.g. PWA) vs native app. 6. open vs closed source 7. Native cloud based vs hybrid or local server/data centre) - most cloud providers offer similar services but all require some tweaks to make it work on another provider. So, it should be developed in a way that's cloud agnostic/neutral --- ## Post #13 by @rong.chen [@jpieraj](https://discourse.openehr.org/u/jpieraj) and [@Daniel.Alomar](https://discourse.openehr.org/u/daniel.alomar) Very interesting requirements, and it helps to have the architecture diagram. Some are perhaps straightforward since we are talking about an openEHR native forms tool. **Relevant openEHR standards** openEHR RM, ADL, AQL, GDL (decision support rules), TERM and REST APIs, as described on https://specifications.openehr.org/release_baseline. This is mainly to ensure the openEHR tools are interoperable and vendor neutral. **Scope** Great to understand what are considered as core functional requirements for the “forms tool” product itself and what are extensions and possible integrations. The latter category is likely open ended and could be performed and evolved by 3rd parties as long as necessary integration APIs are in place. Terminology service and various code generation capabilities should be considered as integration and extension of forms tool in my view. Echoing Pablo’s comment, the forms tool should be part of a background clinical knowledge management environment where all reusable clinical models (archetypes, templates, queries, guidelines and forms) are shared, versioned and managed. Such CKM could provide basic import/export, search, and common format conversion services so they don’t need to be any tools. **Forms vs apps** It is tempting to including application development requirements in the forms tool, in fact we find ourselves developing clinical decision support applications using forms too. If this is the intention (as hinted by no.7 and 8), there are some more relevant standards to consider: CDS hooks, SMART on FHIR & [openEHR](https://specifications.openehr.org/releases/ITS-REST/development/smart_app_launch.html) and some additional requirements on deployment, monitoring and release management. But perhaps these are outside the scope of a forms tool. --- ## Post #14 by @SteveHarris I think - as implied in Daniel's graphic - you need to separately specify two different services: a designer and a runner. Each have very different functionality. I'm not an expert in runner tech, but clearly it will need to be able to fully exercise the capabilities of the template/form language and neatly integrate with security, demographics, terminology and EPR services. Easy and obvious configuration facilities would also help. If I were procuring a form builder tool, there are a couple of things that would be high on my list, and most of them surround the process of migrating off an existing EPR into an openEHR model. Being able to (mostly) import other forms formats would be high - most EPR systems in use in the UK hold form designs as data, so being able to provide a template to match imported records would greatly help in EPR migration. Having talked variously to openEHR people about migration and legacy, I've yet to hear a good solution to the 'there are no archetypes in legacy forms' problem. I don't think its right to assert that a form design conforms to a set of archetypes and issue a template as if this were the case - I would prefer if there were some facility to assert that 'for the purposes of this AQL statement only treat *this* field in *this* adhoc template as if it were from *this* archetype'. I also find the 'archetype/template' language - while perfectly sensible when talking to a software engineering graduate - a little difficult to explain to people who understand the business and practice of care so it would be nice if this was somewhat hidden from them in a user interface they were expected to use. 'Form' and 'reusable section' would be much more easily communicated. FTR I've been involved in form driven architectures for pretty much all of this century, and I edit ISO/IEC 19763-13. Happy to chat. --- ## Post #15 by @mikael For example, the SNOMED CT Maturity Framework can be of help when procuring EHR systems. [Implementation Maturity - SNOMED Implementation Support](https://confluence.ihtsdotools.org/display/IMP/Implementation+Maturity) --- ## Post #16 by @lars.lindskold Thank you, Rong, for your insightful point about forms and their scope; you always trigger my brain to start thinking 😊 . Building on that, I’d like to share an observation about how forms have long been essential tools for structuring human information—especially in healthcare. Forms serve as a means to gather, categorize, and validate data with a clear purpose in mind. They shape how we interact with and interpret information, molding data to fit specific contexts and tasks. In the evolving landscape of healthcare, where machine-readable data is increasingly vital, AI has the potential to revolutionize the way forms are used. Imagine if forms became dynamic entities—able to adjust their fields, structure, and even the type of input in real-time based on context. With AI, we could move beyond the static, one-size-fits-all approach toward forms that adapt to user interactions, suggest relevant fields, or even pre-populate data based on historical or contextual analysis. AI-enhanced forms could ensure that information not only meets immediate needs but is also reusable across different clinical systems—such as EHRs and recomendation-support tools—with minimal friction. This adaptability could lead to more interoperable and intelligent forms, much like how we adjust our communication styles depending on the context of the conversation. In doing so, AI would help bridge the gap between structured data collection and the complex workflows found in clinical environments. The ultimate goal is for AI to not just transform but to support the form-creation process in a way that keeps forms fit for purpose while being flexible enough to evolve as those purposes expand—whether for recommendation support, patient-reported outcomes, or other critical areas of healthcare. This empowerment through AI could enhance the governance, validation, and semantic integrity of forms across domains, adding significant value beyond traditional, static formats. **To end with a more philosophical reflection**, as AI transforms forms, it invites us to reconsider our relationship with information. Are we merely passive recipients of data points shaped by predefined structures, or can we become active participants in a dynamic exchange with our tools and services? As forms become more intelligent and adaptable, they challenge us to rethink the nature of knowledge itself. How do we balance the flood of information with meaningful insight? And in an age where data is both fluid and interconnected, what does it really mean to "know"? *Is the future only to react, or are we still allowed to think?* I’d love to hear others' thoughts on how adaptable forms could improve human-machine collaboration in clinical environments! Lars Lindsköld --- ## Post #17 by @Pete_Bouvier Blimey Lars, why aren't you speaking at the conference!? --- ## Post #18 by @Daniel.Alomar Hi Lars, I completely agree with you that AI can, and in fact, is transforming how we interact with clinical data. AI is here to stay, and this is why we believe that AI can be a tool that aids in areas such as the creation of forms and as an usage analysis. A more extensive use of AI in interacting with clinical data involves a more thorough analysis of the associated risks, such as biases introduced by the training model or those arising from the chosen usage model. A local model has very high costs in terms of computation and training, while a cloud-based model raises privacy concerns. Perhaps RAG systems could be an option, though maybe not in the initial stage of this tool. --- ## Post #19 by @Simon @rong.chen and @pablo point about storing the form data into the clinical record (via templates and archetypes) is absolutely crucial. Lets be honest vast amounts of clinical data are left to rot in proprietary forms engines. None of it ever gets back to the clinical record, the value of that information is huge. The forms designs I have always been involved in are always process driven. Generally you will always need to make decisions based on information gathered by forms. Most workflow engines will include a forms designer. In my experience designing the form before understanding the process causes a lot of pain, unfortunately I have seen it done quite a lot. I always think of forms as CRUD transactions. The viewing of a clinical record is a completely separate concern (a bit like CQRS), I wouldn't really think about forms as the best way of displaying the record. They are just a transactional method for creating information. Driving the view of the clinical record by context is so important, I have worked with a lot of clinicians who have expressed their frustration at trying to view a patient's record by using forms. @lars.lindskold the AI stuff sounds very interesting. If you step outside of healthcare IT for a second and look at other industry sectors (I worked in 'content management') they derive knowledge from the information they consume using ontologies , so its all possible and very exciting. Just not a part of forms until they can help create and perhaps drive the improvement of clinical processes. Sorry for the ramble but I've created more clinical forms than I will ever admit to. The @rong.chen point about putting the form data into the CDR is, for the hospitals I worked in, revolutionary and ground breaking. --- ## Post #20 by @varntzen Hi As a general rule, I would like to warn against being too specific in procurement requirements. An example below: [quote="jpieraj, post:1, topic:5818"] ## Core openEHR Functions 1. Template Management * Support for OPT 1.4 and 2.0 templates * Conversion tool from OPT 1.4 to 2.0 versions [/quote] If I've heard right, it might not be v.2.0 to become the version for most vendors in the near (?) future. Even if, the version will eventually be superseded by something newer, so a too specific requirement of "OPT 1.4 to 2.0" can be risky. A more general phrase, with meaning like "be able to handle conversion from older to newest version, and versions between" would be wiser. (Someone with more knowledge of formal language will have to translate that one :smiley: ) Another issue is to open for dialogue based procurement, where there is no static list of requirements, but a list of features described more open-ended, and discuss with respondents what, and how that can be solved. --- ## Post #21 by @xabiermichelena Excellent comment @lars.lindskold! Completely agree and very stimulating indeed. In a discussion with @jpieraj about this, we got to the point that a good start could be that the forms adapt to: who I have in front of me (the patient: its conditions, medication etc...), who am I (the healthcare provider: my specialty etc...) and the setting (where the encounter is happening). AI can definitely help with this fluidity but also old school logic if the information needed is there. At the end, is probably the combination and integration of CDS (clinical decision support) tools with the forms to capture and follow the care process. If an EHR is capable of swift integration and can adapt to different contexts in real time, it’s a winner! --- ## Post #22 by @SteveHarris Using AI to assess and help develop forms is a complete no-brainer in my mind, but having AI in the loop in certain ways while completing a form (as opposed to simply completing a good prose journal entry) worries me. The point about a form is that it fixes requirements and place in workflow - it captures background meta- and master-data, helps the user to working out if the form is appropriate to complete, ensures essential data for the encounter is captured in a representation that can be reused, and then allows the user to state - in a structured way - what kind of activity should follow either by explicit statement or by classifying the case for a workflow engine. It then provides a transaction that can be signed by the completer in their professional capacity. Having active AI in the loop risks spoiling the contract implied by 'I answered this form as recommended by {insert approving body here} and discharged my responsibility. --- ## Post #23 by @SteveHarris For the record, Dipak Kalra is talking about some of these requirements right now in a TC215 working group meeting --- ## Post #24 by @oughnic He is explicitly asking for information requirements of an EHR system - I think this thread is a significant contribution. Would be good if openEHR community members could contribute through their ISO/CEN member body. --- ## Post #25 by @ian.mcnicoll A big problem has been that traditional form builder products just capture data, and are very poor at displaying or updating existing background or persistent data. If you are lucky they might allow you to copy through data from an existing form but that is just a hack. In the London UCP we have been using an approach which allows multiple templates to site behind a single 'form' . So for example if a sickle cell care plan 'form' expects to be able to see and perhaps add to the patient's allergy list , that can be supported. The form interacts with both the core contextual sickle cell pan and the global allergies list. This fits with @SteveHarris view that a form is more than just a data capture tool - it represents a workspace and a clear exposition what a user is expected to do. I'm doing a session on the ideas above at the EhrCon conference at Reading but there's a wee wiki on the thinking behnd it [here](https://freshehr.notion.site/Introduction-to-the-CGEM-Framework-115ed58514b344da825c3b42c372aff2?pvs=74) as a preview! --- ## Post #26 by @lars.lindskold More for the record:-) You can tune in at lunch today to hear more about Dipak's thoughts, visit a lunch webinar arranged by the Swedish Association of Medical Informatics, host of the OpenEHR initiative in Sweden—**Starts at 12.10** Swedish time – Welcome. https://teams.microsoft.com/l/meetup-join/19%3ameeting_NmJlOWY5MWMtMTNjNi00YjJlLTg3ZGItMDJlMjBjODk4ZDZl%40thread.v2/0?context=%7b%22Tid%22%3a%22493e298e-ea3c-42fc-bd90-b9085b431cab%22%2c%22Oid%22%3a%224a246491-2cf4-4594-9132-6fc3d04cb2c0%22%7d Read more at Linkedin: [https://www.linkedin.com/posts/lindskold_join-conversation-activity-7254845086646050816-oT0x?utm_source=share&utm_medium=member_desktop](https://www.linkedin.com/posts/lindskold_join-conversation-activity-7254845086646050816-oT0x?utm_source=share&utm_medium=member_desktop) --- **Canonical:** https://discourse.openehr.org/t/procurement-requirements-for-an-openehr-native-forms-tool/5818 **Original content:** https://discourse.openehr.org/t/procurement-requirements-for-an-openehr-native-forms-tool/5818