aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2023-02-05-semantic-dissonance.md
diff options
context:
space:
mode:
Diffstat (limited to 'content/posts/2023-02-05-semantic-dissonance.md')
-rw-r--r--content/posts/2023-02-05-semantic-dissonance.md2
1 files changed, 2 insertions, 0 deletions
diff --git a/content/posts/2023-02-05-semantic-dissonance.md b/content/posts/2023-02-05-semantic-dissonance.md
index 5ccc6aa..7333baf 100644
--- a/content/posts/2023-02-05-semantic-dissonance.md
+++ b/content/posts/2023-02-05-semantic-dissonance.md
@@ -2,6 +2,8 @@
title: "Semantic Dissonance"
date: 2023-02-05T16:38:55Z
draft: false
+params:
+ comments: true
---
A while ago I read [Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/). It was too long ago to write a review, however the phrase that I first encountered in that book and has stuck with me since is 'semantic dissonance'. In the field of software development, this means that we have two (or more!) _incompatible_ models of the same real-world situation. This happens a lot in healthcare IT. The latest and greatest standard for data exchange is [Fast Healthcare Interoperability Records](https://hl7.org/fhir/) (FHIR). Many healthcare IT suppliers are being pushed towards exposing their data over this standardised format, and they have to handle mapping from their own internal models to the standard and back again. These mappings are sometimes irreversible, i.e. mapping forward then backward again does not result in the same exact result as the input. They might also be lossy; i.e. a concept exists in one model which does not exist in the other at all, or a concept with a similar meaning but subtly different exists.