Hi,
A related activity that might be useful to know is the “RFP for LOINC - SNOMED CT Cooperation Project”. http://www.ihtsdo.org/news-articles/rfp-for-loinc–snomed-ct-cooperation-project .
Regards
Mikael
Hi all,
Regarding the genericity of the openEHR IM, from the implementation point of view we have at least 3 models:
-
the implementation information model
-
the persistence information model
-
and the reference / canonic information model (the openEHR IM)
Others might have more than these 3 models on their openEHR implementations.
I think some simplifications can still be done to the openEHR IM without losing semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have a discussion about this on the wiki started some years ago).
IMO we should not try to make the reference model simpler just in sake of simplifying the implementation, since the other 2 models are for that. In my systems I have different implementation models that are over simplified openEHR IM implementations, and also very specific / optimized / generic persistence information models compatible with the openEHR IM. And I think the implementation / persistence models are the ones we can simplify and adjust to our needs, but not the reference model, since it’s role is that: be the reference for all implementations.
Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it now, there is no change necessary in the reference model to integrate the potential of SCT largely. Even you can keep on using the semantic rich entry types like Observation, etc.
See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/
If you, however, limit yourself to the Generic entry type, which even gives a better integration while keeping all OpenEhr functinality alive.
http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/
I am interested in what you think about that.
Best regards
Bert Verhees
Hi Bert,
I was thinking about integrating SCT with path-based queries (I’m not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side, so on queries there are just simple codes (specific concept ids, subsets or expressions identified just by one code). Then when evaluating a query, with the TS we can get all the terms and concept ids that match all the is_a relationships or subsets of expressions. I talked with several TS providers and hopefully we can build an integration next year to create and evaluate queries with SCT.
What I’m saying is that I prefer to delegate the complexity of SCT to the TS and create simpler queries in AQL or path-based queries, but your idea is interesting. One problem though is that query creators need to be experts in SCT.
What do you think?
I’m not a real fan of having just codes instead of expressions. Expressions are far more readable and may help in the understanding of the archetype. Just a single code representing the subset won’t be as clear.
Hi Diego,
We really need both as many real-world SNOMED-CT subsets do not align to particular hierarchies or expressions.
Ian
IMHO the clearness of the query should not depend on the AQL code, but the metadata associated with the query, like the ADL header and ontology, the AQL would be the “definition” of the query. To share queries between systems the AQL is not enough. We need a declaration of intent, purpose, use, misuse, etc and description of the query in natural language.
Also, to manage queries we need something like the CKM and an editor. Good AQL should not rely only on clearness and readability, but on specifying exactly what results we need.
I think both options are valid: SCT expressions and just codes in AQL, but since I’m not an expert in SCT, I prefer someone else that knows SCT defines the expressions and relationships in the terminology server so I can create queries just using codes.
Didn’t say otherwise, just that expressions should be preferable ;D
exactly right - ‘query libraries’ and ‘query sets’, with all that meta-description. I thought we would be closer to that today than we are to be honest. In any case, it’s key for creating proper query sets which are what we need to make CDS modules. what would you do when you want to query against a well-known ref-set that is already defined and living in a terminology server? Try to recreate the definition to put in the query? I’m not sure this is a great idea, but on the other hand you might say: how can you trust the ref set definition to always be associated with that code? Or even: how do we know the query author really understands the ref-set? I don’t think we have a proper theory on the query/terminology interface with respect to such issues… - thomas
this is also a real issue - and one that has no clear answer that I know of… - thomas
The problem I see with depending on a given terminology service is
that the code you are defining may or may not be known by the
terminology service. This could be ok for templates, but not for
archetypes. In my opinion generic archetypes should be based on known
syntaxes rather than in specific queries to terminology services
whenever is possible
Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services.
I mean, I can see that there can be valid queries to known terminology
services, I'm not against that. In practical terms however, you can't
always expect to have all the access that you want to a given external
service. e.g. I was banned from W3C once for launching a
transformation (more like 10k...) that depended on a online schema. I
can imagine that could even be worse for terminology services
(downtimes and maintenance aside).
That's why I said standard (explicit?) expression definitions should
be preferred when available
I understand the point, and it makes perfect sense talking about a general solution.
But it also depends on the scope. Consider a nationwide project where terminologies are defined and subsets / expressions can be defined in a controlled way. In this context my approach would not be a problem. Even if local codes are defined, those can be post coordinated / harmonized, and only those codes can be part of queries (I can imagine such rule in a real situation, maybe as part of a querying guideline).
Without considering context and scope, this is a thought problem to solve in a general way, but with each conversation we get closer to a solution, this is a great exercise.
Diego, I think TS accessibility is a different problem and more related to design and implementation. In a national project with a national TS the system is designed to allow those accesses as a requirement. And there are two cases: the TS to be provided by the government or the government giving the contents to the software providers to implement their TS but with the same data like SCT and mappings to ICD, GRD, etc. On both cases access is a basic requirement.
The problem you described is when access to a big public service is needed by an unknown client. The national or local TS are not public, your system needs to be registered as a client. That is at least the approach in my country Uruguay. Th email gov also provides copies of SCT to software providers after signing a contract that is free.
Hi Pablo, thanks for your reply, you definately need people with knowledge on SCT. To call it experts, possible, but it is a limited knowledge area, and if you focus on the expression and grammar part, even more limited. If someone studies on it for two weeks, full time, he/she must be able to get most of it.
And when we have an archetype-editor based on SCT, it must be more easier to use it.
Bert
Diego, I think you are right, a golden developers rule is it write readable code. The time of mnemonics is of the buggy past.
I strongly recommend looking at the way terminology services are handled in FHIR.
A ValueSet Resource (ie the subsets you're talking about) has a URI, so that it can be replicated in a local TS and referenced by it's well-known identifier rather than just a URL. It has a definition (which may be an explicit list of codes, or based on filters (ie rules) - for SNOMED CT you can use the Expression Constraint Language), and it also has an expansion - the enumeration of the codes that satisfy the definition with respect to a particular version of the underlying code system.
There are operations like $subsumes to test the relationship between two codes, and $closure to incrementally build up a subsumption graph in the client for subsets of codes (those actually in the patient records) to support efficient query. For SNOMED CT, a 'code' may be a single SCTID or a post coordinated expression.
michael
Formalization of AQL is also a good idea, but I am sure, AQL, like other query languages, will occur ad-hoc in code. It takes specialists to code and understand them, that has always been like that. But documentation is good, especially if documentation is formalized and up to date, or else, the documentation can have separate life of what it documents, this is, the code moves away from the documentation. Uncle Bob (Robert C. Martin) I listened a lot to him in the past (but he started repeating himself last years) was the one who put my attention to this problem. His answer was: Don’t document. Write code so, that it does not need documentation. See StackOverflow for more funny comments
About the experts, I remember when my kids were 4 years old (twins) in the swimmingpool (it must have been 2003 or so), I had printed out the OpenEHR documents, must have been a few hundreds pages hard the grasp text, reading under the sunny sky with sunglasses, a lot of noise of yelling kids around me. I never regretted doing that. It paid my bills for 10 years or so. I imagine someone studying SCT query techniques in a similar situation now, and having all the technical advantages, like a tablet and Wifi in the swimmingpool. One will never regret studying SCT.