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:
User Management: Ability to create, edit, and delete user accounts.
Data Import/Export: Capability to import and export data in various formats (e.g., CSV, Excel).
Reporting: Generation of customizable reports based on user-defined criteria.
Integration: Compatibility with other systems and software (e.g., PAS, EMR).
Security: User authentication, authorization, and data encryption.
Scalability: Ability to handle increased load and user base.
Customization: Options for customizing the user interface and workflows.
Support: Availability of customer support and service level agreements (SLAs).
Backup and Recovery: Regular data backups and recovery options in case of data loss.
Non-Functional Requirements:
Performance: Response time and system throughput.
Availability: Uptime and reliability of the service.
Scalability: Ability to handle increased load and user base.
Security: Data encryption, user authentication, and access control.
Usability: Ease of use and user experience.
Maintainability: Ease of maintaining and updating the system.
Portability: Compatibility with different devices and platforms.
Interoperability: Ability to work with other systems and software.
Disaster Recovery: Procedures for data recovery in case of system failure.
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.
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?
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.
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:
able to work with terminology service (FHIR presumably) and support given operations (as @mikael mentioned)
(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.
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.
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.
For mobile app (if any required) itâs important to consider web app (e.g. PWA) vs native app.
open vs closed source
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.
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.
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
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.
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 )
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.
.
)