-
Join 1,104 other followers
Subscribe
-
Past Posts
- A Lingua Franca for e-health takes shape with GraphiteHealth
- The Health IT Platform – a definition
- What is interoperability?
- Directions in clinical guideline programming – CHA2DS2-VASc
- Design-by-Contract (DbC) v Test-Driven Design (TDD)
- Software – from Development to Use and Ownership
- Nominalism versus Ontology
Categories
- Computing (43)
- Culture (3)
- decision support (3)
- FHIR (19)
- Health Informatics (92)
- openehr (65)
- Philosophy (7)
- Politics (2)
- standards (47)
- Uncategorized (2)
Recent Comments
- wolandscat on Towards a standard analysis of computable guidelines, clinical workflow, decision support and … the curly braces problem
- Henriette Harmse on The long slow death of UML
- Joshua Bress on Towards a standard analysis of computable guidelines, clinical workflow, decision support and … the curly braces problem
- wolandscat on A Lingua Franca for e-health takes shape with GraphiteHealth
- Santosh Shevade (@santoshshevade) on A Lingua Franca for e-health takes shape with GraphiteHealth
General ICT
Health IT
Technology
Category Archives: Health Informatics
A Lingua Franca for e-health takes shape with GraphiteHealth
Colleagues in e-health often say to me: why don’t you make openEHR easier to map to <insert popular interop standard> (used to be HL7v3, then HL7 CDA, now, HL7 FHIR… DSTU2/3/4/5?). To which I usually reply: if you are implying … Continue reading
Posted in FHIR, Health Informatics, openehr, standards
Tagged archetype, CEM, graphite, openEHR
4 Comments
The Health IT Platform – a definition
Following on from various posts in the past, including my 2014 post What is an open platform?, I thought it might be time to post a succinct (as possible) definition of the platform idea, for e-health. As stated in that … Continue reading
What is interoperability?
There are some rather obscure definitions of health IT’s favourite term interoperability floating around, for example:
Directions in clinical guideline programming – CHA2DS2-VASc
The above shows a typical web form calculator for the CHA2DS2-VASc score, used for estimating the risk of stroke in patients with non-rheumatic atrial fibrillation (AF), primarily for the purpose of deciding the use of anti-coagulant therapy [Wikipedia]. How would such … Continue reading
Posted in Computing, decision support, Health Informatics, openehr, standards
Tagged cds, CIGs, CPGs, guidelines
2 Comments
Aide Memoire for Computable Domain Models
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 … Continue reading
Clinical Decision Logic Fun
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 … Continue reading
Posted in Computing, decision support, Health Informatics, openehr, standards
Tagged cds, decision support, guidelines, OMG DMN
Leave a comment
Towards a standard analysis of computable guidelines, clinical workflow, decision support and … the curly braces problem
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 … Continue reading
Posted in decision support, Health Informatics, openehr, standards
Tagged BPM+, care pathway, care plan, decision support, EHR, guidelines, openEHR
10 Comments
FHIR Fixes – the choice construct part I
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 … Continue reading
FHIR fixes: why a type hierarchy would help
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 … Continue reading
FHIR Fixes – the Observation.value problem
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 … Continue reading