Odonto Data Modelling weekend
15/16/17 April 2016
Some of this is a repetition of Becky Wassall’s post above, but I started writing it before that was posted so here goes anyway!
A group of motivated and concerned dentists and others spent the weekend in a lovely cottage on the Northumberland coast ( generously provided by Prof. Jimmy Steele) to take the development of Odonto forward.
Expectation:
At the start of the weekend I hoped that we would make steps towards bringing together the work previously carried out in the various workshops and events which had taken place to understand and document the problems faced by Community Dentists in terms of the support or otherwise they received from their various systems, some of which were computer related and some of which were organisational.
Objective:
The objective of the weekend was to come up with the first cut of a data model to support the chairside / clinical aspects of Odonto.
Approach:
It was clear from the outset that we would need a set of tools to help us get from the knowledge we had available to the information being captured in a tool set which would make that knowledge useful and shareable. We chose to use OpenEHR as the tool to document the data modelling, which will, if we choose, also enable a rapid implementation of a technical solution capturing what we came up with which supports our goals of creating everything in an open, shareable and where possible standard way,
We also used a mind mapping tool to brainstorm the various domains of data we wanted to model, subsequently converting these to OpenEHR archetypes. The process of brainstorming was fascinating, involving the use of textbooks, experience and a highly iterative approach: as we worked through the various subject areas, it became clearer where, in the evolving model, various data items lived and what we meant by the terms in the context of the data model rather than a broader sense. This was familiar to me with a lot of a data modelling experience, but it was also a great lesson in understanding how developing a data model requires rigorous use of terminology. Many discussions were had which, in a nutshell, boiled down to questions like ‘When is a tooth not a tooth?’ and similar apparently straightforward issues. (As it happens we decided a tooth could be present, absent, replaced or neo-natal, but that was as the result of a number of discussions)
Another learning experience was to identify which characteristics should be inherent to the data model and which should be supported by the business logic of whatever functionality made use of the data model. Not being an expert in the subject area I couldn’t make sensible suggestions on this matter, but the e.g. discussions around whether the categorisations of the relevant values of rotation or inclination of a tooth (which are different for molars and incisors for example) should be supported at the data level or the functional layer were interesting. In the end, we elected for a tendency towards supporting these in the functional layer (which ensures that the data layer stays as flexible as possible) but I have a suspicion that this may evolve.
Outcome:
The main Outcomes of the weekend were:
A number of archetypes in OpenEHR format published on GitHub.
A number of mindmaps which were the initial starting point for the archetypes.
An excellent social weekend, which has strengthened the team behind Odonto.
Kudos to:
Becky Wassall, for being amazing and having the drive and desire to make things better for Community Dentistry patients.
Professor Jimmy Steele for providing the location.
Hannah Thorpe and Kara Scally for bringing their domain expertise.
Lucille Valentine for being able to hold all the discussions she has had in the past and bring them to bear on the work in hand.
Marcus Baw, for an extraordinary blend of medical and technical skills which allowed the translation of mindmaps to OpenEHR archetypes.
Dr Ian McNicoll for providing real time advice in the creation of OpenEHR products.
Apperta [http://apperta.org/] (http://apperta.org/)for buying us a lovely dinner on Saturday.
Take aways:
If you want to use the same technique to build an open source health care system to help patients you could do worse than to:
Build a team of supporters (who are prepared to provide time) with domain knowledge.
Secure funding for those people: it is unlikely that anything sustainable can be built on volunteers.
Understand your problem space.
Do not ‘rush to code’.
As far as possible collocate the team or at least arrange regular gatherings, ideally with a strong social element: it is important that the team feels comfortable to challenge each other and ask questions.
Use tools which aid the journey from clinician knowledge to technically implementable solutions (we have used xmind and OpenEHR).
That is as far as we have got so far, but I also think it is important to:
Avoid committing to a single technology (e.g. development company, platform provider, database etc.) unless and until you are clear that the restrictions provided by these choices will be an acceptable compromise.
Research what else is out there and what could be used without compromising fundamental goals.
Although the comments above regarding how much was done in a short time are appreciated it is important not to underestimate the work which went into getting to the point where the snowball gathered legs if that is not mixing too many metaphors.
