Design-by-Contract (DbC) v Test-Driven Design (TDD)

Posted on 04/03/2021 by wolandscat
A software contract in the Eiffel language

Another bit of software engineering knowledge from my archive relates to two well-known formal quality methods used in software development. This is from a presentation made at ETH Zurich in 2010.

Continue reading →
Posted in Computing | Leave a comment

Software – from Development to Use and Ownership

Posted on 03/03/2021 by wolandscat

Here’s an infographic (alright, it’s just a diagram) I created over a decade ago, randomly extracted from the archives. I think it’s almost self-explanatory.

Here’s a few more slides using this. I wouldn’t adjust too much today, but note that devops and continuous integration had not assumed the importance they have today.

Continue reading →
Posted in Computing | Tagged , | Leave a comment

Nominalism versus Ontology

Posted on 03/03/2021 by wolandscat
Lafon-Rochet 2005 … does it exist?

Nominalism is a philosophical doctrine usually understood to entail a rejection of universals, in favour of the belief that only the concrete exists. Universals are understood as instantiable entities, i.e. something like types. Another flavour of nominalism involves rejection of abstracta, such as mathematical entities, propositions, fictional entities (including possible worlds). You may read about them in the SEP’s rather dull entry on Nominalism in metaphysics.

Continue reading →
Posted in Philosophy | Tagged | 2 Comments

Aide Memoire for Computable Domain Models

Posted on 16/02/2021 by wolandscat

Sometimes a graphic is worth more than words. This is an attempt to capture all the salient features of multi-level modelling, the openEHR way. See the openEHR primer for the story.

Although this is ‘our way’ of doing it, I contend that the general scheme is universally needed – see the bullet list after the cartoons in this older post on openEHR for HL7 FHIR users.

Comments welcome.

Posted in Health Informatics, openehr | Tagged , , | Leave a comment

Clinical Decision Logic Fun

Posted on 22/10/2020 by wolandscat

How close can we get to making a clinical decision logic language look like the published guidelines which it is used to encode?

Below is an openEHR Decision Logic Module (DLM) example, in the current form of the openEHR Decision Language specification currently under development. Why another language? Well I’ll answer that with: show me a language that does this, and we’ll use it instead (e.g. why not ProForma, Arden, GLIF etc?).

Of course this language doesn’t yet solve all the problems, but we are taking two particular challenges seriously:

  • the problem of ‘subject variables’ (aka ‘curly braces’ or data access problem);
  • getting the cognitive level of the language as close as possible to the cognitive level of the source materials and authors’ thinking.

As background, our conceptual basics here.

Continue reading →
Posted in Computing, decision support, Health Informatics, openehr, standards | Tagged , , , | Leave a comment

Towards a standard analysis of computable guidelines, clinical workflow, decision support and … the curly braces problem

Posted on 24/06/2020 by wolandscat

Why don’t we have widespread clinical decision support (CDS), computable guidelines, clinical workflow (plans), and why don’t the pieces we do have talk to the health record? The first time I heard such challenges framed was around 2000, and even at that moment there were experts who had been working on modern versions of the problem for at least a decade, not to mention earlier generations of ‘classical’ AI systems such as MYCIN. So it’s not for lack of time.

After 20 years of staying out of this particular kitchen, I took the plunge in 2015, with a number of projects including Activity-Based Design at Intermountain Healthcare, a major openEHR development project called Task Planning (partly funded by Better.care in central Europe and DIPS in Norway), as well as some minor involvement in recent OMG BPM+ activities. We already had within the openEHR community the Guideline Definition Language (GDL), a fully operational decision support capability originally developed by Rong Chen at Cambio in Sweden (resources site). This provided us with a lot of useful prior experience for building a next generation combined plan/guideline facility.

Here I will talk about what I think has been conceptually missing for so long.

Continue reading →
Posted in decision support, Health Informatics, openehr, standards | Tagged , , , , , , | 8 Comments

FHIR Fixes – the choice construct part I

Posted on 09/03/2020 by wolandscat

I have posted before on the FHIR ‘choice’ construct, particularly here, where I have explained the problems of the choice construct (essentially: it’s an ad hoc constraint construct that subverts the type system, and doesn’t belong in typed formalisms; none use it, except XSD, well known as a poor formalism of little use for modelling). In this post I look into the details of the problem and some possible solutions.

Much of what I report here is connected to discussions I have participated in on the FHIR zulip site, methodology stream.

TL;DR spoiler: the main analysis here.

Continue reading →
Posted in FHIR, Health Informatics | Tagged , | Leave a comment

FHIR fixes: why a type hierarchy would help

Posted on 14/11/2019 by wolandscat

One of the principal reasons for why I and others are proposing (some) type hierarchy in the FHIR Admin resources is as follows (my earlier post on this). Working Groups (i.e. committees) building Resources are currently in the situation of defining Elements in a Resource, i.e. defining name, type, cardinality etc. The Resources are a typed system. Now, in places where Reference() is used, typing is being subverted; they are no longer stating a necessary type, they are trying to think of all possible use cases, and stating a corresponding list of types of instances in those use cases.

Continue reading →
Posted in FHIR, Health Informatics, standards | Tagged , , | 1 Comment

FHIR Fixes – the Observation.value problem

Posted on 12/09/2019 by wolandscat

As described in some detail in this earlier post on the FHIR formalism, a number of FHIR Resources contain ‘choice’ attributes of the form attribute[x], such as the one shown above in Observation. These are mapped in the FHIR UML to a ‘Type’ type, as follows.

This is not particularly helpful to developers and does not make for software that can easily treat the value field as a ‘data value’, which is the clear intention. The problem occurs because, even though there is a well defined collection of FHIR data types, there is no parent type for them to use in other contexts. This post provides a proposal for how to fix this.

Continue reading →
Posted in FHIR, Health Informatics, openehr, standards | Tagged , | Leave a comment

Fixes for FHIR – the Admin Resources

Posted on 11/09/2019 by wolandscat

In this post I revisit the issues with the FHIR Resources described in the earlier post – A FHIR experience: models or just definitions? To summarise:

  • FHIR has no semantic inheritance, only a generic structural inheritance of Resources from abstract Resources like DomainResource, Element and so on;
  • Accordingly, the following symptoms appear in the models:
    • Resources representing closely related entity types, such as Person, Patient, Practitioner, etc contain numerous separately replicated copies of common attributes rather than re-using any common definition (this is true across the board, not just for Admin Resources);
    • There are no abstract supertypes available to use at the types of other attributes, and thus no useful type subsititutability in software, other than for the generic supertypes mentioned above;
    • To compensate, FHIR uses nearly 200 ad hoc choice type definitions which do not constitute reliable semantic types (i.e. it’s unclear what the criteria for the type of a field like Observation.subject really are), or map properly to normal typed programming languages.
  • As a consequence, the FHIR Resources:
    • are brittle, in the sense that unexpected impacts are likely when changes are made to the main Resources to adjust ad hoc typing;
    • do not support classic fine-grained software re-use, due to the replication approach;
    • are likely to limit rather than improve true interoperability, as developers make local variations to models to reduce implementation difficulty.

However, there are changes that can be made that will greatly improve these characteristics, making life much easier for developers and Resource maintainers alike, and extending the life of FHIR. There would be some impact on current profiling efforts, but not a great deal, and certainly worth considering with respect to the long run, which is the next 10+ years of FHIR adoption and implementation around the world.

Some FHIR purists may take exception to the proposal below; I would urge them to consider firstly the value of standard modelling techniques properly applied, and secondly to seriously consider the challenges in maintenance, evolution, implementation and data processing of the next 10 years and just ask the simple question: can we make FHIR significantly better than it is today, reducing costs and improving interoperability for everyone?

What follows is proposed not in the expectation that it will be implemented, but as a basis for thinking about what might be possible at this stage.

(Ed. note: RelatedPerson fixed 12-09-2019 17:40 BST)

Continue reading →
Posted in FHIR, Health Informatics, standards | 4 Comments