openEHR vs MDA/MDD & DSLs

[Gerard Freriks]

Dear Thilo,

When using tools based on a model.
when systems based on an other model,
are capable to define what gets stored, retrieved, presented and  
exchanged without writing code, software or concerting databases,
then I call this MDA, MDD for quite some time.

In openEHR ones can see what others are dreaming of.


Gerard

On 11, Apr, 2008, at 23:15 , Thilo Schuler wrote:

> Hi all, just wanna share this:
>
> For many of you this might not be something new, but today I
> consciously noticed to many analogies between the Model Driven
> Architecture (MDA) or Model Driven Development (MDD)  including the
> trendy Domain Specific Languages (DSL) with openEHR's two model
> approach (see attached png from
> http://www.omg.org/cgi-bin/apps/doc?omg/03-06-01.pdf ) Obviously the
> reasons are partly different (plattform independant code vs semantic
> interoperability - although the openEHR RM can also be implemented on
> all plattforms) but especially DSLs try to abstract domain models from
> technical domain.
>
> PIM Metamodel  => AOM (while ADL ist a textual DSL for it!)
> PIM => Archetypes and Templates
> PSM Metamodel => openEHR Reference Model
> PSM => Reference model instances.
>
> Cheers, Thilo



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080412/21396f73/attachment.html>

Archetype documentation using XML + XSLT

[Gerard Freriks]

The crux might be in the text in red.

Everything can be made to work.
A floating boat made out of match stick. Yes it is possible,
but not the bet engineering choice.
Perhaps XML is not the best choice in all circumstances.

What about ASN.1 isn't that a good alternative?
How about the tools?
Not as ubiquitous as those for XML.

Gerard

On 17, Apr, 2008, at 17:29 , Adam Flinton wrote:

>> There are many better ways to represent data for large-scale
>> deployments than XML (even the dADL syntax from ADL does 100%  
>> better in space,
>> and represents all object-oriented constructs unambiguously).
>>
> You have got to be kidding me on this one.
>
> Having done XML messaging in very large retail systems (major
> supermarket chains in the EU & US), mobile phone systems, home
> office/criminal justice system & now the CFHyou simply have got to
> be kidding.
>
> umm...where to even startoh yes how about...



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080417/7c9de242/attachment.html>

On Information and Interoperability

[Gerard Freriks]

Dear all,

The EHR is about documenting and archiving data and information  from  
a health/care process.
There are good well developed standards from the Documenters/archivers  
domain.
http://www.interpares.org/

Many requirements are defined that most messages do not address.
And most systems that rely on messages for communication do conform to  
the requirements from Interpares.
Requirements for messages that update data bases are never completely  
the same as those for ICT-systems that document data and information.
Data and information that is searchable, usable correctly  and safely  
after 20 years and surviving many changes in society and IT  
technologies.

Gerard




On 18, Apr, 2008, at 14:21 , Tim Cook wrote:

> I agree with your format vs. design comments there.  But, your  
> examples
> lead me to believe that you are still focusing on sending messages  
> with
> limited context and have not considered implications regarding storage
> and retrieval of healthcare information for decision support, public
> health analysis, etc.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080418/52856012/attachment.html>

XML Schema for the openEHR Demographics package?

[Gerard Freriks]

HI,

It is optional
as I happen to remember.

So when there is an archtyped one, so the better.

Standards are conservative documents.

Gerard


On 21, Apr, 2008, at 17:30 , Erik Sundvall wrote:

> P.s. Whatever happened to the demographics package when running it
> through the CEN standardisation-process? A brief look at the
> EN13606-spec gives the impression that they have hardcoded a number of
> field into theit RM instead of using archetyping, is this correct? Why
> on earth...?
> It even looked like there are no places to add new archetyped
> structures (like ITEM_STRUCTURE) anywhere in the 13606 demographics
> package, is this correct?
> __________



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080421/e1838a99/attachment.html>

Differential display

[Gerard Freriks]

HI,

Am I wrong to observe that the differential is not Display and Non- 
Display,
but Structured and Non-Structured?

The problem with the suggestions by Sam is that part of the  
information that is received is not visible.
In order to accept data from a third party I need to see and judge  
both the visible and invisible parts of the Template.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 18, Aug, 2008, at 7:06 , Sam Heard wrote:

> Dear All (cross post)
>
> We are working in an environment where many applications and CDA  
> messages have information that is displayed as text and repeated  
> information in structured form. This also arises in applications  
> which have a formatted document plus structured information  
> (typically in primary care).
>
> I am proposing that we have a section archetype to manage this. The  
> archetype display script would not display any information about the  
> section itself (it would be invisible) and would display the first  
> subsection but not the second. The section archetype would be:
>
> Differential display
> Display
> Entries here will display
> Non-display
> Entries here will not display
> This does mimic the CDA approach but does have the added benefit  
> that the displayed information can be structured as well (a  
> requirement from our customers who want to mix the textural content  
> and structured medication orders (ie not duplicate these in the  
> textural display).
>
> If this archetype arrived somewhere where it was not known the  
> generic display script would show the non-display information  
> (twice). This would be unlikely to cause errors especially as there  
> would be a heading Non-display.
>
> So that is the approach that we have considered. There is an  
> alternative - just have a non-display section. This has the  
> advantage that it could be added when required on an adhoc basis.  
> The major problem that I can see is that it would not be clear which  
> part of the record held the information that was redundant (ie where  
> it was being displayed).
>
> I would be interested in people's views of this approach to the  
> redundant structured data problem that arises from CDA and word  
> processor style record applications.
>
> Cheers, Sam
>
>
> Cheers, Sam

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080818/84ad2e06/attachment.html>

Differential display

[Gerard Freriks]

Hi,

I agree with Heath's opinion.
It is better to present both alternatives and let the application/user  
decide what he wants to see in reality.

But for admission to a record the rule must be: see and inspect both  
before accepting.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 19, Aug, 2008, at 2:05 , Heath Frankel wrote:

> I would suggest that duplication of data is better than accidently  
> hiding
> data, especially when the users are used to having two ways of  
> displaying
> the same data.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080819/80a48653/attachment.html>

text and description

[Gerard Freriks]

Thomas,

I do not have the details, but I know they use the CEN standard for  
registries.

Francois Mennerat will know more.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Dec 1, 2008, at 12:17 PM, Thomas Beale wrote:

> Gerard Freriks wrote:
>> Dear all,
>>
>> The European Institute for Health Records has created a registry of
>> coding systems.
>> In the (near) future they expect to be the place where coding systems
>> and their meta-information are registered so an URL and unique
>> identifying number will suffice.
>>
>> Will this be the way to go?
>
> I didn't know of this body. How does their registry correlate to the
> UMLS list? How do they handle revisions of terminologies? How do they
> handle language variants (including ones that are of earlier  
> revisions,
> or are partial)?
>
> - thomas beale
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081202/d2368708/attachment.html>

text and description

[Gerard Freriks]

Dear all,

The European Institute for Health Records has created a registry of  
coding systems.
In the (near) future they expect to be the place where coding systems  
and their meta-information are registered so an URL and unique  
identifying number will suffice.

Will this be the way to go?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 1, Dec, 2008, at 5:26 , Koray Atalag wrote:

> So custom/local terminologies can be handled this way and the  
> implementation will be left to developersBUT this may result in  
> different implementations which may render interoperability in the  
> long run
>
> So I suggest a sub-section within ontology section where used  
> terminologies are declared explicitly; i.e. "umls": 2008AA version  
> of NLM UMLS knowledge sources. Perhaps an URI and other details can  
> be specified (i.e. WSDL). I think it is easier for the community to  
> agree on such a naming convention.
>
> Custom local terminologies can be declared this way and you can  
> create terminology names for use in term/constraint bindings.Perhaps  
> creating a keyword (i.e. CustomTerminology) might be a good idea so  
> that these names do not interfere with formal names.
>
> Cheers,

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081201/b8d893a6/attachment.html>

Formal methods for Evaluation of Interoperability & Maintainability?

[Gerard Freriks]

HI,

Via the Url a PDF/presentation with some calculations.
No message standard, any message standard and the two-level-model  
paradigm, are compared.
http://tinyurl.com/26hlch

Gerard



On Feb 6, 2008, at 9:28 PM, Sam Heard wrote:

> Hi Koray
>
> I think we will have to come up with some metrics that are relevant  
> as it has not been done before in the domain space. Clearly  
> modelling at two levels is a common approach - relational databases  
> model the idea of tables with rows and columns, linking keys, data  
> types and indexes. The domain information is expressed in terms of  
> these rows and columns. Many systems driven on metadata do the same  
> thing. What is new about openEHR is a generic approach to allow any   
> base model to be constrained through the use of ADL. The result is  
> that the base model can reflect the general business rules and the   
> fixed information constructs - the archetypes the domain knowledge  
> and how it is represented in terms of the base model. The approach  
> relies only on getting sufficient expressivity at the base level to  
> make the split efficient and safe.
>
> The comparison in health care at present is with HL7 version 3. This  
> has a base model (RIM) from which a new model, an RMIM, is  
> constructed (level 2). The difference is that RMIMs are constructed  
> with alterations to the RIM classes (which are renamed). So we now  
> have a new class based on a pattern. The semantics of the RMIM is a  
> mixture of RIM and RMIM and difficult to untangle. CDA is using  
> templates in the same way as openEHR uses archetypes - to express  
> some domain content. As CDA is already committed to XML, the means  
> of further constraint is limited - hence the use of schematron and  
> other devices.
>
> I guess the first metric that we could consider is the speed at  
> which domain concepts can be modelled and the level of human  
> intervention for documentation and maintenance. The UK NHS, which  
> has the most experience of both, has found openEHR far more  
> efficient to use than MIF template constraints on HL7 CDA. Vendors  
> are cautious and have little experience of openEHR directly as yet.
>
> Clearly archetypes are of great use in systems that use the openEHR  
> Framework and allow use of operability constraints out of the box.  
> What about other vendor systems? Well, Ocean tools are being used to  
> produce inputs for vendors which are formal specifications of data  
> to be stored and communicated. The ability to reuse these artefacts  
> for many purposes - queries, transformations, display and data entry  
> provides another metric that is of use.
>
> We will need some large systems built on openEHR and traditional  
> approaches to compare in the future. For the moment, just having  
> clinical specifications that are computable is the main influence on  
> choosing openEHR - or starting from scratch as new vendors see the  
> benefits (or not).
>
> Cheers, Sam
>
>
>
> Koray Atalag wrote:
>>
>> Hi,
>>
>> I want to learn how we can formally/objectively prove that Archetype
>> based dual level development formalism alleviates problems of
>> interoperability and maintainability. I was wondering if someone  
>> did or
>> know of any such study which applies formal validation methods?
>>
>> Best regards,
>>
>> Koray Atalag, MD, Ph.D.
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>
>
> -- 
> Dr Sam Heard
> Chief Executive Officer
> Ocean Informatics
> Director, openEHR Foundation
> Senior Visiting Research Fellow, University College London
> Aus: +61 4 1783 8808
> UK: +44 77 9871 0980
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080207/9dd4321d/attachment.html>

Formal methods for Evaluation of Interoperability & Maintainability?

[Gerard Freriks]

Dear Koray,

A metric from real practice:
- Porting one application from its original database to Ocean  
Informatics EhrGate took two weeks.
Including the production of a SOAP and .Com interface of the interface  
of Oceans product.


Problems:
- How do you put figures to the fact that no longer data base  
conversions are needed?
- How do you put figures to the fact that no longer data is lost  
because of this?
- How do you put figures to the fact that without reprogramming  
Healthcare Providers are able to define themselves what data and  
information they have to store, retrieve, present and exchange and that
they do not need the help of the EHR-system vendor?
- How do you put figures to the fact that vendor lock-in is no longer  
an issue?
- How do you put figures to the fact that since products based on  
openEHR/Ocean are a generic tool instead of a proprietary product  
customized for a specific enterprise or department at great cost?
- How do you put figures to the fact that systems based on openEHR/ 
Ocean enable flexibly all ever changing work processes thereby  
facilitating innovation and market competition?
- How do you put figures to the fact that systems based on openEHR/ 
Ocean never enforces all users to use one set of messages based on one  
standardized business process?

Gerard

On Feb 7, 2008, at 10:03 AM, Koray Atalag wrote:

> Hi Gerard, a very useful document indeed...The approach is quite
> interesting and solid; no questions mathematically (at least in my MD
> mind!). I was thinking about brainstorming about finding some metrics
> (logical and feasible to experiment) to test those issues. Such as:
>
> Maintenance: comparison of lines of code during maintenance, frequency
> of support requests and time to fulfill them, user satisfaction  
> surveys,
> cost figures and so on for maintenance
>
> Interop: your points (i.e. # of interfaces to be implemented, # of
> messages and schemas), number of transactions, reused fragments,  
> number
> of hops during a shared care event (i.e. how many systems particular
> data (EHR extract?) travels, how many users access it and how.
>
> These are just initial thoughts and I am sure there are already better
> ones out there. I think, seriously, such studies would be very
> beneficial for community in convincing interested parties.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080207/c1e09084/attachment.html>

Formal methods for Evaluation of Interoperability & Maintainability?

[Gerard Freriks]

Koray,

What metrics do you want to define?

Gerard


On Feb 11, 2008, at 10:40 AM, Koray Atalag wrote:

> Dear All,
>
> I started this thread to get some feedback for finding methods/metrics
> to test & validate maintainability and interoperability (of Archetype
> based two-level apps). And I got very nice ones; however for
> interoperability, apart from Gerard's interface numbers I did not get
> any and interestingly from a quick literature survey I got very  
> little.
> I mean there are some indirect approaches but not straightforward. My
> case is a little more easier:
>
> 1) There is an up and running clinical IS developed with single level
> methodology based on an internationally agreed terminology including
> relationships and structure (domain knowledge let's say)
> 2) There is a complete Archetype model of this terminology using  
> openEHR
> RM which can comfortably be considered as a domain ontology (it has  
> more
> than what is given in terminology; i.e. existences, cardinalities)
> 3) These two can be said to have the same domain knowledge; ie. one
> hardcoded and one two-level modelled.
>
> Now can you think about a method to evaluate the interoperability
> levels/score of two systems?
>
> Do we need a remote system for benchmarking (i.e. connect and see how
> they interoperate)?
>
> Sorry to botherbut if we can get this straight perhaps we can
> express comfortably that a two-level app beats a single level app 7x  
> in
> maintainability and 5x interoperability. Or beats 2x HL7 system in
> maintenance but is beaten 2x in interoperablity.  Perhaps I am being  
> too
> naive but it is worth trying.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080211/90210170/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Hi,

Free text versus structured data and information debate:
- Like Ian said: Archetypes and templates take away problems from the  
IT-domain and leave them for those in healthcare.
When those in health need, want decision support they will have to use  
more structured info.
In the end they will solve their own problems.

- We, in the archetype world, will have to show the way.
Timo's thoughts are providing ways to think.
Archetypes used must be able to serve many purposes:
recording, retrieval, exchange, archiving and re-use for among others  
decision support.

- The boundary problem has to be solved.
Davids 'grey zone' must be reduced to a manageable small zone.
We can not change the past and must find ways to deal with pre- 
historic (pre-archetype) data.
In order to solve it we must look forward and reduce the 'grey zone'  
by acknowledging that most post-coordination (using modifiers in  
Snomed-space instead of Archetype/Template space) must end.

Gerard


On Jun 3, 2008, at 7:43 AM, Sam Heard wrote:

> Terminology
> A final part of the equation is the area that David Markwell has  
> been working on in the NHS in the UK. He is investigating how to  
> generate computable terminology code phrases from an archetype: that  
> is, how to post-coordinate information captured in an archetype for  
> inferencing in the terminology space. This has benefit in linking  
> with the pre-archetype data and may allow complex research to be  
> undertaken in the future using ontological tools and engines.
>
> So we need to keep the balance between freedom and structure,  
> recognising (as Ian McNicoll says) that good archetypes take the  
> problem out of the technical space to where it becomes a human (and  
> potentially soluble) issue.
>
> Cheers, Sam



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/d583d302/attachment.html>

openEHR Querying specifications

[Gerard Freriks]

Dear all,

The text below by Thomas warrants a conclusion:
- openEHR needs a (place in a) document that defines the correct  
wording and meaning of:
version and revision.

To my mind these words are to much similar and can generate confusions.
Alternatives:
Package (new Archetype that breaks the previous package archetype)  
plus conversion script from the Old to the New Archetype)
Version (new Archetype as the result of some editorial changes, only,  
not breaking the previous version)


Gerard

On Jun 4, 2008, at 10:23 AM, Thomas Beale wrote:

> The result of this is that new _versions_ of officially released
> archetypes should be very low in number and should always have a  
> formal
> definition of how to migrate data created using an older version.
>
> The confusing factor that people are seeing now is that due to the
> current tooling, most archetype authors are creating new 'versions'  
> when
> in fact the changes are only new revisions



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/4100af17/attachment.html>

openEHR Querying specifications

[Gerard Freriks]

I must disappoint you:

Dutch: Revisie, versie.

Gerard


On Jun 5, 2008, at 12:36 AM, Ian McNicoll wrote:

>
> BTW  What would be the equivalents in Dutch for Revision and Version?



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/ca46bf5d/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Ian,

I agree.
But my wished outcome is clear.

And of course we have to deal with the past.
But the sooner we, ...

Gerard

On Jun 5, 2008, at 12:48 AM, Ian McNicoll wrote:

> Hi Gerard,
>
> I agree with most of your comments and in principle that  "most
> post-coordination (using modifiers in Snomed-space instead of
> Archetype/Template space) must end", this amounts to heresy in a UK
> context and I think we should be prepared to regard David Markwell's
> Grey Zone as a contested area for some time. I think we could waste a
> lot of energy in trying to reduce the grey zone and might be better
> served by allowing dual-representation in both openEHR paths and
> Snomed post-coordination, and concentrating our efforts on the clearer
> areaswhere one approach is obviously better than the other. I would
> rather present Snomed-openEHR as the productive marriage of 2 noble
> families, whose sum is greater than the parts, whilst accepting that
> there will remain on-going jockeying for position in the 'border
> lands'.
>
> Ian (joyfully mixing his metaphors)



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/38e85b5f/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear colleague,

I agree with you that the grey zone is a relic from the past we have  
to deal with.
Never the less, I want to argue that we have to reduce this grey-zone.
By means of my suggestion to do post-coordination as much as possible  
in the archetype.

The main reason is:
- In language post coordination is done in the syntaxis and not in the  
dictionary.

Gerard

On Jun 10, 2008, at 9:37 AM, Daniel Karlsson wrote:

> Realizing that the current Snomed CT Concept Model is not enough  
> (today,
> unfortunately by far) and that the tools for supporting constrained
> post-coordination mainly are lacking, at least Snomed CT provides  
> *some*
> constraints on semantics in areas where openEHR provides none. Also,  
> the
> suggestion by David Markwell, I believe, is to represent semantics in
> Snomed space *as well as* in the archetype space.
>
> Also, I firmly believe that the "grey zone" will always exist as it is
> the result of the concurrent use of two different models of semantics.
> Thus, the boundary problem will not be "solved", rather we will have  
> to
> develop methods that makes the "grey zone" related problems less
> harmful.
>
> Regards,
> Daniel



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/31d12655/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

leslie,

I agree with the statement below.

Gerard

On Jun 10, 2008, at 10:06 AM, Hugh Leslie wrote:

> openEHR needs SNOMED and I believe that SNOMED needs archetypes.   
> The decision will be where archetypes and SNOMED should begin and  
> end and I think there will be a lot of debate in the next year or so!



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/7e3ed64c/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear  Daniel,

yes, I said that the grey zone is a relic of the past,
It is there and we have to deal with it.
But that is not to say that it must stay the same.

To my mind we have to be aware that when dealing with semantics and IT  
we must stay close to the eons proven way to do things.
For eons we have had as semantic ingredients:
- a list of words (nouns and verbs) plus modifiers (adverbs,  
adjectives): dictionary/vocabulary
- a syntaxis/grammar
- ways to define what makes sense.

The list of words/dictionary/vocabulary defined the concepts building  
block to be used in grammar.
Using words and grammar we could produce sentences and express what we  
had to express.
But we could produce sensical and non-sensical combinations of words  
and grammar in sentences.
Therefor we had ways to select and use only the sensical sentences.  
And these are archetypes and templates.
Archetypes and templates -in addition- provide the patterns (types of  
sentences) that can be used in healthcare to document observations,  
evaluations, instructions, and actions.

We must think very carefully whether it is wise to have two grammars  
at the same time.
Archetypes and templates have on one hand the role of grammar and the  
pattern used for documenting.
What is a compelling reason to combine the role of a code-list with  
that of grammar in SNOMED?
Does SNOMED have a rich enough grammar?
As rich as archetypes and templates allow?
Does it has a way to deal with patterns?

Isn't it a solution for the grey zone problem to accept that from now  
on we use SNOMED as a code list / vocabulary, that eventually helps us  
reasoning because of the ontological features?
And that archetypes and templates are the grammar and the expression  
patterns?
Coding systems are a fact of life.
Archetypes and templates are a fact of life.
Both need a natural role.

Isn't this suggestion the most practical way to deal with the grey  
zone in the future?

Gerard

On Jun 10, 2008, at 9:55 PM, Daniel Karlsson wrote:

> I didn't say that the grey zone is a relic of the past but, quite
> differently, a fact we need to acknowledge and relate to. The main
> reason: terminologies are not just merely dictionaries but make
> assumptions of semantics that interact with assumptions of semantics
> made in archetypes. Also, in terminological languages, representations
> of the semantics may be processed formally.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/da7e5c9f/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Hi,

The way I like to think about it is that there is a generic archetype  
for lab-tests as a recurring 'pattern'.
Each individual lab test procedure is a code from a general coding  
system.
The way Lab-test are reported (quantitative data, in what units of  
measurement, precision, normal value ranges, semi quantitative data,  
in what ordinal scale ,etc, etc) will be 'codes' as well, but this  
time from the Laboratory Resource Description System.

The 'patterns' will probably be a special type of Archetype that is of  
the cluster nature.
Batteries have  Template nature.

Gerard



On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote:

> Hi Daniel
>
> I was just using that as an example where its not always useful to  
> code everything.  I certainly wasn't trying to say that its not  
> useful to code anything and the example that you give is where it is  
> useful to code.  I was just pushing back against those that want to  
> code everything as I believe that we need to code those things that  
> make sense.
>
> In terms of battery archetypes, thats another problem because  
> batterys tend to vary between labs (certainly here in Australia  
> anyway.)  I would expect that it might be templates that solve this  
> problem with the archetype providing something more generic.  Coding  
> of the analytes would then make sense so that you can compare  
> different result sets.  This could be also solved by producing  
> archetypes for each analyte and then reusing them for different  
> batteries.  This would then mean that P-ALAT is the same archetype  
> where ever it is used.  Personally, I think the coded solution is  
> better here as we would have fewer archetypes to manage.
>
> regards Hugh



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080613/37cb8174/attachment.html>

Archetypes - regex question

[Gerard Freriks]

William,

It is  potentially dangerous ground.
But ...

-  Archetypes express what can be documented about a specific topic.
Since such a 'Real Archetype' can or will consist of re-usable  
patterns, 'Real Archetypes'  consist many times of a collection of sub- 
archetypes that express recurring patterns of documentation.
In other words archetypes can and will be nested.
And there must be a way to specify what archetypes are part of the  
ensemble at what spots.

- It will create the problem for Archetype Governance.
We need to have rules and ways to manage and enforce them.
This needs a tool.
Ocean Informatics, for this purpose, has developed the Archetype  
Knowledge Manager.

Gerard


On 14, Jun, 2008, at 7:31 , Williamtfgoossen at cs.com wrote:

>
> We are getting into dangerous options here: include all and exclude  
> all in a time series where 'all' definitely changes both with  
> respect to revisions of the existing ones, deletions and new to be  
> added might lead to inconsistent calls to archetypes over time.
>
> I believe such constraining should not take place on the archetype  
> over archetype level, but at the (OpenEHR) template level. In here  
> you can be explicit in what is to be included or excluded.
>



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/8845ef4a/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear all,

It is all about patterns for documenting.

I agree that inspection of the present collection of openEHR  
archetypes and those produce by the NHS are a nice resource.
But we must realize that these were produced for demonstration,  
testing, learning or the collection of information requirements.
The Templates and Archetypes we need must be designed for semantic  
correct, reusable, patient safe recording, retrieval, exchange and  
archiving in mind.
A complete new set of scopes that need explicit requirements.

- Patterns are to be re-used and aggregated in other archetypes or  
templates.
Question: What are the rules to be applied to make that decision?

- A pattern will need a new specialization only when new things have  
to be added to the original pattern.
Question: What are the rules for to decide when  to specialize or when  
to add a new item to the original archetype and create a new version?

- What patterns do we have to have in order to be able to document  
what we need to document?
Will we find the answer when we look at the language aspects of what  
we document?

- Some Archetypes document complex notions.
For example: the Barletts Index.
It is  a collection of Observations about a patient system.
Each of these observations can be recorded using a documentation  
pattern.
The aggregation of observations is expressed as a number using an  
algorithm.
This aggregation is named the Bartletts Index.

All of the observations can be documented using separate archetypes  
using semi-quantitate patterns.
The algorithm can be documented in whatever format.
The result is documented using a semi-quantitative pattern,
either on its own as the professional opinion of the healthcare  
provider,
or as the result of the application of the algorithm, as substitute of  
the healthcare providers subjective estimation.

So the Bartletts Index can be a subjective statement of the class of  
Evaluation Archetypes based on Observations,
or the a subjective statement (Evaluation) by a healthcare provider  
without any reference to feeding observations,

What will we do when new observation elements are added to the  
Bartletts Index?
What will we do when a new algorithm is used to do the calculations?

Is this line of reasoning not leading to the following statements:
Observations are observations and end  up in Observation Archetypes  
and are recorded in the EHR, as such.
The Bartlett Index is a derivative that either is an Evaluation of  
Risk expressed as the ARchetype Index as perceived by the documenting  
healthcare provider,
or, the Bartletts Index is a formalism (algorithm) applied to a set of  
documented Observations leading to a risk index that has to be  
documented as an Evaluation.

I might even argue that the Bartletts Index is an agreed Common  
Template to express risk for the new born, that could change over time  
as it is the result of present opinions that can change.
This means that there are two versions of the Bartlett Index that  
express the same notion.
One is the professional opinion of the risk for the newborn by the  
healthcare provider is a certain number.
And that the risk is calculated by a specified algorithm using a  
defined set of observations.

Question: Is the Bartlett Index an Observation or an Evaluation?
Question: Are there two kinds of Indexes?
Question: Is the Bartlett Index an Archetype or Template?

Or more general:
Are Archetype about recording patterns?
Are Templates about context (location, time and culture) dependent  
collection of constituting archetypes?

Gerard













On 14, Jun, 2008, at 15:55 , Thilo Schuler wrote:

> Looking at the openEHR archetype repository, there is a generic lab
> archetype and several specialiced ones based on it. However, it seems
> to me that the specialisations were done mainly to create "battery"
> type lab results structures (e.g. laboratory-liver_function) I think
> keeping the lab archetype to one analyte and aggregating them in a
> template would be cleaner and better from a query perspective.
> Specialisations of the generic lab archetype should only be used to
> add a field that is missing for an unkonventinal lab test.
>
> What do you think?
>



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/1a2f5da0/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear Tmo,

I'm glad that you agree about 'patterns for documentation' as  
presented by Archetypes.

And yes. The archetype approach will enable us to have an ever  
evolving way of express new things or in new ways.
But in the end we need an atomic concept that we will always use in  
our thinking.
And this concept to my idea is the 'documentation pattern' as an  
almost never changing, stable element, we can reuse all the times.

A collection of Documentation Patterns and codes from coding systems  
will become these 'atomic' elements.

Gerard



On 14, Jun, 2008, at 18:10 , Thilo Schuler wrote:

> Obviously, this needs a good governance structure (like oceans
> knowlege manager environment). And certain basic patterns should be
> provided as role models to stimulate the process and avoid too many
> "beginners mistakes". This is what we - early clinical users with some
> technical insight - should  come up with.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/d1923106/attachment.html>

Question on the role of EHR reference models for achieving functional interoperability

[Gerard Freriks]

Dear Georg,

-1-
When interpreting text from standards it is a useful practice to look  
at the definitions.
3.9
electronic health record (EHR) - for integrated care (ICEHR)
a repository of information regarding the health status of a subject  
of care in computer processable form,
stored and transmitted securely, and accessible by multiple authorised  
users. It has a standardised or
commonly agreed logical information model which is independent of EHR  
systems.  Its primary purpose is the
support of continuing, efficient and quality integrated health care  
and it contains information which is
retrospective, concurrent, and prospective
3.10
electronic health record (EHR) ? basic generic form
a repository of information regarding the health status of a subject  
of care, in computer processable form
NOTE The definition of the EHR for integrated care in 3.9 should be  
considered the primary definition of an electronic
health record.  The definition of a basic-generic EHR is given only  
for completeness and to acknowledge that there are still
currently many variants of the EHR in health information systems which  
do not comply with the main (ICEHR) EHR
definition (e.g. a CDR complies with the basic-generic EHR definition  
but not with the ICEHR definition)

3.27
shareable EHR
an EHR with a commonly agreed logical information model
NOTE 1 The shareable EHR per se is an artefact between a basic-generic  
EHR and the Integrated Care EHR (ICEHR)
which is a specialisation of the shareable EHR. The shareable EHR is  
probably of little use without the additional clinical
characteristics which are necessary for its effective use in an  
integrated care setting.
NOTE 2 Whilst the ICEHR is the target for interoperability of patient  
health information and optimal patient care, it
should be noted that the large majority of EHRs in use at present are  
not even shareable let alone having the additional
characteristics required to comply with the definition of an  
Integrated Care EHR.  A definition of a basic-generic EHR has
therefore been included to acknowledge this current reality.


It is clear to me that they defined the EHR as what is called the  
'Sharable EHR'.
Within the light of this definition to have the Reference Model is a  
requirement.

-2-
3.25
semantic interoperability
the ability for information shared by systems to be understood at the  
level of formally defined domain concepts
Semantic Interoperability is more than functional interoperability.
For the latter a piece of written paper or a PDF is enough.
In ISO 20514 one is clearly dealing about full semantic interoperability

-3
When a thing is required most often this is not sufficient by itself.
Other requirements have to be fulfilled in addition.
For semantic interoperability we need terminologies and ways to  
express sensible things in a context (archetypes and templates).
We need in addition a syntax and this is the Reference Model.

-4-
What they actually write and describe as pre-requisites is:
In order to achieve semantic interoperability of EHR information,  
there are four prerequisites, with the first two
of these also being required for functional interoperability:
a) a standardised EHR reference model, i.e. the EHR information  
architecture, between the sender (or
sharer) and receiver of the information,
b) standardised service interface models to provide interoperability  
between the EHR service and other
services such as demographics, terminology, access control and  
security services in a comprehensive
clinical information system,
c) a standardised set of domain-specific concept models,  i.e.  
archetypes and templates for clinical,
demographic, and other domain-specific concepts, and
d) standardised terminologies which underpin the archetypes. Note that  
this does not mean that there
needs to be a single standardised terminology for each health domain  
but rather, terminologies used
should be associated with controlled vocabularies.

In the context of all definitions I read that EHR-systems that have  
only a Reference Model and Service Interface models can interoperate  
at the functional level.
And this is true.
When systems store information using the CEN/openEHR Reference Model  
there is enough information from the RM to represent the data in a for  
humans understandable way.
It then acts exactly as a PDF!
Humans when reading PDF's can interpret only because of their shared  
implicit underlying Reference Model that we know by the name: Syntax  
of language.

WIth regards,

Gerard Freriks

On 24, Jun, 2008, at 12:16 , Georg Duftschmid wrote:

> Dear all,
>
> I would like to ask you for your opinion on a statement in ISO/DTR  
> 20514 (Definition, scope and context of the EHR), which says that  
> "[...] a standardised EHR reference model is required for achieving  
> functional interoperability [...]" (page 7 of ISO 20514).
>
> Functional interoperability is defi

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

Dear all,

Archetypes are Documentation Patterns for clinical and non-clinical  
topics.
Templates are Documentation Patters used in a specific context. They  
can be considered as agreements/contracts on what to show, store, and  
exchange.
How that content of a Template is represented on the screen is the  
topic of this discussion.

On one hand: Keeps things simple. And things are simple when we  
separate as much asp possible. We separated IT from data and  
Information and it  makes a lot of sense to separate presentation of  
that data and information as well.
On the other: Objects consist of three things: Information, Methods  
and Representation. And the information and representation parts carry  
semantics.
Information represented in black is not the the same as when  
represented on a screen in RED or in CAPITALS or flickering.

Thinking about it:
Data and Information- Arche-Types (and Templates)
Presentation: Presentation-Types
Methods: Method-Types

Each Type its own tool, Model and Language
Plus one tool that integrate all three aspects of the Object.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 27, 2008, at 8:58 AM, Erik Sundvall wrote:

>> One thing I noticed in the conversion that I don't have any way of
>> distinguishing between a line of text and multiline text in the
>> archetype (I would generate an appropriate pane in the latter case).
>> Perhaps not a big deal.
>
> This might be a useful requirement for the current template
> specification currently being worked on, or possibly a new kind of
> related specification.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/783d9c35/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

Heather,

You are correct.
Do not mix things.
Tools become to complex.
And healthcare providers loose focus.

When designing archetypes we see the archetype screen.
When designing and discussing templates we see the template screen.
But when discussing data entry and data presentation screens we see  
them.

For each its own tooling and ways to present.

Thinking about the presentation aspect:
- There are several levels:
- parts of the data/information that display urgent matters that have  
to be signaled and that this fact needs to be documented.
- local arrangements that deal with conditional context dependent  
presentation, the functionality of a electronic form
- local arrangements that deal with local preferences on location on  
the screen, presentation forms, fonts, colors, etc.

Gerard

--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 27, 2008, at 2:40 PM, Heather Leslie wrote:

> Hi all,
>
>> From where I sit the issue being discussed here is an old one  
>> essentially
> about human nature - we all respond most easily to that which we  
> know and
> understand.
>
> In designing a website we know that if you want input about  
> navigation, then
> don't have any meaningful content or GUI hints available or almost  
> certainly
> all the feedback will be about the size or color of the button and  
> the font
> and position of the heading.
>
> Similarly my concern in designing templates and getting the content  
> reviewed
> appropriately is that as soon as you add interface/GUI features to  
> make it
> more 'intuitive' to the clinicians their focus goes immediately to  
> that
> which is more familiar.  That is, the feedback tends to be related  
> to their
> user interface experience (naturally gained from their day-to-day  
> use of
> their current clinical system) rather than actually critiquing which
> archetypes have been used, which data fields are presented, and all  
> their
> associated attributes, cardinality, constraints and related metadata  
> etc
> etc.
>
> So my preferred response (and from positive experience) is to spend a
> relatively small amount of time to educate the clinicians on how to  
> feedback
> appropriately and meaningfully on the pure archetypes and templates  
> - we
> have done this successfully, but I suggest it is probably optimal if a
> clinician involved in the design (perhaps a health informatician  
> with a leg
> in 'both camps') to walk them thru the models and to make it a  
> sensible
> conversation.  It is my opinion that the GUI design and review  
> should be
> completely separate to the content design and review - mixing the  
> two gets
> very confusing.
>
> Regards
>
> Heather

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/02f94708/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

My spectrum:

- Archetypes (generic documentation patterns)
- Templates (context dependent documentation patterns)
- Generic User Interfaces (generic presentation patterns)
- User Interface (context dependent presentation patterns)

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 30, 2008, at 3:19 PM, Erik Sundvall wrote:

> Hi!
>
> Thanks for a lot of interesting response regarding "GUI-hints" and  
> other things.
>
> Please excuse a little left-to-right analogy below:
> There seems too be a scale or spectrum of detail level and use case
> specificity going from...
> Left: purely semantic (maximum data set) models = archetypes
> ...via the nearby...
> openEHR templates (still purely semantic if we skip the "hide_in_ui"
> to keep the template artifacts)
> ...further far away to...
> Right: actual GUI in an implemented system with specific widgets  
> positioning etc
>
> Currently openEHR specifications describe artifacts at the "left" side
> of the spectrum. This discussion has interestingly been broadened
> further to the "right" than I was thinking of in my initial questions.
> If we look at a tool like the Template Designer from Ocean Informatics
> there is an immediate jump from templates (close to the left) to
> detailed GUI layout (far right), that jump could be divided into more
> steps (possibly with some steps persisted and reusable) as suggested
> by some in this discussion.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080630/6c380501/attachment.html>

Security & Privacy with openEHR

[Gerard Freriks]

Dear colleague,

In Europe there is a European Directive (law) on privacy.

The European standard for the EHR (CEN/tc251 EN13606 and also an ISO  
standard by now) has incorporated several other European and ISO  
standards:
- ISO 18308: requirements for EHR architectures
- ISO 22600 Privilege Management and Access Control
- CEN EN 13606 part 4

It is for these reasons that European based EHR standards are unique  
because Patient Safety and Privacy are part of the design requirements  
from the start.

For more information search the CEN and ISO standardization  
organisation websites.
To few people from the USA do that.

Gerard Freriks


On 14, Mar, 2008, at 18:52 , Kudakwashe Dube wrote:

> Hi All,
>
> I'm just beginning a research project on
> security/privacy/confidentiality in EHRs. I will greatly appreciate  
> any
> pointers to any material on this topic, especially with respect to
> openEHR.
>
> I've just noted that in the US, HIPAA is driving
> security/privacy/confidentiality implementations in existing EHR  
> systems
> and it seems its is turning out to be a policy/framework-level  
> security
> standard for EHRs in the US that does not prescribe implementation
> issues. I am not sure whether or not EHR standards that incorporate
> HIPAA compliance have emerged yet.
>
> In the EU region, the situation seems different in the absence of
> HIPAA-type punitive legislation for enforcing healthcare information
> security and privacy. A number of EHR standards generally incorporate
> security and privacy considerations. I am not sure whether there are  
> any
> security and privacy compliance requirements spec standards and
> implementation (incl. openEHR) in the EU region. I will appreciate any
> pointer to material in this regard.
>
> Thank you in advance
>
> Regards
> 
> Kuda



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080314/b94f08d3/attachment.html>

Please respond by Friday Nov 7th: Deployment, Version, PATIENTS IN SYSTEM.

[Gerard Freriks]

Perhaps you have not noticed

The question was about Open Source and not about commercial  
proprietary ehr systems

Gf

Sent from my iPhone

On 6 nov 2008, at 20:07, "Norbert Lipszyc"  wrote:

> The dbMotion solution, developed in Israel, is today covering nearly  
> 6 million patients in Israel, and 7 million patients in the UPMC  
> installation in the US.
> Norbert Lipszyc
>
> De : openehr-technical-bounces at openehr.org 
> [mailto:openehr-technical-bounces at openehr.org 
> ] De la part de Dr. Irving Buchbinder
> Envoy? : jeudi 6 novembre 2008 16:04
> ? : For openEHR technical discussions
> Objet : Re: Please respond by Friday Nov 7th: Deployment,  
> Version,PATIENTS IN SYSTEM.
>
> Ignatio
>
> Does ANYONE list his/her numbers of patients hosted by the system? I  
> tried to find that number for several larger commercial systems and  
> got the MdD's answer of milliions and milliions (of patients) ... I  
> could find the number of doctors rather easily.
>
> Irv Buchbinder/ FreeMED
>
> On Thu, Nov 6, 2008 at 9:53 AM, Ignacio Valdes   
> wrote:
> Hello all,
>
> The un-official, Draft 8 of the upcoming American Medical Informatics
> Association Open Source Working Group white paper to be voted on
> November 9th can be found http://ignaciovaldes.com/amia. It will be
> voted on for ratification on November 9th-11th or so. Action is needed
> on your part to answer the question: If open source is so great why is
> no one using it? There is no aggregate data that I can find to counter
> this opinion. If you know of a Free/Open Source EHR/EMR deployment and
> could please send three pieces of information on each deployment that
> you have by Wednesday November 7th: General Location, software version
> and most importantly NUMBER OF PATIENTS IN SYSTEM. This paper could
> have national impact with this data. Please respond by email to
> ivaldes at hal-pc.org if you are able to obtain this data.
>
> -- IV
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> -- 
> -- 
> Irving J. Buchbinder, DPM, DABPS
>  Director, FreeMED Software Foundation, INC
>  -=Technology advances. People stay the same=-
>  Leigh  
> Rubin
> skype at irvbuchbinder
>
> *** E-MAIL CONFIDENTIALITY ***
> This e-mail may contain confidential and proprietary material for   
> Any review or distribution by others is strictly prohibited.  If you  
> are not the intended recipient  please contact info at freemedsoftware.com 
>  and delete all copies.
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 

Please respond by Friday Nov 7th: Deployment, Version, PATIENTS IN SYSTEM.

[Gerard Freriks]

Bert,

What is the definition of 'closed system'?

When open=not-closed.

Is open source open?
Is a system based on a standard and its implementable specification  
open, also?

Is an essential attribute of 'openness' that the software is open?
Or is an essential attribute  of 'openness' that the data base is open?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Nov 6, 2008, at 10:00 PM, Bert Verhees wrote:

>> The question was about Open Source and not about commercial
>> proprietary ehr systems
> Sorry Gerard, there were more closed systems discussed under this  
> topic.
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081106/5ea9a19e/attachment.html>

Why is the editor not opening ADL files?

[Gerard Freriks]

Shouldn't we consider to extend the Demographics to  Resources?

Isn't a person one of many types of resources we need to document in  
and around the EHR?
(e.g. devices, catalogs with lab tests or procedures, rooms, beds, ad- 
hoc lists, etc)

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 5, Apr, 2009, at 11:13 , Thomas Beale wrote:

>
> General principles:
> EHR:
> clinical data
> clinically relevant demographic details, e.g. sex, date of birth,  
> occupation
> but otherwise, identifying information, and even patient id(s) can  
> be avoided completely in the openEHR EHR, or they can be put in; see  
> Common IM for discussion 
> -http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf
> clinically relevant admin data, e.g. admission, discharge, transfer,  
> birth, death, 
> Demographic:
> demographic data of any complexity, including personal contact  
> information, professional qualifications
> relationships, typically for relating professionals together into  
> teams, groups and to employing organisations
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090405/2335c793/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Derek,

Shooting?
No.
I agree with you.
And I disagree.

I think that there are clinical  informaticians that know, implicitly  
or explicitly, about semantics, about language and the philosophical  
aspects.
At least clinicians and nurses do (and most patients and other people)  
since they communicate using voice, writings and gestures.

The problem is that technicians do not understand semantic  
interoperability.
And I must say that many informaticians are actually technicians  
without any understanding of semantics.


Gerard



On 21, Apr, 2009, at 16:17 , Derek Meyer wrote:

> Dear List People,
>
> Another view, and my two (euro) cents, for what they are worth:-
>
> There are many philosophical difficulties in the concept of semantic
> interoperability which technology cannot address. Put simply, semantic
> interoperability requires an agreement on meaning, and meaning is  
> not a
> 'thing'.  Semantic interoperability requires uses of a system to think
> in the same way - or at least in mutually understandable ways - and
> informaticians do not (yet) have the power to change the ways people  
> think.
>
> So semantic interoperability is a kind of philosopher's stone. The
> search for the original philosopher's stone, which could turn base  
> metal
> into gold, simply showed that alchemists misunderstood chemistry and
> sub-atomic physics. Maybe the search for  semantic interoperability
> simply shows that informaticians misunderstand linguistics and the
> nature of knowledge.
>
> OK - you can shoot me down now..
>
> Derek.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090421/9a5b3072/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Graham,

Exactly.
Somewhere there is a paradox.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 21, Apr, 2009, at 21:43 , Grahame Grieve wrote:

> Hi Gerard
>
> Who does understand semantic interoperability?
> The beauty of human interaction is that we can
> get along even without understanding each other.
> And we?ll never get computers to understand each
> other. So we shouldn?t aim for semantic interoperability,
> we should aim for unsemantic interoperability
>
> ;-)
>
> (kudos to the Health IT Nerd)
>
> Grahame
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090421/9dd50288/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref,

Ask yourself the question:
How do we, humans, deal with interoperability?

Do we humans use formally expressed ontologies using OWL.
Do we use rigid formal syntaxes where we use strictly defined formal  
terms.
Do wet have to express a measurement in DV-Quantity as Double or  
Floating Point with Precision x.
All this is the world of zero's and one's, bits and bytes and IT  
industry.

We humans have a vague knowledge of many concepts in our worlds.
We have a very flexible syntax and many, many terms. We even invent  
new ones.
It is a chaotic system based on a limited set of rules with emergent  
behavior.
We express what we want to document using documents, chapters,  
sections, paragraphs, words and characters.
This is the world of documentation, concepts, humans.
This the magnificent world of language, prose and poetry.
Where on the basis of a limited set of rules we can document everything.

It is clear that both worlds (IT and Humans) overlap in certain areas.  
But mostly the do not overlap.
Do not mix them up and when you do, we get confused and create monsters.
Both worlds have to stay absolutely orthogonal to each other.

Any interoperability solution where notions, ways of thinking and  
expressing, from the IT world with bits and bytes are enforced on  
humans, will create problems.
Solutions should start at this human documentation/language level.

The EHR is about documentation of events/facts/thoughts/ideas for  
human consumption primarily.
IT-systems should support this. That is all we need for now.
We can try to model real life using the formal, rigid, technical ways.  
And create something that doesn't fit the needs of humans or relates  
to this human world.
Or we use IT and models to support humans to document what they feel  
they need to document.
Humans are not very precise but language works rather efficiently and  
well enough.

Modeling knowledge in ontologies is an interesting academic exercise.
Modeling the complex real life is an interesting academic exercise.
But...
Let humans use words freely, either as free text of better from a  
common controlled flexible resource (dictionary=coding system/ 
terminology/classification).
Let humans use words in a syntax (Reference Model) to create freely  
all sentences/screens (Templates) they need using agreed documentation  
patterns (Archetypes), using tools based on an Archetype Model.

And that for the moment is good enough at this point in time looking  
for the Holy Grail called Semantic Interoperability.

Gerard


On 21, Apr, 2009, at 12:25 , Seref Arikan wrote:

> Dear members of the list,
> I'd appreciate your opinions and guidance about a particular topic.  
> As most of you probably know, the work in the ontology domain has  
> been the flagship of semantic interoperability for many projects  
> now, and there is a large amount of researchers active in the field.
> I've been involved in use of ontologies for semantic  
> interoperability for the first time in 2002, and since then,  
> ontologies have become a frequently pronounced solution for a large  
> set of problems.
> However, I have a feeling that the nature of this work creates just  
> a layer in the multilayer interoperability space. Expressing  
> relationships among different entities and doing this in a formal  
> way (OWL) is nice. OWL also allows you to do processing, reasoning  
> on the defined relationships, but unless I'm missing something, this  
> is all about relationships, and concepts. I mean the capabilities of  
> OWL seem to be valid in the relationships is defines.
> What about the actual things, data items, entities that OWL links  
> together? I've been a proponent of well defined type systems and  
> object hieararchies in healthcare interoperability solutions, since  
> I've spent years in the software development side of the domain, and  
> a huge number of issues arise from the developers interpreting  
> losely defined types, or inventing their own types.
> Now pinning down concepts either by using terminologies or  
> ontologies is good. It is good to know that two fields on two  
> different data structures are pointing to the same concept. This  
> however, is the beginning of the process. Pointing at the same thing  
> and processing it in the same way are different things. Just because  
> we agree that we are pointing to body temperature in two different  
> documents does not stop us from processing one of them with a  
> double, and the other one with a float.
> There is a great deal of information out there expressed in the form  
> of OWL, or other formalisms, but I can't see this covering all  
> aspects of interoperability, but (no offense) there is a large crowd  
> out there who think they have solved the problem of semantic  
> interoperability. Though it may be an undervaluation of the work,  
> "mappings" are nice, but they don't ease the rest of the work, where  
> mapped items are processed in different domains

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref
As a more technical continuation:
When ontologies and syntaxes are orthogonal the two meet in one place
At that spot on the syntax will refer to a code from a coding system  
(terminology, classification, code list)
Technically it boils down to how semantically correct and safe can we  
define this reference?

Ontologies can play a role in the prlduction of codes

Gerard


Sent from my iPhone

On 22 apr 2009, at 15:26, Seref Arikan  wrote:

> I am happy to see responses in the non-technical level too. Well, in  
> case someone has a technical comment regarding binding ontologies to  
> archetypes and openEHR RM objects, I'll be around :)
>
> Kind regards
> Seref
>
> On Wed, Apr 22, 2009 at 12:06 PM, Ian McNicoll  oceaninformatics.com 
> > wrote:
> Can I suggest moving this to the Clinical list? I think it is an
> important subject ,and rather dear to my own interests but, as Thomas
> pointed out, we are in danger of submerging Seref's original more
> technical question.
>
> Any objections?
>
> Ian
>
> Dr Ian McNicoll
> office / fax  +44(0)141 560 4657
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian at mcmi.co.uk
>
> Clinical Analyst  Ocean Informatics ian.mcnicoll at oceaninformatics.com
> BCS Primary Health Care Specialist Group www.phcsg.org
>
>
>
> 2009/4/22 Gerard Freriks :
> > Dear Seref,
> >
> > Ask yourself the question:
> > How do we, humans, deal with interoperability?
> >
> > Do we humans use formally expressed ontologies using OWL.
> > Do we use rigid formal syntaxes where we use strictly defined formal
> > terms.
> > Do wet have to express a measurement in DV-Quantity as Double or
> > Floating Point with Precision x.
> > All this is the world of zero's and one's, bits and bytes and IT
> > industry.
> >
> > We humans have a vague knowledge of many concepts in our worlds.
> > We have a very flexible syntax and many, many terms. We even invent
> > new ones.
> > It is a chaotic system based on a limited set of rules with emergent
> > behavior.
> > We express what we want to document using documents, chapters,
> > sections, paragraphs, words and characters.
> > This is the world of documentation, concepts, humans.
> > This the magnificent world of language, prose and poetry.
> > Where on the basis of a limited set of rules we can document  
> everything.
> >
> > It is clear that both worlds (IT and Humans) overlap in certain  
> areas.
> > But mostly the do not overlap.
> > Do not mix them up and when you do, we get confused and create  
> monsters.
> > Both worlds have to stay absolutely orthogonal to each other.
> >
> > Any interoperability solution where notions, ways of thinking and
> > expressing, from the IT world with bits and bytes are enforced on
> > humans, will create problems.
> > Solutions should start at this human documentation/language level.
> >
> > The EHR is about documentation of events/facts/thoughts/ideas for
> > human consumption primarily.
> > IT-systems should support this. That is all we need for now.
> > We can try to model real life using the formal, rigid, technical  
> ways.
> > And create something that doesn't fit the needs of humans or relates
> > to this human world.
> > Or we use IT and models to support humans to document what they feel
> > they need to document.
> > Humans are not very precise but language works rather efficiently  
> and
> > well enough.
> >
> > Modeling knowledge in ontologies is an interesting academic  
> exercise.
> > Modeling the complex real life is an interesting academic exercise.
> > But...
> > Let humans use words freely, either as free text of better from a
> > common controlled flexible resource (dictionary=coding system/
> > terminology/classification).
> > Let humans use words in a syntax (Reference Model) to create freely
> > all sentences/screens (Templates) they need using agreed  
> documentation
> > patterns (Archetypes), using tools based on an Archetype Model.
> >
> > And that for the moment is good enough at this point in time looking
> > for the Holy Grail called Semantic Interoperability.
> >
> > Gerard
> >
> >
> > On 21, Apr, 2009, at 12:25 , Seref Arikan wrote:
> >
> >> Dear members of the list,
> >> I'd appreciate your opinions and guidance about a particular topic.
> >> As most of you probably know, the work in the ontology domain has
> >> been the flagship of semantic interoperability for many projects
> >> now, and there is a large 

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref,

HL7 made serious mistakes.
They used the RIM to model the real world events and documentation  
about it.

Mixing two different types of models is impossible.
The best that can happen is that in one model-world one refers to  
constructs in the other world.

Models of reality.
Ontologies are models of reality and in semantic interoperability we  
use them to construct lists of codes, labels and descriptions.
Because of the ontology we are able to make inferences, to express  
knowledge behind the lists of codes, labels and descriptions.
Because of the ontologies we are able (eventually) to make  
applications more intelligent and kind of let them reason.

Models of documentation.
EN13606/openEHR and HL7v3 CDA are models that help people document  
data and information.
It helps them archive, exchange and re-use.
All data and information stored, is stored with all contextual  
information and meta-information about the documentation process.
Models of documentation store data and information in named chapters,  
sections, paragraphs.
They allow users to write complex sentences, using documentation  
patterns humans agreed upon.
They use words from dictionaries (coding systems, terminologies,  
classifications and code lists).
They never map to ontologies. Should never map to ontologies and vice  
versa.

Any attempt to try to map Ontologies to Syntax structures is bound to  
fail.
It is squaring the circle.

Gerard

--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Apr 22, 2009, at 11:06 PM, Seref Arikan wrote:

> Hi Charlie, a couple of good points! Comments are inline.
>
>
> I am working on how the NHS Logical Record Architecture (LRA)  
> asserts conformance/compliance to external standards.   One thing  
> that is required is a semantic mapping between the LRA  
> specifications and the external standard.  Initially I am mainly  
> interested in mapping the static models. (Reference models,  
> datatypes, templates, archetypes, etc)
>
>
> Great starting point. My question is: let's  assume you'll have the  
> complete mappings tomorrow morning, given to you by someone. For  
> now, let's say they are expressed in OWL. All the possible mappings  
> for static models you've liste are complete. Now, what would you do  
> with them? I'd love to hear your use cases for the situation where  
> you have these mappings.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090422/e22d7d90/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Hi Charlie,

I agree.
This topic is not about HL7 and/or EN13606.
It is about the logical, semantic and technical aspects of semantic  
interoperability.

I like to think about problems using simple, time proven, solutions  
and ways to deal with complexity.
One magic solution for everything is impossible.
We humans use the dictionary to describe the meaning of words.
Using a syntax we produce sentences.
With common knowledge in our heads we know what is relevant and makes  
sense.
We express what we need to express in a context.

The dictionary will not tell us what to document.
We need a way to capture what we want to express.
We all use documentation patterns to express things in a common way.

Mental exercise:
- Documentation Pattern: " Once upon a time there was a Princess"
We humans know that it is the documentation pattern for a fairy tale.  
Will the ontology be able to 'know' this?
Probably not. It will assume: there was a princes, there was a time,  
there was a place.

I see the need for six orthogonal levels (models).
1- A structure describing knowledge = the Ontology
2- Words to express knowledge = Coding system
3- Something else
4- A structure to assemble words into sentences
5- A structure to assemble sentences in documents
6- A structure to store meta-information for archiving purposes,  
versioning, etc, etc.

Without 3 we are able to produce correct sentences and collect them in  
documents.
This does not guarantee that we produce relevant sentences in a  
particular context.
It does not guarantee that sentences produced make sense; they can be  
non-sensical.
Even when they are correct the documentation pattern causes the  
interpretation to change completely.
Using 1 we (and IT-systems) will find out that it is nonsense and not  
relevant in a context.
Therefor we need a structure so users can express want they want to  
express.
This level three are Archetypes/Templates.

Level 3 is the Documentation Pattern where context, processes, humans  
interact with systems and use all the other layers to document,  
archive, exchange and re-use heir data and information.

At level 3 we must know how technically we can refer to codes from  
coding systems.
I know that we have not a universal way to refer to codes and coding  
systems.

Do we have a worldwide agreement how we refer to a coding system?
Do we have a worldwide agreement how we refer to a specific code from  
a coding system?
Do we have a worldwide agreement how we refer to a defined subset of  
codes from a coding system?
How do we deal with the variable structure of each code?
Do we have a worldwide agreement how to process the presentation  
labels and descriptions?
Do we have a worldwide agreement how to express inclusion and  
exclusion criteria (in the case of classifications for example)?
Do we have a worldwide agreement how we deal with the language in  
which code and coding system  related items are expressed?
Do all standards, systems, specify all  this in universal way?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Apr 23, 2009, at 9:39 AM, Charlie McCay wrote:

> I would agree that there are limits to the utility of such mappings  
> -  indeed it is to explore such limits that we are engaged in this  
> thread.
> This is a serious area, and openehr, 13606, and hl7 all have  
> mistakes and successes, (and differences and similarities). We have  
> differing perspectives on those, but let's try to put that to one  
> side and address common themes in this thread.
> I agree that there is a difference between language and ontology. I  
> am less convinced that to serve clinical system interoperability the  
> distinction can be maintained absolutely. At one level there is the  
> blurred boundary between terminology and structure, and at another  
> there is the safe automated reuse of entries/clinical statements -  
> something that happens and for which we need a better understanding,  
> with entries being treated as semantically independent.  I beleive  
> that ontologists have much to contribute to this area.
> I share with Seref a desire to understand why the research work is  
> not getting into practice. If it is not addressing the practical  
> questions then I move on to ask what work is.
>
> My interest is in asserting the relationships between standards  
> relevant to interoperability. I beleive that there is value in  
> seeing what is stopping this happening, and whether the cost of  
> addressing some or all of those hurdles would be justified
>
> All the best
>
> Charlie

-- next part --
An HTML attachment was s

CQuantityItem.units not empty

[Gerard Freriks]

Question:

Isn't the pain score a COUNT data type?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Feb 10, 2009, at 5:28 PM, Williamtfgoossen at cs.com wrote:

>
> Thomas,
>
> Thank you for your reply, however it does not satisfy the request.
>
> I think that the pain score is indeed not a physical measurable  
> instrument.
> But it is not an Ordinal, in statistical terms it is an Interval if  
> the numeric score is used (0, 1, 2, 3 etc up to 10) and a ratio when  
> the VAS scale is used.
> Hence reliability studies have determined that it is useful in  
> practice.
>
> However, I would like to have the following
>
> DV_PhysicalQuantity meeting the PQ requirements from ISO 21090
> and the
> DV_CodedOrdinal, or DV_Ordinal meeting the requirements for the CO  
> (Coded Ordinal) from ISO 21090.
> The CO does allow the order as we need, and allows the mathematical  
> operations such as summations, calculations like BMI style, among  
> others.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/750b8134/attachment.html>

Fw: Interoperability with HL7

[Gerard Freriks]

> ISO Archetypes could, as long as they were modelled in a fashion that is 
> neutral to final implementation format.

It is imperative that DCM's are absolutely free to use and in the public 
domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
general.
DCM's must be absolutely free from IP problems, well maintained in a formal, 
flexible, organisation, owned and controlled by all that use them.
OpenEHR as we know it today is a private company. (See under Status: 
http://www.openehr.org/about/foundation.html)


> 
> A common format would require both sides to either map the generic structures 
> into their own specific classes or adopt a more generic model with the 
> semantics in the terminology. The overlap between the information model and 
> the terminology model is probably at the heart of the conflict.

I produced (but not published) a draft document with the DCM Ontology as 
addition to the EN13606 and my thoughts about the next version of EN13606.
But also with my thoughts about the Boundary problem with coding systems and 
ontologies.

In collaboration with the Technical University in Valencia we started a project 
to think about the next version of EN13606.
For this purpose a website is created as focus point for discussions: 
www.EN13606.EU

> 
> Andrew McIntyre




Gerard Freriks

Electronic Record Services B.V.

Ditlaar 7
NL-1066 EE Amsterdam
PO Box: 376, NL-2300AJ Leiden
the Netherlands

M: +31 620347088
E: g.freriks at e-RecordServices.EU
W: www.e-recordservices.eu

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/88f76f5f/attachment.html>

Interoperability with HL7

[Gerard Freriks]

Dear Stef,

It is simple.
Customers demand Archetypes that are completely free ti use in a commercial 
product.
All openEHR artifacts have an IP owned by a a not-for-profit company with two 
owners.
For academic use it is free. But for commercial use things are not free.

Archetypes/Templates and Detailed Clinical Models must be completely public, 
owned democratically by all.

The present situation is not good for business at all.

I'm as a fervent supporter of the ideas behind EN13606 as ever.
We need requirements for DCM's (and Archetypes) that go beyond the present ones.

With regards,

Gerard


On 10 feb 2010, at 13:05, Stef Verlinden wrote:

> 
> Op 10 feb 2010, om 11:37 heeft Gerard Freriks het volgende geschreven:
> 
>> It is imperative that DCM's are absolutely free to use and in the public 
>> domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
>> general.
>> DCM's must be absolutely free from IP p! roblems, al, flexible, 
>> organisation, owned and controlled by all that use them.
>> OpenEHR as we know it today is a private company. (See under Status: 
>> http://www.openehr.org/about/foundation.html)
> 
> Hi Gerard,
> 
> 
> What has happened? For years and years you have been the initiator of many 
> disputes between 13606/openEHR and HL7 and! now all to have become the 
> 'enemy'. 
> 
> OpenEHR is a not-for profit organisation and it's knowlegde is in the open 
> domain. If you had Googled around a litte bit you could have found the 
> following:

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/210599a9/attachment.html>

Interoperability with HL7

[Gerard Freriks]

Bert,

There is only one answer.
Hospitals we talk with have problems with the way  IP is handled by openEHR.
IP owned by two organisations (One UCL and the other Ocean Informatics) they 
consider not PUBLIC.

I agree that the form of the company is not the issue.
What is important who controls the IP.
All Archetypes/Templates/ DCM's must be in the public domain, as is language, 
as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc.


Gerard


On 10 feb 2010, at 14:07, Bert Verhees wrote:

>> 
>> It is imperative that DCM's are absolutely free to use and in the public 
>> domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
>> general.
>> DCM's must be absolutely free from IP problems, well maintained in a formal, 
>> flexible, organisation, owned and controlled by all that use them.
>> OpenEHR as we know it today is a private company. (See under Status: 
>> http://www.openehr.org/about/foundation.html)
> It is not the juridical status of a company that makes the difference for the 
> IP-status of something. If an organization is not-for-profit or for-profit, 
> both can issue all kinds of IP-licenses.
> The company form has nothing to do with the licenses it issues
> 
> Bert
> ___

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/a4107fba/attachment.html>

Interoperability with HL7

[Gerard Freriks]

Stef,

It is a good step.
But not sufficient.

That OpenEHR artifacts are published with such a Creative Commons License 
policy attached to it is a good thing, I agree.
But when a new Reference Model, Archetype Model, Template models change and are 
published that decision is made by the owners because they own the IP and can 
issue any new License policy they wish.

Our customers do not want to be held hostage when they invest in the exiting 
new technology based on En13606/openEHR.
They are taking enough risks already, they feel.

Gerard



On 10 feb 2010, at 15:09, Stef Verlinden wrote:

> 
> Op 10 feb 2010, om 14:32 heeft Gerard Freriks het volgende geschreven:
> 
>> I agree that the form of the company is not the issue.
>> What is important who controls the IP.
>> All Archetypes/Templates/ DCM's must be in the public domain, as is 
>> language, as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc.
> 
> 
> If you read my reply to Bert, which probably crossed your response, you can 
> see that all archetypes are available under CC-BY-SA license. Unofficially 
> since Okt 2009 and officially since Jan 1th 2010
> 
> Do you agree that this means that all openEHR archetypes are in the public 
> domain and that since these archetypes fall under the CC license is really 
> doesn't matter who controls them?
> 
> 
> Cheers,
> 
> Stef

Gerard Freriks
+31 620347088
gfrer at luna.nl

Templates, node identifiers and data instances

[Gerard Freriks]

Safari worked fine

GF

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 19 Nov 2010, at 16:55, Sebastian Garde wrote:

> Hi Seref,
> 
> I have the same problem sometimes with PDFs from the openEHR space in Firefox.
> Often it works, but sometimes I get the error you experience.
> 
> Regards
> Sebastian

13606 revisited - list proposal

[Gerard Freriks]

Dear Pablos,

Internally in the EN13606 Association I started to work on this renewal.
The EN13606 Association will start to think about all 5 parts of the standard.

With respect to 13606 part 1 - the reference model- I think we will have 
discussions on topics such as:
- scope
- Folders
- Semantic links
- the structure below the Entry Class
- the type of relationships between the Composition/section classes used to 
structure documents and the Entry, Cluster and Element classes that define the 
clinical content.

Possibly other members will have their own topics they want to put on the table.
In our EN13606 Association meeting in February in Seville we start the 
discussions after a consultation phase.
openEHR will be part of this consultation phase. Any input from openEHR is 
welcomed.
A WIKI page will be started anytime soon on our website.
After these discussions our suggestions will be submitted to CEN/tc251 and 
ISO/tc215.

For more information about the EN13606 Association and the Seville meeting I 
refer to:
www.en13606.org
Non-members that want to participate in this meeting are invited to subscribe.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 15 dec. 2011, at 05:03, pablo pazos wrote:

> Great! this will be THE opportunity to think about an IM 2.0, and the first 
> topic on my wishlist is the simplification of ITEM_STRUCTURE & children :D 
> 
> -- 
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/0d9c5f74/attachment.html>

13606 revisited - list proposal

[Gerard Freriks]

Dear Erik,

Some personal comments in the text below.

GF



Gerard Freriks
+31 620347088
gfrer at luna.nl



=
On 15 dec. 2011, at 15:02, Erik Sundvall wrote:

> Hi!
> 
> On Thu, Dec 15, 2011 at 08:52, David Moner  wrote:
>> The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
>> :-) will start next February at the EN 13606 Association General Assembly in
>> Seville with an open and public consultation.
> 
> Is there any formal link between the 13606 Association and the actual
> standardisation process or is the "pre-SDO process" to be seen as
> traditional lobbying?

There are personal bonds.
The EN13606 Association has asked for a formal Liaison status with CEN/tc251. 
ISO/tc215 will follow.



> 
> Perhaps the best thing would be if the 13606 Association and openEHR
> could bring forward a unified co-authored suggestion to the SDO
> process rather than two suggestions? Perhaps we can use the new
> mailing list Thomas suggested for mail conversations combined with the
> wiki of the EN 13606 Association, instead of having separate mailing
> lists and separate wikis for the alignment discussions in each
> community?

Yes: that would be nice.
No: it is not essential.


> 
>> Before that, to prepare a
>> draft starting point, during January a consultation will be made to key
>> actors, implementers and users of the standard, including openEHR.
> 
> A great thing would be to actually have at least two independent
> _implementations_ of change suggestions (both AM and RM) after initial
> discussions but before any revisions to the standard are made. That is
> how some other SDOs work with technical artefacts and it could avoid
> some of the previous suboptimal approaches.

So you agree with my NO.


> 
> I assume AOM 1.5 is a candidate for AM? Is anybody already working on
> an AOM 1.5 implementation in addition to Tom's Eiffel version? Are
> there people interested in updating the Java implementation (or some
> other implementation) before or during the SDO process?

I think that some additions to AOM 1.5 will be supported by us.

And we will have new requirements, possibly.



> 
> Regarding the RM I know Tom is experimenting with simplified
> ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other
> RM-redesign experiments going on anywhere?

In my personal thinking the model around the  Entry, Cluster and Element will 
be simplified.
We need to reduce the number of degrees of freedom producing archetypes.
This is an important driving factor behind the new requirements based on our 
experiences producing archetypes.

In addition I'm of the opinion that in the Composition and Section the Entry 
Class must be 'reached' via a reference to an existing committed Entry, only.
In this way there is a more strict separation between functionality dealing 
with presentation/structure and the essential clinical relevant data and 
information that is documented.

These new RM's are not tested in working EHR applications.
They are 'tested' in a sense because we investigate what kind of archetypes can 
be produced.
And whether the number of degrees of freedom is less, but sufficient.


> 
> What is happening in the 13606-world regarding thoughts about
> practical datatypes?

My personal ideas:
- in Archetypes we need to have defined a set of "Leaf-node-Type", being 
indications what a healthcare provider can expect. 
For the techie it is an indication what real data type will be used.
- We need at the minimum the CEN data types, with exclusion of the ordinal data 
type, because at a higher level we will define 'Semantic Ordinals' as 
subpatterns used to model archetypes.
These 'Semantic Ordinals' have additional functionality so more than one can be 
selected, the order in which presented can be recorded, additional inclusion 
and exclusion criteria and signaling range plus attached value that can be used 
for calculations.
- It would be nice, but not essential, to have these 13606 datatypes as 
profiles of the ISO standard.


> 
> What about (optional) reusable ENTRY subtypes in the 13606 world? (see
> http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
> under the heading "2. OBSERVATION et. al. (ISO 13606 CR)")

We need to be able to use specialisations of the Entry class.
My thinking is that these health specific specialisations ( Observation, 
Evaluation, Instruction, Action, etc.) must not play a role in the RM.

We are working on an addition to the 13606 standard that defines how semantic 
interoperability artefacts are structured, used in other semantic artefacts, 
how standardised modeling patterns are used, etc.
In this scheme all these things define a standard for the semantic layer on top 
of the

13606 revisited - list proposal

[Gerard Freriks]

Dear Erik,

My personal thoughts and reactions.

It is based on off-line discussions in the EN13606 Association.
We will collect our thoughts and ideas, present them next year to the community 
and discuss them in February during our annual meeting in Seville.
Until then my personal ideas only.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 16 dec. 2011, at 12:06, Erik Sundvall wrote:

> Hi!
> 
> On Fri, Dec 16, 2011 at 09:32, David Moner  wrote:
>> In any case, this generic design is a result of the current scope of 13606:
>> EHR exchange and not a complete EHR implementation specification.
> 
> Thanks for reminding me.
> 
> I tend to forget that the 13606 purpose never was to make internal
> system semantics interoperable. It's easy to forget the intentional
> 13606 focus when usually thinking of mappings and interoperability
> issues based on examples like the ones on slides 12 and 13 of...
> http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf
> 
> As you know, if you want to truly bi-directionally share things for
> which it is impossible to define deterministic conversion
> algorithms/programs (thus maintaining patient safety in automated
> conversions), then just defining a standard message- or extract format
> will be a lost cause (no matter how determined politicians are and no
> matter how much you pay IT-consultants to try to do the job). Instead
> the semantics of the end point systems will need to be aligned sooner
> or later.
> 
> Anyway it wouldn't hurt if a new or refreshed internationally
> recognized standard could be used by those vendors and system owners
> that actually _want_ to agree on the internal clinical semantics of
> efficiently implementable systems all the way down to some of the
> technical (e.g. openEHR inspired) details. I think there is now a
> market for such a standard (or new standard part) helping those that
> have given up beliefs in mapping of incompatible semantics.

I agree.
This is what I wanted in the first place.
In the standardisation process it was felt to be more safe to obtain 
experiences first this the present scope.
Some wording in the present scope hints at this more extended use outside of 
the EH-Extract.

Although I agree, I think, that the 13606 Reference Model should not be a model 
on how to implement it in a very detailed way in a system.
It must stay a generic and logical model that provides features that help 
vendors to produce such internal proprietary implemented models.

> 
>> From our
>> experience, interoperability between legacy systems (standard-based or not)
>> is much easier using a generic model for exchange. The harsh truth is that
>> the quality of the data and the design of information structures in existing
>> EHR systems is quite bad or unclear, thus making really complicated the
>> process of automatically transforming it to a very specific reference model.
>> This is not the case when we use 13606.
> 
> I suspect this is an intentional difference between current 13606 and
> openEHR; to faithfully capture the current (incompatible) situation
> versus aiming to change the current situation.  Can those different
> goals really meet in one RM or do we need two standardized RMs?
> http://dilbert.com/strips/comic/2011-08-02/

It is/was a matter of scope.

I see no reason why we can NOT have one logical model that can serve the 
purpose of use inside IT-systems and outside an IT-system.
A different matter is whether the present openEHR RM is acceptable or not.
And who owns the spec.



> 
> A side-track question: Do you feel that the archetyped approach with
> 13606 really helps in the current mappings/transformations that you
> work with more than what just using e.g. RDF+OWL would help? Or does
> the archetype stuff and RM mostly complicate things?

When it is possible to design and implement using 13606 and archetypes in less 
than a week a common patient summary between two different hospitals, or a 
system that transforms a proprietary EHR to the CDISC-ODM format,
is that enough of an answer?
My answer is that the present 13606 fulfills its scope and is very functional.



> 
>> A different thing is if 13606 scope changes during the revision. In that
>> case, I agree that reducing layers of modelling by introducing specific
>> classes will make the systems more efficient.

David and I agree.

> 
> Is there an opening for scope-change or not within the formal
> 13606-revision or would one need to start a completely new standard in
> order to define a standard for aligning internal EHR system semantics?

In the EN13606 Association community there are openings to do that.
But whether the CEN/ISO representatives want it, is to be found out.


> 
> Could one add a new part (13606 part-6 or 1b?)

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

> I just care about getting one model 

In the case of 13606 one good model that describes a generic interface for EHR 
communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular 
implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M:  +31 620347088
E: gerard.freriks at EN13606.org
W:  http:www.en13606.org

On 4 Oct 2012, at 00:02, Thomas Beale wrote:

> On 13/09/2012 10:15, David Moner wrote:
>> Hi,
>> 
>> 2012/9/13 Erik Sundvall 
>> It would be great if e.g most of the future ISO 13606 version could be a 
>> true subset of openEHR instead of the current confusing situation. 
>> 
>> This is something I discussed with Thomas some time ago, it would be one of 
>> the best harmonisation solutions, but probably with a slightly different 
>> interpretation. Since 13606 has more generic classes (eg. the generic ENTRY 
>> can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead 
>> of 13606 being a subset of openEHR I think that openEHR should be a 
>> specialized model of 13606. Obviously this would require a deep analysis and 
>> changes of the models, but that could be the idea.
> 
> I don't care about the linguistics of subset / specialisation etc, I just 
> care about getting one model 
> 
> - thomas




Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/846345bc/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

Dear Koray,

We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote.
The scope of 13606 is about EHR communication.
That of openEHR is about the implementation in an EHR system.

At present a standard is missing about defining clinical content.
It would be nice, certainly, when both 13606 and openEHR can share that 
standard for clinical content.
In several places the EN13606 Association, whose scope is wider than the 
European context, is actively working towards that goal.
This single approach for a standard for clinical content is very important when 
we want generic semantic interoperability.
This is the reason why components for a potential standard on archetype 
production are developed inside the Association.
A standard that defines the intersections with: coding systems, ontologies, 
other CEN/ISO standards like System of Concepts for Continuity of Care and the 
Health Information Services Architecture.
All resulting in one basic generic pattern, for all artefacts, that by 
specialisation is able to be used for all kinds of archetypes.
A basis pattern that in more detail allows the definition of more nuances than 
the archetypes we know, so far.
A basic pattern that brings features closer to actual use such as negation, 
semantic ordinals (with inclusion and exclusion criteria), better integration 
with clinical workflow, ontological reasoning over structure and codes, etc.

The EN13606 Association of implementors of the 13606 standard has considerable 
experience in the production of applications based on this standard.
When I look into future needs and developments around the use of coding systems 
and ontologies, I see state of the art developments among the members of the 
Association.

W3C is a good example. indeed.
As far as I know W3C does not prescribes how to implement their standards in 
systems.
This is the responsibility of the industry in all circumstances.


Gerard Freriks
+31 620347088
gfrer at luna.nl




On 4 Oct 2012, at 02:02, Koray Atalag wrote:

> Hi Gerard,
> I think getting the content model is absolutely right ? no one can argue
> But with due respect I disagree with you about the difference. I seriously 
> think standards defining clinical content should converge (not even 
> harmonise).
> I had the privilege of spending some time with Ed Hammond in NZ and was 
> convinced that this is what is needed. Mappings are different and certainly a 
> blackhole.
> That said EN13606 Association?s mission and role is paramount in terms of 
> contextualising ?exchange? within the European context.
>  
> We chose to use openEHR for defining the Interoperability standards in New 
> Zealand as we are very mindful of the fact that this formalism has been 
> defined and carried on for many years by this group; and it IS naturally the 
> leading edge with proven track in implementation (one of which is my own 
> work). I think W3C is a good example of how important it is to have a single 
> approach in contrast to the situation in health IT. These might sound a bit 
> strong but it is what I believe. I acknowledge lack of organisational 
> capacity and skills in past though.
>  
> Cheers,
>  
> -koray
>  

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/a784cb63/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

See below.
On 4 Oct 2012, at 18:07, Thomas Beale wrote:

> On 03/10/2012 23:26, Gerard Freriks wrote:
>>> I just care about getting one model 
>> 
>> In the case of 13606 one good model that describes a generic interface for 
>> EHR communication, also, for communication with other proprietary EHR 
>> solutions.
>> In the case of openEHR one good model that describes one particular 
>> implementation of an EHR-system.
>> 
>> This difference is something the EN1366 Association cares about.
>> 
> 
> well except that the above is a misunderstanding of openEHR, so if the 13606 
> association works on that basis they will miss the opportunity to get 
> harmonisation.

Whatever openEHR aspires to be, it is clear that the scope of 13606 is EHR 
Communication in general.
It has been made clear that, in the renewal process of the 13606 EHR 
Communication standard, EHR-system implementation specifics are out of bounds.
The scope of 13606 will not be extended to match the scope of openEHR.



> openEHR is a model for an open EHR (it's in the name ;-), and includes three 
> kinds of semantics:
> core semantics that apply for any use of health information - messages, EHR 
> systems, documents etc
> semantics that describe accessing EHR information in repositories - any 
> repository
Accessing data in repositories is definitely out of scope for 13606 in this 
round of updating.
> semantics that describe EHR information in an Extract from one system to 
> another - any kind of system
If openEHR is serious about its scope, to be a general receiver of health data, 
then its Reference Model must become much more generic than it is now,
The 13606 Reference Model is very generic just to serve this important 
requirement that it must be able to deal with all systems. 


> These are used to specify the interfaces of EHR systems, EHR gateways (that 
> sit next to existing EMR systems), and EHR Extracts. The openEHR architecture 
> describes the externally shareable information semantics, not the internal 
> implementation. The implementations are the business of vendors, and are all 
> different. In other words, openEHR is an interoperability description of the 
> system - how the information and services look from the outside.
> 
> Insofar as 13606 has been used (uptake by industry vendors appears very low 
> as far as we can tell),

Hm?


> it has been used to build either EHR systems or gateways, rarely messages, 
> which is what it designed for. This seems a fair indication that what the 
> sector wants is a specification for the interoperability interface of the 
> systems and gateways required to even connect a healthcare enterprise to the 
> outside world - and additionally, a specification for making EHR Extracts in 
> these systems.

13606 based interfacing systems have proven to be capable of extracting data 
from any feeder system, transform it into the 13606 format, and into any other 
structured format.
And do this in matter of days.
We do not need openEHR to do that.


> 
> A specification only for EHR Extracts is not that useful, what the sector 
> clearly wants are specifications of the interoperability interface of 
> systems, as well as messages they might create. That's the opportunity here 
> for us working on these standards.

All this is within the scope of 13606.
It is misleading to suggest that the scope of 13606 is just messaging. EHR 
Extracts are about interoperability of data objects in general.


> 
> 13606 needs to be updated a priori, and has lessons from use waiting to be 
> implemented; openEHR has lessons from the last 5 years of use which will lead 
> to changes, so there is scope for change and harmonisation. I think the 
> community here, and also the stakeholders are interested in practical 
> proposals for a new set of standards that actually address needs.

I'm happy to announce that there is a wealth of implementation experience not 
only in the world of openEHR.
There is a wealth of experiences in deploying the 13606 EHR communication 
standard in hospitals, research, regions.
Sometimes in relation with HL7 CDA artefacts, sometimes to create applications 
for data entry, sometime integrated with ontological applications.

In the meantime I sincerely hope that harmonisation is possible without making 
too many unneeded remarks about potential partners.


> 
> - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121005/65054182/attachment.html>

Archetype authoring attribution

[Gerard Freriks]

David,

openEHR:
Creative Commons license CC-BY-SA 2.0, applying to all openEHR.org achetypes 
hosted at the openEHR Clinical Knowledge Manager (CKM).
http://creativecommons.org/licenses/by-sa/2.0/

My simplistic understanding.

A derived work has to be derived.
So when you use the information and transpose it as constraints on an other RM,
then I consider this new archetype as derived from that new RM it is transposed 
to.
So when this approach is followed then the Attribution is to the group that 
provided the clinical content.
But there is no attribution to the openEHR RM specification.

When you translate the text in the openEHR archetype to Dutch it is derived but 
still derived from the original openEHR RM.
In this case attribution must be stated to openEHR RM and the clinical group.

Is this an answer?



Gerard Freriks
+31 620347088
gfrer at luna.nl




On 22 mrt. 2012, at 13:03, David Moner wrote:

> 
> Hello,
> 
> Back again with the licensing topic of archetypes, with a real use case.
> 
> We have been asked to help in creating a set of 13606 archetypes for breast 
> and prostate cancer. Although they will probably incorporate some new 
> requirements, the main source will be some of the openEHR archetypes 
> available at the CKM.
> Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is 
> the state of that discussion), the doubts are the following:
> 
> - Converting the archetype to a new reference model is considered as a 
> derivation? Or the openEHR archetype is considered just as a reference 
> material as could be any textbook or paper?
> - The author of the new archetype has to be the one of the openEHR archetype 
> (Ian McNicoll btw) or the person who in fact creates the new RM-based 
> archetype?
> 
> The underlying question here that should be clarified is to define which is 
> the extension of the concept "derived work".
> 
> David

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/eca31ee3/attachment-0001.html>

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

Sam,

According to me:
- Observations have in reality points in time or ranges attached to it
- As do Evaluations about processes in the patient system they  have in reality 
times attached to them. Inferences are made at a point in time, but relate to 
inferred processes that come and go, or are believed to be present, or not, 
during a period of time.
- As do Instructions
- As do Actions

Time is never is a discriminating factor that sets Observations apart from the 
other Entry types.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 21 Jun 2012, at 14:21, Sam Heard wrote:

> Hi Diego
> 
> I think David Ingram has made a valuable contribution; these are empirical 
> solutions to real problems in real systems. The reality of OBSERVATION is 
> that it deals with point in times, intervals ( max, min etc) and analogue 
> readings. These need to be handled consistently or we end up with 
> combinatorial explosion - lab glucose in LOINC is over 200 codes.
> 
> Satre said that "belief is confusing things with their names". We need to 
> look at the classes and the utility provided. When we have a small number of 
> archetypes there is no doubt we can manage these things with slots etc. But 
> this requires massive alignment very early in the piece.
> 
> Cheers, Sam
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/997972a8/attachment.html>

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

hts, ideas) about something else - in other words, 
> it could be any structure, so we just use a tree. If we subdivided (as indeed 
> we did in the paper), we could posit a number of more specialised data 
> structures.
> 
> 
Really?
I can record as inference (Evaluation) something in the past (as history)
As something inferred now or inferred to happen in the future.
All Evaluations with a history, present and future as do the Observation, 
Instruction and Action.

> 

> See here for Smith/Ceusters/Scheuermann on an ontology for disease course and 
> diagnosis, in which they identify the same categories of information more or 
> less - clinical picture / diagnosis / plan.
> 
> 

They use (to me) a funny definition of 'symptom'.
But as realist ontologists they know that diseases whether diagnosed or not, 
inferred or not are occurrents (processes) with times attached to it.
> So to summarise, it came down to finding categories on which health 
> information data structures - i.e. information models - could be based that 
> would work reliably for most if not all of medicine. Now, having used these 
> categories for some years, it turns out that they are remarkably stable. I 
> know that the grey-zone debate on Observation/Evaluation will continue for 
> ever, but if one steps back for a second, what you see is that for most types 
> of clinical data, it is obvious which category to use. Most of the archetypes 
> for these types are not really in question. Further, noone has identified (to 
> my knowledge) a strong contender for any new kind of category (excepting for 
> sub-categories of AdminEntry, which will probably appear one day). 
> 

On the contrary, in spite of your  claimed years of experience, I have my claim 
to experience both in the openEHR world and that of the EN13606 association and 
this experience shows that they way users use the definitions in openEHR give 
rise to problems for the users. I agree that nobody will annotate a Blood Sugar 
Measurement result as an Evaluation or Instruction or Action.
In literature I have seen many wrong annotations because of problematic and 
unclear  definitions in the real of openEHR.
Why are we having this discussion if there were no problems what so ever?

> I think the main thing we got wrong was naming 'Evaluation' too narrowly, 
> when what we needed was a name that means 'what the clinician thought' (if we 
> had used Sowa's 'description' category I am sure we would now be having 
> arguments about why someone was using a 'description' to record a 
> 'diagnosis'!). We would know we had gotten things radically wrong if now, 5 
> years later, it were clear that say another 5 or 10 data structure types were 
> needed. 
> 
I disagree.
When a clinician is listening to heart murmurs as part of the physical 
examination I can assure you he is listening and thinking a lot, because it is 
very subtile what he is listening to.
Idem dito for palpation, smelling, etc. And there are more examples.

It is not whether he is thinking as a mental process but what matters is what 
is the relationship with the patient system.
Is he thinking about an observable?
Or is he thinking, inferring, about (disease) processes on the basis of 
observables.

For an Evaluation it is clear that it is about a process (continuant) in the 
patient system and that by definition it is an inference.


> If indeed we managed to get this sort of right (for now), it's only because 
> we had 3 previous attempts (GEHR 1992-95; Australian GeHR (1997-2000), first 
> draft of openEHR (pre-2005)) where we got it wrong. 
> 

The word Evaluation is OK.
But we need the correct not confusing definitions with good discriminators to 
make judgements easy.


> This is a hard problem to solve. In HL7v3, it was attempted with the 'mood' 
> code, which is certainly a reasonable starting point philosophically, but 
> doesn't in the end help you get the right data structures. This is well known 
> in HL7v3 as a difficulty (and I am not criticising for that, as I say our own 
> little effort was 10 years in the making). 
> The really amazing thing is that traditional epistemological categories are 
> of such little help. Divisions of a priori / a posteriori / how-to are only 
> vaguely useful (we used them and gave up on Aus GeHR), and yet to a 
> clinician, the differences between the observation of blood glucose over 
> 9mmol/l, Dx of diabetes mellitus and insulin care plan for glucose management 
> are crystal clear.
> I don't doubt that something better is possible in the future, but I think 
> for now some finer adjustments on the current ontology and data structures 
> will be of most practical he
> 
I can only point at our efforts dealing with semantical annotations in the 

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

Yes.

It all is about classifying.
It is all about proper definitions we all share and use.

I believe that when we all interpret the definitions in our own way in our own 
data bases all is working nicely.

The moment we start to exchange this data we will discover that we are not 
interoperable,
The moment we start to re-use data in clinical decision support service we will 
discover that all systems that worked so nicely, have become problems to 
connect.

As EN13606 we work at full semantic interoperability as much as possible.
So we have to define many things, we use to produce archetypes, properly.
Don't we all have an obligation to make semantic interoperability possible?


Gerard Freriks
+31 620347088
gfrer at luna.nl




On 22 Jun 2012, at 02:45, Jussara wrote:

> Think the background of our discussions is about CLASSfying.
> 
> Sent from my iPad

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120622/548ed0bb/attachment.html>

Polishing node identifier (at-codes) use cases.

[Gerard Freriks]

David,

Can I summarise it for my understanding as:
- AT codes are pointers to an 'ontology'.
- AT codes can be considered symbols that represent a particular concept
- The 'ontology' provides a name that will be used to display the name of a 
node (concept) in an archetype.
- When a node is specialised the node name used will indicate a new concept 
(its meaning has changed)
- When the archetype is specialised ideally the new concept in the 
specialisation is a subordinate concept.
- When a Node is specialised the standard does not prescribe that the new 
concept is a sub-set of the previous one.
- The question is: is each Node (and the concept it represents) unique or not.
- The question is: is it obligatory that each node in the archetype carries a 
unique code  of the form AT .

My answers to both questions are:
- Each archetype node is  a unique concept that must have attached to it a 
unique identifier.
- Archetype editors must support this.

And I would like to add:
- When specialising each specialised concept must be a subset of its previous 
one.


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 28 aug. 2013, at 09:13, David Moner  wrote:

> 
> I'll try to summarize the origin of the different views we have regarding 
> this topic and maybe this can be also useful to see why this is not just a 
> configuration problem of the tools.
> 
> We can find the explanation of node identifiers in two places (I use the 
> latest drafts, I think):
> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, used 
> to distinguish sibling nodes of the same type. [Previously called ?meaning?]. 
> Each node_id must be defined in the archetype ontology as a term code."
> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of the 
> form [at] following a type name is used to identify an object node, i.e. 
> a node constraint delimiting a set of instances of the type as defined by the 
> reference model." and  "A Node identifier is required for any object node 
> that is intended to be addressable elsewhere in the same archetype, in a 
> specialised child archetype, or in the runtime data and which would otherwise 
> be ambiguous due to sibling object nodes"
> 
> The definition in AOM is the one followed by the openEHR editor, i.e. a node 
> identifier or at code is just a pointer to the ontology section and a 
> mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the 
> tool does not introduce that code in order not to dirty the ontology section.
> 
> The  first part of the definition in ADL is the one followed in LinkEHR and, 
> in our opinion, more correct formally. When you introduce an archetype 
> constraint for a C_OBJECT you are in fact creating a definition of a type (a 
> sub-type of the more generic type defined by the reference model class) that 
> will be used to create a subset of instances. We have to distinguish this 
> sub-type from the RM type, and since the class name cannot be changed, the 
> only solution is to use the at as type identifier. In other words, our 
> interpretation is that at codes are unique identifiers of each type 
> defined in the archetype, that may be also used to link to the ontology 
> section, but that is the optional part. In fact, the only exception to this 
> would be when you create constraints using a path, because then you are just 
> navigating through the RM but do not change the meaning of the intermediate 
> classes.
> 
> The logic of the tools and the validation checks of archetypes are built 
> based on those interpretations. I agree with Bert in one thing: tools 
> shouldn't change things without notifications, but in this case we face a 
> methodological difference, not just a configuration one, and that's why it is 
> not easy to be solved.
> 
> David
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment.html>

Polishing node identifier (at-codes) use cases.

[Gerard Freriks]

Why bring in religion?

I want to understand and ask questions.
And in the meantime I have an opinion based on my 'GBV'. (see below)

> Can you please give reasons for your statements that archetype nodes must be 
> unique concepts and must be uniquely identified? 
> 

Reasons for my statement?
- Each node in an archetype has a meaning
- Without an implicit or explicit meaning the archetype node indicates chaos, 
meaninglessness, nothingness.
- Meaning is attached to the given name of the node or code attached to that 
node
- In the case of specialisations of archetypes several things can happen, one 
of those is renaming the node, changing the meaning
- This changing the name and meaning of the archetype node needs to be 
reflected in a new unique code

So far I have not explained the scope, the jurisdiction, the namespace, of the 
unique codes I'm alluding to.
At the minimum it must be uniquely defined inside the archetype, and in the 
case of a code from an external coding system, it must be unique in that 
namespace.

> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one.
> 


It all depends on scope of the archetype. Is it used in an 'open world' or 
'closed world' situation?
When used in a 'closed system' ( two or more actors that have an agreement of 
that what is exchanged, IHE with one profile) there is almost no need for 
external codes attached to archetypes. The explicit or implicit agreement is 
sufficient. Whatever the name in the archetype node, when the agreement says, 
the node name means 'Black', but we take to mean 'White' then there is no 
single problem.
In 'Closed world systems' the highest level of semantic interoperability is 
Level2a/2b at the best. It is the world of messaging with ad-hoc agreements, as 
we know it.

When the archetype is used in an 'open world' system, then we need to be very 
precise and explicit. Any party that interprets the data using the archetype as 
source, where it must find the meaning, needs to be informed fully. No single 
human intervention, human interpretation, must be needed to process fully and 
safely the data exchanged.
Local agreements between actors how to interpret the archetype node name do not 
exist, the archetype itself is the full agreement.
In 'Open world' systems the highest level of semantic interoperability is level 
3.
In this 'open world' situation there are other rules than in the 'closed world' 
situation.


Finally.
Do not create a  dichotomic world where things are either science or religion.
There are many shades.
And in order to surprise you:
Do not underestimate something that I call in Dutch: 'het gezonde boeren 
verstand'. (GBV)
Translated: the common sense of the farmer.
Many obvious things that happen in life, happen because they happen.
I do not have to prove, that water flows, that fire burns, that winds exits, 
for you and me to accept this is true,
with or without a science, with or without any belief system, with or without 
any dogma.

I try to base my own opinions on my 'GBV'.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 00:13, Hugh Leslie  
wrote:

> Hi Gerard, 
> 
> This is science, not religion. Can you please give reasons for your 
> statements that archetype nodes must be unique concepts and must be uniquely 
> identified? 
> 
> In openEHR and 13606, the archetype is the unique concept which means that 
> nodes quite rightly can have unique meaning in the context of the archetype. 
> This is like human language where the same word can have different meanings 
> depending on the context used.
> 
> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one. 
> 
> Regards Hugh
> 
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/f83f1222/attachment.html>

openEHR-technical Digest, Vol 18, Issue 38

[Gerard Freriks]

yes, I agree.

And it is the same as communication in a 'closed world' or 'open world' 
situation.


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 09:50, gjb  wrote:

> Re: Ontology & archetype codes
> 
> aren't we, here, in the realms of Descriptive v. Prescriptive Grammar?
> 
> http://grammar.about.com/od/basicsentencegrammar/f/descpresgrammar.htm
> 
> *Descriptive* obliges you to change whenever the language seems to.
> 
> *Prescriptive* obliges you to try to hold the language static.
> 
> The hard bit is gauging the utility of responding to any given change.
> 
> 
> Gavin Brelstaff
> CRS4 in
> Sardinia
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/b67e19cb/attachment.html>

openEHR-technical Digest, Vol 18, Issue 38

[Gerard Freriks]

Daniel,

Closed and Open world assumptions are used the world of:
- Formal logic
- Knowledge representation

This notion of Open and Closed world assumptions occured to.
Let me explain.
I happen to see a parallel/overlap between: systems that serve a well defined 
(Closed) community with implicit and explicit agreements and systems to deal 
potentially with not yet defined things in an not defined (Open) community.
In a system according to the Closed World Assumption all data fields are 
explicitly and implicitly agreed upon. Nothing that is not defined can not be 
processed, just like Relational Data bases and messages.
In a system according to the Open world assumption the semantics of a data 
field are fully defined semantically by archetypes and reference terminologies. 
There is (almost) no implicit meta-data. Ontological reasoners can fully 
exploit the data. These are the systems we want but do not have on the market.

Do you have any suggestion for alternative terms?

Gerard



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 11:12, Daniel Karlsson  wrote:

> Gerard, Everyone,
> 
> could you please *NOT* reuse existing terms like "open world" and
> "closed world" with an already agreed specific meaning in a well-defined
> context for your own purposes!
> 
> On the topic of descriptive vs. prescriptive I believe that that is an
> additional dimension in this discussion. I still want to have an answer
> to the question of what to do with archetype nodes for which there are
> no existing terminology correspondence. Should we ban those archetype
> nodes or should we (over)inflate terminologies with imprecise content or
> should we just accept that archetypes and terminology are different
> artefact beasts with different properties and that we have to thread
> carefully balancing terminology binding possibilities and specific use
> case requirements?


I have questions:
What is the purpose of a Reference terminology when it is missing essential and 
relevant lemma's?
Perhaps we need several Reference terminologies?
Then the next question is how do we delineate more than one Reference 
Terminology?

One thing I know:
We need an agreed list of words we use, reflecting concepts we need, in the 
context of health data inside systems and between systems.
We need a Reference Terminology as a kind of dictionary.
How many dictionaries do we need?
One per domain such as: anatomy, demographics, medicinal product, health and 
care services (interventions, lab-tests, etc.), structure of documents, units 
of measurement, family relations, kinds of media formats, etc., etc.



> 
> /Daniel

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/61a3b36d/attachment-0001.html>

openEHR-technical Digest, Vol 18, Issue 50

[Gerard Freriks]

William,

You have produced a lot of archetypes based on clinical input, that in the end 
were, well considered, well discussed, co-ordinated, agreed, ad-hoc, 
collections of what clinicians expect in a local context, to see on a screen to 
look at, and be used for data capture.
It is a lot of experiences.

Questions:
Have you produced a lot of Template stuff?
Or,
have you produced semantic interoperability artefacts?


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 30 aug. 2013, at 18:42, William Goossen  wrote:

> Semantic interoperability is absolutely compromised when for the same 
> clinical concept variants of archetypes are created.
> If justified for internal system development , the moment exchange with 
> another system requires harmonizing on datapoint to datapoint level. I have 
> done about 2000 in perinatology 800 in stroke care 1250 in youth care 100 in 
> nursing oncology 20 in reuma, 400 in general nursing 250 in diabetes care 200 
> in GP care 100 in cardiology. In the past 13 years.
> The inconsistencies for the same data element in the various domains are BIG, 
> without clinical justifiable reasons.
> That same situation exists if you have locally / vendor specific arechetypes .
> 
> Vriendelijke groet,
> 
> Dr. William Goossen
> 
> Directeur Results 4 Care BV
> +31654614458



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0002.html>
-- next part --
A non-text attachment was scrubbed...
Name: pastedGraphic.pdf
Type: application/pdf
Size: 73662 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0001.pdf>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0003.html>

Recording absence of (clinical) information

[Gerard Freriks]

Dear Koray,

According to SIAMM:

Any thing can be negated (or better it is declared that something is absent.
Since each ENTRY archetype is a named process that is: ordered, executed, 
assessed or summarised after termination, we can describe:
- that there is no order, no execution, no assessment or perception of the 
summary after termination of a specific named Action, Protocol, Clinical 
Pathway.
- in addition it is possible that as the result of a query specific data is not 
found. (e.g. No recording of any Blood Glucose, no recording of Blood Glucose: 
> 12 mMol/L)

This Presence/Absence indicator is NOT a boolean data type but a fixed text: 
Present/Absent
 
In addition, after long debates, it had been decided in the CEN/ISO Task Groups 
that in the RM we have one flag that indicates that something is 'fishy'.
It is the 'Attention' attribute in the ENTRY class.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 jul. 2013, at 09:41, Thomas Beale  
wrote:

>> Hi everyone,
> Hi koray,
> how do you want to do this? We decided against absence / exclusion in th RM a 
> long time ago, 
> because it is not a simple negation in general, but a complex (i.e. 
> archetyped) statement.
> 
> -thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130715/f6dfd00d/attachment-0001.html>

TDS (and TDD) implementations?

[Gerard Freriks]

Hi,

While we are at it.

-1-
Why do we need a TDD?
Isn't a Template just a Composition archetype with Sections archetypes and 
ENTRY archetypes and Cluster archetypes and Element archetypes plus data types.
In addition as many possible degrees of freedom need to be constrained so as to 
reflect the agreement between the two exchanging actors.
In all aspects they rare nothing but an archetype in my part of the world.
The peculiar thing about templates is that they are for prime time actual 
use/deployment.

-2-
Transformations:
The Template (archetype) has node names changed in places (and therefor their 
meaning).
They are more complex in places (because new branches) have been added, less 
complex in places (because branches are not used), more constrained in places 
than the pure parent archetype.

To write generic transformations is not trivial, I expect.
If possible at all.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 09:41, Daniel Karlsson  wrote:

> Hi Ian,
> 
> On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
>> Hi Erik,
>> 
>> 
>> The Ocean TDD->canonical transform is available at
>> 
>> 
>> http://openehr.codeplex.com/SourceControl/latest#176376
>> 
>> 
>> 
>> look for TDD_to_openEHR.xsl
>> 
>> 
>> As far as I know a generic reverse transform is not possible.
> 
> How could that be? Is there something in the TDD format that is not in
> the RM format? The intuition tells me that it should be easier going
> from the rich RM format to the TDD format than in the opposite
> direction. What are the specific issues that make a reverse
> transformation problematic? Could anything be changed to make the
> transformation possible?

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/ddeb7b6f/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

See below
Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 11:09, Daniel Karlsson  wrote:

> On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
>> Hi,
>> 
>> 
>> While we are at it.
>> 
>> 
>> -1-
>> Why do we need a TDD?
>> Isn't a Template just a Composition archetype with Sections archetypes
>> and ENTRY archetypes and Cluster archetypes and Element archetypes
>> plus data types.
> With ADL 1.5, yes I believe.

We, EN13606 Association, use the ADL1.4 spec in our tool: LinkEHR.
This is sufficient for our and CIMI purposes, we believe.


> 
>> In addition as many possible degrees of freedom need to be constrained
>> so as to reflect the agreement between the two exchanging actors.
>> In all aspects they rare nothing but an archetype in my part of the
>> world.
> Ok
> 
>> The peculiar thing about templates is that they are for prime time
>> actual use/deployment.
> What's peculiar about that?

'Normal' archetypes can be produced just to produce other archetypes at design 
time.

Templates are for specific use in a specific context and moment in time when 
actors define a screen or the content of an exchange.
Of course Templates can be designed as templates to be used in local contexts.

Archetypes can not be used without the Composition because a lot of the audit 
info and other info needed for versioning is defined at the Composition level.
The meta-data about the pay load is defined in the EHR-Extract.
Templates are mostly EHR-EXtracts with Compositions inside.

> 
>> 
>> -2-
>> Transformations:
>> The Template (archetype) has node names changed in places (and
>> therefor their meaning).
> No, these are (should be) just two alternative serializations of the
> same meaning. However, what constitutes the meaning of an archetype is
> not a trivial question.

When specializing an archetype the name (and meaning) changes.
When originally the Name node is ENTRY it can be changed in specialization to 
ENTRY:Observation
Or into ENTRY:Observation:ClinicalFinding
Or into ENTRY:Observation:ClinicalFinding:BodyTemperature

The names are different and therefore their meanings.
Although all names are related to each other.



>> They are more complex in places (because new branches) have been
>> added, less complex in places (because branches are not used), more
>> constrained in places than the pure parent archetype.
> Here I must confess I don't understand your use of the word "complex".
> E.g. if there in an openEHR model is two specific named events in an
> observation which are expanded in the TDD (isn't it??) does this
> increase or decrease complexity?


In a parent one node can allow zero to many siblings
In a specialisation we can constrain it to any within the limits as specified 
by the parent.
When allowed we can remove branches with zero-to-zero constraints and not use 
them at all.
We can insert (when allowed) in places additional nodes (new banches) that were 
not in the parent.


>> 
>> 
>> To write generic transformations is not trivial, I expect.
>> If possible at all.
> I do not agree. I believe this is what every implementer necessarily has
> to do, to provide a two-way transformation between a canonical form and
> any serialization and/or persistence form with a different set of
> requirements (query performance, OLTP vs. OLAP, space requirements,
> legacy systems integration, etc. etc. etc.). Not trivial but done on a
> regular basis.
> 

Using the 13606 AOM based tools it must be possible to track the whole 
provenance of any archetype/template.
(There is a problem known for Archetype Slots and keeping track of the original 
choices that were expressed.)
Although the template might be a sub-set in places and a super set in other 
places, all must conform to the Reference Model and all parent archetypes that 
were used in the chain of specializations.

Without the complete set of artifacts the transformation will be NOT possible,
Tracking all these changes that were made to the parent archetype


> 
> Cheers,
> Daniel
> 
>> Gerard Freriks
>> +31 620347088
>> gfrer at luna.nl
>> 
>> On 14 jun. 2013, at 09:41, Daniel Karlsson 
>> wrote:
>> 
>>> Hi Ian,
>>> 
>>> On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
>>>> Hi Erik,
>>>> 
>>>> 
>>>> The Ocean TDD->canonical transform is available at
>>>> 
>>>> 
>>>> http://openehr.codeplex.com/SourceControl/latest#176376
>>>> 
>>>> 
>>>> 
>>>> look for TDD_to_openEHR.xsl
>>>> 
>>>> 
>>>> As far as I 

TDS (and TDD) implementations?

[Gerard Freriks]

Dear Thomas,

Why do we (CIMI) need a TDD?
Isn't a TDD a transformation that is used during the implementation of a 
Template.

We in CIMI -I think, we agreed- is about Clinical Information Models. CIMS.
CIMS that can be transformed to openEHR expressions, 13606 expressions, CDA, 
all expressed as constraints on there respective Reference Models.

These CIM's, once transformed, are used in Templates that will be used locally.
And only then at implementation time implementers want something in XML. And 
that is the TDD.

I think it is completely out of scope for CIMI to talk about Archetypes 
expressed as constraints on their Reference Model
and it is even more out of scope to deal with Templates
and it is absolutely out of scope to deal with implementation issues such as 
XML representations of an implementable Template designed for local use.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 12:31, Thomas Beale  
wrote:

> On 14/06/2013 08:56, Gerard Freriks wrote:
>> Hi,
>> 
>> While we are at it.
>> 
>> -1-
>> Why do we need a TDD?
>> Isn't a Template just a Composition archetype with Sections archetypes and 
>> ENTRY archetypes and Cluster archetypes and Element archetypes plus data 
>> types.
> 
> that's what a template is; but a TDD (Template Data Document) is something 
> different. It's not an XML instance of the canonical (i.e. RM) information 
> model XSD, it's an instance of a transform of that, called a TDS (Template 
> Data Schema). 
> 
> A TDS is something like a 'green CDA' schema but generated from the AOM 
> template structure. The tag set is a mixture of standard RM attribute names 
> (like 'start_time', 'events', etc), and for the data attributes, names 
> derived from the archetype node ids, i.e. things like 'serum_sodium', or 
> 'total_cholesterol'. The result is an XSD whose tagset consists of basic 
> openEHR context attributes (always the same) and template specific data 
> attribute names.
> 
> There is therefore one TDS per template - each TDS is its own schema. 
> 
> A TDD is an XML document instance of a TDS.
> 
>> In addition as many possible degrees of freedom need to be constrained so as 
>> to reflect the agreement between the two exchanging actors.
>> In all aspects they rare nothing but an archetype in my part of the world.
>> The peculiar thing about templates is that they are for prime time actual 
>> use/deployment.
> 
> that's true, but not only that - you need templates to define a data set of 
> any kind. Except in some coincidental cases (like some labs), archetypes 
> don't on their own define useful or complete data-sets. So if a government 
> wants to mandate a discharge summary or e-referral document, they need to 
> define a template to do that, made up of specifically chosen attributes from 
> a set of chosen archetypes.

Data sets are ad-hoc collections of individual data points.
They are out of scope for CIMI, I think.
We need to bother ourselves with 'How do we model the individual data points 
and all their context?



> 
>> 
>> -2-
>> Transformations:
>> The Template (archetype) has node names changed in places (and therefor 
>> their meaning).
> 
> At a technical level, the 'meaning' of each node can't be changed from the 
> archetype - and that is the meaning that is computed with. I agree that in 
> some cases, the clinical meaning may be different, but it should always be 
> refined, not arbitrarily different. ADL/AOM 1.5 addresses this properly and 
> makes all template refinements regular and computable.

One can compute as much as we like.
When we specialize we change meaning (Names of the rate fact and the nodes, 
Constraints, Codes attached)
The at-code can be the same, and that is what is used to compute with.

Even a 'refined' node name means changing the meaning into a 'refined meaning'.




> 
>> They are more complex in places (because new branches) have been added, less 
>> complex in places (because branches are not used), more constrained in 
>> places than the pure parent archetype.
> 
> Currently, no new data at all can be added in an opernEHR template, and no 
> new branches. The only 'new' thing that can be added is clones of existing 
> archetype nodes to account for specific multiplicities required by that data 
> set.

I equate archetypes with templates.
Only Templates are defined to be implemented in a local temporal context and 
will contain: EHR-Extract, one or more Composition, Entry and Elements as 
minimum component.

Archetypes (and CIMI is talking archetypes) can be changed in any that I 
indicated.
Even at run-time arche

TDS (and TDD) implementations?

[Gerard Freriks]

Compact serialization?

When nodes in the archetype while they are developed and can change in the 
'template' level or even during run-time,
there never will be a simple serialization to an XML/XDS format. To much is 
volatile.


When you say ' more compact serialization formats'
do you mean shorter XML payload that go ver the wire?

Observe that when parties decide to be semantically interoperable this means 
that every data point and all its context needs to be sent over the wire.
Full semantic interoperability demands more resources than just updating fields 
in a database.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> 
>> When specializing an archetype the name (and meaning) changes.
>> When originally the Name node is ENTRY it can be changed in
>> specialization to ENTRY:Observation
>> Or into ENTRY:Observation:ClinicalFinding
>> Or into ENTRY:Observation:ClinicalFinding:BodyTemperature
> That's fine, but serializing is not specializing. Templates also allow
> specializing (that is in a way what templates do) as does archetypes so
> there's an overlap. But that's a separate (and important) issue. I was
> asking about the possibility of having more compact serialization
> formats.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/a9baa6e5/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

One simple example:
I can have an archetype slot that is filled at run-time as allowed by a regular 
expression or a hand entered list of possible archetypes that can fill that 
slot.
But there are more examples.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> 
>> In a parent one node can allow zero to many siblings
>> In a specialisation we can constrain it to any within the limits as
>> specified by the parent.
>> When allowed we can remove branches with zero-to-zero constraints and
>> not use them at all.
>> We can insert (when allowed) in places additional nodes (new banches)
>> that were not in the parent.
> Can you provide an example because I thought the latter was not allowed
> (depending on what a branch is).

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/8c9d4f5b/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

The best example is:
One ENTRY archetype node that can have one ore more Clusters added to it - when 
allowed -of course-via Archetype slots at run- or design time.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> Using the 13606 AOM based tools it must be possible to track the whole
>> provenance of any archetype/template.
>> (There is a problem known for Archetype Slots and keeping track of the
>> original choices that were expressed.)
>> Although the template might be a sub-set in places and a super set in
>> other places,
> as I said I don't think this is the case, but if there are issues these
> should be discussed and straightened out. Do you have specific examples
> or template functions where templates loosen constraints?

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/e9787307/attachment.html>

Rich text format in DV_TEXT

[Gerard Freriks]

So do I

GF

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 24 sep. 2013, at 09:42, Ian McNicoll  
wrote:

> Hi Bert,
> 
> This is perfectly legal ADL created with the Ocean AE - it allows for
> a single value with a 'choice' of datatype. We use this pattern fairly
> frequently.
> 
> Ian

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130924/ba42f92a/attachment-0001.html>

Alignment of languages and translations in templates (was: Invalid language codes in languages codeset)

[Gerard Freriks]

imo

1- Slots need to 'point at? archetypes by Name of the Archetype and NOT the 
file name. Plus something else ?
2- All Nodes in any archetype never derive any meaning from the text of the 
label attached the Node and thereby can be language independent. Archetypes 
written in different languages can be used at will. This is possible only when ?
3- Node names derive their identity (meaning) from a code from a predefined 
code set.
4- In addition we must be able to ?point at? other archetypes using unique 
identifiers, or a construct using generated Hash-codes for each unique 
archetype.


Gerard Freriks

+31 620347088
gfrer at luna.nl

On 2 apr. 2014, at 13:27, Diego Bosc?  wrote:

> I repost this discussion from the java implementation list, I think it could 
> be interesting to get feedback from the general implementers community.
> 
> -- Forwarded message --
> From: Thomas Beale 
> Date: 2014-04-02 12:51 GMT+02:00
> Subject: Re: Invalid language codes in languages codeset
> To: ref_impl_java at lists.openehr.org
> 
> 
> 
> I have not been following closely here, but I think the general approach 
> should be that you perform a design time validation pass, that reports things 
> like language incompatibility, i.e. never let there be ambiguity close to 
> runtime. 
> 
> The question then is: how does the validation of this particular thing work? 
> The first thing to note is that the possible slot fillers of a given slot in 
> an archetype are only those that are found in the current working set of 
> archetypes, not some theoretical maximum set (e.g. all of CKM or all Spanish 
> MOH etc). So, within a chosen working set, validation on language 
> compatibilty can probably only occur at the point of operational template 
> (OPT) generation, i.e. where the user specifies which actual languages and 
> terminologies (for terminology bindings) should be used, then a tool could 
> run a relatively simple test to see that all archetypes in the working set do 
> have translations in the chosen language(s). 
> 
> One could imagine more complex validations to do with figuring out of all 
> slot-filling archetypes have any language in common with slot-defining 
> archetypes, but I don't think this is useful. 
> 
> I have no check like this in the ADL Workbench yet, so I am interested to 
> know what others think it should be. 
> 
> We don't really have a proper definition of 'working set' or other possible 
> 'sets' of archetypes, but we probably need them. Getting a common definition 
> means everyone agreeing on a standard workflow for archetype development, and 
> possible ideas like defining a 'deployment set' from a larger 'working set', 
> or maybe a publisher's 'release set'.
> 
> - thomas
> 
> 
> On 02/04/2014 11:33, Diego Bosc? wrote:
>> Just today we had another interesting discussion on a related topic
>> about languages, translations, and slot solving.
>> The problem comes when you have an archetype whose original language
>> is different from the one that you are solving the slot with. There
>> are several alternatives, but seems that there is no 'perfect' one.
>> 
>> There is always the possibility of taking the original language of the
>> solved slot archetype and just add it to the original archetype as a
>> translation, marking the strings in the other languages in some way.
>> 
>> This is related to the languages codes as we could assume that a slot
>> with an 'en-gb' can be safely placed in a 'en' archetype and reuse all
>> the texts and descriptions. The problem comes the other way around
>> (can we assume that a 'en' slot can be safely placed in a 'en-gb'
>> archetype?).
>> 
>> Even if you have the same language in both archetypes, we have to
>> consider if a translation from a slot has the same validity to be
>> included in the original language descriptions of an given archetype
>> (In theory, all translations should be made from the original
>> language, and if the original language was another one, can we assure
>> that the meaning is the same as the original?)
>> 
>> Anyone of the list has been dealing with this problem? Which solutions
>> have you adopted for your tools/systems?
>> 
>> 
> 
> -- 
>  Thomas Beale
> Chief Technology Officer 
> +44 7792 403 613   Specification Program, openEHR 
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog   
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at l

Alignment of languages and translations in templates (was: Invalid language codes in languages codeset)

[Gerard Freriks]

imo

1- Slots need to 'point at? archetypes by Name of the Archetype and NOT the 
file name. Plus something else ?
2- All Nodes in any archetype never derive any meaning from the text of the 
label attached the Node and thereby can be language independent. Archetypes 
written in different languages can be used at will. This is possible only when ?
3- Node names derive their identity (meaning) from a code from a predefined 
code set.
4- In addition we must be able to ?point at? other archetypes using unique 
identifiers, or a construct using generated Hash-codes for each unique 
archetype.


Gerard Freriks

+31 620347088
gfrer at luna.nl

On 2 apr. 2014, at 13:27, Diego Bosc?  wrote:

> I repost this discussion from the java implementation list, I think it could 
> be interesting to get feedback from the general implementers community.
> 
> -- Forwarded message --
> From: Thomas Beale 
> Date: 2014-04-02 12:51 GMT+02:00
> Subject: Re: Invalid language codes in languages codeset
> To: ref_impl_java at lists.openehr.org
> 
> 
> 
> I have not been following closely here, but I think the general approach 
> should be that you perform a design time validation pass, that reports things 
> like language incompatibility, i.e. never let there be ambiguity close to 
> runtime. 
> 
> The question then is: how does the validation of this particular thing work? 
> The first thing to note is that the possible slot fillers of a given slot in 
> an archetype are only those that are found in the current working set of 
> archetypes, not some theoretical maximum set (e.g. all of CKM or all Spanish 
> MOH etc). So, within a chosen working set, validation on language 
> compatibilty can probably only occur at the point of operational template 
> (OPT) generation, i.e. where the user specifies which actual languages and 
> terminologies (for terminology bindings) should be used, then a tool could 
> run a relatively simple test to see that all archetypes in the working set do 
> have translations in the chosen language(s). 
> 
> One could imagine more complex validations to do with figuring out of all 
> slot-filling archetypes have any language in common with slot-defining 
> archetypes, but I don't think this is useful. 
> 
> I have no check like this in the ADL Workbench yet, so I am interested to 
> know what others think it should be. 
> 
> We don't really have a proper definition of 'working set' or other possible 
> 'sets' of archetypes, but we probably need them. Getting a common definition 
> means everyone agreeing on a standard workflow for archetype development, and 
> possible ideas like defining a 'deployment set' from a larger 'working set', 
> or maybe a publisher's 'release set'.
> 
> - thomas
> 
> 
> On 02/04/2014 11:33, Diego Bosc? wrote:
>> Just today we had another interesting discussion on a related topic
>> about languages, translations, and slot solving.
>> The problem comes when you have an archetype whose original language
>> is different from the one that you are solving the slot with. There
>> are several alternatives, but seems that there is no 'perfect' one.
>> 
>> There is always the possibility of taking the original language of the
>> solved slot archetype and just add it to the original archetype as a
>> translation, marking the strings in the other languages in some way.
>> 
>> This is related to the languages codes as we could assume that a slot
>> with an 'en-gb' can be safely placed in a 'en' archetype and reuse all
>> the texts and descriptions. The problem comes the other way around
>> (can we assume that a 'en' slot can be safely placed in a 'en-gb'
>> archetype?).
>> 
>> Even if you have the same language in both archetypes, we have to
>> consider if a translation from a slot has the same validity to be
>> included in the original language descriptions of an given archetype
>> (In theory, all translations should be made from the original
>> language, and if the original language was another one, can we assure
>> that the meaning is the same as the original?)
>> 
>> Anyone of the list has been dealing with this problem? Which solutions
>> have you adopted for your tools/systems?
>> 
>> 
> 
> -- 
>  Thomas Beale
> Chief Technology Officer 
> +44 7792 403 613   Specification Program, openEHR 
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog   
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists

Model CEN/TC251 13606

[Gerard Freriks]

Dear colleagues,

The last week I had a discussion with some colleagues of me at TNO.
They studied the OpenEhr proposal for a model for the EHR.

It is their opinion, and I agree with it, that the Kernel is not generic
enough because it contains things like the structure of the document
(folder, transaction, etc)
Even things like an organiser archetype must become a real archetype and be
not a part of the kernel.

With regards,

Gerard




--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Subject of care

[Gerard Freriks]

Hi,


S.o.C can mean many things:

One person
One mother or foetus
Any body part in or outside the body

And any grouping of items mentioned above.

A S.o.C indicates the participation in activities.

Gerard



On 2002-12-01 23:38, "Sam Heard"  wrote:

> Dear all
> 
> I have been reviewing the subject of care - over family history. It is clear
> that the following information is potentially useful:
> 
> 1. The name of the person so you can refer to them as so-and-so
> 
> 2. The relationship (father, mother) this might or might not include their
> genetic relationship (adoptive) - at present I have this in the genetic
> relationship boolean value of the family history problem. I think this is
> the most appropriate as it is the only time when it is essential to know
> it??
> 
> 3. The ID of the person in the demographic server - allowing contact details
> etc.
> 
> Can others think of other issues with identifying the subject of an entry in
> the EHR - (not the ehr itself!) Times when this is likely are around the
> birth of a child and for family history problems.
> 
> Cheers, Sam
> 
> Dr Sam Heard
> Ocean Informatics, openEHR
> Co-Chair, EHR-SIG, HL7
> Chair EHR IT-14-2, Standards Australia
> Hon. Senior Research Fellow, UCL, London
> 
> 105 Rapid Creek Rd
> Rapid Creek NT 0810
> 
> Ph: +61 417 838 808
> 
> sam.heard at bigpond.com
> 
> www.openEHR.org
> www.HL7.org
> __
> 
> 
> 
> 
> Dr Sam Heard
> Ocean Informatics, openEHR
> Co-Chair, EHR-SIG, HL7
> Chair EHR IT-14-2, Standards Australia
> Hon. Senior Research Fellow, UCL, London
> 
> 105 Rapid Creek Rd
> Rapid Creek NT 0810
> 
> Ph: +61 417 838 808
> 
> sam.heard at bigpond.com
> 
> www.openEHR.org
> www.HL7.org
> __
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

Hi,

My thoughts.

If we assume that a code plus description plus coding system, etc as a unit
of information them the coding system and the version plus some more
attributes will indicate the "language".
Equally we can assume that any piece of text (not coded using a
classification or terminology) is coded using a code, descriptive text,
grammar, a coding system and version number plus some more attributes.
I see no difference between the handling of raw text and coding ro
terminological systems.

Handle both in the same generic way.

Gerard


On 2002-12-05 18:59, "Dipak Kalra"  wrote:

> Dear Tom,
> 
> Sorry for the delay in replying. My remark was describing a situation
> that I believe to be realistic - that a health care session might take
> place in more than one language e.g. via an advocate or a relative.
> 
> If one stipulates that the set of coded terms within a whole
> Transaction must be recorded in one language, then clearly that does
> suggest a different rule needs to be offered for plain text. However, I
> was not necessarily implying that it is right for a whole Transaction
> to be in one language, although I could see Sam's reasons for proposing
> this, merely that this clinical scenario is a complication that needs
> to be considered. I note that Sam has suggested an alternative proposal
> - of linking together two transactions, one in each language. I am not
> sure how this would work for documenting a more interactive situation.
> 
> At this stage, I would prefer us to be exploratory about the various
> scenarios in which language issues arise and then to revisit our model.
> I am suspicious that our present approach might not be sufficient, but
> it may also be that I am being too fanciful in my ideas about how
> multi-lingual consultations might work. I was not at this stage
> intending to imply a particular information modelling approach to
> meeting this requirement.
> 
> With best wishes,
> 
> Dipak
> 
> Dr Dipak Kalra
> Senior Clinical Lecturer in Health Informatics
> CHIME, University College London
> Holborn Union Building, Highgate Hill, London N19 5LW
> Direct Line: +44-20-7288-3362
> Fax: +44-20-7288-3322
> Web site: http://www.chime.ucl.ac.uk
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Model CEN/TC251 13606

[Gerard Freriks]

Dear Mike,


What sets aside a document from a message?
What is recorded in q EHR system?


A document is the information a healthcare provider attests by signing it.
It contains a set of information in a clear context.

What is submitted in a EHR system has to be a set of documents, in my view.

Next to the set of documents other information is part of the record: lab
tests, etc.

In my view documents are persistent and reflect those parts of the recorded
and exchanged information that the healthcare provider attested.
Documents are not virtual at all and always exist.

Gerard

On 2002-12-04 14:00, "Mike Mair"  wrote:

> Dear Gerard, David
> 
> One definition of the GEHR 'kernel' is that of 'record engine'. I wondered
> what your view of the CDA was now in this role, after the Berlin CDA
> conference? The succession of CDAs can be turned out by any suitably
> equipped record system, and the CDAs used as a common currency for them.
> Sometimes these CDAs might not actually exist unless created for their
> communicative role between systems, in which case they are virtual CDAs, and
> the record engine entirely 'virtual'. This substitutes a 'virtual kernel'
> for the GEHR product, and does the same job of providing a communality of
> process between participant record systems without the specifics of the GEHR
> kernel, but it still would permit use of GEHR type components such as
> archetypes.
> 
> Regards
> 
> Mike Mair
> 
> - Original Message -
> From: "David Lloyd" 
> To: 
> Sent: Tuesday, December 03, 2002 8:40 PM
> Subject: Re: Model CEN/TC251 13606
> 
> 
>> Gerard
>> 
>> Several points:
>> 1.Specifically, openEHR proposes a number of Reference Models,
> supplemented
>> by Archetype Models.
>> 
>> 2. You seem to use the word 'Kernel' as a synonym for Reference Model. If
>> this is not so, please will you explain your use of the word Kernel?
>> 
>> 3. The Reference Models proposed by openEHR are just sufficient to meet
> the
>> set of published requirements (e.g. ISO 18308) for an EHR and apply to
>> _any_ EHR. It is necessary to delineate various levels in the Architecture
>> in order to be able to place Classes, Attributes, and Functions
>> appropriately to meet the requirements.
>> 
>> 4. The Reference Models are indeed generic, in the usual sense that they
>> are not prescriptive about what _information_ must be in an EHR, but make
>> possible the representation of all those kinds of information known to
>> exist in (or be necessary for future) EHRs.
>> 
>> 5. For each Reference Model there will be a corresponding Archetype Model
>> (only the Data Types Archetype model has so far been released). Authors of
>> actual Archetypes, conforming to the Archetype models, will be able to
>> impose the required constraints of their domains to guide the construction
>> of instances of EHRs.
>> 
>> 6. To my way of thinking, everything about the Reference Models is
>> _generic_. Archetypes provide the means of using the models to construct
>> EHRs for particular, i.e. non-generic, domains.
>> 
>> I hope this helps to resolve what appears to be a fundamental difference
>> between us!
>> 
>> With best wishes
>> 
>> David
>> 
>> 
>> At 21:02 02/12/2002 +0100, you wrote:
>>> Dear colleagues,
>>> 
>>> The last week I had a discussion with some colleagues of me at TNO.
>>> They studied the OpenEhr proposal for a model for the EHR.
>>> 
>>> It is their opinion, and I agree with it, that the Kernel is not generic
>>> enough because it contains things like the structure of the document
>>> (folder, transaction, etc)
>>> Even things like an organiser archetype must become a real archetype and
> be
>>> not a part of the kernel.
>>> 
>>> With regards,
>>> 
>>> Gerard
>>> 
>>> 
>>> 
>>> 
>>> --   --
>>> Gerard Freriks, arts
>>> Huigsloterdijk 378
>>> 2158 LR Buitenkaag
>>> The Netherlands
>>> 
>>> +31 252 544896
>>> +31 654 792800
>>> 
>>> 
>>> -
>>> If you have any questions about using this list,
>>> please send a message to d.lloyd at openehr.org
>> 
>> 
>> * David S.L. Lloyd, Technical Consultant
>> * CHIME - Centre for Health Informatics and Multiprofessional
>> Education, at UCL
>> * E-Mail:   d.lloyd at chime.ucl.ac.uk   Tel:  +44 (0)20 7288 3364
>> * Web:  www.chime.ucl.ac.uk/~rmhidsl#contact
>> 
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>> 
> 
> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

[Fwd: RE: Subject of care]

[Gerard Freriks]

gt; 
> Dr Sam Heard
> Ocean Informatics, openEHR
> Co-Chair, EHR-SIG, HL7
> Chair EHR IT-14-2, Standards Australia
> Hon. Senior Research Fellow, UCL, London
> 
> 105 Rapid Creek Rd
> Rapid Creek NT 0810
> 
> Ph: +61 417 838 808
> 
> sam.heard at bigpond.com
> 
> www.openEHR.org
> www.HL7.org
> __
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Model CEN/TC251 13606

[Gerard Freriks]

When information has to be exchanged between legal entities
(organisations or persons)
Then only attested and selected information can be exchanged using a
transaction type of exchange.


Of course system integration, where one healthcare provider collects the
data stored by (on on behalf of) him from systems that he controls and is
responsible for, is allowed. This type of 'virtual' use is NOT exchange of
information between legal entities.

The Essential Requirements for the EHR that we are writing in my institute
make this strict distinction. It is based on unpublished discussions between
healthcare providers and legal experts in Holland.

Gerard


On 2002-12-11 14:16, "Thomas Beale"  wrote:

>> Dear Mike,
>> 
>> What sets aside a document from a message?
>> What is recorded in q EHR system?
>> 
>> A document is the information a healthcare provider attests by signing it.
>> It contains a set of information in a clear context.
>> 
>> What is submitted in a EHR system has to be a set of documents, in my view.
>> 
>> Next to the set of documents other information is part of the record: lab
>> tests, etc.
>> 
>> In my view documents are persistent and reflect those parts of the recorded
>> and exchanged information that the healthcare provider attested.
>> Documents are not virtual at all and always exist.
>> 
>> Gerard
>> 
> 
> I agree, but I also saw the presentation that Mike is talking about, and they
> do in 
> fact create virtual CDA instances whcih are made available via the web to give
> users a virtual view of the EHR. This is using CDA documents not even so much
> as messages (there is no new content) but as web forms - in other words, a
> standardised view template for source data from difference systems.
> 
> - thomas beale
> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

Thomas,

I disagree.


I disagree because in essence both are the same. It is in the richness
versus reduced richness that there is a difference. And that difference is
not major.

As a physician I believe in free text and narrative. Healthcare is exchange
of information between responsible humans in the first place and secondly
between databases. And free text in a rich narrative structure is the way in
which humans can express them selves in a rich way as complete and accurate
as they can.
The richer the structure of the free text or narrative the better the
information can be expressed in a structured way. The richer the text is
structured using concepts from a source the better information can be
expressed in an analysable form.
A rich ontology is better than a restricted code set.

Gerard

On 2002-12-18 17:01, "Thomas Beale"  wrote:

> 
> 
> Philippe AMELINE wrote:
> 
>> Hi,
>> 
>> Since I missed the starting point of this thread, I may un-properly
>> answer ; however I can say from the work we are doing that there is a
>> great difference between a system based on an ontology and a system
>> based on free text annotated by a coding system.
>> 
>> The fist one allows structured description (knowledge management
>> field) while the other remains in the field of classification (data
>> management : text index keeping and epidemiology).
> 
> And I have to agree 100%.  But I doubt if Gerard really disagrees with this.
> 
> - thomas
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

[Fwd: RE: Subject of care]

[Gerard Freriks]

uced
>> from the data - I do not think that we can say the origins of all the
> states
>> in a person that arise following a donation - at times it may be ambiguous
>> (graft v host).
>> 
>> We have considered 'donor' to be the relationship - but the person may
> have
>> a relationship with the person apart from this? I do not think that the
>> subject of care needs to be the donor then - it can be the family
> member as
>> it is known who they are. Interesting!
>> 
>>> It seems to me that we can either organise our concepts to make this
>>> kind of record easier and more obvious, or we can begin to inbuild
>>> problems for later on (eg if the fetus is part of the mother, having
>>> to explain to all our knowledge agents that this might not extend to
>>> genotypes, or if it does, then by chance rather than biological
>>> imperative etc...). In the event of one of two fetuses being
>>> affected, and one pregnancy being terminated, what is the result in
>>> the record to indicate the original number of conceptions, the fact
>>> that a genetic risk actually produced a fetus with a prospective
>>> problem, and the DNA and other data originated in the process of the
>>> testing of the CVS sample? It would be wrong, I feel, to treat the
>>> fetus' diagnosis as one of the mother, as confusion here could lead
>>> to all kinds of erroneous conclusions (one fetus had sickle cell ->
>>> mother - who is actually just a carrier - has sickle cell...?).
>>> 
>> 
>> I do believe that we have this covered - the donor example is a bit of a
>> mind bender but I think the subject of care and relationship provides the
>> solution.
>> 
>> COmments?
>> 
>> Cheers, Sam
>> 
>> Dr Sam Heard
>> Ocean Informatics, openEHR
>> Co-Chair, EHR-SIG, HL7
>> Chair EHR IT-14-2, Standards Australia
>> Hon. Senior Research Fellow, UCL, London
>> 
>> 105 Rapid Creek Rd
>> Rapid Creek NT 0810
>> 
>> Ph: +61 417 838 808
>> 
>> sam.heard at bigpond.com
>> 
>> www.openEHR.org
>> www.HL7.org
>> __
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>> 
>> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Terminology services

[Gerard Freriks]

What I wrote was (in other words)
I see no difference (on a certain level) between natural language and an
artificial one like ENV 13606 plus ICD-x or any other classfication and
terminological system.

Gf



n 2002-12-18 17:00, "Thomas Beale"  wrote:

> 
> 
> Gerard Freriks wrote:
> 
>> Hi,
>> 
>> My thoughts.
>> 
>> If we assume that a code plus description plus coding system, etc as a unit
>> of information them the coding system and the version plus some more
>> attributes will indicate the "language".
>> 
> Hi Gerard,
> 
> we need to be specific here: what are the attributes? I think that for
> example ICD10 (version = "10" or are there interim releases?) does not
> tell you the language. As far as I know, people get ICD10 in a file in
> whatever their language is and just call it "ICD10" - I don't know of a
> formal naming scheme for it including the language.
> 
>> 
>> Equally we can assume that any piece of text (not coded using a
>> classification or terminology) is coded using a code, descriptive text,
>> grammar, a coding system and version number plus some more attributes.
>> I see no difference between the handling of raw text and coding ro
>> terminological systems.
>> 
> well I see plenty! But we are probably talking about different things
> here...
> 
> - thomas beale
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

[Fwd: RE: Subject of care]

[Gerard Freriks]

On 2002-12-30 12:38, "Sam Heard"  wrote:

> Dear All
> 
>> 1. In the demographic server, we create 2 PERSONs, and use a foetus
>> archetype for one. We put a mother/in utero PARTY_RELATIONSHIP
>> between them.
>> 
>> however, the in utero relationship as a clinical phenomenon is probably
>> more important than the legal mother/child relationship, which is the
>> kind of thing demographic systems are designed for (this relationship
>> does not change as long as both parties are alive, but the carrying/in
>> utero physical relationship is fairly temporary.
> 
> For all sorts of reasons one cannot separate the mother and fetus until
> quite late in pregnancy - many tests have implications for the fetus and for
> the mother and her pregnancy.
> >>>>>

It is my belief that there will not be one good for all model of the
demographics.
There are several points of view: medical perinatologist, - genetical,
-peadiatrician,  - gynacologist, - pharmacist, -etc, phycological,
sociological, legal, ethical, administrative, etc.

Each viewpoint will have different models for different contexts.

The consequence is that one RIM with one Demographics part will be to
restrictive.
One RIM with several types of demographic models (using
Archetypes/Templates) is the sensible way to think about it.

Gerard



 --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Delta flag - HL7

[Gerard Freriks]

Sam,


Don't confuse two things.

-1- A measument is a measurement.  It is raw data.
-2- An interpretation of raw data by a human or agent or Archetype
transforms this in Information.

Any interpretation is a view on raw data plus a (subjective) interpretation.
And systems should show this and the author of this subjective
interpretation.

Boundary problem:
A radiologist interterprets a complex x-ray. The x-ray is the raw data. The
radiology note is the attributable view on raw data plus the subjective
interpretation.
Now this note is sent to a GP.
At the receiving GP system this note is treated as raw data. Measurement.
After acceptation by the GP and submission this raw data to the record it
can be used to interterpret it. Etc, etc.

The delta-flag is not an attribute to data but a subjective interpretation
recorded in a subjective view.

Gerard


On 10-07-2002 06:16, "Thomas Beale"  wrote:

> 
> 
> Sam Heard wrote:
> 
>> Hi
>> 
>> The quantity data type has the possibility of revealing changes that are
>> unexpected. Let us say for example that you weigh someone and their weight
>> is 80 Kg - and they tell you that they weighed 100 Kg 3 months ago. Or that
>> a Hb was 151 and it is now 121 - still normal but has changed a lot and you
>> may want to have this brought to your attention.
>> 
>> ALSO - we have not differentiated at the RM level between information from
>> the clinician and that given by the patient.
>> 
> why do you say that - ENTRY.provider does this.
> 
>> So OBSERVATION covers both -
>> sure we can say where it came from but the weight example really shows that
>> it may be from both.
>> 
> not sure what you mean here
> 
>> For this reason - I would like to see the Delta (or change) attribute to
>> quantities to enable us to say if this measurement has gone up or down more
>> than expected.
>> 
> just one little question: when does it get turned on? What is "a lot",
> or "more than expected"?
> 
> - thomas beale
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

f we are to formalise this concept, we need to have use cases showing
>>>> when/why contributions need to be handled as explicit entities.
>>>> 
>>>> If we can prove the need, the following architectural possibilities
>>>> suggest themselves:
>>>> - use FOLDERs to act as contributions, i.e. every time a contribution
>>>> goes in, make a new FOLDER that contains the references to those
>>>> TRANSACTIONs
>>>> - define CONTRIBUTION as a new subtype of FOLDER and use it as above
>>>> - if we consider a contribution to be the equivalent of an outer
>>>> transaction in a nested transaction, then we might create a new
>>>> TRANSACTION for each controbution, whose contents are links to the
>>>> other transactions in the contribution,
>>>> - we could always add links to the first TRANSACTION in a contribution
>>>> pointing to the other TRANSACTIONs in the group.
>>>> 
>>>> thoughts?
>>>> 
>>> 
>>> NO way Jose - can I be any stronger than that?
>>> 
>>> - Sam
>>> 
>>> 
>>> -
>>> If you have any questions about using this list,
>>> please send a message to d.lloyd at openehr.org
>>> 
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

On 2002-06-07 15:00, "Tim Benson"  wrote:

> Gerard,
> 
> I feel that the idea of the EHR as being essentially a data base made up of
> bits of messages is a fundamental misconception that is at the bottom of
> many of our problems in health informatics.  As first approximation it works
> for GPs but sadly, it does not scale across the whole healthcare spectrum.
>>>>
\

Tim, I agree with you.
Messages used in logistics are messages used for logistics.
The EHR is about narration.


> 
> Any set structured information is designed for a primary purpose.  This is
> true of databases, documents, classifications and models.  Any attempt to
> use that information outside its original purpose is fraught with danger.
> While it is true that a collection of documents can be thought of as an
> electronic record, we have to take a lot of care when the information which
> they contain is reused outside the original context of a message.
> 
> CEN and HL7 messages are just that - messages - from someone, to someone and
> about someone at a moment in time.  They have more in common with electronic
> mail than with database structures. Any attempt to take information from a
> message and put it into a database is potentially dangerous and needs to be
> done with a real understanding of the data.  This can only be done when
> messages are rooted in very clearly defined use cases.
>>>>>

I want to separate CEN from HL7. With CEN we focus on Documents with
narrative in a structured form either stored or transported between persons.
HL7 (v2 and v3) are about messages exchanged between databases for logistics
purposes. They contain no real narrative.


> 
> The scale of the problem is illustrated by thinking very clearly about ALL
> of the potential users of medical records.  In UK the Dept of Health
> recognises more than 60 medical specialties.  If you add in all of the other
> clinical specialties then you have at least 100 distinct groups of people
> who have their own specialised ways of working and requirements, including
> audit and quality control issues, which ultimately determine how they need
> their data to be structured.  They cannot all use just one structure,
> however much we would like this to be the case.
> >>>

Next to the many types of users there are 10-20 different functions of any
EHR.



> 
> Kind regards
> 
> Tim

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Data Types

[Gerard Freriks]

Tim,

Not the receiving system is the criterion.
It is the requirement to be able to store narrative and retreive/search in
narrative text in a safe way that is the criterion.


Gerard


On 2002-06-04 12:46, "Tim Benson"  wrote:

> Surely the criterion for any structured data is whether another application
> is expected to use that structured data in a way that (a) adds value and (b)
> is safe.  If either (a) or (b) are not true then structure simply adds cost
> and complexity without benefit.
> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Data Types

[Gerard Freriks]

Language is a funny thing.

Sometimes a concept that is used is very precise. (a specific date, a
specific object, e.g. a particular chair)
Sometimes the concept is vague. (some time, some date, any object with the
name chair)
Sometimes it is possible to define exactly what we mean. But what is a
perfect definition of a chair, so a person not having seen any in his life
understands it?

In Informatics many tend to think that everything can be defined precisely.
Reality is, more often than not, it can't .
The problem is how to handle these imprecise concepts faithfully.

By having an attribute (like HL7) indicating this?

Gerard

Ps:
Hi Paul.
Is NHS Scotland interested to take part in EN 13606 work with CEN?


On 2002-06-08 03:57, "Thomas Beale"  wrote:

> 
> Our current solution to this situation, as I mentioned in another post
> was to add the following routines to the PARTIAL_DATE type:
> probable_date: DATE
> possible_dates:INTERVAL
> 
> If the user GUI was then constructed so that a blank date, and a blank
> month were allowed, the software behind would create a PARTIAL_DATE
> object. These functions would provide sensible values for statistical
> computation (i.e. 15th of the month if date unknown, 1st/June if date
> and month unknown). The possible_dates function provides the outer
> limits of the possible values of the date, which can be used for query
> matching. I am not sure of how much skew this introduces, but it has to
> be better than having falsely accuracte dates, or else no structured
> date at all.
> 
> Paul, what do you think of this approach?
> 
> - thomas beale
> 
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

Dear Tim,

I know that I painted things black and white.
But my picture contains some truth's, I think.

The scope of CEN and HL7 is not completely overlapping.
HL7 concentrated more or systems integration within an institutions.
And CEN more on exchange of information between organisations. The last
couple of years CEN moved towards Documents instead of messages. Plus CEN
started to standardise message components. Lego bricks.

My focus on narrative texts (the EHR) is obvious.
In medicine physicians exchange more than objective information and give
orders. They narrate the medical story of their patient, their thoughts and
deliberations about all the objective events that all constitute the EHR.
It is a personal account of a journey travelled together by the patient, its
relatives, and the healthcare provider.
In general it is NOT a narrative to be shared by many. The medical record is
a personal, subjective document. It is a narrative for personal usage. When
information is to be shared the author will select and rewrite parts of his
notes in order to meet a specific request by an other healthcare provider.
This is the way people work. This is the way healthcare providers know how
to work with using paper systems.
I can see that objective information (orders, test results) can be shared by
all without real problems. But people (good healthcare) will need subjective
narrative as recorded in their personal Medical Records.
Personally I don't believe in one all encompassing, fulfilling all needs for
all, Medical Record shared by all; now and in the future.

Gerard



On 2002-06-08 01:27, "Tim Benson"  wrote:

>> From: Gerard Freriks 
>> Date: Fri, 07 Jun 2002 21:46:28 +0200
>> 
>> I want to separate CEN from HL7. With CEN we focus on Documents with
>> narrative in a structured form either stored or transported between persons.
>> HL7 (v2 and v3) are about messages exchanged between databases for logistics
>> purposes. They contain no real narrative.
> 
> This comment seems to point to a mis-conception about what HL7 is doing now
> and what CEN has achieved over the past 10 years.  Most existing HL7
> implementations could be described as logistical, but the same is equally
> true of CEN implementations.  Indeed the work has proceded in parallel with
> a good deal of duplication of effort.
> 
> It is quite wrong to characterize the present work of HL7 as being "for
> logistics purposes" only.  HL7 has about 30 different technical committees
> and special interest groups, and while some do have a logistical focus, many
> do not.  The scope is so wide that few people have a full overview of all
> the work that is going on.
> 
> I am not quite sure that I understand why you focus on the narrative
> perspective as being so crucial.  Ideas about story-telling and narratology
> have been useful in understanding some of the ways in which GPs in
> particular use (and misuse) medical records, but they only illustrate one of
> the ways in which records are used (and these are mostly the ones where
> computability is least important).  The primary use of narrative to to
> provide something that can be understood by a human being, while the value
> of structure is to have something that is computable.
> 
> It is quite easy to produce a medical record which meets these requirements
> for a SINGLE group of users (such as GPs), but it is a different thing
> altogether to solve the problem for MULTIPLE groups.  It is not the
> narrative that creates the problem, but the structure.  Most structures use
> a version of a tree-like hierarchy, which can only support one perspective.
> The way forward is to use structures which support MANY different
> hierarchical structures at the same time.
> 
> The key word above is MANY.  Existing systems support several ways of
> looking at a medical record.  Indeed the Abies GP system of 15 years ago
> allowed the user to view the record according to different types of date, by
> patient problem and by about 20 pre-defined characteristics (medication,
> diagnoses etc) and by groups of coded entries (using the Read Code
> hierarchy).  Indeed the indexes for any medical record contained perhaps ten
> time as many entries as the record itself.  This worked rather well for GPs,
> but did not migrate too well into secondary care, where there are multiple
> and conflicting ways that different groups wanted to look at the data.  The
> solution to this problem is the evolution of virtual records for each group
> of users, based on their own specific use cases. But this has little to do
> with narrative...
> 
> Kind regards
> 
> Tim

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

g
>>>>> VERSIONED_TRANSACTION)
>>>>> - update to plan (new version in existing VERSIONED_TRANSACTION)
>>>>> - etc
>>>>> 
>>>>> So the contribution in this case would be four TRANSACTIONs, each in
>>>>> distinct VERSIONED_TRANSACTIONs, and each having identical details
> in
>>>>> the CLINICAL_CONTEXT object.
>>>>> 
>>>>> Now... contributions are the unit of change of the record. The
>>>>> question is, do we need to be able to easily find them after the
> fact,
>>>>> or is it not really important. If it is not important most of the
>>>>> time, then we can do nothing, sicne they will in fact be findable by
>>>>> looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT
>>>>> objects. However, this will be slow, as it means going through all
>>>>> transactions in the entire record. If it is important to be able
> find
>>>>> contributions quickly (as I have theorised in the past, and Andrew
>>>>> Goodchild at the DSTC suggests), then we need to formalise the
> concept
>>>> 
>>>> 
>>>> I do not think that we do but I am happy to hear what people
>>> have to say.
>>> I
>>>> think it is the same function as putting the date back - ie a
> historical
>>>> date. In fact there is no reason why these things should all be
>>> changed at
>>>> once - a computer might be left on for an hour and then the rest is
>>>> committed - what is that?
>>>> 
>>>> 
>>>>> Andrew has also suggested that EHR extracts are really a kind of
>>>>> "contribution", since they are effectively a bag of TRANSACTIONs to
> be
>>>>> applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not
>>>>> due to the same clinical session (they could be anything, depending
> on
>>>>> what the requestor asked for), their addition to the receiving EHR
>>>>> will in fact be a contribution.
>>>> 
>>>> 
>>>> This is a merge_audit and I do not think that they have the
>>> same status in
>>>> any way.
>>>> 
>>>> 
>>>>> If we are to formalise this concept, we need to have use cases
> showing
>>>>> when/why contributions need to be handled as explicit entities.
>>>>> 
>>>>> If we can prove the need, the following architectural possibilities
>>>>> suggest themselves:
>>>>> - use FOLDERs to act as contributions, i.e. every time a
> contribution
>>>>> goes in, make a new FOLDER that contains the references to those
>>>>> TRANSACTIONs
>>>>> - define CONTRIBUTION as a new subtype of FOLDER and use it as above
>>>>> - if we consider a contribution to be the equivalent of an outer
>>>>> transaction in a nested transaction, then we might create a new
>>>>> TRANSACTION for each controbution, whose contents are links to the
>>>>> other transactions in the contribution,
>>>>> - we could always add links to the first TRANSACTION in a
> contribution
>>>>> pointing to the other TRANSACTIONs in the group.
>>>>> 
>>>>> thoughts?
>>>>> 
>>>> 
>>>> NO way Jose - can I be any stronger than that?
>>>> 
>>>> - Sam
>>>> 
>>>> 
>>>> -
>>>> If you have any questions about using this list,
>>>> please send a message to d.lloyd at openehr.org
>>>> 
>>> 
>>> -
>>> If you have any questions about using this list,
>>> please send a message to d.lloyd at openehr.org
>>> 
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>> 
>> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

Ed,


The invitation by the HL7 board is received well.
We will try to make it to Baltimore.

Harmonisation between CEN and HL7 is and stays our long term goal.
CEN achieved a lot towards this goal in project teams 41 and 42 working on
GPICS harmonised with HL7 and a set of Lab related messages based on GPICS.

The next phase of interactions between CEN and HL7 will have to be
discussed.
Templates, Archetypes, GPICS, Archetype methods, Datatypes, the EHR will be
topics of interest for all of us. Plus the way in which we both can have a
process of harmonisation that is effective pragmatic and reciprocal, might
be an other important topic.

Gerard

Ps: I'm giving you my personal thoughts.



On 2002-06-08 19:50, "William E Hammond"  wrote:

> 
> It is difficult for me to stay on the sidelines.  HL7 recognizes the value
> of CEN and GEHR to its work.  HL7, for example, has invited the chair of
> CEN and the convenors of the work groups to the next meeting.  What I think
> we need to declare is what is real and what is pretend in working together
> - on both sides. I declare and I believe that HL7 is interested in both
> groups.  What that means is not that we (or I) will drop what I am doing
> and accept something different.  What it means that I am willing to dialog
> and debate the issues. I firmly believe that all groups will be mush better
> off if we discuss and deal with our differences rather than each go our
> different ways.  We need to find a way for all groups to move ahead
> together and still do what we each have to do to stay alive and even grow.
> My belief is that V3 will become stable much more quickly than Gerard
> implies. I agree that CDA needs to move ahead with CDA level 3. I am also
> curious as to what clinical templates will do to level 3.  I certainly hope
> we can get together on architypes, GPICS, clinical templates, and Huffs/3M
> clinical data models.
> 
> What say?
> 
> Ed Hammond
> By the way, these are my opiniuons. I'm not sure anyone else wants them.
> 
> Ed
> 
> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

Mike,

I don't remember what was in the Berlin presentation by Gunnar, I think.

It is a fair list of reasons why the uptake is slow.
But what can one expect within a few years?
It took more than 6 years before a CEN standard on ECG-signals was used all
over the world.
What is used of HL7 version 2.2 or 2.3, I expect.

And both CEN and HL7 have a lot of optionalities, since the approach is
generic.

The re-engineering of systems is the case with standards used in
implementations in systems. And the EHR standard could be implemented in
systems it is not only a messaging standard.
Since Berlin we learned of several European implementations of the EHR
standard in systems and messages.
The implemented standard was a pre norm (ENV 13606) that after 3 years of
use is now up for revision. This revision will take on board the GEHR
Australia en USL work via the OpenEhr proposed Models.


Talking about narrative in Medicine.
The narrative is always subjective. It is what the narrator wants to write.
Most often it is the healthcare provider. What he writes is not THE TRUE
STORY it is the story as told by 
Facts are recorded, interpreted, used or ignored and placed in certain
contexts. The highly subjective recorded result is what I call the Pati?nt
Record. Fact and fiction. The EHR is the electronic version of this story
based on selected re-arranged facts. The free text plus facts is
the real stuff what medicine is about. And the more that is stored in a
structured way the better the EHR is computer processable.
Free text expressing the thoughts, the doubts, the professional expertise,
are not debris at all.

Medicine is more than recorded facts and pseudo facts.
Facts? Artefacts is a better phrase.


Gerard


On 2002-06-09 11:59, "Mike Mair"  wrote:

> 
> Dear Gerhard,
> 
> You said:
> 
>> Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and
> is precisely what you want. HL7 version 3 and >CDA will be to unstable for
> some time to come. HL7 doesn't adopt the GEHR (CEN) two model approach.
>> Artifacts based on the present HL7 version 3 RIM will prove to be
> unimplementable as a system or object.
> 
> We can be very encouraged that you may get together with HL7 on this.
> However you (or was it Gunnar Klein) did say  in your ?Berlin CEN meeting
> 2002 presentation (the presentation has disappeared from the
> www.openehr.org. site) that EN 13606 had limited uptake because it was:
> 
> a) incomplete or have offered only partial coverage of the healthcare
> domain;
> b) unnecessarily complex;
> c) too generic, leaving the various implementations too much variability in
> how the models are applied to a given domain;
> d) flawed, with some classes and attributes not implementable as published;
> e) requiring expensive re-engineering of systems;
> f) containing features not required by the
> purchasers of clinical systems.
> 
> The time is evidently ripe for a synthesis. I agree about the importance of
> narrative:
> You said:
> 
>> It is a narrative for personal usage.
>> When information is to be shared the author will select and rewrite parts
>> of his notes in order to meet a specific request by an other healthcare
> provider.
>> This is the way people work. This is the way healthcare providers know how
>> to work with using paper systems.
> 
> Perhaps the record is a resource to make stories out of? The original
> 'syntagm' is just the first, and even that was an interpretation.The 'true'
> story is unknowable.
> 
>> I can see that objective information (orders, test results) can be shared
> by
>> all without real problems. But people (good healthcare) will need
> subjective
>> narrative as recorded in their personal Medical Records.
> 
> Free text remains indispensable, structured data is just the debris left
> behind - it's a point of view...
> 
> Regards
> 
> Mike Mair
> 
> 
> 
> 
> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Data Types

[Gerard Freriks]

Hi,


In my mind I always placed the Null-stuff as an attribute within an
element/Class.   Not in a datatype. It is meta-information.

Gerard






On 2002-06-10 10:03, "Thomas Beale"  wrote:

> 
> 
> Tim Benson wrote:
> 
>> Tom,
>> I do not think that structure can be justified if that structure is
> unlikely
>> to add either value or safety down the line.  So in the situation where we
>> are not able to rely on a time as being either a strict point in time
> or an
>> interval is likely to create semantic problems.  Unless you can rely on
>> strict chronological listing it is unhelpful to try to give spurious
>> precision.  So my suggestion is that such fuzzy dates should be put into
>> free text only and all dates associated with any entry should only be the
>> ones we can rely on, such as date and time of entry.
>> 
> We are having an interesting debate on just this topic on the HL7 CQ
> list (don't know if you get that). The HL7 data type modelling approach
> seems to be to include Null markers all over the place inside the data
> types, so that no matter how little you know, you can still create an
> instance of a structured data item. My reponse to this has been:
> 
> - it makes the data type specification quite a lot more complex, since
> now the semantics have to always include the possibility of an attribute
> or function result of a data item being Null (just start thinking about
> this and it will become more obvious)
> - it will make the implementation of data types and also software that
> uses them more complicated
> - it will create some data instances where parts of the item are
> missing, which will IMO be quite unexpected by most software. E.g.
> IVLs with missing upper and lower limits (but the principle is
> general and applies to all data types). I think there is the potential
> for unsafe data via this approach.
> 
> In the long term, I think this may cause pollution of EHRs and other
> systems with unreliable data items, and cause erroneous results in some
> decision support and query-based applications. It will also prevent
> applications based on a more typical concept of data types from working
> properly.
> 
> I am not saying the HL7 approach is invalid - it is valid - but it is
> also quite complex, and overkill in most cases (in some parts of the RIM
> it is in fact in error, but that's another argument).
> 
> The openEHR approach is much simpler:
> - data types are "clean" - Null markers are specified at the next level
> up in the model
> - some special partial data types such as PARTIAL_DATE are specified,
> because they occur commonly. The model of PARTIAL_DATE explicitly says
> what can be missing and what cannot be, and defines all its semantics
> accordingly
> - if not enough information is known to create a data item, it should be
> recorded as narrative. This way, decision support and querying will not
> be operating on unreliable data.
> 
> This approach can be summarised as an "all-or-nothing" approach - either
> you have the required values to create the data item, or you don't. The
> HL7 approach can be described as an "anything-goes" approach - you can
> create a structured data item no matter how little you know; it will
> just have fewer or more Null markers.
> 
> I am partway though writing up the different design approaches, which I
> will post if anyone wants to see it.
> 
> I wonder what others think.
> 
> - thomas beale
> 
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

Hi,



After analysis done by the Smartcard people in the Netherlands they came to
the conclusion that Smartcards with significant medical information on it
need special safety procedures and back-up facilities.
These extra's necessitate a full back-up centrally and create
synchronisation problems. Everything is technically feasable.
But was to expensive.
They concluded: the smartcard must be used in the process of identification,
only. And even that was very expensive.

With regards,

Gerard





On 2002-06-12 04:18, "Tony Grivell"  wrote:

> At 11:34 +1000 12/6/02, Thomas Beale wrote:
>> Li, Henry wrote:
>> 
>>> This is the process
>>> A patient visits a care provider and presents his e-card as a proof of
>>> consent to treatment
>>> 
>>> The health care provider loads up the health record into the browser and
>>> download the info into whatever system he is using (this applies to Hospital
>>> as well), the health care provider can also choose to discuss the patient
>>> with other health profession on line through the web.
>>> 
>>> When the patient leave the care provider, it is the responsibility of the
>>> care provider to upload whatever he has done to the patient back to the
>>> e-card and the patient goes away. Any subsequent test results etc, it is the
>>> responsibility of the health care provider to contact the patient to have
>>> the data put into the patient's e-card. (the patient can choose not to do so
>>> - but it is of course to the patients benefit to do so)
>>> 
>> So now there are copies of the EHR a) on the patient's card, and b)
>> on the system. Over time there will be many copies of the EHR, some
>> more up to date than the copy on the patient's card. What's the
>> point of having a copy of the EHR on the patient's card?
>> 
>>> The benefit of this is at any one time, the patient is the only person that
>>> has a complete health history of himself and he owns it. (Solve the
>>> 
>> This won't be true - over time I doubt that anyone will have a
>> complete history of the patient - they will all have partial
>> histories, which admittedly is the curret situation, but I don't see
>> any utility in having yet another copy of part of the EHR on the
>> card.
>> 
>> Re: the fear of big brother - I agree this is real; but the
>> solutions in my opinion lie in:
>> 
>> - distributed computing systems
>> - data management by clinical and/or public bodies (non profit
>> enterprises in other words)
>> - strict governance of information and enforcement of consent
>> - data ownership by the patient
>> 
>> - thomas beale
> 
> One attractive option that goes some way to satisfy the above ideals
> is to have any particular data exist in only one primary location
> (backed up, of course), and therefore the total record "scattered"
> potentially around the world.  The patient-held e-card (also backed
> up somewhere?) carries the _index_ to these locations/data, as well
> as being the physical part of a "key" that allows access to this
> data, and maybe also carrying some portion of the data (at least a
> summary of key events and critical information such as serious
> allergies, medication etc)
> 
> tony grivell
> 
> 
>> 
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

The concept of contribution

[Gerard Freriks]

On 2002-06-12 03:34, "Thomas Beale"  wrote:

> 
> 
> Li, Henry wrote:
> 
>> This is the process
>> A patient visits a care provider and presents his e-card as a proof of
>> consent to treatment
>> 
>> The health care provider loads up the health record into the browser and
>> download the info into whatever system he is using (this applies to Hospital
>> as well), the health care provider can also choose to discuss the patient
>> with other health profession on line through the web.
>> 
>> When the patient leave the care provider, it is the responsibility of the
>> care provider to upload whatever he has done to the patient back to the
>> e-card and the patient goes away. Any subsequent test results etc, it is the
>> responsibility of the health care provider to contact the patient to have
>> the data put into the patient's e-card. (the patient can choose not to do so
>> - but it is of course to the patients benefit to do so)
>> 
> So now there are copies of the EHR a) on the patient's card, and b) on
> the system. Over time there will be many copies of the EHR, some more up
> to date than the copy on the patient's card. What's the point of having
> a copy of the EHR on the patient's card?
> >>>>>>

This is the position of the Dutch Smartcard Group.


>> The benefit of this is at any one time, the patient is the only person that
>> has a complete health history of himself and he owns it. (Solve the
>> 
> This won't be true - over time I doubt that anyone will have a complete
> history of the patient - they will all have partial histories, which
> admittedly is the curret situation, but I don't see any utility in
> having yet another copy of part of the EHR on the card.
> 
> Re: the fear of big brother - I agree this is real; but the solutions in
> my opinion lie in:
> 
> - distributed computing systems
> - data management by clinical and/or public bodies (non profit
> enterprises in other words)
> - strict governance of information and enforcement of consent
> - data ownership by the patient
>>>>>>>

Agreed. But ...

"data ownership by the pati?nt" will need some consideration.
I know that most laws in most countries are politically correct and give
rights to patients. But never ownership. Most often a right to inspect,
review, remove, and add information.
In my way of thinking, the author is the owner and one responsible. The
pati?nt has the right to see his information and under certain conditions is
able to remove it or change it.
But what is "Information"?
I think that there are levels or types of information:

"Private Opinions" consisting of personal interpretations of raw data;
"Official Statements/opinions" consisting of professional interpretations of
raw data;
"Raw uninterpreted data" admitted to the EHR;
"Raw interpreted data" not admitted to the EHR, (yet)

Pati?nt have rights towards the last two, but none with the first.
Healthcare providers must have the facility record private unripe thoughts
about the pati?nt and its disease process.
The author os the information is acting as the proxy of the pati?nt.
Patients should have no direct access to all the information. Only to
selected portions of the " Official opinions". The preferred way to inspect
and change is via the responsible proxy.




 
> - thomas beale
> 
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Re Ownership

[Gerard Freriks]

Gunnar,

As a summary of my e-mail:
- Ownership is irrelevant,
- Authorship is relevant,
- Authors that commit information to a record can NEVER remove the
information; they can add;
- Patients can NEVER remove the information; They can add/annotate; Access
control list can be changed by them, only,
- There are different types/classes of data/information,
- Each with possibly different acces control lists and rights,
- Patients need a proxy to exercise all their rights; Proxies can have
mandates,
- My position isn't according to Dutch law. It is a personal one.

Gerard



On 2002-06-12 10:58, "Gunnar Klein"  wrote:

> Dear EHR friends,
> 
> I agree very much with David Guest's opinion that it less fruitful to speak
> about ownership of information though it is done a lot in the debate in many
> countries. It is clearly different from access rights which Gerard is
> speaking about and like David is saying for Australia, in Sweden there is
> usually very little point in trying to distinguishing differnt parts of
> records as less relevant for the patient. i certainly think the
> classification suggested by Gerard in four types of data does not hold.
> 
> Different from the access rights themselves are the rights to decide access
> rights which is quite complicated and varies in different situations. In
> many countries today, the patient concerned always has an overriding right
> of deciding that "his/her" record should be released for reading to a
> specific person or any person. We have an interesting debate in Sweden right
> now on the issue if it is possible to ask the patient to give consent to
> access to records not yet recorded. Some very official legal experts claim
> it is not allowed according to the secrecy act to give a permission to an
> unknown piece of information for the future whereas other legal advisors to
> healthcare organisations are de facto supporting what is built in some cases
> where the patient gives the consent to future relaeases of information to be
> recorded in the future. One example being a centralised list of all currrent
> medication. For standards we have to accept that this type of serrvice will
> be required by some user groups whereas in other legal contexts it will not
> be possible.
> 
> Yet another aspect of "ownership" is the issue of destruction of the whole
> or parts of an EHR. In our legislation as I believe in many others no
> healthcare provider has that right by itself, only a special national body,
> in our case the National Board of Health working directly under the ministry
> of Health can make a decision that allows it and in fact mandate that it
> shall be done usually based on a request by a patient that find that errors
> have been made or harmful opinions expressed by less careful professionals.
> Since many EHR systems installed do not really have a function to do a
> removal of data, these rare situations cause special consultancy services by
> the EHR manufacturer often at high costs 5-15000 EUR.
> 
> Of course a standard requirement shoudl allow for deletion but it is not a
> matter for EHR communication. However, the important thing to note is that
> when records actually shall be deleted it shlould be all copies also sent to
> other providers. Thus, the record need to store logs of record transfers and
> there may be a need to communicate electronically the instruction to the
> recieveing end to delete. However, from a Swedish point of view these
> deletion issues are so rare that it is not an important requirement that
> this should be communicated electronically, one reason is that the
> instruction to another system need to convey also the proof (a paper
> decision for now and a long time to come) of the Authority decision that the
> record can/shall be deleted.
> 
> Best regards
> 
> Gunnar Klein
> - Original Message -
> From: "David Guest" 
> To: "Gerard Freriks" 
> Cc: 
> Sent: Wednesday, June 12, 2002 7:44 AM
> Subject: Re: The concept of contribution - first post :-)
> 
> 
>> Hi Gerard
>> 
>> I have been sitting here in the OpenEHR since February and all of sudden
>> last month someone put through a cyberhighway and the din from traffic
>> has increased enormously. For those who have transferred from other
>> lists I apologise if my ponderings are too facile or have already been
>> covered ad nauseam.
>> 
>> I have never understood the concept of data ownership. I can understand
>> the ownership of things, like hard drives and CD-ROMs, but not data.
>> Data seems to me like a mathematical algorithm or poetry. You can create
>> it, you can interpret it and you can store it. You can also send it on
>> to someone

Clinical blooper? (Was: Re: Data Types)

[Gerard Freriks]

Hi,

When I was thinking about this many years ago,
I needed 4 attributes for a data
item/statement/fragment/transaction/archetype, etc
.
One on Asked/Answered:


Answered YesAnswered No

Asked   The 'normal' answer (3) No response (2)
Yes

Asked   Unsollicited answerthe real 'Null', Not recorded
(1)
No


And then there is the Attribute on Certainty.
And then the one on Completeness.
And the one on Negation.

Gerard



On 2002-06-17 07:43, "Thomas Beale"  wrote:

> 
> One thing to be clear on - we must differentiate between "not recorded"
> and "not there". Not recording someone's weight does not make them
> "weightless" (don't worry I understood the joke, but this is a serious
> point as well). A better example would be - not recording smoking status
> doesn't make the patient a non-smoker.
> 
> There are 5 possible situations I know of that can occur with data:
> 
> 1. it is not recorded (nothing is recorded)
> 2. it was asked (e.g. by an application GUI) but remains unknown due to
> various reasons (patient uncounscious, refused to divulge, etc)
> 3. it is completely known and recorded
> 4. it is recorded, but there are bits missing
> 5. it is recorded, but in the negative (no known allergies, no previous
> surgery, etc etc)
> 
> Cases 2, 4and 5 have not always been properly catered for in systems.
> 
> Case 2 is dealt with in by the use of what i would call "data quality
> markers", i.e. what HL7 calls "flavours of Null". Actually, we call them
> that in the openEHR model, and use HL7's flavours of null (although we
> use them in a different way)
> 
> Case 4 is dealt in openEHR by partial data types e.g. DV_PARTIAL_DATE,
> and with Null Flavours in HL7.
> 
> Case 5 requires proper structurinng of the health record, so that
> negatives can be recorded; archetypes/templates help in this.
> 
> - thomas beale
> 
> 
> Douglas Carnall wrote:
> 
>> In my previous mail to this list (openehr-technical at openehr.org) I wrote:
>> 
>>>> If I see a patient who subsequently turns out to have thyrotoxicosis, but
>>>> do
>>>> not record the presence or absence of certain key clinical findings (e.g.
>>>> pulse, weight, tremor)
>>>> 
>> 
>> Hmm. If I saw a patient with an absent pulse and failed to note that
>> finding, either mentally or in a clinical record, I think I might rightly be
>> accused of being a poor observer of the human condition. Come to think of
>> it, a weightless patient would be interesting too :-)
>> 
>> And everyone has a physiological tremor, though it is often exaggerated in
>> moderate to severe untreated thyrotoxicosis.
>> 
>> So in fact, now I come to think about it again, I didn't mean presence or
>> absence of pulse, weight or tremor, but presence or absence of--all right,
>> use the word, fuzzy, values for pulse, weight or tremor.
>> 
>> But you knew what I meant didn't you?
>> 
>> ;-)
>> 
>> D.
>> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20020617/edaed6a6/attachment.html>

Patient notifications

[Gerard Freriks]

t;>>>> record that the patient can
>>>>> write in - I have (Gates style) called it My
>>> Folder
>>>>> (eh?) and have two
>>>>> subfolders in it at present - consent statements
>>> (as
>>>>> these will be written
>>>>> by the patient) and appointments and
>>> notifications.
>>>>> 
>>>>> It is clear that the patient needs to write and
>>>>> interact with these. I have
>>>>> thought recently that we may be best to develop
>>> a
>>>>> transaction for each of
>>>>> the patient notifications - which will have all
>>> the
>>>>> details in it - rather
>>>>> than process notifications into a collected
>>>>> transaction (like a calendar) -
>>>>> this means that the application will need to
>>> process
>>>>> these.
>>>>> 
>>>>> I have thought that we could have an archive
>>> folder
>>>>> for when the patient has
>>>>> done whatever was required - or declined to do
>>> so.
>>>>> This would mean perhaps
>>>>> an archive folder and an entry for the outcome
>>> of
>>>>> the notification.
>>>>> 
>>>>> What do you think?
>>>>> 
>>>>> Sam
>>>>> 
>>>>> Dr Sam Heard
>>>>> The Good Electronic Health Record
>>>>> Ocean Informatics, openEHR
>>>>> 105 Rapid Creek Rd
>>>>> Rapid Creek NT 0810
>>>>> Ph: +61 417 838 808
>>>>> sam.heard at bigpond.com
>>>>> www.gehr.org
>>>>> www.openEHR.org
>>>>> __
>>>>> 
>>>>> -
>>>>> If you have any questions about using this list,
>>>>> please send a message to d.lloyd at openehr.org
>>>> 
>>>> 
>>>> __
>>>> Do you Yahoo!?
>>>> Yahoo! Mail Plus  Powerful. Affordable. Sign up
>>> now.
>>>> http://mailplus.yahoo.com
>>> 
>> 
>> 
>> __
>> Do you Yahoo!?
>> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>> http://mailplus.yahoo.com
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

Sam,

Could the following be another example?

The Blood pressure.
The RR as an act, a measurement, a procedure.
And the RR as a set of values, the result of the act, the measurement
results, the result of a procedure.

The act is one thing, an intention.
The value as the result of the execution of the intention.

The intention can exist without a real value.

In ENV 13606 part 2 there are the possibilities to add modifiers
(attributes) to 'things' that can express concepts like these.

The question is:
Will we need a new Concept Information Model (archetype) to distinguish
between the two or is one attribute enough?

Gerard



On 03-09-2002 22:31, "Sam Heard"  wrote:

> Dear all,
> 
> I have been working hard to get an ontology of archetypes developed that
> will show the health domain mapped into the openEHR architecture. I have
> found a couple of things:
> 
> 1. That there is often a link between an instruction and subsequent
> observations - which I think will be more important as knowledge bases are
> developed in the future. I have called the link an action specification and
> at present it is modelled as part of the instruction. Let me give a real
> example.
> 
> If you prescribe a medicine then there are a number of attributes of that
> medication order - dose, form, route etc - and there is the frequency of
> administration. When you record that a medication has been administered -
> then you record the dose, form, route etc - but not the frequency. The link
> is the specification of the action - but not the conditional elements of the
> instruction.
> 
> Many other things may be specified at the time that they are ordered and
> there may be protocols etc that are to be followed.
> 
> For this reason - I have two new subclasses in the ontology (not in
> openEHR) - "openEHR Observation - action" and "openEHR action
> specification". This allows me to say which action specification applies to
> an instruction and which obeservations it applies to.
> 
> 2. It might be necessary to state the sequence of different instructions.
> The French oncologists wish to state this for Surgery, Radiotherapy,
> Chemotherapy etc. Clearly each of these will have a complex action
> specification. How then to make it clear about the order of the
> instructions - should one finish before the other starts?
> 
> I welcome your ideas. I have put the zipped (45K) protege files on
> www.gehr.org in the Watch this space section.
> 
> Cheers, Sam
> 
> Dr Sam Heard
> The Good Electronic Health Record
> Ocean Informatics, openEHR
> 105 Rapid Creek Rd
> Rapid Creek NT 0810
> Ph: +61 417 838 808
> sam.heard at bigpond.com
> www.gehr.org
> www.openEHR.org
> __
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

On 13-09-2002 16:51, "Melvin Reynolds"  wrote:

> 
>>> However, the final statement "... As soon as one >starts thinking
>>> about what has to happen to turn messages into EHR >content, it
>>> becomes clearer and clearer that the EHR is nothing like a >compendium
>>> of messages; for from it - it is a time-based accumulator of >EHR
>>> information, some of which is sourced from messages, much of which >is
>>> created by human users of GUI applications." seems like a gross
>>> oversimplification of the reality.
>>> 
>>> It is true a "readable" EHR is not likely to a compendium of
>>> messages.  But an EHR for use in a primary care context is not likely
>>> require to  present the same information (in full) as an acute
>>> secondary care EHR;  and neither are likely to require to present the
>>> full audit trail of  all messages, requests and reports that would be
>>> required of a  medico-legally complete (but clinically unhelpful) EHR.
>>>

The information a healthcare provider submits to the record is what he/she
sees on the screen. This committed information has to be signed. It is not
sufficient that the author is recorded but for legal proof it is necessaryb
that he/she signes the text with his/her private key.

This is the position we (at TNO-PG) take after having studied the legal
literature (1500 pages of texts from EU Directives, Dutch laws, FDA
documents and ethics documents)

So an EHR is a series of signed, authored messages that can be used in
court. Without the fulfillment of the requirements, the EHR is nothing but
information written in the sand before a wave of the sea washes it away.

What an application does with the information on a screen and in its
database is much less relevant from a legal perspective.
What is signed is relevant.

--  --
Gerard Freriks
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

Karsten,

It is the opinion of the Applied Technical Research Institute (TNO-PG), I
work for, after having studied European law and Dutch law that possibly the
only legally valid proof is a signed 'picture' of what was shown on the
screen. E.g. A prescription, an order, a referral.
Next to the information  formally submitted into the EHR their will be a
whole gamut of other secondary information: private notes, not evaluated
results and opinions.
This 'picture' could be generated from information in a database.
Why a 'picture'? Not only the stored information is information; the way it
is presented is information as well. How can one be sure that what is stored
in the database is what has been presented visibly on the screen? (black
characters on a black background, information hidden behind on other window,
etc)

The question open for debate is: what is this 'picture'?
Is it a PDF? Is it Microsoft Word? Is it data in a XML-Document plus the
style sheet used? Is it ...?
What a signature is and what a signed document is, is more clear in Europe.

All this is part of the TNO-PG Essential Requirements for the EHR.
Only systems that comply will fulfil all basic requirements as expressed by
European Directives and Dutch law (that is derived from these Directives)

Gerard

Helas. Copies of these Essential Requirements are not available for
publication, yet. It is a difficult complex document that is being revised
and improved all the time. Until it has been transformed into a usable and
easy readable format we only have copies for internal use and for our
customers that want to have their products approved.
It is our goal to present them to the ISO/TC215 community in due time for
consideration.

On 14-09-2002 10:19, "Karsten Hilbert"  wrote:

>> So an EHR is a series of signed, authored messages that can be used in
>> court. Without the fulfillment of the requirements, the EHR is nothing but
>> information written in the sand before a wave of the sea washes it away.
> This is, however, the way medicine worked for thousands of
> years, and reasonably well, obviously. It is trust that
> defines the doctor-patient relationship, not proof.
> 
>> What an application does with the information on a screen and in its
>> database is much less relevant from a legal perspective.
>> What is signed is relevant.
> Are you suggesting applications should store digitally signed
> screenshots ?
> 
> Regards,
> 
> Karsten Hilbert, MD
> GnuMed i18n coordinator

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

Karsten,
And others,


What is your idea?

- Can you agree with me that it is possible to proof that information was in
a database at a certain time in most systems?
But most systems are unable to proof what was seen on a screen and signed
before being committed to the record or sent to an other entity?
- What are the consequences of the extreme but defendable position of
TNO-PG?

Gerard




On 14-09-2002 11:06, "Karsten Hilbert"  wrote:

> Gerard,
> 
>> that possibly the
>> only legally valid proof is a signed 'picture' of what was shown on the
>> screen. E.g. A prescription, an order, a referral.
> Well, I heard that point of view before. I just wanted to
> verify that this is actually what the organisation you are
> associated with is suggesting.
> 
> Karsten

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

On 14-09-2002 15:16, "David Guest"  wrote:

> On Sat, 2002-09-14 at 21:03, Gerard Freriks wrote:
>> Karsten,
>> And others,
>> 
>> 
>> What is your idea?
>> 
>> - Can you agree with me that it is possible to proof that information was in
>> a database at a certain time in most systems?
> Certainly. That's what Horst's gnotary is about.
> http://www.gnumed.net/gnotary/
> >>>

Trusted functions like these are necessary in general for a better use of
the Internet.


>> But most systems are unable to proof what was seen on a screen and signed
>> before being committed to the record or sent to an other entity?
>> - What are the consequences of the extreme but defendable position of
>> TNO-PG?
> 
> Gerard 
> 
> The logs would show that all the relevant patient data had been
> downloaded to the client. I think it is asking too much of the process
> to also verify that the doctor saw it on the screen, was in a fit state
> to process the data and come to a logical conclusion.
>>>>

I'm not talking of the state of the healthcare provider.
I'm talking about what he saw and thought to sign.

He has no way to see what is in the database down deep in the system.
The only thing is is able to see and vouch for is what he sees on a screen,
piece of paper, etc.


 
> In my experience only the clinical note written on the day can concisely
> log what data was processed to come to the clinical management plan.
> Having pointers to the relevant data is helpful (e.g. see last entry 5
> July 2002; Dr Jones' letter, 26 February 2000, histopathology skin 14
> September 2002). I once thought a drag and drop hyperlink might be the
> best way to do this but text entry is as efficient; just not as cool.
> 
> Is this what you are trying to achieve?
>>>>
No: Vide supra.

Text as pointers or URL's it is all fine with me.
But he signes what he sees.


 
> David 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

NO.
You didn't get it.
So I try again.

I'm making the subtle difference between information in a database and
information presented on a screen.
And signing what is in a database and signing what is on the screen.

By the way. Signing means: "I, the signer, take full responsibility for what
was signed"

Making a hash and signing the hash indicates that a system retrieved
information made a hash out of it and signed it. There is no human
involvement. The human triggered the process, but was no part of it. He
doesn't know what information went into the hash before he signed it. He was
unable to inspect what went into the hash. The signature of the hash means:
this is my hash. It doesn't mean: This is the information I've seen and take
responsibility for by signing.

Making a hash of a screen dump indicates: This is the information as I saw
it on a screen and take responsibility for it by signing.

Information in a database is one thing.
Information on a screen is almost the same but isn't all the times.
Writing black letters on a black background. The information is there but
the healthcare provider can't see it. Information written in a window that
is overlapped constantly by an other window. Etc.

Signing a hash directly from a database is (to me) signing a clean sheet of
paper. And hoping that the system performs well. It won't hold in court or
creates serious problems, al least.

The legal basis for our position is the European Directive
(1999/93/EC,OJL013, 19/01/2000 p.0012-0020)
This directives indicates under which conditions electronic signatures are
equal to paper documents and signatures in ink.
"Advanced electronic signatures which are based on qualified e-certificates
and which are created by a secure-signature-creation device shall:
1 Satisfy the legal requirements of a signature in relation to data in
electronic form in the same manner as hand-written signature satisfies those
requirements in relation to paper-based data; and
2 Be admissible as evidence in legal proceedings"

The above we translate to: a person signs (takes responsibility for) what he
sees on paper (on a screen) and not what is deep down in a complex system
else where outside of his control and not visible.

We are aware that our position will cause serious problems for all present
day systems. They produce signed information perhaps not admissable in
court.
Therefore we are of the opinion that these legacy systems will have to
change in order to get  approval (TNO QM-ICT?) of TNO-TRUST? that they
comply with Dutch and European laws and Directives.


With regards

Gerard


On 14-09-2002 23:24, "David Guest"  wrote:

> On Sat, 2002-09-14 at 23:29, Gerard Freriks wrote:
>> Text as pointers or URL's it is all fine with me.
>> But he signes what he sees.
> 
> I think I've got it, Gerard. What are you signing is that a certain
> dataset was available to you on a particular day for a particular
> patient. You are not signing that you have understood or even looked at
> it but that it was available.
> 
> Wouldn't a hash of the data be both smaller and a more reliable
> attestation of the data available?
> 
> David 
> 

--  --
Gerard Freriks
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

On 15-09-2002 11:26, "Karsten Hilbert"  wrote:

> 1) How do I know that the passphrase I typed in to be used for
> the secret key is used to sign what I see on screen and
> nothing else ?
>>>>

Because a special secure device does all the encrypting.
After having inserted the Health professional Card


> 
> 2) How does the court know that a signed screenshot was
>  actually shown on screen and not just fabricated and never
>  shown ? (It is my responsibility to _inspect_ what is being
>  shown but I cannot prove that signed "screenshots" were
>  actually displayed (on current-day systems).
>>>>>

Because the secure device is able to place the information on the screen.

Having a screenshot provides a richer picture than a set of bits and bytes
down deep in the database.


 
> This isn't about 100% proof, this is about level of trust,
> feasability, deniability and due process. Even with signing
> screenshots.
> >>>

True.
I'll have more confidence in a message displayed on a screen than bits and
bytes in a distributed database in an Health Information Infrastructure


> Or did I miss something ?
> 
> Since it is my responsiblity to carefully inspect the
> on-screen information I could just as well extend that view to
> that it is my responsibility to use a system that I can trust
> to show me what is actually in the database. Thusly I could
> just as well sign database content. Gerard himself remarked
> that we cannot sign that anyone actually reviewed any
> information, only that it was made available. The latter can
> be at the level of a screenshot - or at the level of database
> content. After all it is my responsibility to inform myself
> no matter where I get the information from. Say, I am using an
> SQL shell and sign screenshots of my queries. Does this mean I
> am not liable for the anaphylactic reaction just because I
> didn't do the query for the known penicillin allergy ?!?
> Obviously not, although I understand your position to be: "It
> hasn't been shown to me hence I am not to blame." What other
> purpose might a signed screenshot server ? To shift blame to
> the EHR software manufacturer ?
>>>>>

The whole thing has to do with liability and legal proof.

If next to the information in a database the style sheet used to display is
stored, it is possibly good enough for legal proofs.
 
> Lastly, one simple question. How does TNO propose to handle
> the audit trail of signed screenshots simply in terms of
> storage requirements ?
> >>>>

This is a simple problem.
Now every year one hospital needs 1 kilometre of shelf space.

Have you ever compressed XML documents?
Have you ever looked at diskspace and prices?


>> Making a hash of a screen dump indicates: This is the information as I saw
>> it on a screen and take responsibility for it by signing.
> Nah, I doubt you really believe in the coherency of this
> statement. A screendump merely shows what a screen _may_ have
> looked like.
> >>>>

I think it is fully coherent.

Yes. But systems that have been certified will have a perfect screendump.
This is something that can be tested easily.

To proof that in a distributed environment all informationsystems worked
100% is much more difficult?
Right? Or wrong?

Gerard



> Karsten Hilbert

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype ontology

[Gerard Freriks]

On 16-09-2002 03:03, "Thomas Beale"  wrote:

> I think this is a good overall comment. To which I'll add that what
> needs to be shown to have been understood in court are simple clinical
> or other facts, in the form of propositions, not screen bit patterns. In
> court, it will nee to be shown that that clinician understood fact A, B
> and C before attesting the addition to the EHR. Screen shots are not the
> way to do this. I suggest that a "standardised XML rendition" of the EHR
> entries in question are the way to go.
> 
> Also, we should be careful to differentiate between "attestation" - the
> act of the clinician agreeing that he/she has in fact seen and
> understood what is on the screen be fore committing it to the EHR, and
> "signing" which is an attestation that some lump of content was created
> by a certain person, and not someone else. I don't think "signing"
> guarantees anything about comprehension, just that a particular stream
> of bytes emanated from a source which is positively identified as "Dr
> so-and-so".
> >>>>>

Slowly we are making progress.
I agree that there are several reasons to sign and possibly we need ways to
indicate this.
I agree that there are several contexts. The lonely healthcare provider on
his IT island, the one that exchanges information with a few other
colleagues, the healthcare providers that are part of a complex network for
the exchange of messages, the ones that are part of an higly integrated
system of systems. The more complex the more detail has to be stored
explicitly.
I agree that 'screenshots', 'pictures' can be engineered in several ways.
The most likely candidate is XML-document and XML-stylesheet. But perhaps
there are others.


Gerard

Ps: sorry for having an extemist view.



--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org