Re: Archetype relational mapping - a practical openEHR persistence solution

[Thomas Beale]

This is correct. The usual way I do this with an object model is to 
create a set of P_XXX classes, where 'P_' means 'persistent form'. The 
P_ classes are a transform of the main IM (whatever it is) that does 
things like


 * stringifying a lot of low-level fields
 * ignoring derived fields
 * occasionally using a blob transform where it makes sense.

Then one can start to consider tools like hibernate on the P_ model.

Both the openEHR BMM files and JSON/XML/ODIN save format use this approach.

- thomas


On 26/01/2016 01:52, pablo pazos wrote:
ORM is not a problem with current tools. In fact frameworks like 
Hibernate and Grails make Object-Relational Mapping something 
enjoyable to work with. I think the problem with the described 
approach is the growth of the relational schema when your knowledge 
base grows.


But there are design challenges, ORM doesn't solve all the problems 
itself. IMHO, the object model that should be mapped to relational, if 
relational is chosen as DBMS, is not the raw openEHR IM. 
Simplifications over the IM are needed in order to prevent excessive 
JOINs and huge hierarchies. In fact I teach this in one of my courses 
and this was part of the tutorial we did on MEDINFO. For example, the 
OBJECT_REFs can be designed as simple relationships, because plays the 
role of a FK in the object model. There are many simplifications that 
can be done to reach an object model that is compatible with the 
openEHR model but more "relational friendly".


--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com 


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

Re: Archetype relational mapping - a practical openEHR persistence solution

[Thomas Beale]

based on a quick look, my reaction is the same, unless they have some 
very interesting Archetype => Schema transformation.


On 25/01/2016 14:25, pazospa...@hotmail.com wrote:


I talked about this approach with a colleague from China during 
MEDINFO. The problem is your schema grows with your archetypes. Also, 
that storing data from many templates that don't use all the fields in 
the archetype, will generate sparse tables (lots of null columns). I 
told him it was easier to do an ORM from the IM, because the schema 
doesn't change and allows to store data from any archetype/template. 
But they already have a system working this way.






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

concept maps (Cmaps) for archetyping?

[Thomas Beale]

this group of researchers appears to have created an approach to 
modelling health information using something a bit more powerful than 
mindmaps. They seem to know about CDA but not openEHR.


http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3833511/pdf/gahmj.2012.1.4.003.pdf

- thomas

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

Re: New EHRServer v0.5 and roadmap

[Thomas Beale]

Hi Pablo,

I watched the latest video, very nice. Why not consider a revoiced 
version in English some time? I think it's mature enough to start trying 
to get a wider audience.


- thomas

On 14/01/2016 05:42, pablo pazos wrote:

Hi all!

I'm very excited to share the good news with all my openEHR friends here.

We have released EHRServer v0.5! This version is what we could call 
"feature complete", so it includes all the minimum features of a real 
openEHR server, the latest ones related to securing the API, and 
before that, supporting multi-tenancy.


I'll release user documentation and a full REST API documentation in 
the next couple of days, and will record a demo in English on YouTube 
via Hangout. I made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA


Also, we have a staging server to test the EHRServer*, you are very 
welcome to try it and give us some feedback to continue improving the 
tool: https://cabolabs-ehrserver.rhcloud.com/ehr


* You can create an account and start using it.

Note: the server is not so fast, but is usable.


I'm working hard on v0.6 right now, hopefully we'll have a release 
before February. This version will include fixes to the UI, REST API, 
and security checks, more testing, testable REST API docs, among other 
things. The focus will be on robustness, security, and consistency 
more than adding new features. We can call the EHRServer v0.6 a 
"production ready" system.


I started to meet with some friends and colleagues interested on using 
the EHRServer as an open-source openEHR backend. My next focus will be 
on building pilot projects with some companies, to let them try the 
EHRServer and see if it fits their needs and gathering information to 
improve it. If anyone is interested, please give me a ring or ping my 
by email!




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

Specifications Committee meeting Feb 2016 - have your say

[Thomas Beale]

There will be a SEC (Specifications Editorial Committee 
) face 
to face meeting in Stockholm 11 and 12 February. This will do its usual 
work of considering next releases, processing Problem Reports (PRs), 
Change Requests, and anything else to do with the openEHR specifications 
(e.g. documentation, publishing, UML etc).


If you have raised issues (PRs) about specific problems in 
specifications, they will be dealt with, but you may have other issues 
that you would like the SEC to look at. This could be about anything - 
release frequency, questions you have etc.


Such suggestions can be requested for the SEC meeting agenda on this 
page 
under 
the heading 'Agenda Suggestions'.


- thomas

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

Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Thomas Beale]

On 07/01/2016 17:12, Bert Verhees wrote:

On 07-01-16 17:28, Thomas Beale wrote:


I changed the wiki so that Questions is now visible read-only to 
non-logged in users. I have checked that this works on a test machine.


Works OK now.

What makes me doubt is a very obvious competition-figure-system near 
the questions.

It gives too much away about the people being active on the forum.
I think it can (I don't mean to say it that rough) ~poison~ discussions
I have, however, no problem when it is a (few) mouseclick(s) away.


do you mean the 'top expert' kind of stuff? It seems pre-computed as far 
as I can tell. Let's play with it for a few months and see how well it 
works. We can always try somtehing else later if it doesn't do the job.




Can that be changed?

If not, I will try to live with it.



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

Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Thomas Beale]

I changed the wiki so that Questions is now visible read-only to 
non-logged in users. I have checked that this works on a test machine.


- thomas

On 07/01/2016 15:19, Bakke, Silje Ljosland wrote:


I think for this to be useful, the site have to be readable without 
logging in…


Regards,
*Silje*



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

Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Thomas Beale]

Bert,

were you logged in?

On 06/01/2016 09:33, Bert Verhees wrote:

On 06-01-16 09:07, Bakke, Silje Ljosland wrote:
one of the features we don't use on the wiki is 'Questions', which 
you can see here .

There seems to be an authorization-problem, the site says


  Not Permitted

You are not permitted to perform this operation.



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

Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Thomas Beale]

one of the features we don't use on the wiki is 'Questions', which you 
can see here .


This supposedly is the same kind of function as StackExchange, which we 
didn't get off the ground. So maybe we should try locally.


My proposal would be for some community members to raise a question or 
two at the above link and see what the experience is like for creating 
answers, upvoting etc. We might find it is good enough.


For reference, here is the openEHR StackExchange page 
, which might 
be useful for remembering questions people had.


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

Re: CAMSS assessment of openEHR

[Thomas Beale]

I have set up a CAMSS wiki page 
<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>, 
Silje if you can copy the relevant CAMSS boilerplate in (assessment 
table etc) and make it look vaguely presentable (make child pages if you 
need) then I am sure the community can get it populated quickly for you, 
since it's clearly of general benefit.


- thomas


On 04/01/2016 14:24, Bakke, Silje Ljosland wrote:


Hi Thomas, thanks for your reply!

I don’t have any say in which assessment criteria are used, 
unfortunately. I’ve seen your criteria, and agree they’re more 
specifically applicable to e-health standards.


I’ll probably need a lot of help answering and justifying the CAMSS 
questions, especially those regarding the governance of the 
specifications. I hope it’s okay if I pose specific questions to this 
list.


Regards,
*Silje*

*From:*openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of 
*Thomas Beale

*Sent:* Monday, January 4, 2016 2:57 PM
*To:* openehr-technical@lists.openehr.org
*Subject:* Re: CAMSS assessment of openEHR


Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using 
CAMSS much, if we believe this page, which contains CAMSS assessments 
<https://joinup.ec.europa.eu/community/camss/og_page/camss-assessments>, 
none of which are health related. On this page 
<https://joinup.ec.europa.eu/community/camss/og_page/list-standards>there 
is a much larger list of 'recommended' standards which are all generic 
(PDF, GIF and so on) - I don't know what use this is.


This page 
<https://joinup.ec.europa.eu/community/camss/wiki/camss-05-detailed-camss-criteria>has 
a long page of assessment criteria, which seem mostly reasonable to 
me, but are will probably miss what I would consider the most 
important criterion for value - longevity. I personally think 
longevity is ultimately based on semantic scalability (lack of other 
things will also kill it, like lack of community, implementations 
etc). See here 
<http://wolandscat.net/health-informatics/desiderata-for-successful-e-health-standards/>for 
my set of criteria.


I also don't think that compatibility with other standards is 
necessarily a useful criterion - it depends on whether those other 
standards are in use and are themselves delivering value or just 
getting in the way.


But overall the assessment tool seems OK. What I can't see is any 
example of where it has been applied to an e-health standard.


- thomas



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

Re: CAMSS assessment of openEHR

[Thomas Beale]

Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using 
CAMSS much, if we believe this page, which contains CAMSS assessments 
, 
none of which are health related. On this page 
there is 
a much larger list of 'recommended' standards which are all generic 
(PDF, GIF and so on) - I don't know what use this is.


This page 
has 
a long page of assessment criteria, which seem mostly reasonable to me, 
but are will probably miss what I would consider the most important 
criterion for value - longevity. I personally think longevity is 
ultimately based on semantic scalability (lack of other things will also 
kill it, like lack of community, implementations etc). See here 
for 
my set of criteria.


I also don't think that compatibility with other standards is 
necessarily a useful criterion - it depends on whether those other 
standards are in use and are themselves delivering value or just getting 
in the way.


But overall the assessment tool seems OK. What I can't see is any 
example of where it has been applied to an e-health standard.


- thomas


On 04/01/2016 12:42, Bakke, Silje Ljosland wrote:


Hi guys,

As part of a standards assessment project initiated by the Norwegian 
Directorate of Health, several health IT standards will be assessed 
using CAMSS (https://joinup.ec.europa.eu/node/66790). Have anyone done 
a CAMSS assessment of the openEHR specifications? If so, would it be 
possible to share the results?


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
National ICT Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: 
@arketyper_no 




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

Making FHIR work for everybody

[Thomas Beale]

Here is a blog post on a proposal for making FHIR work more easily with 
other health information architectures 
, 
including openEHR, which may interest some people here.


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

Re: Specialization depth

[Thomas Beale]

The error messages are actually in ODIN format, which can accommodate 
EN-US as well as EN, if we really want to bother with that.


- thomas

On 17/12/2015 07:16, Bert Verhees wrote:




For US/international English spelling, we tend to use International 
English for all natural language, and where we can, accommodate US 
English in the formal spec. Thus, an ADL parser has to be able to 
parse specialise | specialize. The error texts probably are not 
consistent.


The problem is only important for keywords in a definition language, 
it is cumbersome to let a parser check several spelling-forms in 
keywords. The problem I found, however was in a data-string (an 
error-message), and in that case, it is possible to have more 
languages, which can be changed and do not effect the parser. So, I 
take back my remark on this.




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

Re: Specialization depth

[Thomas Beale]

ARCHETYPE_ID is for AOM 1.4, ARCHETYPE_HRID is for AOM 2.0

We will rationalise all these classes in to the BASE component in 
Release 1.1.0 of the RM.


- thomas

On 17/12/2015 07:24, Bert Verhees wrote:

On 16-12-15 14:05, Thomas Beale wrote:

that's why it is gone in ADL2/AOM2.

The new ARCHETYPE_HRID class is the one that matters, and it does not 
know about specialisation depth. 

Please allow me a question, maybe it is explained somewhere.

What is the meaning of the class Archetype_Id in the support-section 
of RM 1.0.3, while in the AOM Archetype_HRID exist which overlaps the 
first.


Thanks
Bert

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





--


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

Re: Specialization depth

[Thomas Beale]

On 16/12/2015 10:54, Bert Verhees wrote:

On 16-12-15 11:37, Diego Boscá wrote:
but there is an example of an specialized identifier in that same 
document
e.g. 
"uk.nhs.clinical::openEHR-EHR-SECTION.t_encounter_report-vital_signs_headings-0001.v1"
in 
http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_an_example


Thanks Diego, for pointing this out, I checked it in RM 1.0.3 
ArchetypeId, and there is indeed a specialization-numbering in the 
archetype identifier.
So this information will become redundant in the archetype, available 
in the concept/root-node id, and in the archetype id.


This is not good, according to many programming standards which advise 
to not have redundant information.


Because it adds nothing, and if it differs, it is not trustworthy.


that's why it is gone in ADL2/AOM2.

The new ARCHETYPE_HRID class is the one that matters, and it does not 
know about specialisation depth.


- thomas




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

Re: Specialization depth

[Thomas Beale]

This is not a specialised identifier, it's just an identifier that has 
'-' characters in it, which in ADL2 are not special.


Just look at the id1.x code of the root node to get the specialisation 
depth of any ADL2 archetype.


- thomas

On 16/12/2015 10:37, Diego Boscá wrote:

but there is an example of an specialized identifier in that same document
e.g. 
"uk.nhs.clinical::openEHR-EHR-SECTION.t_encounter_report-vital_signs_headings-0001.v1"
in http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_an_example




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

Re: Specialization depth

[Thomas Beale]

That is gone in ADL2.

in ADL2 you can know the specialisation depth of the archetype by 
looking at the root node code, e.g.


id1 -> depth = 0
id1.1 -> depth = 1
etc

For US/international English spelling, we tend to use International 
English for all natural language, and where we can, accommodate US 
English in the formal spec. Thus, an ADL parser has to be able to parse 
specialise | specialize. The error texts probably are not consistent.


Bert, can you create a PR for 'ADL2/AOM2 documentation errors' or 
similar in the main PR tracker. If you find a number of them, it wold be 
preferable to include them all in the description of the one PR, rather 
than create a proliferation of PRs, for obvious reasons.


An official release of AOM2/ADL2 is around the corner and we'll include 
fixes for any errors you find.


thanks

- thomas

On 16/12/2015 09:52, Diego Boscá wrote:

The concept_id part from the archetype_hrid shows all the parents of a
given node (or at least did in 1.4)

2015-12-16 10:42 GMT+01:00 Bert Verhees :

On 16-12-15 09:50, Diego Boscá wrote:

Parsing current archetype identifiers you can know the specialization
depth and compare it with root node_id.


Hi Diego,

Thanks for your answer, and I hope you will answer my follow up question

I thought the the versionId's in the archetype_hrid denote the
corrections/versions on an archetype.
But maybe I misunderstand that concept.

Or are you referring to something else?

Bert




2015-12-16 9:42 GMT+01:00 Bert Verhees :

Hi all,

I am looking at this error message from

http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_validity_rules

VARCN: archetype concept validity. The node_id of the root object of the
archetype must be of the form id1{.1}*, where the number of .1 components
equals the specalisation depth, and must be defined in the terminology.
(which has a spelling-error in "specalisation", it should be
"specialisation")

My first question:
How can the parser know the specialization-depth?
When I look at the grammar, it seems not possible to layer the
specializationSection
So it can only check that it is a specialization.

Or am I overseeing something

My second question:
There is another thing, only small, thing, not very important, but I
thought, I mention it anyway.
In the grammar specialization is spelled in the US way ( in
specialization_section : SYM_SPECIALIZE archetype_ref ;), while in the
error-messages specialisation is spelled in the UK-way (in VASID).

Is there a preferred spelling for when handling texts which belong to
software-definitions?

Thanks
Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

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


--

*Thomas Beale*
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> Culture blog 
<http://wolandsothercat.net/>


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

ADL 1.4 specification - now in Asciidoctor format

[Thomas Beale]

The old ADL 1.4 spec is now online 
 in the new 
format. This was done primarily to:


 * fix various formatting
 * fix syntax rendering
 * provide a source form of the ADL 1.4 spec in case interim releases
   between 1.4 and 2.0 are required.

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

Re: Party-actor-folder relationships in hierarchy

[Thomas Beale]

A couple of words of advice: normally, EHR and demographics 'databases' 
would be separated for security and operational reasons. EHRs are not 
normally 'inside' any demographic entities. This section 
in 
the openEHR Architectural Overview may be helpful; also this one 
.


If you are cohosting what are logically separate EHR repositories on a 
cloud service, openEHR does not say anything much about how to organise 
them, although you should consider carefully implementing an 'EHR / 
subject cross-reference' service as briefly described here 
.


You also need to consider how to implement RBAC, and 'legitimate 
relationship' so that only the right people can see the right EHRs.


- thomas

On 26/11/2015 22:36, Dmitry Baranov wrote:

Hi, I have a lot of practical questions to ask :)

Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:

- Database
   [C] ACME company (1.1.1.1)
 [S] EHR System 1 (1.1.1.1.1)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items

 [S] EHR System 2 (1.1.1.1.2)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items



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

Re: Party-actor-folder relationships in hierarchy

[Thomas Beale]

If people want specific changes to the specifications, please raise a 
Problem Report in the usual place 
. 
Otherwise we don't know what the specific shortcomings are.


- thomas

On 27/11/2015 09:02, Bert Verhees wrote:

On 27-11-15 09:56, Dmitry Baranov wrote:

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, 
by the way


That is a point, why is it not like that in OpenEHR or EN13606?

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





--

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

Re: Party-actor-folder relationships in hierarchy

[Thomas Beale]

Hi Bert,

there is no 'policy' about treating the Demographics specification as 
'inferior'. The practical point about demographics is that it is often 
not implemented because many clinical IT environments  already have an 
MPI, so an openEHR EHR system typically implements the 
PARTY_PROXY.external_ref pointers 
from 
the EHR data instead.


But some environments need an openEHR demographic service, and I predict 
more will, even when they have an MPI, because the MPI data is not 
versioned or extensible.


Release 1.0.3 of the ITS component will have XSDs for everything. This 
release is likely to be out by the end of the year or very soon afterward.


- thomas

On 27/11/2015 08:33, Bert Verhees wrote:

I think it is very easy to solve.

The premise is that several legal entities are sharing patients, and 
also share an EHR system, and you want to distinguish which treatment 
is given by which legal institution.


It is easy, build your system so, that all compositions are also 
placed in folders pointing to the legal institutions which gave the 
treatment.
As you maybe know, a composition can be in several folders 
simultaneously.


So you can have a folder-system representing legal institutions that 
share the EHR-system, and folder systems on medical reasons.


In this way it is easy to organize authorizations related to the legal 
entities, and also other queries



I discovered the demography.xsd just yesterday, accidentally, on LiU 
github :)
For some reason it is missing here - 
http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/


That is something funny, demographics are something which are treated 
as a stepchild, not only in OpenEHR, but also in EN13606. In EN13606, 
demographics can't even be archetype.
In OpenEHR, I remember a message on the list, some years ago, I 
thought written by Sam Heard, that it should be replaced by non 
semantical generic structures, which also exist in OpenEHR.


But fact is indeed that there is always something with it.

In LinkEHR-archetype-editor they have a demographics.xsd, you can 
download it when you download their editor.  In LinkEHR they also have 
a demographics.xsd for EN13606, although this should not be 
archetypable at all.


I would be interested what people think about this way demographics 
are treated as a kind of inferior information-structure.


I think we need an answer from the OpenEHR foundation as it must be a 
defined policy to do it this way.


Bert



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

openEHR RM Release-1.0.3 - EHR Extract - SURVEY OF USE

[Thomas Beale]

*If your organisation or implementation uses the openEHR EHR Extract 
specification PLEASE READ THIS.*


Release-1.0.3 is getting close. For those with too much time on their 
hands, you can follow progress here on Jira 
.


We have implemented a subset of Change Requests on the *EHR Extract 
specification *(old Rel-1.0.2 PDF 
; 
new-style latest draft HTML 
) 
which contain breaking changes, as follows:


 * SPECRM-10 : Upgrade
   EHR_EXTRACT to Release 1 of EHR IM
 * SPECRM-13 : Convert
   various fields to coded in EHR Extract.
 * SPECRM-14 : Various
   EHR Extract model improvements
 * SPECRM-6 : Correct
   modelling inconsistency of every EXTRACT_CHAPTER being related to a
   single Entity

The exact changes are described below, and are visible in the latest 
draft of EHR Extract 
. 
Most of them were in the 1.0.2 spec; some weren't except as notes; all 
of them were designed some years ago. The changes are reasonably 
extensive, and some are *technically breaking changes*. As far as we 
know, this is not a problem because the EHR Extract is not in use (the 
world seems to have moved on from the 'extract' idea). If that is true, 
it should be acceptable to allow these changes through in Release 1.0.3 
(since they are old changes anyway).


*However if there are users of this specification, we would like to 
know, in order to determine whether to move these changes into another 
release - please respond on this list if this is your case.*


thanks

- thomas

The detailed list of changes is as follows (by visiting the CRs above, 
you can actually find the links into the Github diff view for each file).


SPECRM-10
- add X_VERSIONED_OBJECT class
- add template binding classes X_VERSIONED_FOLDER, 
X_VERSIONED_COMPOSITION, X_VERSIONED_EHR_ACCESS, X_VERSIONED_EHR_STATUS, 
X_VERSIONED_PARTY to accommodate specific types of openEHR content 
within X_VERSIONED_OBJECT objects.


SPECRM-13
- EXTRACT_SPEC.extract_type is changed to DV_CODED_TEXT
- EXTRACT_ACTION_REQUEST.action is changed to DV_CODED_TEXT.
- EXTRACT_UPDATE_SPEC.trigger_events is changed to be of type 
List.


SPECRM-14
- remove EXTRACT_SPEC.includes_directory and directory_archetype; assume 
that Extract spec and request pairs are modelled together, and that 
EXTRACT_SPEC.extract_type will indicate what kind of extract should be 
returned.

- remove EXTRACT_ENTITY_CONTENT class
- make EXTRACT_FOLDER classes the main containment structure; assumed to 
be archetyped.

- move X_VERSIONED_OBJECT to openEHR Extract package.
- change EXTRACT.request_id to a HIER_OBJECT_ID

SPECRM-6
- a subtype of EXTRACT_CHAPTER is added to the model called 
EXTRACT_ENTITY_CHAPTER

- the class EXTRACT_ENTITY_IDENTIFIER is removed
- the class EXTRACT_ENTITY_MANIFEST is augmented with the attributes:
- extract_id_key[1]: String // id by which this entity (usually a 
patient or EHR) is known in the extract

- ehr_id[0..1]: String // EHR or EMR id
- subject_id[0..1]: String // patient id, UPI
- other_ids[0..1]: Hash // other ids the subject or 
record may be known by
- the class EXTRACT_ENTITY_CHAPTER has a copy of the attribute 
extract_id_key, to mark each such chapter with a meaningful identifier 
within the extract.


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

Re: Binding to multiple terminologies / code systems

[Thomas Beale]

On 30/10/2015 16:00, Barnet David (HEALTH AND SOCIAL CARE INFORMATION 
CENTRE) wrote:


Thomas

For use (NHS in England) it’s probably at the template level (but it 
would be good to occasionally specify at the node level).




just to be clear on this point, because this is the one I want to know 
about. Consider the following archetype extract:


~

definition

OBSERVATION[id1] matches {-- *Liver function test*
data matches {
HISTORY[id2] matches {
events matches {
EVENT[id3] matches {-- Any event
data matches {
ITEM_TREE[id4] matches {
items matches {
ELEMENT[id6] occurrences matches 
{0..1} matches {-- *Test name*

value matches {
DV_CODED_TEXT matches {[ac1]}
}
}
ELEMENT[id7] occurrences matches 
{0..1} matches {-- *Test status*

value matches {
DV_CODED_TEXT matches {[ac2]}
}
}
 CLUSTER[id8] occurrences matches 
{0..1} matches {-- *panel*

items matches {
ELEMENT[id6] occurrences 
matches {0..1} matches {-- *bilirubin*

value matches {
DV_QUANTITY matches 
{...}

}
}
 -- etc
}
}
   }
   }
   }
   }
   }
   }
   }

terminology
bindings
["snomed_ct"] =  <

["ac2"] =   -- 
assume SNOMED has a value set of test statuses


["id3"] =   -- SCT code for 
bilirubin


>
["loinc"] =  <

["id1"] =   -- LOINC code for 
'Liver function test'


["ac1"] =   -- assume 
LOINC has a value set of specific LFT test names (there are >1)


>

~~~

In the above, we don't need to do anything special to make sure that the 
node id1 and value set at ac1 are coded from SNOMED CT, and that id3 and 
ac2 are coded from LOINC - because the bindings don't provide for 
anything else. But if there was a binding for ["id1"] in both the 
snomed_ct and the loinc binding group then we might need a capability to 
say: on this particular OPT, I only want to allow LOINC at node id1, 
while being able to allow other nodes to still use SNOMED CT and / or 
LOINC in different permutations.


The latter is obviously more complicated to specify in a generated 
template, because now you really do have to able to mark different nodes 
as differentially subsetting their allowed bindings, for some particular 
purpose.


I'm hoping we don't need to do this, but would like to know if it is needed.

thanks

- thomas

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

Re: OPT2 specification, choosing terminology bindings...

[Thomas Beale]

looks like sharing SVGs in email is not a good idea... 2nd go


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

OPT2 specification, choosing terminology bindings...

[Thomas Beale]

One of the final things to get right in ADL2 is how to choose 
terminology bindings, also languages and a few other settings when going 
from source archetypes and templates to the OPT. I have put up a draft 
OPT2 specification 
with some 
ideas on this, which people may be interested to comment on. The 
following overview diagram from it gives an idea.


opt tool chain

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

Re: Binding to multiple terminologies / code systems

[Thomas Beale]

Dave,

the solution to this situation is not yet 100% clear in ADL2 (it is in 
ADL1.4, as others have described). We are trying to define a cleaner way 
to represent it in ADL2, but I'm still not clear on the requirements. It 
appears that the scenario you have is that since SNOMED CT, READ and 
CTV3 are extant in the UK, coding should be allowed using any of those, 
but not by other means.


Does this apply across the whole HSCIC model library? Or do you want 
some more fine-grained control, e.g.:


 * do you want to designate certain terminologies for specific
   templates ? E.g. template A can only use SCT, but template B can use
   any of the three?
 * do you need to say on a node-by-node basis in a single template,
   e.g. this node must be coded by SCT, but this other node by say
   SCT-or-READ, and this third node, any of the 3 are allowed?

If others can clarify requirements in this area as well, it would be 
very helpful.


See here in the ADL2 draft spec 
for 
current thinking on this.


thanks

- thomas


On 29/10/2015 15:31, Barnet David (HEALTH AND SOCIAL CARE INFORMATION 
CENTRE) wrote:


All

I have a modelling issue where I’m trying to bind a single data point 
or an archetype to a choice of terminology & code systems.


The actual use case is that I’m modelling a new-born hips examination, 
and the result may be given as either a SNOMED CT concept, a Read 2 
code or a CTV3 code (for those unfamiliar with Read 2 & CTV3, they are 
code systems used (mostly) in primary care in the UK). In the actual 
instance, each code/concept will have a code system identifier to 
distinguish the actual code system used


For example, a result of “no abnormalities and no risk factors” can be 
represented as either


*SNOMED CT*



*Read2*



*CTV3*

ID



FSN



ID



Term



ID



Term

98570100100



Newborn and Infant Physical Examination Screening Programme, hip 
examination done, no abnormality and no risk factor




9OqJ1



NIPE hip, no abnor&no rsk fctr



XadAN



NIPE hip, no abnor&no rsk fctr

In the modelling tools I see you can have a choice, but I can’t see 
how the choice supports multiple terminologies. I see that it does 
support a choice of a terminology & Free text.


Is there a “standard” way of saying a data point may be represented by 
one of 3 terminologies/codes systems? Or is this something the tooling 
deliberately stops you doing?


Thanks in advance



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

Re: Binding to multiple terminologies / code systems

[Thomas Beale]

The answer isn't completely simple. Some background here 
. 
If there are bindings defined for snomed_ct, read2 and ctv3 to the 
ac-code that appears in the archetype definition section, and no further 
constraint is given, the implication is that any code from any 
terminology with a binding may be used at runtime. Since this is 
normally on a value-set by value-set basis, each value set (each 
distinct ac-code) will have a binding entry only in those terminology 
groups in the binding section that make sense.


On 29/10/2015 15:31, Barnet David (HEALTH AND SOCIAL CARE INFORMATION 
CENTRE) wrote:


All

I have a modelling issue where I’m trying to bind a single data point 
or an archetype to a choice of terminology & code systems.


The actual use case is that I’m modelling a new-born hips examination, 
and the result may be given as either a SNOMED CT concept, a Read 2 
code or a CTV3 code (for those unfamiliar with Read 2 & CTV3, they are 
code systems used (mostly) in primary care in the UK). In the actual 
instance, each code/concept will have a code system identifier to 
distinguish the actual code system used


For example, a result of “no abnormalities and no risk factors” can be 
represented as either


*SNOMED CT*



*Read2*



*CTV3*

ID



FSN



ID



Term



ID



Term

98570100100



Newborn and Infant Physical Examination Screening Programme, hip 
examination done, no abnormality and no risk factor




9OqJ1



NIPE hip, no abnor&no rsk fctr



XadAN



NIPE hip, no abnor&no rsk fctr

In the modelling tools I see you can have a choice, but I can’t see 
how the choice supports multiple terminologies. I see that it does 
support a choice of a terminology & Free text.


Is there a “standard” way of saying a data point may be represented by 
one of 3 terminologies/codes systems? Or is this something the tooling 
deliberately stops you doing?


Thanks in advance

Dave Barnet
Interoperability Lead

Interoperability Specifications

Health & Social Care Information Centre

NHS in England


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

Re: Archetype publication question - implications for implementers

[Thomas Beale]

As a reminder, the current draft spec on versioning and lifecycle 
is 
here, and as usual, comments are welcome 
.


- thomas



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

Re: Archetype publication question - implications for implementers

[Thomas Beale]

On 19/10/2015 13:10, Heather Leslie wrote:


The versioning rules have been following. This is a use case that is 
testing them, testing our strategy. Excellent.


What does specialisation add to this? We still have a changed MD5, new 
archetype ID, etc… Aargh.


If we specialise, what happens when the next change comes along? 
Specialise the specialisation? Rinse, wash, repeat?




the normal situation if these were software artefacts would be that you 
would recompile them all, and anything else that become invalid due to 
the changes in some changed archetype would then have to be changed as 
well; anything that still validates remains fine.


This specifically works based on the 'specialise' statement in an 
archetype that normally refers only to the interface ID, i.e. an id that 
includes only the major version.


This of course relies on the ADL2 differential representation of 
archetypes, and the ADL2 identification and referencing rules.


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

Re: Archetype publication question - implications for implementers

[Thomas Beale]

Hence my earlier proposal...

On 19/10/2015 09:18, David Moner wrote:



2015-10-16 3:22 GMT+02:00 Heather Leslie 
>:


·It means that new implementers can use the corrected v1 revision
and we don’t have to create a v2 for a relatively trivial problem;
existing vendor implementations can remain unchanged or they can
choose to update the units if they please. The MD5 changes, but
all paths etc are identical. A minimal disruption approach, if you
like – thanks Heath.


And what happens if a new implementation sends data to an old 
implementation? Since the archetype identifier has not changed the 
receiver will use its own archetype to validate the received data, and 
if it includes the 'deg' unit it will just fail the validation. 
Breaking revisions are not only about changing the archetype 
structure, but also about generating a different set of possible 
instances.



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

Re: Archetype publication question - implications for implementers [ long ]

[Thomas Beale]

surely the obvious approach is that the stored field contains the UCUM 
case-sensitive code, and that applications / services use UCUM tables to 
render whatever display form is asked for in a client call? (I realise 
openEHR archetypes are not doing this; they should be...)


there's another problem: in both v2 and CDA, HL7 specified a single 
units field on the assumption that implementers could somehow square 
the circle and have a single units that satisfies human and computer 
readability. This is not possible. Hence the mess we are in.






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

Re: Archetype publication question - implications for implementers [ long ]

[Thomas Beale]

Eric,

nice summary of issues. If I can take the liberty of pulling out what I 
think are your key issues to worry about + recommendations. I bolded my 
own subset of those ...


On 10/10/2015 10:07, Eric Browne wrote:



*Notes on UCUM*

* UCUM does not supply normative names of units.
* Some of UCUM’s names have been US-ised. E.g. /litre/ has been 
changed to /liter/, /metre/ to /meter/, /deca/ to /deka/.
* *Implementers of UCUM must choose between case insensitive and 
case-sensitive versions*. The two cannot co-exist in the same channel 
of communication without special additional processing.
* Even using UCUM, some units are difficult to represent and agree 
upon e.g. the unit for measuring estimated Glomerular Filtration Rate, 
quite common in healthcare - see http://unitsofmeasure.org/trac/ticket/98


*Notes on openEHR’s implementation of UCUM within the AOM.*

*  The specification is a little vague on adherance to UCUM for 
units, stating that unit strings are to be expressed in UCUM unit 
syntax. This allows for support of units beyond those defined in UCUM.
* The current openEHR BNF for parsing units appears to have some 
errors if it were to be considered UCUM-conforming - e.g. presence of 
‘μ’ symbol; absence of ‘[‘ and ‘]’ symbols.
* openEHR is unclear on which variant(s) of UCUM ( case-sensitive, 
case-insensitive, print ) should be supported or mandated.
The current openEHR BNF for parsing units cannot support 8-bit UCUM 
units such as ‘°’ i.e. degree symbol in values conforming to type 
DV_QUANTITY.


=> conclusion: we should have a PR to correct these issues so that the 
current specifications are at least clear, even if they still may be 
'wrong' in some larger analysis.


Eric, can  you raise a PR here 
, 
with the relevant bullet points from this list? I think we could include 
changes to Release-1.0.3 to make these corrections.




*Tooling implementations for openEHR units*

* Clinical Knowledge Manager - *Many archetypes on the international 
CKM use non-valid UCUM units*.


*Implications for Archetypes, Archetype repositories and Archetype 
Governance

*
* Some unit issues, such as the Blood Pressure tilt angle could be 
“fixed” simply by adding the normative UCUM unit and flagging the 
deprecated unit as such. However, tools would need to be updated to 
allow these new, “fixed” units to be entered where they previously 
could not. Only some of the existing openEHR units could be “fixed” 
this way.
* I think units are somewhat akin to terminology systems like SNOMED. 
There are significant implementation complexities.  The main value in 
standardising units is to ensure safety and quality of data from 
disparate sources. The main additional value in adopting UCUM more 
fully is to support unit conversion.
* Ideally, in order just to support UCUM well, *openEHR 
implementations should support the case-sensitive UCUM value*, the 
print value and the unit definitions, all supplied by UCUM via 
the published XML file. This does not mean that the DV_QUANTITY type 
needs to change, but *it would mean updating existing archetypes to 
replace the current archetype units with the correct UCUM 
case-sensitive one*. Let’s call this the UCUM code. openEHR archetype 
editors would then map these UCUM codes to unit displaynames ( i.e. 
the UCUM print value ).  openEHR applications would also ideally map 
the UCUM code to unit displaynames. i.e. Applications and archetypes 
use UCUM codes internally, but those codes aren’t displayed to humans.
* If there are grounds for changing the Blood Pressure Archetype to 
“fix” the Tile Angle, then those same grounds dictate that many more 
Archetypes be changed.  This *should be undertaken as a major 
versioning exercise*, probably with 6 months warning 
* There will always be tension between national and international 
archetype repositories trying to produce models for an ideal world, 
rather than for implementations that have to operate in the real 
world. My observations of how the openEHR world is evolving is that 
*these archetype repositories do generally, and should try to set a 
gold standard*. _They should push implementations  rather than retard 
them_. The trouble with “fixing” the units of all currently 
published archetypes is that adopting them in order to really make use 
of the normative UCUM units would mean pain for implementers. But for 
what gain?



*Notes on current practice regarding unit usage in  HL7 laboratory 
messages*


I include the following, simply because it tries to illustrate how 
units are currently handled in many typical data sharing environments.
* Legacy, non-openEHR systems using 7-bit databases might use 
predefined table of units something like UCUM - more likely they would 
specify their own unit system - perhaps “deg” for values for "°C” in a 
sy

Re: Archetype publication question - implications for implementers

[Thomas Beale]

I've skimmed the replies on this thread, and I'm inclined to think 
everyone could be right. Problem is, they can't all be right at the same 
time.


So considering the issue from a global deployment perspective I had 
the folllowing idea:


 * in the archetype library, we should stick to proper versioning
   rules, as Diego, David and Sebastian have said, and correct the
   error and issue a new v2 archetype
 o => this way there are no surprises in the archetype library for
   software, or people, by the time we have forgotten about this issue
 o => the paths would stay the same to the various data fields, but
   the units in the tilt table field would be different, and will
   break anything that specifically relies on that
 * but we still may need a way of making adding the correction to the
   v1 version of the BP archetype, for some users, to enable their
   current queries and software based on the 'v1' id to keep working.
   This could be achieved by:
 o creating a specialisation of the v1 archetype that adds a new
   node as Sebastian proposed, or via Heath's proposal
 + => this means that the deployment has to use a new archetype
   id for data production (i.e. in the CDR), but AQL queries
   using the old id should continue to work, assuming the query
   processor correctly finds child archetypes for a given
   archetype id
 o OR enable a modification in the template that has the effect of
   adding the required unit or element
 + => this means that all ids stay the same in data production
   and querying, but the CDR is being told a white lie, in that
   what it thinks is the BP archetype is not exactly what it is
   back in the CKM library

I haven't tried to analyse the details here that far, but the general 
idea is to:


 * a) ensure the archetype library follows the versioning and change
   rules properly
 * b) inject an adjusting fix either as a specialisation, or further
   along in the processing chain - in a template (or even OPT)

thoughts?

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

OS licences - CC-BY-SA 4 compatible with GPLv3

[Thomas Beale]

Announced here officially - http://creativecommons.org/compatiblelicenses


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

New adl-antlr GitHub project

[Thomas Beale]

I have created a new Github project called adl-antlr 
<https://github.com/openEHR/adl-antlr>, to contain a development set of 
Antlr4 grammars for ODIN and ADL, for use (at least currently) with the 
Community Edition of IntelliJ IDEA, with the Antlr4 plugin.


See the README page at the above link if you are interested in using 
this resource, or participating in the development.


- thomas

--
*Thomas Beale*
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> Culture blog 
<http://wolandsothercat.net/>


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

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Thomas Beale]

On 30/09/2015 07:51, michael.law...@csiro.au wrote:
Imagine instead the example was using the corresponding AMT concepts 
(since snomed pure doesn't have any concrete domain modelling -- I.e. 
numeric values).


Then the focus concept would be the AMT amoxycillin Medicinal Product 
concept 2141501136100 and the constraint matches would be MPUUs 
and TPUUs with capsule form and between 500 and 800 mg of amoxycillin 
as an active ingredient




ok - so the query would be applied to instances in a drug database (each 
instance there is a drug descriptor)?


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

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Thomas Beale]

Hi Michael,

in that case, to what information base or DB could the amoxycillin query 
be applied? What is it for?


thanks

- thomas

On 29/09/2015 23:19, michael.law...@csiro.au wrote:

Hi Thomas,

These constraints are essentially queries over the snomed definitional 
content (ie the Relationships), not queries over external data (ie not 
EHRs).  The intent is to identify sets of snomed concepts that satisfy 
the constraint criteria. These sets could be subsequently used to join 
against/filter records in an EHR/EMR.


Work is ongoing for a full featured query language to address this 
larger problem, but the expression constraint language can be used to 
great effect when combined with SQL or other database tech to query 
health records.




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

SNOMED CT constraint syntax - for querying instances or terminology?

[Thomas Beale]

The latest version of the SNOMED CT constraint language 
proposes expressions like the 
following:


Section 6.3

To find those capsules  that have a strength between 500 and 800 mg 
(inclusive), the following expression  constraint  may be used:


<  27658006 |amoxicillin| :
46001 |has  dose form| = <<  385049006 | capsule|,
{ 15 |has basis of strength| =  ( 15 |amoxicillin only| :
15 |strength magnitude| >=  #500, 15 |strength 
magnitude| <= #800,

15 |strength unit| =  258684004 |mg|)}

The purpose of this is apparently as a query to find instances of 
Amoxycillin recorded somewhere - presumably in EHRs, or some kind of 
prescriptions database? However, the document talks of executing queries 
over a 'Substrate', defined as 'The SNOMED CT content over which an 
expression constraint is evaluated or a query is executed.'.


Elsewhere (p12) it says:

Please  note  that  the  substrate  over which  the  expression  
constraint  is evaluated is  not explicitly defined within the 
expression constraint, and must therefore be established by some other 
means. By  default,  the assumed  substrate  is the  set of  active  
components  from  the snapshot release  (in distribution normal form) of 
the SNOMED CT versioned edition currently loaded into the given tool.


It is also not clear what the query really means - is it a query for 
Amoxycillin that has been prescribed for a specific patient? For any 
patient in some cohort? Or for a medication order that has been 
suspended, postponed, or completed?


More generally, I am not clear how the one language is intended to be 
used across SNOMED CT itself (e.g. to generate intentional ref sets) and 
also across instance data. If it's the former, it can only be 
concept-based; if the latter, the query won't correspond to whatever 
information model is in use for the data.


How would it be used with data based on (for example) the openEHR 
medication item archetype in the UK clinical models CKM 
, shown below?





The recommendations in section 7.5 for executing the queries seem to 
imply that they are for evaluation against SNOMED CT.


There are various other oddities, but I'll leave them for later.

if anyone who is working with this can clarify, it would be most 
appreciated.


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

Re: openEHR and IHTSDO (SNOMED CT)

[Thomas Beale]

A number of approaches have been made in the recent past by openEHR and 
CIMI, led by Dr stan Huff. The outcome is that IHTSDO do not appear to 
be currently interested in a formal working relationship with the 
content modelling communities (openEHR, Intermountain Healthcare, CIMI, 
ISO 13606, ...).


I personally don't understand why, but this is the line they are taking. 
I'm not aware of any new plans.


None of this precludes openEHR actively using IHTSDO-issued standards 
and specifications, which we do. ADL / AOM 2 and tooling has now been 
converted to using IHTSDO concept referencing URIs for example.


- thomas

On 25/09/2015 18:26, Mikael Nyström wrote:

Hi,

I wonder if there are any current collaborations or collaboration plans between 
openEHR Foundation and IHTSDO (which is the organisation that owns and 
maintains SNOMED CT.)

Regards
Mikael

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




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

Re: Advantage of ISO

[Thomas Beale]

Bert,

I fail to see the origin of any ambiguity from within openEHR. The 
specifications have been free and open for 15 years, since 2000 (or soon 
thereafter, since some were issued around 2002/2003 for the first time, 
and some later). This has always been clearly stated even in the old 
copyright notice, as well as in the current CC licence.


All of this is verifiable simply by going to the website and viewing the 
specifications, and that has always been the case, again, since the 
beginning.


Therefore, any 'ambiguity' on this subject has been manufactured from 
(very great) ignorance or else malice, for the agendas of other parties. 
There's probably not much we can do about this other than rely on the 
intelligence of potential user organisations to ignore nonsense when it 
surfaces, and get on with doing real work. If they can't even be 
bothered to inspect the website and primary materials, they probably are 
not serious about e-health.


Secondly, Ocean Informatics has nothing specific to do with any of this. 
It does not have any IP that is special in any way. There are a number 
of vendor companies that have become Industry Partners, as can be seen 
on the openEHR.org home page. Most of these companies have contributed 
some IP, which can be seen either at openEHR@Github 
<https://github.com/openEHR>or else in other locations that are 
generally well-signed from the website.


It is not up to Ocean to determine anything to do with openEHR software 
or other IP status - that is done by the openEHR Management board 
<http://www.openehr.org/about/management_board>, and/or Board of 
Governors <http://www.openehr.org/about/board_of_governors>, in cases 
where legal advice may be required.


I hope this is clearer.

- thomas

On 09/09/2015 18:09, Bert Verhees wrote:

On 09-09-15 09:55, Thomas Beale wrote:


Bert,

my comments relate to software only, contributed by companies and 
other organisations at their own development expense.


It has nothing to do with specifications, nor specification-related 
computational artefacts (grammars, XSDs, and the like). These are all 
issued by the foundation, copyrighted to the foundation and will 
always be free to use under all circumstances, as has always been the 
case for 15 years. This will never change.


Good to be crystal clear about this, with all the FUDders waiting for 
their chances.
Remember, they talk with not so well informed people (govt. 
bureaucrats, for example) regarding licensing issues.



;-)


There are three kind of deliverables coming from OpenEHR (and Ocean)
1) The specs  (NOT DERIVABLE)
2) The CKM archetypes (archetypes can be seen as software, (say some)) 
(SHARE ALIKE)

3) What anyone recognizes as software (For Ocean to decide)


For me only the first part is important, but others find part 2 and/or 
3 also very important, for good reasons.



What Ocean does should IMHO be anyway outside the scope of this 
discussion.


I hope they are going to charge lots of money for their software, the 
more the better.


Others are happy to fill the market-gap.



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

Re: Advantage of ISO

[Thomas Beale]

Bert,

my comments relate to software only, contributed by companies and other 
organisations at their own development expense.


It has nothing to do with specifications, nor specification-related 
computational artefacts (grammars, XSDs, and the like). These are all 
issued by the foundation, copyrighted to the foundation and will always 
be free to use under all circumstances, as has always been the case for 
15 years. This will never change.


- thomas

On 09/09/2015 17:24, Bert Verhees wrote:

On 09-09-15 04:20, Thomas Beale wrote:

On 08/09/2015 21:55, Erik Sundvall wrote:

Hi!

ND on the specification documents is not a big or urgent problem if 
there are Apace 2 licenced computable artifacts 
like UML-files/descriptions of all classes, ADL/AQL grammars, 
openEHR term lists/vocabularies and other things needed for building 
actual systems. I believe that is already the case (or at least the 
intention).




we probably need to perform an audit on all of these artefacts to 
check the licences. One thing we need to change is to allow more 
types of software licence, e.g. AGPL. Large companies and huge health 
institutions like the NHS simply cannot expect to be able to use 
everything for free when it costs quite serious investment on the 
part of typically small companies or research groups in academic 
settings. They need to consider contributing resources. Viral 
licences need to be allowed to enable conditional use; if funding is 
made available, such licences can be converted to other types of licence.


We must not forget, this discussion (the ND-part) is in the context of 
the specifications, and specifications is NOT software.
If you are going to ask money for the specifications, or 
membership-construction, OpenEHR is not anymore open.


And most important, you cannot close down this version the OpenEHR 
specs, because you have given it to the world with the right to share it.
It will always compete with your paid version on the market. So the 
AOM-part and other more technical parts will be stable and for free 
for coming decade.


The Reference Model can change version and in a new version close down 
the free distribution, but many can write a Reference Model.

I, personally, consider the Reference Model as least innovative.
We have so many Reference Models, Tim Cook created one, Grahame Grieve 
created one, the guys from 13606 created one.

And don't forget the current version of the Reference Model.
Even in the Netherlands there are a few as datamodel which can easily 
be converted to a two level Reference Model.


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

Re: Advantage of ISO

[Thomas Beale]

On 08/09/2015 21:55, Erik Sundvall wrote:

Hi!

ND on the specification documents is not a big or urgent problem if 
there are Apace 2 licenced computable artifacts 
like UML-files/descriptions of all classes, ADL/AQL grammars, openEHR 
term lists/vocabularies and other things needed for building actual 
systems. I believe that is already the case (or at least the intention).




we probably need to perform an audit on all of these artefacts to check 
the licences. One thing we need to change is to allow more types of 
software licence, e.g. AGPL. Large companies and huge health 
institutions like the NHS simply cannot expect to be able to use 
everything for free when it costs quite serious investment on the part 
of typically small companies or research groups in academic settings. 
They need to consider contributing resources. Viral licences need to be 
allowed to enable conditional use; if funding is made available, such 
licences can be converted to other types of licence.


- thomas

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

Re: Advantage of ISO

[Thomas Beale]

ND = No Derivatives and is the Creative Commons equivalent of what W3C 
has in their licence 
. It's just 
designed to prevent anyone republishing altered versions of the 
specifications /as the original specifications /- in other words forked 
publishing, which would create real problems for obvious reasons.


Probably we do want to allow the forking of the specifications into some 
new specifications, i.e. with new names and identifiers, that clearly 
cannot confused with the originals, and the ND provision 
I believe would prevent 
this.


I am not sure what the best replacement is though - it's quite important 
that a specification with the title 'openEHR EHR Information Model' and 
version xyz really is only one document, and that no modified versions 
of that can masquerade as that thing.


W3C achieve this with a custom copyright notice (see above). We probably 
want a different approach. I don't personally have time to research this 
but ideally we want a licence that does the following for the 
specifications:


 * requires attribution with all replublishing, sharing
 * prevents republishing in altered form with same document title, id,
   and also publisher i.e. 'openEHR'
 * but allows normal forking into artefacts that are clearly different

- thomas


On 07/09/2015 06:48, Bert Verhees wrote:
The ND on the specs, there must be a kind of protection. Brand 
protection could work, but must be registered in all countries of the 
world.


You see the same problem at RFC's, they solved it like this, you 
cannot change them and publish them under the same name.

In the case of RFC a changed version gets a new number.

I don't know what it takes to make an RFC of something and if it would 
be appropriate for OpenEHR.


http://www.rfc-editor.org/


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

Re: Advantage of ISO

[Thomas Beale]

ND = No Derivatives ad is the Creative Commons of what W3C has in their 
licence . It's just 
designed to prevent anyone republishing altered versions of the 
specifications /as the original specifications /- in other words forked 
publishing, which would create real problems for obvious reasons.


Probably we do want to allow the forking of the specifications into some 
new specifications, i.e. with new names and identifiers, that clearly 
cannot confused with the originals, and the ND provision 
I believe would prevent 
this.


I am not sure what the best replacement is though - it's quite important 
that a specification with the title 'openEHR EHR Information Model' and 
version xyz really is only one document, and that no modified versions 
of that can masquerade as that thing.


W3C achieve this with a custom copyright notice (see above). We probably 
want a different approach. I don't personally have time to research this 
but ideally we want a licence that does the following for the 
specifications:


 * requires attribution with all replublishing, sharing
 * prevents republishing in altered form with same document title, id,
   and also publisher i.e. 'openEHR'
 * but allows normal forking into artefacts that are clearly different

- thomas


On 07/09/2015 06:48, Bert Verhees wrote:
The ND on the specs, there must be a kind of protection. Brand 
protection could work, but must be registered in all countries of the 
world.


You see the same problem at RFC's, they solved it like this, you 
cannot change them and publish them under the same name.

In the case of RFC a changed version gets a new number.

I don't know what it takes to make an RFC of something and if it would 
be appropriate for OpenEHR.


http://www.rfc-editor.org/


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

book recommendation - basic formal ontology (BFO) for biomedicine

[Thomas Beale]

A new book, *Building Ontologies with Basic Formal Ontology *(BFO2) has 
been published by Robert Arp, Barry Smith and Andrew Spear.


Amazon.com 

Amazon.co.uk 



I've read a pre-print, and this is an excellent book. Many of us here 
have studied or used some of the key upper level ontologies (BFO, 
BioTopLite etc), and I think BFO2 will probably end up being the one of 
choice for general biomedicine. It contains all the concepts from Barry 
Smith's earlier work (SNAP and SPAN - spatial and temporal regions, 
partonomy concepts etc) and will ultimately (I have been told) 
contain/be merged with a new version of the Information Artefact 
Ontology (IAO) which will probably become the upper level ontology for 
describing types of information that stand in the IS-ABOUT and similar 
relationships with real world referents - in other words, EHR 
information items.


My personal feeling is that in the next 2-5 years, we will finally see 
the joining up of these key ontologies with information models and 
archetypes in the clinical information space. It will be up to us in the 
openEHR community and other related communities (13606, CIMI, HL7 etc) 
to engage with this material and consider how this integration will be 
achieved. A few very early ideas are mentioned in the Archetype 
Technology Overview 
document, 
but of course this is just one narrow area of application.


We need to all get on the same page in terms of understanding and 
conceptual nomenclature in this space, and BFO2 I believe is an 
excellent foundation for that. We will be using it increasingly in the 
openEHR specification space, and I think others will find it useful as well.


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

Re: Advantage of ISO

[Thomas Beale]

Gerard,

the 'IP rights' are defined by the licences. You can read them here 
. The rights to use, 
copy and adapt are clearly defined, and include no curbs on freedom, and 
no requirement for payment. The only real requirement is that 
attribution of the original author(s) remains visible.


This is how all open source IP works. This is why it is called 'open'. 
You will find for example that the Linux kernel is 'owned' by Linus 
Torvalds. But the ownership is irrelevant because of the licence under 
which it is available.


There is no dependency of openEHR IP on proprietary specifications of 
any kind - that is objectively demonstrable. The only reason I can 
imagine that openEHR's open licenced IP could have encountered problems 
in any European country is due to the presence of bureaucrats with an 
understanding of open source / commons licencing as obtuse as your own. 
Or perhaps they were coached?


- thomas

On 04/09/2015 05:46, "Gerard Freriks (privé)" wrote:

Again.

Answer the question ‘Who owns the specifications of openEHR, looking 
at the quotes I provided?

The answer is:
UCL owns the IP rights and licensing conditions.
Members of, participants in, openEHR gremia, do not.

And that is why I call openEHR specifications proprietary.

According to the definition of ‘open standard’, openEHR is an open 
Standard

but owned by as single company.

I know for certain that this fact prohibited serious business in some 
European countries, some years ago.
Because of the licensing and dependency on proprietary specifications, 
the artifacts produced were not controllable by the user/customer.
This was their reason, after legal consultation, not to use software 
based on openEHR specifications.




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

Re: Advantage of ISO

[Thomas Beale]

Gerard,

I am not sure why you are pursuing this line of argument. The only 
interesting question here is not about any 'owner', but about the 
'credible maintainer'. For openly and freely licenced IP, this is all 
that practically matters - the capabilities and behaviours of the 
maintainer with respect to the IP. Do they provide issue reporting? Are 
they responsive? Do they have transparent governance? Do they issue new 
releases? Do they provide channels of communication to the community? 
And so on.


- thomas

On 03/09/2015 21:00, "Gerard Freriks (privé)" wrote:
In this particular case IP is held on specifications archetypes are 
making use of.

It is about ownership of IP of BOTH the Reference Model and the AOM

Gerard


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

Re: ACTION performer?

[Thomas Beale]

Can I suggest that a PR is raised for this 
?


- thomas

On 27/08/2015 21:40, Ian McNicoll wrote:

Hi Silje,

I agree that ACTION.performer would be a useful addition (optional) to 
the RM. For now, I model performer as a participation. 
ACTION.other_participations inherits ENTRY.other_participations


http://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1433173757197_893618_10673

The basic structure of participation is

performer: PARTY_PROXY
function : e.g "Perfomer" (text)
mode:  "face-to-face communication" (a fixed internal oepnEHR code)

A snippet of openEHR JSON (this applies the participation at 
composition level but the internal structure of participation is the same

"ctx/participation_name:0": "Dr. Marcus Johnson",
 "ctx/participation_function:0": "Performer",
 "ctx/participation_mode:0": "face-to-face communication",
 "ctx/participation_id:0": "1345678",

"ctx/participation_name:0": "Dr. Marcus Johnson",
 "ctx/participation_function:0": "Performer",
 "ctx/participation_mode:0": "face-to-face communication",
 "ctx/participation_id:0": "1345678",

   "otherParticipations": [
{
"function": {
"value": "Oncologist"
},
"mode": {
"definingCode": {
"codeString": "216",
"terminologyId": {
"value": "openehr"
}
},
"value": "face-to-face 
communication"

},
"performer": {
"externalRef": {
"id": {
"scheme": 
"2.16.840.1.113883.2.1.4.3",

"value": "1345678"
},
"namespace": "NHS-UK",
"type": "ANY"
},
"identifiers": [],
"name": "Dr. Marcus Johnson"
},
"time": null
},

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com 
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 


Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 27 August 2015 at 10:00, Bakke, Silje Ljosland 
> wrote:


Hi all,

According to Norwegian law, the performer or main performer of a
procedure has to be explicitly recorded. The main performer is not
necessarily the same person who records the action, so the
COMPOSITION.composer RM object may not be used for this. We can’t
seem to find any complete description of the ACTION.participations
RM object, but if it’s possible to specify the role of the
participant there, this may possibly be used. Or will we have to
explicitly model this in the ACTION.procedure archetype?

Any thoughts?

Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
National ICT Norway

Tel. +47 40203298 

Web: http://arketyper.no / Twitter:
@arketyper_no 


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




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



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

Re: difference and relationship between openEHR and EN13606

[Thomas Beale]

Hi Bert,

On 28/08/2015 16:32, Bert Verhees wrote:

On 27-08-15 19:54, Thomas Beale wrote:
I would suggest that CIMI has been simiplified to the point of not 
being directly usable as an RM by openEHR or 13606 - most of the 
needed context information is gone in CIMI, and it doesn't 
distinguish any kind of 'Entry' or clinical statement.


Are you saying, that the context information from the reference model 
is not used?


the CIMI RM 
<https://github.com/opencimi/rm/blob/master/model/Release-3.0.4/BMM/CIMI-RM-3.0.4-generated-from-UML.bmm#>has 
no context information in it.






This was a conscious choice in the CIMI community, designed to get 
buy-in from a much wider range of stakeholders than openEHR or 13606 
deals with. Technically, the CIMI approach is to soft-model nearly 
everything in 'reference archetypes'.


and the archetypes fill in the missing reference model context parts?


that's the idea.



If so, then this makes the two level modeling approach, of course, 
much more flexible, a kind of new database approach/technique, usable 
for virtual anything.


it makes it more flexible in one sense, but also harder for implementers 
- now they cannot know where even basic context like subject, times, 
locations etc are - all that has to be obtained from archetypes. The 
'flexibility' comes with a price...


What goes in any particular RM for some particular domain or industry 
needs to be the result of careful analysis of


 * the need for being able to build reliable software components that
   can assume some things
 * the need for a base model with enough useful primitives that it
   doesn't force endless repeated modelling of the same basic concepts
   in archetypes
 * but sufficient flexibility so that all the variability of the
   domain, and also localization can be accommodated.

It's a balancing act.

So far in openEHR, the context and most other structures etc have proven 
to be good. We'll probably get rid of / simplify the ITEM_TREE stuff in 
Release 1.1, but I can't imagine getting rid of most of the other semantics.


- thomas

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

Re: Archetype versioning: Skipping v1 and going straight to v2?

[Thomas Beale]

Hi Silje,

I would not expect any problems.

- thomas

On 28/08/2015 23:05, Bakke, Silje Ljosland wrote:


Hi everyone,

We’ve bumped into an issue related to versioning of archetypes and 
implementing non-published versions:


Several implementation projects are using archetypes from the 
http://arketyper.no CKM, many of which are still drafts or under 
review since the CKM switch to v0 for unpublished archetypes was done 
only recently, and the publicly available tools all use v1 by default, 
lots of functionality has already been made using unpublished v1 
versions of archetypes, and will be deployed this autumn. Of course, 
when reviewed, these archetypes may go through drastic changes, and 
this will be a problem once other projects at a later time try to use 
archetypes which by then may have been published as v1.


One of our proposed solutions is to skip v1 for these archetypes and 
go straight to v2 when publishing them. Is this practically possible, 
and will it have any adverse consequences?


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
National ICT Norway



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

Re: difference and relationship between openEHR and EN13606

[Thomas Beale]

On 28/08/2015 10:03, 王海生 wrote:

could we just add  a page on openEHR website to illustrate these points
thx


if you search on the wiki 
, 
with either '13606' or 'CIMI' you will find a lot of material.


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

Re: difference and relationship between openEHR and EN13606

[Thomas Beale]

openEHR has an EHR Extract specification 
as well, 
which is more flexible than the 13606 one e.g. it can include 
information from more than one patient, and accommodates both openEHR 
and non-openEHR content.


- thomas

On 26/08/2015 12:50, pazospa...@hotmail.com wrote:


Hi,


I would say that the main difference is that 13606 is for data 
communication and openEHR is for EHR architecture, both based on 
archerypes.





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

Re: difference and relationship between openEHR and EN13606

[Thomas Beale]

On 26/08/2015 16:46, Erik Sundvall wrote:

Hi!

Where can one find proposals/diagrams describing the refreshed RM 
(reference model) in the new 13606 revision? Will 13606 keep using the 
old data types or harmonize more with CIMI or OpenEHR?


Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? 
If so, great!


When it comes to "simplifying" the RM (or perhaps moving complexity to 
another meta/design-pattern layer) I think CIMI has gone further than 
13606. Are there any plans of aligning 13606 with CIMI?




I would suggest that CIMI has been simiplified to the point of not being 
directly usable as an RM by openEHR or 13606 - most of the needed 
context information is gone in CIMI, and it doesn't distinguish any kind 
of 'Entry' or clinical statement.


This was a conscious choice in the CIMI community, designed to get 
buy-in from a much wider range of stakeholders than openEHR or 13606 
deals with. Technically, the CIMI approach is to soft-model nearly 
everything in 'reference archetypes'.


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

Re: difference and relationship between openEHR and EN13606

[Thomas Beale]

On 26/08/2015 13:08, Bert Verhees wrote:

On 26-08-15 14:03, Diego Boscá wrote:

I agree with most of the points, but I'm curious why you say that 13606
does not support AQL (and in any case wouldn't be "AQL does not support
13606"?)
Yes, that is a good question, I did not know that AQL was considered 
to be OpenEHR specific.
In my opinion it was a bound to the archetype model, not to the 
reference model.


It's not. It's exactly the same no matter what the reference model. Of 
course, to properly check AQL queries and execute them in a specific 
environment, access to a representation of the RM being used will be needed.


- thomas

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

Re: ACTION performer?

[Thomas Beale]

On 27/08/2015 10:18, Bakke, Silje Ljosland wrote:


So it’s possible to specify the role of each participant?



yep - the PARTICIPATION type has 'function' i.e.  'role' (this name was 
adopted from 13606 a long time ago - probably too late to change).


- thomas


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

Re: ACTION performer?

[thomas . beale]

Normally you would use participations. 

Sent from my HTC

- Reply message -
From: "Bakke, Silje Ljosland" 
To: "openehr-technical@lists.openehr.org" 
Subject: ACTION performer?
Date: Thu, Aug 27, 2015 10:00

Hi all,

According to Norwegian law, the performer or main performer of a procedure has 
to be explicitly recorded. The main performer is not necessarily the same 
person who records the action, so the COMPOSITION.composer RM object may not be 
used for this. We can't seem to find any complete description of the 
ACTION.participations RM object, but if it's possible to specify the role of 
the participant there, this may possibly be used. Or will we have to explicitly 
model this in the ACTION.procedure archetype?

Any thoughts?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL ANTLR4-grammar

[Thomas Beale]

On 24/08/2015 11:38, Bert Verhees wrote:

On 24-08-15 15:36, Thomas Beale wrote:
Antlr4 rule capabilities and particularly pattern matching is weaker 
than yacc/lex (in some cases quite a lot weaker),
Of course, Yacc/lex can only be used to generate C-code. It's 
functionality in pattern matching is limited to this.


nope - it can be used to generate anything (I use it to generate Eiffel 
code). The point is it can only generate 1 language.




To do whatever you need to do, writing a compiler, translating 
programming languages into another (transpiler), translating a query 
language into another, processing data, JSON,. XML, CSV, to many 
custom made targets, generated code accessible to choose for a 
listener/visitor or tree pattern, and having scoped symbol tables, 
that  is where Antlr comes in.


actually - these are all output stages, and they are perfectly doable 
with any yacc/lex compiler serialiser - which is what the ADL workbench 
is, and what it does. Antlr des make a lot of this easier however.




Maybe the weakness is C-related? It is what one expects because the 
nature of Yacc/lex.


yacc/lex grammars have nothing to do with C - they work the same way 
with any language.


The weaknesses are mainly in the regex matching for string patterns - 
Antlr doesn't do anything like full regex. Its stateful sub-grammar 
handling needs a bit of work as well.


But I agree, it's probably the future, at least for a while.

- thomas


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

Re: AQL ANTLR4-grammar

[Thomas Beale]

quick answer for now - there are base patterns that should be used 
across other projects like AQL


 * here in the specifictions-BASE repository
   <https://github.com/openEHR/specifications-BASE/tree/master/docs/odin>
 * here in the specifications-AM repository
   <https://github.com/openEHR/specifications-AM/tree/master/docs/ADL2>

look for the .g4 files. See particularly the 'base_patterns' one.

These files are currenty mixed in with the specs. I'll move them to a 
more obvious place (so they stand alone, but also enable spec publishing).


If you just want to look at these grammars, go to the ADL2 and ODIN 
specs (home page -> Specifications button ->...)


They are still being worked on, so don't trust them yet.

But do note that most terminal types in ADL apply to AQL, so we should 
aim for a base_patterns and also odin_values grammars across openEHR.


- thomas


<https://github.com/openEHR/specifications-BASE/tree/master/docs/odin>On 
24/08/2015 05:32, ANASTASIOU A. wrote:

Hello everyone

Please see further below regarding a few first steps towards "converting" 
Chunlan's .g files in combination with Eiffel's lexer files to ANTLR's syntax. My main 
motivation for doing this was to produce syntax diagrams for ADL and AQL but very early 
on I realized that there was no point writing just the EBNF because I could be deriving 
the ANTLR representation of the grammar and from that be able to produce a parser as well.

This was going well, until I realised that:

1) Certain definitions could be defined once and re-used in multiple places
2) Some definitions looked almost exactly the same but had different names 
depending where they were applied
3) Some definitions would become obsolete / would not be able to co-exist 
because of the way ANTLR expresses a grammar
4) Some definitions included conditional parsing with states and they were 
becoming a bit indecipherable for me
5) Meantime, ADL 2.0 came along

I have specific examples for the above in a document were I kept notes as I was 
going on which I intend to share. Part of it was also put at an earlier email 
to Thomas...but this was long time ago by now.

The problem is that right now I am "on the road" (and have been for a few weeks 
now), writing this just before I go into class at St. Andrews and cannot talk about this 
to the level of detail I would love to :D

However, the key messages emerging from my experience are these:

A) I would appreciate help from people who wrote the .g and Eiffel YACC files 
because these are not exactly documented. We need to know how some definitions 
came to existence and more importantly, if we have two definitions that are 
almost identical, which one do we keep?

B) !!!We need testing cases!!! for each definition. This became essential as I 
was going on and had to jump back and forth changing definitions. Of course, 
when you do that, it has an impact on every definition uses the modified part. 
My tool of preference was Python. The Python ANTLR target code generation was 
recently reworked and it works almost exactly as its JAVA counterpart. It could 
be used to create quick test code through a makefile or something.

C) I found it easier to work bottom-up. So, if we were to quickly get 
elementary data types / definitions out of the way relatively quickly then the 
real work can start on parts of the grammar that are not exactly 
straightforward :)


Repositories at:
A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax

Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf
  


I hope this helps, had a quick look at the MedInfo stuff and it looks really 
exciting!

All the best
Athanasios Anastasiou





From: openEHR-technical [openehr-technical-boun...@lists.openehr.org] on behalf 
of Thomas Beale [thomas.be...@oceaninformatics.com]
Sent: 03 July 2015 11:10
To: For openEHR technical discussions; For openEHR clinical discussions
Subject: Re: openEHR specifications - the future is Asciidoctor + MagicDraw?

Athanasios,

excellent suggestion. I haven't even looked at building in syntax diagrams right now, 
but your timing is perfect - I was contemplating how to put the ADL grammar into the 
new style spec in a nice way. Currently grammar is generated as an HTML page (as per 
links on this wiki 
page<https://openehr.atlassian.net/wiki/display/ADL/ADL+2+parser+resources>) 
which is ok, but the source file is not in a re-usable form (it's a .y file 
containing Eiffel code - but it would be the same problem with any language like Java 
or C etc) and the lexer files are also not re-usable or easily publishable.

So we need to solve this in a way that makes the lexer and parser grammar files 
primary, and then all other files based on them. All of this goes for AQL as 
well.

Both ADL and AQL g

Re: AQL ANTLR4-grammar

[Thomas Beale]

Antlr4 rule capabilities and particularly pattern matcing is weaker than 
yacc/lex (in some cases quite a lot weaker), but it's more concise for 
the production rules, and as you say, it works for any output side. So 
that's a big win. Over time, I expect we'll cnvert everything to Antlr4.


On 24/08/2015 02:53, Bert Verhees wrote:
I wrote this a bit confusing, too late at night and on my mobile 
(small screen).


The idea I wanted to write is that with Antlr4, you can write a 
grammar, without knowing the purpose of the grammar. If it is used to 
write a query engine, or if it is used to write a translator from AQL 
to XQuery or even SQL. It makes no difference for the grammar. This is 
the first grammar tool ever, which has this feature. All other 
grammar-tools, also the previous versions of Antlr, and JJ (used for 
ADL before) needed code-fragments in the grammar and were, in this 
way, bound to the target purpose.


So because a grammar can serve anyone, because the grammar is purpose 
independent, we can all benefit from this idea from Erik.


That was what I wanted to write yesterday.

Excuse me for any confusing.

Bert

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






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

latest updates to AD2 / AOM2 specifications

[Thomas Beale]

I am finalising the ADL/AOM2 specifications, mainly updating text, and 
incorporating content from older separate documents. It's not finished 
yet, but sections that may interest some people:


 * templates and template overlays
   
 * efficient serialisation formats
   

   for archetypes (JSON, XML, ODIN, YAML)
 * Antlr4 grammar for ADL 2
   


The Antr4 grammar is not normative yet (so don't trust it yet) - we are 
still working with the devs at Marand on converging the multiple 
existing grammars to one thing.


Another document at a much higher level is now online, that answers the 
questions 'what are archetypes?' and 'what are they for?' is here:


 * Archetypes Technology Overview
   

When these documents are finalised (next few weeks), they will enter the 
normal openEHR process for review 
. If you 
want to make comments now, please feel free to comment in one of the 
following ways:


 * on this list, for more informal comments
 * errors and omissions - please report on the openEHR SPECPR Jira
   project
   
.

- thomas

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

Re: ADL versions 1.4, 1.5 and 2.0

[Thomas Beale]

Dave,

I'll try to answer a few.

Firstly, please treat the active specifications as what you find by 
going to the home page 'Specifications' button (top left), i.e. the HTML 
specs here 
<http://www.openehr.org/programs/specification/releases/currentbaseline#ADL2>.


Second point, 'ADL 1.5' was what we used for a long time as the moniker 
for 'next generation ADL', until we realised that we introduced breaking 
changes due to CIMI, OMG/AML and openEHR development work. So 'ADL / AOM 
2' is the 'modern' archetype formalism.


We never released any interim version, although some people think we 
should, as per this page 
<https://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Migration+Roadmap>.


The ADL / AOM 2 specs referred to above are not yet quite complete - 
there are a few more additions to the documents, and 2 very minor 
potential semantic changes - semantic slots and smarter annotations. I 
would expect these specs to be ready for release formal TRIAL in the 
next 4 weeks.


Why does ADL2/AOM2 exist? It addresses various limitations in ADL1.4, 
including lack of proper modelling for specialisation, templating, 
proper versioning and id rules, and proper value sets. A full list is 
here 
<https://openehr.atlassian.net/wiki/display/ADL/Evolution+from+ADL+1.4>.


The ADL Workbench 
<http://www.openehr.org/downloads/ADLworkbench/home>will reliably (in 
most cases) convert ADL 1.4 archetypes to ADL 2 form. This transform is 
not trivial, so anyone who wants to do this conversion should use this 
tool, or the command line version.


CIMI is using only ADL/AOM 2, and CIMI will become a working group of 
some kind in HL7 (agreed but not finalised yet), so HL7 will potentially 
use ADL 2 at some point (but I assume jut the CIMI workgroup for some 
time).


ADL/AOM2 is the basis for the OMG Archetype Modelling Language (AML) 
specification, which has entered the standards track a few months ago.


On the ground in openEHR implementation space, ADL 1.4 is being used. 
New tools that are internally ADL 2 will / do generate ADL 1.4 OPTs to 
enable these systems to keep running. The ADL Workbench doesn't yet do 
this but will.


There is an XML Schema for ADL / AOM 2 here 
<https://github.com/openEHR/specifications/tree/master/ITS/AOM2/XML-schema>, 
also reachable from the current specifications page 
<http://www.openehr.org/programs/specification/releases/currentbaseline>.


The tougher question to answer is when systems will move to ADL 2. THere 
are two questions: EHR systems, and tools. Tools can move faster, and 
are already being changed. CKM also incorporates some ADL 2 features 
already. EHR systems will move more slowly and carefully for obvious 
reasons, which is why we need ADL 1.4 OPT support in next gen tools. I 
would expect some vendors to eventually support ADL 1.4 and ADL2, and 
existing ADL 1.4 based deployments may stay on ADL 1.4.


- thomas

On 12/08/2015 04:32, Barnet David (HEALTH AND SOCIAL CARE INFORMATION 
CENTRE) wrote:


All

Hope everyone is well.

I have a few questions on ADL versions

Is there a general view as to when archetypes will be created in an 
ADL version other than version 1.4?


I’ve sampled CKMs from various countries & found all archetypes (that 
I sampled) were in the ADL 1.4 format.


Some questions:

Is anyone planning to use anything other than ADL 1.4 in the near future?

How will CKMs cope with multiple ADL versions in a single CKM?

When will tools be available to create archetypes in 1.5 and 2.0?

How will the export format change from ADL 1.4 to 1.5 and 2.0?

Will I be able to import an archetype in 1.5 or 2.0 into my CKM?

Is there an XML schema available for 1.5 and 2.0?

When do we expect archetypes in 1.5 & 2.0 to be the norm?

What’s the driver to move to archetypes created to DL version 1.5 or 2.0?

Are all the answers in the published document 
http://www.openehr.org/releases/trunk/architecture/am/adl2.pdf ?


Regards

Dave Barnet
Health and Social Care Information Centre

NHS England, UK




--
Ocean Informatics <http://www.oceaninformatics.com>   *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 	Specification Program, /open/EHR 
<http://www.openehr.org/>

Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/>
Health IT blog <http://wolandscat.net/category/health-informatics/> 
View Thomas Beale's profile on LinkedIn 
<https://uk.linkedin.com/pub/thomas-beale/0/217/68a>


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

Re: Term set for DV_PARSABLE.formalism

[Thomas Beale]

Hi Pablo,

in openEHR, a terminology id of 'local' normally refers to terms inside 
an archetype; each archetype is its own terminology. This makes sense 
for clinical terms in an archetype, but not, I don't think, for terms to 
do with data formats. We can easily add these to the openEHR vocabulary, 
then that provides a reliable single source of such terms, and doesn't 
require archetype authors to re-invent (different) terms for the same 
thing repeatedly.


- thomas

On 29/07/2015 01:04, pablo pazos wrote:
I think we can put the formalisms we know in the terminology, but 
being flexible to allow local formalisms, like using "local" for the 
terminology_id. If we don't do that, we'll need to maintain the 
terminology for every new formalism.


Not sure about having two fields, it seems the role of both is the 
same. We can do that with parameters or suffixes on MIME types (the 
structure allows that): https://en.wikipedia.org/wiki/Internet_media_type


With CODE_PHRASE we can cover both cases, defined and non-defined MIME 
types.


If the MIME type is String, we lose control over the values, I'm 
considering trying to process something I receive and not 
"understanding" that String. With terminology = local, I know that I 
may not have the code (if "local" is another system), but for a MIME 
type from IANA I will have it. Also this allow us to define our own 
openEHR types without the need of registering those at IANA, like ADL 
or OPT (e.g. text/opt+xml).


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

Re: Term set for DV_PARSABLE.formalism

[Thomas Beale]

On 28/07/2015 18:49, pablo pazos wrote:
If that's the case, we lose the coding system / terminology of the 
mime types that are defined.


It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE 
instead of String and use "local" for the terminology_id of those 
formalisms that doesn't have a mime type.




well actually we could do that and put all those other formalisms into 
the openEHR terminology.


The original idea was to allow (encourage) MIME types as strings, and 
then outside of MIME, any other formats just as their own short string, 
e.g. 'mp5' (imagine it exists), or 'adl'.


There are a lot of formats that are essentially text/plain, but the 
format is actually parseable, e.g. glif3, most programming languages and 
so on. So 'text/plain' isn't that useful a thing to know.


I wonder if we have to give in and have two fields, one that is a MIME 
type field (the current one) and a second field that has a term defining 
the semantic format, mostly applicable when the MIME type field is 
text/plain, text/xml and other text types.


- thomas

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

Re: Archetype editor, CKM and v0 & v1

[Thomas Beale]

good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything 
else, it must start with a dot. Somewhat safer perhaps.


- thomas

On 22/07/2015 23:34, Peter Gummer wrote:

Hi Ian,

The + is redundant here, since it’s just saying that there has to be 
one or more digits after the ‘v’. But the next thing that it says is 
that you can have anything at all after those digits.


So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by 
anything at all. This amounts to the same, since any extra digits 
qualify as “anything at all”.


Peter


On 23 Jul 2015, at 01:55, Ian McNicoll <mailto:i...@freshehr.com>> wrote:


Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I 
think!).


unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com <mailto:i...@freshehr.com>
twitter: @ianmcnicoll




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



--
Ocean Informatics <http://www.oceaninformatics.com/>  *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 	Specification Program, /open/EHR 
<http://www.openehr.org/>

Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/>
Health IT blog <http://wolandscat.net/category/health-informatics/> 
View Thomas Beale's profile on LinkedIn 
<http://uk.linkedin.com/in/thomasbeale>



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

Re: Archetype editor, CKM and v0 & v1

[Thomas Beale]

Technically speaking, if we want to properly match any archetype in a 
slot, we need a regex that will match any level of versioning id. Since 
matched archetypes will eventually all have 3-part versions (but today 
might have only 1-part versions), we need to match thngs like


.v0
.v1
.v0.0.1
.v3.0.2

and so on. So Diego's expression will do that. But Sebastian is correct 
- some of the matched archetypes could be test or research archetypes. 
So you need the remaining bit as well. You could in theory use:


v[0-9]+(\.[0-9]+(\.[0-9]+((-rc|-alpha)(\.[0-9]+)?)?)?)?
but I would say it is overkill (you only use regexes like that when you 
think there could be garbage version ids and you want to catch them and 
reject them). A reasonable balance is probably something like


\.v[0-9]+.*

which forces at least one digit of major version, and allows anything at 
all to come after, which is reasonable if we assume that no tools will 
create completely invalid version ids.


For reference, there are some useful regexes here 
.


- thomas

On 22/07/2015 15:26, Sebastian Garde wrote:
My understanding was that minor version and patch version would not be 
part of the normal archetype id, which is what you are looking for here?

Otherwise you'd need to allow "-alpha" etc here as well?

Sebastian


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

Re: VERSION.lifecycle_state options

[Thomas Beale]

Sebastian,

I think this is about right. I think 'immutable' in law and 'immutable' 
in information systems have to be understood as different things. The 
law is always local, so I think the best that could be done is a 
standard kind of attestation whose reason for change was something like 
'final version approved by governing health authority' or similar.


- thomas

On 10/07/2015 10:23, Sebastian Iancu wrote:
Thank you all for your suggestions. To conclude on this topic, the 
main ideas were that:
 - there is no sufficient reasons for an extra value for 
version.lifecycle_state to indicate that a version is immutable
 - immutable is anyway in real life not '100% immutable', corrections 
should/might be allowed under certain conditions (up the the application)
 - immutable state functionality can be achieved using ATTESTATION 
(that gives the seal and context) and perhaps EHR_ACCESS (that gives 
the read-only policy)


Regards,
Sebastian


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

Re: VERSION.lifecycle_state options

[Thomas Beale]

On 09/07/2015 12:53, Erik Sundvall wrote:

Hi!

Is a new type of VERSION.lifecycle_state the best to solve the 
described use-case? Won't the "correcting a typo change" or "we forgot 
a thing" use-cases etc still always be there even for things written 
as binding contracts?


Is it perhaps enough to have the "final" plan fixed/fixated by 
applying digital signatures on the VERSION using the ATTESTATION 
 
class, thus marking the "contractual agreement" with digital 
signatures so that nothing be changed without the system (and/or 
users) noticing it.


this would be my solution as well.



The application can then, for the type of change-sensitive documents 
described by Sebastian, perform signature checks and show warnings or 
refuse to update info unless the change is signed by the same persons 
or organisations that signed the previously signed version.


To me it seems natural that binding contracts and signatures belong 
together.


Heath's use-case "something to indicate a version was moved distinct 
from deleted" won't be solved by signatures though, so 
https://openehr.atlassian.net/browse/SPECPR-83 is still valid.


agree

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

Re: openEHR specifications - the future is Asciidoctor + MagicDraw?

[Thomas Beale]

Athanasios,

excellent suggestion. I haven't even looked at building in syntax 
diagrams right now, but your timing is perfect - I was contemplating how 
to put the ADL grammar into the new style spec in a nice way. Currently 
grammar is generated as an HTML page (as per links on this wiki page 
) 
which is ok, but the source file is not in a re-usable form (it's a .y 
file containing Eiffel code - but it would be the same problem with any 
language like Java or C etc) and the lexer files are also not re-usable 
or easily publishable.


So we need to solve this in a way that makes the lexer and parser 
grammar files primary, and then all other files based on them. All of 
this goes for AQL as well.


Both ADL and AQL grammars can undoubtedly be improved - there is not 
only one grammar for a language - so making changes for computability 
doesn't have to break the language definition. I suspect that if we can 
get some optimal grammars sorted out for Antlr, they will become the 
'primary files' for these languages in the ecosystem. Shinji is also 
after the same thing, and I think has done some work on ADL grammar for 
Antlr.


So we need to do some work here, and your work looks like a good 
starting point.


As soon as we have a few more gremlins sorted out in the main toolchain, 
I'll get myself up to speed on your and Shinji's work here and hopefully 
we can create a solution which I think then really will make for a 
powerful models+documentation+programming toolchain.


- thomas

On 03/07/2015 10:56, ANASTASIOU A. wrote:

Hello Thomas

This is looking really good and much more usable and lite than 
shifting through PDFs.



Just a small suggestion / question.


Will it be possible to have (possibly automatically updated from a 
single model) syntax diagrams for ADL / AQL?




A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax

Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf

Both of these attempts to map the languages were made with the view of 
creating syntax diagrams which are immensely useful when trying to 
provide the bigger picture to people with minimal technical background.



The ADL EBNF hit some snags because of various differences in the 
definitions across different files but in general, it is a 
straightforward task.



Happy to join forces if something like this is already underway.



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

openEHR specifications - the future is Asciidoctor + MagicDraw?

[Thomas Beale]

Back at the September 2014 roadmap meeting *we agreed to move from the 
current specifications documentation *in FrameMaker to a modern tool, 
preferably text-based. This wiki page 
 
shows various alternatives under consideration. The other problem *we 
agreed to deal with was to put all openEHR models into a UML *tool 
environment.



 Progress

We've *made a lot of progress *on both of these. The whole of openEHR is 
now in MagicDraw, one of the most capable UML tools, with an open API 
enabling model publishing. You may have seen the generated website here 
. 
The models themselves are of course available in the various 
specifications Github repos. MagicDraw's native save format is XMI 2.x, 
which will work with any other UML tool that properly implements XMI.


I've been working with Bostjan Lah from Marand on the documentation 
side, using *Asciidoctor as the target*. 
Asciidoctor is asciidoc markdown/up/sideways on steroids + publishing 
tools for DocBook, HTML, PDF etc. This has entailed converting 
FrameMaker sources to Asciidoctor sources and building a new toolchain. 
All of the the *model diagrams and formal specification sections in 
documents are now extracted from the UML models *in MagicDraw, by some 
Java magic that Bostjan has written - so now we have documents that are 
fully model based, and also can be published into at least 3 formats.


The Asciidoctor toolchain is all open source, as are the related 
projects (asciidoc-stylesheet-factory, pygments etc), and the developers 
are very helpful. I've also managed to build a pretty good ADL and ODIN 
code highlighter for Pygments , which hopefully 
should be accepted into the main project.


MagicDraw, although not open source, is pretty open and very 
standards-based, and the people there have been very supportive as well.


We are not finished, but it looks as if the Asciidoctor + UML tooling 
approach will work pretty well, and we will have higher quality 
documentation than before with much greater flexibility.


*What does the result look like*? You can get an idea of the results for 
the re-engineered AOM and ADL specifications:


 *

   AOM specification: source formhere
   ;HTML
   view
   
;
   features to look for: UML tool generated diagrams and specification
   tables;

 *

   ADL specification: source formhere
   ;HTML
   view
   
;
   features to look for: machine highlighting using a newly developed
   ADL mode for Pygments;

The approach to building specification documentation and web resources 
is shown graphicallyhere 
. 



PDFs are coming - takes some work to get the style sheet into shape.  
The project home page on Github 
 gives a fuller 
description of the approach so far.



 Benefits

Once a toolchain like this is established, we can get the following 
benefits:


 *

   model-based documentation is always up to date, as long as the
   models are maintained;

 *

   specifications built like software, under continuous build on server;

 *

   easier to report and fix errors, and to update documents, due to
   easy-ish source form;

 *

   more flexibility to create new output formats.


 Future

Right now, the Asciidoctor+MagicDraw approach looks like a solid future 
solution.  Personally I am now seeing the approach as a generic solution 
for doing single-source technical documentation of any kind for the 
future - I think we may be onto something quite powerful.


We would be interested in feedback and reactions from the community on 
this approach.


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

Re: Updated Vim mode for ADL syntax

[Thomas Beale]

It probably needs some more work to make it right before doing that. 
There is a lot more that can be done, e.g. folding, and it has some 
bugs. Needs a real vimscript pro to have a go at it.


- thomas

On 24/06/2015 17:49, Bert Verhees wrote:


Very good Thomas, I often use vim for quick repair in terminal, I hope 
you get it distributed with vim, as some other programming languages, 
like C, are supported default.


Regards
Bert

Op 23 jun. 2015 18:46 schreef "Thomas Beale" 
<mailto:thomas.be...@oceaninformatics.com>>:



I have uploaded new vim syntax colourising files
<https://openehr.atlassian.net/wiki/display/dev/ADL+Text+Editors>,
for those who use vim. I have included a dark blue background
custom colour scheme as well. Have a look at the screen shots - I
have tried to be somewhat scientific about the colours:

  * various shades of blue for RM classes, properties in cADL, and
also properties in ODIN sections
  * green for terminology codes



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

Updated Vim mode for ADL syntax

[Thomas Beale]

I have uploaded new vim syntax colourising files 
, for 
those who use vim. I have included a dark blue background custom colour 
scheme as well. Have a look at the screen shots - I have tried to be 
somewhat scientific about the colours:


 * various shades of blue for RM classes, properties in cADL, and also
   properties in ODIN sections
 * green for terminology codes

Much much more can be done. For those of you who have any idea of 
vimscript, you will know it is a hugely powerful and fairly arcane 
language. I don't have time to do more on this, but if there are others 
out there who want to work on it and/or add new vim editor schemes, 
please feel free to improve.


- thomas

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

openEHR@ StackExchange - update

[Thomas Beale]

To succeed with openehr.StackExchange.com, the committers phase needs 
200 total. We particularly *need people who want to ask questions* to 
commit (do it here 
).


Secondly, 50% of those committers need 200+ reputation on any other 
StackExchange site. You can see all the sites here 
.


 * For IT devs and other techies, geek docs etc,  I recommend you make
   sure you are always logged in when using StackOverflow, ServerFault
   etc which you probably already do - just be a bit more active in
   commenting, asking questions etc, and you'll get 20 rep in no time
 * For clinical people, and other non-IT, consider joining another
   StackExchange site (Physics, Homebrewing, Tor, Community Building,
   Lifehacks, ) and start posting questions and answers. I joined a
   few - it is actually worth it to learn how StackExchange works.

Let's give it a proper go before giving in and looking elsewhere for a 
way to do openEHR Q&A!


- thomas

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

openEHR @ StackExchange - phase 2 - commitment

[Thomas Beale]

We did it... but did I mention that it's only phase 1? Those of you who 
looked carefully will have realised that getting your own stackexchange 
area isn't easy . But - let's see how 
we go.


We are now in the 'commit' phase, which means gathering enough people 
who commit to using the site (as questioners, answerers, commenters). 
*Anyone who signed up already can commit*, which will give us over 50%.


The commitment score is the minimum of three scores:

 * % /*200 committers in total*
 * % /*100 committers with 200+ rep on any other site*
 * % - commitment score, based on *committers' activity on all other
   sites *and how old the commitment is

These numbers keep changing obviously. We would need to hit 100% on all 
of these to qualify. As you can see, it means not only a lot of 
committers, but a lot of *committers who use other StackExchange sites 
*. There are lots of sites, but one that 
may be of interest is the new Healthcare IT proposal site 
. But 
your activity on Beer, Arduino, Philosophy or Mythology will also help;-)


If we get past this phase, then we are in an operational beta phase when 
we can use the facility normally.


- thomas

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

nearly there - openEHR @ StackExchange - 2 questions to go

[Thomas Beale]

If anyone has any votes left (each user has 5), here is what to do:

 * login to the openEHR Area51 StackExchange page
   
 * find the two questions with < 10 votes (currently on 6 and 8) - near
   the bottom of the page - and UPVOTE them
 * please DO NOT DOWNVOTE anything

In theory *this requires 4 users*, since each user can only vote once 
per question, so to get the question with 6 to 10, that's 4 distinct users.


Please don't try downvoting other Questions with > 10 to upvote those 
with less - as far as I can make out on the Area51 discussion lists this 
is not seen as a good sign by the StackExchange Admins...


- thomas

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

Re: openEHR @ StackExchange - getting close

[Thomas Beale]

On 12/06/2015 16:50, Diego Boscá wrote:

I think it could be also interesting to answer the questions we know
the answer for, to show there are also experts and discussion out
there ;D


If you look at 'hardware-recommendations', another new StackExchange 
area in the 'Commitment' phase (openEHR is in the 'initial' phase), the 
questions generally have no answers yet, and also they are 'locked', and 
it seems that all you can do is get enough 'committers' (people who sign 
up in some way to the specific area).


It's a strange process to be sure, but I think the main thing we need to 
do is to get votes on those last 8 questions and see what happens next.


- thomas

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

Re: openEHR @ StackExchange - getting close

[Thomas Beale]

On 12/06/2015 16:50, Diego Boscá wrote:

I think it could be also interesting to answer the questions we know
the answer for, to show there are also experts and discussion out
there ;D



I have not figured out whether that's what they want or not - but if we 
assume that the 'example' questions don't get deleted by the admins, you 
are probably right. Maybe we just start using it.


- thomas

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

Re: openEHR @ StackExchange - getting close

[Thomas Beale]

We are getting closer 
to the next 
step. We have 76 followers.


We still need 17 questions with 10 votes. We have the requisite number 
of questions, it's just a case of people using their votes on them 
(don't worry if they don't really interest you, they are example 
questions - to get a stackexchange site, the community has to 
demonstrate interest).


Many of the questions with < 10 votes do have some votes, so we probably 
need a total of about 120 up-votes to get through this stage. I think 
each user gets 5 votes, so that's equivalent to 24 users.


Remember, there is no value in up-voting a question that already has 10 
or more votes.


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

Re: VERSION.lifecycle_state options

[Thomas Beale]

I think we need a clear definition of the difference between 'complete' 
and 'final'...


On 10/06/2015 15:59, Sebastian Iancu wrote:

:) final is final! Even though consent was given on wrong data...

I guess if needed on application level it can be overruled under some 
special conditions (special administrative rights, timeframe, owner, 
etc.).
But I was looking more for a 'flag' to signal that a specific version 
cannot be changed anymore (under normal conditions).





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

Re: VERSION.lifecycle_state options

[Thomas Beale]

I suspect that the idea of 'final' requires something more like a 
'locked for modification' flag. But nothing is guaranteed to be 
immutable - what if the consent was given, and the committed information 
was considered clinically 'final' but then a simple typo error (e.g. 
patient name, or the date of procedure) was found?


- thomas

On 10/06/2015 15:32, Sebastian Iancu wrote:

Hello all,

Does anybody (with an openEHR persistence system/solution) encountered 
the need to record other states than 'incomplete', complete', 
'deleted' for a VERSION.lifecycle_state?


The use case is that in some circumstances a version need to become 
immutable and any change should be forbidden. Imagine a care plan that 
was already 'inform-consented' - it should not be allowed to be 
changed in any way, neither logically deleted (unless perhaps some 
administrative reasons). In contrast, by current version of 
specifications, a 'complete' version can be still changed or 
logically-deleted (which is valid behavior also).


Regards,
Sebastian

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







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

Re: openEHR @ StackExchange - progress

[Thomas Beale]

Yes - please don't vote higher than 10.

These questions are 'example' questions - this is the community testing 
phase of StackExchange. I'm not sure if the questions get trashed later 
on or not, but we have to assume for now that they are used solely for 
gauging community size and interest.


We now have 64 followers total - that's what is needed; we still need 27 
questions with a score of 10. We already have 13 with >=10; and we have 
a total of 34 questions.


So we need (at least):

 * 21 of the remaining questions to get a score of 10
 * 6 new questions with 10 votes each

We probably need a bit more than this, since as Seref says, a few 
questions may get removed by the StackExchange reviewers.


*Voting for questions you would not personally be interested in is ok *- 
we just need to up the scores - please use all your votes!


- thomas


On 09/06/2015 08:32, Seref Arikan wrote:
To all who are helping with this: there are questions with upvotes > 
10. I think this is a waste of your upvotes; we need to get as many as 
possible to 10, upvoting beyond 10 does not help with our goal of 
creating an openEHR area.
Also, some of the questions do not comply with Q&A format; generic 
discussions can be problematic if someone reviews them. Again, these 
would be waste of upvotes.


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

openEHR @ StackExchange - progress

[Thomas Beale]

For all those who suffer from 'not enough expert resources for openEHR' 
 you can make it happen - if we can create an openEHR StackExchange 
area.


To get a StackExchange area, we still need to get 16 more followers and 
create 38 more example questions with a score of 10 or more 
. We actually 
only need 10 new questions - we have 28, they just need more votes.


To up the scores on the questions, just upvote them (but not beyond 10). 
Remember these are example questions - the idea is just to show that 
there are enough people interested to make it worthwhile.

Please use all your possible upvotes to get more questions to a score of 10!

Please forward to colleagues in your institution or company to get us 
over the line.


thanks

- thomas

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

Re: Cleaning up the wiki... more space consolidation?

[Thomas Beale]

I've cleaned up the Developers space, made a half decent home page 
<https://openehr.atlassian.net/wiki/display/dev/Developers+Home>, and 
moved the few pages from the Implementation Guidance space, which is now 
gone.


I leave it to others to work on this space - please try to be more 
active in keeping things up to date.


Next question: the Projects wiki space contains software development 
projects - should these pages also just go under the Developers space? 
If people agree with this idea I'll do it.


- thomas

On 25/05/2015 10:57, Thomas Beale wrote:


We appear to be getting more and more newcomers to the openEHR website 
and wiki - and on the wiki, they are faced with a somewhat chaotic 
place! I think we should slowly start to clean it up.



  First suggestion:

There are two spaces for developers - 'Developers', which has a lot of 
pages, and needs some re-organisation, and 'Implementation Guidance' 
which is small and not used much.
I propose to put the pages from the latter under the 'Developers' 
space and remove the latter space.



  Second suggestion:

I think we need a 'getting started' page for each manor development 
technology - Java, Python, C# etc. There are bits and pieces all over 
the place but nothing coherent.


Would people like to see something like the following structure:

  * Developers space
  o Getting started
  + Java
  + C#
  + Python
  + Ruby
  + 



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

Re: openEHR @ StackExchange

[Thomas Beale]

On 25/05/2015 12:16, Diego Boscá wrote:

I would assume it can be both: a question could be just about specs
(just the "openEHR" tag) or about any specific implementation (e.g.
"openEHR" and "java")



yep - that's how I think it would work.

- thomas

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

openEHR @ StackExchange

[Thomas Beale]

On 25/05/2015 11:00, Diego Boscá wrote:
Agree with both. Probably we should go review the mailing lists to 
identify which kind of questions are usually asked by newcomers.


Also, we should use stackoverflow more, with dedicated tags to openEHR.


I created a new site proposal for openEHR on StackExchange 
- 
I'm not quite sure how this works, but I think if it gets visited by a 
lot of people, that helps it get created? So please visit the link!


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

Re: Cleaning up the wiki...

[Thomas Beale]

On 25/05/2015 11:00, Diego Boscá wrote:
Agree with both. Probably we should go review the mailing lists to 
identify which kind of questions are usually asked by newcomers.


Also, we should use stackoverflow more, with dedicated tags to openEHR.


Do we need to do anything special to make stackoverflow work? Should we 
treat that as a potential place to get specific Qs answered? We could 
certainly put some appropriate links from the website e.g. footer menu..


Stackoverflow has one of the best visual dynamics of all discussion list 
type forums, so I think it's good to use it.


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

Cleaning up the wiki...

[Thomas Beale]

We appear to be getting more and more newcomers to the openEHR website 
and wiki - and on the wiki, they are faced with a somewhat chaotic 
place! I think we should slowly start to clean it up.



 First suggestion:

There are two spaces for developers - 'Developers', which has a lot of 
pages, and needs some re-organisation, and 'Implementation Guidance' 
which is small and not used much.
I propose to put the pages from the latter under the 'Developers' space 
and remove the latter space.



 Second suggestion:

I think we need a 'getting started' page for each manor development 
technology - Java, Python, C# etc. There are bits and pieces all over 
the place but nothing coherent.


Would people like to see something like the following structure:

 * Developers space
 o Getting started
 + Java
 + C#
 + Python
 + Ruby
 + 

thoughts?

- thomas

--
Ocean Informatics <http://www.oceaninformatics.com>   *Thomas Beale
Chief Technology Officer*
+44 7792 403 613 	Specification Program, /open/EHR 
<http://www.openehr.org/>

Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/>
Health IT blog <http://wolandscat.net/category/health-informatics/> 
View Thomas Beale's profile on LinkedIn 
<https://uk.linkedin.com/pub/thomas-beale/0/217/68a>


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

Re: Template Designer - remove slot

[Thomas Beale]

On 04/05/2015 16:11, pablo pazos wrote:
Awesome, I'll add this to the TD JIRA. Do anyone remember where that 
JIRA is?


--


Here is a new tracker for the TD 
 
- please add it here.


- thomas

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

AOM Translation details - can we have a concrete proposal?

[Thomas Beale]

As we process outstanding PRs, I discovered an old one from Sebastian 
Garde - SPECPR-24, that initially reports the need for better 
translation meta-data. Silje started a thread on more recent 
requirements here to which some of us replied.


Could we have a concrete proposal - maybe a synthesis of all of this 
thinking from Sebastian, Silje, and anyone else who specifically is 
interested in this? My input would be mainly to say: don't try to put 
every possible meta-data item in - assume that we can rely on an 
external registry and/or CKM for some author information, even if it's 
not the case right now.


I don't think the rest of us will have time to work this out, but I can 
certainly implement a concrete proposal in the ADL Workbench and AOM 
spec if we can have one.


thanks

- thomas

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

Re: Have your say on existing Problem Reports

[Thomas Beale]

Note that you can vote on these PRs as well, according to what you think 
is most important to be fixed.


- thomas

On 09/05/2015 15:10, Thomas Beale wrote:


All,

there are 114 Problem Reports (PRs) being processed by the 
Specifications Editorial Committee (SEC) right now, here on the SPECPR 
Jira tracker 
<https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-46?filter=allopenissues>. 
We are heading to a 2-day meeting (21 May) for the SEC to convert 
these to Change Requests (CRs) that will be the basis of the next few 
releases of openEHR.


If you want to make comments or review any of these PRs (or even raise 
new ones, but please make sure, no duplicates!) then feel free to 
visit the SPECPR tracker and do so.


thanks



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

Have your say on existing Problem Reports

[Thomas Beale]

All,

there are 114 Problem Reports (PRs) being processed by the 
Specifications Editorial Committee (SEC) right now, here on the SPECPR 
Jira tracker 
<https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-46?filter=allopenissues>. 
We are heading to a 2-day meeting (21 May) for the SEC to convert these 
to Change Requests (CRs) that will be the basis of the next few releases 
of openEHR.


If you want to make comments or review any of these PRs (or even raise 
new ones, but please make sure, no duplicates!) then feel free to visit 
the SPECPR tracker and do so.


thanks

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

Technical and clinical lists now have searchable archive.

[Thomas Beale]

We have uploaded the technical and clinical list archives to 
mail-archive.com, which is a web-searchable interface to the lists.


Technical list here 

Clinical list here 
.


These links are now on the mailing lists page 
.


The remaining mailing lists are coming soon.

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

(ignore} technical list archiving test message

[Thomas Beale]

test #1

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

Licensing of specs and artifacts

[Thomas Beale]

The current proposed AOM 2 meta-data can be seen here 
<http://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1422971258847_792963_30335>.
 
Notes:

  * One thing we added due to CIMI, which we think is globally
applicable is 'conversion_details' in RESOURCE_DESCRIPTION.
Typically, an archetype with is_generated = true will have these
conversion_details set. This should take care of the 13606
conversion example.
  * See also ip_acknowledgements, which is how we will put in
acknowledgements for e.g. SNOMED, LOINC etc.
  * The model doesn't yet include any changes corresponding to Silje and
others ideas about a better model of translator details.

The current test example of an archetype with full meta- 
<https://github.com/openEHR/adl-archetypes/blob/master/ADL2-reference/features/meta_data/openehr-test_pkg-WHOLE.full_meta_data.v0.0.1.adls>data
 
is as follows.

archetype (adl_version=2.0.5; rm_release=1.0.2; generated)
 openehr-test_pkg-WHOLE.full_meta_data.v0.0.1

language
 original_language = <[ISO_639-1::en]>

description
 original_author = <
 ["name"] = <"Thomas Beale ">
 ["organisation"] = <"Ocean Informatics 
<http://www.oceaninformatics.com>">
 >
 details = <
 ["en"] = <
 language = <[ISO_639-1::en]>
 purpose = <"This archetype demonstrates the use of 
governance meta-data.">
 use = <"This archetype should be used on a clear day with 
no wind.">
 misuse = <"This archetype should not be used around 
children or dogs.">
 keywords = <"governance", "test">
original_resource_uri = <
 ["resource A"] = <"Some resource available in the 
English language <http://aaa.bbb/path/to/resource>">
 ["resource B"] = <"Some other resource available in the 
English language <http://aaa.bbb/path/to/resource>">
 >
 >
 >
 lifecycle_state = <"unmanaged">
 other_contributors = <"Marcus Aurelius ", 
"Augustus Caesar 
 original_namespace = <"org.archetypes-r-us">
 original_publisher = <"Archetype R Us">
 custodian_namespace = <"org.openehr">
 custodian_organisation = <"openEHR Foundation">
*licence = <"Creative Commons CC-BY 
<https://creativecommons.org/licenses/by/3.0/>">*
 copyright = <"Copyright (c) 2014 openEHR Foundation">
 resource_package_uri = <http://www.openehr.org/ckm/path/to/package>
*ip_acknowledgements = <**
**["loinc"] = <"This content from LOINC? is copyright ? 1995 
Regenstrief Institute, Inc. and the LOINC Committee, and available at no 
cost under the license at http://loinc.org/terms-of-use";>**
**["snomedct"] = <"Content from SNOMED CT? is copyright ? 2007 
IHTSDO ">**
**>**
**conversion_details = <**
**["source_model"] = <"CEM model xyz 
<http://location.in.clinicalelementmodels.com>">**
**["tool"] = <"cem2adl v6.3.0">**
**["time"] = <"2014-11-03T09:05:00">**
**>**
*references = <
 ["1"] = <"Barthel Scale 
<http://en.wikipedia.org/wiki/Barthel_scale>">
 ["2"] = <"Barthel Index, the Internet Stroke Center 
<http://www.strokecenter.org/wp-content/uploads/2011/08/barthel.pdf>">
 ["3"] = <"O'Sullivan, Susan B; Schmitz, Thomas J (2007). 
Physical Rehabilitation, Fifth Edition. Philadelphia, PA: F.A. Davis 
Company. p. 385.">
 >
 other_details = <
 ["regression"] = <"PASS">
 >



On 28/04/2015 13:26, Ian McNicoll wrote:
> Hi Diego,
>
> I will bring this post to the attention of the Board for a more 
> authoritative response on the copyright / licensing question. These 
> are just my personal opinions for now though Heather, Sebastian, Silje 
> and I have discussed many of  these issues so I can think they are 
> probably representative.
>
> >> The copyright holder is still openEHR? Does It have something to do
> >> with the CC-BY-SA license?
>
> The emerging view seems to be that *any* fork of an archetype, even if 
> it just changes local ownership (namespace in ADL2.0) should probably 
> result in change of copyright to the new owner with attribution to the 
> previous owner. CC is a bit vague on when new copyright shoul

Specifications program roadmap - have your say

[Thomas Beale]

There will be a f2f of the Specifications Editorial Committee 
<http://www.openehr.org/programs/specification/editorialcommittee>(SEC) 
in Netherlands, 21/22 May. At this meeting, the SEC will try to process 
the existing Problem Reports 
<https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECPR%20ORDER%20BY%20created%20DESC>(PRs)
 
and convert them to Change Requests (CRs) on the various Specifications 
Trackers 
<https://openehr.atlassian.net/secure/Dashboard.jspa?selectPageId=10190>. The 
result will be a roadmap of specifications changes, expressed as CRs on 
those CR trackers, for approximately the next 2 years.

Of course this will not be fixed - anyone can raise a PR at any time, 
and in the steady state, the SEC will process it quickly thereafter. The 
current exercise is to get up to speed on the backed-up PRs and issues.


  What can I do?

The PR tracker 
<https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECPR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC>currently
 
contains 109 unresolved issues that many of you have reported over the 
last few months / years. There are another 19 older Change Requests for 
the Reference Model 
<https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECRM%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC%2C%20priority%20DESC>.

The SEC's job is just to manage the problem reports, issues and 
determine appropriate changes to the specifications that address them. 
The issues come from everyone in the community.

What everyone can do is to look through those 109 PRs and 19 CRs

  * if there are any comments you want to make or any new PRs you want
to raise.
  * If you were the original raiser of the PR, you can edit the main
text to add detail etc.

All comments will be read by the SEC, and incorporated into the roadmap 
(i.e. the CRs that result from the analysis we are doing).

please report any problems with access, logging in etc to 
admin at openehr.org <mailto:admin at openehr.org>

- thomas beale

(Specifications Program)

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

OpenEHR and Oracle XML DB problems

[Thomas Beale]

Indeed, it would be a great thing. The reason it doesn't exist so far, 
is that to be useful we need synthesised data sets that have some 
realistic statistical spread of values. Since we are talking at multiple 
levels - not just vital signs measurements, but covariance of all kinds 
of measurements with assessments (diagnosis etc), plans and orders and 
actions, the complexity is not trivial.

A data synthesiser to do this for openEHR would be a fantastic Master's 
project (hint :).

- thomas

On 16/04/2015 10:02, Dmitry Baranov wrote:
> Diego,
> that'll be great.
> Hope that OpenEHR github owners will provide us with an instance samples 
> repository some day or other :)
>
>> I can generate random sample instances from current archetypes for you
>> if you need them. Generated data may not make much sense as it only
>> tries to follow the archetype constraints, but it should be enough for
>> application testing and benchmark

OpenEHR and Oracle XML DB problems

[Thomas Beale]

On 16/04/2015 06:46, Bert Verhees wrote:
>
>>>
>>> I think it is a stupid rule in the XML-Schema standard.
>>
>> I just hit this in doing the AOM2 schema. It's a completely senseless 
>> rule, clearly a hangover from 'document' thinking - nothing to do 
>> with 'data' thinking.  I ended up replacing  with.
>>
>> 
>
> It is a poor man's choice, because of the side-effects.
> The "choice"-constraint makes the engine ignore the 
> minOccurs/maxOccurs constraints in the elements under the choice element.
>
>>
>> I have to say, XML-schema based data looks extremely unattractive as 
>> a basis for anything except data exchange. I wouldn't try to 
>> implement anything important inside a system with it, you are too 
>> compromised in too many ways.
>
> It is also used, as I wrote yesterday, to tell an XML-database how, in 
> a specific namespace, the data are arranged, in that way the database 
> can auto-create indexes, etc.
> There is no other way to communicate the structure of XML-documents, 
> and even if we found another way, or invented it ourselves, we still 
> would need a broad acceptation.

We still need some kind of schema for XML docs/ messages, but I would 
not even think of making any persistence be based on XML, especially not 
XML schema. Probably Relax NG would have been the better one for 
messages etc.

Keep XML at the boundaries, that's the key to happiness! I guess JSON 
with its own schema will replace it in the next couple of years.

- thomas

OpenEHR and Oracle XML DB problems

[Thomas Beale]

On 15/04/2015 17:28, Bert Verhees wrote:
> On 15-04-15 17:19, Dmitry Baranov wrote:
>> Sorry Bert ) I had to explain that Oracle 11 is a business 
>> requirement, not a hardware limitation.
>>
>>> Just do it, and then it should run fine, although you have to change 
>>> the
>>> XML-Schemas (a bit) before registering them to Oracle. I already
>>> explained to you before what and why.
>> I remember your advise but not sure that changing all the sequences 
>> to choices is a right way for many reasons. And I'm almost sure that 
>> it's an Oracle bug since other XSD validation tools (visual studio, 
>> netbeans and eclipse) say that my instance files are all OK and 
>> conform to XML schema.
>
> You are right it is a messy solution, but if you use "sequence", like 
> it is defined in the XML Schema, you have to take care that all the 
> nodes in your XML are in the right/defined order.
> I think this is hard to achieve when XML-files are created in 
> production, but of course, you can arrange that as an alternative.
>
> I think it is a stupid rule in the XML-Schema standard.

I just hit this in doing the AOM2 schema. It's a completely senseless 
rule, clearly a hangover from 'document' thinking - nothing to do with 
'data' thinking.  I ended up replacing  with.



I have to say, XML-schema based data looks extremely unattractive as a 
basis for anything except data exchange. I wouldn't try to implement 
anything important inside a system with it, you are too compromised in 
too many ways.

- thomas

AOM2 initial working XSDs and example validating XML output.

[Thomas Beale]

I have been working with the AML (Archetype Modelling Language) team 
recently, and as a result have produced a set of XSDs for AOM2.

These can be found here 
in 
Github.

Notes:

  * it's initial work, very unlikely not to change
  * the schemas were derived from existing AOM Release 1.0.2 schemas,
and have been changed fairly significantly
  * the underlying class structures are not just AOM classes, but P_AOM
classes

,
where the transform between the two is how I convert various complex
objects data e.g. MULTIPLICITY_INTERVALs, Ids etc, to generally
string form. This form is best suited to ODIN, JSON, etc, but also
helps with XML.
  * there are some example archetypes - Apgar, BP and a CIMI one in
generated XML format that validate in Oxygen against these schemas.
The next version of ADL Workbench will contain this XML generator.

People who care about XML more than I do will note I have taken some 
liberties with the XSD, particularly (for now at least) replacing 
'sequence' in some places with 'choice', since my current outputter 
doesn't know about order. There are also some others in the 'Resources' 
schema to do with names of XML attributes - many are just 'id' when they 
should arguably be 'language', 'code', 'terminology' etc. I'm looking at 
how to deal with this.

All feedback welcome.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

ADL 2 Workbench update - alpha of next release available

[Thomas Beale]

anyone is welcome to do this - please report problems here 
.

thanks

- thomas

On 03/02/2015 15:43, pablo pazos wrote:
> I will have some free time next week, do you want me to beta test it 
> and create a small report for you? (bugs, improvements , etc).
>
> -- 
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com 
>
> 

-- next part --
An HTML attachment was scrubbed...
URL: 

ADL 2 Workbench update - alpha of next release available

[Thomas Beale]

On 03/02/2015 15:17, pablo pazos wrote:
> Hi Thomas,
>
> Does it have ADL 1.5 / 2 editing capabilities?

partial. You can create a new archetype, template, specialised archetype 
by right-click on the appropriate node in the explorer of the library 
you are in. You can then either a) use the ADL source tab and/or b) 
right-click on the new archetype/template in the explorer and do 'edit' 
(the orange icon) and then in the definition view, some right click 
operations work. It's pretty alpha, and is being slowly worked on.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: