The success of your QMS depends on the data architecture, so it’s important to get it right.
The data architecture – or more simply put, the structure around how data is coded, collected, stored, integrated and used within the QMS – needs to reflect your organisation’s specific operational context. For example, when coding contracts by ‘type’, the options for ‘type’ need to be relevant to the organisation. Similarly, feedback types need to reflect the types of feedback an organisation receives and wants to track.
It sounds simple enough, but it can be complex.
The challenge is to strike a balance between the data architecture supporting the usability of the QMS and the usefulness of the subsequent data analysis.
At an operational level, the data architecture needs to support individual team members to easily use the QMS. Here are some common issues to avoid:
- Long lists of options in dropdown menus can make it difficult to choose, but shortlists of options may not necessarily be the best solution.
- Illogical taxonomies make the selection confusing.
- Irrelevant options make it hard for users to relate to the QMS. Equally, if the user cannot pick the option they expect, they may disassociate with the system.
At a strategic level, the data architecture needs to support analysis for data-driven decisions. This will not be possible if:
- The options are too general – it will be difficult to draw distinctions
- There are too many options in the list – it can make nonsense of the data
- The options are ambiguous, overlap, or have gaps – it is difficult to draw conclusions
- The analysis of the data only provides the obvious – it isn’t useful
- You cannot use the data to support evidence-based decisions – it isn’t valuable
To summarise, the data architecture needs to be structured in a way that not only supports the user interface, searchability and data management but also enables an organisation to identify emerging issues, measure performance, and track risk exposure.
But, it’s also important to remember that if the system becomes static, it soon becomes irrelevant. It’s not about getting it ‘right’ from the start so that it will be ‘right’ forever. The data architecture of your QMS needs to be managed as a perpetually open-ended process, evolving as your organisation’s operational context and horizons change.
In a recent customer spotlight, Bernadette Jongbloed, Quality Manager at Kensington Private Hospital shares her advice to those who are in the early stages of building their QMS:
“The data in LogiqcQMS is just great, it’s endless what we can do with it now. From about year three, we had built our system to a point where the data trends became really valuable. During this time, we noticed that a lot of the initial architecture we had created no longer fit, like drop-down boxes. So, we made changes within the system to make it work better for us. That’s a key piece of advice for anyone considering LogiqcQMS – let the system talk to you and the data your inputting guide you rather than projecting what you think you might need down the track!”
Bernadette Jongbloed, Kensington Private Hospital
To support our clients, the data architecture of the system is initially set up based on relevant industry Standards and recognised taxonomies. For instance, the WHO Conceptual Framework for the Classification of Patient Safety forms the basis of an example 2-tier taxonomy for incident types. These options are examples only and can be modified to reflect an organisation’s specific context.
Looking for support on how to set up the data architecture of your QMS for success? Get in touch.
.svg)
