Friday 1 February 2013

Clinical Decision Support Modelling


As part of working on clinical decision support systems over the years a constant tension remains between approaches focused on modelled or programmatic implementation of knowledge/rules.

Of course these classifications are really a sliding scale; I can produce models from programmatic statements and I can produce executable programs from a model. As a models capability to represent concepts is enhanced and made more generic - so to the complexity of the model or the possible combinations of concepts increases. This is implicitly a trade off.

The question, as always, is whether complexity is the enemy of uptake?  Standards such as GELLO allow arbitrarily complex statements to be expressed giving great ability to implement a great number of decision support system needs. However, this often leads me cold - I invariably get to the point where I ask if I am just going to program then why can't I use Javascript, it is well accepted, in use, has tools and a I have massive number of programmers available to industry.

I also find myself getting back to the basic questions of how to access a representation of a health record in a standardised fashion for writing my rules.  VMR, CDA, openEHR or FHIR?  Which concept terminology should I use?  SNOMED, what ever is local? or invent my own reference terms (à la openCDS)?

This leads me back to the position that really we are still at the point of defining service interfaces as a priority.  Definition and agreements on interactions available and payload content within a domain of use are #1.   Specific determination of capabilities of a decision support service and the ability provide appropriate input information and receive responses in useful forms (including structured and rendered) give me enough to chew on for now... still...



No comments:

Post a Comment