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-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: More generic reference model

[GF]

Thomar,

I know of the SOLOR project where SNOMED is harmonised with LOINC and RxNorm

http://wiki.hl7.org/index.php?title=CIMI_Quality_Modeling_Collaboration
http://www.healthcare-informatics.com/blogs/david-raths/interoperability/can-solor-snomed-loinc-rxnorm-project-create-terminology
http://www.businesswire.com/news/home/2016071900/en/Healthcare-Services-Platform-Consortium-Launches-Data-Standard-Integration

Gerard


> On 12 sep. 2016, at 10:32, Thomas Beale  wrote:
> 
> 
> we also still need a standard approach for non-SNOMED CT terminologies, such 
> as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of 
> progress on this issue?
> 
> - thomas
> 
> On 12/09/2016 07:32, Diego Boscá wrote:
>> sure thing, that's why we need standard expressions
>> 
>> 2016-09-12 8:27 GMT+02:00 Bert Verhees :
>>> Op 11-9-2016 om 20:32 schreef Diego Boscá:
 In practical terms however, you can't
 always expect to have all the access that you want to a given external
 service. e.g. I was banned from W3C once for launching a
 transformation (more like 10k...) that depended on a online schema.
>>> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RM Participations name/role?

[GF]

My understanding:
Roles are characteristics of an entity (person, device)
Functions are characteristics of a service/process

I agree with David.
The Statement (ENTRY) defines who is involved in that statement.

Problem:
A Statement is the documented result of a process (Observing, 
Assessing/Inferencing, Planning, Ordering, Executing)
How to model a Panel/Bundle is documented in a Statement? (e.g. Chem 7 panel, 
Apgar score, Blood count, Long function, etc.)
Each of the items in the Panel theoretically can be executed by a different 
participant.


Gerard


> On 24 Nov 2016, at 09:18, David Moner  wrote:
> 
> Hi,
> 
> I'm not sure if this is a correct approach. What in the example you call a 
> function can be in fact a full Action that is being done. That is, if the 
> function is so relevant that you can even assign a dedicated participant to 
> it, it should be also enough important to be represented and documented as an 
> individual entry of the EHR: coded, with start and end times, etc. If the 
> case is that a complex procedure is composed by other simpler procedures, 
> then we should document and link all of them.
> 
> I see the case of Silje from a different perspective. What she is asking is 
> if we can document the participants of each Element inside the Entry. So far 
> this is not possible, as Entries have been always seen as a whole clinical 
> statement, with all participants assigned to that level.
> 
> 2016-11-23 20:47 GMT+01:00 Ian McNicoll  >:
> Hi both
> 
> Agreed. 
> 
> Role = pathologist
> Function = macroscopic histopath examination. 
> 
> Ian. 
> On Wed, 23 Nov 2016 at 17:32, Thomas Beale  > wrote:
> Hi Silje,
> 
> The PARTICIPATION class 
> 
>  has a codable attribute 'function' for this purpose (calling it 'function' 
> rather than 'role' came from 13606). It may be that you want to state a 
> 'role' as well, i.e. to say that a certain kind of person is required, and 
> then use function to state the actual function that person is supposed to do 
> in the particular activity in question. 
> I would have expected 'function' to be sufficient for your example - just use 
> 2 x other_participations on the OBSERVATION.
> 
> An example of needing both could be something like:
> role = nurse
> function = foley catheterisation
> Currently 'role' is only known in the demographic model, i.e. on the other 
> side of the PARTY_PROXY.external_ref link. It may make sense to add a role 
> attribute to PARTICIPATION at some point if we need to distinguish the type 
> of person (qualification) from what they do in the activity.
> 
> - thomas
> 
> On 23/11/2016 06:29, Bakke, Silje Ljosland wrote:
>> Hi,
>> 
>>  
>> 
>> We’re wondering if it’s possible to specify what the role was of each 
>> instance of Participation in an OBSERVATION archetype? For instance in a 
>> histopathology result the macroscopic description will often be performed by 
>> a different person from the microscopic description. We’re thinking both 
>> will be listed using participation, but we need to be able to document which 
>> person did what.
>> 
>>  
>> 
>> Kind regards,
>> Silje Ljosland Bakke
>> 
>>  
>> 
>> Information Architect, RN
>> 
>> Coordinator, National Editorial Board for Archetypes
>> National ICT Norway
>> 
>> Tel. +47 40203298 
>> Web: http://arketyper.no  / Twitter: @arketyper_no 
>> 
>>  
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> 
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> 
> 
> 
> 
> -- 
> David Moner Cano
> Grupo de Informática Biomédica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es 
> http://www.linkedin.com/in/davidmoner 
> 
> Universidad Politécnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
> Valencia – 

Re: RM Participations name/role?

[GF]

Silje,

It may be true that it is sufficient for your use case.

In principle there are two methods to deal with information in the EHR:
-1- In the COMPOSITION the data is referenced by a code/url because it is in a 
shared Repository
-2- In the COMPOSITION all data needs to be made available explicitly, when 
used in a message/document where the receiver has no access to the shared 
Repository.

This means that the generic Archetype needs to support these two possibilities 
where in the Template for a particukar use case one of the methods is 
implemented

Gerard

> On 24 Nov 2016, at 10:35, Bakke, Silje Ljosland 
>  wrote:
> 
> Hi, thanks for your replies everyone! I think the function attribute is 
> sufficient for our use case, as the focus is on what the person did. Their 
> profession/credentials can be provided by an external knowledge base. <>
>  
> BTW, I tried looking this up using the UML link from the CKM, which led me 
> here: 
> http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html
>  
> .
>  I then tried to follow the List link to 
> http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html
>  
> ,
>  which gave me a 404.
>  
> Mvh.
> Silje
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> ] On Behalf Of Ian 
> McNicoll
> Sent: Thursday, November 24, 2016 9:49 AM
> To: For openEHR technical discussions  >
> Subject: Re: RM Participations name/role?
>  
> Hi David, 
> 
> I think your approach is perfectly valid but I suspect would impose an 
> overhead of complexity that is not always justified or necessary. 
> 
> In the original lab system the kind of individual entry tracking you suggest 
> is probably required to facilitate workflow but by the time it hits the ehr, 
> that level of granularity is not needed IMO.
> 
> Another good example of the way the health data is summarised and compressed 
> as it passes through the system.
> 
> Both approaches are valid IMO. 
> 
> Ian
> On Thu, 24 Nov 2016 at 08:18, David Moner  > wrote:
> Hi,
>  
> I'm not sure if this is a correct approach. What in the example you call a 
> function can be in fact a full Action that is being done. That is, if the 
> function is so relevant that you can even assign a dedicated participant to 
> it, it should be also enough important to be represented and documented as an 
> individual entry of the EHR: coded, with start and end times, etc. If the 
> case is that a complex procedure is composed by other simpler procedures, 
> then we should document and link all of them.
>  
> I see the case of Silje from a different perspective. What she is asking is 
> if we can document the participants of each Element inside the Entry. So far 
> this is not possible, as Entries have been always seen as a whole clinical 
> statement, with all participants assigned to that level.
>  
> 2016-11-23 20:47 GMT+01:00 Ian McNicoll  >:
> Hi both
> 
> Agreed. 
> 
> Role = pathologist
> Function = macroscopic histopath examination. 
> 
> Ian. 
> On Wed, 23 Nov 2016 at 17:32, Thomas Beale  > wrote:
> Hi Silje,
> 
> The PARTICIPATION class 
> 
>  has a codable attribute 'function' for this purpose (calling it 'function' 
> rather than 'role' came from 13606). It may be that you want to state a 
> 'role' as well, i.e. to say that a certain kind of person is required, and 
> then use function to state the actual function that person is supposed to do 
> in the particular activity in question.
> 
> I would have expected 'function' to be sufficient for your example - just use 
> 2 x other_participations on the OBSERVATION.
> 
> An example of needing both could be something like:
> role = nurse
> function = foley catheterisation
> Currently 'role' is only known in the demographic model, i.e. on the other 
> side of the PARTY_PROXY.external_ref link. It may make sense to add a role 
> attribute to PARTICIPATION at some point if we need to distinguish the type 
> of person (qualification) from what they do in the activity.
> 
> - thomas
> 
>  
> On 23/11/2016 06:29, Bakke, Silje Ljosland wrote:
> Hi,
>  
> We’re wondering if it’s possible to specify what the role was of each 
> instance of Participation in an 

Re: Questionnaires

[GF]

Hi,

'Questionnaires’ is a problem.

The spectrum ranges from
- simple lists of questions and answers
to
- questions and answers that depend on other input from previous 
question/answers or data in the database
and questionnaire answers that can be aggregated in one result.

Answers to questions sometimes will be queried and others are not.
Sometimes one question allows one answer, sometimes more than 1, sometimes 
questions are optional, sometimes not.
Sometimes these answers and questions play a role within the questionnaire, 
sometimes they are used on their own outside.
Sometimes the aggregated results will be queried.
Sometimes questionnaires are used locally for administrative reasons, sometimes 
they act like any other clinical test.

All these give rise to requirements for possible solutions.

‘Intelligent’ questionnaires I consider out of scope, for the moment.

And - I think- the problem is tractable on the condition that the questionnaire 
is modelled as CLUSTERs.
With one CLUSTER/pattern to allow the optional aggregated result and define the 
components of the questionnaire.
This organising CLUSTER/pattern makes use of CLUSTERs/patterns for each 
question/answer pair.
These CLUSTERs are topics that can be queried. One must allow that queries 
start at the CLUSTER level.
It must be possible to query the aggregated result and the individual topics. 
The same problem is encountered with Lab. Panels.
So the quetionnaire nut meeds to be cracked.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Jul 2017, at 06:40, Heather Leslie 
> <heather.les...@oceanhealthsystems.com> wrote:
> 
> Hi Pablo,
>  
> From my POV the critical words in your email are “(defined on templates)”. If 
> we have to define the semantics of each questionnaire in the templates, why 
> not just archetype it and lock it down at that level.
>  
> In a generic questionnaire every data element will have to be an ‘Any’, 
> defined in the template; the questions will need to be added, the relevant 
> values defined etc.
>  
> AND the biggest problem for me is defining the pattern for the generic 
> questionnaire – every time I’ve tried to design a flexible pattern that 
> allows various levels of nesting under cluster headings for questionnaire 
> groupings etc I get tied up in knots. There is no one single solution that 
> will cover all questionairres – simple tree structures will not provide the 
> solutions we need.
>  
> We could use a generic OBSERVATION container and a simple CLUSTER that allows 
> multiple instances of a question with an ‘Any’ data type and a SLOT for 
> nesting further instances. But the modelling overheads are onerous and I’m 
> still struggling to see the value in pushing the work to the template design 
> rather than just archetyping it. I’ve attached an example to show a possible 
> pattern – but it is SO MESSY with renaming of every data point, constraining 
> every aspect of each question (just as you would in a de novo archetype) and 
> the overheads of explaining how to build a template from a generic pattern 
> and define every single part of it in the template seem not worth the benefit.
>   <>
> Maybe I’m missing something…
>  
> Heather
>  

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reports - a new openEHR RM type?

[GF]

There are several kinds of context archetypes/templates and their meta-data are 
used for:
- de novo data - re-used data
- step in the clinical treatment model (observation, assessment/inference, 
planning, ordering, execution)
- kind of interface it is designed for (data presentation on a screen, data 
capture, database store/retrieve, CDSS, …

Each Template needs to capture all this and is a Composition.
All these contexts are characteristics of a Composition in the end.

Questionnaires are in essence a tool that classifies information.
And sometimes it transforms a set of responses into an aggregated value/code
The questionnaire can be treated as any classification, meaning we need to de 
fine inclusion and exclusion criteria, 
and possible results per question can be a quantitative result (number, PQ, 
code), or a semi-quantitative result (high, low), or a qualitative result 
(present/ not present).
Semi-Qualitative results need, inclusion/exclusion criteria and a definition of 
what the norm/population is is about (females, children, etc.)


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

> On 31 May 2017, at 06:54, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Hi Thomas,
> 
> Thinking about the hierarchy, at which level will be a Report be? Below 
> compo? Below entry? Structure? Representation?
> 
> OT: many asked me this and didn't had a good answer. Do we have a pattern to 
> model questionnaires? Some require to define questions, and the answer type 
> in most cases is boolean, or coded text (multiple choice), and answers might 
> be 0..* (more than one answer for the same question is valid).
> 
> Cheers,
> Pablo.
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[GF]

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Jun 2017, at 10:48, William Goossen <wgoos...@results4care.nl> wrote:
> 
> Hi Heather,
> 
> the key difference is that the assessment scales have a scientific 
> validation, leading to clinimetric data, often for populations, but e.g. 
> Apgar and Barthell are also reliable for individual follow up measures.

Correct.
But in essence it is a set of questions and answers plus a set of rules to 
aggregate the collected data.




> 
> a simple question, answer, even with some total score, does usually not have 
> such evidence base. I agree that in the data / semantic code representation 
> in a detailed clinical model it is not different.

As you write yourself.

> 
> Hence, also Grahame's nonsense comment on the value of semantic 
> interoperability of such things. It is for user groups of stakeholders to 
> determine the clinical and scientific merits of such instruments not a 
> technical implementer.
> 

Yes. Local players must decide what they need.
But there is an interoperability issue, as well.
It is very likely that for research many years  from now we need to be able to 
interpret the old data.
In other words we need interoperability over longer periods of time, or better 
interpretability over longer periods of time.



> 
> vriendelijke groeten, with kind regards,
> 
> dr. William Goossen

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Questionnaires

[GF]

Hi,

A few of generic ideas around the question-answer pair.

There are several kinds of question-answer pairs:
- The general generic pattern is the pair: question - answer;
- The questionnaire can be one or more question-answer pairs;
- The questions can be locally defined or regionally, nationally, 
internationally used;
- Answers can be free text, quantitative (number, code), semi-quantitative 
(derived from a categorised set of possible answers using inclusion and 
exclusion criteria) or qualitative (present, not present);
- Answers can be aggregated by means of category, mathematical formula.

This list of kinds of questionnaires ranges from simple to very complex 
patterns.
Some are simple statements others are very complex scales and questionnaires in 
between.
They are all variations on a theme.
Any answer can expressed in the in-line local form and/or with a reference to 
an external source.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Jun 2017, at 07:59, Grahame Grieve <grah...@healthintersections.com.au> 
> wrote:
> 
> hi Heather
> 
> > A generic question/answer pattern is next to useless - interoperability is 
> > really not helped
> 
> I think you should rather say "A generic question/answer pattern is only 
> useful for exchanging the questions and answers, and does not allow re-use of 
> data". This is not 'next to useless for interoperability', just not fit for 
> any wider purpose
> 
> Grahame
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_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-clini...@lists.openehr.org 
> <mailto:openehr-clini...@lists.openehr.org>>
> Cc: Thomas Beale <openehr-technical@lists.openehr.org 
> <mailto:openehr-technical@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-technical Digest, Vol 64, Issue 4

[GF]

Why?
What are the arguments?

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Jun 2017, at 08:44, William Goossen <wgoos...@results4care.nl> wrote:
> 
> The examples given as Glasgow Coma Scale and Barthel index are definitely NOT 
> questionnaires. These are assessment scales and require quite a different 
> approach than the also extremely useful questions and answers.
> 
> Vriendelijke groet,
> 
> Dr. William Goossen
> 
> Directeur Results 4 Care BV
> +31654614458
> 
>> Op 5 jun. 2017 om 08:25 heeft openehr-technical-requ...@lists.openehr.org 
>> het volgende geschreven:
>> 
>> Send openEHR-technical mailing list submissions to
>>   openehr-technical@lists.openehr.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>   
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> 
>> or, via email, send a message with subject or body 'help' to
>>   openehr-technical-requ...@lists.openehr.org
>> 
>> You can reach the person managing the list at
>>   openehr-technical-ow...@lists.openehr.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openEHR-technical digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Re: Questionnaires (Grahame Grieve)
>>  2. RE: Questionnaires (Heather Leslie)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Mon, 5 Jun 2017 15:59:26 +1000
>> From: Grahame Grieve <grah...@healthintersections.com.au>
>> To: For openEHR technical discussions
>>   <openehr-technical@lists.openehr.org>
>> Cc: For openEHR clinical discussions
>>   <openehr-clini...@lists.openehr.org>
>> Subject: Re: Questionnaires
>> Message-ID:
>>   <cag47hgypmsi1u1znhheoh_ymz841m7mlvwd6hgccufsy-vq...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> hi Heather
>> 
>>> A generic question/answer pattern is next to useless - interoperability
>> is really not helped
>> 
>> I think you should rather say "A generic question/answer pattern is only
>> useful for exchanging the questions and answers, and does not allow re-use
>> of data". This is not 'next to useless for interoperability', just not fit
>> for any wider purpose
>> 
>> Grahame
>> 
>> 
>> On Mon, Jun 5, 2017 at 3:51 PM, Heather Leslie <
>> heather.les...@oceanhealthsystems.com> wrote:
>> 
>>> Following Thomas? suggestion re a separate thread:
>>> 
>>> 
>>> 
>>> I wrote a blog post in 2014 which still reflects our current thinking re
>>> questionnaires: https://omowizard.wordpress.com/2014/02/21/the-
>>> questionnaire-challenge/
>>> 
>>> 
>>> 
>>> Our experience is that the data is the priority and so we want to focus on
>>> questionnaires to support capture of good quality data.
>>> 
>>> 
>>> 
>>> If you want to try to capture data from the majority of existing
>>> questionnaires then good luck ? questionnaires notoriously ask questions
>>> badly, conflating multiple concepts into one question, Boolean True/False
>>> when there are other ?shades of gray? etc. They work variably as far as
>>> human interpretation but usually very badly wrt computer interpretation.
>>> 
>>> 
>>> 
>>> We do have experience in taking previous paper questionnaires, analysing
>>> the data requirements sought in terms of what we want to persist and then
>>> we design the UI/questions to match the data desired and/or suggesting the
>>> UI might show a questionnaire but each question the clinical data is
>>> actually recorded using core archetypes ? for example ?Do you have
>>> diabetes?? ? ?Yes?, is recorded using the value ?Diabetes? in the
>>> EVAL.problem_diagnosis and ?No? is recorded in the matching exclusion
>>> archetype. This creates real clinical data that can be used as part of a
>>> health record rather than create an electronic checkbox version of the
>>> original paper questionnaire which will never be used again, but capture
>>> dust in our EHR?s virtual archives.
>>> 
>>> 
>>> 
>>> In summary:
>>> 
>>>  - A generic question/answer pattern is next to useless -
>>>  interoperability is really not helped, especially if both the question and
>>>

Re: Blockchain

[GF]

What problem is BlockChain solving, that deployed technologies can not solve?

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

> On 13 Nov 2017, at 12:46, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> How are the plans about blockchain for OpenEhr? Is there any plan to 
> incorporate it in the standard, or is it regarded as a technical implementers 
> business?
> 
> Bert
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[GF]

Hi,


A blockchain[1] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-te20151031-1>[2] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-fortune20160515-2>[3] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-nyt20160521-3> – originally 
block chain[4] <https://en.wikipedia.org/wiki/Blockchain#cite_note-primer-4>[5] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-obmh-5> – is a continuously 
growing list of records 
<https://en.wikipedia.org/wiki/Record_(computer_science)>, called blocks, which 
are linked and secured using cryptography 
<https://en.wikipedia.org/wiki/Cryptography>.[1] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-te20151031-1>[6] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-cryptocurrencytech-6> Each 
block typically contains a hash 
<https://en.wikipedia.org/wiki/Cryptographic_hash_function> pointer as a link 
to a previous block,[6] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-cryptocurrencytech-6> a 
timestamp <https://en.wikipedia.org/wiki/Trusted_timestamping> and transaction 
data.[7] <https://en.wikipedia.org/wiki/Blockchain#cite_note-IPblockchain-7> By 
design, blockchains are inherently resistant to modification of the data. A 
blockchain can serve as "an open, distributed ledger 
<https://en.wikipedia.org/wiki/Distributed_ledger> that can record transactions 
between two parties efficiently and in a verifiable and permanent way."[8] 
<https://en.wikipedia.org/wiki/Blockchain#cite_note-hbr201701-8>[not in 
citation given <https://en.wikipedia.org/wiki/Wikipedia:Verifiability> (See 
discussion. 
<https://en.wikipedia.org/wiki/Talk:Blockchain#Edit_misrepresenting_cited_sources>)]
 For use as a distributed ledger, a blockchain is typically managed by a 
peer-to-peer <https://en.wikipedia.org/wiki/Peer-to-peer> network collectively 
adhering to a protocol for validating new blocks. Once recorded, the data in 
any given block cannot be altered retroactively without the alteration of all 
subsequent blocks, which requires collusion of the network majority.

https://en.wikipedia.org/wiki/Blockchain 
<https://en.wikipedia.org/wiki/Blockchain>



What is Blockchain offering?
Bringing data from a to b?
Storing data?
Securing data?
Preventing privacy incidents?
Taking care of non-repudiation?
Taking care of data integrity?
Play a role in logging?
Will it prevent hacking of PC’s, Servers?
and other attacks such social hacking, pasword sniffing, etc.?

At best it serves a role in: non-repudiation, data integrity and logging 
(access control lists) without the need of a trusted third party service.
But one has to rely on safe/secure IT-systems that make use of it.
It takes care of a non-health related issue; it takes care of a generic legal 
issue.

Bye the way.
NICTIZ’ opinion is:
- Certainly it (blockchain) can not be deployed and replace in healthcare the 
present “proven technology"
 Het kan zeker nog niet worden ingezet voor vervanging van de huidige “proven 
technology” in de zorg
- It is in the hype-phase.
- Many of the potential advantages will have to be proven.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 15 Nov 2017, at 21:14, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> There are so many privacy breaches in medical data, hacked accounts, 
> data-leaks, wacky account rules, social hacking, temporary personal from 
> employment agencies, no logging on access to systems, systems standing open 
> and the nurse doing something else.
> A GP can call a specialist, it is very common to call a specialist, and say 
> that information is needed on patient So and So. This happens so many times. 
> He does not need to prove that he is the GP for that patient. A specialist 
> does not have time for that kind of verifications.
> 
> And when you talk about these kind of things to clinicians, the all denying, 
> but they all know better.
> And when you talk about these kind of things to software companies, they 
> start denying too, their software is oke!
> But it isn't, because a doctor does not pay for security, but for nifty 
> software. On security no money can be earned.
> 
>> So unless you are talking about the openEHR system being actively hacked, I 
>> don't think this is a real use case. If we are talking about the openEHR 
>> versioning being hacked, then a) they had to hack RAID 10 storage, DB 
>> persistence mirroring, daily backups, b) the data centre has singificant 
>> security, c) some security analysis will have been made in advance (it will, 
>> won't it?!), and depending on the perceived threat, there may be e.g. 
>> hashing + notary, or signed hashes + notary, which requires the hackers to 
>> be of a superior variety. 
> 
> No one

Re: Blockchain

[GF]

A EJRC document about Blockchain in education:  
http://publications.jrc.ec.europa.eu/repository/bitstream/JRC108255/jrc108255_blockchain_in_education(1).pdf
 
<http://publications.jrc.ec.europa.eu/repository/bitstream/JRC108255/jrc108255_blockchain_in_education(1).pdf>



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 16 Nov 2017, at 00:02, GF <gf...@luna.nl> wrote:
> 
> Hi,
> 
> 
> A blockchain[1] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-te20151031-1>[2] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-fortune20160515-2>[3] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-nyt20160521-3> – 
> originally block chain[4] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-primer-4>[5] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-obmh-5> – is a 
> continuously growing list of records 
> <https://en.wikipedia.org/wiki/Record_(computer_science)>, called blocks, 
> which are linked and secured using cryptography 
> <https://en.wikipedia.org/wiki/Cryptography>.[1] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-te20151031-1>[6] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-cryptocurrencytech-6> 
> Each block typically contains a hash 
> <https://en.wikipedia.org/wiki/Cryptographic_hash_function> pointer as a link 
> to a previous block,[6] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-cryptocurrencytech-6> a 
> timestamp <https://en.wikipedia.org/wiki/Trusted_timestamping> and 
> transaction data.[7] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-IPblockchain-7> By 
> design, blockchains are inherently resistant to modification of the data. A 
> blockchain can serve as "an open, distributed ledger 
> <https://en.wikipedia.org/wiki/Distributed_ledger> that can record 
> transactions between two parties efficiently and in a verifiable and 
> permanent way."[8] 
> <https://en.wikipedia.org/wiki/Blockchain#cite_note-hbr201701-8>[not in 
> citation given <https://en.wikipedia.org/wiki/Wikipedia:Verifiability> (See 
> discussion. 
> <https://en.wikipedia.org/wiki/Talk:Blockchain#Edit_misrepresenting_cited_sources>)]
>  For use as a distributed ledger, a blockchain is typically managed by a 
> peer-to-peer <https://en.wikipedia.org/wiki/Peer-to-peer> network 
> collectively adhering to a protocol for validating new blocks. Once recorded, 
> the data in any given block cannot be altered retroactively without the 
> alteration of all subsequent blocks, which requires collusion of the network 
> majority.
> 
> https://en.wikipedia.org/wiki/Blockchain 
> <https://en.wikipedia.org/wiki/Blockchain>
> 
> 
> 
> What is Blockchain offering?
> Bringing data from a to b?
> Storing data?
> Securing data?
> Preventing privacy incidents?
> Taking care of non-repudiation?
> Taking care of data integrity?
> Play a role in logging?
> Will it prevent hacking of PC’s, Servers?
> and other attacks such social hacking, pasword sniffing, etc.?
> 
> At best it serves a role in: non-repudiation, data integrity and logging 
> (access control lists) without the need of a trusted third party service.
> But one has to rely on safe/secure IT-systems that make use of it.
> It takes care of a non-health related issue; it takes care of a generic legal 
> issue.
> 
> Bye the way.
> NICTIZ’ opinion is:
> - Certainly it (blockchain) can not be deployed and replace in healthcare the 
> present “proven technology"
>  Het kan zeker nog niet worden ingezet voor vervanging van de huidige “proven 
> technology” in de zorg
> - It is in the hype-phase.
> - Many of the potential advantages will have to be proven.
> 
> 
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 15 Nov 2017, at 21:14, Bert Verhees <bert.verh...@rosa.nl 
>> <mailto:bert.verh...@rosa.nl>> wrote:
>> 
>> There are so many privacy breaches in medical data, hacked accounts, 
>> data-leaks, wacky account rules, social hacking, temporary personal from 
>> employment agencies, no logging on access to systems, systems standing open 
>> and the nurse doing something else.
>> A GP can call a specialist, it is very common to call a specialist, and say 
>> that information is needed on patient So and So. This happens so many times. 
>> He does not need to prove that he is the GP for that patient. A specialist 
>> does not have time for that kind of verifications.
>> 
>> And when you talk about these ki

Re: Blockchain

[GF]

Bert,

I’m very sorry.
What I wrote I found it at their summary (page 8) of the NICTIZ document.
Of course it is my selection from that text.

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

> On 16 Nov 2017, at 00:53, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Dear Gerard, Nictiz published hundreds of pages about blockchain. So if it is 
> a hype (which it is), then Nictiz is playing an important role in that.
> 
> You cannot summarize those hundreds of pages to a few words and then state 
> that that reflects the opinion of Nictiz. Blockchain is a comprehensive 
> subject.
> 
> Please read this document, which is an nuanced inventory of their positions 
> regarding this:
> https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/Blockchain_in_de_zorg.pdf
>  
> <https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/Blockchain_in_de_zorg.pdf>
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[GF]

see below.

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

> On 13 Nov 2017, at 13:17, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Not very far from now (looking into the future, Scotty and Captain Kirk), 
> health information will be a worldwide web.
> Mayor players are diving into this trillion dollar business.
> 
> Health information will need to be accessible, and blockchain can be used to 
> guard all interaction between systems.
> You can find dozens of documents which handle about this.

Blockchain is a service that supplies functionality such as: non-repudiation, 
trust between parties in the public domain.
These functionalities can be achieved using existing technology.
In addition health is not something that takes place in the public domain.
There are not many things in healthcare that need anonymous transaction 
services that banks, notary public, provide.
Healthcare is highly personal.
> 
> In the Netherlands Nictiz is busy with it.
> 
> For example read this (sorry, only Dutch)
> https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/Blockchain_in_de_zorg.pdf
>  
> <https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/Blockchain_in_de_zorg.pdf>

NICTIZ sees some application of Blockchains at the IT-Infrastructure level: 
authentication, authorisation, and Access control.

OpenEHR is not a specification at the IT-Infrastructure level.


> 
> Summarizing:
> - Blockchain is needed when interacting parties do not trust or know each 
> other
> - A trusted third party cannot be found or is not desirable
> - Validity en transparency of transactions is important
> - Stored or interchanged data are very important

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

[GF]

In other words:

What is BlockChain solving?
My answer: it solves non-repuduation without a third trusted party.

Correct?

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 14 Nov 2017, at 17:31, Pieter Bos <pieter@nedap.com> wrote:
> 
> One problem with blockchain is that people think every blockchain is secure, 
> anonymous and decentralized – but that really depends on the specific 
> implementation.
> 
> You can probably still create a proof of something-that-is-not-work-or-space 
> that is reasonably decentralized, given you have enough independent parties 
> who can authorize blocks, a mechanism to decide how to trust new authorizing 
> parties and a good tamper-proof protocol including for example strict rate 
> limiting.
> 
> But the very nature of storing healthcare related data in a public blockchain 
> seems very tricky to me anyway – almost any implementation would need to be 
> able to handle attacks where you link multiple pieces of data to the same 
> person or party without having explicit permission to do so.
> Regards,
> 
> Pieter Bos

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM

[GF]

Lesson:
- One is at risk when relying on one single source; one single point of failure.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Nov 2017, at 09:37, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> On 19-11-17 09:31, Ian McNicoll wrote:
>> Does not work here either, Bert. The whole site is offline. Probably just a 
>> tech snafu.
> 
> Thanks Ian, it is strange, it is so since (at least) three days. I wouldn't 
> expect that from such an important standard.
> Bert
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

My two cents.

Two data collections are involved: Patient registry, Patient Health Record.
I focus on the Patient Health Record.

0- Committed data is never physically deleted.

1- Inactive. 'Copy of data'.
EHR with patient records.
The patient moves to an other place and chances Healthcare Provider.
A copy of the EHR is sent to that HcP.
The original becomes inactive and can be consulted for legal, administrative 
purposes, only.
The Patient record is labelled: inactive, read only for legal and 
administrative reasons

2- Inactive. ‘Removal of data’
The patient demands by force of law that all personal and health data is 
removed.
The EHR becomes inactive and can only be consulted for legal, administrative 
reasons
The Patient record is labelled: inactive, read only for legal and 
administrative reasons

3- Active: Updating of data by third party (patient)
The patient demands a change in the data recorded.
Data recorded after one or more events are changed.
The original Compositions stay un altered.
A new version of the Composition (with the patient as author) is created.

4- Active, Update by original author
New facts indicate that previously entered data about an event was incorrect. 
The mistake needs to be corrected.
A new version of the Composition is created.
Old data can be acted upon. The application needs to redress this fact.

5- Update before a Commit.
During data entry but before the Commit data can be changed always. Versioning 
is NOT necessary.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Nov 2017, at 13:49, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> It's potentially not a completely wrong idea: it might be worth thinking 
> about a 'deleted' marker on the VERSIONED_OBJECT type itself. As i noted 
> before though, i'd like to get a better idea of real scenarios where the 
> current model of deletion doesn't work properly before doing anything.
> 
> - thomas
> 
> 
> On 03/11/2017 02:36, Bert Verhees wrote:
>> 
>> In a versioned system there is no status for "deleted" necessary *inside* a 
>> composition. The system itself marks the composition deleted. With this in 
>> mind it seems to me the semantical meaning of the inside "deleted" status is 
>> meant for something else.
>> 
>> Bert
>> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

Even when the patient wants all data to be removed, this means removeal in the 
context of the provision of helath care.
For legal and administrative purposes the data can NOT be removed but be 
available for these non-healthcare provision related circumstances.
One needs a label ‘deactivated’ (for health purposes.

Remember: Even when the patient has left the author (HcP) has administrative 
and legal responsabilities. He is accountable for many years because fo actions 
taken. He needs to be able to defend himself.

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 4 Nov 2017, at 17:20, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Gérard has some points. A patient, in the Netherlands, has under conditions 
> the right to require the physical removal of all data.
> In that case no "deleted" marker is necessary.
> 
> Then there is the case of inactive patients. In case of a GP the law requires 
> he must.be <http://must.be/> able to produce the patients data until ten 
> years after last visit. Often patients just disappear without formally ending 
> the relationship with the GP or they never had a formal relationship. 
> Tourists for example. A GP is not interested in seeing persons in a listing 
> which are not his active patients.
> 
> I once, some years ago, helped facilitating archiving those patients data, so 
> they could be they physically removed from the GP information system. Also 
> here was no "deleted" marker necessary.
> 
> The only situation I can think of that requires a "deleted" marker is when a 
> information system is used for historical data research together with active 
> clinical use..
> 
> Maybe a standard should not facilitate such combination of use cases in a 
> single data storage information system.
> When historical research is needed one should query the archive system.
> 
> Bert
> 
> 
> Op za 4 nov. 2017 13:16 schreef GF <gf...@luna.nl <mailto:gf...@luna.nl>>:
> My two cents.
> 
> Two data collections are involved: Patient registry, Patient Health Record.
> I focus on the Patient Health Record.
> 
> 0- Committed data is never physically deleted.
> 
> 1- Inactive. 'Copy of data'.
> EHR with patient records.
> The patient moves to an other place and chances Healthcare Provider.
> A copy of the EHR is sent to that HcP.
> The original becomes inactive and can be consulted for legal, administrative 
> purposes, only.
> The Patient record is labelled: inactive, read only for legal and 
> administrative reasons
> 
> 2- Inactive. ‘Removal of data’
> The patient demands by force of law that all personal and health data is 
> removed.
> The EHR becomes inactive and can only be consulted for legal, administrative 
> reasons
> The Patient record is labelled: inactive, read only for legal and 
> administrative reasons
> 
> 3- Active: Updating of data by third party (patient)
> The patient demands a change in the data recorded.
> Data recorded after one or more events are changed.
> The original Compositions stay un altered.
> A new version of the Composition (with the patient as author) is created.
> 
> 4- Active, Update by original author
> New facts indicate that previously entered data about an event was incorrect. 
> The mistake needs to be corrected.
> A new version of the Composition is created.
> Old data can be acted upon. The application needs to redress this fact.
> 
> 5- Update before a Commit.
> During data entry but before the Commit data can be changed always. 
> Versioning is NOT necessary.
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 3 Nov 2017, at 13:49, Thomas Beale <thomas.be...@openehr.org 
>> <mailto:thomas.be...@openehr.org>> wrote:
>> 
>> It's potentially not a completely wrong idea: it might be worth thinking 
>> about a 'deleted' marker on the VERSIONED_OBJECT type itself. As i noted 
>> before though, i'd like to get a better idea of real scenarios where the 
>> current model of deletion doesn't work properly before doing anything.
>> 
>> - thomas
>> 
>> 
>> On 03/11/2017 02:36, Bert Verhees wrote:
>>> 
>>> In a versioned system there is no status for "deleted" necessary *inside* a 
>>> composition. The system itself marks the composition deleted. With this in 
>>> mind it seems to me the semantical meaning of the inside "deleted" status 
>>> is meant for something else.
>>> 
>>> Bert
>>> 
>> 
>> 
>> 

Re: Scenarios for change type "deleted"

[GF]

Small example.

As GP I had scanned early 1990’s to CD’s all ‘Green cards’, meaning patient 
records.
I can not remove these files on write-only media.
But logically they were removed because they were all archived and stored in a 
vault.
My EHR-system had no access to these scans.
All this might give frowns by the legal profession.

Logical deletion is possible at best.
Logical deletion means that that data no longer is actively used in health care 
provision processes.
Absolute and full Physical deletion many times is impossible, or not practical.


Gerard

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Nov 2017, at 11:43, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
> On Mon, Nov 06, 2017 at 11:38:23AM +0100, GF wrote:
> 
>> 2- Physical deletion is NOT ...
> 
> ... easy and often practically next to impossible.
> 
>> possible. During the life cycle
>> of data data collections are backed-up. This can be in write
>> once, read many times,  media. Sometimes complete databases
>> are replicated as back-up.
> 
> While true it draws blank stares from legal or political.
> 
> So we need to declare "deleted" to mean "deleted-as-much-as-possible".
> 
> Karsten
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

Hi,

There are several (5) realities:
1- that what is actually happening in the Patient System
2- that what is observed by the HcP/author (observables via senses)
3- subjective evaluation by HcP
4- that what is documented in the EHR patient record (Committed Composition)
5- the EHR Patient Record system

a- Each commit must be logged and never physically removed.
Committed Compositions are never physically removed 
Each is a legal act that needs to be documented and stored. Several other 
processes are connected such as: billing, (lega) reporting

b- The status of Committed Compositions can change (from active to not-active, 
cq readable to not-readable)
In other words the Access Control status is changed.
A change in a Care Plan as part of the Patient System is documented via a 
superseding new Committed Composition indicating the termination of the process 
 that is a a Care Process Plan.
It will be a new update, as a new version, of the Committed Composition that is 
about the Care Process Plan.
Nothing can/must be 'logically deleted’, a new status must be documented.

c- When patients demand the removal of all data the Patient record is declared 
in-active or its Access Control List is changed such that only the patient has 
controlling access rights.

d- When specified Committed Compositions are ‘removed’ as requested by the 
Patient these wil be declared iin-active or its Access Control List is changed 
such that only the patient has controlling access rights. 

e- In-active means that the data can NOT be used for the provision of Health 
Care; it can be used for administrative or legal purposes. Logging is one of 
the legal/administrative needs.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Nov 2017, at 15:39, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> For the first scenario, changing a care plan, or stopping it, I wouldn't 
> think of calling it logical deleting it but bring it into another state: 
> stopped, or something like that.
> 
> The second is in fact physical removing it from the Ehr and then saving it 
> somewhere in some form. In the openehr standard is, as far as I know not a 
> facility to do this. In fact the second scenario is, as I see it, from the 
> openehr point of view the same as the third.
> 
> Bert
> 
> 
> Op ma 6 nov. 2017 15:11 schreef Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>>:
> 
> 
> On 04/11/2017 18:38, Bert Verhees wrote:
>> But also apart from that. The discussion is if a standard should facilitate 
>> an inactive patient (logical deleted) to still remain in the active clinical 
>> information system with a special flag or that he should be transferred to 
>> an archive system. This is the question which is important to decide if a 
>> standard should define a "deleted" flag.
>> 
>> I think such a flag is a technical flag to organize some way of archiving 
>> data. It has no additional semantic meaning and should not belong in a 
>> standard defining semantic structures.
>> 
> 
> just to be clear, we are talking about (at least) 3 different things:
> logical content deletion, e.g. I want to 'wipe out' my second homeopathic 
> Care Plan that is no longer relevant because I stopped believing in homeopathy
> archival of EHR: I want to move the EHR to an archive system that allows 
> access, querying (or at least extraction), but separate from operational EHRs
> physical deletion of EHR from entire system: nuke this EHR
> The delete marker in the current model only applies to the first one. 
> To support archival, we need to know what we think the archival workflow will 
> be. Let's say we defined that, then I can imagine adding a new Boolean flag 
> to EHR_STATUS called e.g. archived or ready_for_archival or similar. THis 
> flag would prevent the system from 'seeing' the EHR even if it was not yet in 
> the physical archive, and it would enable an archival admin process to know 
> that it really can archive this EHR. When you think about it, a flag won't be 
> enough, it needs to be some sort of signed 'consent for archiving' concept.
> For the third scenario, another flag may make sense like 
> 'ready_for_deletion', but again, we need to study the needed workflow in 
> detail to really know what changes to the models are needed.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>___
> openEHR-

Re: Scenarios for change type "deleted"

[GF]

Restricting the reading, and processing, for use outside the provision of 
healthcare or labelling it as restricted NOT for use in healthcare are two 
alternatives for ‘Logical Deleting’.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 7 Nov 2017, at 11:48, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
> On Tue, Nov 07, 2017 at 10:51:42AM +0100, GF wrote:
> 
>> c- When patients demand the removal of all data the Patient
>> record is declared in-active or its Access Control List is
>> changed such that only the patient has controlling access
>> rights.
> 
> Given the fact that ACLs are ephemereal in many sorts of ways
> I can easily understand the desire for physical deletion (but
> I agree with you that it is next to impossible under many
> circumstances).
> 
> Best,
> Karsten
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

Always it is possible to cheat whatever.

But it nneds a criminal mindset to do just that. what one is not supposed to do.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 7 Nov 2017, at 17:25, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
>> Restricting the reading, and processing, for use outside the provision of 
>> healthcare or labelling
>> it as restricted NOT for use in healthcare are two alternatives for ‘Logical 
>> Deleting’.
> 
> Sure. But.
> 
> What isn't there can't be breached.
> 
> What is, will be.
> 
> Karsten

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

How is ‘ removal’ defined?
In my thinking, it means the right to have data labelled such that is NOT used 
in the provision of healthcare.

Copies made in the past, can not easily be removed, all the times.
Data shared with third parties can not easily be removed.
Data that is acted upon, can not easily be removed. 
Data that is re-used for administrative purposes or legal reporting can not 
easily be removed. Think of use of data in legal proceedings, used for 
administrative purposes, data logged in the log-file.

The law and its regulations (based on EU law) can write what they like.
Reality, technology, choices made in the past, will never change in the sense 
that all data can physically be removed.
At best it is removed logically and locally, meaning it is not allowed to play 
a role in the provision of healthcare in the future.
That is and stays my opinion.

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 7 Nov 2017, at 18:15, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> I just received ab email about this.  In Dutch from the Dutch Authority 
> Privacy (Autoriteit Persoonsgegevens )
> 
> The DPIA mentions very explicitly right on correction and right on removal. 
> Else the system owner will be fined. It is European law.
> 
> No room for discussions or ethical considerations. Just law. The KNMG, Royal 
> Dutch Society for Medical Affairs states the same.
> 
> They do not say logical or physical removal, they just say removal. If I was 
> responsible. I would know how to be sure to do the right thing. I guess 
> everybody else also knows what to do.
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

I do NOT dispute what patients can demand.

Under all circumstances it is the author that is accountable for his actions.
Even under Dutch Business  law one needs to keep files for the Revenue Tax) 
offices.

What is meant by the Privacy Law is that all data must be logically be 
‘removed’.
All health data must NOT show up.
All business transactions need to be preserved.
All accountable actions can be questioned in Public and Criminal law.

Meaning, in my view, that the patient record is there but unavailable for the 
provision of health care.
Meaning that either that record is tagged as ;inactive’ or the that the reading 
and writing rights are for the patient only.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 4 Nov 2017, at 21:17, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Gérard, I think you are wrong. A patient in the Netherlands can require under 
> specified conditions total physical and logical removal of his data from a 
> health care information system . 
> 
> If you want I can represent you a link to the law - text which says so, but 
> because that is in Dutch, and therefor not readable for others, and also not 
> interesting for others I rather take that communication to private level 
> instead of public discussion group level.
> 
> Best regards
> Bert Verhees 
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

[GF]

(Health) Data never must be physically deleted.
Facts happen and are recorded.
But not always readable.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 4 Nov 2017, at 21:38, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> But also apart from that. The discussion is if a standard should facilitate 
> an inactive patient (logical deleted) to still remain in the active clinical 
> information system with a special flag or that he should be transferred to an 
> archive system. This is the question which is important to decide if a 
> standard should define a "deleted" flag.
> 
> I think such a flag is a technical flag to organize some way of archiving 
> data. It has no additional semantic meaning and should not belong in a 
> standard defining semantic structures.
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Question about periodic interval events

[GF]

Hi,

I perceive the need to change/improve the OpenEHR spec because of this 
discussion.

What is the interpretation by Thomas?

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jun 2018, at 04:17, Pablo Pazos  wrote:
> 
> Hi Gerard,
> 
> On Sun, Jun 24, 2018 at 4:04 AM, GF mailto:gf...@luna.nl>> 
> wrote:
> See below
> 
> GF
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 24 Jun 2018, at 01:49, Pablo Pazos > <mailto:pablo.pa...@cabolabs.com>> wrote:
>> 
>> Hi Gerard,
>> 
>> On Sat, Jun 23, 2018 at 6:58 PM, GF mailto:gf...@luna.nl>> 
>> wrote:
>> When one assumes that the all events are the same kind of events but 
>> occurring at various points in time,
>> 
>> That is what is supported by the openEHR spec, no need to assume. All EVENTs 
>> in HISTORY.data are of the same type ~ have the same definition in the 
>> archetype.
>> 
>> 
>> Then the period can be expressed as Frequency (n/T) or equally as Period 
>> n/F).
>> 
>> Where n=number of events and T= total time from begin of the first event 
>> till the last (E.1 - E.n)
>> Clinical example:
>> Heart rate = 120 beats per minute.
>> 
>> Or as Period (T=n/F) expressed as time units that is the time between two 
>> events.
>> Clinical example:
>> Period between heart beats =  60/120 = 0,5 seconde. I.E the time between 
>> E(n+1) - E(n)
>> 
>> In your example
>> Period =  1 divided by Time (E2.start - Time E1.start),
>> or, Period = 1 divided by Time(E3.start) - Time(E2.start)
>> or, Period = 2  divided by Time (E3.start - Time E1.start)
>> 
>> This works with POINT_EVENT, my question is about INTERVAL_EVENT from the 
>> openEHR specs, where each event start and end are different.
> 
> Any Event (process) has an end date and start date an can be small but never 
> zero.
> End dates are always different from start dates.
> So what do you mean?
> 
> I'm talking about openEHR events by the definition of the specs, not trying 
> to come up with another definition. In openEHR POINT_EVENT is the record of 
> an event that to the record is just a point in time, doesn't really matters 
> if in reality the event took 10 seconds to execute, like a BP reading. That 
> is not clinically relevant in most contexts.
> 
> 
>> 
>> By openEHR, the heart rate EVENT is one single measure of the hear rate, 
>> there is no record of individual beats.
> 
> Its meaning can be several things.
> It can be the rate (frequency) at a real point in time. Time=T e.g. now, 
> yesterday.
> Or it can be the average over a period of time.e.g. the last minute,the last 
> 10 minutes, the last month.
> Actually it is a little bit more complex.
> 
> 
> Again, I'm following the spec definitions, not trying to create my own 
> interpretation. In that context, current models of heart rate, and current 
> information model structure for OBSERVATION don't try to model individual 
> beats, an EVENT is not that, is the consideration of the beat rate as one 
> data point.
> 
> Then the period that I'm talking about is the HISTORY.period by the openEHR 
> specs, that affect EVENTs in the same OBSERVATION time series. That is not 
> clearly defined in the specs (going back to my original question).
> 
> 
>> What would make an INTERVAL_EVENT from heart rate, is to record the average 
>> heart rate in an hour.
> 
> Frequency at point in a Unit Time.
> 
> Not sure that I'm following. INTERVAL_EVENT by the openEHR specs is not that. 
> It allows to record a summarized value from an interval of time, e.g. average 
> (or max, or min, or mean, ...) heart rate in the last 10 minutes.
> 
> 
>> And a periodic list of INTERVAL_EVENTs, would be records of the average of 
>> the heart rate that happen periodically. The issue I'm having is the specs 
>> don't have a concrete definition of "period" for INTERVAL_EVENT series.
> 
> INTERVAL–EVENTs as interval between events measured over a period of time.
> 
> What is NOT defined?
> 
> This is not correct, check the spec: 
> http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_history_package
>  
> <http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_history_package>
> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-tech

Re: Question about periodic interval events

[GF]

When one assumes that the all events are the same kind of events but occurring 
at various points in time,

Then the period can be expressed as Frequency (n/T) or equally as Period n/F).

Where n=number of events and T= total time from begin of the first event till 
the last (E.1 - E.n)
Clinical example:
Heart rate = 120 beats per minute.

Or as Period (T=n/F) expressed as time units that is the time between two 
events.
Clinical example:
Period between heart beats =  60/120 = 0,5 seconde. I.E the time between E(n+1) 
- E(n)

In your example
Period =  1 divided by Time (E2.start - Time E1.start),
or, Period = 1 divided by Time(E3.start) - Time(E2.start)
or, Period = 2  divided by Time (E3.start - Time E1.start)

Where in the OPENEHR specs can I find Frequency?
When we document we talk about numbers but often in qualitative terms?
What is the complete list of terms to describe these things using a 
classification?

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 23 Jun 2018, at 21:35, Pablo Pazos  wrote:
> 
> Hi all,
> 
> As usual I'm reading the specs and have a question about periodic interval 
> events.
> 
> I'm not sure how the period is calculated in a series. Let's say we have 
> interval events on a time line:
> 
> ---E1.start___E1.end--E2.startE2.end---...
> 
> Note: interval events can have different durations.
> 
> Is the period calculated from E1.start to E2.start or from E1.end to E2.start?
> 
> This is of course to know when E3 should start.
> 
> Thanks!
> 
> --



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

Re: Question about periodic interval events

[GF]

See below

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 24 Jun 2018, at 01:49, Pablo Pazos  wrote:
> 
> Hi Gerard,
> 
> On Sat, Jun 23, 2018 at 6:58 PM, GF mailto:gf...@luna.nl>> 
> wrote:
> When one assumes that the all events are the same kind of events but 
> occurring at various points in time,
> 
> That is what is supported by the openEHR spec, no need to assume. All EVENTs 
> in HISTORY.data are of the same type ~ have the same definition in the 
> archetype.
> 
> 
> Then the period can be expressed as Frequency (n/T) or equally as Period n/F).
> 
> Where n=number of events and T= total time from begin of the first event till 
> the last (E.1 - E.n)
> Clinical example:
> Heart rate = 120 beats per minute.
> 
> Or as Period (T=n/F) expressed as time units that is the time between two 
> events.
> Clinical example:
> Period between heart beats =  60/120 = 0,5 seconde. I.E the time between 
> E(n+1) - E(n)
> 
> In your example
> Period =  1 divided by Time (E2.start - Time E1.start),
> or, Period = 1 divided by Time(E3.start) - Time(E2.start)
> or, Period = 2  divided by Time (E3.start - Time E1.start)
> 
> This works with POINT_EVENT, my question is about INTERVAL_EVENT from the 
> openEHR specs, where each event start and end are different.

Any Event (process) has an end date and start date an can be small but never 
zero.
End dates are always different from start dates.
So what do you mean?

> 
> By openEHR, the heart rate EVENT is one single measure of the hear rate, 
> there is no record of individual beats.

Its meaning can be several things.
It can be the rate (frequency) at a real point in time. Time=T e.g. now, 
yesterday.
Or it can be the average over a period of time.e.g. the last minute,the last 10 
minutes, the last month.
Actually it is a little bit more complex.



> What would make an INTERVAL_EVENT from heart rate, is to record the average 
> heart rate in an hour.
Frequency at point in a Unit Time.


> And a periodic list of INTERVAL_EVENTs, would be records of the average of 
> the heart rate that happen periodically. The issue I'm having is the specs 
> don't have a concrete definition of "period" for INTERVAL_EVENT series.

INTERVAL–EVENTs as interval between events measured over a period of time.

What is NOT defined?



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

Re: Quantities of arbitrary units in openEHR

[GF]

Ia gree with Diago.

UCUM basicly is a terminological system.

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jan 2018, at 09:41, Diego Boscá <yamp...@gmail.com> wrote:
> 
> I think there are several potential problems with this, and IMHO we are 
> stepping too much on what should be done in a terminology service (We are 
> literally talking about a 'public available UCUM service'). You can also ask 
> the terminology service what kind of unit code you have. Your implementation 
> could answer "arbitrary" for these new units.
> 
> In my opinion, saying "here comes a mass unit code" is not much different 
> from "here comes a diagnosis code", and we say these in a completely 
> different way (a better way, if you ask me).
> 
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
> of terminology code that is potentially dangerous as knowledge or terminology 
> advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' 
> all mixed up. That's why I also expect these properties to be as derived from 
> the codes and not the other way around.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Quantities of arbitrary units in openEHR

[GF]

Semantic Interoperability is possible only when each. distinct domain:
has its own model
has its own rules
and always orthogonal to other models.

A terminology can be equated to a Dictionary.
A terminology is never an Encyclopedia of everything.

We need a terminology of concepts related to the Patient System.
And we need a terminology for things not related, such as Units of Measurement.
There will be more terminologies we need: basic archetype patterns for 
documentation, time-related concepts, medical devices, continuity of care, 
business modelling, etc.

So I agree with Thomas.
SNOMED must have bounderies.
I fear that the SNOMED world is without a well defined scope.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jan 2018, at 10:00, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> The thing I am not a fan of is that units themselves become part of 
> terminology. This is a SNOMED direction but I think a wrong one. The reason 
> is that the ontology of units isn't the same as the ontology of findings, 
> medications and so on. In fact they all have different ontologies, and trying 
> to jam them all into SNOMED CT under a single meta- model is problematic at 
> best. 
> But units are so clearly different that they deserve their own service - for 
> a start, UCUM unit strings are post-coorindatable according to the UCUM 
> grammar, and then you have the classification of units under properties, 
> synthetic properties under basic properties, strange stuff currently called 
> 'arbitrary' (which is still real, and must have a place inside the ontology); 
> units conversion rules and algorithms and so on. 
> So while a mass unit code like 'kg' might not see much different for a code 
> for pneumonia, even this simple example is already a pre-coordination of 'k' 
> and 'g' according to a units ontology, something that clearly doesn't apply 
> to 'pneumonia', at least not in the same way (i.e. 'viral pneumonia' is a 
> particular that is described by a disease ontology).
> 
> Thinking a bit more about 'arbitrary', I think I agree with Diego - to sort 
> it out properly needs a proper ontology.
> 
> - thomas
> 
> On 26/01/2018 08:41, Diego Boscá wrote:
>> I think there are several potential problems with this, and IMHO we are 
>> stepping too much on what should be done in a terminology service (We are 
>> literally talking about a 'public available UCUM service'). You can also ask 
>> the terminology service what kind of unit code you have. Your implementation 
>> could answer "arbitrary" for these new units.
>> 
>> In my opinion, saying "here comes a mass unit code" is not much different 
>> from "here comes a diagnosis code", and we say these in a completely 
>> different way (a better way, if you ask me).
>> 
>> Also, I'm not a big fan of "arbitrary" property, as feels like a "other" 
>> kind of terminology code that is potentially dangerous as knowledge or 
>> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of 
>> measurements' all mixed up. That's why I also expect these properties to be 
>> as derived from the codes and not the other way around.
>> 
> 
> -- 
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com/>
> Consultant, ABD Team, Intermountain Healthcare 
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation 
> <http://www.openehr.org/>
> Chartered IT Professional Fellow, BCS, British Computer Society 
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog 
> <http://wolandsothercat.net/>___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[GF]

Hi all,

In my opinion there are several types of ‘patterns’:

- Specific Local Templates/patterns used in a defined community for specific 
purposes
- Specific Clinical Models/patterns for things like: the documentation of 
lab-test forms/panels, collections of meta-data for documentation of specific 
observations/test for abdominal complaints, etc.
- Generic Clinical Patterns for things like: any lab panel, address, any device 
meta-dataetc.
- Basic Patterns for things like: any observation, any evaluation, any order, 
any action, and any process, and their full epistemology, etc.
- Atomic Patterns for those standardised constructs making use of Data Types 
and that are used to construct the patterns above such as: types of Result, 
types of temporal meta-data, etc.

Is this classification of Patterns useful? 

My SIAMM is about the last three patterns and NOT about specific local 
templates and specific clinical models.
Each consists of a limited and manageable set of patterns.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 16 Feb 2018, at 00:20, Heather Leslie 
> <heather.les...@oceanhealthsystems.com> wrote:
> 
> Hi Bert,
> 
> Unfortunately pattern by itself won't result in good archetypes. Mind you, I 
> think the RM classes are brilliant and they have been the cornerstone for our 
> modelling experience. In fact I suspect that the lack of these classes is a 
> large part of the reason why other modelling paradigms such as CIMI have not 
> been able to progress as far and as fast they had wished. 
> 
> Clinical medicine is messy, by definition. Our experience is that we often 
> identify patterns and then we routinely come across as many examples that 
> break those patterns. The slow progress that results is the result of 
> refining those patterns to work as universally as possible in the clinical 
> scenarios and how to deal with apparently outlying data points.
> 
> Then you need to consider clinical diversity that takes into account the 
> range of clinicians; differing professional requirements; differing 
> professional levels of details; needs of specialists vs generalists; clinical 
> context; institution and location; cultural differences; language 
> differences; personal health records; requirements for public health and 
> research I could go on. We need to identify what a concept is and the 
> appropriate scope; ensure minimising overlap as well as minimising gaps 
> between concetps. Good archetype design is just not as simple as what you 
> yearn for, despite how logical it seems to you. Our job would be much easier 
> if it were so.
> 
> The only practical way forward is to start with good representations of 
> clinical data and then get broad review from ALL experts - to ensure that the 
> clinical data is fit for use as well as to ensure that they are implementable.
> 
> As CKM Editors we try to get developers involved in reviews but they are 
> often in the minority - not because they are not invited but mostly because 
> they don't respond. We have a large list of technicians who were part of the 
> companies who funded the original openEHR sprint. Some responded immediately 
> with 'Accept' just to try to accelerate the archetype to get a published 
> state. Most ignore the invitations to participate. DIPS engineers have been 
> the most consistent participants and many modifications in archetypes arose 
> from their participation in reviews - this has reflected their requirements 
> for clinical content as well as their suggestions regarding the technical 
> implications of the archetype design.
> 
> The adverse reaction archetype is a case in point - eventually we had 221 
> reviews from 92 individuals in 16 countries PLUS an unknown number of 
> participants from HL7 Patient care and FHIR communities. Health 
> informaticians and IT experts comprised at least a third of reviewers - 
> engineer engagement to this level is not our usual experience and if my 
> memory is correct, most of the technical input came from the HL7 community, 
> not openEHR.
> 
> Patterns have been identified and more are being refined... but don't expect 
> them for all concepts, there will always be lots of unique models. 
> Representing data that real clinicians can use will not be solved by patterns 
> alone. Engaging clinicians is critical. Ontologies are useful but don't 
> necessarily cater for the entire reality that is clinical practice. Engineer 
> review and input would be much appreciated if it were available.
> 
> Why don't you agitate to get more engineers participating in the reviews? I 
> would gladly invite anyone who is willing to engage. Get them to adopt an 
> archetype today and join in the collective effort - the resulting archetypes 

Re: Archetype pattern

[GF]

I agree that the different kinds of ‘templates’ show up in different parts of 
the RM.
But we need to think more.


All are ‘patterns’ of different kinds.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 16 Feb 2018, at 12:41, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> in openEHR terms...
> 
> On 16/02/2018 05:38, GF wrote:
>> Hi all,
>> 
>> In my opinion there are several types of ‘patterns’:
>> 
>> - Specific Local Templates/patterns used in a defined community for specific 
>> purposes
> 
> specialisations of any archetype for local usage.

Templates used to define an active interface in a specific context

> 
>> - Specific Clinical Models/patterns for things like: the documentation of 
>> lab-test forms/panels, collections of meta-data for documentation of 
>> specific observations/test for abdominal complaints, etc.
> 
> COMPOSITION archetypes, probably some SECTION archetypes

I think these will be sometimes SECTIONS,  ENTRIES or perhaps CLUSTERS



> 
>> - Generic Clinical Patterns for things like: any lab panel, address, any 
>> device meta-dataetc.
> 
> all the ENTRY archetypes

Generic CLUSTERS


> 
>> - Basic Patterns for things like: any observation, any evaluation, any 
>> order, any action, and any process, and their full epistemology, etc.
> 
> ENTRY part of RM

ENTRIES

> 
>> - Atomic Patterns for those standardised constructs making use of Data Types 
>> and that are used to construct the patterns above such as: types of Result, 
>> types of temporal meta-data, etc.
> 
> Data types and atomic generic Data structures part of RM.

DataTypes. Anything other than DataTypes are CLUSTERS


> 
> - thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

[GF]

Hi,

In order to reach full interoperability and interpretability we need a clearcut 
separation between constituting models that are part of the Interoperability 
standards stack.
It is the function of a Terminology to create a system of concepts that 
coherently defines concepts in a domain.
And that is and must be the only function of SNOMED.

When it comes to queries we need to take into account data values in a context, 
the epistemology.
SNOMED will NEVER be able to model, contain the full temporal and spacial 
epistemology.
That context/epistemology is defined by meta-data in COMPOSITION that as 
committed to databases and documents.
In addition the world of databases is the domain of what is called the Closed 
World Assumption and Terminologies like SNOMED are part of the Open Worlds 
Assumption domain.
Mixing these two creates severe problems.

So I oppose the thought to crate search engines in the SNOMED Terminology 
domain.
CIMI has adopted this fines, sharp divide between the worlds of Archetypes and 
Terminology.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 17 Feb 2018, at 08:57, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> Hi, sorry to interfere, if II understand well,
> 
> I think a possible problem could be that respiratory infection caused by a 
> virus can return some derived codes to be returned although in this case it 
> are not so many.
> 
> However to use this mechanism generally, it can happen that really many 
> derived codes will be returned from the SNOMED engine, and in that case the 
> AQL query would need to be executed many times. Once for each possible 
> derived code.
> 
> One could also consider to hand over the result set from AQL to the SNOMED 
> engine to see if it is derived, which could cause less executions.
> 
> But in both cases it is datamining which is always difficult to estimate what 
> the best strategy in a specific case is.
> 
> A good idea maybe to design an intelligent query-strategy-decision engine 
> which offers advice to see what works best. This engine could execute limited 
> queries, for example, with a count operator so that it does not need to go 
> all the way when a limit is reached.
> 
> It is true what you write that datamining queries seldom are expected to 
> return in real time, but I have seen situations in marketing were they ran 
> for hours and queried almost one million dossiers, we even created in between 
> databases.
> 
> That decision engine could also be an external service.
> 
> It is good to hear that you think about separated services anyway. That works 
> in the advantage of a microservices architecture.
> 
> Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

Is it an idea to annotate nodes with instructions for display.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 18 Feb 2018, at 15:16, Erik Sundvall <erik.sundv...@liu.se> wrote:
> 
> This is an Interesting topic!
> 
> Standardised methods for representing application GUI behaviour/appearance in 
> an open vendor neutral way is one of the few still missing pieces in the 
> openEHR ecosystem needed in order to avoid vendor lock in.
> 
> Some clever choise of split point is likely fruitful since some parts are 
> closer to openEHR data/query definitions and some will be closer to 
> GUI-implementation/visualisation/layout frameworks (like Angular etc) that 
> should likely not be reinvented by openEHR but that (sometimes at an annoying 
> speed) keep changing versions and popularity faster than the RM/AM/AQL 
> related data definition framework should...
> 
> When designing this, perhaps some (2-5) existing currently popular GUI 
> frameworks could be initial targets for output from the process, and the 
> selection could be updated over time. Perhaps for example https://angular.io/ 
> <https://angular.io/> and https://reactjs.org/ <https://reactjs.org/> are two 
> starting candidates for experimentation? (Both have partially declarative 
> design, but other suggestions are of course welcome) Then mechanisms in those 
> platforms could be reused rather than reinvented.
> 
> Also looking at the things done in the format used/shared by Marand and DIPS 
> is an interesting input for gathering requirements.
> 
> //Erik Sundvall
> 
> sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>>:
> 
> 
> On 17/02/2018 20:11, Pablo Pazos wrote:
> > I think SET has a lot of applications, including result
> > sets. Of course that should interior from LOCATABLE to be archetypable.
> >
> > I'm not sure on the types associated with the UI. I have a
> > specification for UITenplates that includes some of that, I can share
> > it :)
> >
> 
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
> 
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works,
> something like Balsamiq but with real data connections built in.
> Marand's EhrExplorer does some of this, and it would also be useful to
> extract some of the semantics of that tool into a standard specification
> to support this kind of thing.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> -- 
> Sent from mobile.
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

Is there a terminology with concepts we can use to annotate?
Probably there is and there are more.
Which one, will be the question.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Feb 2018, at 07:00, Erik Sundvall <erik.sundv...@liu.se> wrote:
> 
> 
> sön 18 feb. 2018 kl. 23:10 skrev GF <gf...@luna.nl <mailto:gf...@luna.nl>>:
> Is it an idea to annotate nodes with instructions for display.
> 
> Yes, using (mostly shared/standardised) annotations for GUI-rendering hints 
> in templates (or layers of templates) has been a major idea in previous 
> GUI-related discussions in openEHR mailing lists. 
> 
> //Erik
> 
> (We should link to some old list posts on the topic in that wiki page Tom 
> created)
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Feb 2018, at 12:07, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> note that a key problem I want to address is that templates based on 
> COMPOSITIONs don't really make sense as models of data retrieval/display 
> forms - they are really only useful for data capture forms (or messages, or 
> documents), because COMPOSITION is a container for committing data to the 
> EHR. 
> 


Or any interface be it for committing, querying, display, data entry, 
documents, messages, clinical decision support interactions?
These all can be dedicated kinds of Template/Interface
> Displaying data is a different question - it may be EHR data, it may be 
> demographic data, and it may be something else entirely. So the data items we 
> want to mention in templates are mostly of ENTRY level, and will be the 
> results of queries; the relevant queries could be included in such templates. 
> 
> So the starting point for many forms won't be a COMPOSITION - it is instead a 
> different logical container that groups data that result from one or more 
> queries, into a 'use group', i.e the group of data items intended to be 
> visualised or used as a report etc.
> 
> 

Unless the COMPOSITION is the description of any interface.

> One problem today is that people trying to define screens for visual 
> applications are forced (more or less) to create templates starting with 
> COMPOSITIONs, which is incorrect; my impression is that such templates are 
> only used for data capture and that other display forms are modelled in 
> various non-standard ways, or not at all.
> 
> I think annotations (based on paths) will be useful, but I not completely 
> adequate to achieved what is needed.
> 
Why?


> - thomas
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

Hi,

There is NO need for an other RM.

Templates (imo) describe an interface.
Templates for an interface used for display only need annotations in the 
appropriate nodes of the Display Archetype

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Feb 2018, at 10:29, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> On 19-02-18 10:21, Diego Boscá wrote:
>> Personally I would prefer if no visualization attributes ended up in the EHR 
>> RM, but I'm fine if we want to create an additional RM to handle 
>> visualization (and we create templates of that model that point to the EHR 
>> model)
> 
> I agree on this!
> 
> (again sloppy English in my previous message, this time changing the meaning, 
> I changed the quote below, I am awake now, will not happen again, excuse me)
> 
>> 
>> 2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl 
>> <mailto:bert.verh...@rosa.nl>>:
>> On 18-02-18 23:09, GF wrote:
>> Is it an idea to annotate nodes with instructions for display.
>> 
>> Personally I think having special templates/archetypes for display is 
>> better. Templates are created per purpose, and mixing purposes in a single 
>> template does not seem good idea to me
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Creating a terminology

[GF]

Hi,

It was designed using MindMap.
There is a version that expresses it as a set of archetype patterns based on 
AOL 1.4,
using an other modelling style that OpenEHR is using.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 22 Feb 2018, at 13:43, Darlison, Matthew <m.darli...@ucl.ac.uk> wrote:
> 
> Dear Gerard,
>  
> Many thanks – that’s interesting as an expression of the terminology, but I’m 
> guessing that was either generated from a machine-readable expression of the 
> terminology, or would need such a machine-readable version to exist before it 
> could be instantiated within a terminology server/service? I’m also 
> interested to try that out, so that other software might be able to 
> interrogate the resource…
>  
> Yours,
>  
> Matthew
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of GF
> Sent: 22 February 2018 12:23
> To: Thomas Beale <openehr-technical@lists.openehr.org>
> Subject: Re: Creating a terminology
>  
> Dear Matthew,
>  
> In the attachment a candidate terminology as PDF
>  
> It is known as SIAMM
> Semantic Interpretabily Artefact Modelling method
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
>  
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
> 
> On 22 Feb 2018, at 13:03, Darlison, Matthew <m.darli...@ucl.ac.uk 
> <mailto:m.darli...@ucl.ac.uk>> wrote:
>  
> Dear All,
> 
> I've been looking for some time for ways of injecting knowledge into the 
> ecosystem so that it is available to an EHR, but also to other systems that 
> might want to use it.
> 
> I currently think I need to create a terminology (or maybe more than one), 
> but I've found vanishingly few open tools and little guidance on what I could 
> use to do this, and experiment to see if it does what I need.
> 
> I'd be grateful for any advice... 
> 
> Yours,
> 
> Matthew
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Empty COMPOSITION.content is valid?

[GF]

In the archetype the amount of constraints must be minimal.
In the Template the amount of constraints must be optimal (maximal?)

Archetypes are generic patterns.
Templates are specific patterns.

Generic meaning to be used in all systems at all points in time.
Specific meaning to be used in a jurisdiction at a point in time.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 26 Jul 2018, at 10:46, Diego Boscá  wrote:
> 
> You would be surprised to the amount of legacy data with no clinical content, 
> just because original systems allowed it
> 
> El jue., 26 jul. 2018 10:41, Bert Verhees  <mailto:bert.verh...@rosa.nl>> escribió:
> On 26-07-18 09:57, Thomas Beale wrote:
> > Does it make sense to have an empty COMPOSITION.content?
> 
> Imagine a visit to a GP, and nothing clinical comes out of it. Nothing
> worth mentioning, but still having had a composition and a consult to
> pay for.
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: Drug dispense entry class question

[GF]

Hi,

Two process are presented:
- the process  of administering medication (as Action) to the Patient System 
and that is documented
- the process of fulfilling an Order (Prescription) issued by a Prescriber, 
where the Clerk hands over the Medication to the Patient System, and that is 
documented

Everything is about documenting what happens to the Patient System in the case 
of the EHR.

The first process is an ACTION_ENTRY in the context of the process of 
administering medication to the Patient System.
The second is an Order that is executed as an ADMIN_ENTRY as part of an 
Organisational process within the Pharmacy.
Both are nested processes starting with a Plan that can be documented, an Order 
as part of the plan; followed by the documented execution of the Order by the 
Clerk, and then the Action of applying the medication to the patient. Each of 
these steps have a set of possible states.

In my line of thinking I’ve used a set of Entries to model healthcare provision 
documentation generically:
- the generic Observation process using the ENTRY
- the generic Evaluation process using the ENTRY
- the generic Planning process using the ENTRY
- the generic Ordering process using the ENTRY
- the generic Action process using the ENTRY

Each of these can be applied in the context of the Patient System or the 
Organisational System one fixed attribute is used,
A de novo Evaluation result (e.g. diagnosis) is about the Patient System. The 
same diagnosis in a referral letter is done in an Administrative context

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 11 Aug 2018, at 21:03, Pablo Pazos  wrote:
> 
> Hi all,
> 
> How would you map a "pharmacy drug dispense" task, where the patient comes 
> with a prescription and a clerk delivers the medication packages?
> 
> I was thinking this is clearly and ACTION, but also seems to be an 
> ADMIN_ENTRY, since it is just a delivery of some product.
> 
> I'm inclined to think it as an ACTION if this task alters the state of the 
> prescription INSTRUCTION ISM. On this case, as a parallel question, I'm not 
> sure if the dispense ACTION should be a final "COMPLETED" state, what happens 
> if we want to record the patient's intake of the drug? Where the real 
> "COMPLETED" is when the treatment is finished.
> 
> What do you think?
> 



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

Re: post-coordination in openEHR

[GF]

Pablo,

I agree that there are special rules on how to use coding systems.

Only in specified domains at specified levels in ontology the pre- or 
postco-orinated codes can be used safely.

Without rules there will be overlap of ways to code in the archetype versus 
coding in the coding system.
This is the Boundary Problem.
It can be avoided by rules:
- refrain from using co-ordinated codes, except for anatomical structures
- create archetypes that allow to express all the pre/post-co-oriated codes
- all nodes in the archetype need to be coded using Reference Coding Systems 
(SNOMED, LOINC)

In my view the Archetype is the preferred way to express pre-/post coordinated 
terms.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 9 Aug 2018, at 23:10, Pablo Pazos  wrote:
> 
> IMO it means post coordinated stuff can't be used at design time in 
> archetypes. It can be used at runtime. For instance we use snomed expressions 
> embedded in openEHR queries to filter coded texts. In the archetype or 
> template that defines that coded text, there is only a binding with snomed, 
> nothing else.
> 
> On Thu, Aug 9, 2018, 09:21 Georg Fette  <mailto:georg.fe...@uni-wuerzburg.de>> wrote:
> Hello,
> Using terminology bindings it is posssible to bind terminology IDs of
> specific terminologies to archetypes as well as to their members. In the
> openEHR documentation it is written that there is no concept of
> post-coordination outside the terminology environment. What does that
> exactly mean ? When I have a post-coordinated expression, how do I use
> it within openEHR ? The linkage of an openEHR system to a potential
> terminology server is something that I do not yet unterstand very well.
> Greetings
> Georg
> 
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de 
> <mailto:georg.fe...@uni-wuerzburg.de>
> -
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: AQL on specific list of compositions

[GF]

Hi,

There is ample reason to reconsider the use and need for folders.

There is a need for holding/collecting structures.
The RM has several places where data can be collected:
- Folder
- Composition
- Section
- Entry
- Cluster

For what purposes?
What contributes to the meaning, the semantics?
What is for aiding the author / reader managing the data?

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 20 Aug 2018, at 10:53, Thomas Beale  wrote:
> 
> 
> 
> On 18/08/2018 07:56, Bert Verhees wrote:
>> I cannot imagine how a folder structure can get lost except by data 
>> corruption. In that case anything is lost anyway and a rollback from a 
>> backup is needed.
> 
> It's a thought experiment, not a serious proposition about a real system. But 
> it partially answers the question: what is in an EHR? If Folders contain some 
> extra information that can't be reconstructed by running specific queries, 
> then probably the Folders are a first order part of the EHR rather than just 
> an optimising data structure.
> 
>> 
>> In fact there should not be a folderstructure in the database. There are 
>> folder objects which contain a list of references (data) to compositions. 
>> Not the compositions itself are in those lists. That would not be possible 
>> because a composition can be referenced in more then one folder.
> 
> There can be a Folder structure (= hierarchy of Folders), even though (as you 
> say) Folders only hold refs to Compositions, and more than one Folder can 
> point to the same Composition.
> 
> - thomas



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

Re: AQL on specific list of compositions

[GF]

Hi Karsten,

ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of 
concepts related to care and its documentation.
It would be. a good thing to harmonise terms we use.
More info via: https://contsys.org <https://contsys.org/>

ContSys is NOT a Data model but a way to define concepts and there relations 
using UML.
It can/must inform the production of shared archetypes.

ENCOUNTER
Most certainly this is the case when a Healthcare Provider meets the patient 
and documents the care given.
Meeting can be real and virtual via telephone, e-mail, a third party

But there is an encounter when the HcP interacts with the EHR without a Patient 
(Virtually) present.

So ENCOUNTER, in my terms, is any interaction of an Author (HcP, Patient, third 
Party/Proxy) with the Patient Record.

The ISO standard System of Concepts for Continuity of Care uses the term and 
definition:
contact <https://contsys.org/concept/contact_period> perio 
<https://contsys.org/concept/contact_period>d-   healthcare activity period 
<https://contsys.org/concept/healthcare_activity_period> during which a contact 
<https://contsys.org/concept/contact> occurs

EPISODE
ContSys defines this as:
episode of care-health related period 
<https://contsys.org/concept/health_related_period> during which healthcare 
activities <https://contsys.org/concept/healthcare_activity> are performed to 
address one health issue <https://contsys.org/concept/health_issue> as 
identified by one healthcare 
<https://contsys.org/concept/healthcare>professional[

PROBLEM
In addition the term PROBLEM is used in the context of EHR’s.
ContSys has NOT defines this term.
The closest concept in ContSys is:
reason for demand of Care-  subject of care 
<https://contsys.org/concept/subject_of_care> or a subject of care 
<https://contsys.org/concept/subject_of_care> proxy's perception of health 
needs <https://contsys.org/concept/health_need> motivating a demand for car 
<https://contsys.org/concept/demand_for_care>e



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Aug 2018, at 13:20, Karsten Hilbert  wrote:
> 
> An Encounter (in community medicine) is very much different
> from an Episode of Care.
> 
> An Encounter happens when patient and healthcare system
> "meet" in some way, it is one-off. It can encompass a
> multitude of Reasons for Encounter, about different care
> targets.
> 
> An Episode of Care is a time range during which one
> particular care target is handled. It manifests itself during
> 1..many Encounters, each of which is about 1..many care
> targets (problems).
> 
> Karsten



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

Re: GDPR and OpenEhr.

[GF]

Lets be clear.
Each record of a patient is a unique traversal of the health and care system 
over time and therefor very much identifying the patient.

What we talk about is: the right to be forgotten and the circumstance that 
after a legal period the medical data must be destroyed in some countries.
The EHR 13606 is designed based on a set of medical-legal requirements.
I’m of the opinion that that set does not need an update because of the new 
privacy law.
When I’m mistaken I would like to be pointed at those missing requirements.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 5 Sep 2018, at 17:12, Bert Verhees  wrote:
> 
> On 05-09-18 11:15, GF wrote:
>> Thomas,
>> 
>> The record can stay where it was.
>> Only the connection of identifying patient data and the Record-ID needs to 
>> be encrypted.
>> De-encryption can take place using a key owned and provided by a notary 
>> public.
> 
> I don't think that is enough, Gerard, if the record contains DNA material, or 
> other identifying material.
> 
> A 1997 study showed that up to 87% of the U.S. population could be identify 
> with just zip code, birthdate and gender.
> A researcher was able to identify William Weld (Massachusetts Gov.) from 
> anonymous hospital discharge records.
> 
> Today this numbers will be much higher because clinical actions will be on 
> cell-phones and internet-browsers, and there is much more linked-information 
> about individuals.
> 
> Read this, very interesting:
> 
> https://www.forbes.com/sites/adamtanner/2013/04/25/harvard-professor-re-identifies-anonymous-volunteers-in-dna-study/#41635a6892c9
>  
> <https://www.forbes.com/sites/adamtanner/2013/04/25/harvard-professor-re-identifies-anonymous-volunteers-in-dna-study/#41635a6892c9>
> 
> An organization which has no business with your medical data should not have 
> access to them, not even historical clinical data.
> GDPR, were we all talk about, which is the thread of this message, is mainly 
> build around consent, but what is consent?
> 
> There should be more discussion about to get the understanding landing at 
> normal people:
> Click on the image, I found yesterday, to see more images:
> https://twitter.com/ianmthompson/status/1037276071002038272 
> <https://twitter.com/ianmthompson/status/1037276071002038272>
> 
> Bert



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

Re: GDPR and OpenEhr.

[GF]

Thomas,

The record can stay where it was.
Only the connection of identifying patient data and the Record-ID needs to be 
encrypted.
De-encryption can take place using a key owned and provided by a notary public.

All must be handled by the Patient-ID server and an official functionary that 
is equipped to manage keys in a trusted way.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Sep 2018, at 20:28, Thomas Beale  wrote:
> 
> I continue to wonder what will happen when a cancer patient (perhaps in a 
> moment of depression or disaffection with care) asks for the hard delete, 
> gets better, then has a recurrence a few years later. What does the health 
> system do when all the notes are really gone?
> 
> I think a better solution is to create a digital locked room when such EHRs 
> are put, one-way encrypted with a giant key provided by the patient. Then 
> when they have regrets, they can ask - nicely - for their record to come out 
> of cold storage.
> 
> Another argument against total deletion is that a) the state has invested in 
> helping sick patients and b) other citizens have a potential interest in 
> health records belonging to those in the same major disease cohort, i.e. 
> diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous deletions are certainly 
> going to compromise research that looks at longitudinal Dx v treatments v 
> outcomes. Perhaps perhaps permanent anonymisation is a better solution in 
> this case, with the original patient being given the new EHR id.
> 
> I think GDPR has some way to go yet in healthcare...
> 
> - thomas
> 



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

Re: Identifying archetype nodes in AQL via terminology code

[GF]

See below.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Sep 2018, at 10:42, Thomas Beale  wrote:
> 
> 
> In openEHR as it stands now, the answer would be no, because the 
> snomed-ct:263495000 code is just one binding to at0017. What is reliable in 
> the data is the at0017 internal code.
> 

Exactly.
For the data inside an EHR system the at0017 code is essential, the key thing.
But in terms of what it means for interpretation by humans and ‘intelligent’ 
services the SNOMED code is the key thing.

In essence OpenEHR/13606 binds Codes from Reference Terminologies to 
archetype/template structures inside EHR systems and messages or documents.
> In future, it is not out of the question that different types of OPTs would 
> be generated that would treat bound terminology codes as if they were the 
> structural ones, but this is probably a long way off. Some further ideas 
> about this in the ADL2 spec 
> <https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_terminology_integration>,
>  and also the OPT2 spec 
> <https://www.openehr.org/releases/AM/latest/OPT2.html>.
> 
> It also might not be hard to preprocess AQL queries written like this into 
> the standard form, but that would require that the code snomed-ct:263495000 
> be bound uniquely to at0017, and no other node code e.g. at0015. So doing 
> this would require stricter binding rules than we currently have, and which I 
> think are not semantically justifiable.
> 
> - thomas
> 
> 



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

Re: Identifying archetype nodes in AQL via terminology code

[GF]

In SIAMM every node can have any name/label.
Its meaning is carried in attached one or mode codes. One code that is required 
at minimal is from the set of Reference Coding Systems.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Sep 2018, at 10:33, Birger Haarbrandt  wrote:
> 
> Hi Georg,
> 
> currently, this is not possible directly using AQL. However, technically it 
> is possible to make a look-up within all archetypes to automatically retrieve 
> the elements (and their paths) that have a matching terminology-binding (for 
> example to the snomed code for gender). This path could then be used within 
> an AQL query which can use the code for "male". I actually was thinking about 
> building such a tool within HiGHmed make analytics quers more convenient, 
> though we are still searching for a developer.
> 
> Hope this answers your question,
> 
> Birger



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_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-clini...@lists.openehr.org>
> Kopia: Openehr-Technical <openehr-technical@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-clini...@lists.openehr.org 
> <mailto:openehr-clini...@lists.openehr.org>>
> Kopia: Openehr-Technical <openehr-technical@lists.openehr.org 
> <mailto:openehr-technical@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: Setting thresholds

[GF]

The metadata describing these interfaces with these services can be constructed 
using archetypes resulting in Template/Compositions.

Thomas: I know what BFO is.
But what stand RO ans IAO for?

Why must they be based on an ontology?
In the case of signalling/normal values, it will be simple: item-ID, Low value 
plus units, High value plus units, date of publication.

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

> On 01 Mar 2018, at 15:33, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> On 01/03/2018 11:05, Seref Arikan wrote:
>> Hi Diego,
>> 
>> I'd like to hear how you'd address the requirement via a call to an external 
>> service.
>> 
> 
> I don't think it should be that complicated - after all, a call out to a 
> terminology service is already a call out to a service; terminology is just 
> one kind of reference knowledge that a query language / engine needs to get 
> at; we can assume that a units service (as Bert and others were discussing 
> earlier), lab results reference ranges, drug DB and so on may all be needed 
> by the query service.
> 
> So I think it mainly comes down to the syntax and programming model of 
> talking out to such interfaces. We might potentially assume that they are all 
> based on a common ontology meta-model of some kind (e.g. based on BFO, RO, 
> IAO etc) in which case a common underlying style could be established.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

Yes, there might be a need for a service as external point of reference.
In spite of this data in the EHR needs to be suplemented with the actual 
reference ranges as provided by the service.
When we can agree that EHR systems in the future store not only the datapoints 
but the context info as well, then archetypes need to be able to store next to 
the datapoint the reference ranges as occured at the time of committing.
The additional services, most likely, will be part of the system, under the 
application control.

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

> On 01 Mar 2018, at 12:12, Diego Boscá <yamp...@gmail.com> wrote:
> 
> Assuming there is a service that provides the given value for a given 
> identified range (based on the parameters you provide like sex, age, race... 
> ) it would be allowing kind of namespaces that have defined operations. This 
> would also allow easy querying of external terminologies, public health 
> queries (average/max/min of X in population that has Y, Z, W properties), 
> etc. 
> 
> El 1 mar. 2018 12:06 p. m., "Seref Arikan" <serefari...@kurumsalteknoloji.com 
> <mailto:serefari...@kurumsalteknoloji.com>> escribió:
> Hi Diego, 
> 
> I'd like to hear how you'd address the requirement via a call to an external 
> service. 
> 
> I've been holding back on the recent external service calls discussions :) 
> there is certainly a need for that but it also has the potential to open a 
> can of worms and I'd better no hijack this thread ;)
> 
> On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá <yamp...@gmail.com 
> <mailto:yamp...@gmail.com>> wrote:
> I believe that we need a way in standard AQL to call to arbitrary external 
> services, this seems like another use case for that 
> 
> El 1 mar. 2018 11:46 a. m., "Seref Arikan" <serefari...@kurumsalteknoloji.com 
> <mailto:serefari...@kurumsalteknoloji.com>> escribió:
> Hi Colin, 
> See responses inline please
> 
> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <colin.sut...@ctc.usyd.edu.au 
> <mailto:colin.sut...@ctc.usyd.edu.au>> wrote:
> 
> 
>> On 1 Mar 2018, at 1:59 am, Seref Arikan <serefari...@kurumsalteknoloji.com 
>> <mailto:serefari...@kurumsalteknoloji.com>> wrote:
>> 
>> […]
>> 
>>> 
>>> 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
>> 
>> […]
>  In a clinical trial, the protocol may set thresholds for measurements in one 
> version of the protocol, then change the thresholds in a subsequent version 
> of the protocol. Since a decision may be based on a threshold level, the 
> threshold value needs to be retained along with the measurement for each 
> instance under each protocol. So I think you need a new template for each 
> protocol. 
> Yep, a new template for each protocol would be what I'd consider, as I 
> mentioned in another reply. Based on the information I heard so far regarding 
> the requirements and the specific example you provided here, I'd consider 
> associating thresholds with the identifier+version of the template for the 
> protocol: can you see any problems with this in the context of your specific 
> example? 
> 
> An AQL query on the threshold level will therefore need to have a unique name 
> for each threshold ( not a value of the threshold) in order to retrieve the 
> value used across protocols in the decision, for a simple case where the 
> decision alg

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

I will have to digest it.
I’ll be back.

GF

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 11:08, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
>  Some theory along these lines 
> <https://wolandscat.net/health-informatics/analytic-framework-for-health-information/>
>  is needed...
> 
> On 03/04/2018 08:35, A Verhees wrote:
>> 
>> GF :"There are NO agreed standardised archetypes/patterns we all use to 
>> define the meta-data in order to document the full eppistemology
>> so data can be interpreted fully and safely. "
>> 
>> 
>> So what do you suggest as a solution?
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

Can I understand that you file-guide are patterns that fit archetypes so 
Healthcare Providers can compose whatever they want.
The file-guides insertions are context driven.
The system of file-guides acts like an Ontology for clinical/administrative 
content.
Archetypes define how things are presented in a system-interface.


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

> On 05 Apr 2018, at 14:50, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Le 05/04/2018 à 12:16, Thomas Beale a écrit :
> 
>> On 02/04/2018 18:38, Philippe Ameline wrote:
>>> 
>>> Actually, I don't think that I use grammar in an unusual way. If I do it 
>>> technically, lets assume for the sake of the discussion that I am really 
>>> talking about a grammar, ie a set of rules that allows you to interpret an 
>>> arrangement of concepts as a discourse. Typically, a dependency grammar is 
>>> not just a tree representation, but a tree representation where you take as 
>>> a rule that the sons of an element qualify this element. Since every 
>>> natural language sentence can be represented as a dependency grammar tree 
>>> and vice versa, it is possible to assert that a dependency grammar is a 
>>> sufficient grammar.
>> 
>> Right - but the normal sense of 'grammar' is something that controls / 
>> validates sentences made up of words so at least they have acceptable 
>> structural forms, even if they say semantically nonsensical things. The fils 
>> guides 'grammar' is supplying both levels - correct form (by implication, 
>> due to ordering of tree elements as you pass through them) and valid 
>> semantics (due to the content of the tree elements, thus preventing 'colon 
>> of stenosis' but allowing the reverse).
> 
> Let's imagine that there is no fils guide.
> 
> A "patient record" is a graph of trees (means trees which nodes can be 
> interconnected by typed traits, either to connect the description tree that 
> implements a given document description tree, or to follow a given issue over 
> time, etc).
> 
> If you assume that this trees are organized as a dependency grammar and their 
> nodes are filled using an ontology, you don't need anything else to read it, 
> feed smart agents, etc. It is a story told using a structured language (ie a 
> grammar and an ontology).
> 
> Of course, as you mentioned, it is possible that it contains "wrong entries" 
> like "colon located at stenosis".
> 
> In the wild, it can be achieved by providing practitioners with just an 
> interface where they can freely express themselves by building trees (this is 
> the usual interface for encounter notes since it is fully non deterministic).
> Now, for many good reasons, we could want to guide the way (some/most) trees 
> are elaborated (to ease and speed up the process, to make certain that the 
> information we want to process will be "well put", etc).
> In deterministic areas, we can use archetypes. In semi-deterministic areas, 
> we can use fils guides (a flexible way to guess and propose the next "sons" 
> depending on current path).
> 
> In my mind, fils guides and archetype are of different kind: an archetype is 
> a flexible information schema and nodes that were "build using this mold" 
> keep a link to it ; on the contrary, a fil guide is nothing more than a UI 
> helper that makes a one step deep proposal (since, when validating a proposed 
> son, you now are on a different path (previous one + validated node) and the 
> system will try to find a fil guide for this path). Since the process is 
> fully dynamic and local to the user (depending on the set of fil guides he 
> uses) the nodes don't have to remember what fil guide they originate from.
> 
> To sum it up, you can have a journey walking in well known areas (archetypes) 
> and finding your way in the wild (tree filling interface). When in the wild, 
> you can sometimes be presented with a "step wide carpet" (Fil guide) that 
> helps you walk more comfortably (this process being iterative, you can 
> "follow the carpet as it unfolds", but can also head on in another direction).
> 
>> well maybe 'structural terminology' is a bad term; what I am really talking 
>> about is models of possible content (possible utterances).
> 
> I was mainly talking about the extra structural elements such as "Entry", etc.
> 
> Besides, if "models of possible content" are very important inside the 
> deterministic area, it would be pretty limited to have the only alternative 
> "model of free text". If only because, if you provide users with a structured 
> language, you

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

I understand Archetypes are discourse models and form a sentences
A collection of sentences (Entry Archetypes) form one story/session/Composition 
and define the content of a system-interface connected to a database, or 
screen, or other service like a messaging system.
In my terms: A Template consists of Entry Archetypes and is the content of a 
system-interface.
The Composition, Template, the system-interface are equivalent, but need the 
story, system-interface, Template must contain the data and its full context/ 
epistemology.
The Archetypes in my thinking are standardised patterns with which to construct 
an Entry archetype.

My hierargy becomes:

Ontology- Encyclopedia
Terminology - Dictionary
Cluster Archetype   - Standardised phrases/patterns
Entry Archetype - Clinical sentence including epistemology/context (collection 
of patterns)
Composition - Clinical story a Template with a collection of 
sentences/Entry archetypes

Queries can be for leave nodes to find in a Patient Record the datum. In order 
to interpret the datum fully and safely one must inspect the whole associated 
Entry and/or Composition, (depending on specifics)

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 14:38, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Le 28/03/2018 à 23:42, GF a écrit :
>> I see the analogies:
>> - Ontology   = Encyclopedia
>> - Terminology= Dictionary
>> - Archetype  = Phrase
> 
> Hi Gerard,
> 
> I would rather see Archetypes as "discourse models" that form a mold for 
> sentences or groups of sentences. The Phrase, in you enumeration, would 
> rather be the instantiated information (stored in database).
> 
> If you are curious about the way a tree of concept can be homogeneous to a 
> sentence, Google "dependency grammar".
> 
> This has been my main topic for 30 years in the report generation domain, and 
> I can say that "simply ordering information on a form" and "trying to tell 
> something using a structured vocabulary" are much different tasks. Typically, 
> the first approach concentrates on the leaves while the other makes certain 
> that branches give the proper meaning to the leaves.
> 
> Best,
> 
> Philippe
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

Fist of all: My ideas about modelling and using archetype, etc is not shared by 
OpenEhr

I agree that the tree is important.
My tree starts at Composition contaiining one of more Sections, and/or Entries.
The Entry models a process of one of these: data observation, data evaluation, 
data planning, data ordering and data about events/actions.
Each of these models deal with the full epistemology of that topic using 
standardised patterns/Clusters/Archetypes
That what is observed is a Cluster archetype that models the datum plus its 
context/epistemology.

What is important is the Modelling Style.
In OpenEhr the nodes of the Archetype are changed.
In my style, since I make use of predefined patterns I will not change the 
nodes but change the data in the Elements.
In my style of modelling querying the leaves is that what is done. The unique 
path defines its meaning.
In my way of modelling the collection of paths is a kind of ontology for data 
in healthcare records.




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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 17:25, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Le 30/03/2018 à 16:49, GF a écrit :
>> Philippe,
>> 
>> I understand Archetypes are discourse models and form a sentences
>> A collection of sentences (Entry Archetypes) form one 
>> story/session/Composition and define the content of a system-interface 
>> connected to a database, or screen, or other service like a messaging system.
>> In my terms: A Template consists of Entry Archetypes and is the content of a 
>> system-interface.
>> The Composition, Template, the system-interface are equivalent, but need the 
>> story, system-interface, Template must contain the data and its full 
>> context/ epistemology.
>> The Archetypes in my thinking are standardised patterns with which to 
>> construct an Entry archetype.
>> 
>> My hierargy becomes:
>> 
>> Ontology - Encyclopedia
>> Terminology  - Dictionary
>> Cluster Archetype- Standardised phrases/patterns
>> Entry Archetype  - Clinical sentence including epistemology/context 
>> (collection of patterns)
>> Composition  - Clinical story a Template with a collection of 
>> sentences/Entry archetypes
>> 
>> Queries can be for leave nodes to find in a Patient Record the datum. In 
>> order to interpret the datum fully and safely one must inspect the whole 
>> associated Entry and/or Composition, (depending on specifics)
> 
> Gerard,
> 
> I think that I get your point, though not being proficient enough in openEHR 
> details.
> 
> In my own universe, the basic information unit (as stored on disk) is a tree. 
> Each node of this tree being an element from the ontology, the tree is fully 
> autonomous and doesn't need external interpretation material.
> 
> For example:
> 
> Echocardiography
> Indication
> 
> Findings
> Mitral valve
> Doppler
> Mitral leak
> 
> 
> Hence, the "basic query unit" is not for leave nodes, but rather for a path ; 
> for example a query for "Echocardiography/Findings/Mitral valve" would return 
> a sub-tree.
> 
> But maybe you were saying this already.
> 
> Best,
> 
> Philippe
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

Pre-coordinated SNOMED codes are like classifications, in that they are used at 
the user level, the User Interface,
The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed in 
its constituents.
These decomposed primitive codes can be used in structures like archetypes at 
the proper places.
In this way the pre-coorodinated SNOMED codes are iso-semantic.

But we keep the semantic differences codes expressed  using the SNOMED ontology 
and the Archetype and its codes.
Ontologies have the Open World Assumption. A pre-corodinated code like: 
No-Cancer means never there was, is or will be cancer. Ontologies describe 
reality.
In archetypes that use the Closed World Assumption Diagnosis=cancer, 
PresenceModifier=No means No Cancer found but perhaps they are. It just was not 
found. Presence of absence in a database are described.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 20:55, Diego Boscá <yamp...@gmail.com> wrote:
> 
> What I was referencing was one way in which current systems (or more exactly, 
> their developers) could use codes already available in Snomed to create 
> subsets of their forms, regardless their input forms have precoordinated 
> options or use some kind of postcoordination mechanism. By defining these 
> subsets, you are making this form comparable with other similar forms (that 
> use other approaches to store similar information). It isn't about making 
> doctors in the same organization being able to have *new* ways of encoding 
> things, is about taking the forms they currently use and encode them in order 
> to be comparable with data in other organizations (and in principle, they 
> don't even need to be aware of this codification). With this, we can make 
> data have a meaning outside their original systems.
> 
> This is why I say that precoordination in snomed is a good thing. They are 
> terms that have been put in a form somewhere, and having them as is, and at 
> the same time having their undelying equivalent postcoordinated expression 
> helps in softening the boundary problem IMHO.
> I'm always up to go into the future inventing new cool things, but at least 
> in healthcare we are not allowed to lose data already available in current 
> systems.
> 



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

Re: [Troll] Terminology bindings ... again

[GF]

In system interfaces we must not use pre-coordinted SNOMED terms.
In User Interfaces we can to use them.

In extremo one pre-co-ordinated code can describe the whole oeuvre of 
Shakespeare which makes sense in very specific circumstances for very specific 
purposes

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 22:13, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Some people (count me in) strictly ban what you call precoordination (that I 
> call "aglutinating language") because they believe that there is a nearly 
> infinite set of them and such a system is born to "explode" as the frog that 
> wanted to mimic the ox.
> 
> To put it differently: you cannot express all possible discourses as 
> predetermined concepts.
> 
> Do I interpret your answer correctly if I say that you have an optimist 
> vision in the form "there is a limited number of clinically sound 
> precoordinations so that SNOMED expansion will reach an asymptote that keep 
> being manageable"?
> 
> 



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

Re: [Troll] Terminology bindings ... again

[GF]

Dear Philippe,

On purpose I provided these examples.

I agree that anatomic structures can be pre-coordinated.
They are the exception to the rule.

And perhaps in the domain of medical devices we could have exceptions.

I see the analogies:
- Ontology  = Encyclopedia
- Terminology   = Dictionary
- Archetype = Phrase

Under specific circumstances we need aggregated concepts for use in the User 
screen, or during data entry, or data export (for statistics)
SNOMED has the capability to create those complex codes for these very specific 
purposes.
When we need to store and retrieve in a database or when a Clinical Reasoner 
processes data the Rules apply.
Archetypes help define the datum but also its full context/epistomology so the 
data can be interpreted safely.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 28 Mar 2018, at 18:14, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Gerard, I like your rule (build a grammar that coordinates a vocabulary of 
> "atomic concepts" instead of agglutinating meta-concepts in the vocabulary), 
> but not your "left eye" example ;-)
> 
> In my own "universe", the "left eye" is a true physical object (when "eye" is 
> a concept).
> I would say the same thing about the "left common carotid artery" which is 
> something you can actually "touch". Representing this concept as an artery 
> which belongs to the carotid network on the left part of the body is not 
> pre-coordination but rather what could be expressed by a semantic network.
> 
> I agree with your "blue eye" example since it is simply "an eye which color 
> is blue".
> 
> To answer Mikael Nyström in the same message, I would be OK with his 
> conclusion about "the simple solution is to not use what you don't need" if :
> - this task had not been unsuccessfully tested by Belgian GPs, who literally 
> spent years trying to select a subset with no avail,
> - this "language" was not advertised as a communication system... which 
> actually keeps you exposed to the full set unless everyone agrees to a common 
> subset (using Tom's proposals and Gerard's rule, for example).
> 
> Mikael is right when he says that it would be unfair to say that Snomed "is 
> bad because it isn’t optimized for [one's] narrow use case"... unless there 
> are lots of narrows use cases needed and unless one of these narrow use cases 
> is key to the next mainstream use case. If innovators (typically the ones 
> with weird use cases) consider Snomed as a millstone around their necks, it 
> is actually an issue worth considering.
> As pointed before in this thread, this conversation is closely related to HL7 
> V3 and its RIM before it was "fhired".
> 
> Best,
> 
> Philippe



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

Re: [Troll] Terminology bindings ... again

[GF]

Pablo,

It is as Thomas and I wrote.

Open world Assumption: Ontologies declare absolute truths irrespective of 
geographical location and point in time.

Closed World Assumption: Archetypes help express what an author wants to 
document. These are very subjective truths at a point in time.

This subtle but important distinction is only one of the reasons to refrain 
from the use of pre-coorodinated SNOMED terms. Things like these matter when we 
start to reason about the documented patient data.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 01:11, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> I'm sorry but "...no cancer was, is, or will be present." doesn't even make 
> sense. No system can record what can or can't happen in the future, and that 
> concept is not part of any terminology AFAIK.
> 
> On Sun, Apr 1, 2018 at 7:35 PM, GF <gf...@luna.nl <mailto:gf...@luna.nl>> 
> wrote:
> Thomas,
> 
> OpenEHR and 13606 deal with Closed World Assumption systems.
> And therefor both mean in the case of 'No Cancer' that Cancer was not found 
> in the database or that No Cancer was the documented result of an evaluation.
> Both statements are documented things in a Template that according to the 
> author cancer is not found.
> But any time in the future it might.
> 
> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no 
> cancer was, is, or will be present.
> 
> Gerard   Freriks
> +31 620347088 <tel:+31%206%2020347088>
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 1 Apr 2018, at 14:41, Thomas Beale <thomas.be...@openehr.org 
>> <mailto:thomas.be...@openehr.org>> wrote:
>> 
>> 
>> On 01/04/2018 13:16, GF wrote:
>>> Pre-coordinated SNOMED codes are like classifications, in that they are 
>>> used at the user level, the User Interface,
>>> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed 
>>> in its constituents.
>>> These decomposed primitive codes can be used in structures like archetypes 
>>> at the proper places.
>>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>>> 
>>> But we keep the semantic differences codes expressed  using the SNOMED 
>>> ontology and the Archetype and its codes.
>>> Ontologies have the Open World Assumption. A pre-corodinated code like: 
>>> No-Cancer means never there was, is or will be cancer. Ontologies describe 
>>> reality.
>>> In archetypes that use the Closed World Assumption Diagnosis=cancer, 
>>> PresenceModifier=No means No Cancer found but perhaps they are. It just was 
>>> not found. Presence of absence in a database are described.
>> 
>> I'm unclear why you call this a use of the closed world assumption: the 
>> entire openEHR framework is for building HISs that enable reporting of 
>> reality as it is known to those working in it. So if they put 'No cancer' 
>> that just means that the current clinical thinking for some patient, with 
>> respect to some investigation, is that the original presenting problem is 
>> not cancer.
>> 
>> That never means that the patient doesn't have cancer in their body 
>> somewhere, it just means that the currently investigated signs and symptoms 
>> don't relate to cancer, according to the the investigation carried out. Even 
>> that can be overturned later. But everyone assumes this - the EHR is always 
>> understood as an 'open world' system, where absence of X doesn't mean 
>> negation of X, it just means that no-one has investigated X.
>> 
>> - thomas
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> <mailto:openEHR-technical@lists.openehr.org>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> 
> 
> 
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
> +598 99 043 145
> skype: cabolabs
>  <http://cabolabs.com/>
> http://www.cabolabs.com <ht

Re: [Troll] Terminology bindings ... again

[GF]

I think, we happen to be in full agreement.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 01:06, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> In a so-called closed-world system, everything that is stated constitutes the 
> totality of the truths about the world it relates to. In particular, absence 
> of an assertion (such as 'patient X has cancer') means negation, i.e. that 
> patient X doesn't have cancer. But openEHR and 13606 don't work like that; 
> absence of some particular statement about X just means nothing has been said 
> about the relevant issue so far.
> 
> - thomas
> 
> On 01/04/2018 23:35, GF wrote:
>> Thomas,
>> 
>> OpenEHR and 13606 deal with Closed World Assumption systems.
>> And therefor both mean in the case of 'No Cancer' that Cancer was not found 
>> in the database or that No Cancer was the documented result of an evaluation.
>> Both statements are documented things in a Template that according to the 
>> author cancer is not found.
>> But any time in the future it might.
>> 
>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no 
>> cancer was, is, or will be present.
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

1- What stands AP)SA(A'P’) for?

Here below some missing topics we need to have agreement about

2- Thinking about the health and care provission documentation process there 
are:
- Observation process
- Evaluation process (including, and restricted to, diagnosis, diff diagnosis, 
problem kist, episode list, etc
- Planning process
- Ordering process
- Execution process of acts

3- We need to recognise that some data is de novo, other data is repeated after 
a querry

4- Systems need to be aware that some data is directly health care care 
related, other is administrativem process oriented

5- When that what is documented is used in shared working processes we need a 
common vocabulary: i.e. System of Concepts for Continuity of Care



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 14:06, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Le 02/04/2018 à 12:54, A Verhees a écrit :
> 
>> > The "good all" SOAP is dead ; nowadays, the encounter stream is switching 
>> > to (AP)SO(A'P'):
>> > people now come with an existing set of Assessments and Procedures,
>> > not "just" with "Subjective" issues.
>> 
>> Wasn't that always the case?
> 
> We are currently switching from "mainly acute" to "mainly chronic" care. 
> Reason why I claim that the "encounter information stream" must switch from 
> SOAP to (AP)SA(A'P')
> 
> In my understanding, the concept of episodes of care came long after Weed 
> coined the SOAP approach; but I may be wrong.
> 
> However, the main concept here is to consider an encounter as part of a 
> global process and no longer as an isolated event. This is, unfortunately, 
> still a disruptive concept ;-)
> 
> Philippe



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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe.

1- documentation in health and care, as you wrote, can have two points of focus:
- focus: the healthcare provider: as author documenting in his EHR about the 
patient what this HcP has done
- focus the patient: as subject of care allowing other HcProviders as authors 
to document what has been done
The problem is to have these two focus points not only to co-exist, but be 
integrated.

My French is good enough to read 2 medical textbooks in French when I was 
training to become a GP.
If possible share that article with me, I’m curious.

2-In my view ContSYS is one of the ingredients needed to integrate these two 
focus points.
We need more than ContSys:
- a model for the epistemology
- archetypes designed using re-occuring standardised phrases
- terminology providing primitive terms
- a generic standardised solution for modifiers: (non-)presence, states, 
certainty
- standardised services/interfaces for database, user screen/keyboard, 
messages, clinical reasoner
- supporting terminology services (i.e converter into/from user friendly terms, 
…)
- all based on orthogonal shared standardised models.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 21:15, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Le 02/04/2018 à 19:45, GF a écrit :
>> 1- What stands AP)SA(A'P’) for?
> 
> I guess that you know the SOAP as the 4 main "chapters" of a clinical 
> encounter (https://en.wikipedia.org/wiki/SOAP_note 
> <https://en.wikipedia.org/wiki/SOAP_note>).
> From  Lawrence Weed's concepts, a patient encounter should be recorded as a 
> "grid" with problems as columns and SOAP elements as line.
> 
> This concept is theoretically sound for acute care since it starts with 
> patient's verbatim of the reasons for encounter (S standing for Subjective - 
> which is truly dated!).
> 
> In the current "state of the medical art", always more chronic care oriented, 
> a patient often comes with an ongoing list of problems and treatments, hence 
> (AP)SO... and leaves with the same or a different list of A and P, hence 
> (AP)SO(A'P').
> 
> 14 years ago, I worked with a knowledge management research team on 
> establishing both the theoretical aspect and the user interface of such 
> concept, by the name "virtual staff".
> To make it short, imagine the Ligne de vie, with the vertical "now" 
> separator... then spread this separator as a curtain in order to open the 
> patient encounter as a cognitive map located between the past (AP) and 
> the future (A'P').
> 
>> 
>> Here below some missing topics we need to have agreement about
>> 
>> 2- Thinking about the health and care provission documentation process there 
>> are:
>> - Observation process
>> - Evaluation process (including, and restricted to, diagnosis, diff 
>> diagnosis, problem kist, episode list, etc
>> - Planning process
>> - Ordering process
>> - Execution process of acts
> 
> I am currently writing a paper (in French) telling a story of "boxes" and 
> "bubbles". Boxes are care places (say organizations at large) with roles 
> within a domain. Bubbles are the patients (say persons at large) with a 
> "polar reference frame vision" about "who is around and among them, who is 
> close or not so close".
> 
> In the usual system, only boxes operate an information system... and they are 
> pretty bad when it comes to "continuity of X" (replace X with care, 
> education, employment, etc).
> 
> Now, let's suppose that the reference information system is in the bubble. 
> And that service providers are just considered as contributors that can join 
> the current team that surround the person.
> 
> In the ongoing paper, I am trying to describe what happens when "a bubble 
> steps through a box"... and it is an amazing model to make many things clear!
> 
>> 
>> 3- We need to recognise that some data is de novo, other data is repeated 
>> after a querry
>> 
>> 4- Systems need to be aware that some data is directly health care care 
>> related, other is administrativem process oriented
>> 
>> 5- When that what is documented is used in shared working processes we need 
>> a common vocabulary: i.e. System of Concepts for Continuity of Care
> 
> Thanks to François Mennerat, a glorious CISP Club founder, we have been aware 
> of Consys for many years... but "so many years" is also the problem!
> 
> Philippe
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

see below

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 23:35, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> GF: "When we add to all this that only part of the epistemology can be 
> pre-coordinated it means that part of the temporal aspects for instance can 
> NOT be dealt with in SNOMED, then we have the situation that part of the 
> epistemology is in SNOMED and part defined in the Archetype/Template."
> ---
> Using SNOMED does not block using other terminologies or even local 
> terminologies.

13606 and OpenEHR do not block anything.
There are too many degrees of freedom.
All creating problems interpreting the data fully and safely.




> 
> In OpenEhr is always a part of the epistemology in the context of the 
> archetype, that is its power. Terminologies serve to undoubtable define the 
> presented data-item or act as a data-item. This is also the case in CEN13606

In most systems the full epistemology is not recorded.
It is there because of implicit or explicit agreements between users.
There are NO agreed standardised archetypes/patterns we all use to define the 
meta-data in order to document the full eppistemology
so data can be interpreted fully and safely.



> 
> 
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands



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

Re: [Troll] Terminology bindings ... again

[GF]

I agree
> The message is simple:  don't allow items with complex meanings in leafnodes, 
> but use archetypes to represent complexity.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 00:04, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> In addition to this, OpenEhr tends to the use of simple precoordinated 
> concepts, that is because the archetypes explain the details.
> 
> It is, for example, rare in OpenEhr to use the concept for "bloodpressure 
> sitting". Normally one would create two leafnodes, one with the concept for 
> "bloodpressure", the other for "sitting". This level of expressing detail in 
> archetypes is historically grown in the years from before SNOMED, and it 
> seems like a blessing now, because it makes the discussion about concepts 
> with complex meaning a bit superfluous.
> 
> Avoid complex meanings in leaf nodes and express complexity in archetype 
> structure, and the number of different concepts to be used will be reduced 
> and the chance of availability of needed concepts rises.
> 
> The message is simple:  don't allow items with complex meanings in leafnodes, 
> but use archetypes to represent complexity.
> 



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

Re: [Troll] Terminology bindings ... again

[GF]

Archetype modelling and the use of SNOMED pre- and/or post-coordination

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 09:31, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> Can we specific define in about ten words which problem is talked about in 
> this discussion?
> 
> Maybe we can then use that definition as a guideline to keep the discussion 
> focussed.
> 
> Best regards
> Bert Verhees
> 
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com 
> <mailto:pablo.pa...@cabolabs.com>>:
> Please see below,
> 
> On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl <mailto:gf...@luna.nl>> 
> wrote:
> Is that so?
> 
> There will be systems that allow pre-coordinated codes. There will be systems 
> that use as many pre-coordinated codes. And several in between solutions.
> 
> I agree, there will be systems that allow and use pre and post coordinated 
> codes, that is a fairly normal requirement in clinical information systems 
> and openEHR specs supports that.
> 
> This means that reasoners will be used to create transformations.
> 
> It doesn't mean that, I don't see where that is implied.
> 
> Some systems might use reasoners using ontologies, rules, codes and other 
> content, to infer some "facts", and the results should be interpreted in the 
> same context as the ontologies, rules, clinical records and codes are 
> created, managed and used. Inferred facts are context dependent.
> 
> Some other systems might not use any reasoners or ontologies at all, and 
> define programmatic rules that use SNOMED codes and expressions (pre and post 
> coordinated), and other contextual clinical / demographic / administrative 
> information to evaluate those rules and get some result (an alert, a 
> recommendation, a reminder, etc.)
> 
> And other systems might not have rules at all and just use codes, expressions 
> and contextual data to create some visual representation of the patient's 
> status, to be presented to a clinician and make him/her evaluate the data and 
> make a decision. This is the most basic area we should cover, and what 
> originally generated this discussion: how to use SNOMED in openEHR queries.
> 
> Use cases are many, we can't focus on just one area and generalize from there.
> 
> It is likely that ontological servoces will be used, And then we will have a 
> potential problem.
> 
> That will really depend on specific implementations. I don't think proposing 
> a combination of standards with a lot of potential will cause any issues per 
> se.
> 
> 
> But perhaps solvable with the correct precautions.
> One being that ontological servoces are NOT used and that ad hoc rules do the 
> transform.
> 
> That is exactly my point from above, automatic conclusions from a reasoner or 
> any AI can be interpreted as a general truth on any context. Those 
> conclusions should be interpreted in the same context as data and knowledge 
> was created. And semantics should be given by humans on a per-context basis.
> 
> 
> What possible solution is the canonical one? which is the ‘golden truth’.
> 
> Since all that ^ is context-dependent, I don't think there is any canonical 
> form or golden truth.
> 
> 
> When we add to all this that only part of the epistemology can be 
> pre-coordinated it means that part of the temporal aspects for instance can 
> NOT be dealt with in SNOMED, then we have the situation that part of the 
> epistemology is in SNOMED and part defined in the Archetype/Template.
> 
> I agree and that is a good example of what I call "context" (how and where 
> knowledge and information is defined, managed and used, very related to 
> epistemology :)
> 
> 
> 
> Gerard   Freriks
> +31 620347088 <tel:+31%206%2020347088>
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com 
>> <mailto:pablo.pa...@cabolabs.com>> wrote:
>> 
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so there 
>> is no terminology world separated from the content modeling and data 
>> recording world. We will use SNOMED inside the openEHR context, so the 
>> SNOMED meaning will be constrained by the openEHR meaning when recording 
>> clinical information. We should be constraint to that context.
>> 
>> On Mon, Apr 2, 2018 at 6:01 AM, GF <gf...@luna.nl <mailto:gf...@luna.nl>> 
>> wrote:
>> Pablo,
>> 
>> It is as Thomas and I wrote.
>> 
>> Open world Assumption: 

Re: [Troll] Terminology bindings ... again

[GF]

It is Obvious:

- We need to take the next step in Semantic Interoperability: Semantic 
interpretability.
- And think about what is missing, so far
- How to use codes from Terminologies and Classifications
- How to deal with the full Context/Epistemology
- How to deal with modifiers for presence/absence, certainty and other state 
info
- What other models we need to deal with clinical, administration, and 
collaboration, processes

In order to have systems that allow the full, safe, interpretation by humans, 
services, reasoners now and in the future.
Systems with the minimal amount of implicit information needed to interpret 
safely and fully.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 09:35, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> 
> GF :"There are NO agreed standardised archetypes/patterns we all use to 
> define the meta-data in order to document the full eppistemology
> so data can be interpreted fully and safely. "
> 
> 
> So what do you suggest as a solution?
> 
> 
> 
> 
> 
> 
>> 
>> 
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl <mailto:gf...@luna.nl>
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>  
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

OpenEHR and 13606 deal with Closed World Assumption systems.
And therefor both mean in the case of 'No Cancer' that Cancer was not found in 
the database or that No Cancer was the documented result of an evaluation.
Both statements are documented things in a Template that according to the 
author cancer is not found.
But any time in the future it might.

'No Cancer' as pre-coordinated term in the case of SNOMED means that no cancer 
was, is, or will be present.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Apr 2018, at 14:41, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> On 01/04/2018 13:16, GF wrote:
>> Pre-coordinated SNOMED codes are like classifications, in that they are used 
>> at the user level, the User Interface,
>> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed 
>> in its constituents.
>> These decomposed primitive codes can be used in structures like archetypes 
>> at the proper places.
>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>> 
>> But we keep the semantic differences codes expressed  using the SNOMED 
>> ontology and the Archetype and its codes.
>> Ontologies have the Open World Assumption. A pre-corodinated code like: 
>> No-Cancer means never there was, is or will be cancer. Ontologies describe 
>> reality.
>> In archetypes that use the Closed World Assumption Diagnosis=cancer, 
>> PresenceModifier=No means No Cancer found but perhaps they are. It just was 
>> not found. Presence of absence in a database are described.
> 
> I'm unclear why you call this a use of the closed world assumption: the 
> entire openEHR framework is for building HISs that enable reporting of 
> reality as it is known to those working in it. So if they put 'No cancer' 
> that just means that the current clinical thinking for some patient, with 
> respect to some investigation, is that the original presenting problem is not 
> cancer.
> 
> That never means that the patient doesn't have cancer in their body 
> somewhere, it just means that the currently investigated signs and symptoms 
> don't relate to cancer, according to the the investigation carried out. Even 
> that can be overturned later. But everyone assumes this - the EHR is always 
> understood as an 'open world' system, where absence of X doesn't mean 
> negation of X, it just means that no-one has investigated X.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

It is a generic problem that impacts OpenEHR also.

Present systems need a lot of implicit human knowledge in order to interpret 
the data safely and fully.
SNOMED pre-corodination is one way to make this implicit knowledge explicit. It 
possibly is a solution.
My point is that it is not the best solution.
Not only do we need to make more of the implicit knowledge explicit but use 
archetype structures/patterns to define the full context/epistemology in a 
Standardised, shared way.

Existing systems use a myriad number of ways to store health and administrative 
data.
This demands specific requirements to be met.
Systems of the future have other additional requirements that impact archetype 
patterns and the standard way of using coding systems.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 10:06, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Check the initial messages on the thread.
> 
> Basically how to use SNOMED in openEHR, and in a specific area: data 
> querying. AQL support for SNOMED codes and expressions was an initial part of 
> the topic.
> 
> We are trying to solve a basic problem: how to get data out the systems in a 
> smart way. This is because archetypes are good but don't have context that 
> terminologies have, and AQL is good but only queries what is defined by 
> models. So we need something to query over terminologies in combination with 
> querying over models. Reasoning, interpretation and modeling approaches are 
> other orthogonal problems.
> 
> This is a very specific problem for the openEHR specs and ITS, is not a 
> general problem to solve.



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

Re: [Troll] Terminology bindings ... again

[GF]

Dear Thomas,

There are two possible Modelling styles:
- Archetype Leafnode style (Element-Data style)
Specialisation by changing the Element Data field
Each archetype is a fixed, standardised, pattern, a mini-ontology
The fixed path to the leaf-node defines the full meaning of that leaf-node

- Archetype Node style (Class-Attribute style)
Specialisation by changing node names in the archetype
Each archetype makes use of  non-standard patterns.
The meaning is changed by changing node names.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 18:07, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> Gerard,
> 
> I don't know that your modelling approach is that far from openEHR - you are 
> from memory using CLUSTER in a way we are not, but I don't recall the 
> details. In any case, is there a recent reference page on the web where a 
> technical summary of your modelling style can be seen?
> 
> thanks
> 
> - thomas
> 
> On 30/03/2018 16:49, GF wrote:
>> Philippe,
>> 
>> Fist of all: My ideas about modelling and using archetype, etc is not shared 
>> by OpenEhr
>> 
>> I agree that the tree is important.
>> My tree starts at Composition contaiining one of more Sections, and/or 
>> Entries.
>> The Entry models a process of one of these: data observation, data 
>> evaluation, data planning, data ordering and data about events/actions.
>> Each of these models deal with the full epistemology of that topic using 
>> standardised patterns/Clusters/Archetypes
>> That what is observed is a Cluster archetype that models the datum plus its 
>> context/epistemology.
>> 
>> What is important is the Modelling Style.
>> In OpenEhr the nodes of the Archetype are changed.
>> In my style, since I make use of predefined patterns I will not change the 
>> nodes but change the data in the Elements.
>> In my style of modelling querying the leaves is that what is done. The 
>> unique path defines its meaning.
>> In my way of modelling the collection of paths is a kind of ontology for 
>> data in healthcare records.
>> 
>> 
> 
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com/>
> Consultant, ABD Team, Intermountain Healthcare 
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation 
> <http://www.openehr.org/>
> Chartered IT Professional Fellow, BCS, British Computer Society 
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog 
> <http://wolandsothercat.net/>___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

Both styles are possible with any RM.
It is a choice.

Most archetype modellers use the Class-Attribute / Archetype Node style.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 11:04, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> Maybe we should relate this thinking to CEN13606 because that Reference Model 
> allows more generic thinking.
> (Thinking this because GF was the convenor of this CEN standard)
> 
> But even then some more explanation would be welcome.
> 
> Bert



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

Re: [Troll] Terminology bindings ... again

[GF]

The specialisation in the OpenEHR RM itself is an anomaly, that can be 
circumvented.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 12:14, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> On 31-03-18 12:11, GF wrote:
>> Both styles are possible with any RM.
>> It is a choice.
> Do you mean, inside OpenEhr by using the GenericEntry?
> Or are there other entry-types possible also?
> 
>> 
>> Most archetype modellers use the Class-Attribute / Archetype Node style.
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl <mailto:gf...@luna.nl>
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 31 Mar 2018, at 11:04, Bert Verhees <bert.verh...@rosa.nl 
>>> <mailto:bert.verh...@rosa.nl>> wrote:
>>> 
>>> Maybe we should relate this thinking to CEN13606 because that Reference 
>>> Model allows more generic thinking.
>>> (Thinking this because GF was the convenor of this CEN standard)
>>> 
>>> But even then some more explanation would be welcome.
>>> 
>>> Bert
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> <mailto:openEHR-technical@lists.openehr.org>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>



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

Re: [Troll] Terminology bindings ... again

[GF]

In my opinion there is something essential missing, so far.
What is missing is a collection of standard Cluster archetypes/Patterns that 
can be used to create any story, describing the 
observation/evaluation/planning/ordering and action processes including all the 
possible contexts.
All the Archetype Patterns create one Documentation ontology.

That Documentation ontology as grammar combined with a terminology like SNOMED 
and LOINC looks like Phillipe's system.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 11:38, Philippe Ameline <philippe.amel...@free.fr> wrote:
> 
> Diego,
> 
> IMHO your contribution is orthogonal to what Thomas very accurately 
> explained. Building subset is a symptom of the issue, not a solution.
> 
> As I tried to explain in my initial post, we are currently facing two 
> generation of technologies in medicine:
> - systems that record information as trees of atomic concepts, in the same 
> way we are all exchanging in "globish" by inserting English concepts in a 
> grammatical structure,
> - systems that still rely on a fixed database schema and usually have a 
> "discourse system" limited to field/value pairs.
> 
> When I try to explain all this to lesser tech-savvy people (means, who don't 
> belong to this list ;-) ), I usually explain that:
> - usual systems (with an information schema tied to a database schema) are 
> like a printed form. The day after you received the 5000 printed sheet you 
> ordered, you will realize that there are several design flaws that you will 
> have to endure while the stock is not empty,
> - openEHR is a flexible schema, similar to a set of stamps that lets you 
> build forms dynamically from blank paper. If your design has to evolve, you 
> just have to adapt one of the stamps.
> - in my system, based on an ontology and a dependency grammar, you can use 
> stamps (archetypes like) and/or "write" freely.
> 
> I have always understood openEHR as a link, a step, between the "good old 
> way" (discourse range hard coded into a database schema) and a modern 
> approach where you can really "tell a patient story" using a genuine 
> (structured, processable) language. 15 years ago, Thomas and I spent hours 
> discussing the opportunity for openEHR to include a reference ontology in its 
> kernel ; this decision was not made for very good reasons, but I guess that 
> it still remains a necessary evolution.
> Thomas very accurately explained why SNOMED is a deceptive candidate for such 
> a reference ontology. And, unfortunately, it is deep rooted in its origins as 
> a coding system. I can hear all the arguments about "legacy system" and even 
> "legacy medicine" (the one still fully organized for siloed acute care at a 
> time our society already entered the information age and suffers from chronic 
> diseases). The question remains to guess if SNOMED is a component that lets 
> you stuck in the past or helps you disrupt the legacy craps.
> Now, let's imagine a modern system that would allow you to "tell a patient 
> medical story" from the various viewpoints of a multidisciplinary patient 
> centered team. What would be the point about having "local vocabulary 
> subsets"? Do you think that a GP shouldn't use the word "mitral leak" or any 
> other "specialized" word in the medical vocabulary?
> 
> My feeling is that selected subset is a solution when using SNOMED as a 
> coding system. The subset being the global list of values that are legal for 
> the fields in the existing schema, in the same way you will select subsets in 
> a billing system. But when it comes to "telling a story" using a language, in 
> my opinion subsets are a non-sense. We don't use "vocabulary subsets" when we 
> talk, and each contributor in a patient's team would mechanically get exposed 
> to a super-set; subset is actually only fit for silos... and at a time when 
> medicine is already becoming a narrow silo in health, I really don't see it 
> as a sound strategy.
> 
> Best,
> 
> Philippe
> 
> Le 23/03/2018 à 10:49, Diego Boscá a écrit :
>> IMO having both representations (pre and postcordinated) is not bad per se 
>> (in fact, knowing that they are equivalent is pretty good). The main problem 
>> is that technical people (including myself) shouldn't just dump the entire 
>> snomed ct into a data field and call it a day. To design better and useful 
>> systems you need a first "curation" phase where you define your relevant 
>> subsets that fit your system. The boundary problem is less of a problem if 
>> even if different terms were

Re: [Troll] Terminology bindings ... again

[GF]

What do you expect from a technical description when it comes to styles?
Under the hood one sees no striking differences.
Archetype nodes are archetype nodes, leafnodes are leafnodes.
What is different is the way one uses ADL to constrain the RM.

Or do you mean to see the documentation Ontology?

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 13:04, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> Okay. Do you have a technical description of what you are talking about?
> 
> Thanks
> Bert



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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

Chairos time has fussiness (uncertainty) as attribute.

Actually any topic needs a fussiness/uncertainty attribute. Either a range of 
something or a subjective qualification



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 17:17, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
> On Wed, Mar 21, 2018 at 04:32:53PM +0100, GF wrote:
> 
>> My point is that some times we can not/want not use points
>> on the time line but use fussier terms like: begin of an
>> event somewhere in 2015, or a duration of one month, or
> 
> Which can be modelled as
> 
>+/- 
> 
> such as
> 
>+/- <3 months>
> 
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: [Troll] Terminology bindings ... again

[GF]

One simple rule solves the boundary problem.

In my words.
In principle models we use in the Semantic Stack are autonomous and orthogonal 
to each other. Meaning that at precisely defines points the intersect,
SNOMED is an ontology defining terms for concepts.
Concept can be primitive or compound.
Primitive concept examples are: Left and Right and Eye, White, Red and Blue. 
All terms one expects in a dictionary.
Compound concepts are pre-co-ordinated concepts: Left Eye, Right Eye. Eye White 
coloured Red, ‘Blue eye’. All terms one expects in a pattern/standard phrase 
using words from a dictionary in a syntax.

The rule is:
Pre-coordination is done via Archetype/Patterns using Primitive concepts.
Pre-coordination is not done via an ontology/terminology.

Off course clinicians on their screens or doing statistics need Compound 
concepts and therefor need pre-coorodinated terms.
These pre-coordinated terms must never be used to store, retrieve, interpret 
raw health data inside Health IT-systems.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 22 Mar 2018, at 00:46, Heather Leslie 
> <heather.les...@atomicainformatics.com> wrote:
> 
> Hi Mikael,
> 
> What efforts are being made to resolve the boundary problem?
> 
> I applied to get involved with the  SNOMED information modelling group but 
> wasn’t successful, to try to engage on exactly that  point.
> 
> I’m not aware of any work going on. I’d be very pleased to get involved if I 
> could. It’s a fiendish problem and we need cooperation and collaboration from 
> both sides of the fence.
> 
> Regards
> 
> Heather
> 
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org 
> <mailto:openehr-technical-boun...@lists.openehr.org>> On Behalf Of Mikael 
> Nyström
> Sent: Thursday, 22 March 2018 1:00 AM
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org 
> <mailto:openehr-technical@lists.openehr.org>>
> Subject: SV: SV: [Troll] Terminology bindings ... again
> 
> Hi Tom,
> 
> I believe that you proposal to ”move / remove the pre-coordinated codes out 
> of SNOMED” is very appealing in theory. However it is very difficult in 
> reality to agree on where the line between a suitable pre-coordinated concept 
> and a concept that is better to post-coordinate or handle in another way are. 
> The line between the two alternatives also seem to be use case dependent, 
> which makes it even more difficult, and of cause also related to the boundary 
> problem. However, until there is a strong agreement on where the line should 
> be I continue to believe that it is better so include the concepts in the 
> same pile and let each use case decide how to select the concepts they need 
> and transform between the different representations.
> 
> I like discussions about SNOMED CT and I don’t have any problems at all with 
> critical comments as long as they are fair. Those kinds of criticism quite 
> often makes me writing change requests. I am also happy to answer questions 
> about SNOMED CT. However, I and several other people that are involved in the 
> SNOMED CT  community are quite tired of people that argue that SNOMED CT is 
> bad based on incorrect facts and/or SNOMED CT is bad because it isn’t 
> optimized for their narrow use case.
> 
>  Regards
>  Mikael
> 
> Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> <mailto:openehr-technical-boun...@lists.openehr.org>] För Thomas Beale
> Skickat: den 21 mars 2018 14:17
> Till: openehr-technical@lists.openehr.org 
> <mailto:openehr-technical@lists.openehr.org>
> Ämne: Re: SV: [Troll] Terminology bindings ... again
> 
> 
> 
> Nevertheless, I think it would have been good to move / remove the 
> pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable 
> core, which would actually look a lot more like Philippe's (much smaller) 
> terminology.
> 
> This relates to the old debate on reference v interface terminology, and just 
> throwing out precoord concepts is probably not right - they need to be in a 
> completely different hierarchy.
> 
> The post-coordination grammar in SCT is good, its theoretical challenge is 
> the concept meta-model, i.e. what things like 'morphology', 'laterality' you 
> can mention, and in what relationship. But this is hard for all of us, and 
> requires some serious ontology work (Mikael and other experts know all about 
> this of course).
> 
> What I would say is this: in a similar way that I think SNOMED should have 
> separated out 'SNOMED technology' (representation, APIs etc) from content, I 
> think the concept meta-model should hav

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

Duration must be modelled using Archetype and not as part of the RM or AOM.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Mar 2018, at 15:55, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Hi Gerard, this is about the current specs, not about what is supported by 
> programming languages.
> 
> On Mon, Mar 19, 2018, 05:57 GF <gf...@luna.nl <mailto:gf...@luna.nl>> wrote:
> Again my thoughts
> 
> Duration is not a Data Type in many computer languages.
> So we need to model it in an Archetype (Chairos)
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 19 Mar 2018, at 06:24, Pablo Pazos <pablo.pa...@cabolabs.com 
>> <mailto:pablo.pa...@cabolabs.com>> wrote:
>> 
>> Hi,
>> 
>> Looking at CDuration 
>> http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf 
>> <http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf> page 46, the 
>> range constraint is defined with a Duration class.
>> 
>> On the support specs 
>> http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf 
>> <http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf> page 
>> 30 we have the ISO8601_DURATION class.
>> 
>> Should AOM reference that class or we have another Duration class somewhere?
>> 
>> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from 
>> ISO8601_DURATION). 
>> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf 
>> <http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf> 
>> page 54
>> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago and that 
could not be inspected without a magnifying glass on a sheet of paper that was 
2 by 1 meters?

Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 00:22, A Verhees <bert.verh...@rosa.nl> wrote:
> 
> That is true, but I think it would be good if it would find its way in the 
> RM, for two reasons
> 1) misusing the duration does not seem right, and I think the ISO string 
> representing a duration must change. That is, I know, a long way, so the part 
> before the 'T' should represent a calendar datatype, and the other part 
> should be a duration. It is also worth considering to split the DV_DURATION 
> type in the same way.
> 2) If it find its formal way in the RM libraries will support it also, which 
> will help implementers to do it the right way.
> 
> Bert



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

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

I agree with your opinions.

In summary:
Model 1- Ontological models define primitive concepts in Terminologies. 
Concepts that one can expect to see in a dictionary.
Model 2- Archetypes define compound concepts using primitive concepts from 
terminologies. Archetypes are models that model a concept and its 
epistemology/context. Archetypes are agreed re-usable patterns and are like 
sentences constructed using syntax and words from a dictionary. This is the 
level where post-coordination takes place.
Model 3- Templates are specific models composed of Archetypes defining the 
content of an interface (database, screen, clinical reasoner, etc) Templates 
are temporal, locally defined, chapters and paragraphs defining/documenting 
patient data obtained in the healthcare process.
Model 4- For specific reasons users might want to see pre-coordinated terms on 
screens, or statistical reporting demand it. This means that raw data obtained 
using Model 3 can be converted to pre-coordinated terms from a Terminology. It 
is a User Interface issue.

All models are orthogonal to each other and intersect at well defined places. 
Models can not be mixed and overlap.
When they do, the problem is intractable.

Next to these 4 models we need additional models:
- Healthcare Process (ContSys)
- Documentation process (Observation Process, Evaluation Process, Planning 
Process, Ordering process, Execution Process, Administrative processes)
- …

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 23 Mar 2018, at 01:06, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> I have made some attempts to study the problem in the past, not recently, so 
> I don't know how much the content has changed in the last 5 years. Two points 
> come to mind:
> 
> 1. the problem of a profusion of pre-coordinated and post-coordinatable 
> concepts during a lexically-based choosing process (which is often just on a 
> subset).
>  this can be simulated by the lexical search in any of the Snomed search 
> engines, as shown in the screen shots below. Now, the returned list is just a 
> bag of lexical matches, not a hierarchy. But - it is clear from just the size 
> of the list that it would take time to even find the right one - usually 
> there are several matches, e.g. 'blood pressure (obs entity)', 'systemic 
> blood pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable 
> blood pressure' and many more.
> 
> I would contend (and have for years) that things like 'sitting blood 
> pressure', 'stable blood pressure', and 'blood pressure unrecordable' are 
> just wrong as atomic concepts, each with a separate argument as to why. I 
> won't go into any of them now. Let's assume instead that the lexical search 
> was done on a subset, and that only observables and findings (why are there 
> two?) show up, and that the user clicks through 'blood pressure (observable 
> entity)', ignoring the 30 or more other concepts. Then the result is a part 
> of the hierarchy, see the final screenshot. I would have a hard time building 
> any ontology-based argument for even just this one sub-tree, which breaks 
> basic terminology rules such as mutual exclusivity, collective exhaustiveness 
> and so on. How would the user choose from this? If they are recording 
> systolic systemic arterial BP, lying, do they choose 'systemic blood 
> pressure', 'arterial blood pressure', 'systolic blood pressure', 'lying blood 
> pressure', or something else.
> 
> Most of these terms are pre-coordinated, and the problem would be solved by 
> treating the various factors such as patient position, timing, mathematical 
> function (instant, mean, etc), measurement datum type (systolic, pulse, MAP 
> etc), subsystem (systemic, central venous etc) and so on as 
> post-coordinatable elements that can be attached in specific ways according 
> to the ontological description of measuring blood pressure on a body. This is 
> what the blood pressure archetype does, and we might argue that since that is 
> the model of capturing BP measurements (not an ontological description of 
> course), it is the starting point, and in fact the user won't ever have to do 
> the lexical choosing above. Now, to achieve the coding that some people say 
> they want, the archetype authors would have the job of choosing the 
> appropriate codes to bind to the elements of the archetype. In theory it 
> would be possible to construct paths and/or expressions in the archetype and 
> bind one of the concepts from the list below to each one. To do so we would 
> need to add 40-50 bindings to that archetype. But why? To what end? I am 
> unclear just who would ever use any of these terms.
> 
> The terms that matter are: systemic, systolic/diastolic, terms for body 
> location, terms 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

When I’n not mistaken:
Duration is not the same concept as Calendar.
IsoTime and Calendar are both data types defining an absolute point on the time 
line, but in different ways.

Duration is the difference between points on the time line.

My point is that some times we can not/want not use points on the time line but 
use fussier terms like: begin of an event somewhere in 2015, or a duration of 
one month, or

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 15:02, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> I don't mind how you call it, programmers call it Duration and Calendar, both 
> are well known datatypes, but they have other semantics.
> 
> 
> On 21-03-18 14:53, GF wrote:
>> 
>> You gave proof that there are different kinds of time.
>> Chrono-time as used fro time stamping at one exact point in time.
>> And Chairos-time used for imprecise relative time as used by humans,
>> 
>> Chrono-time is one primitive data type.
>> Chairos-time is defined using archetype/patterns
>> 
>> 
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl <mailto:gf...@luna.nl>
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 21 Mar 2018, at 12:25, Bert Verhees <bert.verh...@rosa.nl 
>>> <mailto:bert.verh...@rosa.nl>> wrote:
>>> 
>>> 
>>> On 21-03-18 10:50, GF wrote:
>>>> Does including Duration in the RM fit with the scope for the RM?
>>>> 
>>>> Why do we have archetypes?
>>>> Why not include every thing in the RM?
>>>> Do we want the HL7v3 Reference Model as it existed many years ago and that 
>>>> could not be inspected without a magnifying glass on a sheet of paper that 
>>>> was 2 by 1 meters?
>>>> 
>>>> Is there one kind of duration?
>>>> 24 minutes, 5 seconds?
>>>> For 2 hours past midnight?
>>>> For 2 hours after (clinical) event x
>>>> For 2 months after (clinical) event y
>>> 2 months cannot be technically represented in a duration, because month is 
>>> not a stable time-definition. It is a Calendar definition.
>>> It is therefor that most major programing languages have a Duration and a 
>>> Calendar class.
>>> Or you say that OpenEhr has no valid Duration-datatype, so always express 
>>> Duration in an archetype (your way),
>>> or say that OpenEhr has a valid Dv_Duration type, and do it right (I prefer 
>>> this way),
>>> or express months as if it is a stable time-indicator and ignore it is not 
>>> (like it is now)
>>> 
>>> Those are the three possible ways to solve this problem, I think
>>> I am curious to learn what the community will decide.
>>> 
>>> Bert
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> <mailto:openEHR-technical@lists.openehr.org>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

Again my thoughts

Duration is not a Data Type in many computer languages.
So we need to model it in an Archetype (Chairos)

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Mar 2018, at 06:24, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> 
> Hi,
> 
> Looking at CDuration 
> http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf 
> <http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf> page 46, the 
> range constraint is defined with a Duration class.
> 
> On the support specs 
> http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf 
> <http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf> page 
> 30 we have the ISO8601_DURATION class.
> 
> Should AOM reference that class or we have another Duration class somewhere?
> 
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from 
> ISO8601_DURATION). 
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf 
> <http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf> 
> page 54
> 



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

Re: [Troll] Terminology bindings ... again

[GF]

Dear Silje,

I think we agree.

In my view it is not wise to use pre-coorinated codes that include contextual 
information. The reason is that the complete why, when, who and how result in 
too many permutations in order to be tractable.
One must make the distinction between how data is expressed in a generic system 
interface connected to other services such as: database, clinical reasoner, 
import/export, etc. and between a specific interface that users connect with 
for data inspection, data entry, statistical data analysis.
The former must NOT use pre-coordinated terms; the latter depending on user 
requirements will use pre-coordinated terms that can be constructed using the 
raw data in the generic system interface.



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 23 Mar 2018, at 10:35, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> I read Thomas’ reply with great interest, and I generally agree that with a 
> well thought out information model, the very detailed precoordinated 
> expressions are redundant. At the same time I understand Mikael’s point of 
> view too. BUT, what I’m often met with is that because these precoordinated 
> expressions exist (like for example “lying blood pressure” and “sitting blood 
> pressure”), we should use them INSTEAD OF using our clever information models 
> (that we do have) for recording new data. <>

>  <>
> 
> In my opinion this is wrong because it doesn’t take into account that 
> healthcare is unpredictable, and this makes recording more difficult for the 
> clinician. How many different variations would you have to select from? Take 
> the made up example “sitting systolic blood pressure with a medium cuff on 
> the left upper arm”; this will be a lot of possible permutations, especially 
> if you take into account all the different permutations where one or more 
> variable isn’t relevant.
> 
> So while I don’t think the existence of these precoordinated terms in itself 
> is a problem, it’s a potential problem that people get a bit overzealous with 
> them.
> 
> Regards,
> Silje
> 



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

Re: [Troll] Terminology bindings ... again

[GF]

Yes.

The simple rules that solve the Boundary Problem need some exceptions.
- anatomical structure
- possibly some aspects of devices

To investigate it properly is a possibility.
The problem I see is the How question.
For me there is only one solution and that is by analysing the problem and 
thinking about it.

Ingredients that we could take in consideration are notions like:
- Models in the Interoperability Stack must be autonomous and orthogonal
- The Models we need in the Stack
- Closed world assumption of Archetypes versus Open world assumption of the 
ontology behind SNOMED
- Requirements for data exposed to users via statistics, screens, forms, and 
documents
- Requirements for data stored, retrieved from databases
- Requirements for data to be interpreted by clinical reasoners
- Modelling methods

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 24 Mar 2018, at 08:41, Heather Leslie 
> <heather.les...@atomicainformatics.com> wrote:
> 
> Totally agreed, Silje. I think preordination for anatomical location is 
> invaluable, but it’s the only use case that I have identified as one we 
> absolutely can’t do without.
> 
> But I would love the opportunity to really investigate this properly, and 
> with others who understand SNOMED better than I. That will help with the 
> boundary issue/semantically grey area.
> 
> I’d prefer that we could use and reuse simpler, really high quality value 
> sets from in multiple archetypes for different contexts eg a list of 
> diagnoses in the Problem/diagnosis archetype as well as the Family History 
> archetype. The archetype context is invaluable here. And the terminology 
> community focussing on high value terms that would provide great impact.
> 
> Regards
> 
> Heather
> 



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

Re: Setting thresholds

[GF]

I agree this ‘definition’ problem is outside of the scope of this list.
But since you misused terms, I reacted.

In your example in words:
- Observation 'Serum sodium = X’,  'Normal associated and stored Normal range 
for adult males:: Lower=A, Higher=B 
- Evaluation 1 'X is abnormal and lower than Lower bound A’
- Evaluation 2 'Patient System has a state of  Hyponatrenomy’
- Evaluation 3 ‘Patient System has problem item on the Problem list Y’
- Evaluation 4 ‘Patient System has risk to have as possible diagnosis Z1, Z2, 
Z3’
- …
-…
-  Evaluation N ‘Patient has diagnosis Z4’

I agree that just one single Observation is not enough to safely diagnose the 
patient.
More is needed than that.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 17:29, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> We’re getting into territory that maybe doesn’t belong in the technical list 
> anymore, but anyway. <>
>  
> I suspect this may be a disagreement in choice of words. I’m talking about 
> the difference between observational and evaluative statements. The lab 
> result is observational and what I called “diagnosis” is evaluative. The 
> point I was trying to make is that these are different in nature, whether we 
> choose to call the evaluative statement “problem” or “diagnosis”. The 
> S-sodium lab result by itself doesn’t necessarily mean that the patient 
> actually had a real hyponatremia, though I see that my previous statement 
> could be interpreted as such. Maybe the patient had simultaneous 
> hyperlipidemia or hyperproteinemia? The assessment of the larger picture is 
> of course what leads to the evaluative statement.
>  
> The overall point I was trying to make was that you can’t expect to be able 
> to computationally draw conclusions about the health of a patient based only 
> on reference ranges for single observational statements; you also need a 
> human (or perhaps in the future a machine?) to assess a larger picture.
>  
> I wish you all a nice weekend! J
>  
> Regards,
> Silje
>  

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

Attached to each numerical value one needs several ranges that apply to the 
value.
- normal value for a defined population
- other signalling ranges

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 28 Feb 2018, at 13:18, Jussara Macedo Rötzsch 
> <jussara.mac...@coreconsulting.com.br> wrote:
> 
> Hi
> Ranges  aren’t actually part   of the Information model, they are rules for 
> decision support, and therefore belong to the Application level, like a gdl 
> based CDS
> Jussara 
> 
> 
> Em qua, 28 de fev de 2018 às 09:01, Seref Arikan 
> <serefari...@kurumsalteknoloji.com 
> <mailto:serefari...@kurumsalteknoloji.com>> escreveu:
> This sounds like something you should handle at the application level rather 
> than modeling level to me. 
> 
> On Wed, Feb 28, 2018 at 11:48 AM, Jan-Marc Verlinden <jan-m...@medrecord.io 
> <mailto:jan-m...@medrecord.io>> wrote:
> We are developing a completely openEHR based Personal Health Environment 
> (PHR). For this we would like to show measured data in a graph containing 
> "good" or "bad". Mostly one would see some traffic light system, our approach 
> is different but comes to the same principle.
> 
> So for this we need to set thresholds that also could be changed afterwards. 
> In the most common BP archetype (and Template) no thresholds are defined, so 
> at what level would we do that?
> -- 
> Regards, Jan-Marc
> Mobile: +31 6 53785650 <tel:+31%206%2053785650>
> www.medrecord.io <http://www.medrecord.io/>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>--
>  
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_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-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

Thomas,

yes, agree.
But we need more ontologies informing archetypes, classifications and 
/terminologies about other topics such as defined in the ISO Continuity of Care 
standard, …

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Mar 2018, at 16:24, Thomas Beale <thomas.be...@openehr.org> wrote:
> 
> 
> Sorry - didn't mean to be cryptic.
> BFO = basic formal ontology - probably best mainstream reference is the book, 
> see here on Amazon 
> <https://www.amazon.co.uk/Building-Ontologies-Basic-Formal-Ontology/dp/0262527812>
> RO = relations ontology - an ontology of possible relationships between 
> upper-level biomedical entities, including part-of, develops-from etc. OBO 
> ref <http://obofoundry.org/ontology/ro.html>.
> IAO = Information Artefact Ontology. OBO ref 
> <http://obofoundry.org/ontology/iao.html>.
> 
> I'm not saying that the concrete representation of reference data has to be 
> an ontology (e.g. as produced by Protege), but reference information 
> ('knowledge') is unavoidably based on an ontological viewpoint in the same 
> way that the contents of SNOMED CT are (should be). Drug data for example 
> takes the form of facts about drugs such as constituents, interactions; units 
> information is /should be based on an ontology of measurement concepts (which 
> is not very well represented in OBO right now - as far as I can determine, 
> people think it should be in IAO, but I think that is incorrect. Practically, 
> UCUM serves pretty well.)
> 
> - thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

Imo

Past data including past references are in the EHR.
The present is elsewhere as a service in the EHR-system.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 09:47, Diego Boscá <yamp...@gmail.com> wrote:
> 
> Not sure if I fully understand/agree. As knowledge advances, past data could 
> be seen under a new light (e.g. some medication was given to a set of 
> patients and now we know it has a contraindication with another medication) 
> and we could get different results each time we run the query, which is 
> exactly what we want

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

I agree with Karsten.

Diagnosis (in my terms) is a statement as the result of an Evaluation process 
about the Patient System.
Measurement is the result of an Observation process about the Patient System 
using materials of the Patient System as source.
Evaluation is the result of an Evaluation process that indicates that the 
result is ‘normal’, ‘elevated’, ‘low’, ‘abnormal’, ‘risk of’, etc.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 15:22, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> 
> On Fri, Mar 02, 2018 at 01:48:40PM +, Bakke, Silje Ljosland wrote:
> 
>> A doctor making and recording a conclusion that a
>> measurement of some kind is too high or too low, IS a
>> diagnosis.
> 
> Uhm, no.
> 
>> their conclusion would be recorded as a diagnosis of hyponatremia.
> 
> While most doctors will do that it is wrong.
> 
> Hyponatremia is not a diagnosis. It is just a
> supposedly-clever way of saying what the lab already said. It
> is intended to make non-doctors think we doctors are in
> control of the situation.
> 
> At best, it is an unresolved problem. All in all it is a
> _finding_, or observation, notably out-of-range :-)
> 
> Karsten
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Unique paths for slots problem if slots are filled with same archetype

[GF]

Either it is solve using standardised basic Archetypes or via the RM.
The RM route is the preferred one.

When thinking about it, then…
Data in any Patient Record is either:
- de novo data stored at a session
- re-used pre-existing data (Reported data, used data in processes, etc.) This 
data is pre-existing data that is re-used. When querying for a concept it must 
be possible to restrict it to new data and/or re-used data.
Again this can be solved via standardised basic Archetypes or the RM.
The RM is the best option.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Nov 2018, at 12:23, Thomas Beale  wrote:
> 
> I've just been thinking more about this problem. I agree we need to fix it, 
> and it seems fairly likely adjusted rules for forming paths and storing 
> archetype markers in data will be needed.
> 
> But... the archetype structure mentioned is a hack for getting around the 
> lack of order-tracking attributes in the RM. We've had a look at this before 
> (e.g. here 
> <https://openehr.atlassian.net/wiki/spaces/spec/pages/60358659/RM+additions+for+workflow+process>)
>  but I would suggest we need to think soon about additions to the ENTRY class 
> or package to properly model requester and receiver meta-data.
> 
> - thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[GF]

Dear colleagues,

GDPR as I understand it and apply in the Netherlands gives consumers/patients 
several rights: inspect, change, to be forgotten.
An other important topic is: the goal binding of data. Only absolutely 
necessary data needed to execute a specified task can be collected.

With respect to the discussion:
The EHR serves several purposes: documentation of the actions of the 
author/health care provider, the documentation of the state of (un-)health of 
the patient, input for billing and input for other processing such as research.
The right to be forgotten does NOT imply that all the data needs to be removed. 
Removing is an impossibility when data is archived on for instance a DvD/CD.
In my opinion when the patient asks to be forgotten then this applies to the 
Clinical/health context, only.
In all other contexts the patient can never be forgotten or deleted. Any legal 
transaction is subject to archiving laws. For tax purposes the time period is 5 
years in the Netherlands, I think. Only after these periods as defined by law 
the transactions can/must be deleted.

In the case of the EHR (13606 / OpenEHR) there is a need to ‘obscure' the 
patient in the clinical context. But allow the patient to be found for 
medico-legal purposes, research, etc.
This functionality is executed in the Patient-Index Service and NOT the Patient 
Health Record.

All my reasoning is true in the local, and iCloud, wat of processing/storing 
data.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Sep 2018, at 19:24, Ian McNicoll  wrote:
> 
> Hi Bert,
> 
> There are certainly some implementations that allow for hard-deletes of 
> compositions and Ehrs. This is a complex area as GDPR does not confer an 
> absolute right for medical info to be forgotten (as I understand it). It does 
> allow for copies of the record to be retained for medico-legal purposes.
> 
> However, in our cloud-provider setting, we absolutely need to be able to hard 
> delete Ehrs, as people may simply want to switch CDR providers. As a data 
> processor, we have no right to keep t record, as long as it is available via 
> another provider.
> 
> Ian
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com <mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> <mailto:ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> 
> On Sat, 1 Sep 2018 at 14:52, Bert Verhees  <mailto:bert.verh...@rosa.nl>> wrote:
> OpenEhr does not really allow to delete data, only logical deletion (mark as 
> deleted), but GDPR demands the right of the patient to be forgotten.
> 
> Is there some change expected in the specs for compliance to GDPR, or was 
> this already implemented?
> 
> We had this discussion, slightly different, about ten months ago but no 
> conclusion if I recall well
> 
> Sorry if I missed a message about this.
> 
> Thanks
> Bert Verhees
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

Re: Generic modeling and issues for querying

[GF]

Because archetypes and templates allow to use one or more instantiations 
depending on constraints, querying needs to be done on instantiations informed 
by the Template.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Sep 2018, at 03:13, Pablo Pazos  wrote:
> 
> @Thomas I realized we have a similar issue with multiple occurrences of 
> structured items.
> 
> For instance, an OPT:
> 
> ...
> CLUSTER 0..* at1234
> - ELEMENT at1235
> - ELEMENT at1236
> 
> Could have an instance:
> 
> ...
> CLUSTER at1234
> - ELEMENT at1235
> - ELEMENT at1236
> CLUSTER at1234
> - ELEMENT at1235
> - ELEMENT at1236
> 
> Then querying for "SELECT  WHERE ../path_to_at1235/value > X AND 
> .../path_to_1236/value = Y" will return data even if both ELEMENTs referenced 
> by the paths are contained in different CLUSTER instances.
> 
> An AQL exercise would be how to get the CLUSTER which contains ELEMENTs that 
> comply with conditions on more than one ELEMENT inside them and there are 
> many occurrences of the same CLUSTER, so CLUSTER and children will have the 
> same paths.
> 
> Not sure how to express that considering that depends on instances not on the 
> model.
> 
> Maybe is something that should be handled by the CONTAINS operator? I believe 
> it was Ian that said the CONTAINS should be evaluated against instances, not 
> against the template. If that is the case, I think that will also solve the 
> issue explained on my first message.
> 
> Any ideas?



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

Re: openEHR on FHIR and vice versa

[GF]

The requiremetns for OpenEHR are NOT the same as those for FHIR or CIMI.
Therefor a complete generic mapping is impossible.
Always it will be an ad-hoc, bespoke, one.

The choices FHIR made for its Resources differ from those of OpenEHR and CIMI 
archetypes.
They do NOT share the same Reference Model.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 14 Dec 2018, at 11:48, Diego Boscá  wrote:
> 
> Hello Georg,
> 
> The main result of that paper was supporting FHIR as a reference model to 
> define archetypes (you can do that with no limitations on the currently 
> available tool). There is no openEHR archetype <-> FHIR profile service yet, 
> although I believe that providing a openEHR -> FHIR generical transformation 
> could be feasible.
> Most of the results of this work are available as import/export functions in 
> LinkEHR: Importing StructureDefinitions should work for most things (in fact, 
> I have been updating this part recently and will have better support for STU3 
> in next LinkEHR version we publish). The export feature is in the original 
> DSTU format though, I assume we should go further and generate 
> StructureDefinitions as in STU3. For the transformation of data instances, as 
> I said we use archetypes as way to express FHIR profiles and resources, so 
> transforming between them is no more difficult than transforming between 
> openEHR, CDA, ISO13606, ODM, etc. which you can do with the LinkEHR studio 
> (FYI, the LinkEHR Studio version available on the website allows you to test 
> this mapping/transformation part, the only thing you won't be able to do is 
> to export the output XQuery transformation)
> 
> Regards
> 
> El vie., 14 dic. 2018 a las 11:19, Georg Fette ( <mailto:georg.fe...@uni-wuerzburg.de>>) escribió:
> Hello,
> I have just read the paper "Combining Archetypes with Fast Health 
> Interoperability Resources in Future-proof Health Information Systems", 
> in which the representation of openEHR archetypes as FHIR profiles is 
> presented. As I am also trying to use this approach and I wonder if 
> there are working and publicly available applications (possibly emerged 
> from the above mentioned research) that use that approach ? I am 
> especially interested in:
> - transforming openEHR archetypes into FHIR profiles 
> (StructureDefinitions) and storing them in a FHIR server.
> - transforming FHIR profiles into openEHR archetypes and storing them in 
> an openEHR server.
> - transforming openEHR archetype instances into FHIR resources (Bundles) 
> and storing them in a FHIR server.
> - transforming FHIR resources into openEHR instances and storing them in 
> an openEHR server.
> Greetings
> Georg
> 
> -- 
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de 
> <mailto:georg.fe...@uni-wuerzburg.de>
> -
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> <mailto:openEHR-technical@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
> 
> 
> -- 
>  <https://htmlsig.com/t/01C268PZ>
>   <https://htmlsig.com/t/01C47QQH>   <https://htmlsig.com/t/01C4DPJG> 
>   <https://htmlsig.com/t/01BZTWS7>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es <mailto:diebo...@veratech.es>
> yamp...@gmail.com <mailto:yamp...@gmail.com>
> VeraTech for Health SL 
> +34 654604676 
> www.veratech.es <http://www.veratech.es/>
> La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada 
> desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está destinada 
> a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le recordamos 
> que sus datos han sido incorporados en el sistema de tratamiento de VERATECH 
> FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos exigidos por 
> la normativa, usted podrá ejercer sus derechos de acceso, rectificación, 
> limitación de tratamiento, supresión, portabilidad y oposición/revocación, en 
> los términos que establece la normativa vigente en materia de protección de 
> datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011 Valencia o 
> bien a través de correo elec

Re: Two-level modelling diagram

[GF]

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 29 Nov 2018, at 11:47, Thomas Beale  wrote:
> 
> On 28/11/2018 17:56, Pablo Pazos wrote:
>> Do we need the user in the middle?
> we could, although I learned a long time ago to only include relevant 
> elements, and the point of this diagram is just one thing: where the models 
> of information are made, and how they relate to the built system. 
> 
What is needed is the last linking pin: the standardised Archetype patterns 
that are used to create libraries used to produce (local) Templates.
The RM allows too many degrees of freedom to model things.
We need a set of Modelling rules to create the set of standardised Archetype 
Patterns.

Patterns that provide models/metadata for living and non-living things (such 
as: buildings/rooms, devices, medicinal products, …)
Patterns that provide models/metadata for the documentation of medical  Care 
processes: Observation, Evaluation, Planning, Ordering, Execution.
Patterns that support co-operation, scheduling, etc.
Patterns that define absolute/relative times and locations
Patterns that define possible results in a quantifiable, semi-quantifiable or 
qualifiable way
Patterns that …




>> 
>> Another point, I always thought that diagram lacks some management, for 
>> instance the developer is not who manages the IT aspects of the system 
>> running in production, makes deployments, updates, etc.
> well then we are into the cycle of software management, I'm not trying to 
> represent any of that, just to show in a relatively simple way how the models 
> relate to the system.
> 
>> 
>> And thinking about this, there are at least two main flows: one is 
>> design-development-use, and the other is maintenance-evolution. I think the 
>> second one might be even more important than the first one, where domain 
>> experts get feedback from the users, and the IT team gets feedback from 
>> users and domain experts, for instance to make changes or create more 
>> reports or add UI elements. IMO this second flow is what gives openEHR a lot 
>> of value.
> also true - but I would make a second diagram to show UI / UX feedback loop 
> and evolution.
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_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-clini...@lists.openehr.org <mailto:openehr-clini...@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-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org