Developing an openEHR based clinical registry – initial lessons…

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):

Registry

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!

Advertisements
This entry was posted in local stuff, software. Bookmark the permalink.

4 Responses to Developing an openEHR based clinical registry – initial lessons…

  1. Birger says:

    Hi Koray,

    thanks for sharing your experience. I think it would be great if this project was described more deeply. There are many projects out there that have to learn to use openEHR the hard way as those detailed descriptions are missing (especially when it comes to modelling). It would be great if you could share some of your strategies and thoughts that you have while creating archetypes and templates. I know there are people making a living by giving courses but I think free tutorials would help to spread the word about openEHR. I think the reason HL7 had so many problems to introduce v3 was the lack of openly available tutorials. The openEHR community should learn from that.

    Regards,

    Birger

    • Koray Atalag says:

      Hi Birger, thanks for your thoughtful comments.
      See I have posted more info on the Project just now – will publish soon and share here.
      In the meantime if you have further questions please contact me.

  2. Peter Jordan says:

    Hi Koray, Did you try using Entity Framework (EF) for your domain model? That’s now the leading ORM in the .NET application world and plugs nicely into APS.NET MVC. There would still be a challenge hooking into an openEHR persistence layer – as it’s not a ‘traditional’ relational DB – but EF is pretty flexible, offering code, model or DB first options. I’m also interested in the distinction between and openEHR Registry and an XDS Registry/Repository.

    • Koray Atalag says:

      Hi Peter, sorry just saw this.
      I’m not a seasoned .Net programmer so not sure about EF – probably not. We built on Ocean Informatics’ framework and followed their conventions for the View Models too. But as you very well know the ‘domain’ (as in clinical domain) model is purely openEHR based – in our case an openEHR Template serialised into operational template for validation and Template Data Object (C# class) for domain model.
      Re registry – A clinical registry is totally different from XDS; this is really a clinical information system.
      See slide 6 on http://www.slideshare.net/atalagk/development-of-gestational-diabetes-registry-using-openehr

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s