Today's CIMI MTF meeting is cancelled

[Stan Huff]

Folks,

     None of the co-chairs are available for the MTF call today, so the call is cancelled.  I apologize for the short notice.  However, I have attached a first draft of “CIMI principles.”  I gleaned these principles from past CIMI minutes and presentations.  Feel free to send me additions or corrections.  Discussion and subsequent approval of these principles will be the subject of our next call.  Thanks, Stan

[William Goossen R4C]

Dear Stan, all

Thank you for taking up another task on behalf of CIMI and sending this around.

However, after 5 years of work in CIMI and the 8 years of solid work on the ISO TS 13972 [ see full reference below] I am very dissapointed with your 2 page document.

Where in 13972 parties all over the world have put in their knowledge to come up with a desirable, feasible, rich and useful set of requirements for clinical information models, it seems to me, based on your simplified list of CIMI model principles, that CIMI is back to square 1 from 2010, before the first look meetings took place.

Some key pain points are:

1.    From the worlds of openEHR, 13606, HL7, IHE and more we do know that only logics does not make sense to clinicians. The conceptual level must be addressed and the categories used for that in archetypes are core to keep clinicians convinced that the abstract logical models deal with something they care about. For that reason this archetype winning feature was taken as base for ISO TS 13972.
That is where currently most CIMI attempts fail.  Now we are in HL7, we are obliged to take work of CIC on DAM's and data sets seriously. How?

2.    You state CIMI models are logical models. But that is not true, they are computable models. They are expressed in ADL which is a computable formalism, which can hold logics to some extend and which can hold conceptual stuff. The key underpinning for my argument that CIMI is more about computable is that it was not really possible (for humans) to link a data element - node to a unique code from a standardized code system in ADL.  This has significantly improved through CIMI work, but in contrast to openEHR, CIMI is not addressing models that link to clinical concepts.  How is this going to happen?
And I do not mean the automated LOINC to CIMI model transform where a lot of the background is auto inserted, but other real models where people have to work on and agree.

If we want to make progress in this space we need conceptual, logical and computable go hand in hand. CIMI needs ISO 13972 for this. CIMI models should be 13972 instances that move a step further: to become computable. And there is where HL 7 with CDA, v3 messaging and FHIR and openEHR and 13606 club can help CIMI to make working things. (I am currently producing a full HL7 v3 CDA or message payload based on 10 DCMs in UML for a working PHR).

3.    The logical model is fine and I think here are some contributions made. However, .... it is an illusion that we can fit all clinical content into one reference model. And I have never been convinced that we need that for modeling. The fight in 13972 on this has been solved very elonquently I believe: conceptual prefered linkage to ISO 13940, system of concepts for continuity of care. Logically prefered linked to a reference model of choice (openEHR RM, HL7 RIM, HL7 FHIR, any other). And only when moving from the logic into the computable space we need to set limits to a reference model of choice and the syntax or formalism that fits with that. As you know, the ISO 13972 is architecturally based on Blobels Generic Component Model, and the x axis of this refers to the RM-ODP. It is exactly matching the steps CIMI needs to take.
When will this be part of work?

I think we should use the reference model as a tool to provide guidance on how to link the logics. But in the medical world there will always remain exceptions, so without conceptual bases, logical foundations we cannot determine the proper CIMI computable model / syntax / formalism. It is helpful to reverse engineer from applications via engineering views to computable, check the logics and underpin the concepts. That is how I have created most of the current 200 DCMs, and the core CIMI work on LOINC fits in that approach.  But it needs to be forward engineered again. I see CIMI not making any progress on this space. Even where long time ago we agreed to work on concrete models that would be helpful for solving practice issues. I just checked the list of CIMI models. And that is a wonderful resource indeed, but it covers person, provider and many lab tests. I have offered multiple times to help out with other examples.

4. In the attached set of principles I see a regression from both CIMI work back and this group not even looking at ISO TS 13972 so that billionification of efforts is facing us. And that where we finely would be able to move forward with CIMI established and the ISO TS 13972 ready for use. So maybe I fully misunderstand why we did get this draft and am I much too harsh, or we must conclude that after so many years we have nothing to offer than Stan's whish list of the starting meeting in Washington. I hope that is not true, please correct me.

5. Despite all attempts to get additonal tools ready for the task on the cimi website tool list, this has failed to so far. I think that is unfair treatment of one member over the other, because the openEHR tools are prominently listed. And this is not the first time I made a remark about that off line.

 
[ ISO  TS 13972:2015. Technical Specification. Health Informatics - Health informatics — Detailed clinical models, characteristics and processes. Geneva, International Organization for Standardization, Technical Committee 215 Health Informatics. www.iso.org]

Met vriendelijke groet / With kind regards,

dr. William T.F. Goossen
 
directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands

phone: +31654614458
e-mail: wgoo...@results4care.nl
skype: williamgoossenmobiel
kamer van koophandel 32133713
http://www.results4care.nl
http://www.results4care.eu
http://www.linkedin.com/company/711047

On 22-10-2015 19:45, Stan Huff wrote:

Folks,

     None of the co-chairs are available for the MTF call today, so the call is cancelled.  I apologize for the short notice.  However, I have attached a first draft of “CIMI principles.”  I gleaned these principles from past CIMI minutes and presentations.  Feel free to send me additions or corrections.  Discussion and subsequent approval of these principles will be the subject of our next call.  Thanks, Stan

--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.

[Thomas Beale]

On 23/10/2015 07:36, William Goossen R4C wrote:

Dear Stan, all

Thank you for taking up another task on behalf of CIMI and sending this around.

However, after 5 years of work in CIMI and the 8 years of solid work on the ISO TS 13972 [ see full reference below] I am very dissapointed with your 2 page document.

Where in 13972 parties all over the world have put in their knowledge to come up with a desirable, feasible, rich and useful set of requirements for clinical information models, it seems to me, based on your simplified list of CIMI model principles, that CIMI is back to square 1 from 2010, before the first look meetings took place.

Some key pain points are:

1.    From the worlds of openEHR, 13606, HL7, IHE and more we do know that only logics does not make sense to clinicians. The conceptual level must be addressed and the categories used for that in archetypes are core to keep clinicians convinced that the abstract logical models deal with something they care about. For that reason this archetype winning feature was taken as base for ISO TS 13972.
That is where currently most CIMI attempts fail.  Now we are in HL7, we are obliged to take work of CIC on DAM's and data sets seriously. How?

2.    You state CIMI models are logical models. But that is not true, they are computable models. They are expressed in ADL which is a computable formalism, which can hold logics to some extend and which can hold conceptual stuff. The key underpinning for my argument that CIMI is more about computable is that it was not really possible (for humans) to link a data element - node to a unique code from a standardized code system in ADL.  This has significantly improved through CIMI work, but in contrast to openEHR, CIMI is not addressing models that link to clinical concepts.  How is this going to happen?
And I do not mean the automated LOINC to CIMI model transform where a lot of the background is auto inserted, but other real models where people have to work on and agree.

I think when Stan says 'Logical models' he means models that are not tied to a specific implementation technology, not that they are not computable, as they clearly are.

If we want to make progress in this space we need conceptual, logical and computable go hand in hand. CIMI needs ISO 13972 for this. CIMI models should be 13972 instances that move a step further: to become computable.

William, I am not familiar with what a '13972 instance' is - can you elaborate?

And there is where HL 7 with CDA, v3 messaging and FHIR and openEHR and 13606 club can help CIMI to make working things. (I am currently producing a full HL7 v3 CDA or message payload based on 10 DCMs in UML for a working PHR).

3.    The logical model is fine and I think here are some contributions made. However, .... it is an illusion that we can fit all clinical content into one reference model. And I have never been convinced that we need that for modeling. The fight in 13972 on this has been solved very elonquently I believe: conceptual prefered linkage to ISO 13940, system of concepts for continuity of care. Logically prefered linked to a reference model of choice (openEHR RM, HL7 RIM, HL7 FHIR, any other). And only when moving from the logic into the computable space we need to set limits to a reference model of choice and the syntax or formalism that fits with that. As you know, the ISO 13972 is architecturally based on Blobels Generic Component Model, and the x axis of this refers to the RM-ODP. It is exactly matching the steps CIMI needs to take.
When will this be part of work?

are you suggesting adding to the CIMI reference model with 13940 concepts?  Similar discussions have occurred in the past in the 13606 group (no outcome yet).

But: 13940 UML diagrams are a conceptual model, so a RM version of this probably won't be 1:1. I think it is more likely that the 13940 concepts need to be grafted in to a proper clinical information model RM, so that it becomes 'process enabled'. This would probably imply doing somehting at the reference archetype level in CIMI. Worth thinking about.

--

Thomas Beale Chief Technology Officer +44 7792 403 613

Specification Program, openEHR Honorary Research Fellow, UCL Chartered IT Professional Fellow, BCS Health IT blog

[Gerard Freriks]

Dear Colleagues,

An interesting set of statements by William.

My take on this debate is that there are two worlds.

The world of clinicians that need to express what they want and have to express fully.

And the world of health IT that must transform the clinical statements into more technical expressions.

The former, the people, clinician, point of view is one with an awful lot of implicitness.

An implicitness that was shown to exist in the Semantic Health Net project where one line of loose items in a spreadsheet could give rise to almost two pages of inferred narrative. It was obvious that a Rules engine never can make these inferences and use them in a decisions support service.

The latter, the more technical pendant of the clinical view, has as intention to use artifacts that allow the capturing of all the otherwise implicit data, also.

And model these technical artifacts such that Rules engines generically can interpret the data in its context. These technical artifacts allow the faithful and save interpretation of data. It is, in my idea, the next level of semantic interoperability, it is Semantic Interpretability.

Because of these two different scopes, and approaches, transformations between the two kinds of artifacts are needed.

It is logical that persons, active in the clinical world, see with CIMI things that are complex and are perplexed.

Gerard

Gerard Freriks

+31 620347088

gf...@luna.nl

On Oct 23, 2015, at 8:36 AM, William Goossen R4C <wgoo...@results4care.nl> wrote:

Dear Stan, all

Thank you for taking up another task on behalf of CIMI and sending this around.

However, after 5 years of work in CIMI and the 8 years of solid work on the ISO TS 13972 [ see full reference below] I am very dissapointed with your 2 page document.

Where in 13972 parties all over the world have put in their knowledge to come up with a desirable, feasible, rich and useful set of requirements for clinical information models, it seems to me, based on your simplified list of CIMI model principles, that CIMI is back to square 1 from 2010, before the first look meetings took place.

The scope of DCM’ is to carry the consensus in the human and clinical environment what can be and should be documented about clinical concepts.

The scope of CIMI is to carry consensus in a more technical, health IT, sense what can and must be documented such that in the end Rules engines safely and faithfully can interpret the data. To that end common patterns are designed.

Some key pain points are:

1.    From the worlds of openEHR, 13606, HL7, IHE and more we do know that only logics does not make sense to clinicians.

That is why they model things such that a lot of implicit human knowledge is needed to interpret the instantiated data safely.

I accept that this is how humans work.

The conceptual level must be addressed and the categories used for that in archetypes are core to keep clinicians convinced that the abstract logical models deal with something they care about. For that reason this archetype winning feature was taken as base for ISO TS 13972.
That is where currently most CIMI attempts fail.  Now we are in HL7, we are obliged to take work of CIC on DAM's and data sets seriously. How?

One of the problems in HL7 is that several different groups modelled the same things in different ad-hoc ways.

All CIC and DAM’s are useful inputs as are many other things.

2.    You state CIMI models are logical models. But that is not true,

William do you mean that they have NO logic in them.

they are computable models.

I hope so.  But I hope that all models are computer processable.

In my opinion CIMI models make use of recurring patterns and try to model the same things in a standard way.

As opposed to models created for clinicians.

They are expressed in ADL which is a computable formalism, which can hold logics to some extend and which can hold conceptual stuff. The key underpinning for my argument that CIMI is more about computable is that it was not really possible (for humans) to link a data element - node to a unique code from a standardized code system in ADL.

William. Linking unique codes to a data element is what EN13606 makes possible and express it using ADL.

This is what I do all the time and capture meaning by means of mapping to coding systems.

Without it generic safe interpretation of data is impossible,

This is what CIMI is discussing also.

  This has significantly improved through CIMI work, but in contrast to openEHR, CIMI is not addressing models that link to clinical concepts. 

I beg you pardon!

CIMI is not active in the world of chemistry; it is active in healthcare.

And therefor deals with clinical concepts.

How is this going to happen?
And I do not mean the automated LOINC to CIMI model transform where a lot of the background is auto inserted, but other real models where people have to work on and agree.

The DCM process and other processes will produce useful expressions with consensus by clinicians.

But in order to process these artifacts safely they need a transformation to CIMI in order to be able to safely process data by Rules engines in a generic way.

Both kinds of artifacts are needed next to each other.

Will all those clinicians model the same things in the same way?

My answer will be: NO.

Will they model correctly modifiers and qualifiers? No

Will they cater for unified ways of pointing at other data?

Will they cater for unified ways to deal with the boundary problem because of pre- and post-coordinated codes?

Will they cater for the full set of contextual, epistemological data in a standardized way?

All my answers to these rhetorical questions is: No.

If we want to make progress in this space we need conceptual, logical and computable go hand in hand.

Clinicians as humans express what they need in their implicit ways. And that is fine.

But these expressions are not safely computable by Rules engines generically.

So these DCM-like artifacts need to be transposed  to CIMI artifacts.

In that sense they go hand in hand.

CIMI needs ISO 13972 for this. CIMI models should be 13972 instances that move a step further: to become computable. And there is where HL 7 with CDA, v3 messaging and FHIR and openEHR and 13606 club can help CIMI to make working things. (I am currently producing a full HL7 v3 CDA or message payload based on 10 DCMs in UML for a working PHR).

Yes.

DMR, all produced archetypes by clinicians, defined data sets, als are input for CIMI and in a technical sense create models that generically are semantically interpretable by Rules engines.

3.    The logical model is fine and I think here are some contributions made.

I’m puzzled.

In item 2 you state that it is NOT true that CIMI models are logical models.

However, .... it is an illusion that we can fit all clinical content into one reference model.

That is why the RM is very elementary and abstract.

In this way all possible meta data can be modeled. Using a second mArchetype Object Model that meta-data is expressed as constraints on that RM. This is the idea behind 13606.

The 13606 RM and AOM allow all possible meta-data to be expressed.

Do you have knowledge that shows otherwise?

And I have never been convinced that we need that for modeling.

Interoperability without solid points of reference on all aspects is impossible.

Claiming that we can interoperate safely without common shared models is wrong.

We humans can do that. We can make rather good inferences about missing data, machines can not.

When you are active in the world of humans/clinicians, what you feel makes sense, because this is how humans operate in daily life.

So in your environment you feeling might be correct.

In the world if interoperable machines that need to interpret things safely, and Rules engines are the example, we need Reference Model, reference terminologies, and standardized patterns all over the place. We need to reduce 

The fight in 13972 on this has been solved very elonquently I believe: conceptual prefered linkage to ISO 13940, system of concepts for continuity of care.

In the Clinical Information Models links to terms defined in ContSys can and will be used.

But ContSys is more. It also defines the context in which clinical statements using clinical Information Models are used. ContSys informs how things are modelled.

The Clinical Treatment Model that ContSys defines sets this contextual stage where statements play a role,

In addition ContSys is focussed on clinical processes and in addition on other processes, as well: administrative, knowledge management, etc.

This posed the question how processes are modelled.

Either as documents with entities that play a part in a process or,

as processes that are modelled and entities that play a part in them.

This choice is a choice for a modeling style.

Without refection on these two possibilities of modeling processes we can not mal Reference Archetypes, Clinical Information Models.

Logically prefered linked to a reference model of choice (openEHR RM, HL7 RIM, HL7 FHIR, any other)

Linked?

You mean expressed using a specific Reference Model such as …

And only when moving from the logic into the computable space we need to set limits to a reference model of choice

You mean to place constraints on the reference mode of choice to express the clinical content.

and the syntax or formalism that fits with that. As you know, the ISO 13972 is architecturally based on Blobels Generic Component Model, and the x axis of this refers to the RM-ODP. It is exactly matching the steps CIMI needs to take.
When will this be part of work?

In my view CIMI fits well.

CIMI defines recurring patterns that model the same things always in the same way.

One way of using SNOMED and LOINC codes.

One way to express all possible results.

One way to use unique identifiers.

One way to indicate the localization in absolute and relative time

One way to indicate how modifiers (presence, certainty, status) are modelled]

Etc. Etc.

CIMI will create patterns as examples of generic artifacts.

Generic artifacts that can be specialized as defined by for instance DCM’s.

But respecting that the scope of DCM’s is NOT the same as the scope of CIMI models.

There is an overlap but are not the same.

I think we should use the reference model as a tool to provide guidance on how to link the logics.

Reference Models are there to be constrained.

They provide NO guidance on how to create content. Let alone link to ‘logics’, what ever that means.

But in the medical world there will always remain exceptions, so without conceptual bases, logical foundations we cannot determine the proper CIMI computable model / syntax / formalism.

Each model used (13606 RM, that of CDA, that behind LOINC, or SNOMED) determine a conceptual base.

CIMI is not there to deal with all exceptions. CIMI is there to create recurring patterns we can use to create artifacts that express clinical content but in a way that secures safe and full interpretability needed for Rules engines and re-use of data.

It is helpful to reverse engineer from applications via engineering views to computable, check the logics and underpin the concepts.

The way in which existing systems deal with clinical content will NEVER create is haphazard, ad-oc, and represents at best what clinicians expect.

When I observe these efforts I see many times systems that need a to of implicit knowledge to interpret the data.

This is something that humans can do, but Rules engines never will.

That is how I have created most of the current 200 DCMs, and the core CIMI work on LOINC fits in that approach.

That is not to say that the existing systems can not inform CIMI models or the way CIMI models are specialized.

  But it needs to be forward engineered again. I see CIMI not making any progress on this space. Even where long time ago we agreed to work on concrete models that would be helpful for solving practice issues. I just checked the list of CIMI models. And that is a wonderful resource indeed, but it covers person, provider and many lab tests. I have offered multiple times to help out with other examples.

It escaped you that in order to create recurring patterns one has to analyse many existing examples.

Before we can embark on the creation of a large library of models we need to solve some unsolved problems such as:

- the boundary problem

- qualifiers and modifiers

- referring to resources, including coding systems

- recurring patterns such as those found in Lab tests.

- how to model panels of statements

- …

When these basics have been discussed and solved a generic set of patterns is there to be used to define CliniCal Models.

DCM’s will be one of the resources that provide input, no doubt.

4. In the attached set of principles I see a regression from both CIMI work back and this group not even looking at ISO TS 13972 so that billionification of efforts is facing us.

Remember that the scope of CIMI is NOT the same as that of DCM, as will be clear by now.

There for the requirements can be different.

The existing CIMI requirements have been placed on the table to be discussed because since the move to HL7 enforces CIMI to reconsider these principles/requirements.

I fail to see any regression, by the way. 

And that where we finely would be able to move forward with CIMI established and the ISO TS 13972 ready for use. So maybe I fully misunderstand why we did get this draft and am I much too harsh, or we must conclude that after so many years we have nothing to offer than Stan's whish list of the starting meeting in Washington. I hope that is not true, please correct me.

Lets discuss the principles for CIMI,

But respect that the scope of CIMI is NOT the same as for DCM’s.

5. Despite all attempts to get additonal tools ready for the task on the cimi website tool list, this has failed to so far. I think that is unfair treatment of one member over the other, because the openEHR tools are prominently listed. And this is not the first time I made a remark about that off line.

I agree.

For the moment we can discuss and decide without the need to use openEHRH tools.

With OMG CIMI works on UML tooling.

LinkEHR when provided with the CIMI Reference Model XML schema could be used.

<Proposed CIMI Principles v01.docx>

[Gerard Freriks]

CIMI is a terminological standard.

These defined COntSys concepts will be used as any other coding system.

In addition ContSys defines a Model for the diagnosis and treatment in any clinical process.

(Observation, Inference about the patient system, Assessment of processes, Planning of processes/actions, Ordering of processes and planning and funnily the execution of these processes.actions)

I agree with Thomas that CIMI and ContSys are not on the same level of the Semantic Stack.

CIMI is in between the RM and AOM and coding systems. It defines how to model concepts that are not only interoperable, but also interpretable now and in the future by Rules engines.

ContSys will inform the content of Clinical Models, and the kind of Clinical Models as one of the informing resources.

The present 13606 RM and AOM are sufficient to create artifacts that are conferment to, make use of, ContSys and any other coding system.

We do not need changes in the RM and AOM, we need to define standard patterns.

Gerard Freriks

+31 620347088

gf...@luna.nl

[Stan Huff]

William,

    I think you (mostly!) missed the point of the document entirely.  The list I sent is NOT requirements for detailed clinical models.  It is a summary of technical and policy decisions that we have previously made about how CIMI will create models.  For example:

1.      The fact that we have approved ADL 2.0 and AML as our syntactic formalism is a choice we made, not a requirement.

2.      The fact that CIMI models must use the CIMI core reference model is a decision, not a requirement.

3.      The fact that CIMI physical quantities will specify only one preferred unit of measure is a decision, not a requirement.

Whereas requirements say what should or could be, our decisions state what CIMI will do in making models. The entire list of things in my document are policy decisions, not requirements. We are reviewing and reiterating these policy decisions because we have a bolus of new participants in the MTF now that CIMI is an HL7 WG.

 

Having said that, you raise some good points that I would like to address.

 

We should review TS ISO 13972 to see if there are any requirements that CIMI needs to make policy decisions about. If you could point out specific items where CIMI needs to make a decision and has not, that would be very helpful to make sure that we haven’t missed something important.

 

I agree with Gerard’s discussion about how ContSys relates to CIMI.

 

The need for a reference model, and the expressivity thereof.  At its heart the CIMI reference model is a recursive name value pair (or a recursive entity attribute value EAV model if you prefer that style).  I would challenge you to come up with any structural data model that cannot be modeled using the CIMI reference model. It is universal in the same way as RDF triples.  It is totally generic and not specific to medicine at all.  The reason that we have a reference model is not because we can’t make models without it (we certainly could!), it is because the reference model guarantees a consistency in the models that allow algorithmic translation from one modeling language to another.  That is very important because we want to be able to convert models from ADL to AML (UML) and vice versa algorithmically.  If you make the models de novo without a reference model, you have no guarantee that you can algorithmically convert between representations.  You may be able to manually translate each model or even families of models, but without the reference model you have no guarantee of translation between formalisms.

 

I agree with Tom’s interpretation of what I meant by “logical” model.  I put the phrase in quotes the first time I used it because I meant it in a special way, not in the lay use of the term.  The sub items in that section further specify what we mean by “logical model”.  Given your input, I think I will add another bullet that says the models are computable.  Maybe that is a better term for describing what we mean rather than trying to make a special use of “logical model.”

 

You are right to criticize the fact that we don’t have content beyond LOINC derived lab models.  We have just been very methodical in discussing and examining the various modeling styles.  I think we are making progress and that we will have more content soon based on contents that already exist at openEHR, Results4Care, Intermountain, HL7 CDA templates, LEGOs from Keith Campbell and the VA, etc.  But we need to move faster.

 

Your tools should definitely be referenced on the CIMI website.  That is just an oversight on my part, and absolutely not intentional.  I apologize that this has not been fixed.  You have mentioned it before and I did not follow through.  Send me and Sarah Ryan the content that you want added and I will make sure it appears on the CIMI page.

 

Thanks for your comments.  I look forward to further discussions.  Stan

--

[Claude Nanjo]

Stan and William,

Where could one find more information on TS ISO 13972? When I tried to get information it seemed that the specification needed to be purchased.

Thank you,

Claude.

[William Goossen R4C]

Dear Claude, all,

The full published standard is available at: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62416

Every SDO has its own rules for payments. HL7 and CIMI ask for every meeting payment of participants. ISO meetings are free.
HL7 standards are free, ISO standards must be bought.
Most HL7 courses and tutorials are at a cost, some are free. ISO has many trainings free, where others come at a cost.

I cannot be responsible for these differences :-[

I have shared with CIMI many earlier versions of the TS 13972, as I have with HL7. And although some edits in Double Dutch Wililam Speak to plain English will have occurred, and renumbering to fit the ISO style, the core of characteristics and processes has not been changed since early 2014 versions.

Now CIMI is a formal HL7 workgroup, perhaps a follow up on the agreement at the start in 2007 is possible, this work was part of JIC agreement that ISO would set up the requirements document and HL7 would create a set of instances. And I think it would be OK if HL7 staff asks for a formal HL7 copy of the work.
On the other hand, all kinds of bureacracy within HL7 eventually led to only 2 of the planned 10 instances being published.

Met vriendelijke groet / With kind regards,

dr. William T.F. Goossen
 
directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands

phone: +31654614458
e-mail: wgoo...@results4care.nl
skype: williamgoossenmobiel
kamer van koophandel 32133713
http://www.results4care.nl
http://www.results4care.eu
http://www.linkedin.com/company/711047

[William Goossen R4C]

Thank you for your thoughtful reply Stan,

This clarifies a lot indeed. And I think the discussion on conceptual (Contsys), Logical (13972) and computable (CIMI) as I read from this, will indeed bring us steps further. Thanks for clarifying. I will restep in with the various topics you raise below. Perhaps the link between the above three main approaches should be clarified, in particular what each value is, and how we can move from c to l to c.
I will give it some thought and come back to you.

Met vriendelijke groet / With kind regards,

dr. William T.F. Goossen
 
directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands

phone: +31654614458
e-mail: wgoo...@results4care.nl
skype: williamgoossenmobiel
kamer van koophandel 32133713
http://www.results4care.nl
http://www.results4care.eu
http://www.linkedin.com/company/711047

[Gerard Freriks]

Colleagues,

If I may make a suggestion?

The qualifications used I do feel comfortable with (e.g. ‘conceptual’, ‘logical’, ‘computable’)

All three have aspects of: concept, logic, and are computable.

These terms are not explicit, discriminatory, enough.

conceptual => terminological

logical => clinical content specification

computable => semantic Interpretable

Gerard Freriks

+31 620347088

gf...@luna.nl

-- 

<Mail Attachment.png>

Thomas Beale Chief Technology Officer +44 7792 403 613

Specification Program, openEHR  Honorary Research Fellow, UCL  Chartered IT Professional Fellow, BCS  Health IT blog

<Mail Attachment.png>

-- 
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.

[William Goossen]

Dear Gerard,

This is too far away of accepted meanings, in particular the ISO 11179 descriptions of this.

(ISO/IEC 11179-1:2004, Information technology — Metadata registries (MDR) — Part 1: Framework)

To equal conceptual with terminological is  quite contrary to Ogden and Richards approach where real world, conceptual representation in our minds and the symbols we use are clearly identified and separated from each other.

the clinical content specification in clinical modeling refers in most publications I read about this, and also to how that is incorporated in archetypes and in 13972,  to the specification of clinical contents of the model: what is meant with the concept? For which patients?, what is the evidence base for its use? How do we get correct and valid data (method of application), how to interprete data? How is this concept linked to others.

computable is whether a computer can work with it and if it works in application a or b. Computable to me is mostly opposite of semantic interoperable.
So naming it computable moves away from our intentions.

Met vriendelijke groet / With kind regards, 
 
dr. William T.F. Goossen
 
directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands
telefoon +31654614458

[Gerard Freriks]

William,

Can you agree with me that the terms as used by you are not descriptive and discriminatory?

When you think they are, please clarify.

Gerard

Gerard Freriks

+31 620347088

gf...@luna.nl

On Oct 28, 2015, at 9:43 AM, William Goossen <wgoo...@results4care.nl> wrote:

Dear Gerard,

This is too far away of accepted meanings, in particular the ISO 11179 descriptions of this.

(ISO/IEC 11179-1:2004, Information technology — Metadata registries (MDR) — Part 1: Framework)

I checked the ISO 11179-1:2004 and found NO definitions for ‘logical’, 'conceptual’, ‘computable’.

So I do not know why you think that your argument and reference to the 11179 is a valid one.

To equal conceptual with terminological is  quite contrary to Ogden and Richards approach where real world, conceptual representation in our minds and the symbols we use are clearly identified and separated from each other.

When you refer to Ogden and Richards I agree fully what they wrote. So we can not disagree about this.

But you write: ’To equal conceptual with terminological is  quite contrary to…’.

As far as I know ‘concepts’ are defined in a Terminology. So there is a relationship.

‘Concepts’ are also used in the other items you mentioned: DCM and CIMI.

That is why your term is not discriminatory.

the clinical content specification in clinical modeling refers in most publications I read about this, and also to how that is incorporated in archetypes and in 13972,  to the specification of clinical contents of the model

: what is meant with the concept? For which patients?, what is the evidence base for its use? How do we get correct and valid data (method of application), how to interprete data? How is this concept linked to others.

You equated this clinical content specified using DCM with the term: ‘logical’.

Do you imply that those other items (ContSys and CIMI) are NOT logical?

That is why your term is not discriminatory.

What I propose as qualification (‘Clinical Content Specification’) is a correct and well defining, discriminating, one.

computable is whether a computer can work with it and if it works in application a or b. Computable to me is mostly opposite of semantic interoperable.
So naming it computable moves away from our intentions.

Computers can work with ‘zero’s' and ‘ones’.

All data in IT is expressed as a set of bits and therefor computable.

As is nonsensical data, pictures, letters, numbers, sound, etc.

Computable entails: writing, reading, changing bits and this allows removing bits.

I fear that CIMI has more aspirations than fulfilling these basic functions associated with computing.

It must be known by you that CIMI is using bits to define meta-data needed for semantic rich data structures to store retrieve and be safely operated upon using rules engines.

Many concepts are expressed in CIMI models.

What you clearly imply is that CIMI models do not deal with concepts or logics and you reduce CIMI models to sets of bits that can be processed.

What to think of the fact that ContSys (the document), DCM (the document) can be processed by a computer?

It is for these reasons that I think the terms you used are NOT discriminatory at all.

CIMI will be able to express clinical content defined by DCM’s (as one of the possible sources) but take into account that the meta-data CIMI uses allows a computer processing at a different level than bits and bytes. CIMI must support the computer processing of data at the level of modeled concepts such that Rules engines can computer process the data defined using CIMI patterns/structures in a safe and generic way.

[Claude Nanjo]

Thank you William for the clear explanation. I am not familiar with ISO but SDOs need to fund their activities so I understand.

Sent from my iPhone

--

<mime-attachment.png>

Thomas Beale Chief Technology Officer +44 7792 403 613

Specification Program, openEHR Honorary Research Fellow, UCL Chartered IT Professional Fellow, BCS Health IT blog

<mime-attachment.png>

--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce.
For more options, visit https://groups.google.com/d/optout.