As I said it´s a matter of context.
Jussara Rötzsch
Md, MSc
Director, OpenEHR Foundation
Owner, Giant Global Graph ehealth Solutions
I agree that we need a practical solution and that we can't change (at least not overnight) what has been going on for ages.
As an intermediate solution, it would be great if it is possible to see on which facts a diagnosis is based (or a differential diagnose is rejected) and which protocol is used in order to get to that diagnosis.
As we discussed some time ago, a diagnoses (for example 'rheumatoid arthitis') isn't a 'hard' diagnosis. Differerent hospitals/ groups of doctors/ regions/ etc. use different protocols containing different criteria to come to the diagnosis RA.
So one RA diagnosis can't be directly compared to another RA diagnosis unless they're based on the same criteria.
Cheers,
Stef
Hello!
Agree to practical solutions, and to not change but support what is going on in medicine.
Is this a "general purpose" diagnosis archetype or is there any limit at least to some area?
The discussion will be much easier and to the point if there is a usecase. Diagnosis is very different in places and I do not see a simple "one fits all" archetype soon.
A "general purpose" diagnosis archetype in all bloom will not provide detailed interoperability. It will only be able to serve as search target, and readers will have to parse the content similar to free text.
The Austrian hospital discharge summaries have very few and simple fields in the diagnosis part, some basic diagnostic codes and mostly free text. This made everybody happy for discharge management.
However this will not support a group that is in the middel of developing a diagnosis.
Therefore: What is your usecase?
Greetings,
Stefan Sauermann
Program Director
Biomedical Engineering Sciences (Master)
University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
P: +43 1 333 40 77 - 988
M: +43 664 6192555
E: stefan.sauermann@technikum-wien.at
I: www.technikum-wien.at/mbe
I: www.technikum-wien.at/ibmt
I: www.healthy-interoperability.at
and panic attacks/hyper ventilation. These were my inferences about the
process inside the patient system.
> Only one was true and had to found out via trial and error diagnostics
and trial treatments. I fear that the best we can do in most circumstances
(as GP) is to code 'Reasons for ..' and do not use the word diagnosis too
often.Isn't that what we call 'differential diagnosis'?
Anyhow. I agree that these DD or reasons for should be seperated and
clearly distinctable from the 'final' diangosis, preferably based on facts and
deduction.
"final" diagnoses mainly exist with the field of pathology/the coroners
office.
Karsten
But what to do with the rest of the world that continues to use the term diagnosis meaning something else?
Gerard Freriks
+31 620347088
gfrer@luna.nl
Hello!
If you want to be interoperable to “the rest of the world”, you will have to sit together with all of them, agree on the information you want to share in which situation, on how it is packed for communication and write this up in an agreement.
Before that day, there will be no safe interoperability without human brains checking each exchange thoroughly, asking back in case of doubt.
There will only be interoperability with those who agreed beforehand.
Hope this helps, greetings from Vienna,
Stefan
Hello,
that´s what CKM and the openEHR community are for!
Regards
Exactly. At least that should be the purpose. Why else would we bother and put time in this openEHR effort.
Cheers,
Stef
Hi Stefan
You are now getting to the nub of what we are trying to do in openEHR. Actually the modelling of clinical content is a change agent itself.
Our hope is to do this on CKM or the like and not need the sitting part.
Cheers, Sam
Have ‘all’ sit together?
‘All’ never write one good novel.
‘All’ do not invent E=MC2
‘All’ do not design and fill a coding system such as SNOMED with all the codes
‘All’ will use semantic interoperability artefacts such as SNOMED
‘All’ by using it will validate and maintain the codes in for example SNOMED
‘All’ will not design the machinery behind SNOMED with which the SNOMED lemma’s are defined
‘All’ will use semantic interoperability artefacts such as Archetypes
‘All’ by using it will validate and maintain the archetypes
‘All’ will not design the machinery behind Archetypes with which the Archetypes are defined and standardised.
Those that are not-‘All’ in the standardisation world must be aware that healthcare is using fuzzy words as ‘Diagnosis’.
And that when we produce semantic interoperability artefacts we have to cater to the healthcare world that is using these fuzzy words.
But when we - in our machinery- do not define words/concepts in a rigorous way, we never get generic semantic interoperability.
Inside our machinery we had better use new words, one new one for each aspect that is associated with the inflated word ‘Diagnosis’.
It is the opinion of the EN13606 Association that the concepts as used and defined by System of Concepts for Continuity of Care (ContSys) defines these new words that we can (must) use inside our machinery.
‘All’ in the world can make archetypes to their hearts delight and use their own ‘slang’ or dialect, as long as we -inside the artefact- use the ContSys terms that are not fuzzy.
As long as each user is making artefacts for his own local domain, precise and generally shared definitions are not important.
Slowly in the standards world we start to think on how to create a wider more generic semantic interoperability instead of catering for the small closed domains, that we were/are doing until now.
In this context my words must be interpreted.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Dear Sam, all,
I am fully aware of the openEHR efforts, CKM etc. I agree that these are platforms are required !!! to get the work done.
My point is that interoperability will only work for users / systems who are represented in the discussions. Those who engage and agree on harmonised solutions will have interoperability. “The rest of the world” are not represented, they do not discuss. We cannot solve their problems for them. The “rest of the world” will therefore not have interoperability (with us) without further work.
Limiting the scope to a certain user group and a use case will make harmonisation crisp and easier. We can focus on solutions for those who are represented in the discussions and get those going. We can then prove and disseminate to “the rest of the world” that this works elegantly with little effort for a certain purpose in a certain community. Our experience in Austria is that “the rest of the world” will notice and jump on the train. The train needs to be there before anybody will jump on.
(I do admit that we do not see the complete “rest of the world” on our Austrian trains. But there is an audience and there is international cooperation with relevant groups elsewhere.)
(Online tools are fine. In my experience however harmonisation work is successful if you have at least a few face to face meetings at the start, but that is another story, does not belong here.)
Greetings from Vienna,
Dear Karsten, all,
We are at the moment running a working group that defines a "pathology report" for Austria, as a means to exchange results across organisations. We explicitly do not cover the detailed workflows that lead to the report. Tomorrow there will be a meeting on this topic in Germany as well. Austria will be represented and there will be cooperation. If this group (anybody individually) wishes to join these discussions please let me know.
We had a face to face meeting yesterday (vendors, users) and touched the topic of "final diagnosis" for patients (not from the coroners office but for contributing to treatment). The group decided that there is something like a "final diagnosis". (Detailed definition still to come).
I agree to your point that things will always change for living beings. However our group decided that it makes sense to exchange results once all reasonable considerations have been done according to good clinical practice.
We are learning a lot and I am more than happy to share and hear experiences from this group. Please accept that I believe in limiting this exchange to pathology reports and related issues in the first place. We do not have time nor resources to discuss solutions for all "the rest of the world".
Hope this helps, greetings from Vienna,
Stefan Sauermann
Program Director
Biomedical Engineering Sciences (Master)
University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
P: +43 1 333 40 77 - 988
M: +43 664 6192555
E: stefan.sauermann@technikum-wien.at
I: www.technikum-wien.at/mbe
I: www.technikum-wien.at/ibmt
I: www.healthy-interoperability.at
It takes this community to do that - and people in it to make it grow, and change it as is needed. If we see the situation like software tools, its like putting out a new tool that initially only a small community uses (think GIT in the early days). You have to get it going and show its value, and then more people will come. And then the next increment will be based on the thoughts of more users. And so on.
- thomas
Agree.
My preception is that the people in this community share a common vision of doing this on the openEHR platform, within CKM. That is fine and there is hope.
I have the feeling, that the people in this community think in many different usecases. We seem to be talking about different flavours of similar things without explicitly stating which flavour is actually meant. This makes harmonisation very hard.
Would it be reasonable to establish usecases in order to promote more focussed sub-discussions?
I am happy to engage in a “pathology report content” use case effort, should anybody wish to join.
On behalf of the national EHR effort we are running a group of users and vendors, so we get heavy, national scale engagement from very high ranking experts. I also have a contracted team here, supporting and documenting the discussion into a guideline document. I would have to check with the bosses, but I guess they might be nudged to agree that we could also capture the results of our discussion into the tools you suggest (if the effort is manageable). Austria is using CDA as transport format but that is another issue. It does not keep us from a useful technology-independent content discussion in this community.
Of course we would need help from others who are more experienced in the tools and philosophy of archetypes.
This may also generate some input into the 13606 revision that is on the move.
So: Volunteers, lets hear from you!
Greetings from Vienna, looking forward,
Stefan
Where exactly?
If you mean ISO / CEN in Vienna, I will OF COURSE be there!!
We are preparing the social program, be aware of a dinner on Monday after the conference cocktail, and a city walk / dinner combination on Tuesday.
Should anybody be around on Sunday evening, we could also have a smaller, more focused meeting.
Greetings from Vienna,
Stefan
yes. I am looking into upgrading the wiki so it is better organised, and we can create a place to describe or refer to use cases. hopefully! - thomas
Hi Stefan,
Are you aware of the NEHTA Pathology DCMs done in Australia. These should be close to going into CKM if not already, otherwise you may find in the NEHTA CKM.
Heath
Hi Stefan,
The latest NEHTA Pathology Test Result DCM can be found here: http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.839
I will be attending MIE, Semantic Health Net meetings and ISO in the next few weeks, so hope we can catch up and have a chat F2F
Regards
Heather
hello!
I am MIE as well, arriving Monday. You can find me at
Bernd Blobels’s Workshop
EHRs, Mobile Technologies and Policies on the Move to Pervasive Care, Session: T05-WS: Health and Patient Record,
Room:Master
Monday, 14h45-18h30
or call me on mobile, M: below.
I do have an ancient mobile number of yours, will try that and see if it works.
And then probably ISO / Vienna.
Greetings from there,
see you soon, looking forward