Detailed Clinical Modelling for EHR Development and deployment and for HL...

Clinical (archive)
1

In a message dated 10-11-2008 0:30:48 W. Europe Standard Time, hugh.leslie@oceaninformatics.com writes:

Hi William

I think that the biggest problem I have with DCM is this bit -
"Purposes of DCM include:
1] to allow quality of clinical content to be discussed and verified by clinicians, "

Most of the formalisms that you have mentioned including UML and V3 RIM and OWL and Gello are very technical - how do you propose that these can be used by clinicians to discuss and verify clinical concepts? This doesn’t seem to be as much of an issue with openEHR archetypes as we find that they are very approachable for clinicians generally (as the NHS report into the openEHR trial found).

regards Hugh

Hugh,

that is exactly why we need DCM: no technical points, but clinical descriptions need to be veriefied. I follow the general IT in health care approach where clinicians can check and verify the results of information analysis.

DCM is 3 steps:

  1. express clinical content

  2. model in one baselline model e.g. UML

  3. transform in various formats including ADL, XML, v3

Basically there is nothing new.

But what you refer to is step 2 - 3, where I want clinicians to verify step 1.
The use of the entry page and the GUI example of archetype editor can help doing the work in step 1. You are probably not showing the ADL or XML representations to clinicians either I hope?

William

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

2

Hi William,

We have the same aim - verifying clinical descriptions without the need for any technical detail.

However, I think that a slightly different way is more efficient:

  1. Model the clinical content as ADL (by someone who knows the archetype editor)
  2. Use the Clinical Knowledge Manager (CKM) at http://www.openehr.org/knowledge to automatically process the ADL and render it in whatever format you like for clinical review…be it in HTML tables or Mindmaps. (It generates these on the fly, on the basis of the latest archetype in ADL.). The clinical review is taken care of within CKM. Each archetype will go through a couple of review rounds before being a “Published” archetype.

This has two main advantages in my view:

  • When you update the formal ADL, you automatically update the HTML, Mindmap or whatever other presentation you prefer. No issues with keeping both the clinical content and the formalism in sync.
  • The clinical content is expressed formally from the beginning. Essentially, if it is not formalised from the beginning, you need to ensure that the clinical content from DCM Step 1 is formalised correctly - essentially I believe this will require another review - where without doubt new change requests for the clinical content will arise - which then needs to be consistently updated on various levels again.

Even if there should be some details that cannot be modelled in ADL as you said in an earlier email, I think it is easier to fix that where required rather than follow a different process for that reason.
We are still fine-tuning the CKM review process, but Anneke has already done a review based on this methodology using CKM: it would be good to hear if the review process was too technical and if it helps to verify clinical descriptions. a non-technical way to verify the clinical description of a clinical concept is certainly our aim.

Having done the first few reviews in the knowledge manager (and having implemented the logic behind it), I strongly believe we would be lost if we wouldn’t start with a formalised model. The review process is far more complex than we imagined in the beginning. Without being able to automatically render the clinical content as required and being able to review on a detailed level while at the same time have the clinical content formalised, I believe that we will not move as fast as we can and create a lot of unnecessary overhead as well as synchronisation issues.
Having said that, we are currently investigating how to implement an “Archetype Nursery” - a place within CKM where you can suggest new archetypes, start some informal discussions, and maybe automatically create an initial version of an archetype from this.

Cheers
Sebastian

3

Sebastian,

Your additional comments are very helpful, and yes I agree, the content should be formalised before moving into any formalism, including ADL. That is in particular what I try to achieve. We do have now large examples in the Bridg project of CDISC and the 7 year plus experience in the Netherlands how to set that up.

We have done with HL7 approaches (with far less sofisticated support as you describe) as you said: do and redo and synchronize etc. That is not helping, but given the absence in 2001 of any valid approach we found a way that worked.

If it would indeed be possible that any requirement we have in the first step (identifying and clinical validation of content) will immediately lead to changes in the archetype editor where it then can be modelled, and we get something out of the archetype editor that can be read by an HL7 tool - even without all additional attributes - we would be able to speed things up. Anneke does find the new tool helpful as I understood.

However, we are also dealing with different formats requested from different clients moving different technical directions.

What I find especially important in our current discussions that the content for the ISO standards work on DCM becomes available step by step. And perhaps driving it this way will reveal better the additional requirements and make it feasible to include them.

Thanks for your reply.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

4

Hi William

By reading your and Sebastian’s post I feel: In contrast to the first statement in your post, you don’t agree with Sebastian on the core issue that there should be a formal expression underlying the DCMs from the start.

“the content should be formalised before moving into any formalism” → isn’t the way you put this a contradiction by itself? However, I think I know what you mean: clinical content should be discussed in the clinical community in a more informal way (narrative, excel, UML), i.e. without possible restrictions through stricter formalisms (e.g. ADL) or tools (e.g. the archetype editor).

I understand your aim for the least possible restriction, but as a medical person having worked with archetypes I felt that there are advantages of initial strictness/formality. It forces clinicians to explicitly model their idea of the concept. This makes communication between different clinicians easier, as the chances are higher that they have the same understanding. This is a major short-cut for the modelling process.

Regarding your suggesting of quick changes to the archetype editor and ADL: As long as no changes to the ADL is required, they can be done very quickly depending on resources (developers!). After all the archetype editor is open source. Changes to the formalism ADL itself will need a more formal process (change request etc) as it could have implications on many users, implementers, projects.

Regards, Thilo

I am a medical person and I think the

5

In a message dated 10-11-2008 15:08:36 W. Europe Standard Time, thilo.schuler@gmail.com writes:

Hi William

By reading your and Sebastian’s post I feel: In contrast to the first statement in your post, you don’t agree with Sebastian on the core issue that there should be a formal expression underlying the DCMs from the start.

"the content should be formalised before moving into any formalism " → isn’t the way you put this a contradiction by itself? However, I think I know what you mean: clinical content should be discussed in the clinical community in a more informal way (narrative, excel, UML), i.e. without possible restrictions through stricter formalisms (e.g. ADL) or tools (e.g. the archetype editor).

Foolish me, yes you are right. I mean formalising as a process among clinicians to come to consensus about a very strict and precise specification of data elements. And preferred also the stamp of a professional body e.g. scientific association, that this spec is going to be it for a while (sse AHQR in US, CDISC for trials, FDA for medications).

Once that is there either in word, excel, and so on (including ADL if that has been chosen as the method for the process), we can focus on step 2 translating the content into a computer operatable formalism. Thank you for helping to clarify this better.

I understand your aim for the least possible restriction, but as a medical person having worked with archetypes I felt that there are advantages of initial strictness/formality. It forces clinicians to explicitly model their idea of the concept. This makes communication between different clinicians easier, as the chances are higher that they have the same understanding. This is a major short-cut for the modelling process.

I agree, am just pointing that what I see in most projects that this step is too much initially. E.g. I work(ed) in NL with formal groups e.g. perinatology. They worked 7 year to get consensus on a very detailed data specification including definitions, relations etc. Similarly we have now a set for diabetes which took 2 years to achieve consensus about. Also I worked with stroke professionals, they where not able to come to consensus in a period of about 2 years leaving many things open. For the juvenile care records in the Netherlands, several rounds of consensus achieving approaches led again to a basis or core data set.
Such materials contain normally a set of 10 to 100 archetypes (in case of stroke even more). And, that is why I make such a point of that, these efforts have great value. Form this it is relatively easy to go to ADL, UML or HL7 v3 formalisms.
Basically, the existence of such clinical groups specifying their materials, and not always directly able to move to a formalism in your definition, is why I try to move to DCM: at least we can tap in to the efforts of clinical groups, do not force them into one formalism, but into one that each can use further. I see however that it comes closer and closer to choose one formalism at least as starting point and form there move to the other. The richness of what is out there is why I still think a intermediate step is usefull.

Regarding your suggesting of quick changes to the archetype editor and ADL: As long as no changes to the ADL is required, they can be done very quickly depending on resources (developers!). After all the archetype editor is open source. Changes to the formalism ADL itself will need a more formal process (change request etc) as it could have implications on many users, implementers, projects.

What would be the best way to come up with such requirements and where to put them? Is this list best or individuals that do the work, and one by one or a whole set once gone throuhg actual development of archetypes?

Regards, Thilo

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

7

Williamtfgoossen@cs.com wrote:

In a message dated 10-11-2008 15:08:36 W. Europe Standard Time,
thilo.schuler@gmail.com writes:

Regarding your suggesting of quick changes to the archetype editor
and ADL: As long as no changes to the ADL is required, they can be
done very quickly depending on resources (developers!). After all the
archetype editor is open source. Changes to the formalism ADL itself
will need a more formal process (change request etc) as it could have
implications on many users, implementers, projects.

What would be the best way to come up with such requirements and where
to put them? Is this list best or individuals that do the work, and
one by one or a whole set once gone throuhg actual development of
archetypes?

It may be time to establish a Problem Reporting tracker on openEHR.org
for the purpose of posting feature requests for the archetype editor(s)
(there are two).

CHanges to ADL are I think well enough managed by the 'spec' Jira
tracker already in existence; they tend to be relatively few in number
and created by a relatively small number of experts, for obvious reasons.

- thomas beale

8

Hi!

Foolish me, yes you are right. I mean formalising as a process among
clinicians to come to consensus about a very strict and precise
specification of data elements. And preferred also the stamp of a
professional body e.g. scientific association, that this spec is going to be
it for a while (sse AHQR in US, CDISC for trials, FDA for medications).

Once that is there either in word, excel, and so on (including ADL if that
has been chosen as the method for the process), we can focus on step 2
translating the content into a computer operatable formalism.

If ADL (or any other formal representation of the AOM - Archetype
Object Model) is powerful enough and is chosen for capture of clinical
needs, then I believe that what you describe as step 2 can be
automated since ADL _is_ a "computer operatable formalism". Does that
explanation make sense?

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

9

Why don’t we just do the experiment: create a ‘fictive’ clinical domain, let’s say the Ptolemeus score. In this domain we put parameters and functions that address the challenges mentioned earlier on this list. Once we have this, we provide a description of how to formalize and ask a group of clinicians to ‘formalize this domain with the various methods suggested: narrative, excel, UML and ADL. Preferably one picks 4 different groups of clinicians. Alternatively one can ask the same group to start with the narrative formalization and end with the ADL method. Within each group scores are taken how much time it takes to do the job and what the ‘perceived’ difficulties are.

Once this is ready we ask the technical people both on the HL7 and openEHR side to translate (in the order above, so the narrative description first) these descriptions into an HL7 or openEHR artifact to be able to store and retrieve data within this domain.

The ultimate test is to connect the different implementations based on different standards and exchange data and to see what shows up at the other end.
The goal of DCM is to standardize clinical data so it can be deployed in diffent health care information technologies and is re-usable over domains, purposes, standards and implementations.

This experiment will provide some answers and hopefully a clue for the solution.

Cheers,

Stef