Use HL7 v3 RIM or SNOMED post-coordinated expression

Over the weekend there is a long debate within HL7 community on the approach of expressing information with HL7 RIM ActRelationship or using SNOMED CT post-coordinated expression The debate started from the following questions raised within the community, · How do you indicate an Allergic reaction as “suspect”? · How do you report that a patient “denied” an allergy? (e.g. Denies allergy to shellfish). One group of participants strongly recommended to use SNOMED CT expression; Another group of participants stated that the same information can be expressed in HL7 v3 RIM using ActRelationship, the benefit is that the implementation will be simpler and not tied to SNOMED CT. The main argument for using SCT Context Model is as following, >>>> There is a difference. SNOMED-CT has explicit DL rules so you can create unambiguous expressions about certainty, presence, absence, etc.

HL7 ActRelationships are the wild-west and people do whatever they want with them, resulting in inconsistent representations.

For something as important as representing a diagnosis, problem (including a medication allergy/intolerance) we need to give people good advice. Lets not pretend that you can accomplish the same thing with the RIM semantics that you can with SNOMED-CT.

You cannot make these assertions in an EHRS/message with the same precision and clarity using something like ICD or ICPC. Would that it was that we have a wider choice, but it is very clear that all terminologies are not created equal, and the safest, easiest to implement and most robust is SNOMED-CT.

If you can say it in a conventional SNOMED-CT expression, use it. Make sure the rest of the HL7 RIM components support/collaborate it, but optimize the use of SNOMED-CT.

>>>> The primary argument for using ActRelationship is as following >>>> Realistically there may not be much difference between sending the values in a post-coordinated expression or in RIM syntax. Psychologically there's a huge difference. And there is added complexity of being able to parse and interpret and navigate SNOMED in terms of what's allowed. I'm not aware of many jurisdictions supporting complex post-coordination. Many that do just have pre-defined post-coordinated expressions, which works ok for small value sets, not so well for others.

Anyhow, the key message here is that the RIM will let you do it either way. And it's quite possible to create models that support multiple terminology approaches. You just have to be willing to include structures that may not be used by all terminologies. When you get to the point of selecting a single terminology, then you can constrain out the structures that aren't needed for that terminology. >>>> Then out of this discussion, it all also led to the issue of SNOMED CT licensing issue whether every HL7 affiliate has SNOMED CT license, whether HL7 should still stay at terminology neutral ground etc and whether this terminology neutral positioning is still relevant or useful to promote the semantic interoperability, and which option is pragmatic and expedient, etc, etc. What I am going to describe below is a story, and then we will try to explore various options to solve their interoperability issue to determine which option is more pragmatic and expedient. 1. Bob built an application with the following screen layout, and naturally he created four data elements to store these four information as seen on the UI. 2. Tom also built a similar application but with slightly different UI design. As a result, his back-end information model only has two data elements. 3. George also built a similar application with much simpler UI design as shown below, as such he only created ONE data element to store the information. Now all of sudden, the authority asked Bob, Tom and George to exchange information, so what should do to enable the exchange of above diagnosis information assuming that terminology is standardized to use SNOMED CT (the existing application may or may not use SNOMED CT). 1) Using SNOMED CT post-coordinated expression. Using this approach, there is only ONE data element in the exchanged XML document. So when Bob's application sends out message, the application needs to compose SNOMED CT compositional grammar and set the following expression in the data element, 396275006 | Osteoarthritis: 363698007 | Finding site | =(182204005 | Entire knee joint|:272741003 | laterality|=7771000 | left |) ,246112005 | severity |=24484000 | severe | When Tom and George's applications receive the message from Bob's application, Tom needs to transform the expression accordingly and map the result to the two data elements within his information mode. Whereas George just needs to find the corresponding code to match the received SNOMED CT expression and map the result to the data element within his information mode. Note: of course Tom and George can choose to persist the received message as it is, then perform the corresponding expression transformation when it retrieves the data and renders to UI. There are few additional development required to make the above happen i) All systems either natively uses SNOMED CT (SCT) for the existing code set, or supports SCT. ii) Bob's system needs to know what are the data elements whose value needs to be composed into corresponding SCT post-coordinated expression. This requires some change to Bob's existing system. iii) Tom's system needs to parse the SCT expression, and then perform the transformation and mapping to two data elements in his information. data element#1, 396275006 | Osteoarthritis: 363698007 | Finding site | =(182204005 | Entire knee joint|:272741003 | laterality|=7771000 | left |) data element#2, 246112005 | severity |=24484000 | severe | iv) George's system needs to map the received SCT expression to the pre-coordinated code in this system, or he needs to find ways to construct human readable description as clinician sees on UI directly from the received SCT expression. In fact this also applies to Tom's case where he needs to find ways to construct human readable description from the expression if he chooses not to map the expression to the pre-coordinated code. 2) Using information model such as RIM ActRelationship. Within this approach, the common data elements defined for information exchange include four data elements - diagnosis, location, laterality and severity. So for Bob, he just specify the SCT code in the four common data elements defined, so no additional effort required for him. And when Tom receives the message, he maps the three data elements (diagnosis, location and laterality) to his local 'diagnosis' data element, and the other common data element (severity) simply pass through. As for George, he maps the four common data elements to his local single 'diagnosis' data element. For both options to work, of course effort is required to harmonize the different level of post-coordination and between post-coordination and pre-coordination whether it is performed at message receiving stage or during the data rendering stage. But the overall cost is lower for the second option, and performance is also much better in my view. Think about the relationship between information model and terminology just like the relationship between application object model and the parameters exposed for external client to pass value to the application object model. We can design the application object model to expose a String parameter to hold either simple code or expression, or we can design the object model to expose more structured parameters with each of them hold only simple code as shown in the below figure. (The parameter is to represent the code or expression, I did not model other attributes such as codeSystem, version etc to simplify the illustration) Using option#1 object model, the application needs to parse the expression in order to render the UI properly, or when it needs to find all the Osteoarthritis problem entries regardless of its location or severity for general database level query. If the application object model eventually still needs this discrete information item or even at database level for the general query, it is more efficient to specify these items in the information model to ease the implementation and make the processing more efficient. So in a nutshell even though SNOMED CT has the ability to perform all expression transformation, subsumption, equivalence testing etc, in general application still needs to have objects to hold these discrete data items instead of just single complicated string value for more efficient application business logic processing and database level general query.