Thanks a lot for your quick and elaborate answer. It was the final push I needed to read the SNOMED data entry guide you referred me to before. If I had done that earlier, I wouldn’t have had to ask this question. Sorry about that, and thanks again for your patience.
I do now understand that snomed coding of disorders/findings/procedures in this screening archetype is fine:D
No, since the information provider will vary (patient memory, his wife, EHR etc) and it’s meant as a quick data entry form, we don’t want to record it for now.
Yes, I now get that this mapping is the moment we should be careful. But since many parties (integrators, customers, consultants etc) have direct database (read) access in our software, this problem is bigger than FHIR. Since most are not experienced health informaticians. But this problem is not unique to snomed encoding.
You also convinced me on not using the ‘history of’
and thanks for explaining that the ‘history of’ only overrules the default context of occurring at present by specifing the finding occurred in the past. But not that it is now inactive, there can be no assumption of the present occurrence by computers, right?
I’m still interested in your thoughts around the grey area between openEHR and snomed.
Learning more now, I still believe the snomed default context, and the other snomed terms that add context (like history of) are better left to information models for snomed to focus on meaning of singular concepts. Because I dislike the mixture of layers of abstractions. Especially because of the problems described in snomed “Search and Data Entry Guide” 6.2.2.
Until most of the world is on shared information models (like openEHR CKM), there’s off course a lot of value for snomed to fill the void:)