Re: DV_PROPORTION vs DV_QUANTITY for %

2019-01-03 Thread David Moner
I think DV_QUANTITY is the option here. Someone could argue that % is not a
proper unit, but it is, both in UCUM and SNOMED CT.

DV_PROPORTION should be only used when you want to maintain the numerator
and denominator explicitly separated, as a fraction, which should not be
the case with percentages. But it is true that the definition of the type
attribute in the specification is a bit misleading: "Indicates semantic
type of proportion, including percent, unitary etc."

El jue., 3 ene. 2019 a las 7:59, Bakke, Silje Ljosland (<
silje.ljosland.ba...@nasjonalikt.no>) escribió:

> Hi everyone, happy new year!
>
>
>
> We’ve just hit a question about modelling choices, how to represent
> percentages. We have a data type DV_PROPORTION, which can be used to
> represent any proportion such as a fraction or a percentage, and we have
> the DV_QUANTITY data type which can have % as the unit. In most existing
> archetypes such as the OBSERVATION.pulse_oximetry archetype, we’ve used the
> DV_PROPORTION data type for the percent elements, while for some reason in
> the draft EVALUATION.alcohol_consumption_summary archetype we’ve chosen
> DV_QUANTITY with the unit ‘%’ for the “Strength” element.
>
>
>
> We’ve had a look at the data types documentation (
> https://specifications.openehr.org/releases/RM/latest/data_types.html),
> and we can’t really find any guidance in the examples there. Is there any
> guidance about this anywhere else? Does anyone have any opinions about when
> to use each data type for percentages?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no / Twitter: @arketyper_no
> <https://twitter.com/arketyper_no>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Postcoordinated terminology expressions in openEHR

2018-11-19 Thread David Moner
Hi, just for clarification, you have mixed are two different things:

- SNOMED CT postcoordinated expressions are structured combinations of one
or more concepts to express a clinical idea. You use them to create new
concepts not available in the SNOMED release. They are built using the
SNOMED CT Compositional Grammar. In the archetypes they could be used for
the semantic binding of the structure (at codes), or for data values in
coded data types
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Compositional+Grammar

- SNOMED CT Expression Constraint Language is an extension of the
compositional grammar that allows building SNOMED CT subsets intensionally,
i.e., by restriction or querying. This allows you to create a subset by
defining an expresion. This can be used to constraint coded values (ac
codes)
https://confluence.ihtsdotools.org/display/DOCECL/Expression+Constraint+Language+-+Specification+and+Guide

Now, if your question is about how to combine the modeling of archetypes
and the modeling of SNOMED CT expressions, this paper could give you some
hints. It's old, but still relevant. There are clear areas for modeling
information as archetypes or with terminologies, but there is also a grey
area where both solutions are applicable.

"Representing clinical information using SNOMED Clinical Terms with
different structural information models", David Markwell, Laura Sato,
Edward Cheetham
http://ceur-ws.org/Vol-410/Paper13.pdf

El lun., 19 nov. 2018 a las 14:21, Bakke, Silje Ljosland (<
silje.ljosland.ba...@nasjonalikt.no>) escribió:

> Hi everyone,
>
>
>
> We’ve recently started an informal and practically oriented regular
> contact with the Norwegian SNOMED CT NRC. One of the things they were
> interested in discussing was how to use postcoordinated SNOMED CT
> (expression constraint language) expressions with openEHR, which I know
> nothing about. Does anyone have any knowledge about or experience with this?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no / Twitter: @arketyper_no
> <https://twitter.com/arketyper_no>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Seeking clarification regarding Assumed value

2018-10-08 Thread David Moner
I totally agree with Sebastian, that's a fight we have had for years while
implementing LinkEHR.
You can of course create an ad hoc tool for openEHR, including all the
usability and additional rules you want. But if your tool is really generic
(i.e. based in a BMM definition of the reference model), it will be
difficult to implement those rules.

El lun., 8 oct. 2018 a las 13:38, Sebastian Garde (<
sebastian.ga...@oceaninformatics.com>) escribió:

> Hi Heather,
>
>
>
> Purely technically, I think the answer is “false” - since assumed values
> are an available independent of their context (e.g. data or state).
>
> But for all practical modelling I think the answer is “true” –
> assumed_value should really be used for protocol/state, but not data.
>
> As for the tooling, there’s always a bit of tension between these two,
> i.e. how generic such tools can and should be, what should be exposed to
> the UI and what maybe not.
>
>
>
> Sebastian
>
>
>
>
>
> *Von:* openEHR-clinical  *Im
> Auftrag von *Heather Leslie
> *Gesendet:* Montag, 8. Oktober 2018 12:17
> *An:* For openEHR clinical discussions  >
> *Cc:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Betreff:* Seeking clarification regarding Assumed value
>
>
>
> Hi everyone,
>
>
>
> Assumed value -
> https://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_assumed_value
>
>
>
> I’ve spoken to Sam Heard on many occasions and I have understood him to
> say that the intent for an assumed value to only be relevant for ‘State’ in
> an OBSERVATION. But never in ‘Data’. This is what I’ve always taught
> modellers.
>
>
>
> The original Ocean Archetype Editor, had this implemented. In more recent
> years ‘assumed value’ was implemented across all of the parts of the
> OBSERVATION. Incorrectly, as I understand it, but the code was never
> reviewed nor updated.
>
>
>
> We are now debating how this should be implemented in the new ADL
> Designer, and I’m seeking clarification.
>
>
>
> It makes sense to be able to potentially have an assumed value for ‘State’
> – for example the position of the patient if it is always the same in 99%
> of use cases. The theory, as I understand it, is that in this situation the
> position will only be recorded if the assumed value is modified from the
> assumed value. (Mind you, if the assumed value is excluded/zero occurrence
> in an implemented template, it will not necessarily be a valid assumption,
> but let’s keep that argument about whether assumed values are reasonable at
> all for later).
>
>
>
> The discussion is often further compounded by confusion about default vs
> assumed values.
>
>
>
> I don’t think that it makes any sense to allow an ‘assumed value’ for
> actual data values eg a Systolic Blood Pressure measurement – especially
> if, as per the specs link (above), “The notion of assumed values is
> distinct from that of 'default values'. The latter is a local requirement,
> and as such is stated in templates; default values do appear in data, while
> assumed values don’t.”
>
>
>
> My question to the list: Data values need to be recorded explicitly and
> should never be assumed – True or False?
>
>
>
> Thanks
>
>
>
> Heather
>
>
>
> *Dr Heather Leslie*
>
> MB BS, FRACGP, FACHI, GAICD
>
> M +61 418 966 670
>
> Skype: heatherleslie
>
> Twitter: @atomicainfo, @clinicalmodels & @omowizard
>
> www.atomicainformatics.com
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Inconclusive lab results coding

2018-09-17 Thread David Moner
gt;> https://cloudehrserver.com
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>> --
>>
>> *Ing. Pablo Pazos Gutiérrez*
>> pablo.pa...@cabolabs.com
>> +598 99 043 145
>> skype: cabolabs
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>
>> [image:
>> https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]
>> <https://cabolabs.com/>
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: openEHR Education Program

2018-07-25 Thread David Moner
Thank you all for your answers.
I agree that at this point the important thing is to find the way to
endorse trainers and, maybe, design the desired professional
certification,skills and not necessarily providing specific training
materials.
I'll wait for news.

Regards,
David

El mié., 25 jul. 2018 a las 11:01, Pablo Pazos ()
escribió:

> Hi David, yes I was involved :)
>
> Evelyn presented a document called Book of Knowledge, which tried to
> analyze/define different contexts and aspects of different roles people can
> play using openEHR, the skills needed for an openEHR related job, and some
> topics that should be part of training/education programs ("program" in
> terms of courses and their internal organization of topics). On that
> opportunity I acted as a reviewer/editor of the BoK.
>
> I think the BoK was an excellent start for a full fledged program
> ("program" in terms of people organizing, validating, endorsing and
> certificating courses, trainers and students), but in practical terms it
> might be to ambitious and had a huge scope that can't be handled by the low
> budget we have at the Foundation.
>
> Some months ago people from the board started to propose a the need of a
> practical approach and way smaller scope, but someone has to define that.
> After talking a lot with Hildi, Koray, and Heather, Hildi proposed a new
> plan of action and presented that to the board. This time I also acted as a
> reviewer/editor, as well as others. Hildi is actually leading this new
> effort.
>
> I think after the board approve the document presented by Hildi, that
> should be opened to the community for transparency and feedback. The nice
> thing is, maybe my biggest contribution to the doc, is that includes a plan
> of action for the first 12 months of the new education program (was never
> formally established), that includes, among other things, to have some
> guidelines for trainers to coordinate/standardize parts of the training
> they (we) give, and how the endorsement of trainers should be handled by
> the foundation and the related responsibilities of the education program in
> assessing and endorse training proposals. It would be great if in a couple
> of years we can have people offering training that is formally endorsed by
> the openEHR foundation. This of course will be also a filter for people
> offering openEHR training that doesn't have any experience with it and
> never participated in the community, sadly there are cases.
>
> Hope this gives a little background of the education program, what's going
> on, and what are the next steps.
>
> Best,
> Pablo.
>
> PS: I think after the program is formally established, we'll open
> postulations to add more members, as we do with the SEC.
>
>
> On Tue, Jul 24, 2018 at 8:37 AM, David Moner  wrote:
>
>> [Although this is a transversal topic to openEHR, I send it to the
>> technical list, as it is the most active]
>>
>> Hello,
>>
>> Some time ago (I think it was in 2015), there was some movement towards
>> formalizing an Education Program about openEHR. I thing Evelyn Hovenga
>> and Pablo Pazos were involved.
>> There have not been news about this, so I'm curious if it is still
>> active. If not, I think it is more important than ever, and we should
>> retake it.
>>
>> In the past I was responsible of (trying to) develop a similar program
>> inside the EN 13606 Association, so I'm happy to share the strategies we
>> had there, and to participate in developing an openEHR education and
>> certification plan.
>>
>> Best regards,
>> David
>>
>>
>> --
>> David Moner Cano
>>
>> Web: http://www.linkedin.com/in/davidmoner
>> Twitter: @davidmoner
>> Skype: davidmoner
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


openEHR Education Program

2018-07-24 Thread David Moner
[Although this is a transversal topic to openEHR, I send it to the
technical list, as it is the most active]

Hello,

Some time ago (I think it was in 2015), there was some movement towards
formalizing an Education Program about openEHR. I thing Evelyn Hovenga and
Pablo Pazos were involved.
There have not been news about this, so I'm curious if it is still active.
If not, I think it is more important than ever, and we should retake it.

In the past I was responsible of (trying to) develop a similar program
inside the EN 13606 Association, so I'm happy to share the strategies we
had there, and to participate in developing an openEHR education and
certification plan.

Best regards,
David


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: AE constraints offset for POINT_EVENTs

2018-06-26 Thread David Moner
Hi Pablo,

An old discussion about the offset and constraints over methods:
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09386.html

And an even older one (from 2012!):
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg06557.html

It seems that we have never found a full agreement between those who agree
with constraining the value returned by methods, and those who think that
it is not a recommendable approach.

BTW, I just checked that in LinkEHR we cannot constraint offset or any
other method, since our main source for the RM is the XML Schema and it
doesn't define them.

El mar., 26 jun. 2018 a las 4:27, Pablo Pazos ()
escribió:

> Hi all,
>
> Testing the Archetype Editor for OBSERVATION, found that defining a
> POINT_EVENT structure, allows to create a constraint for EVENT.offset,
> while that is a function by the v1.0.2 spec.
>
> Another weird thing is that defining a POINT_EVENT, and saying the HISTORY
> is periodic, makes the panel for the offset definition disappear, but the
> offset is still on the generated ADL.
>
> I believe this is a bug. Will test with LinkEHR.
>
> Anyone had problems with this before?
>
>
> definition
> OBSERVATION[at] matches {-- Presion arterial
> data matches {
> HISTORY[at0001] matches {-- Event Series
> period matches {
> DV_DURATION matches {
> value matches {|PT5M|}
> }
> }
> events cardinality matches {1..*; unordered} matches {
> POINT_EVENT[at0002] occurrences matches {0..1} matches
> {-- Cualquier evento
> offset matches {
> DV_DURATION matches {
> value matches {|PT5M|}
> }
> }
> data matches {
> ITEM_TREE[at0003] matches {*}
> }
> }
> }
> }
> }
> }
>
>
>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> _______
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: openEHR Toolkit

2018-03-28 Thread David Moner
Congratulations Pablo, a great and very useful contribution!

2018-03-28 5:39 GMT+02:00 Pablo Pazos <pablo.pa...@cabolabs.com>:

> Hi all,
>
> I have released a humble pack of tools to help developers working with
> openEHR and the EHRServer.
>
> This is a pre-alpha version, I'm looking for feedback. Any service idea,
> improvements, comments, etc. are very welcome!
>
> Please give it a try: http://server001.cloudehrserver.com/cot/
>
> We have many areas of improvements :)
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

2018-03-02 Thread David Moner
You are talking about a future reuse or validation of the data. But what it
was discused here is how to define the reference ranges for any data to
take an action at the moment of data registry. And, as Gerard said, those
references must be stored for future interpretation of the data. Thus, I'm
of the opinion that ideally this should be stored together with the
archetype/templates as it is part of the domain knowledge at that moment.
If it changes, the archetype version might also change as usual. For simple
rules, problably the current rules that can be added to the archetypes
could be enough. But if they are complex and we need to implement them in
an external service, then we have to maintain them functional in the
future. It is exactly the same as with terminologies: they evolve, but we
should mantain past version to interpret old data.

BTW, for our beloved Blood Pressure archetype this has just happened. BP is
still the best example for everything :D
http://www.acc.org/latest-in-cardiology/articles/2017/11/08/11/47/mon-5pm-bp-guideline-aha-2017

2018-03-02 9:47 GMT+01:00 Diego Boscá <yamp...@gmail.com>:

> Not sure if I fully understand/agree. As knowledge advances, past data
> could be seen under a new light (e.g. some medication was given to a set of
> patients and now we know it has a contraindication with another medication)
> and we could get different results each time we run the query, which is
> exactly what we want
>
> 2018-03-02 2:55 GMT+01:00 Colin Sutton <colin.sut...@ctc.usyd.edu.au>:
>
>> There is a risk that the external service could provide different answers
>> at different times, if the external service is updated for technical or
>> clinical reasons (e.g. knowledge improvements)
>> Shouldn't the result of the query to the external service be made at the
>> time of the source event, not in AQL.
>> —
>> Colin
>> > On 1 Mar 2018, at 10:31 pm, Bert Verhees <bert.verh...@rosa.nl> wrote:
>> >
>> > On 01-03-18 12:01, Diego Boscá wrote:
>> >> I believe that we need a way in standard AQL to call to arbitrary
>> external services, this seems like another use case for that \
>> >
>> > I agree!
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical@lists.openehr.org
>> > http://scanmail.trustwave.com/?c=13000=oeSX2qbCWwprcB5eNMB
>> 27oRdY2Loky0QJHUrFju91A=http%3a%2f%2flists%2eopenehr%
>> 2eorg%2fmailman%2flistinfo%2fopenehr-technical%5flists%2eopenehr%2eorg
>>
>>
>> 
>> #
>> Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive
>> email content security solution.
>> 
>> #
>>
>> 
>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
>> to be read or used by the named addressee. It is confidential and may
>> contain legally privileged information. No confidentiality or privilege is
>> waived or lost by any mistaken transmission to you. The CTC is not
>> responsible for any unauthorised alterations to this e-mail or attachment
>> to it. Views expressed in this message are those of the individual sender,
>> and are not necessarily the views of the CTC. If you receive this e-mail in
>> error, please immediately delete it and notify the sender. You must not
>> disclose, copy or use any part of this e-mail if you are not the intended
>> recipient.
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, u

Re: Templates for application form development

2018-02-19 Thread David Moner
I was reviewing that work, and I found it cited this reference. This is an
old topic...

H. van der Linden, T. Austin, J. Talmon, Generic screen representations for
future-proof systems, is it possible? There is more to a GUI than meets the
eye, Comput Methods Programs Biomed. 95 (2009) 213–226.
doi:10.1016/j.cmpb.2009.03.003.


2018-02-19 17:37 GMT+01:00 David Moner <dam...@gmail.com>:

> We also have a Final Degree Project where a student made a proposal for a
> Visual Template Model. It's from 2012, for ISO 13606, and also in Spanish,
> but the main idea probably remains the same :-)
>
> I've been always in favor of having a third layer for visualization
> purposes that defines some of the expected behaviors and the visual aspect.
> As Erik said, this is not about reinventing what the existing UI frameworks
> can do, but to have a way of instructing them on how to show the
> information on screen.
>
> 2018-02-18 19:57 GMT+01:00 Pablo Pazos <pablo.pa...@cabolabs.com>:
>
>> I have a pdf spec in Spanish, this was a university project to have
>> platform independent GUI definitions based on opts, while creating
>> technology specific GUI generators for data entry and display. I mentioned
>> this a while ago on the lists but catched not much attention.
>>
>> Need to do a little translation work :)
>>
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote:
>>
>>
>>
>> On 17/02/2018 20:11, Pablo Pazos wrote:
>>
>>> I think SET has a lot of applications, including result sets.
>>> Of course that should interior from LOCATABLE to be archetypable.
>>>
>>> I'm not sure on the types associated with the UI. I have a specification
>>> for UITenplates that includes some of that, I can share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> David Moner Cano
>
> Web: http://www.linkedin.com/in/davidmoner
> Twitter: @davidmoner
> Skype: davidmoner
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

2018-02-19 Thread David Moner
We also have a Final Degree Project where a student made a proposal for a
Visual Template Model. It's from 2012, for ISO 13606, and also in Spanish,
but the main idea probably remains the same :-)

I've been always in favor of having a third layer for visualization
purposes that defines some of the expected behaviors and the visual aspect.
As Erik said, this is not about reinventing what the existing UI frameworks
can do, but to have a way of instructing them on how to show the
information on screen.

2018-02-18 19:57 GMT+01:00 Pablo Pazos <pablo.pa...@cabolabs.com>:

> I have a pdf spec in Spanish, this was a university project to have
> platform independent GUI definitions based on opts, while creating
> technology specific GUI generators for data entry and display. I mentioned
> this a while ago on the lists but catched not much attention.
>
> Need to do a little translation work :)
>
>
> On Feb 18, 2018 7:51 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote:
>
>
>
> On 17/02/2018 20:11, Pablo Pazos wrote:
>
>> I think SET has a lot of applications, including result sets.
>> Of course that should interior from LOCATABLE to be archetypable.
>>
>> I'm not sure on the types associated with the UI. I have a specification
>> for UITenplates that includes some of that, I can share it :)
>>
>>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works, something
> like Balsamiq but with real data connections built in. Marand's EhrExplorer
> does some of this, and it would also be useful to extract some of the
> semantics of that tool into a standard specification to support this kind
> of thing.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
>
>
> _______
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: ELEMENT.null_reason proposal

2017-01-25 Thread David Moner
So, if I understand well, the idea is to add an attribute for representing
clinical reasons for a null flavor, maintaining the current null_flavor for
technical reasons only. Is that right?

2017-01-25 13:34 GMT+01:00 Ian McNicoll <i...@freshehr.com>:

> Hi Diego,
>
> That's a pretty good suggestion, although in that case we are really
> abandoning the idea of the current fixed base set of 'technical'
> null-flavours and allowing them to be replaced by local terms, while I was
> suggesting something more like the ISM_TRANSITION setup where
> archetype-specific 'clinical overlays' can be provided via the archetyped
> careflow_steps but are always associated with the underlying state_machine
> and current_status attribute.
>
> Ian
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> 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 25 January 2017 at 11:54, Diego Boscá <yamp...@gmail.com> wrote:
>
>> If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
>> specialized archetype (directly from an rm class) that has the texts
>> (+ codes) needed in a given country/use case?
>> This probably should work even if set of null_flavour codes is fixed.
>> I don't know if this would be enough, but in theory it provides a
>> workaround for all issues (except the cluster one)
>>
>> 2017-01-25 12:33 GMT+01:00 Thomas Beale <thomas.be...@openehr.org>:
>> >
>> > Silje has just pinged me again on the question of whether we should
>> have an
>> > ELEMENT.null-reason or similar attribute to accommodate specific
>> reasons for
>> > null_flavour being set. There are 3 PRs on this as follows:
>> >
>> > SPECPR-41 - Enable content specific flavours of null to be specified per
>> > archetype
>> > SPECPR-62 - Add a 'reason for null' text attribute in the Reference
>> model
>> > SPECPR-119 - CLUSTER also needs a Null_flavour
>> > SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
>> >
>> > These are all reporting the same problem. (The last one can probably be
>> > closed as a direct duplicate of SPECPR-62). Having re-read the comments
>> on
>> > all, my inclination is to propose the simple addition of an attribute
>> > null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional
>> and
>> > will not invalidate any existing data, but on the downside it will be a
>> data
>> > field that will often be emtpy (i.e. Void, or 'null' in the Java/C
>> sense).
>> >
>> > What would the general reaction to proposing this change be?
>> >
>> > - thomas
>> >
>> >
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical@lists.openehr.org
>> > http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RM Participations name/role?

2016-12-02 Thread David Moner
2016-12-02 14:22 GMT+01:00 Thomas Beale <thomas.be...@openehr.org>:
>
>
> I see the case of Silje from a different perspective. What she is asking
> is if we can document the participants of each Element inside the Entry. So
> far this is not possible, as Entries have been always seen as a whole
> clinical statement, with all participants assigned to that level.
>
>
> From a realist perspective, the phrase 'participants of an Element'
> doesn't completely make sense - an Element is just an atom of information
> that is part of something else. You can only participate in an 'activity'
> (an Activity that has been performed in openEHR is an Action; an activity
> that generates information is usually an Observation, with the protocol
> part indicating how it was done), and to express the activity generally
> takes 1..N Elements in some sort of structure, including timing etc. If two
> different activities are being reported inside the same Entry, there are
> two possible conclusions:
>
>1. it should really be two Entries
>2. they are just considered detailed items within the larger activity
>documented by he Entry.
>
> I think we need to be more careful on the meanings of the primitives in
> the RM - in any RM in fact - they are regularly abused within all RMs I
> see, including CDA, FHIR, even HL7v2. It always seems OK from a human
> perspective, but we say good-bye to computable information when we do that.
>
>
>
That was exactly my point ;-)

I was not advocating for  including participations at the ELEMENT level. On
the contrary, I was remembering that it can only be done at the ENTRY
level.

In the case of Silje, the histopathology findings archetype that can be
found at the CKM is a CLUSTER (
http://www.openehr.org/ckm/#showArchetype_1013.1.2680). So, it is not
possible to add there the participation information to inform about who did
the macro or micro findings as she wanted. The alternative I proposed
without modifying the current RM is, as you also said, to create two
different ENTRYs.

-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RM Participations name/role?

2016-11-24 Thread David Moner
Hi,

I'm not sure if this is a correct approach. What in the example you call a
function can be in fact a full Action that is being done. That is, if the
function is so relevant that you can even assign a dedicated participant to
it, it should be also enough important to be represented and documented as
an individual entry of the EHR: coded, with start and end times, etc. If
the case is that a complex procedure is composed by other simpler
procedures, then we should document and link all of them.

I see the case of Silje from a different perspective. What she is asking is
if we can document the participants of each Element inside the Entry. So
far this is not possible, as Entries have been always seen as a whole
clinical statement, with all participants assigned to that level.

2016-11-23 20:47 GMT+01:00 Ian McNicoll <i...@freshehr.com>:

> Hi both
>
> Agreed.
>
> Role = pathologist
> Function = macroscopic histopath examination.
>
> Ian.
> On Wed, 23 Nov 2016 at 17:32, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>> Hi Silje,
>>
>> The PARTICIPATION class
>> <http://www.openehr.org/releases/RM/latest/docs/common/common.html#_overview_3>
>> has a codable attribute 'function' for this purpose (calling it 'function'
>> rather than 'role' came from 13606). It may be that you want to state a
>> 'role' as well, i.e. to say that a certain *kind of person* is required,
>> and then use function to state the actual function that person is supposed
>> to do in the particular activity in question.
>> I would have expected 'function' to be sufficient for your example - just
>> use 2 x other_participations on the OBSERVATION.
>>
>> An example of needing both could be something like:
>>
>>- role = nurse
>>- function = foley catheterisation
>>
>> Currently 'role' is only known in the demographic model, i.e. on the
>> other side of the PARTY_PROXY.external_ref link. It may make sense to add a
>> role attribute to PARTICIPATION at some point if we need to distinguish the
>> type of person (qualification) from what they do in the activity.
>>
>> - thomas
>>
>> On 23/11/2016 06:29, Bakke, Silje Ljosland wrote:
>>
>> Hi,
>>
>>
>>
>> We’re wondering if it’s possible to specify what the role was of each
>> instance of Participation in an OBSERVATION archetype? For instance in a
>> histopathology result the macroscopic description will often be performed
>> by a different person from the microscopic description. We’re thinking both
>> will be listed using participation, but we need to be able to document
>> which person did what.
>>
>>
>>
>> Kind regards,
>> *Silje Ljosland Bakke*
>>
>>
>>
>> Information Architect, RN
>>
>> Coordinator, National Editorial Board for Archetypes
>> National ICT Norway
>>
>> Tel. +47 40203298
>>
>> Web: http://arketyper.no / Twitter: @arketyper_no
>> <https://twitter.com/arketyper_no>
>>
>>
>>
>>
>> ___
>> openEHR-technical mailing 
>> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: How can I model multiple checkboxs options with terminology?

2016-09-12 Thread David Moner
I'm with Ian, a coded_text with multiple occurrences. Probably the existing
"unique" option in the "items" attribute of the container CLUSTER already
solves the problem of repetitions of the same ELEMENT. It will mean that
you are defining a logical set of ELEMENTs. What I have never had clear
(and I think it is not clear in the specifications either) is if the unique
property means identity or equality, i.e. we cannot have exactly the same
ELEMENT, or we cannot have ELEMENTs with the same value.

Bert, what you propose is probably mixing things from the data structure
definition and from the UI, which is not a good idea for future
maintenance. If we want to render the different options as checkboxes, as a
selection list or whatever other representation lies on the UI side.

2016-09-12 7:49 GMT+02:00 Bert Verhees <bert.verh...@rosa.nl>:

> Op 11-9-2016 om 17:51 schreef Ian McNicoll:
>
>> This leaves the problem of how to exclude non-unique elements as Bert
>> suggested. We have talked in the past about adding a 'unique' keyword to
>> occurences to signfify that repeated identical elements are invalid,
>> however I am struggling to think of any valid clinical use-case where it
>> would be valid to have repeated, non-unique coded_text or text items.
>>
>
> Hi Ian, I think you know Murphy's law. If a bug can happen, it will
> happen. Last years, for developers, the rule is to write code in a way that
> a bug can not occur.
>
> Archetypes are everywhere, as building blocks in templates, they can be
> the base of reports, messages (incoming outgoing), displays.
>
> I think a new datatype, like DVCodedList would be a good idea (a list with
> codephrases, a list which can have attributes like sort (true/false),
> single-select (true/false)) but also a list with no items predefined which
> retrieves its items from code, a list with max-display (for if it gets to
> long), etc. It would be good for integrating SCT, to have such a list
> datatype.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RM in OWL

2016-07-13 Thread David Moner
Hi Seref,

You can ask Jesualdo Fernández-Breis, they have developed model
transformations based on ontologies. They used to have their demo system
running, but it is not working now:
http://sele.inf.um.es:9080/PoseacleConverter/
Yo can find his contact information here: http://webs.um.es/jfernand

David

2016-07-12 18:02 GMT+02:00 Seref Arikan <serefari...@kurumsalteknoloji.com>:

> Greetings,
>
> I was wondering if there is any projects out there that provide an OWL
> version of the RM.
>
> I found this page: http://trajano.us.es/~isabel/EHR/ where an OWL version
> is kindly provided, though I'll need to get in touch with the author to
> clarify the terms and conditions of use.
>
> There are papers out there that use an OWL representation of archetypes
> etc but I could not find any RM representation other than the link above.
> Any pointers would be appreciated.
>
> Cheers
> Seref
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

2016-05-18 Thread David Moner
When we register a coded value, we store the terminology and the code. The
display or rubric of it can be used for example to communicate data to a
system that may not have access to the complete terminology, so that a
human user can understand it. This behavior should not be different for
units. We should not store the readable form of the unit everywhere.


Apart from that, I think that trying to avoid unscientific units should be,
as far as possible, a requirement the modeling activities. FYI:

Spoons lead to inaccurate medicine doses for kids (
http://www.nhs.uk/news/2014/07July/Pages/Spoons-lead-to-inaccurate-medicine-doses-for-kids.aspx
)

-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Ordinal values without descriptions

2016-04-26 Thread David Moner
I will not discuss about the readiness of that particular scale. But un
general words, we are very accustomed to scales where you have to answer
"From 1 to 10, score your satisfaction with the service provided, with 1
meaning 'not satisfied at all' and 10 meaning 'completely satisfied'". I
guess that these kind of scales could also be used for recording some
information in the EHR. In that case, the problem is that the DV_ORDINAL is
not designed for those cases, but to assign a comparable value to
descriptive texts. Maybe in your case, it is not a DV_ORDINAL but a Integer
what you need to represent, and the texts are just hints about the sense of
the score.

2016-04-26 17:50 GMT+02:00 Diego Boscá <yamp...@gmail.com>:

> Technically speaking it is in fact possible to create an alternative
> of two different data types in a given attribute (say for example in
> your use case, DV_ORDINAL (1,low) , DV_COUNT (2), DV_ORDINAL
> (3,medium), DV_COUNT (4), DV_ORDINAL (5,high)).
> In any case I agree with Thomas that this scale probably isn't ready
> to be used yet in a EHR
>
> 2016-04-26 12:59 GMT+02:00 Bakke, Silje Ljosland
> <silje.ljosland.ba...@nasjonalikt.no>:
> > Hi everyone,
> >
> >
> >
> > We’re working on an archetype for the Montgomery-Åsberg Depression Rating
> > Scale (MADRS). This scale contains several ordinal values where there is
> no
> > description, and some where there is no text at all. This doesn’t work
> very
> > well in archetypes, and particularly when uploading to a CKM, because
> > there’s an expectation that every field should be filled in, and the CKM
> > will replace empty fields with * or sometimes *([language code]). Is
> there
> > any way to get around this?
> >
> >
> >
> > See here for what the MADRS looks like:
> http://www.psy-world.com/madrs.htm
> >
> >
> >
> > 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




-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Specialization depth

2015-12-16 Thread David Moner
In AOM/ADL 2 this is not true anymore, so I fear we have lost the only way
to know the specialization depth of an archetype (without navigating
through all its parents).

2015-12-16 10:52 GMT+01:00 Diego Boscá <yamp...@gmail.com>:

> 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 <bert.verh...@rosa.nl>:
> > 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 <bert.verh...@rosa.nl>:
> >>>
> >>> 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
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
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

2015-10-19 Thread David Moner
2015-10-16 3:22 GMT+02:00 Heather Leslie <
heather.les...@oceaninformatics.com>:

> · 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.


-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
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

2015-10-02 Thread David Moner
orway will likely use the new archetype as their national standard,
> diverging from the openEHR CKM content, which is not desired by either
> party.
>
>
>
> A portion of the diff is attached, which demonstrates the major breaking
> changes. There are many other changes that only refer to translations and
> are non-breaking in the rest of the diff
>
>
>
> Major changes are:
>
> · Changing ‘Tilt’ units – ‘°’ to ‘deg’ – at1005 – this is the
> critical and breaking correction that has triggered considering these
> additional changes:
>
> o   Making Measurement Location a choice of coded text and text – at0014
>
> o   Removal the redundant ‘Location’ cluster heading
>
>
>
> This is the first time we have had to update a published archetype and it
> certainly won’t be the last. If there were breaking changes that needed to
> be made for clinical safety reasons or similar critical reasons I would
> have no hesitation in proceeding to v2. If there were non-breaking changes
> we would manage the progression with additional minor revisions or patches
> – not a problem. This one has breaking changes but no clinical safety
> issues, so a bit of a grey zone because of the possible implementation
> implications.
>
>
>
> I have no doubt that many implementers are already grappling with these
> issues if they have implemented draft archetypes, so perhaps you all have
> established systems and approaches for this.
>
>
>
> I have had some advice suggesting we should leave the archetype as is,
> rather than ‘rock the implementation boat’ for little semantic value, yet
> I’m not sure that it is our role to be paternalistic. My own inclinations
> are that we should govern the archetypes from a pure point of view,
> updating and creating new versions if we have to, and allowing CKM to
> provide the transparency that will support implementers to make informed
> choices.
>
>
>
> So:
>
> *Option 1*: Do nothing. The current flawed archetype will be the only one
> available on the openEHR CKM
>
> *Option 2*: Promote the new candidate archetype to the public trunk as a
> potential new iteration – so available for viewing and download, but with
> no official status, effectively in limbo until a further review round is
> carried out and it is republished.
>
> *Option 3*: Promote the new candidate archetype to the public trunk, run
> formal content reviews on it and plan to re-publish as v2
>
>
>
> Please, your thoughts?
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> *Dr Heather Leslie *MBBS FRACGP FACHI
> *Consulting  Lead*, Ocean Informatics <http://www.oceaninformatics.com/>
>
> *Clinical Programme Lead, *openEHR Foundation <http://www.openehr.org/>
> p: +61 418 966 670   skype: heatherleslie   twitter: @omowizard
>
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
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?

2015-10-01 Thread David Moner
Hello,

At this point I think that is the only option. I want to believe that the
SNOMED CT Expression Constraint Language has been designed with a future
evolution of SNOMED CT in mind, where concepts will be enriched with
numerical values. For example, SNOMED CT now contains a set of Virtual
Medical Products (VMP) such as "[374649006] Amoxicillin 400mg/5mL
suspension (product)" with two relationships:
- Has active ingredient →  Amoxicillin
- Has dose form →  Oral suspension
If these relationships are enriched with the medication strength, then the
VMP concepts would be better defined and could be queried using the
numerical options of the constraint language.


2015-09-30 9:20 GMT+02:00 Thomas Beale <thomas.be...@oceaninformatics.com>:

> 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
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
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?

2015-08-28 Thread David Moner
I can't see any problem to the approach you propose.

2015-08-28 15:05 GMT+02:00 Bakke, Silje Ljosland 
silje.ljosland.ba...@nasjonalikt.no:

 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

 Tel. +47 40203298

 Web: http://arketyper.no / Twitter: @arketyper_no
 https://twitter.com/arketyper_no



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

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




-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

New paper: Archetype-based data warehouse environment

2015-06-19 Thread David Moner
Dear all,

My colleagues Luis Marco-Ruiz, José A. Maldonado, Nils Kolstrup, Johan G.
Bellika and myself have just published a paper titled Archetype-based data
warehouse environment to enable the reuse of electronic health record data
in the International Journal of Medical Informatics. I think this work can
be of interest for many of you.

Best regards,
David

Link: http://www.sciencedirect.com/science/article/pii/S1386505615300058

Abstract:

- Background. The reuse of data captured during health care delivery is
essential to satisfy the demands of clinical research and clinical decision
support systems. A main barrier for the reuse is the existence of legacy
formats of data and the high granularity of it when stored in an electronic
health record (EHR) system. Thus, we need mechanisms to standardize,
aggregate, and query data concealed in the EHRs, to allow their reuse
whenever they are needed.
- Objective. To create a data warehouse infrastructure using
archetype-based technologies, standards and query languages to enable the
interoperability needed for data reuse.
- Materials and methods. The work presented makes use of best of breed
archetype-based data transformation and storage technologies to create a
workflow for the modeling, extraction, transformation and load of EHR
proprietary data into standardized data repositories. We converted legacy
data and performed patient-centered aggregations via archetype-based
transformations. Later, specific purpose aggregations were performed at a
query level for particular use cases.
- Results. Laboratory test results of a population of 230,000 patients
belonging to Troms and Finnmark counties in Norway requested between
January 2013 and November 2014 have been standardized. Test records
normalization has been performed by defining transformation and aggregation
functions between the laboratory records and an archetype. These mappings
were used to automatically generate open EHR compliant data. These data
were loaded into an archetype-based data warehouse. Once loaded, we defined
indicators linked to the data in the warehouse to monitor test activity of
Salmonella and Pertussis using the archetype query language.
- Discussion. Archetype-based standards and technologies can be used to
create a data warehouse environment that enables data from EHR systems to
be reused in clinical research and decision support systems. With this
approach, existing EHR data becomes available in a standardized and
interoperable format, thus opening a world of possibilities toward semantic
or concept-based reuse, query and communication of clinical data.


-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
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

2015-06-11 Thread David Moner
I would not do so. This is not an automatic process, this first phase is
just a way of filtering proposals. For sure the people in StackExchange
will evaluate each proposal in detail, and if they find that votes and
questions are clearly addressed or governed the proposal won't be accepted.

2015-06-11 17:41 GMT+02:00 Seref Arikan serefari...@kurumsalteknoloji.com:

 Thanks, can someone write a comment (shamelessly in capitals..)  under the
 highest voted (16 the moment) question asking visitors to NOT to vote for
 questions with  10 votes? My user can't do it for some reason.

 There are ~19 wasted points that could have been used on other questions
 a.t.m and people will just arrive and keep upvoting the top 5 ones. (This
 is a weird design; if  10 votes do not help, why let users vote beyond 10
 at that stage?)

 On Thu, Jun 11, 2015 at 4:12 PM, Cavero Barca, Carlos 
 carlos.cav...@atos.net wrote:

 Done! 90 followers :)

 Regards.
 Carlos.

 -Original Message-
 From: openEHR-technical [mailto:
 openehr-technical-boun...@lists.openehr.org] On Behalf Of Arild Faxvaag
 Sent: Thursday, June 11, 2015 3:46 PM
 To: For openEHR technical discussions
 Subject: Re: openEHR @ StackExchange - getting close

 done signing up and upvoting.

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

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive this
 e-mail in error, please notify the sender immediately and destroy it.
 As its integrity cannot be secured on the Internet, the Atos group
 liability cannot be triggered for the message content. Although the sender
 endeavors to maintain a computer virus-free network, the sender does not
 warrant that this transmission is virus-free and will not be liable for any
 damages resulting from any virus transmitted.

 Este mensaje y los ficheros adjuntos pueden contener información
 confidencial destinada solamente a la(s) persona(s) mencionadas
 anteriormente y pueden estar protegidos por secreto profesional.
 Si usted recibe este correo electrónico por error, gracias por informar
 inmediatamente al remitente y destruir el mensaje.
 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no
 se hace responsable por su contenido. Su contenido no constituye ningún
 compromiso para el grupo Atos, salvo ratificación escrita por ambas partes.
 Aunque se esfuerza al máximo por mantener su red libre de virus, el
 emisor no puede garantizar nada al respecto y no será responsable de
 cualesquiera daños que puedan resultar de una transmisión de virus.
 ___
 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org

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



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

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




-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

ACTION just as event trigger

2015-04-07 Thread David Moner
Hi Pablo,

Think that an ACTION can happen without any previous instruction. For
example, a medication taken without a previous prescription. That
information has to be stored not just as a log, but as proper clinical
data. So it seems OK that ACTION includes part of the clinical record.

David

2015-04-07 4:06 GMT+02:00 pazospablo at hotmail.com pazospablo at hotmail.com:

  A couple of week ago someone mebtioned that ACTION archetypes are not
 being developed or used a lot, and maybe is because we actually don't need
 to put data on ACTIONs as part of the clinical record, but maybe only as
 event trigger and logs of ehat happened. With tgis I mean: ACTION recording
 might be used ti send notifications to other statems (like whe a lab test
 is done, the results are sent or queried), or to keep the log of real world
 events that happened and may change the status of another entity (i.e.
 INSTRUCTION/ACTIVITY).


 What is the opinion of the community about the role of the ACTION ENTRY in
 the openEHR Information Model and as a EHR entity, from the point of view
 of it's use in current systems?


 Thanks,

 Pablo.


 Sent from my LG Mobile

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150407/ce19dbcd/attachment.html


ACTION just as event trigger

2015-04-07 Thread David Moner
The recommendation is to always use the same archetypes you would have used
to originally record that information. That is the best way to ensure the
systems work when retrieving information. For example if you query about
medications taken by the patient you only have to query the ACTION
archetype instead of searching information scattered in other archetypes.

David


2015-04-07 11:19 GMT+02:00 pazospablo at hotmail.com pazospablo at 
hotmail.com:

  Hi David. A medication taken should be an action or an observation? What
 matters more, the event of taking the drug ot yhat thr drug eas taken? I
 think the latter can occur when a doctor asks the patient for medication
 taken. I agree the real time record of the event can also occur.


 Thanks!


 Sent from my LG Mobile

 -- Original message--

 *From: *David Moner

 *Date: *Tue, Apr 7, 2015 03:41

 *To: *For openEHR clinical discussions;

 *Cc: *openehr-technical at lists.openehr.org;

 *Subject:*Re: ACTION just as event trigger
 Hi Pablo,

 Think that an ACTION can happen without any previous instruction. For
 example, a medication taken without a previous prescription. That
 information has to be stored not just as a log, but as proper clinical
 data. So it seems OK that ACTION includes part of the clinical record.

 David

 2015-04-07 4:06 GMT+02:00 pazospablo at hotmail.com pazospablo at 
 hotmail.com:

 A couple of week ago someone mebtioned that ACTION archetypes are not
 being developed or used a lot, and maybe is because we actually don't need
 to put data on ACTIONs as part of the clinical record, but maybe only as
 event trigger and logs of ehat happened. With tgis I mean: ACTION recording
 might be used ti send notifications to other statems (like whe a lab test
 is done, the results are sent or queried), or to keep the log of real world
 events that happened and may change the status of another entity (i.e.
 INSTRUCTION/ACTIVITY).


 What is the opinion of the community about the role of the ACTION ENTRY
 in the openEHR Information Model and as a EHR entity, from the point of
 view of it's use in current systems?


 Thanks,

 Pablo.


 Sent from my LG Mobile

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

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




 --
 David Moner Cano
 Grupo de Inform?tica Biom?dica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es
 http://www.linkedin.com/in/davidmoner

 Universidad Polit?cnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
 Valencia - 46022 (Espa?a)




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150407/91703620/attachment-0001.html


[openEHR-announce] Extension of nominations 31 Jan 2015 - and join up now.

2015-01-12 Thread David Moner
  find the openEHR board nomination process a bit confusing and pretty
  different to what I am used to in other community settings. When
 joining
  as an openEHR individual member you first have to wait until your
  application has been approved, this might be logical in some ways, but
 it
  means you will need to remember to get back to the member site some days
  later and then do your nominations (a nomination dropout risk). Also
 you
  can not even view nominations without logging in. After logging in I did
  not find any list of members possible to nominate, but after navigating
  around a while I found these four nominations: - Bosca Tomas, Diego -
  McNicoll, Ian - Bakke, Silje Ljosland - Kobayashi, Shinji I guess
 these
  nice persons were nominated by individual members, I did not find any
  information regarding if industry members have nominated any
 candidates.
  I did not find any information regarding if any of the current board
  members are considered already nominated or not (I guess not, since Ian
 is
  on the current board and has been nominated separately). The strangest
  thing, unless I misunderstood the submission form: The form is rigged
  primarily to nominate yourself, and it is optional to Include name in
 list
  of event registrants - does that mean that there may be people secretly
  nominated? Very strange at least from a Swedish
 community/NGO/volunteer-org
  perspective. I would like to nominate Thomas Beale for example, can I
 do
  that? By replacing my own name that is pre-filled in the form I guess
 it is
  possible to nominate someone else but it is far from obvious from
  form-texts regarding your nomination etc. In the community settings
 I
  am used to, the nominations are open so that any member can nominate any
  member, then the nominated persons are asked if they would accept a
  nomination or not, then there is a vote among the remaining nominated
  persons. I would suggest some changes - Listing all current
 nominations
  (including from both industry and individual members) without login
  requirement - Allowing at least logged in members to see who else is a
  member (so that we know who can be nominated and can encourage people to
  become members if they are not listed) - Making it possible to nominate
  other people than yourself - Clarifying if anybody not on the visible
  nomination list is considered to be nominated - Send out nomination
  reminders regularly (perhaps including a list of the then nominated
  persons) Best regards, Erik Sundvall Ph.D. Medical Informatics.
  Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in
 Sweden)
  Li?: erik.sundvall at regionostergotland.se (lio.se changing name 1 Jan
 2015)
  LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ On Tue, Dec
 23,
  2014 at 12:58 AM,  wrote: Happy Xmas everybody, Thank you to the
 new
  members and Industry Partners that have joined up so far. We have three
  nominations for the Management Board at this stage. Two of the
 companies
  have asked for an extension for the joining date to allow transition to
  the new Calendar year. The Board considered their request at the last
  Board meeting and agreed. Consequently the closure date for nominations
  has been extended to the 31 Jan 2015. Please join up by going to
  http://members.openehr.org We need a broad and representative group to
  vote for the Management Board. Your involvement is crucial. The funds
 also
  help us with the provision of some of the fundamentals (web site, CKM
  etc). Have a great break over Xmas but make sure you contribute to
 the
  MedInfo workshops by the middle of January. Keep an eye on the lists
 for
  details. Looking forward to working with you all in 2015! Cheers,
  Sam Dr Sam Heard Chairman, openEHR Foundation
  ___ openEHR-announce
 mailing
  list openEHR-announce at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-announce_lists.openehr.org
 
  ___ openEHR-clinical mailing
  list openEHR-clinical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org___openEHR-technical
  mailing
  listopenEHR-technical at lists.openehr.orghttp://
 lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino

archetype UIDs

2014-11-18 Thread David Moner
Hi,

I was not aware of this addition. It is clear that having these UIDs it
will be simpler to check if the archetype has changed, as you say. But is
it also the intention of these UIDs to be used to fill the archetype_id
attributes in the RM instances? Or the link between the instance and an
specific archetype will be done using the traditional archetype
identifier+version+revision+build? Moreover, if now we will have unique
identifiers with version+revision+build, why do we need an additional UID?

David

2014-11-17 14:44 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:


 We are finalising the last details of the ADL 2/AOM 2 specifications for a
 Trial release. One detail is the question of UIDs. The current AOM 2
 specification shows two UIDs: provenance_id and instance_id. The former is
 created at archetype creation and never updated, even with major archetype
 version changes, meaning that it can always be used to track an archetype,
 including all versions and copies, through time.

 The latter is updated every time anything at all changes with the
 archetype.

 *The question here is: should these two ids be mandatory in ADL 2?  *I
 believe they should, since they enable tooling to track archetypes and
 archetype changes properly. Previously, when the specs where identified as
 ADL 1.5, we had them as optional, for reasons of backwards compatibility,
 but having moved to ADL 2, we no longer have this requirement.

 - thomas

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/f0d8c45d/attachment.html


archetype UIDs

2014-11-18 Thread David Moner
I can see the point now. I couldn't understand the benefits of the new UID
attributes.
It is OK if they become mandatory in 2.0. We just have to have clear rules
to know when a new instance_id has to be created.

2014-11-18 14:31 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:

  On 18/11/2014 12:50, David Moner wrote:

  Hi,

  I was not aware of this addition. It is clear that having these UIDs it
 will be simpler to check if the archetype has changed, as you say. But is
 it also the intention of these UIDs to be used to fill the archetype_id
 attributes in the RM instances? Or the link between the instance and an
 specific archetype will be done using the traditional archetype
 identifier+version+revision+build? Moreover, if now we will have unique
 identifiers with version+revision+build, why do we need an additional UID?

  David


 Hi David,

 Personally I don't think UIDs are needed; checking if an archetype has
 changed is easier to do with an MD5. UIDs are mostly a distraction.

 But some people and more particularly governments like them. So if we
 include them in the AOM, then I guess they have to work. So making them
 optional won't work - because they can't be generated from anything, you
 have to 'have them' which means they have to have been created at the right
 point in time, usually by the creator or modifier of some artefact.

 I don't see any utility in mixing UIDs into the human-readable ID (HRID)
 either in models or in data. They aren't shorter, and you can't infer
 anything from them as you can with the HRID, and noone who needs to inspect
 data (as inescapably happens routinely in integration development work) can
 easily work with UIDs. So their utility is largely imaginary in my view.
 But not everyone agrees with that

 - thomas

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/923c120a/attachment.html


Another meta-data requirement from CIMI

2014-11-13 Thread David Moner
We can't assume that an approved/published Intermountain model (to say
something) automatically becomes a published archetype either. So we have a
problem here. Which should be the default life cycle state of an
auto-generated archetype?

2014-11-13 19:41 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:

  On 13/11/2014 18:37, David Moner wrote:

 I don't think so, but maybe we could use the release_candidate state,
 instead the draft one that I mentioned.


 well I think either could be correct, depending on the circumstances. E.g.
 the latest openEHR/FHIR joint Adverse reaction archetype might go in at
 'release_candidate', but many other openEHR ones wouldn't. Even archetypes
 that are 'published' according to us could easily go in as drafts, since it
 may be that CIMI is the first environment where a really wide group of
 reviewers looks at it (and inevitably changes it).

 So.. I don't see any clear rules just yet ;-)

 - thomas

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/41d806b1/attachment.html


ADL 1.4 migration roadmap - a start

2014-11-07 Thread David Moner
Hello Thomas and thank you very much for pushing this. As we talked early
this year, I think this interim or transitory versions are the way to go
before 2.0 is complete.
Personally, and regarding EN ISO 13606, I also think it is the best option
for the current renewal process to adopt only small changes that solve
limitations or problems of 1.4, and leave the adoption of 2.0 for the next
renewal process, once 2.0 has been fully tested through implementations and
supported by the industry.

Regarding the contents of each version, we have to study it in detail, but
probably the philosophy could be:
- 1.5: changes that only affect the parser and maybe need adding some
support classes to the AOM, but that can afterwards be ignored by systems
(e.g. annotations, generated marker, maybe the namespace, ...)
- 1.6: changes that would require that the new edited archetypes have to be
exported to 1.4 format to work normally (e.g. change domain types to
tuples, absence of existence and cardinality or the differential
specialization)
- 1.7: changes that would affect how systems use the archetypes (e.g.
unification with templates)

Maybe the 1.7 directly corresponds to 2.0...

David


2014-11-07 13:01 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:


 I have started an ADL 1.4 migration roadmap page
 http://www.openehr.org/wiki/display/ADL/ADL+1.4+Migration+Roadmap. This
 currently consists of a list of all changes made from 1.4 = 2.0 (as it now
 is), with an idea of which retrospective interim version (i.e. 1.5, 1.6,
 1.7 etc) the change could go in. Although this isn't the way things are
 normally done, there is one major advantage: the way things are working now
 in ADL/AOM 2 are pretty good and have been re-engineered a few times over
 the ADL '1.5' journey. Putting the final version into these retrospective
 releases should mean a smoother ride from 1.4.

 Who does this affect? Firstly, everyone with 1.4-based tools, openEHR
 implementations and AQL queries. Secondly, the ISO 13606 revision process -
 these interim versions are likely to be the best roadmap to new versions of
 AOM in ISO 13606, if that revision proceeds.

 The initial work I have done is to try to include a row for each ADL/AOM 2
 change, and assign an interim version like '1.5', '1.6' etc to it. I made
 some suggestions as to what the interim releases could be:

- 1.5 - quick wins
- 1.6  - tuples; remove openEHR special C_DV_QUANTITY etc types
- 1.7 - differential archetypes and templates

 But these are there to be broken.

 I have also included some impact headings on the right side of the table.

 All of this needs the relevant members of the community to look at it; I
 won't be spending much time on it personally, other than to help people
 understand the technical side of ADL/AOM 2 and what effects it has on
 specific things.

 Hopefully this is a useful starting point.

 - thomas

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141107/4d79fe26/attachment.html


Defining multiple constraint bindings in AOM/ADL 1.4

2014-10-31 Thread David Moner
I will explain it in another way.

ac codes are used as placeholder constraints, i.e. a kind of link to
a query or subset in a terminological systems that defines the possible
instance values of a coded attribute.

My question was: Is it needed to be always a link to a subset? Cannot we
use ac to define bindings to specific terminological codes explicitly
enumerated, without the need of defining a subset in the terminological
system in advance?

2014-10-30 20:05 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com:


 Hi David,

 well the very direct answer is: ADL 1.4 is ... a bit limited;-)

 your last example section:

 constraint_bindings = 
  [BI98] = 
  items = 
  [ac0001] = terminology:BI98?code=
 [ac0001] = terminology:BI98?code=
  
  
 


 would not even be allowed in ADL 2. Now, we have to ask why something like
 the above could exist. Presumably there has to be some distinguishing
 feature of the two mappings, otherwise how does tooling and systems know
 what to choose. One concept that has been brought up in the past is the
 idea of mapping codes and value sets differently for different uses of the
 same terminology, e.g. GP v nursing. Maybe something like:

 constraint_bindings = 
  [snomedct] = 
  [nursing] = 
  [ac0001] = http://snomed.info/id/ http://snomed.info/id/
  [ac0002] = http://snomed.info/id/ http://snomed.info/id/
  
  [general practice] = 
 [ac0001] = http://snomed.info/id=/
 http://snomed.info/id=/
   [ac0002] = http://snomed.info/id/ http://snomed.info/id/
  
  
 

 The syntax might be different. There are all kinds of questions here. E.g.
 maybe you want the binding to snomedct to be mostly the same for all
 purposes, but just a bit different for some.  See the ac0002 code above -
 it's mapped to the same thing in each case. Maybe we want something more
 like:

 constraint_bindings = 
  [snomedct] = 
  [ac0002] = http://snomed.info/id/ http://snomed.info/id/
  
  [snomedct/nursing] = 
 [ac0001] = http://snomed.info/id/
 http://snomed.info/id/
   
  [snomedct/general practice] = 
 [ac0001] = http://snomed.info/id=/
 http://snomed.info/id=/
  
 

 It's easy to imagine a lot of other similar ideas. So far I have never
 seen a solid statement of requirements on this need. Can you provide some
 more background on the need you have? It's not out of the question to get
 it into the soon-to-be-finalised ADL2, but we'd need something pretty clear
 to go on.

 Secondly, your statement:
 Isn't it reasonable to allow defining coded value sets explicitly at the
 archetype level (specially in cases where maybe we only have to define two
 or three codes)?

 I assume you mean the internal code-set construct i.e.
  [local::
  at0001,
  at0002]

 which can of course have 1:1 code:concept bindings for each at-code. But
 you know that, so I probably don't understand what you are really asking...

 - thomas


 On 30/10/2014 11:54, David Moner wrote:

 Hello,

  A very direct question: Why it is not possible to define multiple
 constraint bindings for the same archetype node and the same terminology in
 AOM/ADL 1.4? I know in AOM/ADL 2.0 the management of these constraints
 change completely, but the following is the situation (limitation?) in
 existing 1.4.

  For a given textual node, it is possible to define multiple term
 definitions (at codes), for example:

  DV_CODED_TEXT matches {
  defining_code matches {
  [local::
  at0001,
  at0002]
  }
 }

  term_definitions = 
  [en] = 
  items = 
  [at0001] = 
  text = X
  description = *
  
  [at0002] = 
  text = Y
  description = *
  
  
  
 


  However, it is not possible to define the same using constraint bindings
 (ac codes). More precisely, it is only possible to do it if each code
 pertains to a different terminology. For example, the following example
 would be valid:

  DV_CODED_TEXT matches {
  defining_code matches {[ac0001]}
 }

  constraint_definitions = 
  [en] = 
  items = 
  [ac0001] = 
  text = New constraint
  description = *
  
  
  
 

  constraint_bindings = 
  [BI98] = 
  items = 
  [ac0001] = terminology:BI98?code=
  
  
  [AIR93] = 
  items = 
  [ac0001] = terminology:AIR93?code=
  
  
 


  But not the following one, the ADL parser and the openEHR Archetype
 Editor do not even accept it:

  DV_CODED_TEXT matches {
  defining_code matches {[ac0001]}
 }

  constraint_definitions = 
  [en] = 
  items = 
  [ac0001] = 
  text = New constraint
  description = *
  
  
  
 

  constraint_bindings = 
  [BI98] = 
  items = 
  [ac0001] = terminology:BI98?code=
 [ac0001] = terminology:BI98?code=
  
  
 


  Is it mandatory to use predefined subsets to define a coded value set
 with multiple values in a constraint binging?
 Isn't it reasonable to allow defining coded value sets explicitly at the
 archetype level (specially

Any prep for MIE 2015 in Madrid?

2014-10-31 Thread David Moner
Hello Koray,

The EN 13606 Association is organizing its General Assembly to take place
in parallel to MIE 2015. It is always open to the general public, so anyone
interested can be informed of the activities of the Association.
We are also preparing a proposal for a workshop about professional
certification in EN ISO 13606 which is a topic of interest for many people.

Everything will be announced in a timely manner through our communication
channels:
http://www.en13606.org
https://twitter.com/en13606
http://groups.google.com/group/en13606


David

2014-10-31 3:47 GMT+01:00 Koray Atalag k.atalag at auckland.ac.nz:

  Hi, I was just wondering if there's any activity planned for MIE 2015
 http://www.mie2015.es/ in next May - the deadline for submissions has
 just been extended:



 *Deadline for Papers and Posters (indexed)  is extended to November 17th,
 2014*
 *Deadline for Workshops, Panels, Special events (nonindexed) proposals is
 December 1st.*



 If nothing I guess there will be some individual participations - I'm
 keen to attend and coordinate things.



 Cheers,



 -koray



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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141031/e1d5b165/attachment.html


Defining multiple constraint bindings in AOM/ADL 1.4

2014-10-30 Thread David Moner
Hello,

A very direct question: Why it is not possible to define multiple
constraint bindings for the same archetype node and the same terminology in
AOM/ADL 1.4? I know in AOM/ADL 2.0 the management of these constraints
change completely, but the following is the situation (limitation?) in
existing 1.4.

For a given textual node, it is possible to define multiple term
definitions (at codes), for example:

DV_CODED_TEXT matches {
defining_code matches {
[local::
at0001,
at0002]
}
}

term_definitions = 
[en] = 
items = 
[at0001] = 
text = X
description = *

[at0002] = 
text = Y
description = *






However, it is not possible to define the same using constraint bindings
(ac codes). More precisely, it is only possible to do it if each code
pertains to a different terminology. For example, the following example
would be valid:

DV_CODED_TEXT matches {
defining_code matches {[ac0001]}
}

constraint_definitions = 
[en] = 
items = 
[ac0001] = 
text = New constraint
description = *





constraint_bindings = 
[BI98] = 
items = 
[ac0001] = terminology:BI98?code=


[AIR93] = 
items = 
[ac0001] = terminology:AIR93?code=





But not the following one, the ADL parser and the openEHR Archetype Editor
do not even accept it:

DV_CODED_TEXT matches {
defining_code matches {[ac0001]}
}

constraint_definitions = 
[en] = 
items = 
[ac0001] = 
text = New constraint
description = *





constraint_bindings = 
[BI98] = 
items = 
[ac0001] = terminology:BI98?code=
[ac0001] = terminology:BI98?code=





Is it mandatory to use predefined subsets to define a coded value set with
multiple values in a constraint binging?
Isn't it reasonable to allow defining coded value sets explicitly at the
archetype level (specially in cases where maybe we only have to define two
or three codes)?
It would be a simple but very convenient patch to add to AOM/ADL 1.4+
before 2.0.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141030/cebfff48/attachment.html


Licensing of specs and artifacts

2014-10-02 Thread David Moner
 40203298




 ___
 openEHR-technical mailing listopenEHR-technical at 
 lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/0b423b40/attachment.html


Licensing of specs and artifacts

2014-10-02 Thread David Moner
2014-10-02 10:03 GMT+02:00 Thomas Beale thomas.beale at oceaninformatics.com:



 I think the key things to remember in resolving this are how the various
 artefacts get used, which helps figure where 'adaptation' actually exists.
 I can think of the following:

- archetype = template = software application
   - the simplest standard practice
   - this is USE not ADAPTATION
- archetype = specialise = template = software application
 - the next simplest standard practice
   - this is USE not ADAPTATION
- archetype = software application
   - not a great idea in general - it means that the 'archetypes' are
   not really maximal re-usable data sets, but something like predefined
   templates. However, someone is bound to do this, and produce a good 
 product
   from it.
   - this is USE not ADAPTATION
- archetype = forking = modification = templating = software
application
 - Result: probably non-interoperable data; but may occur for
   pragmatic reasons, e.g. openEHR is too slow to make fixes to the 
 archetype.
   - this is ADAPTATION

 According to the CC-BY-SA 4.0 licence text only the last of these paths
 means that the final software or other result is an 'adaptation' of the
 original archetype, which means that the CC-BY-SA license applies, IF YOU
 PUBLICLY SHARE THE ARTEFACT.



Just to be clear, I repeat that that is exactly what I would like to
interpret. But if I read the legal texts trying to be objective (and again,
not being a lawyer!) it is normal that doubts arise. If I generate a
validation software that includes validation rules from the archetype
constraints, that is arguably an adaptation, not just a use.

And it is also important to note that if you sell a software you are also
publicly sharing it. Publicly share does not imply for free, but outside of
a personal use.

I fully support the comments of Grahame. Probably the solution is to go
just for the simpler option and don't worry about what others do with their
own business.


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/b357fa49/attachment.html


Archetype Naming proposals - do we need V0?

2014-10-01 Thread David Moner
2014-10-01 15:35 GMT+02:00 Sebastian Iancu sebastian at code24.nl:

  Dear all,

 I'm surprise to see such a low analysis of the impact of changing v1 to v0
 of the existing CKM archetypes.
 Even though they are not 'published', or are in logical 'draft' mode, they
 were conformant to openEHR standards for at least past 5 years or so. Some
 of them are used already in production environments for more than 2-3 years
 (at least in our case).
 Changing them now on CKM will break logical binding with already existing
 production data. This cost has to be eventually supported by industry
 implementers, and I can assure you this is not trivial, and it is giving
 the impression that openEHR standard is not reliable/stable enough.


Sebastian,

Although you are for sure right  in your worries, that doesn't mean that
current archetypes managed in CKM are safer. For many years most of the
current v1 archetypes in CKM where in draft and that meant that they have
been changing without changing their id. You can protect your systems if
you check archetype correspondences not only by the archetype id but using
something else such as their hash code. And in that case, changing to v0
should not mean any difference or additional problem.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fc487bf9/attachment.html


Path in use_node

2013-09-05 Thread David Moner
At the first use_node reference you have to add the target node_id at0007.
You don't have to repeat the items container attribute at the path, which
is substituted by attribute3, but the target node id has to be used if it
is not redefined by a new one, as in the case of attribute4[at0005]

[archetype_id]/attribute3[at0007]/**items[at0008]/value/value


2013/9/5 Bert Verhees bert.verhees at rosa.nl

  On 09/05/2013 09:38 AM, Diego Bosc? wrote:

 II would say that you just have to attach the remaining path from target
 node to the use_node path, so I would say first option is the right one


 That seems to me the most logical too.

 Thanks, Diego!

 Bert





  2013/9/5 Bert Verhees bert.verhees at rosa.nl

 Hi All,

 We had a discussion about data-pointds being identified by
 archetype-path, not  archetypenode-id.
 I agree with that, but I am a bit confused how to do following.

 consider following fantasy archetype

 --

 Entry[at] matches {-- Encounter
 attribute1 matches {
 SECTION[at0003] occurrences matches {0..1} matches {
 items  cardinality matches {0..*} matches {
 ITEM_LIST[at0007] occurrences matches {0..1} matches {
 items existence matches {0..1} cardinality
 matches {0..*; unordered; unique} matches {
 ELEMENT[at0008] occurrences matches {0..1}
 matches {
 value matches {
 DV_TEXT occurrences matches {1..1}
 matches {
 value matches {/abc/}
 }
 }
 }
 }
 }
 }
 }
 }
 attribute3 matches {
 use_node ITEM_LIST /attribute1[at0003]/items[at0007]
 }
 attribute4 matches {
 use_node ITEM_LIST[at0005] /attribute1[at0003]/items[at0007]
 }

 --

 Now I want to know the path in the three ways to the data-point of value
 of DV_TEXT

 Which one is right, or are all wrong?

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0008]/value/value
 [archetype_id]/attribute4[at0005]/items[at0008]/value/value

 or we have this (repeat the targetpath also in the path to the data-point)

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute4[at0005]/items[at0007]/items[at0008]/value/value

 or is it like this (repeat the complete path of the targetpath)

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value

 [archetype_id]/attribute3/attribute1[at0003]/items[at0007]/items[at0008]/value/value

 [archetype_id]/attribute4[at0005]/attribute1[at0003]/items[at0007]/items[at0008]/value/value

 Thanks very much

 Bert



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

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




 ___
 openEHR-technical mailing listopenEHR-technical at 
 lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130905/07c37bfd/attachment-0001.html


Polishing node identifier (at-codes) use cases.

2013-09-03 Thread David Moner
2013/9/2 Thomas Beale thomas.beale at oceaninformatics.com

  On 02/09/2013 08:49, David Moner wrote:




 2013/9/2 Thomas Beale thomas.beale at oceaninformatics.com


  Well, LinkEHR is a real implementation in use by several organizations,
 and we think these identifiers are needed both technically and
 methodologically, so we will continue our way of doing thing :-)


  To be clear, I didn't mean modelling tools, I meant production EHR
 systems that use the resulting models.


  Of course, me too:
 http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239


 Yep, I know about that (the more systems the better!). But I would be
 interested to know what the clinical models look like - are they posted
 anywhere? And what is the clinical modelling process? I would think after a
 few years of it, there would be some ideas on which nodes need to be
 defined and which don't? I'm just trying to get some evidence here, so we
 can better understand the right set of rules to use in the formalism and
 its tooling.



I have uploaded some archetypes to
http://www.en13606.org/resources/files/cat_view/67-sample-archetypes

They correspond to the ISO EN 13606 archetypes of the Patient Summary
document of the Fuenlabrada Hospital. They are only in Spanish. They are
mainly based on openEHR archetypes from the CKM, but also enriched with
some information from NEHTA specifications and from the Spanish law for
clinical documentation.

[image: Im?genes integradas 1]



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130903/1440cf21/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93093 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130903/1440cf21/attachment-0001.png


Polishing node identifier (at-codes) use cases.

2013-09-02 Thread David Moner
2013/8/30 Thomas Beale thomas.beale at oceaninformatics.com


 You are probably right. I think for the moment I would like to get ADL/AOM
 1.5 completed (more or less) with the current assumptions, at least until
 we can obtain some more evidence (particularly from vendor companies with
 actual production implementations) and modellers whose archetypes are
 deployed for real, that would show that we need to change the current
 status quo. Call me conservative, but I don't like changing things without
 real world justification!


Well, LinkEHR is a real implementation in use by several organizations, and
we think these identifiers are needed both technically and
methodologically, so we will continue our way of doing thing :-)


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130902/eb052dc8/attachment.html


Polishing node identifier (at-codes) use cases.

2013-09-02 Thread David Moner
2013/9/2 Thomas Beale thomas.beale at oceaninformatics.com


  Well, LinkEHR is a real implementation in use by several organizations,
 and we think these identifiers are needed both technically and
 methodologically, so we will continue our way of doing thing :-)


 To be clear, I didn't mean modelling tools, I meant production EHR systems
 that use the resulting models.


Of course, me too:
http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239



 I'm still not really clear on the rules that LinkEHR uses to decide when
 at-codes are not defined in the archetype ontology section.


The rules are:
- Every archetype node always has an explicit unique identifier. We use the
at codes to do so, to minimize the impact with current ADL.
- The archetype authors decide, during the definition and review process,
which nodes need or have a description or terminology binding due to
clinical reasons.



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130902/7273ebf9/attachment.html


Polishing node identifier (at-codes) use cases.

2013-08-30 Thread David Moner
2013/8/29 Thomas Beale thomas.beale at oceaninformatics.com


 well the idea here has always been, and remains justified today:

- an archetype-local definition in words for the meaning of the node
is needed, because this says _exactly_ what the designers intended
- those meanings are given by domain experts, and (with some review,
QA process) will be as good as any linguistic definition in any ontology or
terminology (probably better, because they are specific to the case at 
 hand)
 - if we are lucky enough to find some code that matches, or
approximately describes the same thing in an ontology and/or SNOMED CT /
LOINC etc, then we can add those bindings

 If we were only allowed to define nodes for which matching codes can be
 found in OBO, SNOMED or other supposedly reliable places, then we would
 have no chance of building anything but the most meagre archetypes, and no
 ability to build semantically enabled health information systems.

 I don't know of any facts that would contradict this long-standing
 position today...


I'm not contradicting those positions, which I agree, I'm just saying that
this is a very subjective topic, dependant on the context of use, the
availability of some resources (e.g terminological codes) and many other
factors. So, we can all do our best but it will be very difficult to have
rules that guide which nodes of the archetype have to be identified just
based on a structural matter (the rules you asked for).

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130830/e72e674d/attachment-0001.html


Polishing node identifier (at-codes) use cases.

2013-08-29 Thread David Moner
2013/8/28 Thomas Beale thomas.beale at oceaninformatics.com

  On 28/08/2013 10:07, David Moner wrote:




  No, currently all at codes are also found at the ontology in
 LinkEHR, even if they are empty, to be compatible with the  VATDF2 check,
 although we would like to avoid it :-)

  In my opinion we talk of two different levels of meaning. One is the
 explicit meaning, where the definition of the node is defined through a
 natural text or a terminology binding and that is, of course, the needed
 for a complete semantic interoperability. The other is the implicit
 meaning, when you create e.g. an OBSERVATION with occurrences {1..1} you
 are creating An OBSERVATION that only happens once. That means something
 (otherwise you wouldn't have defined that constraint), even if you cannot
 give it a natural name or a terminology code. And if it means something, it
 shall have an identifier.


 David, I am not totally clear on what you mean. OBSERVATION is a class
 that always has an at-code on it anyway, because it is a high-level class
 and needs its clinical meaning defined anyway. If you impose {1..1} on it,
 you will do that via a SECTION or COMPOSITION slot.




I know that the openEHR archetype editor only allows introducing
OBSERVATIONs and the other clinical classes through a slot at the
COMPOSITION and SECTION, and probably that is a good methodological
approach or good practice to improve archetype governance, but technically
it is not the only possibility. You can create an archetype from the top
COMPOSITION to the leaf data values in one single archetype. And in any
case, it is just an example, we can use MY_CLASS_NAME or whatever to avoid
thinking this is a problem about how things work at the openEHR reference
model.



  I don't think a clinical modeller would have to mind about these
 aspects. He/she creates an archetype node (internally, a unique at code
 is created). He/she optionally gives it a name or defines a terminology
 binding (internally the ontology structures are created). When the
 archetype is used or processed, the systems will only use the information
 they have available.


 Ok, but if tools have no rules, then we can end up with an archetype like
 this:

 OBSERVATION matches {
 data matches {
 HISTORY matches {
 
 }
 }
 }


 with no meaning on anything. What is to prevent that?


To be exact, in our approach all those classes should have an at code,
even if it is not described at the ontology section. But in any case,
current at rules does not force to put a description with a sense
either, except for the root node because it corresponds to the same concept
as the archetype identifier when you create the archetype. It is more a
duty of the clinical validation team to check those kind of things, not
something that can be automatically validated by rules. Look at the
following brand new archetype created with the openEHR editor, just
choosing an OBSERVATION root:

definition
OBSERVATION[at] matches { -- Test example
data matches {
 HISTORY[at0001] matches { -- Event Series
events cardinality matches {1..*; unordered} matches {
 EVENT[at0002] occurrences matches {0..1} matches { -- Any event
data matches {
 ITEM_TREE[at0003] matches {*}
}
}
 }
}
}
}

ontology
term_definitions = 
[es] = 
items = 
 [at] = 
text = Test example
description = unknown
 
[at0001] = 
text = Event Series
 description = @ internal @

[at0002] = 
 text = Any event
description = *

 [at0003] = 
text = Tree
description = @ internal @
 





The only meaning there is the Test example name of the OBSERVATION,
because it corresponds to the archetype name. But all the others have no
meaning and no existing rules are checking that (having Event series,
Any event and Tree is the same as not saying anything). So, again,
those ontological descriptions will be always checked by the authors, not
by the tools.

By the way, following the specifications, even that example archetype
created with the openEHR editor is not perfect. Both the at0001 and the
at0003 codes should not be needed according to the rules, since they are
members of single value attributes without sibling nodes...



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/aad85b12/attachment-0001.html


Polishing node identifier (at-codes) use cases.

2013-08-29 Thread David Moner
2013/8/28 Gerard Freriks gfrer at luna.nl

 David,

 Can I summarise it for my understanding as:
 - AT codes are pointers to an 'ontology'.
 - AT codes can be considered symbols that represent a particular
 concept
 - The 'ontology' provides a name that will be used to display the name of
 a node (concept) in an archetype.


I will stop at this point because I think it is the kernel of the
discussion. Which should be the idea?
- The ontology must provide a name or meaning for each at node in an
archetype? This is how thing are supposed to work in current specifications
- The ontology can provide a name or meaning for each at node in an
archetype? This is how we think it should be, the ontology provides a
semantic description only when it is needed or it is possible.

And what is providing a meaning or semantic description?
- A terminology binding? Of course, we will rely on terminologies and
ontologies for a complete semantic interoperability.
- A natural language description? Well, here is where no automatic rules
can exist to check if a description such as Systolic blood pressure or
This is a PQ type node or The sky is blue or   are correct or have a
sense, only a human validation check can work here.

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/e8f03d7d/attachment.html


Polishing node identifier (at-codes) use cases.

2013-08-28 Thread David Moner
2013/8/27 Thomas Beale thomas.beale at oceaninformatics.com



 What is so wrong about having at-codes in every class of the archetype
 with no ontology definition for that code?


 interesting question - so far (10 years!) we have always treated an
 at-code as something that is in the ontology. At the moment no tools at all
 would handle the assumption that only some codes had definitions; it would
 raise questions: how do you know which things need definitions and which
 don't? My guess is that there would need to be a special definition that is
 connected to the at-codes you want to have no definitions, which would
 complicate the archetype ontology section structure.

 - thomas



I'll try to summarize the origin of the different views we have regarding
this topic and maybe this can be also useful to see why this is not just a
configuration problem of the tools.

We can find the explanation of node identifiers in two places (I use the
latest drafts, I think):
- In AOM 1.5 specifications, page 47: Semantic identifier of this node,
used to distinguish sibling nodes of the same type. [Previously called
?meaning?]. Each node_id must be defined in the archetype ontology as a
term code.
- In ADL 1.5 specifications, page 26: In cADL, an entity in brackets of
the form [at] following a type name is used to identify an object node,
i.e. a node constraint delimiting a set of instances of the type as defined
by the reference model. and  A Node identifier is required for any object
node that is intended to be addressable elsewhere in the same archetype, in
a specialised child archetype, or in the runtime data and which would
otherwise be ambiguous due to sibling object nodes

The definition in AOM is the one followed by the openEHR editor, i.e. a
node identifier or at code is just a pointer to the ontology section
and a mechanism to distinguish sibling nodes. Thus, wherever it is not
needed, the tool does not introduce that code in order not to dirty the
ontology section.

The  first part of the definition in ADL is the one followed in LinkEHR
and, in our opinion, more correct formally. When you introduce an archetype
constraint for a C_OBJECT you are in fact creating a definition of a type
(a sub-type of the more generic type defined by the reference model class)
that will be used to create a subset of instances. We have to distinguish
this sub-type from the RM type, and since the class name cannot be changed,
the only solution is to use the at as type identifier. In other words,
our interpretation is that at codes are unique identifiers of each type
defined in the archetype, that may be also used to link to the ontology
section, but that is the optional part. In fact, the only exception to this
would be when you create constraints using a path, because then you are
just navigating through the RM but do not change the meaning of the
intermediate classes.

The logic of the tools and the validation checks of archetypes are built
based on those interpretations. I agree with Bert in one thing: tools
shouldn't change things without notifications, but in this case we face a
methodological difference, not just a configuration one, and that's why it
is not easy to be solved.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/a5af394a/attachment.html


Polishing node identifier (at-codes) use cases.

2013-08-28 Thread David Moner
2013/8/28 Thomas Beale thomas.beale at oceaninformatics.com



 Does LinkEHR actually do this? I.e. only some at-codes are found in the
 ontology? Your statement above (bolded) is right in theory (or at least
 that's the way I see it), but then the obvious question is: if I mutate the
 type (say) ENTRY to ENTRY[at0123], what does ENTRY[at0123] mean? In general
 we want to equate that with a meaning of some kind (like 'ENTRY' has a
 meaning). Remember, we could have done something like 'ENTRY[admission]' or
 'ENTRY[bp_measurement]' but we don't do that because we want the meanings
 to be multi-lingual (one day the 'ENTRY' bit should be as well...). So we
 use term codes.

 So if we agree that 'mostly' we want those meanings defined, then the
 question is: which places doesn't it matter? I would say: places where it's
 obvious, like ELEMENT.value: DV_TEXT. My view has always been that we would
 avoid at-codes in locations where the meaning is obvious (principally for
 single-valued attributes, where the archetype meaning is the same as the RM
 meaning). The other reason for that is to limit the length of paths for
 Xpath processing. Unnecessary codes can double the length of some paths.



No, currently all at codes are also found at the ontology in LinkEHR,
even if they are empty, to be compatible with the  VATDF2 check, although
we would like to avoid it :-)

In my opinion we talk of two different levels of meaning. One is the
explicit meaning, where the definition of the node is defined through a
natural text or a terminology binding and that is, of course, the needed
for a complete semantic interoperability. The other is the implicit
meaning, when you create e.g. an OBSERVATION with occurrences {1..1} you
are creating An OBSERVATION that only happens once. That means something
(otherwise you wouldn't have defined that constraint), even if you cannot
give it a natural name or a terminology code. And if it means something, it
shall have an identifier.




 If we go the other way, then we are saying: at-codes are 100% mandatory
 everywhere, but definitions for them are optional. Then we need some rules
 on when it is optional and when mandatory. What rules would you propose for
 that? Remembering that a clinical modeller absolutely relies on those rules
 for understanding the archetype?



I don't think a clinical modeller would have to mind about these aspects.
He/she creates an archetype node (internally, a unique at code is
created). He/she optionally gives it a name or defines a terminology
binding (internally the ontology structures are created). When the
archetype is used or processed, the systems will only use the information
they have available.



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/c3a581e6/attachment.html


Archetype meta-data - moving foward

2013-05-06 Thread David Moner
I have added a license attribute. An archetype can need both a copyright
and the applicable license.

David


2013/5/3 Thomas Beale thomas.beale at oceaninformatics.com

  On 03/05/2013 11:28, Diego Bosc? wrote:

 By the way, we should use the momentum to also revamp the available
 metadata. A few ideas:

 - Move 'copyright' from language specific information to general
 metadata (It's not being really translated at the moment).
 - Move 'references' from other_details to general metadata (It's
 important enough IMHO).
 - Information about date of validation, validity time and who validated it.
 - RM version this archetype was based on.
 - etc.



 Personally I would agree with all of the above. I have already added the
 rm_release to the ARCHETYPE class now in the AOM (not yet pushed up), but
 for the others, I suggest we try to create a wider discussion to do this
 exercise with a small amount of discipline, but still be in a
 crowd-sourcing mode (is that possible ;-)

 To that end, I added a child page to the Knowledge Artefact
 Identification 
 pagehttp://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts,
 herehttp://www.openehr.org/wiki/display/spec/Knowledge+Artefact+Meta-data,
 dedicated to meta-data. I added some tables where we can potentially review
 the current model and propose changes. If people think this isn't
 sufficiently detailed, feel free to rework it in another way.

 - thomas


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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130506/a190fa03/attachment.html


About openEHR BMM

2013-05-02 Thread David Moner
Hi,



 If we see the multi-axial identifier not as a fixed string, but a computed
 output from a bunch of identifying meta-data, as per the recent knowledge
 identification proposal 
 updatehttp://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts,
 then we should consider adding the rm_release to these items. Then it is
 just a case of defining a function that includes it in one of (possibly
 many) ids. I didn't think to include it in this draft, but we can do that.

 I still don't believe it's useful in the primary multi-axial ontological
 identifier, because there is no certain computational relationship between
 an archetype and a given release of the RM. Some archetypes will be valid
 for many releases, others for only one. But having it in the archetype
 meta-data is a good idea, because that nails down at least the release at
 which the archetype was created. Then it can be interrogated by some sort
 of compatibility testing tools.

 David, can I suggest you add a comment in the feedback table on that page,
 so I don't forget to do this.


Exactly, that was one of the original ideas, at least add that RM version
information at the archetype header. As you say, that only indicates the
version used to create the archetype and not the compatibility with other
versions of the RM (forward or backward). That could be even added also as
metadata: rm_compatibility = openEHR-RM_1.0.0, openEHR-RM_1.0.1
Since we can have all the RM versions loaded at the tools it should be
quite easy to check the validity towards all of them automatically.



  you probably should also report a relevant summary of these points on the
 CIMI list and/or to Michael van der Zel so he can fix his generator.


I wasn't aware that the CIMI BMM was automatically generated by Michael,
that explains many of the cases. I'll contact him.




  - Need of visualization information. There are two properties defined
 related to visualization of the model. The
 archetype_data_value_parent_class property is defined at the documentation
 as a base class from the Reference Model whose descendants are considered
 to be 'logical data types [...] is only used to help tooling provide more
 intelligent display. The archetype_visualise_descendants_of property is
 used to designate a class whose descendants should be made visible in tree
 and grid renderings of the archetype definition. In order to repeat some
 of the problems of existing model representation, such as XMI, we should
 avoid polluting the pure RM definition from visualization or user-oriented
 metainformation. At the end that only complicates the BMM format. The
 representation of that metainformation should not be part of the BMM
 requirements.


 I do agree that in general XMI suffers from this, I am not sure if I agree
 that the above items are a big problem in BMM at a practical level (in XMI
 land, the graphical stuff can be all over the place and is complex). But in
 any case, they could be made to disappear from the .bmm files with the use
 of 'archetype repository profile' (.arp) files or maybe some other future
 alternative. At the moment I am not sure if it is worth the trouble until
 we have a proper concept of ARPs. Dave Carlson wants to use these to store
 some general meta-data for models, but noone has really agreed on what is
 required.



For me those visualization characteristics are more about preferences of
each tool/user. So it's fine for me to separate them in a different place,
where they can be modified without changing the model itself, whose
definition should remain immutable.

That, said, I must say that we are not big fans of BMM :-)
While we agree that current alternatives (i.e XMI) are not usable in
practice nowadays, we find extremely improbable that BMM gains big
acceptance outside the openEHR world. I doubt that we ever see the HL7 CDA
model expressed in BMM for example. So we decided to support it as another
option, but we still hope that the industry finds a way to agree on a
common usable format for defining models.

David



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/17abd27a/attachment-0001.html


About openEHR BMM

2013-05-02 Thread David Moner
There is plenty of people working on this, mostly from the semantic point
of view.

Apart from the works in CIMI, I must point to our colleagues at the
University of Murcia that have been working for years in reference model
conversions using semantic web technologies:
http://webs.um.es/jfernand/miwiki/doku.php?id=projects:poseacle_gen

POSEACLE converter: http://miuras.inf.um.es:9080/PoseacleConverter/




2013/5/2 pablo pazos pazospablo at hotmail.com

 Great!

 BTW, it will be really useful to have multi-model tools.

 I was thinking if multi-model apps could be also useful, e.g. to have
 different persistent structures. My guess is that app can implement one
 canonical model (e.g. openEHR RM) and then map to other models e.g. for
 instance transformation and output purposes.

 My idea: what do you think about creating some kind of mapping language,
 to specify correspondences between BMM models? (e.g. using semantic
 mappings/relationships to tell if one class in model A is equivalent/more
 generic/more specific/... to other class in model B).

 There are many kinds of semantic correspondence between models, e.g. a
 class in one model can map to a property in another model, etc...

 The idea behind that is that using the mapping information and an input
 instance schema (in the canonical model), and maybe some input or
 cursomization from the user/designer, a complete transformation definition
 can be created, so automatic transformation from an instance in the
 canonical model to some output model (13606, CDA, ...) can be done.

 Is this idea to crazy or do you think it can be useful to have something
 like that?
 Anyone is working on something like that?

 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/homehttp://twitter.com/ppazos

 --
 Date: Wed, 1 May 2013 16:07:08 +0100

 From: thomas.beale at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: About openEHR BMM

 On 01/05/2013 14:48, pablo pazos wrote:

 Hi Thomas, having a small spec would be great, thanks!

  BTW, does anyone use XML representation of UML diagrams to process class
 models?


 wait time = 5 days

 - thomas


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

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

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




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/59641c13/attachment.html


About openEHR BMM

2013-05-02 Thread David Moner
Hi Bert


 I have a problem with both archetype-editors, I explained a few times on
 this list why.
 Both change archetypes while loading them, f.e. one likes to add node-id's
 to datavalues, and the other does not like that.
 There are some more incompatibilities, between the both. I forgot the
 details.
 Then one is not able to create demographic archetypes, also a problem.




I remember that list of problems, and some of them can be resolved and it
is our fault not to have resolved some of them yet.
But there are others that are not so easy to address since they are related
to the basic internal philosophy of the tool, such use adding an id to
every node.

We'll try tu publish an updated version of the editor sooner than later.

David



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130502/9c341cd1/attachment.html


About openEHR BMM

2013-04-30 Thread David Moner
Hello all,

We have just implemented the support of Basic Meta Model files (BMM) in
LinkEHR Editor as a format to import new reference models into the tool.

First of all, I think that it is necessary to clarify some erroneous ideas
or misunderstandings about LinkEHR that have been recently published. Until
now, LinkEHR used XML Schema as an input format to define reference models.
It is analyzed to create the internal information structures needed to edit
archetypes based in that model. Internally, LinkEHR follows a pure
implementation of the AOM 1.4 model so that the only limits of the tool are
what can be expressed as an archetype.

The decision to support XML Schema as an input format is based on the fact
that many reference models are only or normatively expressed in that way
(for example HL7 CDA, HL7 CCD or CDISC ODM). This has nothing to do with
the discussion about the expressiveness of the XML Schema language, but
just a solution needed to support some daily used and
well established models such as CDA.

That said, we decided to implement the support of BMM definitions as an
additional input format to XML Schema, in order to extend the possibilities
of the tool. That implementation took around three days and the only
problems came from the interpretation of the BMM format. Some doubts arose
and we want to share them for discussion.

- Schema identification. This is just a curiosity. The BMM identification
includes the following information. It is curious that here the RM release
is required as part of the identification schema (which is completely
logical), but it is not used for the generation of the archetype identifier
or archetype header to make its localization safer, as we have requested
some time in the past (
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005943.html
).
rm_publisher = openehr
schema_name = rm
rm_release = 1.0.2

- Order of the properties. It is not specified if there is an order of
appearance of all reserved words and sections of the BMM. Depending on
this, the implementation strategy of the parser varies. Is the order
relevant? We assumed that it is relevant for the header sections, but it is
not at the definition of the classes.

- Cardinality property of Single attributes. Testing the CIMI BMM we have
found several places where a P_BMM_SINGLE_PROPERTY had a cardinality
property defined. We interpreted that as an error, since a monovalued
attribute has no cardinality.

- Is_abstract as string. Also at the CIMI model we found several
definitions as is_abstract = True. We interpreted it as an error since
it should be a boolean value without double quotes.

- Definition of generic properties. They are defined by using the
P_BMM_GENERIC_PROPERTY reserved word. What it is not clear is if those
properties can be SINGLE or CONTAINER ones. In other words, is it possible
to define a container attribute(with its cardinality) of the type
GENERIC_PROPERTY?

- Generic_parameters property of P_BMM_GENERIC_PROPERTY should be a list.
Since a generic class can be defined to support one or more parameters, the
generic_parameters used when that class is called should be defined as a
list of strings. Currently, all examples define it as a single string value.

- Need of visualization information. There are two properties defined
related to visualization of the model. The
archetype_data_value_parent_class property is defined at the documentation
as a base class from the Reference Model whose descendants are considered
to be 'logical data types [...] is only used to help tooling provide more
intelligent display. The archetype_visualise_descendants_of property is
used to designate a class whose descendants should be made visible in tree
and grid renderings of the archetype definition. In order to repeat some
of the problems of existing model representation, such as XMI, we should
avoid polluting the pure RM definition from visualization or user-oriented
metainformation. At the end that only complicates the BMM format. The
representation of that metainformation should not be part of the BMM
requirements.


We have uploaded the JavaCC specification of the BMM grammar to the openEHR
wiki: http://www.openehr.org/wiki/display/dev/BMM+grammar+and+parsers
Feel free to use or modify it.

David



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130430/e6d695a4/attachment.html


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

2012-09-13 Thread David Moner
Hi,

2012/9/13 Erik Sundvall erik.sundvall at liu.se

 It would be great if e.g most of the future ISO 13606 version could be a
 true subset of openEHR instead of the current confusing situation.


This is something I discussed with Thomas some time ago, it would be one of
the best harmonisation solutions, but probably with a slightly different
interpretation. Since 13606 has more generic classes (eg. the generic ENTRY
can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead
of 13606 being a subset of openEHR I think that openEHR should be a
specialized model of 13606. Obviously this would require a deep analysis
and changes of the models, but that could be the idea.

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120913/3286ef2d/attachment.html


EN 13606 renewal activities

2012-08-02 Thread David Moner
Dear all,

The CEN/ISO 13606 EHR-communication standard is starting the process for
its renewal. Several activities have been held and will be organised in
order to support this process:
? The EN 13606 Association has held a enquiry with implementors of the
13606 all over the world, including persons from openEHR. A survey has been
published: http://www.en13606.org/activities/general-assembly-2012
? During the CEN/ISO working group meetings held in Vancouver it was
decided to start a New Work Item Proposal (NWIP) as first step.
? The EN 13606 Association promoted a meeting in London (UCL) to discuss
this NWIP and action lines with some key players active in CEN and ISO from
the UK, Sweden, Norway, Spain and the Netherlands.
? During the MIE2012 conference by the end of August in Pisa, the EN 13606
Association will organise two workshops and a training course. We invite
you to attend and participate in the discussions about the renewal of the
CEN/ISO 13606 standard.

*Workshop 1: 13606, what is it and how will it be renewed (1.5 hours, date
to be confirmed)*
? What is the 13606 for?
? What are its 5 parts?
? Deployment experiences: Who is using it, for what purpose?
? Why a new version?
? Who will be involved?
? How can you be involved?
? What is the formal CEN/ISO process?

*Workshop 2: Topics for renewal of the 13606 EHR-communication standard
(1.5 hours, date to be confirmed)*
? Which will be the renewal scope?
? Lessons learned from using the standard
? Harmonisation with HL7 CDA?
? Harmonisation with openEHR?
? Harmonisation with standard: System of Concepts for Continuity of Care?
? Harmonisation with standard: Health Information Services Architecture?
? Extension with SIAMS: How to model archetypes?

*EN 13606 training (15 hours, 25th and 26th of August)*
A 2-day course about the 13606 norm will be done the weekend before MIE. It
will include a deep description of the standard, the archetype development
process and practical exercises to learn how to use it. You can download
the details of the course from:
http://www.mie2012.it/documents/EN13606trainingcourse.pdf


You are all welcome to participate in any of these activities.

Best regards,

David Moner
Secretary of the EN 13606 Association


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120802/df13977f/attachment.html


maybe weak point in Archetype-specification

2012-06-25 Thread David Moner
I agree that this is not a reasonable behaviour any more, the archetype
identifier could be just the default name proposal, but that's all.

David

2012/6/24 Bert Verhees bert.verhees at rosa.nl

 Please consider following.

 I think it is a weak point to have a file which contains an archetype
 having the same name as the archetype-id.
 This policy is enforced by as well the OCEAN-editor as the LinkEHR editor
 (however the latter has a bug in this).

 I don't know if it is officially specified. But the disadvantage is that
 information is stored twice in the same file (in the contents and in the
 filename), this can cause problems, ambiguities.

 Also, it is unnecessary restrictive, it is impossible to store more
 archetypes in one text-file.

 Many programming languages have the same restriction, but often the have
 also workarounds for this restriction.

 regards
 Bert Verhees

 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120625/6f57362d/attachment.html


DV_ORDINAL C_DV_ORDINAL

2012-06-25 Thread David Moner
Dear Bert,

See in-line comments

2012/6/24 Bert Verhees bert.verhees at rosa.nl


 - The LinkEHR-editor does not accept OCEAN-editor constructs as
 C_DV_QUANTITY, and thus, does not allow multiple constraints on a
 DV_QUANTITY


As I explained before, LinkEHR does accept those constructs. The only
limitation is that you cannot edit them graphically (but you can do it in
ADL view) or transform them to standard structures.

[image: Im?genes integradas 1]


- The LinkEHR editor silently adds NodeID's on DataValues as the archetype
 does not have them.
 **


I agree that the tool should not add those node_Ids if they did not exist.
We will take a look to this.



 - The LinkEHR creates per default the line: terminologies_available =
 ... which is not accepted by the Ocean-Editor


This is part of the ADL 1.4 (and 1.5) specifications:
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf

8.6.2 Ontology Header Statements
The terminologies_available statement includes the identifiers of all
terminologies for which term_bindings sections have been written.

Maybe what it is not clear at the specs is if that line have to be added if
no terminologies have been defined or only when you have at least one. That
line can be removed very easily in that case.




 A warning comes up, that the archetype_id does dif from the filename.
 The LinkEHR editor offers three choices:
 - Save (ignore warning)
 - change the ID to the filename
 - change the file name to the id
 The first two options do the same, this is unexpected and is a bug.


As I said in another mail, this can probably be removed since it is not
really necessary.

Thank you for all your comments Bert. It can seem obvious, but it
is difficult to improve tools if we do not receive comments about them.

Regards,
David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120625/2eee3a6e/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: LinkEHR-DomainType.gif
Type: image/gif
Size: 32260 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120625/2eee3a6e/attachment-0001.gif


DV_ORDINAL C_DV_ORDINAL

2012-06-25 Thread David Moner
Hi Bert,


2012/6/25 Bert Verhees bert.verhees at rosa.nl



 Hi David, is it possible that the Expand Domain Type is only in the paid
 version? I don't have it in my free version. But maybe I am wrong, but I
 cannot check it now. I am in the wrong room/wrong computer. I will check it
 later.



It should be available at the free version of the webpage. Although I see
that it is bit old one and we should update it :-)





  - The LinkEHR creates per default the line: terminologies_available =
 ... which is not accepted by the Ocean-Editor


  This is part of the ADL 1.4 (and 1.5) specifications:
 http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf

  8.6.2 Ontology Header Statements
 The terminologies_available statement includes the identifiers of all
 terminologies for which term_bindings sections have been written.

  Maybe what it is not clear at the specs is if that line have to be added
 if no terminologies have been defined or only when you have at least one.
 That line can be removed very easily in that case.


 The problem, I already said, I was not sure if it was to blame to the
 OCEAN or the LinkEHR editor. The problem is that the Ocean editor gives a
 vague error message pointing to line-number later.
 The problem is, if you remove it, every time you save the archetype it is
 added again.

 It should not be the purpose of arcehtype-editors to rework archetypes in
 text-editors. I can do that, I have seen enough archetypes. But I know many
 people who can't, but they also have to do it.


Yes, I meant to avoid generating that line when it is not needed, not
removing it by hand.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120625/95bc53e6/attachment-0001.html


DV_ORDINAL C_DV_ORDINAL

2012-06-24 Thread David Moner
 this (it is under the NodeID
 from the parent ELEMENT)
 [at0004] = 
description = *
a1 = een
text = New element
a2 = twee
 
 -
 Both methods are in compatible to each other. Both archetype-editors do
 not open each others archetypes.

 This is very inconvenient.

 Another difference:
 The LinkEHR editor offers a NodeID on the DataValue inside the ELEMENT,
 giving the opportunity to give the data-value another description (in the
 term-definitions) then the ELEMENT has.
 The OCEAN does not offer this, but also does not accept archetypes made by
 the LinkEHR editor
 Even the most simple archetype created by the LinkEHR editor cannot be
 opened by the OCEAN editor.

 Like this snippet:
 definition
EVALUATION[at] occurrences matches {1..1} matches {  -- sda
data existence matches {1..1} matches {
ITEM_TREE[at0001] occurrences matches {0..1} matches {  --
 ITEM_TREE
items existence matches {0..1} cardinality matches {0..*;
 unordered; unique} matches {
ELEMENT[at0002] occurrences matches {0..*} matches {
  -- ELEMENT
value existence matches {0..1} matches {
DV_TEXT[at0003] occurrences matches {0..1}
 matches {*}  -- DV_TEXT
}
}
}
}
}
}

 ontology
terminologies_available = ...
term_definitions = 
[en-us] = 
items = 
[at] = 
text = sda
description = sda
 
[at0001] = 
text = ITEM_TREE
description = This is a ITEM_TREE object
 
[at0002] = 
text = ELEMENT
description = This is a ELEMENT object
 
[at0003] = 
text = DV_TEXT
description = This is a DV_TEXT object
 
 
 
 





 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/12ac978f/attachment-0001.html


Archetype authoring attribution

2012-03-23 Thread David Moner
Hello,
See in-line.

2012/3/22 Sam Heard sam.heard at oceaninformatics.com

 Hi David

 ** **

 As the aim for all is interoperability of these things, I would hope that
 the information would be two way. I would suggest getting the new experts
 to comment on CKM and then derive a 13606 archetype (this is described in
 the 13606 standard). I would like that to be a future part of CKM but
 understand this may seem a little too controlling.

 ** **

 If we start creating clinical content specifications in lots of places it
 will not really assist medicine a great deal. We estimate that it is
 costing health care dearly to do this again, again and again. Particularly
 when providers are interested in quality and sharing information.

 **


Of course, sharing these models is the only way to achieve global
agreements I do not know which kind of changed they would require for the
archetypes (if any) but I think they will be related to the real data
available at the EHR system of the hospital. So they will be probably very
localized changes. What clinicians have done right now is to translate most
of the archetypes into Spanish, and that can be very easily incorporate
into the openEHR CKM archetypes.


 **

 That said, I would attribute the work to openEHR, the original authors,
 contributors and any new expert inputs. The license is to openEHR so I
 guess it is openEHR that needs attributing if you want to stay with the
 legal requirement. The SA does mean that you have to share the derived work
 under a similar license, something that some have been worried about. I am
 interested in your views on this.

 ** **

 Cheers, Sam

 **


There is no doubt about the attributions and original references that must
accompany the new archetypes (by the way, maybe in this sense the archetype
metadata could be improved. Diego Bosc? has been working on this topic for
his PhD). The question as I said before is about the authorship attribution
and the meaning of derived work. See below.




2012/3/23 Thomas Beale thomas.beale at oceaninformatics.com


 if it is the same archetype, then it is a derived work. Which is fine,
 that's what CC-BY is for. My understanding of the term is that a machine
 conversion to another format (which is essentially what you are saying)
 would be a derived work - legally not different from JPG - PNG I suspect.

 - thomas



Probably the problem is not so simple. I will put different options of
things that can happen as an example  (any new case is welcome):

1- If I take an openEHR archetype and modify/specialize it as a new openEHR
archetype it is a derived work.
2- If I take an openEHR archetype and generate an implementation guide
document of it, it is a derived work. The change of the format does not
affect as you said.
3- If I take an openEHR archetype and generate software, schemas, etc. as
Thomas said in a different thread they are not derivative works, they are
original works based on the specification
4- If I take an openEHR archetype and generate another archetype of a
different reference model based on it (could be 13606, HL7 CDA or
whatever), is this a derivative work? The fact that the openEHR to 13606
conversion is nearly straightforward is not relevant here. It could be not
the case. At the end someone (or some automatic process) will have to
decide the correspondence between different reference models. For me this
is exactly the same case as point 3. Thus, should not be considered a
derivation but a new work which uses the original archetype as a reference,
as could have been any textbook or paper.
5- If I take an openEHR archetype and generate an HL7 CDA implementation
guide based on it, is this a derivative work? The answer to this depends on
the previous one. The fact of representing clinical models in a different
format (if we see ADL just as a format for defining models) should not
change the essence of the problem as we saw in point 2.

See that I'm just trying to set out the limits of the problem to find a
general rule if it is possible.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/44753655/attachment.html


Mandatory description at Term_definition

2012-03-22 Thread David Moner
Hi,

At the Term_definition section of the ADL specifications (1.4 and 1.5), we
can read that Each term is defined using a structure of name/value pairs,
and must at least include the names ?text? and ?description?, which are
akin to the usual rubric, and full definition found in terminologies like
SNOMED-CT.

Although being in essence true, we can find examples where de description
part is not needed. For example, at
the openEHR-EHR-OBSERVATION.lab_test-histopathology.v1, we can see:

[at0074] = 
text = Aborted
description = *


The * is the default value inserted by the archetype editor. Shouldn't
have more sense to make description a not mandatory field? For very simple
data items probably it will not be needed. This also applies to the
constraint_definition that follows the same structure.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/f9dbff24/attachment.html


Archetype authoring attribution

2012-03-22 Thread David Moner
Hello,

Back again with the licensing topic of archetypes, with a real use case.

We have been asked to help in creating a set of 13606 archetypes for breast
and prostate cancer. Although they will probably incorporate some new
requirements, the main source will be some of the openEHR archetypes
available at the CKM.
Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which
is the state of that discussion), the doubts are the following:

- Converting the archetype to a new reference model is considered as a
derivation? Or the openEHR archetype is considered just as a reference
material as could be any textbook or paper?
- The author of the new archetype has to be the one of the openEHR
archetype (Ian McNicoll btw) or the person who in fact creates the new
RM-based archetype?

The underlying question here that should be clarified is to define which is
the extension of the concept derived work.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/1d3b44b5/attachment.html


Suggestion to replace use of generics with inheritence in future RM versions

2012-03-22 Thread David Moner
2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com

 Instead, I think we should re-invigorate the Java Implementation
 Technology Spec, that Rong wrote originally some years ago, to provide Java
 implementation guidance for issues like this. All target implementation
 technologies have their issues; if we keep hacking the primary specfication
 model to suit all of them, we will no longer have any clear statement at
 all of what we really wanted in the first place, and it would in any case
 probably be a very weak model, once you accommodate no generics, no
 multiple inheritance, no typing, !



I was exaclty thinking about this while seeing this proposal for the
ITEM_STRUCTURE change to a VALUE_CLUSTER:

http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes


It is an example of multiple inheritance not supported by Java and some
other languages. I agree with you that a programming language limitation
cannot be imposed to a good model design, but it is also true that for
example Java is not a minor language to forget of. There should be a
balance between what it is perfectly modelled and what can be implemented
by most.


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/35ce4106/attachment.html


Building software to convert HL7 v2/v3 messaging into archetypes templates

2012-02-09 Thread David Moner
Hello,

Here at the Technical University of Valencia, we have been developing
LinkEHR (www.linkehr.com) for the last six years and it seems to be exactly
what you are looking for. LinkEHR Studio has two main functionalities:
- It is a generic archetype editor, able of working with any reference
model you import into it. We have worked with archetypes for
openEHR, EN13606, HL7 CDA, CDISC ODM, MML and many others.
- It is a data transformation tool based on archetypes. You can use an
archetype and map it to a data source, defining the appropriate
transformation functions and rules. Then the tools automatically generates
an XQuery to transform existing XML data instances into XML extracts that
follow the archetype and reference model rules.

Although we have not worked directly with HL7 v2.x messages, it should be
possible to work with them in their XML representation version. You just
have to choose or define an archetype as target schema, import the HL7 XML
message schema as source, and define the correspondences between those two.
We have generated CDA documents based on this methodology, so v2.X messages
should be even easier to manage.

Contact us if you have any question.

Best regards,
David


2012/2/3 Chang, Wo L. wchang at nist.gov

 Dear All,

 ** **

 I hope this is the right reflector?.

 ** **

 First of all, thanks to those who developed tools, prepared tutorials,
 etc.!!

 I have spending the last few days playing around with the followings:

 **? **Java Reference Implementation of openEHR

 **? **LiU-Archtype-Editor-0.5.2

 **? **Archtype Editor 2.2.779

 **? **ADL 1.5 Workbench beta

 **? **Template Designer 2.6.1213.3

 **? **Etc.

 Along with reading very good tutorials on:

 **? **Intro to openEHR, Sam Heard

 **? **Knowledge-enabled approach to eHealth records, Heather
 Leslie

 **? **Using Archtypes with HL7 Messages and Clinical Documents,
 Health Frankel

 **? **EN 13606-2 Gello ? DCM, Andrew McIntyre

 **? **Etc.

 And openEHR stable specifications on:

 **? **Introducing openEHR

 **? **Architecture Overview

 **? **Etc.

 And ISO 13606 Part-1 and Part-2.

 ** **

 I truly believe the archtype/template would be the right approach for my
 project on long-term management and preservation of EHRs.  The Java ref.
 implementation libraries, Archtype Editor, Template Designer are great
 utils/tools.

 ** **

 My basic question is: are there any public tools available to allow me to
 covert HL7 v2/v3 messaging to/from archtypes/templates as described in
 Health Frankel?s tutorial on ?Using Archtypes with HL7 Messages and
 Clinical Documents??

 ** **

 I know there is deep learning curve and would very much appreciated for
 any pointers.

 ** **

 Thanks in advance for any help!

 ** **

 --Wo

 ** **

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120209/5982c777/attachment.html


pass_through attribute in ADL 1.5

2012-01-26 Thread David Moner
In fact, the emphasis attribute of 13606 is a CV.

2012/1/26 Diego Bosc? yampeku at gmail.com

 but they won't show everything on a 'full' GUI either. Maybe what is
 needed is not only a boolean but a way to tell exactly the criteria
 with different values of a controlled vocabulary, such as 'mandatory',
 'recommended', 'passable'/'skippable'...

 2012/1/26 David Moner damoca at gmail.com:
  Following this new sense for it, I think that the implications for a GUI
 or
  visual representation would depend on a decision of the implementers. If
 the
  screen space is reduced, they could opt for just showing the clinically
  relevant data and leave the rest for a second screen, a pop-up or
 something
  like that.
 
 
  2012/1/25 Diego Bosc? yampeku at gmail.com
 
  Would this attribute value change depending on where is the archetype
  used? i.e. if we use it on a GUI of a smartphone rather than a
  standalone or web application
 
  2012/1/25 David Moner damoca at gmail.com:
  
   2012/1/25 Thomas Beale thomas.beale at oceaninformatics.com
  
   Maybe another way of understanding this flag is as 'this node can be
   skipped without loss of meaning'. I would be very interested to know
 if
   we
   should make AQL queries sensitive to this flag. Has anyone thought
   about
   that?
  
  
  
   In this sense I can see the reason for this attribute, since it can be
   understood as part of the documentation of the clinical model. But
   definitely it is not clearly described at the specs since there it
 seems
   to
   be linked to the presentation template only.
  
   I fact, there is a similar attribute in EN13606 ITEM class, but used
 in
   an
   opposite sense. The attribute is emphasis and it is described as A
   way of
   denoting that the composer wished to mark this ITEM as being of
   particular
   note (an unusual measurement value, an unexpected outcome, anything
 that
   might be considered necessary to highlight to a future reader).
  
   I have never thought about this. I don't know if this kind of
   annotations
   (this item is important or clinically relevant or not) better fits
 as
   part
   of the RM or part of the AOM. In other words, if this marker is
 related
   to a
   specific data instance or to a data item definition in an archetype.
  
   Thoughts on this?
  
  
  
   --
   David Moner Cano
   Grupo de Inform?tica Biom?dica - IBIME
   Instituto ITACA
   http://www.ibime.upv.es
  
   Universidad Polit?cnica de Valencia (UPV)
   Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
   Valencia ? 46022 (Espa?a)
  
   ___
   openEHR-technical mailing list
   openEHR-technical at openehr.org
   http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 
 
  --
  David Moner Cano
  Grupo de Inform?tica Biom?dica - IBIME
  Instituto ITACA
  http://www.ibime.upv.es
 
  Universidad Polit?cnica de Valencia (UPV)
  Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
  Valencia ? 46022 (Espa?a)
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/b6c254ed/attachment.html


pass_through attribute in ADL 1.5

2012-01-25 Thread David Moner
2012/1/25 Thomas Beale thomas.beale at oceaninformatics.com

 Maybe another way of understanding this flag is as 'this node can be
 skipped without loss of meaning'. I would be very interested to know if we
 should make AQL queries sensitive to this flag. Has anyone thought about
 that?



In this sense I can see the reason for this attribute, since it can be
understood as part of the documentation of the clinical model. But
definitely it is not clearly described at the specs since there it seems to
be linked to the presentation template only.

I fact, there is a similar attribute in EN13606 ITEM class, but used in an
opposite sense. The attribute is emphasis and it is described as A way
of denoting that the composer wished to mark this ITEM as being of
particular note (an unusual measurement value, an unexpected outcome,
anything that might be considered necessary to highlight to a future
reader).

I have never thought about this. I don't know if this kind of annotations
(this item is important or clinically relevant or not) better fits as
part of the RM or part of the AOM. In other words, if this marker is
related to a specific data instance or to a data item definition in an
archetype.

Thoughts on this?



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/6c0f2e0b/attachment.html


Constraints on class methods

2012-01-16 Thread David Moner
I found that offset was a stored value at openEHR RM 0.95 (back in 2005),
but then it became a computed method.


2012/1/15 Thomas Beale thomas.beale at oceaninformatics.com


 Life would have been much easier if Event recorded 'offset' as a stored
 value, and the 'time' was the property being computed. I argued
 strenuously for that years ago, precisely to avoid the problem we are
 talking about here, but lost the battle ;-)

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120116/f2d17f07/attachment.html


Constraints on class methods

2012-01-10 Thread David Moner
Doesn't this create problems while using archetypes/templates as basis for
the generation of data instances?

I mean, a computed attribute (for example, the EVENT offset) gets its value
from already existing values or attributes of the instance class (in this
example, from the time and the parent.origin). We should not create the
instance if data is not valid regarding the archetype/template, but we
cannot check the validity of the constrained offset while we don't have the
instance complete. It seems somehow a vicious circle. An assertion here is
clearly preferable, since by definition it is only applied to existing
instances.

David


2012/1/10 Thomas Beale thomas.beale at oceaninformatics.com

 On 10/01/2012 08:40, Diego Bosc? wrote:
  Oh, this is the first time I have heard that functions can be
  constrained. However, AOM specifications say otherwise:
  C_attribute:  a  node  representing  a  constraint  on  an  attribute
(i.e.  UML  ?relationship?  or
  ?primitive attribute?) in an object type; (AOM specifications, page 12)
  This excludes clearly the 'stored properties'.
 
 

 That wording in the current release does exclude non-attributes. But I
 think it should be possible to state constraints on computed attributes
 (public functions with no parameters). It has already been implemented
 and is not difficult.

 - thomas

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/096b847f/attachment.html


Outcomes conclusions of the openEHR course in spanish ( ideas for the future)

2012-01-05 Thread David Moner
 openEHR-clinical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/f3716c50/attachment.html


13606 revisited - list proposal

2011-12-16 Thread David Moner
2011/12/16 Erik Sundvall erik.sundvall at liu.se



 If so, why do you want to turn the 13606/openEHR into something
 healthcare a-specific? Wouldn't that be an enormous deviation from
 the current 13606 thinking and purpose? Was not 13606 intended exactly
 for healthcare?



Well, in fact current EN13606 RM is nearly healthcare independent, except
the EHR_EXTRACT class name, the attributes ehr_system, ehr_id,
subject_of_care and healthcare_facility and the demographic model. The
class and attribute names can be easily changed to drop the EHR part and
for the demographic package I think that the one of openEHR is much better
and, in fact, it is already healthcare independent.

In any case, this generic design is a result of the current scope of 13606:
EHR exchange and not a complete EHR implementation specification. From our
experience, interoperability between legacy systems (standard-based or not)
is much easier using a generic model for exchange. The harsh truth is that
the quality of the data and the design of information structures in
existing EHR systems is quite bad or unclear, thus making really
complicated the process of automatically transforming it to a very specific
reference model. This is not the case when we use 13606.

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

David
-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/43915127/attachment.html


13606 revisited - list proposal

2011-12-16 Thread David Moner
Hi,

2011/12/16 Erik Sundvall erik.sundvall at liu.se

 Hi!

 As you know, if you want to truly bi-directionally share things for
 which it is impossible to define deterministic conversion
 algorithms/programs (thus maintaining patient safety in automated
 conversions), then just defining a standard message- or extract format
 will be a lost cause (no matter how determined politicians are and no
 matter how much you pay IT-consultants to try to do the job). Instead
 the semantics of the end point systems will need to be aligned sooner
 or later.


I completely agree. But aligned does not mean that the have to be exactly
the same. Conversions between models and standards will always be needed.

Anyway it wouldn't hurt if a new or refreshed internationally
 recognized standard could be used by those vendors and system owners
 that actually _want_ to agree on the internal clinical semantics of
 efficiently implementable systems all the way down to some of the
 technical (e.g. openEHR inspired) details. I think there is now a
 market for such a standard (or new standard part) helping those that
 have given up beliefs in mapping of incompatible semantics.


The problem is that a unique solution will never be used by all actors (due
to the human nature of divergence). The need of interoperability between
different solutions and systems will always exist and then we have to give
a solution for this scenario. Best practices maybe will commonly accepted,
but no specific solutions probably.


  From our
  experience, interoperability between legacy systems (standard-based or
 not)
  is much easier using a generic model for exchange. The harsh truth is
 that
  the quality of the data and the design of information structures in
 existing
  EHR systems is quite bad or unclear, thus making really complicated the
  process of automatically transforming it to a very specific reference
 model.
  This is not the case when we use 13606.

 I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized RMs?
 http://dilbert.com/strips/comic/2011-08-02/


I talked of this with Thomas last August in Oslo. For me, the ideal
solution would be to have a unique model that covers both needs. It should
include generic classes such as those of 13606 and inherit from them
specific classes for building EHR systems, as those of openEHR. Technically
it should be possible to have, for example, a generic
COMPOSITION-ENTRY-CLUSTER-ELEMENT structure that can be instantiated, but
also a COMPOSITION-OBSERVATION-ITEM_TREE-ELEMENT structure inherited from
it. An implementer could choose then to just create instances of the
generic classes (e.g. for exchange) or instances of the specific ones, that
are compatible (e.g. for operational systems). Note that this is currently
not possible since ENTRY is an abstract class in openEHR.


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


It definitely helps. On the one hand because we deal with data
transformations and then it is essential to have a clearly defined
reference or information model to shape the data that is going to be
communicated. And on the other hand, archetypes are the target schema for
these data. We will all agree that the dual model is the best way to have
together the three basic ingredients of semantic interoperability: the data
structure, the concept definition and the binding to terminologies.


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

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


I have no idea. I don't know the internal rules of ISO.


 Could one add a new part (13606 part-6 or 1b?) to the specification
 containing detailed RM semantics (inspired by openEHR) and at the same
 time align that new part and a more general healthcare a-specific
 model (a revised 13606 part-1(a)?) in a way that clearly defines a
 deterministic (and tested) conversion algorithm from the detailed
 clinically focused RM (6 or 1b) to the healthcare a-specific RM
 (1a)?


From what I have heard, it is possible to add new part to the standard.


David


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa

13606 revisited - list proposal

2011-12-16 Thread David Moner

  I suspect this is an intentional difference between current 13606 and
 openEHR; to faithfully capture the current (incompatible) situation
 versus aiming to change the current situation.  Can those different
 goals really meet in one RM or do we need two standardized 
 RMs?http://dilbert.com/strips/comic/2011-08-02/


 I should perhaps point out that openEHR has a perfectly usable generic
 Entry 
 typehttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.htmlthat
  does the same as 13606 Entry. This Entry type is designed for weakly
 structured data.


It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is
now only complicates de model by creating a standalone branch. Instead of
that, I would prefer to look for a solution where the ENTRY class is
directly instantiable. Thus, an implementer can choose to use it if the
lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs.
Moreover, it would be easy to cast an ENTRY instance into any of its
descendants when needed.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/120f3d44/attachment.html


13606 revisited - list proposal

2011-12-15 Thread David Moner
Hello Thomas,

The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
:-) will start next February at the EN 13606 Association General Assembly
in Seville with an open and public consultation. Before that, to prepare a
draft starting point, during January a consultation will be made to key
actors, implementers and users of the standard, including openEHR.

There is more information at
http://www.en13606.org/index.php/activities/general-assembly-2012

As you know, my opinion is that an harmonisation or at least a seamless
transition between 13606 and openEHR is a key element to succeed.

David


2011/12/15 Thomas Beale thomas.beale at oceaninformatics.com


 At the CIMI meeting last week and elsewhere, I have noticed a lot of
 interest in the ISO 13606 2012 revision, specifically in a) whether the
 openEHR and 13606 reference models can be brought together for part 1 of
 the revision and b) in finalising ADL/AOM 1.5 for providing a new
 snapshot to ISO for part 2.

 It seems to me that it would be useful to have a dedicated place to
 discuss this, so I would like to propose a new mailing list,
 13606-alignment at openehr.org

 Does this seem like a useful idea?

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/82893545/attachment.html


13606 revisited - list proposal

2011-12-15 Thread David Moner
Hi Stef,

There are no subscription fees, all activities are open to the public. The
only requirement is to confirm the attendance in advance because the space
will be limited.

David


2011/12/15 Stef Verlinden stef at vivici.nl

 I asume there is no subscription fee for openEHR members.

 Cheers,

 Stef


 Op 15 dec. 2011, om 11:33 heeft Gerard Freriks het volgende geschreven:

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



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/59a07d26/attachment.html


ADL Workbench beta 5

2011-12-01 Thread David Moner
Thank you Seref, I did not open that one :-)

David

2011/12/1 Seref Arikan serefarikan at kurumsalteknoloji.com

 Hi David,
 On behalf of Thomas, I'd like to relay the following respone to your
 question:

 I know it needs work, but this documented example schema should help.

 the link is:
 http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/EXAMPLE.bmm.txt

 - thomas






 On Thu, Dec 1, 2011 at 6:56 AM, David Moner damoca at gmail.com wrote:

 Hello Thomas,

 Is there any grammar or documentation of the RM schema format? I have
 only found the .bmm existing schemas, but I'm not sure on how to interpret
 some of the fields.

 David

 2011/11/30 Thomas Beale thomas.beale at oceaninformatics.com


 This new beta, available 
 herehttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html,
 includes the following features:

- new Class Tool: properties 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool.png,
ancestors 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool_ancestors.png,
descendants 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool_descendants.png
- RM meta-data tool - descriptive meta-data of each loaded Reference
Model can be viewed in the tool
 - CKM 
 iconshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/RM_icons_overview.pngon
  models
 - 
 statisticshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/catalogue_statistics.png

 metricshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/catalogue_metrics.pngtools
  showing use of RM classes in archetypes - answers 'what is being
archetyped'?
 - JSON output serialisation of differential and flat archetypes -
useful for people who like reading JSON syntax, and have software that 
 can
consume JSON
- Improved format of reference model schemas (see release notes).
 - Release 
 noteshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/release_notes.html

 We are already aware of some GUI font rendering / spacing issues in the
 Linux and Mac builds of the tools. Other than that, please post all issue
 reports  feature requests herehttp://www.openehr.org/issues/browse/AWBPR
 .

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




 --
 David Moner Cano
 Grupo de Inform?tica Biom?dica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es

 Universidad Polit?cnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
 Valencia ? 46022 (Espa?a)

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111201/1cd1e2ab/attachment.html


ADL Workbench beta 5

2011-12-01 Thread David Moner
Hello Thomas,

Is there any grammar or documentation of the RM schema format? I have only
found the .bmm existing schemas, but I'm not sure on how to interpret some
of the fields.

David

2011/11/30 Thomas Beale thomas.beale at oceaninformatics.com


 This new beta, available 
 herehttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html,
 includes the following features:

- new Class Tool: properties 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool.png,
ancestors 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool_ancestors.png,
descendants 
 viewhttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/class_tool_descendants.png
- RM meta-data tool - descriptive meta-data of each loaded Reference
Model can be viewed in the tool
 - CKM 
 iconshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/RM_icons_overview.pngon
  models
 - 
 statisticshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/catalogue_statistics.png

 metricshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/images/catalogue_metrics.pngtools
  showing use of RM classes in archetypes - answers 'what is being
archetyped'?
 - JSON output serialisation of differential and flat archetypes -
useful for people who like reading JSON syntax, and have software that can
consume JSON
- Improved format of reference model schemas (see release notes).
 - Release 
 noteshttp://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/release_notes.html

 We are already aware of some GUI font rendering / spacing issues in the
 Linux and Mac builds of the tools. Other than that, please post all issue
 reports  feature requests herehttp://www.openehr.org/issues/browse/AWBPR
 .

 - thomas beale

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111201/1960510e/attachment.html


Questions about the necessity of ITEM_SINGLE

2011-10-04 Thread David Moner
I think Thomas has already mentioned that here there is a good possibility
of harmonization with EN13606. At the end it seems that we only need  single
ELEMENTs and a container with list or table semantics.

2011/10/4 Sebastian Garde sebastian.garde at oceaninformatics.com

 Yes - and if you want to go one further, ITEM_LIST is nothing more than
 a special case of ITEM_TREE as well.
 Modelling this explicitly hasn't been extremely useful I believe,
 especially if weighed against your evolution argument.

 Sebastian

 Am 04.10.2011 01:42, schrieb Heather Leslie:
  I model using ITEM_TREE as default in every archetype, except where we
 might need a table structure.
 
  So I always aim to allow for maximal flexibility as the archetype
 evolves... and in almost every situation it does.
 
  Heather
 
  -Original Message-
  From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
  bounces at openehr.org] On Behalf Of Rong Chen
  Sent: Tuesday, 4 October 2011 6:29 AM
  To: For openEHR clinical discussions
  Cc: openehr technical
  Subject: Re: Questions about the necessity of ITEM_SINGLE
 
  Hi Pablo,
 
  I agree with your analysis here especially the last one regarding
 evolution of
  archetypes.
 
  Regards,
  Rong
 
  On 3 October 2011 16:23, pablo pazospazospablo at hotmail.com  wrote:
  Hi everyone,
 
  I've been studying how to simplify the ITEM_STRUCTURE model to enhance
  the persistence performance of our Open EHR-Gen project
  (http://code.google.com/p/open-ehr-gen-framework).
 
  Now I'm reaching a point in which I doubt about the necessity of
  ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
  expose some arguments and hear your comments about it.
 
  Semantic argument: As I understand ITEM_SINGLE, the semantics of this
  class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
  I mean
  that: the semantics of ITEM_SINGLE is just a matter of cardinality
 (=1).
 
  Practical argument: in practice, an ITEM_SINGLE is like using an
  ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
  TABLEs, the interface of each class can be the same, like: getItems(),
  setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
 
  Evolution argument: If I have an archetype with an ITEM_SINGLE, but
  the concept modeled with this archetype needs to change adding more
  nodes to the archetype, I need to change the ITEM_SINGLE to another
  ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
  can add any nodes without changing the ITEM_STRUCTURE type. I think
  this way is more simple to create new archetypes with backwards
  compatibility.
 
  What do you think?
 
  --
  Kind regards,
  Ing. Pablo Pazos Guti?rrez
  LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
  Blog: http://informatica-medica.blogspot.com/
  Twitter: http://twitter.com/ppazos

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/4d18e261/attachment.html


future of CEN 13606 data types

2011-09-19 Thread David Moner
It sound as a very interesting proposal.

As you say, profiling ISO 21090 data types leads to several problems of
inconsistency and non-interoperability. And in terms of efficiency, our
tests using the new data types in LinkEHR are not satisfactory at all.

But my main question is if this initiative has possibilities of achieving an
official support from HL7. This is an important question to prepare the
future of current norms. This is what the 13606 says about the data types:

It is recognised that, at the time of producing this standard, a new set of
health informatics data types is being developed by ISO TC/215. Once this is
published, CEN may choose to deprecate TS 14796 in favour of this new
standard. In doing so, it will need to provide a mapping correspondence to
the new data type standard, and this mapping will also need to be used in
order to adopt the new data types alongside EN13606-1.

Thus, while no official ISO 21090 profile has been defined and mapped to
existing TS 14796 (although there are some proposals), the last ones are
still the valid ones for 13606. If there is any possibility for this new
proposal of Grahame to succeed, it would be a waste of time to change
current data types working with 21090.


@Erik: CEN/ISO 13606 discussions take place at the Association forums and
wiki, to prepare inputs for the CEN/ISO committee. The data types topic is
one of the most important to work on.
Web and forums: www.en13606.org
Wiki: wiki.en13606.org

David


2011/9/18 Thomas Beale thomas.beale at oceaninformatics.com


 At the HL7 meeting last week in San Diego, Grahame Grieve presented
 something called Resources for 
 Healthcarehttp://www.healthintersections.com.au/rfh/introduction.htm(RFH), 
 essentially a replacement model for much of HL7v3, for 'practical
 use'. The driver was the well-known over-complexity of HL7v3. According to his
 report http://www.healthintersections.com.au/?p=610 on the reception of
 RFH at the HL7 meeting, there appears to be a real appetite for change at
 HL7, which is good to see.

 Within RFH, Grahame has proposed a new data types 
 modelhttp://www.healthintersections.com.au/rfh/datatypes.htm.
 In practical terms this will presumably mean that implementations directly
 based on the RIM and 21090, and particularly the creation of RIM/21090 data
 instances will see much reduced use in the future. From the point of view of
 openEHR and 13606 this represents some positive possibilities for bridging
 implementations in the future, and maybe finally solving the 'logjam' in
 health informatics standards.

 Things to note about the RFH data types:

1. They use orthodox object modelling rather than the subtractive
modelling / profiling approach used to date HL7.
 2. They define a very lean set of semantics (so far).
 - These two together mean that for the first time, HL7 data types (if
   that is what RFH data types become) can be extended in the normal OO 
 sense,
   rather than having to be 'profiled' (creating N variants, all
   non-interoperable with each other). Interoperability can potentially 
 now be
   found by connecting to the core definitions, even if it can't directly 
 be
   found with more complex extensions of the core types.
3. They incorporate a lot of features of the openEHR data types.
 - The current openEHR data types are currently more full-featured, and
   in some cases probably more complex than they need to be - adjustments 
 may
   be possible here (one example: the normal / reference ranges in 
 DvQuantified
   should be pulled out into a wrapper type or else added by inheritance to
   DvQuantity and possibly DvCount, DvProportion).

 My conclusions at this point:

- building a data conversion interface between openEHR and HL7 of the
future now has a good chance of success, if the RFH data types develop in 
 an
appropriate way
 - CEN/ISO 13606 should move to the RFH data types, and not use 21090 -
doing so is likely to set up a legacy in the future for 13606 users that 
 HL7
community is about to leave behind. It will allow 13606 to become much
closer to openEHR, and facilitate the merging of the models into one, which
I think is a necessary future step for both openEHR and 13606.

 If HL7 goes this way, some real convergence finally looks possible, and
 people working on openEHR and 13606 need to think about how to go about it.

 - thomas beale


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org

EN/ISO 13606 openEHR - harmonisation possibilities

2011-09-09 Thread David Moner
Thomas,

Could you please clarify this sentence?

I'm the main author of that document. As you said, it is a 45 pages document
of which only two and a half are a summary description of ADL to understand
the proposed archetypes. And only there we can see some examples of ADL
structures (yes, openEHR ones) taken directly from EN13606-2, which is the
norm referenced at the document, and not from the openEHR specifications.

I really think that your affirmation is misleading and unfair.

David

2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com


 As an aside, it is an interesting document - 45 pages about archetypes,
 including a lot of directly copied openEHR material, and no attribution
 at all to openEHR! Lucky it is not an academic paper

 - thomas

 --
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/fa75f391/attachment.html


EN/ISO 13606 openEHR - harmonisation possibilities

2011-09-09 Thread David Moner
Ok, but again, the referenced documents at that epSOS annex are CEN EN 13606
part 1 and CEN EN 13606 part 2. If openEHR has to be mentioned is in those
documents, not in this annex since it only deals with 13606 and the
archetype/ADL summary is just for clarifying concepts for the reader and not
a complete history about the technology behind.

David

2011/9/9 Thomas Beale thomas.beale at oceaninformatics.com

 On 09/09/2011 19:04, David Moner wrote:
 
  Thomas,
 
  Could you please clarify this sentence?
 
  I'm the main author of that document. As you said, it is a 45 pages
  document of which only two and a half are a summary description of ADL
  to understand the proposed archetypes. And only there we can see some
  examples of ADL structures (yes, openEHR ones) taken directly from
  EN13606-2, which is the norm referenced at the document, and not from
  the openEHR specifications.
 
  I really think that your affirmation is misleading and unfair.

 David,

 sorry - you are right, there is not 'a lot' of copied material, only p
 11  12. But I do find it funny that there is no mention of openEHR,
 because it means that readers of the document won't realise that they
 should go to openEHR to see ongoing developments in the specification
 and tools (I am not saying the only development in tools of course, but
 since 13606-2 is a snapshot of an openEHR spec, it would make sense to
 make this clear, one would have thought).

 - thomas

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/f8c1b5f3/attachment.html


openEHR 13606 EHR Extract

2011-05-05 Thread David Moner
2011/5/5 Thomas Beale thomas.beale at oceaninformatics.com


  - What is the difference between an EXTRACT_CHAPTER and a common FOLDER?



 Chapters of type EXTRACT_CHAPTER are used to explicitly organise top-level
 chunks of content in the Extract; the meaning of each chapter is
 archetype/template-defined. EXTRACT_FOLDERs are there to represent FOLDER or
 similar structures from the source system, i.e. to preserve such structures
 in the Extract. So EXTRACT_CHAPTER is an artefact of an Extract, FOLDER is
 (usually) an artefact of data being extracted. I think 13606 mixes these
 functions up in one FOLDER class, which makes it difficult to say what a
 Folder actually is in a 13606 Extract.

 - thomas



As in other cases, the 13606 approach uses a more generic way to get the
same results without the need of defining specific classes or data
structures. At this specific case, there is an attribute at all
RECORD_COMPONENTs that is synthesised. Its definition is: This attribute
value must be TRUE if this RECORD_COMPONENT has been created in order to
comply with this standard , but this point in the EHR hierarchy has no
corresponding node in the EHR from which it was extracted.

So, as you said, in a 13606 extract we can have a mix of FOLDERs created to
organise the information of the Extract and FOLDERs existing at the original
EHR system, but they can be clearly distinguished by the synthesised
attribute.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110505/ad69b710/attachment.html


Archetype versioning on CKM

2011-04-28 Thread David Moner
2011/4/28 Heather Leslie heather.leslie at oceaninformatics.com

  Hi everyone,

 I think you are missing some of the further complexity here. There is a
 definite need for differentiation between draft and published archetypes for
 which a version number alone is not enough.
 Currently we are talking only about v1 archetypes and how to manage them,
 and to a degree it makes sense. We certainly considered using v0.x for
 drafts but it doesn't solve the downstream problems - once a v1 archetype is
 published, the non-breaking revisions will become v1.1, 1.2 etc. No problem
 But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but
 it needs to be clear that it is v2 *draft* initially and not v2 *published*
 until we have completed the neccessary collaborative reviews.


I see your point and I completely agree with it.

Using v0 to denote draft archetypes before going to v1 only solves the first
iteration. When moving to v2, v3, etc. we certainly will have drafts and
published archetypes for those new versions and we have to manage all them.
Even when creating  v1.x or v1.x.y archetypes we can need drafts prior to
the formal voting/validation/publication of them. Archetypes, as a technical
resource (not as a concept definition) need to have unique identifier for
each minimal change. We have the archetype revision history but we should
also show those changes by changing the identifiers.

So, we fall back to the need of rethinking archetype identifiers to include
these new requirements or change them into identifiers with no semantics. Or
a third option, maybe the best one, to clearly separate between a concept
identifier that would be the current identifier and a resource identifier
to track every change and to, at least, warn systems that use archetypes
that something has changed.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/9cdfe73f/attachment.html


Archetype versioning on CKM

2011-04-27 Thread David Moner
2011/4/27 Ian McNicoll Ian.McNicoll at oceaninformatics.com



 Would calling first draft archetypes .v0 help to highlight their fragility?



In fact, that is what the specifications say. Our archetype editors should
use 0 when creating a new archetype.

(Knowledge Artefact Identification specifications)

.v0 rule: all archetypes have this version on initial creation, before being
accepted by the
collaborative authoring environment;

revision id rule: revision number starts at 0 and is incremented whenever a
backwards
compatible change is made that affects the structure ? by widening
constraints and/or adding
new nodes;

commit id rule: commit number starts at 0 and increments for any change at
all to an archetype,
including changes to meta-data, addition of translations and so on.

An archetype will start its life as a ?v0? artefact, and with no namespace.
In this form, it can have any
number of revisions and commits. It may be maintained for some time outside
a Publishing Organisation,
or it may be offered to a PO, where it will initially become part of an
?alpha? development area.
where it will remain until its identifier and location in the package and
Library structure is stablised.

Once stable, an alpha archetype will migrate to the main ?dev? area, where
it will be given a namespace
prefix and have its version incremented to ?v1?. At this point it could be
published into the
?release? area, or alternatively, further development may occur before
publishing. Whenever the revision
is changed, due to a backwards-compatible structural change, the archetype
should be re-published,
enabling the community to have access to the latest form of the archetype.

During development, each change will increment the commit number. Whenever
an archetype is published,
the commit number is reset to 0.




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110427/61a8d1ae/attachment.html


openEHR artefact namespace identifiers

2011-04-07 Thread David Moner
Dear Thomas,

I agree with your general approach, but you miss two important things.

1. If openEHR spreads, you cannot expect that all implementations will be
always up-to-date. That means that just upgrading the version number of the
archetype will not be enough for a system to automatically differentiate the
right version for the RM version they have implemented. If we just say Ok,
but since that information will be at the archetype header we don't need it
at the identifier, we can also say the same for the concept, the RM class,
the RM and the organisation. At the end, we will find that we don't need a
semantic id, as Erik said, and that a UUID, OID or whatever is enough for
identifying archetypes.

2. Archetypes are not only for openEHR. We must always have in mind that
other reference models can be used with their own life-cycle that could be
not so fine-grained as in openEHR. For example, we are now creating HL7 CDA
R2 archetypes but during this year it is expected CDA R3 to be approved. How
will we differentiate archetypes of R2 from archetypes of R3? Once again, R2
will still be used for many years and updating the version number isn't
enough.

Finally, I also agree that is not the same to talk about RM version of an
archetype than to talk about archetype validity regarding a RM, but one
should not exclude the other.

David



2011/4/7 Thomas Beale thomas.beale at oceaninformatics.com

  On 05/04/2011 19:16, David Moner wrote:

 Hello,

  I like that approach regarding namespaces, it will be needed sooner than
 later.

  Related to archetype identifiers there is another problem still to be
 solved. How they deal with RM evolutions?  Current openEHR RM release is
 1.0.2 but it can change in the future. Nowhere at archetypes is said which
 RM version was used to define them. This information should go, at least, at
 the archetype header, but probably should also be represented at the
 archetype id.  Otherwise we will not be able to differentiate between an
 archetype for one version of the RM and the same archetype (modified if it
 is the case) for a different one.


 It should go in the archetype, that is for sure - but it should be
 understood only as 'the RM version used when this archetype was authored /
 quality assured etc' - rather than 'the RM version for which this archetype
 is valid'. The reason is easy to understand: for some particular archetype,
 authored at RM 1.0.2 let's say, it may be valid for many RM revisions after
 that, even RM 2.x, and not only that, it might be perfectly valid for prior
 revisions e.g. 1.0, 1.0.1, even 0.95 - it can depend a lot on what parts of
 the RM the archetype happens to use. This is the reason I argued against
 including the RM version in the archetype id, because it doesn't tell us
 anything about validity. (We had a long discussion about this on the
 technical list last year or 2009 I forget which).

 Now.. if the RM changes, let's say to 2.0.0, then we might assume that
 there are one or two breaking changes, and that a few archetypes could
 break. The only way I can see to deal with this is:

- we stick with the rule that minor RM change numbers never break
archetypes (or indeed existing data), i..e 1.0.1 - 1.0.2 - 1.0.3 etc is
guaranteed safe
- we say that a major RM version change, i.e. 2.x, 3.x etc that
includes breaking changes there has to be a validity test run on all
archetypes.
 - any that don't pass, i.e. are compromised by the change need to be
   marked in some way, maybe a header field with the meaning 'valid up to 
 RM
   release xxx' or so.
   - such archetypes would themselves then have to be versioned
   (.v1 = .v2)

 It should be remembered that we can undertake many innovations and 'fixes'
 that don't break anything on the RM, and therefore don't require a major
 release. So openEHR 2.x, 3.x etc are likely to be extremely rare events.

 - thomas




 --
   [image: Ocean Informatics]  *Thomas Beale
 Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/
 *

 Chair Architectural Review Board, *open*EHR 
 Foundationhttp://www.openehr.org/
 Honorary Research Fellow, University College 
 Londonhttp://www.chime.ucl.ac.uk/
 Chartered IT Professional Fellow, BCS, British Computer 
 Societyhttp://www.bcs.org.uk/
 Health IT blog http://www.wolandscat.net/
 *
 *

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110407/e2124891/attachment.html

openEHR artefact namespace identifiers

2011-04-07 Thread David Moner

  2. Archetypes are not only for openEHR. We must always have in mind
  that other reference models can be used with their own life-cycle that
  could be not so fine-grained as in openEHR. For example, we are now
  creating HL7 CDA R2 archetypes but during this year it is expected CDA
  R3 to be approved. How will we differentiate archetypes of R2 from
  archetypes of R3? Once again, R2 will still be used for many years and
  updating the version number isn't enough.

 I don't know what R3 looks like, but if it is a different reference
 model, then the ids would be something like

 hl7-cda3-Entry.diagnosis.v1

 If CDA r3 on the other hand is a clean extension / superset of CDAr2,
 then the 'reference model' is really just 'cda', and there is no simple
 relationship between particular archetypes and particular releases of
 the CDA model.

 - thomas


So, at the end you are putting the RM version somewhere at the identifier...
 :-)

(btw, I don't know which will be the changes at R3)

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110407/f35a3824/attachment.html


GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-03 Thread David Moner
Thanks Thomas. I will resume the reasoning that brought us here:
in some cases templates will also be shared together with
archetypes, then, in my opinion, they should not incorporate GUI
related stuff and be only about data constraints.

David

2010/12/3, Thomas Beale thomas.beale at oceaninformatics.com:
 On 03/12/2010 21:01, David Moner wrote:

 #3.  The templates you use should only restrict data entry.  It should
 not filter existing data of the same structure.  If it does; there goes
 interoperability. Along with the entire premise for the use of and
 purpose of archetypes.
 Interesting... If templates are only used for data entry and not for
 data reading and revision that should be stated clearly for all
 developers, since I think it is not said anywhere at the
 specifications, the web or the wiki. Every developer should know that
 (coming back to the topic of this thread) if they hand-code a
 visualization template all that work is only useful for the data
 generated at their own system and not for the data from an external
 one, even if it is using the same archetypes.

 the general idea has always been that data can always be interpreted by
 a receiver using just the archetypes declared in the data. I believe
 this will continue to be a reliable assumption into the future. However,
 with the new style templates, which are essentially just archetypes, it
 may be that templates will be shared quite often as well, since the
 computing machinery that can deal with archetypes will be able to deal
 with ADL 1.5 templates as well (with only very minor upgrades from
 today, since we are talking about operational templates, which are
 essentially big archetypes). This is not going to add much information,
 since the information structures themselves (i.e. the compositional
 hierarchy of Composition, Sections, Entries etc) will reflect the
 structure of the template that was used. But if the receiver wants to
 validate the received data against the template, which is likely to
 include a) numerous removed optional items and b) further constrained
 coded text fields, then it will need the template. Note that the data as
 received must be definition already be valid with respect to the
 implicated archetypes, and if the receiver is interested in what the
 template says, then it means they probably have some agreement with the
 sender institution about using their templates. This will almost
 certainly happen with nationally standardised templates for referrals,
 discharge summaries and so on.

 In summary: displaying and using the data with just the archetypes used
 to build it will be fine, since the data will reflect accurately the
 removed optional items, reduced terminology choices etc. Any site
 wanting to do processing against the template will undoubtedly be in
 some kind of communication with the publisher of the template.

 - thomas
 *
 *



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)




GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-02 Thread David Moner
2010/12/2, Tim Cook

 Hmmm,I am very interested in hearing about a use case where these
 templates are 'needed' to 'fully interpret' the data.

 Thanks,
 Tim


Maybe I do not have the knowledge to give a valid clinical example but
it is reasonable to think that constraining an archetype in the way a
template does can influence the interpretation of the data.
Imagine you have a set of archetypes and you define a template
constraining some items to not allowed. You use that template to fill
some data and then you require the collaboration of a physician from
an external organisation. You share the archetypes but not the
template. And then the other physician fills some more data (including
the one you marked as not allowed) and returns it to you. There is the
problem, when you revise the data using again your own template you
will never see part of the new data and that can affect your
interpretation of it.
That's why structural templates must be also shared in some cases.


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)




GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-01 Thread David Moner
We had a similar discussion at the EN13606 web page. These are the
conclussions I got.

We should distinguish two types of templates:

- Structural templates (specific use). Artefacts that constrain archetypes
for specific uses or aggregate them in order to build more complex
structures. These are the current openEHR templates.

- Visualization templates (local use). These are a new idea. Local templates
are just for visualization configuration (for example, positioning of the
elements, definition of the size of a field, selection of a visual
representation for a class or selection of the interface language).

The important here is to distinguish ?specific use? from ?local use?. In my
mind, a specific use is to define a use case where only a part of the
archetypes or several archetypes are used. This is related to data
structures. For example, to keep only the part of the blood pressure
archetype that is important for the Primary Care measurement of vital signs.
This specific use further constrains archetypes and these kind of structural
templates should be also shared as the archetypes themselves since they will
be needed to fully interpret the data. On the other hand, a local use is
when you define constraints that are only useful for your own use or
specific system. This is related to GUIs. These visualization templates are
not meant to be shared outside your institution.
ADL 1.5 is enough for defining the structural templates. Visualization
templates needs something else to be defined. I would not recommend the use
of those GUI-directives mixed with the structural templates, but to define a
new level (maybe a specific model) for them. As some of you said, maybe
these visualization or local templates do not need to be a part of
standardized architecture since they are local implementations, but I
think that it is possible to design a kind of common framework to deal with
them together with archetypes and structural templates.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/62a878f7/attachment.html


Templates, node identifiers and data instances

2010-11-19 Thread David Moner
Dear all,

I have a doubt about templates defined as an archetype specialization. The
updated specs say that templates are just a further specialized archetype.
So, any change made at that level (remove or define mandatory nodes, slot
filling, etc.) also means a new level at the node identifier. For example,
if I have a node with at0001 and I constraint something of it at the
template level, we should generate a new at0001.1 for that node.

The question is, data instances that will be generated should use the
clinical archetype node id (at0001) or the template node id (at0001.1) as
archetype identifier? Or phrased differently, for the second case, if I
communicate the instance, should I also share the template definition to
better describe it or would be enough by sharing only the clinical
archetype?

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/19f2a26c/attachment.html


openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

2010-11-11 Thread David Moner
You can find here the related work to this problem from our colleagues at
the University of Murcia.

An approach for the semantic interoperability of ISO EN 13606 and OpenEHR
archetypes.
Catalina Mart?nez-Costa, Marcos Men?rguez Tortosa, Jesualdo Tom?s
Fern?ndez-Breis
Journal of Biomedical Informatics 43(5): 736-746 (2010)

David


2010/11/10 Thomas Beale thomas.beale at oceaninformatics.com


 For those unaware, we started the openEHR/13606 mapping 
 herehttp://www.openehr.org/wiki/display/stds/openEHR+to+ISO+13606-1%2C+ISO+21090+mapping,
 and you can see if you look carefully that there is an initial description
 of where a purely automated conversion algorithm that Erik is talking about
 goes.




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2010/edbee82b/attachment.html


Uppercase and lowercase at archetype nodes

2010-11-04 Thread David Moner
While working with archetypes for different reference models we have faced a
problem regarding the uppercase/lowercase rules for naming archetype nodes
at ADL.

The ADL specifications imposes the following rule: A type name is any
identifier with an initial upper case letter, followed by any combination of
letters, digits and underscores. A generic type name (including nested
forms) additionally may include commas and angle brackets, but no spaces,
and must be syntactically correct as per the UML. An attribute name is any
identifier with an initial lower case letter, followed by any combination of
letters, digits and underscores. Any convention that obeys this rule is
allowed (ADL 1.5 draft, page 26).

However, at the UML specifications I have only found the following style
guidelines: Capitalize the first letter of class names (if the character
set supports uppercase) and Begin attribute and operation names with a
lowercase letter. But I understand these as style recommendations and not
as a mandatory specification since they are accompanied with others such as:
Center class name in boldface and Put the class name in italics if the
class is abstract.

In any case, as we all know, object-oriented programming is not just UML. We
can use other modeling tools or programming languages that do not impose the
uppercase/lowercase rule. And moreover, at the AOM specifications I cannot
find any reference about the fact that the rm_type_name String should begin
with uppercase or the rm_attribute_name String with lowercase.

For example, all the attributes of the CDISC ODM standard are defined
starting with an uppercase.

So, from a generic perspective of the dual modeling process, I think that
archetypes (or more specifically, ADL) should not impose rules in this
aspect. What's your opinion?

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101104/606a93a8/attachment.html


proposed ADL 1.5 simplification

2010-07-06 Thread David Moner
2010/7/6 Peter Gummer peter.gummer at oceaninformatics.com

 Sebastian Garde wrote:

  A future Archetype Editor would always replace the adl_version with
 1.5 when you save an archetype, I expect, similarly to what was done
 manually with a text editor in this little experiment. This would be
 the minimal change to any archetype when migrating to 1.5.


We should avoid this kind of automatic changes. A user might not expect that
his 1.4 ADL code is changed to a different syntax without at least a
warning, since it can have an impact on his system implementation. As a
typical example, when you open a .DOC document with Microsoft Word
2007/2010, it will never change it to .DOCX automatically.

David

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100706/dc37d6c1/attachment.html


DV_DATE definition mismatch

2009-11-16 Thread David Moner
Dear Heath,

The problem I?m focusing is an incorrectness regarding the dual model
methodology rules.

If in a reference model we have an attribute of the type ?String?, an
archetype constraining it must be a C_String instance from the archetype
model. If we had an attribute of the type ?Date?, then the correct AOM class
to constraint it would be a C_Date.

The problem here is that in the reference model we have a ?String? attribute
(the ?value? attribute of the DV_DATE) but the generated archetypes use a
C_Date class to constraint it instead using a C_String. Here is the
mismatch. Following the principles of the dual model approach we cannot
consider that a valid archetype with regard to the underlying reference
model.


2009/11/16 Heath Frankel heath.frankel at oceaninformatics.com

  Hi David,

 There is nothing wrong in the openEHR specifications or the Ocean Archetype
 Editor?s construction of the ADL representation of an ELEMENT of type
 DV_DATE.



 The RM specifies the DV_DATE class as having a value attribute of type
 string that represents an ISO8601 date, which supports partial dates, e.g.
 ?1934-05? or ?1934? (also note that ?193405? is also a valid ISO8601
 representation of ?1934-05?).  These partial dates are not supported by
 XML?s xs:date and hence it has not been used in the schema.



 The constraint specified in the ADL fragment you have provided below is a
 further constraint on this ISO8601 representation, as specified in
 http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf section
 5.4.6.1.  This particular constraint indicates that the month is optional
 and day is not to be provided, so valid date must be a partial date like the
 examples above.



 What Java Parser are you using?  Are you sure that the parser is not
 producing a DvDate object that represents the value attribute of the
 ELEMENT, which itself has a value attribute which has a constrained string
 representation of a partial date?



 Regards



 Heath



 Heath Frankel

 Product Development Manager

 Ocean Informatics



 heath.frankel at oceaninformatics.com

 +61 (0) 8 7127 5574







 *From:* openehr-technical-bounces at openehr.org [mailto:
 openehr-technical-bounces at openehr.org] *On Behalf Of *David Moner
 *Sent:* Friday, 13 November 2009 9:09 PM

 *To:* For openEHR technical discussions
 *Subject:* DV_DATE definition mismatch



 Hello everybody,

 I have detected what it seems a mismatch between the DV_DATE definition of
 the reference model and the ADL parser/AOM model specifications.

 At the RM, the DV_DATE value is defined as a String constrained as an
 ISO8601 pattern. This is both at the RM specification and at the XML Schema.

 Following the ADL/AOM specifications, something such as (this code has been
 generated by the Ocean Archetype Editor)
 DV_DATE matches {
 value matches {-??-XX}
 }
 will be parsed as a C_Primitive_Object of the type Date (in fact, DvDate at
 the java parser that I use).

 The problem then is that the DvDate type parsed does not correspond to the
 String definition of the RM, generating then a non valid archetype that does
 not correspond to the RM.

 There are two possible solutions. Or the RM is changed to represent
 correctly the DV_DATE value as a xs:date type with the appropriate ISO8601
 facet or the archetypes should take the form
value matches {-??-XX}
 to be parsed as a String according to the RM definition.

 I'm right with this?

 --
 David Moner Cano
 Grupo de Inform?tica Biom?dica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es

 Universidad Polit?cnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
 Valencia ? 46022 (Espa?a)

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091116/d2a2197d/attachment.html


DV_DATE definition mismatch

2009-11-13 Thread David Moner
Hello everybody,

I have detected what it seems a mismatch between the DV_DATE definition of
the reference model and the ADL parser/AOM model specifications.

At the RM, the DV_DATE value is defined as a String constrained as an
ISO8601 pattern. This is both at the RM specification and at the XML Schema.

Following the ADL/AOM specifications, something such as (this code has been
generated by the Ocean Archetype Editor)
DV_DATE matches {
value matches {-??-XX}
}
will be parsed as a C_Primitive_Object of the type Date (in fact, DvDate at
the java parser that I use).

The problem then is that the DvDate type parsed does not correspond to the
String definition of the RM, generating then a non valid archetype that does
not correspond to the RM.

There are two possible solutions. Or the RM is changed to represent
correctly the DV_DATE value as a xs:date type with the appropriate ISO8601
facet or the archetypes should take the form
   value matches {-??-XX}
to be parsed as a String according to the RM definition.

I'm right with this?

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091113/7a6f71cf/attachment.html


License and copyright of archetypes

2009-09-01 Thread David Moner
Dear all,

These days I have been thinking about the legal issues involving the use of
existing archetypes. I have seen that openEHR archetypes available on the
Clinical Knowledge Manager are all Copyright (c) 200X openEHR Foundation.
But, what does this exactly implies? I can download them freely, but can I
use them in a commercial environment? Must I make public specialized
archetypes or adaptations from them? Obviously, I is not me but anybody
:-)

I have searched the openEHR page and wiki but I have not found anything
about this topic, just a point in the copyright notice of the specifications
linking to the non-existing page
http://www.openehr.org/free_commercial_use.htm

I think it would be good to start a discussion about licensing. I'm not
talking about open source implementations, but about the archetype artifacts
that anyone can develop. A first approach that can be made is the use of a
Creative Common license. I think that one of them can fit the interests of
the openEHR community. In my opinion, the main aspects that a license for
archetypes must cover are:

- To maintain the attribution to the original author (the openEHR Foundation
or whoever)
- To allow a commercial use of archetypes (like or not, health is a
business)
- To allow modifications and derivations of the archetype.
- On behalf of the openEHR community, the new derived archetypes should be
made public with the same conditions. This is arguable and could be
eliminated.

As I said, one of the Creative Commons licenses covers all this properties.
It is the Attribution Share Alike license: This license lets others remix,
tweak, and build upon your work even for commercial reasons, as long as they
credit you and license their new creations under the identical terms. This
license is often compared to open source software licenses. All new works
based on yours will carry the same license, so any derivatives will also
allow commercial use.
http://creativecommons.org/about/licenses

Finally, this leads to a secondary point. Maybe, the copyright attribute
of an archetype should be renamed to license to best fit the conditions of
usage of archetypes.

What's your opinion?


-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090901/184ad8fa/attachment.html


License and copyright of archetypes

2009-09-01 Thread David Moner
Ok, that page didn't appear to me because I was not logged in the wiki when
I made the search :-)

It is good to see thar there are discussed more or less the same points as
in my mail.

Best regards,
David


2009/9/1 Thomas Beale thomas.beale at oceaninformatics.com


 There is now a page for discussing this -
 http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing

 - thomas beale

 David Moner wrote:

 Dear all,

 These days I have been thinking about the legal issues involving the use of
 existing archetypes. I have seen that openEHR archetypes available on the
 Clinical Knowledge Manager are all Copyright (c) 200X openEHR Foundation.
 But, what does this exactly implies? I can download them freely, but can I
 use them in a commercial environment? Must I make public specialized
 archetypes or adaptations from them? Obviously, I is not me but anybody
 :-)

 I have searched the openEHR page and wiki but I have not found anything
 about this topic, just a point in the copyright notice of the specifications
 linking to the non-existing page
 http://www.openehr.org/free_commercial_use.htm

 I think it would be good to start a discussion about licensing. I'm not
 talking about open source implementations, but about the archetype artifacts
 that anyone can develop. A first approach that can be made is the use of a
 Creative Common license. I think that one of them can fit the interests of
 the openEHR community. In my opinion, the main aspects that a license for
 archetypes must cover are:

 - To maintain the attribution to the original author (the openEHR
 Foundation or whoever)
 - To allow a commercial use of archetypes (like or not, health is a
 business)
 - To allow modifications and derivations of the archetype.
 - On behalf of the openEHR community, the new derived archetypes should be
 made public with the same conditions. This is arguable and could be
 eliminated.

 As I said, one of the Creative Commons licenses covers all this properties.
 It is the Attribution Share Alike license: This license lets others remix,
 tweak, and build upon your work even for commercial reasons, as long as they
 credit you and license their new creations under the identical terms. This
 license is often compared to open source software licenses. All new works
 based on yours will carry the same license, so any derivatives will also
 allow commercial use.
 http://creativecommons.org/about/licenses

 Finally, this leads to a secondary point. Maybe, the copyright attribute
 of an archetype should be renamed to license to best fit the conditions of
 usage of archetypes.

 What's your opinion?


 --
 David Moner Cano
 Grupo de Inform?tica Biom?dica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es

 Universidad Polit?cnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
 Valencia ? 46022 (Espa?a)

 --

 ___
 openEHR-clinical mailing listopenEHR-clinical at 
 openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical



 --
 *Thomas Beale
 Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/
 *

 Chair Architectural Review Board, *open*EHR 
 Foundationhttp://www.openehr.org/
 Honorary Research Fellow, University College 
 Londonhttp://www.chime.ucl.ac.uk/
 Chartered IT Professional Fellow, BCS, British Computer 
 Societyhttp://www.bcs.org.uk/
 *
 *

 ___
 openEHR-clinical mailing list
 openEHR-clinical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090901/39e2c1f2/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090901/39e2c1f2/attachment.png


optional existence, cardinality and occurrences.

2009-07-03 Thread David Moner
I agree with the initial idea about the optionality of existence,
occurrences and cardinality; there is no need to state them if they are not
changed from the reference model.

But one problem arises with the cardinality. As far as I know, the only way
to differenciate a C_Single_Attribute and a C_Multiple_Attribute while
parsing the ADL and generating the AOM instance is through the 'existence'
of the cardinality constraint. If we don't have that keyword it is imposible
to choose the correct attribute object.

At the Jira issue we can read with reference model checking..., but making
the ADL parsers dependent of the RM is absolutely not a good idea in my
opinion.



2009/6/30 Thomas Beale thomas.beale at oceaninformatics.com


 Dear all,

 as part of the specialisation semantics, which are nearly all
 implemented in the ADL workbench, we have made existence, cardinality
 and occurrences all optional. This is sensible for 'source' form
 archetypes - i.e. it is natural that only overridden constraints be
 stated in an archetype, if there is no override of either the reference
 model or a specialisation parent archetype, where the latter is
 relevant, then no constraint is needed.

 The change is described in http://www.openehr.org/issues/browse/SPEC-303

 We have not yet released a new version of the ADL workbench with this
 change, but will soon. What I would like to know is if the implementers
 of other archetype parsers, compilers etc can deal with this change.
 Note that it would normally be part of implementing the wider ADL 1.5
 semantics, since it is logically part of the specialisation semantics.

 has anyone else considered implementing these semantics yet?

 thanks

 - thomas beale


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/025ca78c/attachment.html


optional existence, cardinality and occurrences.

2009-07-03 Thread David Moner
From my point of view, to load a RM meta-model in the ADL/XML/OWL/whatever
parser is still an unappropiate dependance. That would mean that any change
on the RM, if there is any, also implies changing that meta-model for the
parser to correctly work.

In my mind, a dual model system implementation should support a minimal
working environment totally independent of the RM. That is, if I receive an
archetype of a RM that I don't know, I should still be able to parse it and
show it in a minimal form (maybe ugly and redundant, but at least
functional). In fact, I have always thought that the parsing of
C_Domain_Type is not yet a well resolved problem, but that's another topic
:-)

Moreover, if we finally suppose that a meta-model of the RM is available at
the time of parsing, obviously it will be also available at the time of
working with the AOM. And then, coming back to the occurrences problem, why
do we need C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE classes at the AOM? I
mean, why don't just have C_ATTRIBUTE class with its members attribute and
an optional cardinality attribute that will be interpreted as single or
multiple attribute through the RM meta-model?

Maybe a solution could be to add a new keyword such as container or
multiple to specify that an attribute is multivalued and that has nothing
to do with the cardinality. Maybe something like:

ITEM_TREE[at0001] matches {
items container matches { ... }
}

or if we want to redefine the cardinality:

ITEM_TREE[at0001] matches {
items container cardinality matches {1..*; ordered} matches
{ ... }
}


Just some quick thoughts,
David


2009/7/3 Thomas Beale thomas.beale at oceaninformatics.com

  David Moner wrote:

 I agree with the initial idea about the optionality of existence,
 occurrences and cardinality; there is no need to state them if they are not
 changed from the reference model.

 But one problem arises with the cardinality. As far as I know, the only way
 to differenciate a C_Single_Attribute and a C_Multiple_Attribute while
 parsing the ADL and generating the AOM instance is through the 'existence'
 of the cardinality constraint. If we don't have that keyword it is imposible
 to choose the correct attribute object.


 yes, that was one of the reasons for making it mandatory originally. The
 way it has to be handled is in the presence of a RM checking component. I
 have implemented this in the reference ADL parser with no problems - by the
 time the compiler reads any ADL text, it as loaded the reference model and
 can find any attribute in it, and detect whether it is a container or not.


 At the Jira issue we can read with reference model checking..., but
 making the ADL parsers dependent of the RM is absolutely not a good idea in
 my opinion.


 not dependent on 'the' RM - just capable of loading any RM. In the
 reference parser, I have implemented a simple meta-model expressed in dADL -
 see this page for details -
 http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR
 (this will explain why I did not use an XML-schema, to those who will be
 horrified by such an act ;-)

 As such, the reference parser now loads any RM you want, and parses any
 archetype against its correct reference model - so there is no dependency.

 - thomas beale


 *
 *

 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/23e2cb88/attachment.html


ADL internal references change proposal

2009-02-09 Thread David Moner
Hello to everybody.

We have detected an issue in the ADL grammar related to the node_id (at
value) of Internal References. An Internal Reference node, as any other
C_OBJECT, inherits the node_id attribute. But its ADL grammar does not allow
to define this value in a textual representation.

archetype_internal_ref:
  SYM_USE_NODE type_identifier c_occurrences object_path
| SYM_USE_NODE type_identifier error


We think it is necessary to allow the introduction of this information in
some cases. When we re-use an internal data structure, we are maybe also
changing its meaning. For example, looking at the example provided in the
ADL 1.4 document, page 59.

CONTACT [at0004] ? { -- home contact
purpose ? {-- etc --}
addresses cardinality ? {0..*} ? {
ADDRESS [at0005] ? { -- phone
type ? {-- etc --}
details ? {-- etc --}
}
ADDRESS [at0006] ? { -- fax
type ? {-- etc --}
details ? {-- etc --}
}
ADDRESS [at0007] ? { -- email
type ? {-- etc --}
details ? {-- etc --}
}
}
}

CONTACT [at0008] ? { -- work contact
purpose ? {-- etc --}
addresses cardinality ? {0..*} ? {
use_node ADDRESS /contacts[at0004]/addresses[at0005] -- phone
use_node ADDRESS /contacts[at0004]/addresses[at0006] -- fax
use_node ADDRESS /contacts[at0004]/addresses[at0007] -- email
}
}
}

We re-use nodes at0005, at0006 and at0007 but we do not assign a new at
code to them. Structurally, this is correct, but not semantically (i.e. we
reuse structure but not meaning). It is not the same a home phone number
than a work phone number. In fact, SNOMED uses diferent codes for each
case: a Patient home telephone number (code 429697006) and a
javascript:action(27)Patient work telephone number (code 428843000).

To sum up, it would be necessary to change the ADL grammar to support the
use of new definitions of term_codes in the archetype internal references,
something like:

use_node ADDRESS*[at1234]* /contacts[at0004]/addresses[at0005] -- phone


Finally, it is necessary to remember that the archetype slot (which is a
very similar use case) allows this kind of definition.

c_archetype_slot_id:
  SYM_ALLOW_ARCHETYPE type_identifier
| SYM_ALLOW_ARCHETYPE type_identifier *V_LOCAL_TERM_CODE_REF*
| SYM_ALLOW_ARCHETYPE error



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/d47e07fc/attachment.html


Archetypes for EN13606 RM

2008-08-08 Thread David Moner
Hello Pablo,

EN13606 (now ISO 13606) archetypes follow the same archetype model and ADL
syntactic representation as openEHR. What changes is the underlying
Reference Model, what you do is to constraint its specific classes and
attributes. OpenEHR archetypes are not directly compatible with the 13606
norm, but the can be easily converted to it, the standard itself includes
the details about this.

Unfortunately, the ISO 13606 RM is not publicly available, but you can buy
it at the ISO web page
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40784

With regard to the tools, you can try the LinkEHR Editor. It is a generic
archetype editor which works with any RM, including EN13606. Although it is
not a clinical oriented tool at this moment (we are working on it :-)), at
least guides you in defining archetypes following the RM structure. You can
find it at
http://www.linkehr.com/

Regards,
David Moner

2008/8/8 Pab pazospablo at hotmail.com

  Hi, I'm starting a research on EN13606. In many places mention that
 EN13606 defines archetypes to constraint it RM, but I can't find the spec of
 such archetypes.
 Anyone knows if there is a spec for EN13606 archetypes?
 If I make an archetype with the OpenEHR archetype editor, this archetype is
 compatible with the EN13606 RM? I see in OEHR website that OEHR is
 compatible with EN13606, but I don't know if this compatibility extends to
 the archetypes too.

 Thanks a lot!
 Pablo.

 --
 Atte.
 A/C Pablo Pazos Gutierrez
 Montevideo, Uruguay.
 www.SimpleWebPortal.net
 http://YuppFramework.blogspot.com
 http://groups.google.com/group/yuppframeworkphp


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080808/d944ef88/attachment.html


Updating government, commercial and academic use of openEHR

2008-07-31 Thread David Moner
Hello Thomas,

About your petition, there are some Changes in our group. Now it is called
Biomedical Informatics Group and the team is composed by Monserrat Robles,
Jos? Alberto Maldonado, David Moner and Diego Bosc?. Jesualdo is still at
the Murcia University.

We are currently involver in several pilot projects (most of the will begin
next september) in order to test semantic interoperability of legacy
information through archetypes (13606 or openEHR, to be determined) among
several hospital from different regions of Spain. We hope all those projects
will be a very good testbed for the adoption of these technologies :-)

PS: We met Gerard Freriks this week at Madrid and I think we will be soon
collaborating.

Best regards,
David Moner


2008/7/28 Thomas Beale thomas.beale at oceaninformatics.com


 On the pages

 http://www.openehr.org/shared-resources/usage/governments.html
 http://www.openehr.org/shared-resources/usage/commercial.html
 http://www.openehr.org/shared-resources/usage/academic.html

 there is information about current use of openEHR. We would like to hear
 from anyone with updates for these pages.

 - thomas beale


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080731/558f8b79/attachment.html


  1   2   >