Procurement requirements for an openEHR native forms tool

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
  1. openEHR Resource Utilization
  • Ability to use openEHR RM resources (e.g., Event-Context) for querying and updating data
  1. 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

13 Likes

Hey Jordi,

As backend dev, I have super limited experiences with procurements etc. But what does “integration with FHIR tools” mean here in detail?

Hi Jordi,

This is intresting, and very possible indeed. It would help knowing the targeted end user profile.

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.

1 Like

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.

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?

Hi Jake,

Perhaps this graphic will help explain our approach and the integrations we believe this tool should include

4 Likes

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.

1 Like

@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 Karolinska/Stockholm procurement of Digital health platform (CDR, tools, services, consultants) - #26 by 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


1 Like

I think that integrated terminology and ontology services (including ICD, SNOMED CT and other) also should be included.

1 Like

Thank you all for your comments. We are processing them and will come with a refined list :slight_smile:

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: SDC Implementations - FHIR Infrastructure - Confluence
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. 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

@jpieraj and @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 openEHR - 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 and some additional requirements on deployment, monitoring and release management. But perhaps these are outside the scope of a forms tool.

3 Likes

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.

2 Likes

For example, the SNOMED CT Maturity Framework can be of help when procuring EHR systems.
Implementation Maturity - SNOMED Implementation Support

2 Likes

Thank you, Rong, for your insightful point about forms and their scope; you always trigger my brain to start thinking :blush: .
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

6 Likes

Blimey Lars, why aren’t you speaking at the conference!?

2 Likes

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.

@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.

1 Like

Hi
As a general rule, I would like to warn against being too specific in procurement requirements. An example below:

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.

2 Likes