If it’s just about showing related information, that the user then skims through, it’s ok not to know it’s one or the other. Both may be relevant. I’m not proposing decision logic here, only presenting information to the user.
The embed of the codes is the least of the problems!!
So how would you do it?
I don’t understand why you are capturing SNOMED CT codes then. I’m not understanding clearly!!
Given that most data is currently free text narrative data: progress notes/clinical synopsis etc. It’s a good feature to search through those. e.g. give me anything related to “urinary tract infection”. SNOMED is really useful to query on synonyms: UTI, Bacterial urinary infection etc. etc.
If words in the free text are classified by the original author using SNOMED codes that could would make the results a lot more precise instead of string matching. So you will want to record the SNOMED code with/in the text.
The search usecase I describe is a lot less specific and quicker compared to the specific AQL queries in openEHR. Where the query should be of very high sensitivity and specificity to be fit for e.g. decision support. And thus take lot’s of time and effort to get precisely right.
Maybe this screenshot from our demo app (in Dutch) will help.
In that case, why not just put some kind of markdown link in there?
I think he may have a UTI
Hhaha yes, glad you understood the Dutch.
Yes putting it in markdown can work, but it has several downsides, see my post above: Semi structured narrative data - #7 by joostholslag
This post highlights one of the challenges with moving away from fully structured/atomised text representation (the old DV_PARAGRAPH approach) to narrative-oriented representation (the DV_TEXT markdown approach).
The way to think about these two representations is that DV_PARAGRAPH is something like a post-parse AST (abstract syntax tree) representation, i.e. the kind of in-memory structured object tree that results from parsing some text into pieces.
The markdown representation is a pre-parse representation.
Narrative is nice (or at least acceptable) for authoring and reading, but bad for computing; that’s why you parse it.
Structure is great for computing, but annoying for authoring and reading.
Given that we have adopted a markdown narrative representation for lumps of text larger than a single atom - i.e. paragraphs, or ‘lines of text’ etc, we need a way to represent terminology mappings.
This could be done as links, as @ian.mcnicoll suggested below - the question is links to what? SNOMED Uris like http://snomed.info/sct/id/1234567890 can be constructed, but they won’t function like URLs, i.e. they are not really links.
Another approach would be to write them inline, to be processed by another layer, i.e. they don’t constitute markdown as such. To achieve this, some means similar to markdown linking [] has to be used to establish which words the coding applies to.
This might be something like the following:
"^dysuria^[snomedct::49650001] warranting a urinary sediment to exclude a ^UTI^[snomedct::68566005]"
If the text you want is exactly the same as the preferred term, we could do:
"[snomedct::49650001|dysuria|] warranting a ..."
But the term for 68566005 is “urinary tract infection”, not “UTI”.
The above is not super-readable, so some better choice of syntax might be possible:
"/dysuria/[snomedct::49650001] warranting a urinary sediment to exclude a /urinary traction infection/[snomedct::68566005]"
I used ‘urinary traction infection’ as the text to emphasise the fact that the delimiters (here, //) are needed to indicate the text the mapping applies to.
I’m sure someone else can do better, but what we aim to do here with this kind of solution is:
Edit: I tested the string above in the CommonMark tester page; it comes through OK.
Thank you for your elaborate response. I also like that you proposed a syntax. It makes it easier to discuss.
What I don’t like is that it’s yet another micro syntax and yet another way of dealing with mappings in openEHR. And, as stated before that it’s less feature rich than TERM_MAPPINGs. But mostly that it will require a custom parser for DV_TEXT data instead of just treating it as markdown. Besides the coding work (we’ll have to do some anyways) it gives uglyness, if e.g. you sync the text to a non-openEHR system. You’ll have to clean out the openEHR micro syntax. Or what if markdown introduces a different function for the openEHR unique syntax/
The thought that just came to mind, could we do it the other way around, instead of annotating part of the text with a mapping, could we add an attribute to the TERM_MAPPING that’s part of the DV_TEXt that records what part of the text the mapping refers to?
Welcome to the (horrible) world of markdown 
Theoretically yes. You’d have a single DV_TEXT for the sentence
“dysuria warranting a urinary sediment to exclude a UTI” with TERM_MAPPINGS carrying some sort of position data like:
mappings:
That would not be super-reliable, since people would get mixed up on whether the character positions referred to the number of characters in the output, or in the input (potentially full of other markdown text like links etc).
Another possibility might be to adopt a kind of referencing/citation approach. E.g.
“dysuria[1] warranting a urinary sediment to exclude a UTI[2]”
The numbers [1] and [2] refer to the 1st and 2nd items in the mappings list. We assume that when there is a single word to have a mapped term, we just do “word[n]”. If there are more words, then we need some delims, e.g. “dysuria[1] warranting a urinary sediment to exclude a (urinary traction infection)[2]”
We’d have to mess around to figure out which kind of brackets or other delimiters would work best, but this is at least readable, and would not even break the RM.
I’ll be honest and say right way that capturing these snomed codes like this without context, and just as context-free mappings, is probably a very bad idea!!.
But (if you insist!!), why not just use something like my simple URI type of idea, and just lob the list of SNOMED codes into mappings against he whole DV_TEXT element. I don’t think you really need character positions , the codes themselves align the correct positions. And if there are duplicate SNOMED codes - well so what!!
Yes, my first thought was something like the charpos as you described. But I agree it can get mixed up pretty easily. Maybe it could be solvable in an acceptable way by implementers, since it doesn’t have to be super reliable, for today’s usecase. But I also like the other possibility, since mappings are conceptually quite close to citations, and it reuses the TERM_MAPPINGS. I agree it’s very well readable. Would there be a way not to break the markdown syntax: not just valid, but also something that makes sense without openEHR. There is the footnote syntax ([^1] ) but it doesn’t have delimiters afai can tell. And we still have to go from footnote to TERM_MAPPING. We could put a uri in the footnote that reference the term mapping.
But how about putting an Ehr_scheme uri in the url part of the markdown link syntax?
e.g.
"[dysuria](ehr://system_id/ehr_id/top_level_structure_locator/path_inside_top_level_structure|mapping1) warranting a [urinary sediment to exclude a [urinary tract infection] (ehr://system_id/ehr_id/top_level_structure_locator/path_inside_top_level_structure|mapping2)"
Why do you think it’s a bad idea? Whole of SNOMED is without context, right? The value of the feature is clear right, would you solve it another way?
You could be right about not needing character positions. It indeed is mostly about the report as a whole that should be highlighted in a query. But you probably still would want to highlight the matching characters in the text. But that could be done by matching again when rendering the result of the query, may not be necessary to store the characters the original match relates to. But I struggle to accept that such a simple problem can not be solved well 
I’m curious for the view of others, maybe @bna has an opinion?
dysuria warranting a urinary sediment to exclude a urinary tract infection
Bad idea - it is very, very easy for the wrong SNOMED codes to be picked up - this is a good example because actually this is arguably not a diagnosis at all, but an indication for an investigation.
Or better example
[Painless haematuria](openehr_mapping://snomed.info/sct/ 197938001) but warrants a urinary sediment to exclude a urinary tract infection
In passing, I should note that I agree with this.
At an HL7 meeting years ago, I was asked by the very eminent lead of a research group that had produced a product that NLP-processed text notes and added SNOMED codes to them, each code connected to specific words in the text, to throw him an example.
I proposed: ‘patient expresses a fear of lung cancer’.
The software, hitherto having been tested on thousands of notes at Mayo clinic supposedly without error coded for ‘lung cancer’.
When it should have coded for anxiety.
I rest my case
This is a very interesting topic which we have visited many times over the last decade. Currently we are doing work on NLP capabilities for a smart editor. We call it “EHR Notes”. The EHR could be a metaphor for “air” and also the EHR. What we want to achieve is an editing capability which feels as lightweight as air, and still have the power to detect structure in the content.
The editor work in the space above openEHR data. Since the content might address any type of clinical concept it will have to be able to inject any type of archetype/template/clinical model. I.e. Patient admitted with pain in left kne. Temp. 37 C, BP: 120/80.
We’ve learned from many research programs that the training of AI robots take lots of time and resources. When finished they only cover specific domains within health and care. Lessons learned from this is that the editor must be able to support different types of robots (functions, etc.). This is why we are exploring a way to define a generic API which takes a corpus as input and a structured result as output. The output will be handled by the editor to add links in the content and also create structured content for the openEHR CDR.
As many has commented above; this is a very complex problem and the specificity of the NLP functions are not that good. This is why we think on them as assistants. They are the newly educated doctor and you should treat them as such. The output from an NLP function should be considered as a potential advice. We have to let the clinician be the one to decide if the advice is to be used.
I will publish a video showing this kind of features later.
As part of this work I implemented a very simple NLP service. The source code is here: GitHub - bjornna/ehrnotes-ask: The NLP service
The NLP engine is based on SpaCY and is trained to do NER (named entity recognition). There are multiple input sources like: SNOMED-CT for anatomy, ICNP with its axis, a medication list, etc.
Currently we are involved in research programs to work out improved NLP functions. They will be trained and developed by real NLP experts. The source code above is done by an amateur (me). Still it works reasonably well.
I finally found time to create and publish a video on our NLP based EHR Notes: https://twitter.com/bjornna/status/1456359961383026694?s=20
Hi Thomas,
As Ian remarked, the example I gave intentionally has an ambiguous SNOMEd coding. Probably 314940005 Suspected urinary tract infection (situation) would have been better. But my point is, since snomed is only terminology, not information, an archetype indeed is the smalles unit of information. So when building queries you can never draw conclusions/compute based on only the snomed code. You’ll need to check the snomed code is recorded as part of an EVALUATION.problemd_diagnosis to compute that the patient has a UTI. But you can suggest to the user a certain narrative report has ‘something do do with’ UTI. In this case it’s not a big problem that the wrong snomed code was recorded. And there still is a lot of value here, right? Or how would you solve the problem I’ve shown with the prototype screenshot?
Hi Bjørn, thanks for the great prototype on EHR Notes, this is very similar to what we have in mind. Could you please share a bit more about how you technically record the mappings from the plain text in the note, to ICNP and openEHR OBSERVATIONs?
Yes, within openEHR system environments whose software and models were written by semantically conscious people, this is all pretty reasonable.
Just be aware that when the data get sucked into some other environment, users there may make the assumption that the codes embedded in the data express the whole and true semantics of the data. If they do, incautious use of codes in our nice openEHR environment may have unintended consequences later.
This is not to say don’t do it; just that this is the kind of risk being run. It might be a low / no risk.
Aah yes, that’s a valid concern. And another reason I hate mapping to outside systems. Assumptions that make sense in one system are crazy dangerous in another. I hope we can agree that in an openEHR system mapping (a piece of) a DV_TEXT in a EVALUATION.clinical_synopsis.synopsis to a snomed clinical finding, it’s not a diagnosis. (And I would argue the same for other SNOMED uses, a terminology is not a fully computable information system, why else would we need openEHR archetypes.)
Then I’m willing to take the risk other people do something stupid.
But having said that. Could it help to add a char to TERM_MAPPING.match indicating an approximate match, for example:~? This would make the intention of the mapping even clearer in openEHR. And if we would do uri like Ian suggested by markdown url with protocol set to openehr_mapping::// there is an indication for an implementer in another system to have a look at the information in the openEHR TERM_MAPPING class and the ~ match should be a second warning not too issued too much.
No. Most parts of SNOMED CT has a context, although the context often is expressed as a default context. See for example 6.2.3. Default Context - Search and Data Entry Guide.
Btw, I think that the entire SNOMED CT Search and Data Entry Guide would be interesting for this discussion.