We have been busy developing the Gestational Diebetes Registry in collaboration with the Diabetes Projects Trust funded by the Counties Manukau DHB since the beginning of the year. I must say very busy…The prevalance of gestational diabetes, similar to Diabetes itself, is very high especially in certain ethnic groups and being able to detect and follow-up women with previous gestational diabetes or high risk population is a necessity. That’s what the Registry is all about.
So what’s a clinical registry BTW? Why do we need them? Well the for dummies (referring to the book series NOT meaning it!) kind of explanation would be (taken from my prezo from last week’s internal launch):
I am still a bit skeptical about clinical registries before getting into it to be honest. I simply thought they exist because we don’t have a decent EHR in place. Also there are purpose built maternity systems which collect most, if not all the information we capture. So why? Well it became apparent that to support public health interventions, such as recalls etc., you need to have some CRM functionality – that is a complete history of correspondence and any intervention with the participants. Obviously the information needs of registry users almost always have differences – especially when they start to evolve on their own.
OK -enough of Registry 101. This is an end-to-end openEHR implementation – what I mean by that is the UI, data bindings, business logic, query and persistence are all based on the openEHR stack – including the DEMOGRAPHIC models. We have used a framework (OceanEHR Platform) which provides APIs to create, persist and query openEHR data relatively easily. Building on the basic functionality provided we then implemented our registry specific GUI and business logic (a C# .Net MVC app).
The most fascinating part of the project to me was refining the registry dataset using the openEHRClinical Knowledge Manager and then creating the C# domain model object from the Template Designer with a touch of a button – literally. Next we imported that class to the Visual Studio project and Voila! You can actually instantiate, populate and store openEHR data with a few lines of code!!! The Nirvana – or that’s what we thought 😉
The biggest difficulty was to map openEHR based domain model to our own implementation model (ViewModel to be specific). What I mean by that is you can’t go ahead and create instance of the domain model and use it to create GUI, bindings, program logic etc. That’s a totally different beast. Typical ‘impedance mismatch’ paradigm… So the lesson for me was there’s no silver bullet (yet) to develop clinical apps but I still believe openEHR is a pretty good shot. We need more experience with frameworks and software design & development methods. Not to mention modelling – that’s another lesson learnt post. I’d like to thank to my PhD student Alex for his incredible effort in development – had a couple of 3am Skype sessions!