Re: Comments on "Terminologies in Information models", anyone?

[GF]

My thoughts:
- The picture is not wrong
- It needs more detail:
- Codes from codings systems are used in structures
- Ontologies are the ‘best’ coding systems, derived classifications are 
‘good’ as well
- In structures codes are used in two ways: to give meaning to nodes in 
the structure, as 
  And to give meaning to the data fields in the structure.
-Since both codes and structures can give (i) meaning to concepts 
problems can occir (the Boundary Problem)
Additional rules how to use the structure and codes used are needed: 
Rule 1: Only basic (primitive) codes from a coding systems are allowed.
e.g. Code allowed for: 'Mamma tumor' but not a code for 'Mamma tumor 
not found’
Perhaps more rules are needed.
In CIMI/HL7 there was/is and agreement to use LOINC codes to express 
the question and SNOMED to be used to provide the answer.

Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Oct 2019, at 11:29, Vebjørn Arntzen via openEHR-clinical 
>  wrote:
> 
> d. Although measures have been taken to implement international standards 
> such as the FHIR, for many years there will be a need to adhere to these 
> national information models. There is a trend towards increased international 
> standardization of information models and the use of terminologies as 
> information carriers. Important examples of frameworks that can be used in 
> Norway include Digital Imaging and Communication in Medicine (DICOM) (21), 
> Cross Enterprise Document Sharing (XDS) developed by Integrating the 
> Healthcare Enterprise (IHE), Fast Healthcare Interoperability Resources 
> (FHIR) developed by the organization Health Level Seven (HL7) and archetypes 
> developed by OpenEHR. The frameworks have different methods for terminology 
> binding, but what they have in common is that they look at the use of 
> standardized terminologies and the utilization of mutual experiences where 
> appropriate. This is a natural development of an ecosystem of information 
> exchange within health, driven by an international environment. A whole that 
> contains both coding systems, terminologies and information models is an 
> international trend. For example, IHE will use information models from HL7. 
> HL7 uses, among other things, SNOMED CT as proposed coding in its FHIR 
> information models and DICOM uses SNOMED CT directly which encodes several 
> places in its frameworks. Common to the organizations that drive the 
> development going forward is broad international participation, anchoring in 
> academia and with suppliers and / or authorities. There is an issue related 
> to the use of SNOMED CT as a bound terminology as it is licensed, and use 
> will therefore be tied to membership or require payment. SNOMED International 
> has previously allowed DICOM to use terms as part of a published standard. In 
> 2019, a larger amount of terms were released for use in the International 
> Patient Summary (discussed later). This is done to make it easier to use 
> SNOMED CT, even where there is a need for restrictive binding to terminology 
> in an information model.
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Choosing appropriate composition archetypes for recording smoking and drinking summary

[GF]

Dear Enviado,

Look at the metadata at the Composition level and you know what its purpose is.
This is the text describing the OpenEHR COMPOSITION
 A Composition is considered the unit of modification of the record, the unit 
of transmission in record extracts, and the unit of attestation by authorising 
clinicians. In this latter sense, it may be considered equivalent to a signed 
document.

Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Jun 2019, at 20:17, Jussara macedo  wrote:
> 
> I would call my contribution as a question to the bones, end to name what we 
> call skeletons in the closet or elephants in the room.
> I was attracted to openEhR in last century when attending a HL7 WGM in 2007 
> in San Diego. By that time I was so convinced that CDA would solve my 
> problems. Then I met Sam Heard and that meeting changed my whole picture.
> Since that I am a fiercely openEHR advocate.
> When talking about documents though, there are too many standards to describe 
> them, and I really hate waste of time calling differents names for the same 
> thing. Snomed ct has a hierarchy describing records artifacts, why don’t we 
> simply adopt them?
> Hope we can have a discussion on convergence and harmonization. I am all ears 
> to listen to other’s opinion
> 
> Jussara Rötzsch
> Enviado do meu iPhone
> 
> Em 5 de jun de 2019, à(s) 12:15, Dileep V S  <mailto:dil...@healthelife.in>> escreveu:
> 
>> Dear Gerard,
>> 
>> Thanks for your response. Your point of a composition being designed to 
>> record a complete encounter is worth another discussion. 
>> 
>> I personally feel that it is one way of implementing your CDR, but there 
>> could be other equally effective approaches that work better in other 
>> situations. For example in the CDR service component of our platform 
>> (EHR.Network), we have gone with generic reusable templates such as 
>> complaints, diagnosis, medication summary, medication order etc. The 
>> application can compose the complete schema for different encounter/event 
>> use cases using a combination of these generic templates. The data gathered 
>> in any event is grouped together under episodes and events using the virtual 
>> folder service.
>> 
>> This approach ensures the generic nature of the platform, while maintaining 
>> it's extensibility over time. It also helps us contain the proliferation of 
>> templates and keeps our library of commonly used stored queries to a 
>> manageable level.
>> 
>> May be there are other better approaches than either of these that are 
>> already being used by others. I feel the approach to choose will depend upon 
>> the requirements and so maintaining flexibility for the implementer will be 
>> crucial.
>> 
>> regards
>> 
>> Dileep V S
>> Founder
>> HealtheLife Ventures LLP
>> m:   +91 9632888113
>> a:   106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w:<http://ayushehr.com/>ehr.network,  <http://ehr.network/>ayushehr.com 
>> <http://ayushehr.com/>   <http://ayushehr.com/>e: dil...@healthelife.in 
>> <mailto:dil...@healthelife.in>
>> 
>> On Tue, Jun 4, 2019 at 5:04 PM GF mailto:gf...@luna.nl>> 
>> wrote:
>> Hi,
>> 
>> Afaik.
>> Composition is to document one complete encounter.
>> 
>> I use the ENTRY to start documenting the Documentation process.
>> And CLUSTERS to deal with Pannels with Clinical Statements.
>> 
>> 
>> Gerard   Freriks
>> +31 620 34 70 88
>> ‭+31 182 22 59 46‬
>>   gf...@luna.nl <mailto:gf...@luna.nl>
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 4 Jun 2019, at 06:25, Dileep V S >> <mailto:dil...@healthelife.in>> wrote:
>>> 
>>> 
>>> What would be the composition archetype recommended for a template to 
>>> record summaries such as Smoking & drinking? The best that I could think of 
>>> is the encounter composition. Do let me know if any other is better suited.
>>> 
>>> On a related note, are there any rules or best practices in choosing the 
>>> appropriate composition archetype to use for building templates? Are we 
>>> planning to have more composition archetypes such as Medication list & 
>>> problem list for use with all kinds of different templates?
>>> 
>>> regards
>> 
>> ___
>> openEHR-clinical mailing list
>> openEHR-clinical@lists.openehr.org 
>>

Re: Choosing appropriate composition archetypes for recording smoking and drinking summary

[GF]

Hi,

Afaik.
Composition is to document one complete encounter.

I use the ENTRY to start documenting the Documentation process.
And CLUSTERS to deal with Pannels with Clinical Statements.


Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 4 Jun 2019, at 06:25, Dileep V S  wrote:
> 
> 
> What would be the composition archetype recommended for a template to record 
> summaries such as Smoking & drinking? The best that I could think of is the 
> encounter composition. Do let me know if any other is better suited.
> 
> On a related note, are there any rules or best practices in choosing the 
> appropriate composition archetype to use for building templates? Are we 
> planning to have more composition archetypes such as Medication list & 
> problem list for use with all kinds of different templates?
> 
> regards

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Moving towards the use of SNOMED CT in place of local codes for better interoperability

[GF]

Dear Vebjørn,

1-AFAIK

Each documented item in the EHR is following the pattern: Question=Answer

Archetype/Template nodes define the Question.
The Data Element in the Archetype/Template defines the Answer.

Between the two organisations behind LOINC and SNOMED there is an agreement to 
use LOINC for coding the question.
And use SNOMED to code the answer.
CIMI is using this convention.

This brings me to:
Question = Answer
use LOINC = use SNOMED

2-Local code sets versus International codes.
Interoperability (interpretability) demands that in the end we all use the same 
Basic Models/standards in our Semantic stacks.
Always there will be reasons to create local codes/classifications for specific 
purposes.
Interoperability (interpretability) demands that these local 
codes/classifications need to be mapped to International models/standards.

Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 8 Mar 2019, at 09:07, Vebjørn Arntzen via openEHR-clinical 
>  wrote:
> 
> Hi, Dileep
>  
> There are nodes in archetypes where it could, and perhaps should, be 
> recommended to use terminology where possible. In many of them, there already 
> is such recommendations. For example in Problem/Diagnosis name in the 
> archetype Problem/Diagnosis:
> Identification of the problem or diagnosis, by name.
> Comment: Coding of the name of the problem or diagnosis with a terminology is 
> preferred, where possible.
>  
> And in Severity category in Symptom/Sign, the coded text are already binded 
> to SNOMED-CT:
> Mild [The intensity of the symptom or sign does not cause interference with 
> normal activity.]
> [SNOMED-CT::162468002] (Symptom mild (finding))
> Moderate [The intensity of the symptom or sign causes interference with 
> normal activity.]
> [SNOMED-CT::162469005] (Symptom moderate (finding))
> Severe [The intensity of the symptom or sign causes prevents normal activity.]
> [SNOMED-CT::162470006] (Symptom severe (finding))
>  
> If it is preferred to use a local valueset instead, or to extent the number 
> of codes, the datatype is a choice of either Coded text, or Text, to allow 
> for this. It's mentioned in the comment of that element:
> Comment: Defining values such as mild, moderate or severe in such a way that 
> is applicable to multiple symptoms or signs plus allows multiple users to 
> interpret and record them consistently is not easy. Some organisations extend 
> the value set further with inclusion of additional values such as 'Trivial' 
> and 'Very severe', and/or 'Mild-Moderate' and 'Moderate-Severe', adds to the 
> definitional difficulty and may also worsen inter-recorder reliability 
> issues. Use of 'Life-threatening' and 'Fatal' is also often considered as 
> part of this value set, although from a pure point of view it may actually 
> reflect an outcome rather than a severity. In view of the above, keeping to a 
> well-defined but smaller list is preferred and so the mild/moderate/severe 
> value set is offered, however the choice of other text allows for other value 
> sets to be included at this data element in a template. Note: more specific 
> grading of severity can be recorded using the 'Specific details' SLOT
>  
> Terminologies come and go, what's popular today may not be popular tomorrow. 
> And as for SNOMED, there is a substantional fee to be paid to use them, which 
> not all countries in the world are willing (or able) to pay. This is why 
> there are mostly recommendations to use*a terminology*, and not a specific 
> named one.
>  
> If you find elements where it should be mentioned to use terminology where 
> possible, please add a change request for that archetype.
>  
> 
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Archetype modelling pattern for Physical examination findings

[GF]

Dear colleagues,

I looked at the page url provided and have difficulty to inspect the figures 
because of a low resolution.

I agree that a more patterned way is necessary in order to have EHR systems 
that have access to more uniformly defined data needed for processing.
This requirement I call: Interpretability.

When all kinds of Observations need to be expressed in a uniform way we need 
ideally:
1- We need uniform patterns for each possible observation and all the various 
ways in which observations are expressed
2- We need to cater for ways to express the metadata of Observations that are 
part of a meaningful list
3- We need to cater for ways to express the metadata of the observation, itself
4- We need to cater for ways to express the metadata around the data subject
5- We need to cater for ways to express the metadata of the treatment process 
of the topic
6- We need to cater for ways to express the metadata of the clinical process
7- We need to cater for ways to express the metadata of the documentation 
process
8- We need to cater for ways to express the metadata of all the contextual 
information

ad1: e.g. quantitative-, semi-quantitative-, qualitative observations expressed 
using: numbers, text, codes, and many units of measurement, 
ad2: e.g. Blood pressure, Lab panels, … 
ad3: e.g. seeing, hearing, touching, smelling, tasting, …
ad4: e.g. body position, before, during or after exercise, etc.
ad5: e.g. reason for encounter, data collection/observation, history, 
examination, evaluation, planning, ordering, execution
ad6: e.g. intake, investigation, treatment, referral, 
ad7: e.g. de novo recording of a fact, re-use of previously, recorded facts, 
clinical data, administrative data, preliminary data/unprocessed data, data 
admitted to the record
ad8: e.g. localisations in time and space in absolute and relative terms

In my way of thinking I start with the documentation process in the ENTRY with 
two CLUSTERS. One for the context data and one for the Panel.  The Panel 
consists of a CLUSTER for each Panel component and one for the context of all. 
And then per Panel component two CLUSTERS: one for data and one for its context.

Gerard   Freriks
+31 620 34 70 88
‭+31 182 22 59 46‬
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 7 Mar 2019, at 05:33, Heather Leslie 
>  wrote:
> 
> Hi everyone,
>  
> The CKM editors have been gradually refining our views on how to model 
> Physical examination findings for many years now. There have been many hours 
> wasted exploring options that have had dead ends. We’d like to prevent others 
> having the same experience by sharing and publishing an agreed pattern and we 
> feel that we have one ready for broader consumption.
>  
> We clearly needed to find a solution that works from a modelling point of 
> view ensuring that the clinically diverse requirements are catered for, as 
> well as the needs of implementers for querying etc.
>  
> I have developed a page on the wiki to try to explain our proposal and 
> provide some examples - 
> https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern
>  
> <https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern>
>  
> Comments welcome, probably best if you add them to the wiki page, please.
>  
> Regards
>  
> Heather
>  
> Dr Heather Leslie
> MB BS, FRACGP, FACHI, GAICD
> M +61 418 966 670
> Skype: heatherleslie
> Twitter: @atomicainfo, @clinicalmodels & @omowizard
> www.atomicainformatics.com 
> 
>  
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org <mailto:openEHR-clinical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: ECG archetype advice required

[GF]

In human communication it many times is clear what is meant.
Of course Cardiac Output = 2 liters / minute means 2 liters of blood and not 
Oxygen.
In both cases the unit is liters of something per period of time; many times 
for instance: liters / minute or liters / day, etc.
We are always tempted to pre-/post-coordinate and make the unit Liters (blood) 
or liters (O2).

In my SIAMM way of modelling I abstain as much as possible from pre- and 
post-coorodinated codes.
The unit is generically a volume/time period specialised as liters/minute
In the archetype the context must make it clear that it is about the Cardiac 
Output of Blood.

In this way, making these choices, the Boundary problem between structure and 
coding system is avoided.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Sep 2018, at 09:48, David Moner  wrote:
> 
> I agree with Ivar. In fact, UCUM has the unit  /min  to represent frequencies 
> without a numerator unit.
> 
> El mié., 5 sept. 2018 a las 9:39, Ivar Yrke ( <mailto:i...@dips.no>>) escribió:
> 1/min, definitely!
> 
> 
> 
> Cardiac output is measured as liters/minute. Liters of what? We could have 
> used the unit liters{blood}/minute, but I have never seen that done. It is 
> considered obvious from the context. Likewise with other units. Velocity is 
> measure as meters/second, not meters{travelled}/second. One could argue that 
> meters{travelled} makes it clear that it is not meters{altitude}, but that is 
> generally considered obvious from the context.
> 
> 
> 
> For some reason there is this temptation to add a fictive unit ({beats}, 
> {count} etc.) when the number itself is unit less. This is not necessary. The 
> context is always sufficient, just like in the cases that have a unit. Let us 
> cut through the unclarity of UCUM and keep it simple and basic.
> 
> 
> 
> My argument is probably influenced by my background as a physicist. But if no 
> one has objected to 1/min in pulse/heartbeat, then I see no reason to deviate 
> from the basics in ECG or to modify pulse/heartbeat.
> 
> 
> 
> Vennlig hilsen
> 
> Ivar Yrke
> 
> Senior systemutvikler
> 
> DIPS AS
> Telefon +47 75 59 24 06
> 
> Mobil +47 90 78 89 33
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Science of Machine Learning (was Machine Learning , some thoughts)

[GF]

Data of perfect quality means, in my opinion, data and their complete context.
A diagnosis by a nurse is not the same as one by a patiente, or strting intern, 
or one MD with 20m years experience.
Just mentioning one example.



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Jun 2018, at 17:16, Philippe Ameline  wrote:
> 
> Le 27/06/2018 à 22:26, Bert Verhees a écrit :
> 
>> On 27-06-18 16:43, Philippe Ameline wrote:
>>> 1) you can find a bunch of practitioners that agree on working extra
>>> hours to comment a big bunch of images, or
>> 
>> Did I tell you about the plant-app? I believe I did. 700.000 pictures
>> are reviewed, often by volunteers.
>> 
>> The app recognizes 16000 plants. Important is how you do it, and that
>> it does not cost effort by the volunteers, for example in relation to
>> what they do anyway.
>> 
>> https://plantnet.org/ <https://plantnet.org/>
>> 
>> It is a French product.
> 
> Dear Bert,
> 
> The plant-app was the subject of your initial post.
> 
> The math in support of deep learning are being studied. To make it
> short, it remains somewhat mysterious since such classification
> algorithms "should not work", but actually, they do ;-)
> 
> From an article I just read, such NP complete algorithms are similar to
> finding a needle in a hay stack and shouldn't provide valuable
> answers... unless the conditions (large enough needle, correctly ordered
> stack) make the problem handy.
> 
> To sum it up, data quality (signal over noise ratio) is paramount. In
> the plant-app you mentioned, adding a certain level of fuzziness
> (improperly labeling images or adding images of objects that are not
> plants) could probably make the whole app plainly crappy.
> 
> Just to say that building a deep learning system starts from making
> certain that the data it will be fed with are of proper quality. This is
> usually not the case in medicine, largely because IT is considered a
> back office concept and there is seldom the kind of feedback loop that
> could lead to having errors fixed.
> 
> My point is that you can perfectly (but with considerable efforts)
> organize a trained network of practitioners to feed a "data lake" in
> order to train a neural network... but will probably be disappointed if
> you try to process existing information.
> 
> Best,
> 
> Philippe
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

Dear Evelyn,

The ideas I have are collected in a rough document called SIAMM (Semantic 
Interpretability Artefact Modelling Method)
This is known by several persons active in ISO/CEN.

At present I’m no longer actively involved in standardisation work.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 29 Jun 2018, at 01:25, Dr Evelyn Hovenga  wrote:
> 
> Gerard I suggest you prepare a concept proposal for your standards 
> organisation to submit to CEN or ISO.  My co-director of GeHCo chairs the ISO 
> WG on all data matters, have you had a look at their current worklist?  ICO 
> TC2215  or CEN TC251?  Anyone who identifies a standards gap is able to take 
> action through the relevant organisations.
> 
> Evelyn
> 
> From: openEHR-clinical  On Behalf 
> Of GF
> Sent: Friday, 29 June 2018 9:12 AM
> To: Bert Verhees 
> Cc: For openEHR clinical discussions 
> Subject: Re: Machine Learning , some thoughts
> 
> Bert,
> 
> Any one automobile or airplane or house is built using many, many standards.
> 
> The models/standards I mentioned deal with a particular aspect of data to be 
> stored, retrieved, processed and exchanged.
> Data that is generated in and by a patient in a context,
> observed by a person in a context
> Data that is documented using a structural model,
> using codings systems based on models/standards,
> etc. etc.
> 
> All are important, none is king or the centre of the world.
> 
> Gerard
> 
> Your joke deals with the situation where there are competing standards.
> In my case I mention standards that do not compete, do not overlap.
> 
> 
> 
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
> 
>> On 29 Jun 2018, at 00:15, Bert Verhees > <mailto:bert.verh...@rosa.nl>> wrote:
>> 
>> GF said: We need standards on how to describe the health data and their 
>> epistemology/context, modeling patterns and rules on how to use coding 
>> systems and deal with ‘negation’, just to mention a few other things needed 
>> to define data inside EHR systems in such a way that data can exchanged.
>> 
>> Dear Gerard, you know the joke?
>> 
>> A: We have 14 standards how to be interoperable in healthcare IT
>> B: What? I go and create a new standard which replaces all these standards.
>> A: We have 15 standards how to be interoperable in healthcare IT
>> 
>> The lesson is: We are all to small to be the center of the universe. We can 
>> all be a part of it, nothing more.
>> 
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

Bert,

Any one automobile or airplane or house is built using many, many standards.

The models/standards I mentioned deal with a particular aspect of data to be 
stored, retrieved, processed and exchanged.
Data that is generated in and by a patient in a context,
observed by a person in a context
Data that is documented using a structural model,
using codings systems based on models/standards,
etc. etc.

All are important, none is king or the centre of the world.

Gerard

Your joke deals with the situation where there are competing standards.
In my case I mention standards that do not compete, do not overlap.




Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 29 Jun 2018, at 00:15, Bert Verhees  wrote:
> 
> GF said: We need standards on how to describe the health data and their 
> epistemology/context, modeling patterns and rules on how to use coding 
> systems and deal with ‘negation’, just to mention a few other things needed 
> to define data inside EHR systems in such a way that data can exchanged.
> 
> Dear Gerard, you know the joke?
> 
> A: We have 14 standards how to be interoperable in healthcare IT
> B: What? I go and create a new standard which replaces all these standards.
> A: We have 15 standards how to be interoperable in healthcare IT
> 
> The lesson is: We are all to small to be the center of the universe. We can 
> all be a part of it, nothing more.
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 28 Jun 2018, at 16:03, Stefan Sauermann  
> wrote:
> 
> Instead, the greatest hope for effective systems will be realized when the 
> infrastructure for introducing computational tools in medicine has been put 
> in place by visionary leaders who understand the importance of networking, 
> integration, shared access to patient data bases, and the use of standards 
> for data exchange, communications, and knowledge sharing.”

We need standards on how to describe the health data and their 
epistemology/context, modeling patterns and rules on how to use coding systems 
and deal with ‘negation’, just to mention a few other things needed to define 
data inside EHR systems in such a way that data can exchanged.

> 
> The archetype community  (and many other standards groups) have them all, 
> volunteers, early adopters, and large scale implementers. Sometimes we lose 
> sight of each other, but they are all there.
> 
> Looking forward,
> greetings from Vienna,
> Stefan



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

When it necessary and defendable data can be collected and used.
Explicitly kinds of data and organisations are mentioned that can store more 
data than most others.
Healthcare and political parties are examples special catagories.
Clause 53 deals with health and care

Gerard


https://www.gdpr.associates/download-gdpr-text-23-languages/

Special categories of personal data which merit higher protection should be 
processed for health-related purposes only where necessary to achieve those 
purposes for the benefit of natural persons and society as a whole, in 
particular in the context of the management of health or social care services 
and systems, including processing by the management and central national health 
authorities of such data for the purpose of quality control, management 
information and the general national and local supervision of the health or 
social care system, and ensuring continuity of health or social care and 
cross-border healthcare or health security, monitoring and alert purposes, or 
for archiving purposes in the public interest, scientific or historical 
research purposes or statistical purposes, based on Union or Member State law 
which has to meet an objective of public interest, as well as for studies 
conducted in the public interest in the area of public health. Therefore, this 
Regulation should provide for harmonised conditions for the processing of 
special categories of personal data concerning health, in respect of specific 
needs, in particular where the processing of such data is carried out for 
certain health-related purposes by persons subject to a legal obligation of 
professional secrecy. Union or Member State law should provide for specific and 
suitable measures so as to protect the fundamental rights and the personal data 
of natural persons. Member States should be allowed to maintain or introduce 
further conditions, including limitations, with regard to the processing of 
genetic data, biometric data or data concerning health. However, this should 
not hamper the free flow of personal data within the Union when those 
conditions apply to cross-border processing of such data.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 27 Jun 2018, at 12:36, Karsten Hilbert  wrote:
> 
> On Wed, Jun 27, 2018 at 12:28:30PM +0200, Diego Boscá wrote:
> 
>> Technically it's ok if patients/citizens are aware of it (and willing to 
>> share it)
> 
> No, because the basic rule is that
> 
>   everything is forbidden
> 
> except where
> 
>   explicitely allowed
> 
>   PLUS
> 
>   it can only be allowed if *necessary* for
>   a given purpose,
> 
> which, by definition, it is not:
> 
>>>> [...] it is not possible to know which information is
>>>> relevant, and that all information is better recorded just in case
> 
> That is, at any rate, the current interpretation I am aware
> of here in Germany.
> 
> 
> Of course, this whole situation attests to the cluelessness
> of people designing GDPR.
> 
> "Just in case" is simply not possible.
> 
> But better to let this rest.
> 
> Karsten Hilbert
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

Dear Karsten,

The GDPR allows the collection of health data.
The GDPR restricts itself to person identifiable data and it secondary 
use/abuse of privacy rights.

Since health and care are about all of society, all of life, all must be able 
to be documented.
No restrictions.

So I disagree with: 'but that is currently illegal under EU GDPR.'




Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 27 Jun 2018, at 12:18, Karsten Hilbert  wrote:
> 
> On Wed, Jun 27, 2018 at 11:57:05AM +0200, Stefan Sauermann wrote:
> 
>> I agree completely that it is not possible to know which information is
>> relevant, and that all information is better recorded just in case
> 
> Not that I like the fact but that is currently illegal under EU GDPR.
> 
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

I agree fully.

This implies that on the fly small archetypes need to be used to store one or 
more aspects.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jun 2018, at 18:10, Dr Evelyn Hovenga  wrote:
> 
> Bert nurses think like you, they need to view every patient within the 
> context of the person's response to their complaint, injury, procedures 
> performed or treatments provide and the person's individual social network, 
> family commitments, lifestyle, home and workplace environments,  location 
> exposures (current and/or past) etc.  We should be able to collect and store 
> information about these aspects in lifelong EHRs.
> 
> Evelyn
> 
> -Original Message-
> From: openEHR-clinical  On Behalf 
> Of Bert Verhees
> Sent: Wednesday, 27 June 2018 12:17 AM
> To: Stefan Sauermann ; For openEHR clinical 
> discussions 
> Subject: Re: Machine Learning , some thoughts
> 
> On 26-06-18 14:35, Stefan Sauermann wrote:
>> Dear Bert, all!
>> Sorry if this consumes excess bandwith, feel free to delete.
>> 
>> The case you describe clearly provides a sound reason why "generic
>> archetypes will remain necessary".
>> I agree completely. This use case must always be satisfied.
>> It does not include automated processing at the receiving end. The
>> receiving party must read the information and decide what to do, using
>> their human brain cells, no 100% reliable computer aided decision
>> support (as in medical devices).
>> 
>> In this use case, I see no difference between:
>> - transmitting information within a "generic archetype"
>> - transmitting the same information in unstructured free text.
>> 
>> Both technologies provide a useful solution for the use case.
>> - So (in my humble view) this specific use case does not demand a
>> "generic archetype". In other words, it needs no archetype at all.
> Just a few days ago I heard about Google scanning a great number of files of 
> all kind and format, searching for medical information. The results were 
> quite remarkable.
> 
> https://www.healthdatamanagement.com/articles/google-continues-work-to-use-machines-for-health-analytics
> 
> But unstructured information is not what I am aiming for.
> 
> There will be some semantics.
> A clinician can indicate that data are from the user story, or from the 
> observation, so, that is already some information.
> While talking with the patient, the doctor can measure heartbeat, 
> bloodpressure, saturation, temperature, bloodsugar, even almost without 
> touching de patient. It will be more soon.
> Development goes so fast.
> And patients can also measure data at home, or at work, or wherever.
> Context is also location, patient personal data, time of the day, jet-lag, 
> season of the year, weather conditions, other medical conditions, alcohol 
> consumption, social status
> 
> Most of these data are not regarded as relevant in the actual medical 
> condition. So archetypes do not have items for this.
> 
> There are two kind of medical data.
> a) Medical data which are relevant in the context of a specific medical 
> condition.
> b) Medical data of which the relevancy is not yet known in the context of a 
> medical condition, or another medical condition, which maybe is also not 
> known at the moment.
> 
> The data of the second kind are also medical data, so why not store them?
> 
> Karsten yesterday said, a person at the doctor should be more then a medical 
> complaint. I agree with that. But the current medical practice is not like 
> that.
> You go to the doctor with a medical complaint, and you talk about that, the 
> doctor does research in that context, and the software finds some archetypes 
> which fit to that.
> 
> But the person should be seen as more then a medical complaint, but as a 
> complex of conditions and lifestyle.
> We need generic archetypes which can store machine generated datasets to 
> store information about the whole person, instead of only the medical 
> condition which is subject of conversation.
> 
> I believe I am the only person in this list who thinks like that. But that 
> does not matter.
> 
> Have a nice day
> Bert
> 
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

One needs patters that document the documentation process in general for 
Medical Statements, Evaluations, Orders, Actions
Patterns to Collect Complaints
Patterns to Collect Observations by tractus
Patterns to collect complaint specific  data
Patterns to collect Diagnosis specific data
Patterns to collect data for ordering of procedures (diagnostic, treatment)


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Jun 2018, at 16:51, Anastasiou A.  wrote:
> 
> Hello Bert and all
> 
>> I wonder if besides that approach an approach of archetypes growing in the 
>> wild could be of use. They could be used beside the predefined archetypes.
> 
> I don't think that enabling people to create local fragmented subsets of 
> information is a step in the right direction. We still
> need the functionality of the CKM, in the same way that you need consensus in 
> an open source project. You need to file
> issues, that are reproducible and reasonable and someone takes responsibility 
> for dealing with them and there is a cycle
> of "refreshing" the current best knowledge and so on.
> 
> I am hoping that somewhere, some junior doctors are taking up projects in 
> defining Archetypes and Templates and buddy up
> with their friends who joined Computer Science instead and they all become a 
> tribe too.
> 
> They could be working on "Archetypes & Templates for Secondary Uses of 
> Routinely Collected Data" and that could be a lab for development of new 
> things
> away from "practice".
> 
> 
> As a side comment: I think that you are also speaking from different 
> experiences. There is still some way to go in the transition to an electronic 
> HER that would
> enable all this. Maybe things are progressing faster where you are (?)
> 
> All the best
> Athanasios Anastasiou
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

It is a truth that, in the case of GP’s, almost always they deal with 
Complaints, Tentative diagnosis or estimation of the Seriousness (good/bad 
feeling), some trial Therapies and some addition investigations/tests,  plus 
finally some time to observe the evolution of the complaints over time; await 
the test results, and after a while get an idea of a possible diagnosis or a 
complaint free patient.

Rarely one consultation resulted in a distinct diagnosis.

The patient population of GP’s is very amorf. There are a lot of haystacks and 
a few needles.

In hospitals it is somewhat different. It is much more finding a diagnosis and 
treatment or proving that there some diagnosis do not apply.
Hospital patient are a highly selected group of patients.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Jun 2018, at 14:56, Anastasiou A.  wrote:
> 
> Hello Bert and all
> 
> I am a little bit "worried" with "micro-archetypes" the way you describe them.
> 
> I think that what you are probably referring to is "Disease Specific 
> Templates", which I really hope is what we are all working towards :)
> 
> So, archetypes do indeed describe one conceptual quantity, or aspect of a 
> person's healthcare and then a template describes a multidimensional "Point"
> which characterises the patient journey within the disease.
> 
> Consider for example "Total Brain Volume". You can use it to track cognitive 
> decline in AD 
> (https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(04)15441-X/abstract)
> and this gives you one "explanatory variable". But, still, there are patients 
> whose brain volume is abnormal (for their age) and they still perform well in 
> other tests, so you need more
> "data points" (a richer template) around the phenomenon to understand it 
> better.
> 
> I think that what you are describing is something like "An automated approach 
> to constructing disease specific 'Minimal Clinical Datasets'".
> 
> Once you have this minimal dataset discovered, THEN you could compose the 
> template or automatically create the archetypes.
> 
> And yes, this CAN be done today, definitely.
> 
> All the best
> Athanasios Anastasiou
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Bert Verhees 
> Sent: 25 June 2018 12:31
> To: Anastasiou A. ; For openEHR clinical 
> discussions 
> Subject: Re: Machine Learning , some thoughts
> 
> On 25-06-18 12:44, Anastasiou A. wrote:
>> The time scales for doing this would be enormous. We can probably work
>> out a lower limit by looking at the lifecycle of archetypes in the current 
>> CKM.
> 
> Thanks, for your answer, I agree with you and others, and already wrote that, 
> that an EHR will not be good enough for machine learning.
> 
> I was too optimistic and to much impressed by some results of machine 
> learning. It will do very good things in healthcare, but only on very 
> specific cases.
> 
> But while writing this
> 
> What would be good, however, an improvement. I suggested to my wife (a GP), 
> and she agreed (partly)
> 
> Classic EHR software only has few datapoints on a screen, and many 
> particularities come into free text, and if the GP is really motivated, maybe 
> he finds some ICPC code.
> 
> Archetypes do not really change this practice. A GP is a busy person.
> 
> What could help is modularity. A GP should be able to add datapoints to his 
> screen. For example, beside all the normal things, the GP sees that there are 
> red eyes, but how can he make this available to the system in a way that it 
> can be found back?
> 
> What about micro-archetypes which describe only one datapoint? And the GP 
> should be able to invoke them by voice. He says "red eyes" and magic happens, 
> there is a datapoint on the screen which offers a possibility to click on a 
> checkbox. Eventually a choice, A bit red, medium red, very red.
> 
> This kind of software does not have to be something for the far future, but 
> can be available already now.
> 
> Also thanks to machine learning, a limited form of NLP (natural language 
> expression (machine learning helping with NLP) can be used, and that was my 
> idea of generating archetypes, last Saturday. A computer could, in some cases 
> of simple datapoints, also even generate micro-archetypes for them, and with 
> templates or container-archetypes, generate evaluation-archetypes
> 
> Maybe, when it is so easy to create datapoints, and store them, maybe then 
> machine learning in diagnostic can come closer, also in some cases for a GP, 
> or machine learning can do suggestion: lo

Re: Machine Learning , some thoughts

[GF]

Largely I agree with Bert.
Medicine is an art for 80% and science for 20%

What medical data is recorded in most cases by GP’s is so scanty that AI is not 
possible.
Collecting data over long periods of time might help.

Most IT-systems can not store all the epistemology that is needed for AI, at 
present.
Most of that needed additional info can be obtained on the fly by IT-systems to 
be designed,
Most of the context information (dates, times, locations, persons involved, 
relationships), are  available but never stored,

Analysis of images, sounds, that might become feasible.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Jun 2018, at 12:52, Bert Verhees  wrote:
> 
> On 25-06-18 12:40, GF wrote:
>> Providing health and care is part science and for a large part an art.
>> Meaning that humans are needed.
>> 
>> Artificial Intelligence is a nice scientific hyped topic and nothing more.
>> 
>> That is not to say that AI might play a role and can be of use.
>> It needs to be properly designed, engineered and not hacked together.
>> It is certain that AI applications in healthcare must be treated as Medical 
>> Devices.
>> 
>> For it function properly we need to be able to document healthcare topics 
>> including the full context/epistemology.
> I agree, especially on GP-level, I checked with my wife, she is GP, as you 
> (Gerard) know. I asked her if the context/epistemology in a EHR is sufficient 
> for machine-learning. It is not, she sufficient, and that will never be. GP's 
> have other things to do then carefully record all datapoints that describe a 
> disease.
> Even when using archetyped-systems this does not change.
> 
> Allthough, there are some patient-conditions which are very typical for a 
> disease, mostly this is not the case.
> For example, many infection-diseases have fever as a symptom, and one person 
> gets pain in his back, and the other has headache as a result of fever and 
> other inconveniences coming with infection disease.
> 
> So, the GP cannot do much with machine learning, the best source of knowledge 
> is his experience, and if he cannot solve with that, he should ask someone 
> else, or send the patient to the hospital to a specialist.
> 
> But there, machine learning can do things in some specialties.
> 
> Anyway, thanks for your reply
> Bert



signature.asc
Description: Message signed with OpenPGP
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Machine Learning , some thoughts

[GF]

Providing health and care is part science and for a large part an art.
Meaning that humans are needed.

Artificial Intelligence is a nice scientific hyped topic and nothing more.

That is not to say that AI might play a role and can be of use.
It needs to be properly designed, engineered and not hacked together.
It is certain that AI applications in healthcare must be treated as Medical 
Devices.

For it function properly we need to be able to document healthcare topics 
including the full context/epistemology.
Present OpenEHR/13606 and terminology developments form a good foundation.
But are not sufficient.
What is lacking are well researched and designed shared patterns that capture 
the full context, epistemology.
CIMI is trying to do that.
CIMI, part of HL7, is possibly diverging and getting under the influence of 
practical thinking as it is  adjusting ist gols to encompass FHIR.

GF


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Jun 2018, at 12:21, Stefan Sauermann  
> wrote:
> 
> 82% of correct recognition rate is a desaster in healthcare.
> 74% is even worse.
> 
> My evidence based feeling is that we still will need to sort it out manually 
> for some years to come.
> 
> Hope this helps,
> Stefan
> 
> Stefan Sauermann
> 
> Program Director
> Biomedical Engineering Sciences (Master) ->
> Medical Engineering & eHealth (Master) in September 2018!
> 
> University of Applied Sciences Technikum Wien
> Hoechstaedtplatz 6, 1200 Vienna, Austria
> P: +43 1 333 40 77 - 988
> M: +43 664 6192555
> E: stefan.sauerm...@technikum-wien.at
> I: www.technikum-wien.at/mme
> I: www.technikum-wien.at/bhse
> I: healthy-interoperability.at
> fb: www.facebook.com/uastwMME
> portfolio: https://mahara-mr.technikum-wien.at/user/sauermann
> 
> Am 23.06.2018 um 18:11 schrieb Bert Verhees:
>> Today my wife showed me Plantnet.
>> 
>> https://plantnet.org/en/
>> 
>> It recognizes over 6000 plants from showing a flower or a leaf to your 
>> phone. It has learned from machine-learning 700.000 pictures, and its 
>> knowledge every day grows stronger, because it keeps on learning. And not 
>> only the looks of a flower, but if it takes location (biotope) and date in 
>> consideration, the certainty of recognizing gets stronger.
>> 
>> Now you can imagine that it must be hard to recognize a plant from a 
>> picture, without seeing the dimensions and showed in many possible angles, 
>> in sunlight, cloudy or twilight.
>> 
>> I was impressed how good it already was. Very advanced computer-knowledge 
>> for free in the hands of the millions.
>> 
>> There is also an app, I did not try it, which recognizes birds from audio. 
>> You walk somewhere, hear a bird and want to know what kind of bird that is.
>> 
>> The Berlin Natural History Museum leads a contest of 29 teams using 23 
>> different methods, with more than 82% good identifications for isolated bird 
>> recordings, and more than 74% correct identifications for recordings mixing 
>> several bird songs.
>> 
>> 
>> I often notice there is a trend in thinking that Machine Learning cannot be 
>> much help, see how miserable google-translate translates. But then we for 
>> get to see how much progress is made in other areas.
>> 
>> Why am I writing this? Just to let you think about it.
>> 
>> I wonder, Is OpenEhr usable for recognizing pattern in diseases over Machine 
>> Learning, isn't behind every diagnosis a small cloud of archetypes which 
>> forms a pattern? The features of recognizing/learning should not be found in 
>> archetypes ID's, although, that can help a lot, but it should also look to 
>> datatypes, their semantics and relations.
>> 
>> Isn't OpenEhr better for recognizing pattern then whichever classic storage 
>> structure, because the data-structures in OpenEhr are in semantic models, 
>> this instead of some weird Codd-structure, which only has technical reasons 
>> to exist.
>> 
>> (Classic data stored in classic SQL schema's could be brought over to 
>> archetyped structures, to make the base of machine-learning larger.)
>> 
>> I think, when this is developed, we should be able to get to at least two 
>> advantages.
>> 
>> 1) We don't need CKM anymore, computers can understand archetypes, we don't 
>> need to restrict ourselves to a limited number. We can also use archetypes 
>> we do not know, and maybe we never know. Even, we wouldn't need archetypes 
>> anymore, just as reminder/instruction. But the computer could create the 
>> ar

Re: What to call this concept?

[GF]

Dear all,

I agree with Philippe.
The world is complex.
A very generic question can be answered from various points of view.

The WHO ICF classification might be the resource to rely on.
The attached picture is an overview of the most relevant points of view.

Before the question is asked ‘what do you do’ one needs to provide the context.
Be it: on human body function, human activity or Participation as social 
activity with others.

http://www.who.int/classifications/icf/icfbeginnersguide.pdf

Gerard Freriks




Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 22 Jun 2018, at 09:57, Philippe Ameline  wrote:
> 
> Great answer,
> 
> I also liked Bert's "Only the first man was reflecting the truth because, 
> laying bricks, you do alone, the rest you do together with others"
> 
> To sum it up (my own way):
> 
> When asking someone what he does (in life or even for a living), the answer - 
> from people doing the very same thing - can range from very mundane to fully 
> inspirational.
> In health, all answers are plainly valid, and it would be a terrible mistake 
> to only take into account the technical description. We are all, on this 
> list, working to save lives, to have suffering people heal, to open the way 
> for a better world... and we are also all spending most of our time typing on 
> a computer keyboard (be it code or projects sheet, etc). It is true that 
> typing allows us to benefit from several years of life when compared to those 
> who are pneumatic drilling outside... but it doesn't define who we are.
> Bert reminds us that the most important part is always done with others... 
> meaning that "what do you do?" could be better expressed as "what is your 
> social network?".
> It may remain a little bit theoretical or philosophical, but the 
> "individuation" concept states that, to become a better self, one should find 
> her best place as a service provider to her network (hence opposed to 
> "individualism"... and also opposed to finding a comfortable slot in a 
> hierarchy).
> 
> This to say that a human being is a complex biological entity part of a 
> complex social network and that taking care of her can never be achieved in a 
> reductionist way. So, "what do you do?", "what is your social network?" and 
> "who are you?" are three very connected questions.
> I stop there... my virtual foreman reminds me that I don't make a living from 
> posting on this list ;-)
> 
> Best,
> 
> Philippe
> 
> Le 21/06/2018 à 19:24, Pablo Pazos a écrit :
>> And the foreman came along and said "I'm an atheist and you work for me, 
>> stop talking and do your job".
>> 
>> On Thu, Jun 21, 2018 at 11:46 AM, Philippe Ameline > <mailto:philippe.amel...@free.fr>> wrote:
>> Le 15/06/2018 à 08:41, Bakke, Silje Ljosland a écrit :
>>> 
>>> A typical question that would lead to this concept could be “What do you 
>>> do?”.
>>> 
>>> 
>> 
>> A man came upon a construction site where four people were working.
>> He asked the first, “What are you doing?” and the man replied: “I am laying 
>> bricks.”
>> He asked the second, “What are you doing?” and the man replied: “I am 
>> building a wall.”
>> As he approached the third, he heard him humming a tune as he worked, and 
>> asked, “What are you doing?” The man smiled, “I am building a cathedral!”
>> The forth was very concentrated, nearly ecstatic, and when asked “What are 
>> you doing?”, looked up at the sky, and answered, “I am working for the sake 
>> of God!”
>> 
>> ___
>> openEHR-clinical mailing list
>> openEHR-clinical@lists.openehr.org 
>> <mailto:openEHR-clinical@lists.openehr.org>
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 
>> <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
>> 
>> 
>> 
>> 
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
>> +598 99 043 145
>> skype: cabolabs
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>> <https://cabolabs.com/>
>> http://www.cabolabs.com <http://www.cabolabs.com/>
>> https://cloudehrserver.com <https://cloudehrserver.com/>
>> 
>> 
>> 
>> ___
>> openEHR-clinical mailing list
>> openEHR-clinical@lists.openehr.org 
>> <mailto:openEHR-clinical@lists.openehr.org>
>> ht

Re: What to call this concept?

[GF]

Hi,

You are doing the impossible.

The only correct and natural answer to the question is: ‘living’.

Humankind and its culture encompasses broad and very detailed activities.
It is ALL we do, or don't do, in this World
From work to cleaning ones nose, talking with the neighbour,  or doing nothing 
but being bored.

In order to answer this question one needs to scope the context, the reason why 
one wants to know and record it.
Questions that need to be answered first:
Why do you ask the question?
And for what purpose will you use the answer?

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 15 Jun 2018, at 08:41, Bakke, Silje Ljosland 
>  wrote:
> 
> Hi everyone,
>  
> We’ve been struggling for a while to define and delineate a concept about the 
> activities an individual does during their day – do they do paid work, unpaid 
> work, are they a student, are they unemployed and seeking work, unemployed 
> and not seeking work, retired, carer, are they a young child or infant, or 
> something else? There may be multiple, like both studying and working.
>  
> A lot of feedback has been that we should constrain this to just employment, 
> ie paid work. That would make the definition simple, but that’s not the 
> concept we’re trying to define. We’ve been thinking about things like role in 
> life, socio-economic or psychosocial activity situation, or activity in daily 
> life. The first is rather vague, the second isn’t really a common expression, 
> and the third feels too close to “ADL”, which is normally thought of 
> functional assessments like whether you can take care of your own hygiene and 
> nutrition.
>  
> A typical question that would lead to this concept could be “What do you do?”.
>  
> We’d really appreciate any ideas for what words or phrases we should use to 
> name and describe this concept!
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
> 
> Tel. +47 40203298
> Web: http://arketyper.no <http://arketyper.no/> / Twitter: @arketyper_no 
> <https://twitter.com/arketyper_no>
>  
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org <mailto:openEHR-clinical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

[GF]

The scope of LOINC is NOT the same as the scope of SNOMED.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 12 Mar 2018, at 08:39, Mikael Nyström <mikael.nyst...@liu.se> wrote:
> 
> Hi,
>  
> I do that too. It seems like more and more people are moving away from the 
> position that SNOMED CT is complex and expensive to a position that SNOMED CT 
> is manageable and an affordable way of getting rid of local terminologies and 
> add value.
>  
>  Regards
>  Mikael
>  
>  
> Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> <mailto:openehr-technical-boun...@lists.openehr.org>] För Pablo Pazos
> Skickat: den 12 mars 2018 08:28
> Till: For openEHR clinical discussions <openehr-clinical@lists.openehr.org>
> Kopia: Openehr-Technical <openehr-techni...@lists.openehr.org>
> Ämne: Re: Terminology bindings ... again
>  
> Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
> clinical terminology towards SNOMED CT.
>  
> On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström <mikael.nyst...@liu.se 
> <mailto:mikael.nyst...@liu.se>> wrote:
> Hi,
>  
> Yes, it is correct that expressions include single code binding. Those kinds 
> of bindings are just the simplest variants of expressions. :-)
>  
> I think that in a few years’ time nearly all implementations of SNOMED CT not 
> only implement the international version, but also one are a few 
> international, national or local extensions, so this use case is probably the 
> normal use case and not the exceptional use case.
>  
>  Regards
>  Mikael
>  (Among other things SNOMED CT Implementation 
> Advisor)
>  
> Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org 
> <mailto:openehr-clinical-boun...@lists.openehr.org>] För Pablo Pazos
> Skickat: den 12 mars 2018 01:39
> Till: For openEHR clinical discussions <openehr-clinical@lists.openehr.org 
> <mailto:openehr-clinical@lists.openehr.org>>
> Kopia: Openehr-Technical <openehr-techni...@lists.openehr.org 
> <mailto:openehr-techni...@lists.openehr.org>>
> Ämne: Re: Terminology bindings ... again
>  
> Now that I have more experience with SNOMED expressions, I like the idea of 
> doing the binding with an expression, also I think an expression includes the 
> single code binding, if that is correct there is no need of defining a 
> different notation for single code binding, just use a simple expression 
> formed by one specific concept code. Also the expression being something 
> processable and very versatile, we can express complex concepts with a few 
> codes, which will help on adding knowledge to the archetype and serve to a 
> better and simpler CDS.
> 
> About the metadata, there should be expressed against which SNOMED release 
> this expression was created. We can't be sure only with min version. I should 
> be responsibility of the user to check if the expression works on a different 
> version/release of SNOMED. Another metadata is if the version is a local 
> extension, some countries have their own extensions.
> 
> I don't know if we need to support other terminologies (technically) and if 
> doing that is useful (strategically). Terminology services can do SNOMED to 
> ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
> SNOMED-LOINC collaboration, so we might expect an official mapping in the 
> future (https://loinc.org/collaboration/snomed-international/ 
> <https://loinc.org/collaboration/snomed-international/>). IMO we should focus 
> on SNOMED.
>  
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>> wrote:
> Recently we discussed terminology bindings. We probably still have not got 
> them right, but we don't have a model of what we think they should be. I 
> posted a quick idea of a possible more structured version:
> 
> term_bindings = <
> ["snomed_ct"] = <
> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
> (SIMPLE_BINDING) <
>  target = <http://snomedct.info/id/169895004 
> <http://snomedct.info/id/169895004>> -- Apgar score at 1 minute
>  notes = <"some notes">
>  min_version = <"2017-02-01">
>  etc = <"etc">
>   >
> ["id26"] = (CONSTRAINT_BINDING) <
>target = <"71388002 |Procedure| : 40

Re: Terminology bindings ... again

[GF]

CIMI made the decision to use LOINC for the ‘question' part of the statement.
And SNOMED for the ‘answer’ part.
Leading to: Question = Answer, or something coded in LOINC is something coded 
in SNOMED.
Nodes in an archetype coded in LOINC and data coded in SNOMED.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 12 Mar 2018, at 01:38, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Now that I have more experience with SNOMED expressions, I like the idea of 
> doing the binding with an expression, also I think an expression includes the 
> single code binding, if that is correct there is no need of defining a 
> different notation for single code binding, just use a simple expression 
> formed by one specific concept code. Also the expression being something 
> processable and very versatile, we can express complex concepts with a few 
> codes, which will help on adding knowledge to the archetype and serve to a 
> better and simpler CDS.
> 
> About the metadata, there should be expressed against which SNOMED release 
> this expression was created. We can't be sure only with min version. I should 
> be responsibility of the user to check if the expression works on a different 
> version/release of SNOMED. Another metadata is if the version is a local 
> extension, some countries have their own extensions.
> 
> I don't know if we need to support other terminologies (technically) and if 
> doing that is useful (strategically). Terminology services can do SNOMED to 
> ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
> SNOMED-LOINC collaboration, so we might expect an official mapping in the 
> future (https://loinc.org/collaboration/snomed-international/ 
> <https://loinc.org/collaboration/snomed-international/>). IMO we should focus 
> on SNOMED.

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Setting thresholds

[GF]

There are different kinds of ranges:
- normal with reference to a specific population,  for children, males, whites, 
etc
- signalling with reference to the specific subject of care
- signalling with reference to the specific healthcare provider
- signalling with reference to a specific context
- etc.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Mar 2018, at 22:47, Sam Heard <sam.he...@oceaninformatics.com> wrote:
> 
> HI All
> Goals and targets are an example of ranges as data. The INR treatment range 
> is a very common data set that the clinician populates as it is dependent on 
> the history and other considerations.
> Cheers, Sam
>   <>
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Setting thresholds

[GF]

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 28 Feb 2018, at 14:42, Seref Arikan <serefari...@kurumsalteknoloji.com> 
> wrote:
> 
> Hi Tom, 
> 
> The original question is talking about 'threshold's changing in time. Would 
> not using reference ranges may make things complicated during implementation 
> with the changing threshold requirement? 

Not when the complete context/epistemology- and thus the actual range-  is 
stored next to the data value.
What is the complexity?



> 
> First: if the threshold is changing with respect to all instances of a 
> particular composition (template_id = 'x') , when the change happens, would 
> not you have to update reference ranges of the DV_QUANTITY node in all 
> composition instances across all EHRs to express the new threshold? That is, 
> if you define high systolic blood pressure using a reference value, would not 
> you have to update all blood pressure observations when the accepted 'high' 
> value (threshold) changes? 
> 
> Second: Setting the reference value to express a threshold would make it 
> impossible to query above/below threshold sets of composition via AQL because 
> it'd require a query that uses the WHERE clause as follows:
> " WHERE some/path/node1.value > /some/path/node1.reference_range.value" 
> (excuse the mock paths) which, as far as I know is not supported by AQL at 
> the moment, not even grammar-wise (I may be out of date on this one) 
> 
> If you keep the reference value at the application level, all you have to do 
> is update it without having to touch the existing instances and use AQL to 
> select above/below threshold since you can plug the threshold value directly 
> into WHER

Leaving epistemological information in the application is. creating problems 
because ranges change overtime and are true in one geo- and temporal context 
only.

> 
> You'd have to 
> 

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Archetype Modeling Methodology

[GF]

David,

Thanks for the White paper.
I think I agree.

What is the latest news from Spain?

GF

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Feb 2018, at 10:49, David Moner <dam...@gmail.com> wrote:
> 
> Dear community,
> 
> We have just published a new paper describing a formal Archetype Modeling 
> Methodology (AMM). The aim of this paper is to provide archetype designers 
> (especially those who are new to this methodology) with clear guidelines on 
> how to face an archetype development project.
> 
> D. Moner, J.A. Maldonado, M. Robles, Archetype modeling methodology, Journal 
> of Biomedical Informatics. 79 (2018) 71–81. doi:10.1016/j.jbi.2018.02.003. 
> 
> You can find the published paper in
> https://www.sciencedirect.com/science/article/pii/S1532046418300224 
> <https://www.sciencedirect.com/science/article/pii/S1532046418300224>
> 
> For those who don't have access to it, I have prepared a white paper 
> summarizing the methodology. You can find it in 
> https://es.slideshare.net/damoca/archetype-modeling-language 
> <https://es.slideshare.net/damoca/archetype-modeling-language>
> 
> We hope this contribution is useful for you and that it facilitates archetype 
> adoption.
> 
> -- 
> David Moner Cano
> 
> Web: http://www.linkedin.com/in/davidmoner 
> <http://www.linkedin.com/in/davidmoner>
> Twitter: @davidmoner
> Skype: davidmoner
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: design description of lab archetypes

[GF]

Hi,

In my SIAMM thinking:
- I use the ENTRY to model using a fixed pattern the process of documentation 
of anything (the context of documentation) and that what is documented
- What can be documented is done using a panel (compound statement) as CLUSTER
- The compound statement CLUSTER documents all about the context of the panel
- The compound statement CLUSTER can hold one or more single statement CLUSTERS
In this way the path always is the same for one single statement of a panel of 
single statements.


In CIMI they use the ENTRY in a peculiar way to achieve the same, but I am not 
in favor of this solution.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 4 Dec 2017, at 01:14, Koray Atalag <k.ata...@auckland.ac.nz> wrote:
> 
> Hi,
>  
> I couldn’t see any further discussions on the points Thomas raised – 
> especially around being able for AQL to be able to fetch a lab result whether 
> inside the single analyte or part of a panel. Right now they’d be two 
> different paths and it is not ideal. I’ve also read the documentation Ian has 
> put and found it confusing as well.
>  
> Can I ask to provide further guidance to the community using the specific use 
> cases Tom gave below? I reckon going with the panel option by default is 
> probably a practical good solution
>  
> Cheers,
>  
> -koray
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[GF]

Hi,

You are right; I agree with you.
But …
Archetypes (most times) have to be very forgiving with constraints.

Archetypes are used to build Templates.
These are created for a specific purpose in a specific circumstance.
Templates are used to specify interfaces and then most constraints have to be 
set fully.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Nov 2017, at 15:49, Boštjan Lah <bostjan@marand.si> wrote:
> 
> 
> 
>> On 10 Nov 2017, at 15:03, GF <gf...@luna.nl <mailto:gf...@luna.nl>> wrote:
>> 
>> Why isn’t it a good idea?
> 
> Perhaps it's just a matter of taste, but it makes no sense to me to have 
> something stored into container Diagnosis and then not have an actual 
> diagnosis code in it.
> Same for temperature, blood pressure, etc.
> Perhaps I can make a counter-question - can you give an example where this 
> makes sense?
> 
> Bostjan
> 
> 

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[GF]

Hi,

Even when elements make no sense when both are recorded, even then 1..1 is a 
problem in Archetypes.
It is up to the implementer to decide to restrict 0..n further in the Template.

I suggest to make archetype as generic as possible and use almost always 0..n

 Implementers are exposed to Templates but NOT Archetypes.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Nov 2017, at 11:47, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Crossposting this between the clinical and implementers lists, since it 
> belongs in both:
>  
> In some archetypes, one or more elements are set as mandatory (typically 
> occurrences 1..1 or 1..*), because the rest of the concept makes no sense 
> without this particular element recorded. Examples are Problem/diagnosis name 
> in Problem/diagnosis, and Temperature in Body temperature. This is not 
> intended to mean that it’s mandatory to enter data into the element in a UI, 
> but that this particular element is mandatory in any persisted composition 
> that uses the archetype.
>  
> Recently however, we received a request to change the Head circumference 
> element in the Head circumference archetype from 1..1 to 0..1 because the 
> element being mandatory in the archetype automatically made the UI form 
> builder mandate the entering of data into the UI field, and removing the 
> archetype on the fly made more unnecessary clicks. In a fit of mental 
> hiccups, I agreed with and performed this change, but have since realised 
> this is wrong, because:
> ·   A mandatory archetype element is not the same as a mandatory UI field
> ·   A mandatory UI field is more like a field where you only allow 
> persisting non null values, while a mandatory archetype element can be 
> persisted with a nullvalue without a problem.
>  
> How are implementers actually handling this? Do you separate UI field 
> mandation and archetype element mandation?
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
> 
> Tel. +47 40203298
> Web: http://arketyper.no <http://arketyper.no/> / Twitter: @arketyper_no 
> <https://twitter.com/arketyper_no>
>  
> ___
> openEHR-implementers mailing list
> openehr-implement...@lists.openehr.org 
> <mailto:openehr-implement...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>  
> <http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: design description of lab archetypes

[GF]

Hi,

Panels have a specific name
And can have an associated result describing the panel as a whole.
Plus context data pertaining to the panel and all its items.
E.g. Haematology panel: normal.
Both the Panelresult and the results of the individual items can to be queried.

Remarks:
- The individual Itemresults are the result of a process and therefor 
Observations (ENTRIES)
- The Panelresult is the result of an EVALUATION

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 13 Jul 2017, at 21:19, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Going a bit further in my analysis, it seems to me that the archetypes needed 
> are not exactly what are in CKM right now... I would expect:
> COMPOSITION: Lab report
> order meta-data
> etc
> OBSERVATION: Lab Test [*]  // may be LOINC coded here, or via archetype 
> binding only
> protocol
> method
> other details...
> sample
> data/events/data: ITEM_TREE: results [1]
> ELEMENT: test status
> ELEMENT: diagnostic service category
> ELEMENT: conclusion
> ELEMENT: test findings
> ELEMENT: pathological diagnosis
> CLUSTER: Lab Analyte Result [*]  // may be LOINC coded here, or via archetype 
> binding only
> value
> method [0..1]
> comment [0..1]
> other detail [0..*]
> Only the bolded items need be archetypes. So I don't think 'lab panel' 
> (understanding 'panel' as just a list of analyte results) needs an archetype. 
> Maybe I am missing something
> 
> - thomas

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: openEHR-technical Digest, Vol 64, Issue 6

[GF]

Dear Silje,

I understand that at the clinical (health care provider) level each wants/needs 
to do its own thing in each unique way.

But:
Modelling Templates using recurring patterns (Archetypes) has a (a lot of) 
value.
Doing the same things the same has value.
In this way we can create an ordered way to query the data safely.

What means ‘the way that best represents the data’?
Is it the way clinicians see it how it is presented?
Or is it the way we can query the best, most safe way?
Requirements for both are not the same.

Questions in questionnaire are observations.
But what is it, when a Scale makes use of existing data in the database and 
calculates an aggregate result?
(E.g. BMI)
Isn’t the latter an evaluation of existing observations by means of a rule?
In the case of BMI the weight and length are real observable properties of a 
(human) body.
Question: Is the BMI an observable property? I think not. It is an aggregate, 
an evaluation.



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Jun 2017, at 19:34, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> I agree and disagree.  <>J
>  
> An EHR needs to be able to cope with all kinds of data, “questionnaire” or 
> not. However I’m not so sure a modelling pattern that works for everything 
> that could be labelled a “questionnaire” is achievable, or even useful.
>  
> Modelling patterns are sometimes extremely useful, for instance for 
> facilitating modelling by non-clinicians or newbies, but sometimes they 
> aren’t very practical. One of the problems is that clinical information in 
> itself is messy, because healthcare information doesn’t follow nice semantic 
> rules. Clinical modelling must above all be faithful to the way clinicians 
> need to record and use data, not to a notion of semantically “pure” models.
>  
> Finding “sweet spots” by identifying patterns that are sensible, logical, and 
> above else *work* for recording actual clinical information is often an 
> excruciatingly slow process of trial and error, exemplified by the substance 
> use summary EVALUATION and the physical examination CLUSTER patterns of 
> modelling, which both had taken years of trial and error long before I got 
> involved in them.
>  
> If we can find patterns across some kinds of “questionnaires”, like clinical 
> scores, great! However, since there isn’t a standardised pattern for paper 
> questionnaires, it’s not likely that it’s possible to make one for electronic 
> questionnaires. Outside the RM/AOM, a generic pattern archetype for every 
> questionnaire with variable levels of nesting, variable data points, etc 
> isn’t possible, nor would it in my opinion be useful. It would put all the 
> modelling load on the template modellers, which arguably would be more work 
> than modelling the same structures as made-for-purpose archetypes.
>  
> Some rules of thumb have developed over time though:
> 1.   Model the score/assessment/questionnaire in the way that best 
> represents the data
> 2.   Use the most commonly used name for identifying it
> 3.   Model them as OBSERVATION archetypes, unless they’re *clearly* 
> attributes of f.ex. diagnoses, in which case they should be CLUSTERs 
> (example: AO classification of fractures)
> 4.   Make sure to get references that support the chosen structure and 
> wording into the archetypes
>  
> In my opinion this pragmatic approach is likely to capture the data 
> correctly, while at the same time minimising overall modelling workload.
>  
> Regards,
> Silje
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> <mailto:openehr-technical-boun...@lists.openehr.org>] On Behalf Of GF
> Sent: Tuesday, June 6, 2017 3:58 PM
> To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org 
> <mailto:openehr-clinical@lists.openehr.org>>
> Cc: Thomas Beale <openehr-techni...@lists.openehr.org 
> <mailto:openehr-techni...@lists.openehr.org>>
> Subject: Re: openEHR-technical Digest, Vol 64, Issue 6
>  
> I agree.
> ‘questionnaire’ is many things, but not at the same time.
>  
> In any case any EHR needs to be able to cope with all kinds.
> From ones with one or more qualitative results: such as the checklist
> To the validated Score where individual results are aggregated in one total 
> score.
>  
> It must be possible to create one pattern that can deal with all kinds.
>  
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
>  
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>  
> On 6 Jun 2017, at 14:46, Vebjørn Arntzen <varnt...@ous-hf.no 
> <mailto:varnt...@ous-h

Re: openEHR-technical Digest, Vol 64, Issue 6

[GF]

I agree.
‘questionnaire’ is many things, but not at the same time.

In any case any EHR needs to be able to cope with all kinds.
From ones with one or more qualitative results: such as the checklist
To the validated Score where individual results are aggregated in one total 
score.

It must be possible to create one pattern that can deal with all kinds.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Jun 2017, at 14:46, Vebjørn Arntzen <varnt...@ous-hf.no> wrote:
> 
> Hi all
>  
> To me a "questionnaire" is a vague notion. There can be a lot of different 
> "questionnaires" in health. From the GP's in Thomas's example to a Apgar 
> score, to a clinical guideline and even a checklist. Those are all a set of 
> "questions and answers", but the scope and use is totally different. In paper 
> questionnaires we will find a mix of many, maybe all, of those, crammed into 
> what the local practice have found to be useful (= "Frankenforms"). To try to 
> put all of them into a generic questionnaire-archetype is of no use.
>  
> Examples:
> The GP questionnaire referred to by Thomas is in the quoted question about 
> "ever had heart trouble" merely a help for the GP, and of little use for 
> computation. But if it is supplemented by more specific questions, based on 
> answers by the individual, then the final result can be "occasional 
> arrhythmia with ventricular ectopics", which is a relevant information for 
> later use and should be put into a relevant archetype. So is it a 
> "questionnaire" or a guideline for the consultation? Not relevant IMO, it's 
> the content, that's relevant.
>  
> Patients with haemophilia in Oslo university hospital are offered a 
> questionnaire online to register whether they've had incidents of bleeding, 
> what caused it, if they needed medications and if so, the batchnumber of the 
> medication. This is followed up by the staff both for reporting of used 
> medication, and for the patients next follow-up out-patient control or 
> admission. Questionnaire or not? Not relevant – it's what the information is 
> and what it is for, that is important. Find relevant archetypes for them, 
> OBSERVATIONS or ADMIN-ENTRY for this, I guess.
>  
> Even checklists are a set of questions and answers. "Have you remembered to 
> fill out the diagnosis?". "Is there a need to offer the patient help to deal 
> with the cancer diagnosis?". Main thing is to analyze what the resulting 
> answer is representing, and the use of it. Decision support? Clinically 
> relevant? Merely a reminder? Put them into a template, using appropriate 
> archetypes.
>  
>  
> Regards, Vebjørn
>  
> Fra: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org 
> <mailto:openehr-clinical-boun...@lists.openehr.org>] På vegne av Thomas Beale
> Sendt: 5. juni 2017 18:55
> Til: For openEHR technical discussions; For openEHR clinical discussions
> Emne: Re: openEHR-technical Digest, Vol 64, Issue 6
>  
>  
> 
> this has to be essentially correct, I think. If you think about it, scores 
> (at least well designed ones) are things whose 'questions' have only known 
> answers (think Apgar, GCS etc), each of which has objective criteria that can 
> be provided as training to any basically competent person. When score / scale 
> is captured at clinical point of care, any trained person should convert the 
> observed reality (baby's heartrate, accident victim's eye movements etc) into 
> the same value as any other such person. In theory, a robot could be built to 
> generate such scores, assuming the appropriate sensors could be created.
> 
> With 'true' questionnaires, the questions can be nearly anything. For 
> example, my local GP clinical has a first time patient questionnaire 
> containing the question 'have you ever had heart trouble?'. It's pretty clear 
> that many different answers are possible for the same physical facts (in my 
> case, occasional arrhythmia with ventricular ectopics whose onset is caused 
> by stress, caffeine etc; do I answer 'yes'? - maybe, since I had this 
> diagnosed by the NHS, or maybe 'no', if I think they are only talking about 
> heart attacks etc).
> 
> My understanding of questionnaires functionally is that they act as a rough 
> (self-)classification / triage instrument to save time and resources of 
> expensive professionals and/or tests.
> 
> There is some structural commonality among questionnaires, which is clearly 
> different from scores and scales. One of them is the simple need to represent 
> the text of the question within the model (i.e. archetype or template), 
> whereas this is not usu

Re: openEHR-clinical Digest, Vol 59, Issue 20

[GF]

Dear William,

I persist.
Questions -> LOINC
Answers   -> SNOMED
Check with Stan Huff for the opinion of CIMI

Yes, SNOMED has Observable entities attached to a ‘value’.
It is used in the leaf-node (ELEMENT)

Other nodes in Archetypes (all other structural classes like COMPOSITION,  
SECTION, ENTRY, CLUSTER) had better use LOINC.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Apr 2017, at 11:51, William Goossen <wgoos...@results4care.nl> wrote:
> 
> Many questions are in SNOMEDCT eg observable entities 
> Many answers are in LOINC, in particular the answers to questions for 
> assessment scales.
> 
> ISO TS 13972 gives careful guidelines to choose the precise code from any 
> code system for both questions and answers.
> 
> The blunt this does A and that does B will prove impossible for many concepts 
> and I see no move to 100% redo SnomedCT nor LOINC (because it is unnecessary).
> 
> Vriendelijke groet,
> 
> Dr. William Goossen
> 
> Directeur Results 4 Care BV
> +31654614458

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: SNOMED in CKM

[GF]

Pablo,

I agree.
Attaching codes to nodes in the archetype is in order to disambiguate that 
archetype node concept/name.

In addition.
I think that we should NOT use SNOMED-CT codes for that purpose.
As far as I know this is the realm of LOINC. So we need LOINC codes to 
disambiguate nodes in an archetype.

In general LOINC is used to disambiguate the ‘Question’.
And SNOMED is used to disambiguate the ‘Answer’; the ‘Result'
This implicates that LOINC must be used in all Archetype nodes that are NO 
leaf-nodes.
SNOMED must be used in Leaf-nodes and stored as results and queried for as 
results.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 25 Apr 2017, at 06:23, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Hi Bert,
> 
> Maybe my wording is the issue here since I don't disagree with what you said.
> 
> Take into account that I use the word "might" on every sentence, as the 
> indication of an ability. Never said that 1. applies to all contexts, or 2. 
> that those are hard rules. In those cases I would use "must" instead of 
> "might".
> 
> With that being said, when a SNOMED CT code is referenced directly as a bind 
> to an archetype node, the purpose is to add definition to the archetype, not 
> to use the code as part of the record. That can be done, but is not the 
> purpose of having term bindings on the archetype. That is explained on the 
> specs somewhere, is not my idea :)
> 
> 
> Cheers,
> Pablo.

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: BMI archetype

[GF]

My ‘definitions'

Observation: a result obtained by an author using human senses
Calculation: a kind of Evaluation by a human or device using Observations and 
knowledge (rules, formula)
Evaluation/assessment: Interpreting observations caused by processes using 
existing knowledge
Diagnosis: Special case of Evaluation. The process pertains to processes in the 
Patient system.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Apr 2017, at 09:10, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> from ehr_im
> 
> OBSERVATION (for all observed phenomena,including mechanically or manually 
> measured, and responses in interview)
> 
> My interpretation is automatic calculations are included in "mechanically 
> measured".
> 
> Also
> 
> EVALUATION (for assessments, diagnoses, plans, risks, recommendations)
> 
> I don't see an evaluation in the execution of a numeric formula, but I can 
> see it in the recording of an evaluation in terms of the result of executing 
> the formula. Similar case the calculation of the mean systolic BP based on a 
> series of events = 140 mmHg (is OBS), and stating "high BP" or "hypertension" 
> is EV).
> 
> On Mon, Apr 10, 2017 at 3:55 AM, Bert Verhees <bert.verh...@rosa.nl 
> <mailto:bert.verh...@rosa.nl>> wrote:
> Op 10-4-2017 om 8:52 schreef GF:
> I would say one needs both:
> Evaluation: when calculating by the author the BMI-number using existing 
> weight/height data
> Observation: when reading/copying by the author aa a BMI-result from a source
> 
> Also a good argument ;-)
> 
> A good solution would then be, put it in a cluster, so it can be sticked into 
> whatever is right for the situation.
> 
> 
> Bert
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org <mailto:openEHR-clinical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
> 
> 
> 
> -- 
> Ing. Pablo Pazos Gutiérrez
> Cel:(00598) 99 043 145
> Skype: cabolabs
>  <http://cabolabs.com/>
> http://www.cabolabs.com <http://www.cabolabs.com/>
> pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: BMI archetype

[GF]

I would say one needs both:
Evaluation: when calculating by the author the BMI-number using existing 
weight/height data
Observation: when reading/copying by the author aa a BMI-result from a source

Gerard Freriks
+31 620347088
gf...@luna.nl

> On 10 Apr 2017, at 08:33, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Hi, 
> 
> Shouldn't the BMI archetype on CKM be of type Evaluation? One does not 
> observe BMI, it is a calculation.
> openEHR-EHR-OBSERVATION.body_mass_index.v1
> Thanks for your comments.
> 
> Bert
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Z scores

[GF]

As is the case, there are several different ways in which data form the data 
base is represented on a screen or inputted via the key board.
Next to text, codes, images there are numerical values.
Many times the present data types are sufficient.
But there are more complex numerical results such as:
- value and normal ranges for a specific population
- value as the result of a statistical method. The Z-vlaue is just one of them.
For each kind of statistical result we need a specific archetype pattern.
These could be additional (extended) data types, but equally could be 
standardised archetype patterns.
The latter I prefer because data types I associate with the interface with 
program languages. And there statistical result do not play a role.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2017, at 08:21, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Hi everyone,
>  
> We’ve got an archetype proposal for Z scores 
> (https://en.wikipedia.org/wiki/Standard_score 
> <https://en.wikipedia.org/wiki/Standard_score>).
>  
> The way we understand these, they’re statistical calculations for specific 
> values such as height or weight, based on a population average, similar to 
> percentiles. We’re not sure how to model this in archetypes, and were 
> wondering if anyone else have solved this already? We’ve got an archetype 
> that’s related to child growth charts that will solve the problem for now, 
> but we’re looking for a more generic solution.
>  
> One of our hypotheses is that Z scores and percentiles should be handled 
> using some sort of RM “Statistical value” element. Could someone from the 
> specs program comment on this?
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
> 
> Tel. +47 40203298
> Web: http://arketyper.no <http://arketyper.no/> / Twitter: @arketyper_no 
> <https://twitter.com/arketyper_no>
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Problem with constraint_binding

[GF]

Yes.

Any item in an archetype potentially has:
- an ad-hoc, locally defined, display name
- an official canonical name in a specific language domain
- and, in order to disambiguate it, an unique code in
- a specific terminology/classification domain

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 16 Mar 2017, at 12:06, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
> On Wed, Mar 15, 2017 at 09:31:27PM +, Bert Verhees wrote:
> 
>> The problem with to Dv_coded_text's is however that it offers two value -
>> fields and that is not what we want.
> 
> But isn't the "name" field in any coded terminology "just
> another code" for a concept ?  Or, in other words, the
> "canonical", human-readable, stylised, formal label for a
> concept the user of a terminology may wish to actually name
> differently in day-to-day use ?
> 
> Karsten
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Problem with constraint_binding

[GF]

Hi,

Multiple codes create the problem of deciding which one is ‘the truth’.
One code needs be declared to be ‘the truth’.

But…

‘The truth’ depends on the context the code is used in.
So how can one declare what the clinical/administrative/research context is?

And…

‘subject’ has ‘associated data'
Is the code used for defining the subject of associated data?
Or is the code used to define the data provided itself?


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 15 Mar 2017, at 23:05, Sam Heard <sam.he...@oceaninformatics.com> wrote:
> 
> Hi All
>  
> The idea was that the code_phrase was directly entered as part of choosing 
> the text from the terminology.
> Anywhere where coding is done as a secondary process, the code mappings allow 
> multiple codes.
>  
> I think this meets all the needs you have specified. Mappings allow each 
> terminology to be specified.
>  
> It is likely in the future that EHRs will have multiple mappings for 
> different purposes and different eras of computing, allowing upgrading of 
> historical data.
>  
> Cheers, Sam
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

I agree that they do not fit in a Data Type.
It had better be handled using archetypes.
It is too complex for a DV_Ordinal Data Type

The reason why I wrote what I wrote is that Archetype must do more than the 
bare essentials.
Leaving more to the implicit knowledge of humans or value sets stored in one or 
the other service, or coding system.
I think that one of the functions of archetypes is to define precisely what is 
stored and retreived and transported with the least amount of implicit 
knowledge left for humans.

Gerard


> On 30 Sep 2016, at 10:31, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> 
> On 29/09/2016 13:31, GF wrote:
>> Each entry in the classification needs:
>> - a screen representation (‘+++')
>> - a description (‘moderate')
> 
> in theory these two come from DV_ORDINAL.symbol, which is a DV_CODED_TEXT. 
> That assumes a text value of '+++' and either a description or synonym (or 
> both) of 'moderate'.
> 
>> - an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
>> 'Higher limit'
>> - an expression defining the exclusion criteria ('no diagnosis of xyz')
> 
> these are semantic things and I think have to be outside of the DV_ORDINAL 
> data type definition, which after all just represents a value. Once you add 
> these, it becomes a disease- or test-specific definition. I'm not sure where 
> we would put these things - I think probably in a knowledge base of semantic 
> definitions of different test results. One might argue that SNOMED should 
> provide that, but I'm inclined to think it belongs in a knowledge base of 
> lab-related ranges, labels and other computational elements, like the 
> 'presentation ranking number' and 'value for calculation support' you have 
> below.
> 
>> 
>> And perhaps each entry needs:
>> - Ranking number (‘1')
> 
> DV_ORDINAL.value.
> 
>> - Presentation ranking number (‘4')
>> - Associated value for calculation support (‘100')
>> 
>> To my ideas the Semantic Ordinal, as described, actually is an Archetype 
>> Pattern or a Data Type.
>> 
> 
> did you mean 'of a Data Type'?
> 
> I think the above ideas are all likely to be useful, but they won't all fit 
> inside DV_ORDINAL...
> 
> - thomas

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

The ERS system needs to be able to represent faithfully that what was shown on 
a screen.
This is what the HcProvider signs off/attests.
See the requirements imposed on ERS systems in ISO 18308.

Therefor I’m of the opinion that the archetype used to store data in, and 
retrieve data from, the database must be able to carry that screen info.
For Clinical Decision Support Systems this screen info is irrelevant.
For legal purposes it is essential.

HcProviders always will use their own local classifications. They never 
uniformly will use one and the same, all the time.
These local classifications need to be mapped on a standardised internal 
pattern/archetype for classifications. It is this pattern that is stored and 
retrieved annex to the mapping to the local classification.

Gerard


> On 30 Sep 2016, at 10:06, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> On 29-09-16 14:31, GF wrote:
>> Each entry in the classification needs:
>> - a screen representation (‘+++')
>> - a description (‘moderate')
>> - an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
>> 'Higher limit'
>> - an expression defining the exclusion criteria ('no diagnosis of xyz')
>> 
>> And perhaps each entry needs:
>> - Ranking number (‘1')
>> - Presentation ranking number (‘4')
>> - Associated value for calculation support (‘100')
> 
> 
> I don't think screen presentations should be something to consider in 
> archetype-structures. A few weeks ago this was said to me on this list, and I 
> think that is right. Screen presentation-definitions should be something to 
> use in templates for screen presentation. There can also be templates for 
> other purposes, messages, reports, etc.
> 
> Archetypes, except for its original purpose: data-structure-representation, 
> need to be purpose independent. Archetypes are the base to build templates 
> on, and depending of the purpose of the template, the data will be 
> represented in a different way.
> 
> So archetypes need to be as much as possible machine-processable, and if you 
> use all kind of convenient terms to, for example, indicate pain, then you 
> will never be able to datamine (research in the history of a patient, or in a 
> population) in a more generic way, and you will also need that specific 
> archetype.
> 
> Imagine a hospital with 7000 archetypes, it will become nearly impossible to 
> find persons which have pain, what kind of pain and how severe it is.
> 
> Better is to code pain, and I know SCT has good codes for pain (there may be 
> other code-systems too). This makes machine processable searching for pain, 
> kind of pain, severity of pain possible and will improve healthcare for a 
> specific patient or a population.
> 
> Bert
> 
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')
- an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
'Higher limit'
- an expression defining the exclusion criteria ('no diagnosis of xyz')

And perhaps each entry needs:
- Ranking number (‘1')
- Presentation ranking number (‘4')
- Associated value for calculation support (‘100')

To my ideas the Semantic Ordinal, as described, actually is an Archetype 
Pattern or a Data Type.

Gerard

> On 29 Sep 2016, at 14:09, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> 
> On 29/09/2016 12:58, GF wrote:
>> Is possible to define inclusion and exclusion criteria in the DV-Ordinal?
>> 
> 
> Gerard
> 
> can you explain in more detail what you mean?
> 
> -thomas
> 
> 

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

Is possible to define inclusion and exclusion criteria in the DV-Ordinal?

GF

> On 29 Sep 2016, at 09:00, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Thanks for your replies everyone!
>  
> Can the Any data type be constrained to DV_ORDINAL and populated with values 
> in template or at run time?
> Regards,
> Silje
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: More generic reference model

[GF]

Thomas,

I agree.

In the Semantic Stack various layers are orthogonal and intersect.
The intersection between SNOMED Reference Terminologies and structures 
(archetypes) is exactly at the righthand side of the ‘is’ relation.
Codes from SNOMED are ‘universals’, meaning definitions, like entries in a 
dictionary. They define generic truth’s.
Archetypes are Logical Models that define what will be documented about a 
specific patient by a specific author at a specific place and time, for a 
specific reason.
The nodes in the structure are needed to document the data in its context, the 
epistemology. 
Archetypes are about ‘particulars’. They are the left-hand side of the ‘is’ 
relation.
This left-hand needs a different code from a different coding system. LOINC is 
the logical candidate.
Even without a filled right-hand side with a SNOMED code, there is the need to 
bind a code to the left-hand side in the archetype to disambiguate it.

Two kinds of coding systems intersect in the Semantic Stack layer that is the 
Archetype in well defined locations for well defined reasons.

Gerard

> On 3 sep. 2016, at 08:51, Thomas Beale  wrote:
> 
> 
> 
> On 02/09/2016 04:04, Bert Verhees wrote:
>> On 02-09-16 11:18, Daniel Karlsson wrote:
>>> Terminologies typically do not specify which pieces of information are 
>>> needed in a given situation.
>> 
>> Hi Daniel, I don't have at the moment opportunity to reply to all you write, 
>> so excuse me for cherrypicking one idea of your message.
>> 
>> I thought SNOMED specifies which information is needed in a given situation, 
>> but maybe I misunderstand you?
> 
> It does various things, but this is not one of them, except by accident ;-)
> 
> SNOMED is on the right-hand (ontological) side of the is-about relation, EHR 
> information (defined by archetypes) is on the left (epistemological) side.
> 
> So terminology codes within EHR information can indicate what the items 'are 
> about' (in terms of real world categories) but the structures and data types 
> of information items are not generally known within the terminology. 
> Terminology doesn't say why pulse is a good surrogate for heart rate, or in 
> what circumstances MAP BP would be used, or the structure of data in a liver 
> function test. These are generally contingent relations and substitutions, 
> based on cultural, economic and other factors. Terminologies (if well 
> defined) mostly deal in necessary / invariant relations between entities. At 
> the next level out, EHR data relates to situations, which are full of 
> accidental relationships; terminology doesn't easily deal with these either.
> 
> - thomas
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: More generic reference model

[GF]

Daniel,

I agree with your opinions.

And observe - like you - differences where boundaries are drawn.

To me it is logical that there are differences because the scope of Bert is not 
the same as the scope of OpenEHR or CIMI.
Bert’s scope is implementation in databases
OpenEHR -to me- is a mix of theory and implementation practicality creating 
archetypes serving clinicians
CIMI’s scope is to create standardised Logical Models that happen to be 
archetypes. 
CIMI does not expect that CIMI Logical Models will be implemented as is, but 
implemented after a transformation.


Gerard

> On 2 sep. 2016, at 11:18, Daniel Karlsson  wrote:
> 
> Dear All,
> 
> while there is, as you note, overlap and resulting redundancy, I believe this 
> is hard to avoid. If the archetype is an information requirement 
> specification and and the information requirements are different for 
> observations, evaluations, instructions, ... (which I believe they are) then 
> this level is needed. Terminologies typically do not specify which pieces of 
> information are needed in a given situation. CIMI e.g. has drawn the line 
> between the RM and archetypes differently compared to openEHR and introduced 
> more layers (RM, reference archetypes, clinical patterns, etc.) but the 
> overall idea with specific clinically motivated constraints for classes of 
> information. Not-quite-as-similarly, FHIR has specified information 
> requirements in a growing number of clinical resources.
> 
> So, I do not see a trend moving away from information model frameworks 
> (together with terminologies) being central to interoperability.
> 
> This doesn't mean that openEHR shouldn't try hard to improve (the guidance 
> for) use of archetypes together with more terminologies like SNOMED CT, but 
> we still jointly have to identify the "sweet spot" (Heather's words) which 
> gives the most usefulness.
> 
> Cheers,
> Daniel
> 
> 
> On 2016-09-01 09:54, Bert Verhees wrote:
>> Hi,
>> 
>> 
>> I am just wondering if there are some opinions about this.
>> 
>> 
>> Do we still need the not so generic reference model which OpenEhr has, with 
>> archetypes denoting Observation, Evaluation etc?
>> 
>> Wouldn't a more  generic reference model, like ISO13606 be sufficient, when 
>> the terminology, worldwide, is moving to SNOMED-CT?
>> 
>> Because the SNOMED-concepts already indicate in which hierarchy a data-item 
>> belongs (clinical finding, procedure, body structure, etc), and with much 
>> more detail then the OpenEHR reference model.
>> 
>> 
>> When using SNOMED in OpenEHR there will be redundant information created, 
>> and to not create redundant information is one of the main golden rules in 
>> system design.
>> 
>> I think the reference model design needs reconsideration. It comes from a 
>> time when there was no SNOMED-CT.
>> 
>> Thanks for any thoughts.
>> 
>> Bert
>> 
>> 
>> ___
>> openEHR-clinical mailing list
>> openEHR-clinical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 
> 
> -- 
> Daniel Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: HL7 and negation

[GF]

Processes have state models to indicate how they are  (are not) executed.
When an investigation could not be done there must be an abnormal status 
indicator and reason explaining why.

On other matter is the presence or absence of something.

Gerard




> On 14 jun. 2016, at 05:56, Heather Leslie 
>  wrote:
> 
> Hi Thomas,
>  
> Point 3 is not simply about ‘not applicable’ – it is about the need to assert 
> a clinical statement that the examination could not be done (as opposed to NA 
> or didn’t feel like it), often for medicolegal purposes. It is more than ‘not 
> applicable’ and often needs a reason why to be asserted. Classic example is a 
> patient who has had an eye injury and concomitant head injury – the pupils 
> are one of the physical signs that are monitored closely to track potential 
> intracranial issues and if the pupils are not able to be visualised due to 
> swelling or other trauma you may miss a clue as the patient deteriorates. We 
> need to record that the clinician effectively looked but couldn’t complete 
> the examination due to 
>  
> Agree that Point 4 is a not applicable situation – for this patient only, but 
> the template as a whole might be applicable for most others. 
>  
> I know that it has been requested for many years but we also need reasons for 
> selection of many of the existing RM null flavours…
>  
> Regards
>  
> Heather

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: HL7 and negation

[GF]

In my system there are more kinds of ‘ENTRY’ than Observation, Evaluation, 
Ordering and Action.
I see the need to have kinds of patterns for processes like: Observing 
Assessing/Inferencing, Planning, Ordering and Executing.
Each of these processes have an associated state model and epistomological 
features of which one of them in Localisation in Time.

Gerard


> On 11 jun. 2016, at 16:37, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Gerard,
> 
> in this scheme what does 'status' encode? Actual | future?
> 
> - thomas
> 
> On 11/06/2016 14:48, GF wrote:
>> It is for the reasons that Thomas states that I think there are three 
>> Modifiers:
>> - Presence
>> - Certainty
>> - Status
>> 
>> Gerard
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: HL7 and negation

[GF]

It is for the reasons that Thomas states that I think there are three Modifiers:
- Presence
- Certainty
- Status

Gerard


> On 11 jun. 2016, at 12:09, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Let's state the problem as one of associating some sort of absence, presence, 
> or in-between indicator with some X in a patient, or some other subject...
> 
> There is some discussion about this topic in SPECPR-118 
> <https://openehr.atlassian.net/browse/SPECPR-118>, in which Ian McNicoll made 
> the comment:
> 
> I think we need to do a bit more thinking about the pros and cons and the 
> somewhat different requirements of e.g negating a diagnosis vs. negating a 
> symptom.
> 
> This is exactly right - there are different kinds of Xs. There are observable 
> Xs, including things we use instruments to observe (which we generally assume 
> to be reliable in a practical sense). So presence/absence claims can 
> reasonably be made in cases where the X being observed (e.g. pregnancy, MRSA, 
> being a smoker) is the same thing the claim is made about (is pregnant, neg 
> MRSA, non-smoker). In this case, the presence / absence can reasonably be 
> said to be part of the reported reality of the X in question.
> However, if the claim is about a C (some 'condition') where C cannot be 
> directly observed (or is not, in the current situation) then we are looking 
> at an epistemic claim about knowledge of C, based on observed X, what X means 
> in the context of patient type P, and so on. There is a range of epistemic 
> claims that could be made about Cs, e.g. the following:
> doesn't exist - 100% sure C not present in patient - e.g. diabetes type I, 
> based on negative oral glucose test
> may exist - C is effectively one branch of a differential diagnosis or other 
> assessment
> does exist - 100% sure C present in patient - e.g. diabetes type I, based on 
> +ve oral glucose test
> no risk of C in future - 100% sure C will not occur, e.g. BRCA1 or 2 breast 
> cancer, based on genetic test (we assume the latter is bullet-proof)
> risk of C in future - some likelihood of C occurring
> guarantee of C occurring in future - future reaction to exposure to bee venom 
> in a patient known to be hyper-allergic to been venom
> This basically boils down to:
> 
> it may be reasonable to allow presence or absence of true 'observables' to be 
> encoded in a binary way (what we think of as Observations in openEHR)
> claims regarding any kind of assessment, opinion, diagnosis, etc of something 
> we don't directly observe as such are epistemic claims, i.e. claims about 
> type of knowledge we have of some C, and are not encodable as a Boolean 
> 'existence' idea, but only as a level of certainty or similar. (what we think 
> of as Evaluations in openEHR)
> To make things somewhat annoying, there is probably a grey area between the 
> two. For example, 'pregnant' could arguably be regarded as a direct 
> observation or an assessment. But I think for 95% of cases things are obvious.
> So my conclusion is that the way to record presence / absence of true 
> observables could reasonably be done in a simple way, while any type of 
> assessment has to be recorded in a way that a) allows some range of 
> certainty, b) can include the temporal aspect (now, future etc) and c) can 
> reflect the current state of the investigative process.
> 
> Another annoyance that may prevent simple modelling is that EHRs often 
> include statements like 'is diabetic', e.g. reported by an obviously diabetic 
> patient about her diagnosis from 20y ago. Such statements are not in 
> themselves assessments, they are reports of the outcome of an earlier 
> process. As such, it may be reasonable to report such things in a more or 
> less binary way, e.g. is / is not diabetic.
> 
> I'm not a fan of negation or any other variety of presence, absence, risk of 
> etc being part of terminology, at least not pre-coordinated with the 
> ontological part (doing so is a total confusion about what the terminology 
> expresses). A typology of negation / epistemic claims could potentially exist 
> in some separate part of a terminology e.g. SNOMED, to be used to code 
> information model property like 'epistemic_status', or similar.
> 
> Aside: apparently the FHIR approach to representing things like 'no known 
> allergies' is to infer it by seeing if an allergies list is empty or not. 
> That sounds like a bad idea to me. If 'no known allergies' is understood as a 
> clinically meaningful statement made by e.g. a GP (based on reliable 
> knowledge about the patient), checking for a list being empty in some EMR 
> system isn't at all the same thing. All that latter does is establish that no 
> allergies have been recorded on this 

HL7 and negation

[GF]

Dear Colleagues,HL7 is thinking about the problem of negation. http://wiki.hl7.org/index.php?title=Negation_RequirementsThe group discussing it created a document with negation use cases.My questions are:- Can you let us know your reaction to this list of use cases?And- How should ‘negation’ be handled the best in respect of semantic interpretability?My personal opinions:- the boolean should not be used- try to translate the ‘negation’ problem into ‘presence and absence’. A concept is or is not present, a numeric result is of is not present.- do not use pre- and post co-ordinated concepts using SNOMED but use the SNOMED primitives.I’m curious to learn what your opinion is.Gerard

NegationUseCases.xlsx
Description: MS-Excel 2007 spreadsheet
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org