Compact XML format...?

[Thomas Beale]

> Hi Heath,
> 
> On Tue, 2007-11-27 at 11:32 +0100, Heath Frankel wrote:
> >  As stated previously, the TDS is not
> > intended for information exchange, but as a tool for integration.
> 
> This may be getting too philosophical for my small brain.
> 
> I do apologize for being so "dense". But I cannot reconcile the
> difference you are claiming between "information exchange" and
> "integration".
> 
> Isn't 'integration' the process of validating/coordinating 'information
> exchange'?
> 

Heath is just using this terminology to distinguish between local systems that
feed into EHR systems from self-standing EHR/EMR systems which might talk to
each other. Actually, the division is not that clear - we use the TDS message
to handle CDA documents from some sources (which may be EMR-like) because it
works better, and writing a generic transform for CDA level 3 (fully
structured) is hard.

- thomas beale

Null Flavours, boolean values in openEHR

[Thomas Beale]

As a result of a conversation with John Arnett at NHS CfH and others on the
soomewhat controversial topic of Null flavours, I have started a short wiki
page on the topic at
http://www.openehr.org/wiki/display/spec/Null+Flavours+and+Boolean+data+in+openEHR

Feel free to comment.

- thomas beale

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Hi Koray,

At the moment we have not seen any need for multiple inheritance in 
archetypes. Do you have a particular use case? Note that C specialising 
B means that C conforms to B and to A. Nothing special needed to do that.

- thomas beale

Koray Atalag wrote:
> Hi,
>
> I have a question about the referencing of archetypes in specialization. And 
> also want to know if there is a limit on the number of specializations of 
> archetypes.
>
> For example:
>
> A is top level archetype
> B is specialization of A
> C has to further specialize B
> and there is possibility that D also has to further specialize C and so on.
>
> So in theory all childs have to conform to A. But the question is in C which 
> archetype will be written in 'specialize' section? A or A & B ? I assume it 
> is currently B. But in theory, possible one in a million, a particular 
> specialized archetype might conform to multiple parents...In my opinion this 
> is perfectly possible. So what happens?
>
> The other question is whether ADL or other limits the number of 
> specializations.
>
> Best regards,
>
> Koray Atalag, MD, Ph.D.
>
> Freelance consultant and developer
> http://koray.pathos-web.org
> skype: atalagk
>
>
>   
> 
> Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel 
> and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
please change your address book entry for me to 
Thomas.Beale at OceanInformatics.com
*Thomas Beale*
/Chief Technology Officer/ Ocean Informatics 
<http://www.oceaninformatics.com/>

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Grahame Grieve wrote:
>> At the moment we have not seen any need for multiple inheritance in 
>> archetypes.
>> 
>
> I see this as very similar to multiple inheritance in objects.
> There is no *need*, but there is useful things that can be done.
> The question is whether the price is justified.
>
> The use case is relatively simple in concept - allowing multiple
> inheritance would allow me to "cross-cut" concerns. I could write
> an archetype that only dealt a narrow aspect of an information
> structure, such as data integrity issues, and then use it across
> multiple archetypes, letting them focus on the big picture, not
> the minutiae of data integrity, which is mostly overlooked but
> ubiquitiously present.
>   
Hi Grahame,
in openEHR at least, data integrity is not defined or solved by 
archetypes - it is in the reference model.

- thomas

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Grahame Grieve wrote:
> hi Tom
>
> We are speaking about data integrity issues at different
> levels. Of course the reference model assures data integrity
> at that level; I was speaking of data integrity at the of
> data aquisition - calibration, methodology, attribution, these
> kind of things.
>
> Grahame
>
>   
ah - 'data quality' in other words - i.e. markers / meta-data relating 
to the data capture from the source, not the integrity of the data as 
represented on the openEHR system?

So far I would see such things as being catered for using compositions 
of archetypes - we currently have a lot of Cluster and Structure 
archetypes for this purpose. In all Entry archetypes (Observation etc), 
there is a 'protocol' attribute. It would be easy to create an item 
under protocol in those Entry archetypes that need it for 'data 
quality', which is a slot taking a subset of Cluster or Structure 
archetypes which report on data quality / capture. We already do a lot 
of re-use of this kind with archetypes.

I would be very hesitant to introduce the equivalent of multiple 
inheritance, because the true nature of inheritance is a notion of 
substitutability, or IS-A-ness. Using inheritance as a way of doing a 
mixin as can be done in software can be confusing.

It is interesting that even the Eiffel language, which has the smoothest 
and cleanest implementation of multiple inheritance (which Eiffel 
developrs use ubiquitously in application development), has evlved its 
semantics to distinguish 'conforming inheritance' and 'non-conforming 
inheritance'. The latter does not confer substitutability.

In the archetype space, 'substitutability' really translates to: can I 
use a parent archetype to process the data creating using child 
archetypes? The answer should (in my view) only be yes when the parent 
is ontologically a precursor of the children, e.g. the laboratory 
archetype is an ontological parent of laboratory-lipids. I think it 
would be hard to push the idea that some archetype containing no 
constraints apart from some data_quality items was an ontological parent 
of laboratory-lipids or any other archetype.

If we were to go more towards using software constructs in archetypes, I 
think I would be more interested in genericity (i.e. template types) 
rather than multiple inheritance.

- thomas

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

I should note that in the next generation of archetypes and tooling, 
archetype 'source' files for specialised archetypes will be 
'differential' in nature - i.e. valid ADL, but containing only added and 
changed items from the parent, just as for subclasses in an 
object-oriented programming environment. This will not affect archetypes 
already created, other than to generate warnings for inconsistencies. 
Over time, the tools will migrate to working off the differential source 
form, not the inheritance-flattened form we use today (with the 
difference only manifesting for specialised archetypes).

The current generation of the ADL worbench already shows the inherited 
items that are changed or added in specialised archetypes. The next 
release will enable the source files to be displayed, and will generate 
the appropriate warnings due to more sophisticated validation up the 
specialisation lineage. In practical terms, this translates to more 
maintainable archetypes and a better ability to see the differences 
between a given specialised archetype and the parent.

- thomas beale

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Andrew Patterson wrote:
>> I should note that in the next generation of archetypes and tooling,
>> archetype 'source' files for specialised archetypes will be
>> 'differential' in nature - i.e. valid ADL, but containing only added and
>> changed items from the parent, just as for subclasses in an
>> object-oriented programming environment.
>> 
>
> This is excellent news - I was going to launch into a tirade this
> afternoon about how archetype specialisation requires repeating
> the whole parent definition, and how much more robust OO subclassing
> is because of the differential nature! Good thing I held off on my venting.. 
> :)
>   
we have actually generated differential form archetypes - we are now 
adjusting some of the parser semantics, since now it has to check up the 
specialisation lineage for codes and a few other things, not just in the 
current archetype. A few weeks away from being solid I would say. Also, 
the ADL workbench now works more like a compiler - you can see what is 
compiled, what is not, and quickly reload anything already compiled.
> A while back there was talk of a confluence wiki being set up
> for storing of some of these thoughts?? Is anything happening in
> that area? I can help out if any admin is required - I just installed Jira
> and Confluence on my own machines..
>   
they are both going - as is the new website. All will be available very 
soon. For confluence, we will ust put in some minimal structure to save 
us from complete disorganisation - it will be an open wki. There will be 
plenty of opportunity for experts here to contribute and help shape 
these things - we just want them running in a basic reasonable form so 
people don't hate us when they see it ;-)

- thomas beale

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Koray Atalag wrote:
>
> In my former message, with the question of writing down B and A for 
> spelicalization section of C, I was proposing to write down the names of all 
> archetypes till the top level in specialization archetype- like an absolute 
> specialization path. This I think is not true multiple-inheritance as in any 
> instance of this specialized archetype, it will conform to only one parent 
> and not inherit non-conforming stuff from both parents, but the applications 
> working at the level of the parent archetypes shall be able to use this data 
> seamlessly. Maybe ridiculous but I want to name it as 
> 'multiple-generalization' :D
>
>   
Hi Koray,

now I understand what you want. You want the 'inheritance-flattened' 
form of a specialisation archetype - i.e with everything in it due to 
all parents. This happens to be the current form of archeypes anyway. We 
are converting over to the differential form used in object-oriented 
programming very soon (in .adls files), but the flat form will still be 
avalable (.adl files), generated and validated rather than directly 
created as they are today. In the current form of the .adl file we don't 
mention the lineage of parents all the way to the top. It would be easy 
enough to do, although I don't quite see what use it would be.

- thomas

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Erik Sundvall wrote:
> Hi!
>
>
>   
> Can one share important sub-parts without sharing view on process and
> structure. If so, will the information entered using the two different
> archetypes be computable in a similar way for e.g. decision support
> systems.
>   
this is why we have Cluster & Structure archetypes that are routinely 
shared via slots in various other archetypes - it provides a high degree 
of re-use, just as for classes referencing other classes (assocation, 
aggregation) in the object paradigm .

- thomas

Multiple parents and max number of nested specialized archetypes?

[Thomas Beale]

Dipak Kalra wrote:
> Dear Heather,
>
> Your 50c worth is really an excellent explanation. Well done, and I 
> hope many readers on the list will find it helpful.
>
You should see what Heather can do for $1

- thomas

parsing templates

[Thomas Beale]

Heath Frankel wrote:
> Greg,
> The XML representation of Archetypes are just as normaitive as ADL, the XML
> (just like ADL using a different syntax) is a serialisation of the Archetype
> Object Model representation of an Archetype.
>
> The OET files are a proprietary template definition used by the Ocean
> Template Designer product.  This Template Designer also has a Form Designer
> that can take a template definition and automatically build a form.  This
> form can be output as a Form Definition with control constraints expressed
> using the Archetype Object Model constraint object.  This form definition
> can be used within the Ocean EhrView web components to render this form
> using ASP.NET. 
>
>   
*we should be clear that the schema of templates is only 'proprietary' 
temporarily. It has been under development and use by Ocean and various 
users, including the UK NHS. Efforts are underway to finalise a draft 
specification of the template specification format for openEHR. As 
anyone will see from an .oet file, the model is relatively simple and is 
not in any way secret. It has just been a case of using something to see 
how well it works before proclaiming it a specification (or standard...).

The draft specification should be available within a few weeks.

- thomas beale

*

software development & starting out

[Thomas Beale]

Greg Caulton wrote:
> Thanks Seung,
>  
> Simple diagrams help me a lot :-)  My background is computer science 
> not medicine. 
>  
> I am starting to get the picture, this is exciting stuff.  In the past 
> I have the best HIS systems organize clinical data into a hierarchy 
> with little rhyme or reason, and custom to the client.  Writing 
> meaningful reports from flowsheet data was a disaster.  This could 
> really help a lot and gives me something to focus my implementation on 
> rather than a custom domain model.
>  
> I am sure I will post many more questions.
>  
*in a similar vein, you may find this paper useful as well - 
http://www.openehr.org/publications/health_IT/MedInfo2007-BealeHeard.pdf

- thomas beale

*

[archetypes.com.au] Functionality to compare two archetypes

[Thomas Beale]

Rong Chen wrote:
> Hi Sebastian!
>
> It is a very nice piece of work you and Stefan have done! I fully
> agree that we need to make archetypes compatibility checking explicit
> and this is a very good start.
>
> It will be useful to publish the algorithm that you used for
> comparison so others could comment. And the same algorithm could be
> implemented in different tools to ensure interoperability of
> archetypes.
>   
I have just been thinking about the specification for this area myself, 
and how we should approach it. In our software, we have just 
successfully done the 'flat-form' -> 'differential form' transformation 
of specialised archetypes, and we are now working on the differential -> 
flat-form transform (i.e. compression through inheritance). These two 
transforms allow hierarchies of specialisations to be properly 
processed. The excellent work Sebastian mentions above gives us some 
generic differencing, even between non-parent/child pairs. There are 
probably some more variants we need as well.

My proposal would be that once we have perfected the 
transformations/comparisons in software, that we document the algorithms 
in the Archetype Semantics document (currently an early draft lives here 
- 
http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/architecture/am/archetype_semantics.pdf).
 
This will provide guidance for other tool builders, and a solid 
reference for what we believe the semantics are.

- thomas

Security & Privacy with openEHR

[Thomas Beale]

tised, role-based and scoped such that there is a
> scheme for auto-granting of rights that ensures that a cardiologist with
> sufficient permissions always gets all the info he needs to create a
> full report?  however, auto-granting of rights may imply need for
> decision support. 
>
>   
or Artificial INtelligence ;-) See what I said above.

- thomas beale

Archetype documentation using XML + XSLT

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Archetype documentation using XML + XSLT

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Archetype documentation using XML + XSLT

[Thomas Beale]

Adam Flinton wrote:
>
> XSLT requires design not different from anything else.
>
> Use the unix app mentality i.e. that a given script does one job well & 
> then have a number of scripts & alles will be in ordnung.
>   
this is certainly the way to go alright. It does mean you need decent 
shell and/or other glue languages like make or Ant or whatever, but unix 
is good at that.

- thomas beale

Archetype documentation using XML + XSLT

[Thomas Beale]

Adam Flinton wrote:
>
> Oh & one quick ancillary  question 
>
> Does this/ Would this include Template (.oet) > XHTML via XSLT?
>
>   
*Adam,

The current (simple) .oet XML format for templates will soon be replaced 
with a proper openEHR XSD (also simple) which is more based on the AOM, 
and hence the AOM XSD, plus a converter. Turning this into HTML can be 
done however suits - better re-use of code from various archetype -> 
HTML conversions should be possible.

- thomas

*

Archetype documentation using XML + XSLT

[Thomas Beale]

Erik Sundvall wrote:
> Hi!
>
>   
> Actually I would prefer more emphasis on the view that the AM is the
> main reference and that ADL is a serialization of it. But a "reference
> form" of individual _archetypes_ needs a serialization not just an
> object model of course...
>   
The AOM is indeed intended as the definitive model of an archetype. 
However it is currently lacking in a few small areas - the 
ARCHETYPE_ONTOLOGY class needs some additional items for example. But in 
terms of explanatory power, object models are often not the best 
representation; they show a parser-output view. Syntax shows a 
parser-input view, and we humans are parsers (i.e. we read things 
serially). This is why we represent mathematics, java code, OWL, EBNF 
and many other things in the form of syntax.

By definition, an syntax is a 'serialisation' of its object model. But I 
don't think we can see all syntaxes as being the same. There is an 
OWL-RDF syntax for OWL, but it is unreadable gibberish, so humans 
usually read OWL-abstract. Similarly, Java programmers use the Java 
language rather than some XMI-like syntax. Syntaxes designed primarily 
for data serilialisation are not necessarily any good for human use, 
including comprehension, explanation of principles and therefore 
education. Most XML is of the latter kind - a direct serialisation of 
some object model. But you can't read it and understand it in the way 
that you can an abstract syntax (if anyone doubts this, just try reading 
OWL-RDF or XMI sometime).
> No matter how nice and pure ADL might be, I have seen people getting
> suspicious of "this OpenEHR-thing" when ADL has been focused too
> strongly. (Or people getting upset by having to learn yet another
> language, alternatively having been put of by the idea of having to
> write an ADL parser in a new environment.)  It's wonderful that there
> are now two "official" ways (ADL and XML) to serialize AM constructs,
> having even more would probably not hurt.
>   
there are also at least 2 open source parsers available. In an ideal 
world we would have just used an existing language, but none of the 
candidates proved up to the job. OWL probabaly comes closest., but still 
lacks some basic constructs that prevent it being easily usable for 
archetypes.

The power of ADL is important to me now as I am in the midst of defining 
extensions and semantics for specialisation. I originally thought I 
would do it directly as an object model, but found I had to go back to 
ADL to understand the semantics properly; changing / enhacing object 
models will come as a largely derivative step.

> Thomas Beale wrote:
>   
>>  Interesting links:
>> http://www.json.org/xml.html
>> 
>
> For some months I have been wanting to experiment with making a simple
> JSON implementation of the AM (and eventually also the RM) as a
> compact javascript- and Flash/Flex-friendly alternative to ADL/dADL
> and then submit it as an ITS for openEHR. I realize I won't have the
> time for it though so I drop the idea here hoping that someone else
> gets inspired.
>
>   
I think this is an excellent idea, and it would make a very useful ITS.

- thomas beale

Archetype documentation using XML + XSLT

[Thomas Beale]

Adam Flinton wrote:
>   
>> Other limitations on using XML - it's a no-show for enterprise scale 
>> databases 
>> or information processing. All that wasted space starts to count when you 
>> have 
>> to buy two ?20,000 high availability RAID disk arrays instead of oneand 
>> plus 
>> the bandwidth wastage when there are millions of messages rather than just a 
>> few. Yes, binary compression helps, but it just shifts disk and bandwidth 
>> loss 
>> to the CPU. There are many better ways to represent data for large-scale 
>> deployments than XML (even the dADL syntax from ADL does 100% better in 
>> space, 
>> and represents all object-oriented constructs unambiguously).
>>   
>> 
> You have got to be kidding me on this one.
>
>   
no kidding. You just have to do the maths. 2 years ago I was in a CfH 
meeting where it was made clear that the volumetrics on the projected 
number x size of HL7v3 prescription (and related) messages was going to 
blow out the budget for telecomms expenditure by over 50%. Database 
volume estimates made by Oracle for the Spine on the basis of whole of 
UK, HL7 XML messages were shown to be simply uneconomic. In our own EHR 
product we have had to resort to various kinds of compression, which 
impact on performance, and we have to have larger disc arrays than would 
be needed if the data were represented in a more efficient way. Our 
engineers are currently looking at replacing XML altogether in the 
persistence layer.

Of course organisations that have unlimited budgets may not notice this, 
but for everyone else it's important.
> Having done XML messaging in very large retail systems (major
> supermarket chains in the EU & US), mobile phone systems, home
> office/criminal justice system & now the CFHyou simply have got to
> be kidding.
>   
it's not the size of the organisation that matters, it's the amount of 
data generated and rate of data generation. The more data (and users), 
the more disk space / bandwidth / CPU (if using 
compression/decomprssion) you need. Fact of life - if your data gets big 
enough, you will hit a wall just using XML.

> umm...where to even startoh yes how about...
>
> "XML is a very commonly used standard with thousands of tools in
> existence from routing engines, to processing engines to parsers to
> database layers "
>
> or maybe
>
> "XML is THE standard in enterprise level messaging systems with
> standards such as SOAP, EbXML, OAGI BODS etc.etc."
>
> or maybe :
>
> "XML integrates easily with existing web infrastructures by use of such
> mechanisms as AJAX, Rest JSON etc".
>
>
> Now wrt ADL.
>
> Adam
>
>   
Although the above are just marketing statements, the standards do 
indeed exist - how else would industry even start to cope with XML? My 
point is that it is so horribly ineffcient that that there is a general 
need for solutions (and these are emerging) to the concomitant costs of 
very large amounts of data. That's why all the binary XML work and work 
on alternative representations - once you get over a certain size, you 
have to use something else, or a serious compression approach.

- thomas

BTW you only need one good open source parser for any language on each 
platform. I'm not quite sure of the value of having 20 competing ones, 
all with different sets of bugs, maintainers and conformance statements

*
*

Archetype documentation using XML + XSLT

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Archetype documentation using XML + XSLT

[Thomas Beale]

Adam Flinton wrote:
> Peter Gummer wrote:
>   
>> Adam Flinton wrote:
>>
>>   
>> 
>>> I have already noted how using text children of an element to use a value 
>>> vs a std "value" attribute in the archetype xml  inflates the file sizes.
>>> 
>>>   
>> So you aren't convinced by Thomas's objection that putting the values in XML 
>> attributes would make a mess of the XPath?
>>   
>> 
>
> No as the existing paths aren't xpaths at all e.g..
>
> 
>
> let alone something like
>
> local::at0013
>
> It's simply a matter of parsing the file into an AOM.
>
>   
Adam,

I was not talking about openEHR paths, I was talking about any Xpaths. 
If you define an Xpath based on a given model entity being an XML 
attribute, it will be different from the path to the same thing based on 
the model entity being an XML element. If that path was shared, e.g. in 
a tool, or published for some reason, and you change your XML 
representation for efficiency reasons, your published Xpath doesn't work 
any more.

Separately, in openEHR, we use Xpath-compatible paths. A path like

/items[at0001]/items[at0004]

 is machine converted to the Xpath

/items[@archetype_node_id = "at0001"]/items[@archetype_node_id = 
"at0004"]

Not hard to guess why we do that;-)

Portable paths are the basis of portable queries; portable queries are 
the basis of decision support having any hope of being able to define 
queries once and for all into a standardised health record rather than 
havig to have queries written not just for each target system type, but 
for each installation, if database schemas differ (and they do in the 
NHS environment).

- thomas beale



*
*

Regex in Archetypes must include TYPE

[Thomas Beale]

Adam Flinton wrote:
>>
>> No need to do that, Adam, just wrap the regex within parentheses. So taking 
>> the example you gave, the correctly-wrapped regex would be:
>>
>> Include entries
>> openEHR-EHR-CLUSTER\.(checklist_item-general-cvs1.v1|checklist_item-general-cvs2.v1|checklist_item-general-cvs3.v2|checklist_item-general-cvs4.v2draft|checklist_item-general.v1|checklist_item-general.v2|checklist_item-general.v3)
>>
>> The code to generate this is trivial in any programming language (assuming 
>> your programming language has the ability to concatenate strings, which I 
>> reckon is a safe bet). Unless you're programming in assembly language, it's 
>> probably one simple line of code.
>>
>>   
>> 
> Hum.
>
> I agree that that would work but it's still wrong in principle IMHO i.e. 
> then the regex is still a pseudo/meta regex i.e. it requires processing 
> to turn it into a valid regex.
>
> This would have to be duplicated in all the different implementations 
> etc.etc.
>
>   
*All,

I also agree with Adam. A regex should be able to be used over a 
population of strings (identifiers in this case) and have the effect of 
filtering out what you want. Having to put the regex together first is 
inviting problems - some implementations will forget, others will do it 
wrongly, the specifications of how to do it will change

Practically speaking this does not change the specifications, but I 
suspect we should put some guidance in to the effect that regexes based 
on full identifiers should be used in archetype slots.

- thomas

*

Regex in Archetypes must include TYPE

[Thomas Beale]

Well the problem here is that the specifications don't actually say 
anything about the regexes, or even that you have to use regexes to 
identify archetypes in slots - it is just one way of doing it. So any 
tools today that take a particular approach to regexes are already 
outside the standard.

I think what we should probably do is to state that regexes, if used, 
must be assumed to be usable as a filter on whole archetype ids without 
prior modification. This still does not prevent some tool using the 
short regexes now in use in the archetype editor, since the clearly can 
be used at a technical level - it is just that they might create errors. 
And there may be some short patterns which are actually correct. I'm not 
sure how we can formally state this

- thomas


Peter Gummer wrote:
> Thomas Beale wrote:
>   
>> I also agree with Adam. A regex should be able to be used over a 
>> population of strings (identifiers in this case) and have the effect of 
>> filtering out what you want. ...
>>
>> Practically speaking this does not change the specifications, but I 
>> suspect we should put some guidance in to the effect that regexes based 
>> on full identifiers should be used in archetype slots.
>>   
>> 
>
>
> Surely the specifications should be stronger than just guidance. 
> Existing tools that are massaging the regex will cease to work if they 
> are given a full regex. It would be a breaking change, so I think it 
> should be spelled out in the specification. Otherwise, tools are going 
> to have to try to do some clever guesswork to decide whether a given 
> pattern is intended to match the full archetype id or just the domain 
> concept part of it.
>
> - Peter
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Differential display

[Thomas Beale]

I won't contribute much to this discussion, except to say that the 
'problem' here is /duplication/ of information - that is, the same 
information occurring in a document or being created in a system in two 
different ways, usually narrative and structured, but not always this 
combination. CDA is always constructed of narrative, with optional 
structured content which in theory duplicates the narrative content, or 
may be a subset of it. The problem for clinicians therefore is to get 
rid of the duplicate stuff for display.

So the need to display or not is a consequence of the duplication which 
is the underlying problem. Perhaps a better name for the 2 parts would 
be 'primary' and 'duplicate' or 'alternative rendition' or similar.

- thomas


Thilo Schuler wrote:
> Hi everybody
>
> I know CDA which requires *all* information to be in human-readable, 
> textual form (Level 1). Optionally there can be references to 
> machine-readable entries (Level 3). This design makes sure no 
> information is disclosed from a clinician that views the document only 
> with as simple XSLT-transformed XHTML.
>
> I must admit I didn't quite understand the use case.
>
> 
>
> This does mimic the CDA approach but does have the added benefit
> that the displayed information can be structured as well (a
> requirement from our customers who want to mix the textural
> content and structured medication orders (ie not duplicate these
> in the textural display).
>
>  
>
> Maybe you could explain it a bit further.
>
> But in general I feel - probably similar to Ian and Gerard - it is not 
> a good idea to bring view-related stuff into an archetype. Thus, I 
> wouldn't call it "display" and "non-display".
>
> However, think the there is a gowing need to have a possibility to 
> easily use archetypes together with HL7 CDA. As Stefan also pointed 
> out, many national ehealth programs have opted to use this part of 
> HL7v3! This is a chance for openEHR as it is way ahead of the HL7 
> template initiative with respect to clinician involvement, which is 
> crucial.
> So maybe, we could discuss whether to create an CDA-compatibility 
> SECTION archetype with a Level1 and a Level3 section. 
>
> Cheers, Thilo
> 
>
> _______
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Differential display

[Thomas Beale]

Ok - so we know that some data are duplicated, but not how well, or to 
what extent. If  Sections were used to mark this, ten it is up to the 
applicatoin to decide how to render it. A safe rendering might be to 
mark the 'duplicated' section in some way - e.g. a line around it and 
"(duplicate)" somewhere - how this is done is up to the application 
system. Hiding may be safe in some environments that are dealing with 
content whose creation they know about, but it is always the choice of 
the application.

The thing to remember if Section archetypes are used is that the 
presence of this duplication thing must be known ahead of time, which it 
sounds as if it normally would be, because it is to do with how 
applications are constructed.

- thomas

Heath Frankel wrote:
> Actually the use case is as follows:  
>
> As part of a clinical encounter the practitioner authors a textual clinical
> note to be included along with structured content.  BP is entered in a
> structured form and the system copies the result into the textural clinical
> note automatically as is done in a lot of existing clinical systems (which
> are traditional primarily texturally oriented, with a little bit of
> structured data).  So the textual clinical note contains a combination of
> manually entered content and system generated content from structure
> content, the user has the ability to edit and remove the auto generated
> content which may deviate from the original content entered in a structured
> manner.  Therefore, the textual note and the structured data need to both be
> viewable because there is no way of knowing what structured content was
> duplicated in the textual note and what original content was manually
> entered in the textual note.  Once the structured content is copied into the
> textual note, it has lost its connection with the original content.
>
> This may not seem idealistic but this the reality of what existing systems
> do and existing users are used to.  If openEHR is to be taken up by existing
> system vendors and accepted by their users, we must support this existing
> non-idealistic paradigm in a way that does not too much overhead on the
> system and its implementers.
>
> I would suggest that duplication of data is better than accidently hiding
> data, especially when the users are used to having two ways of displaying
> the same data.
>
> Heath
>
>   
>> -Original Message-
>> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
>> bounces at openehr.org] On Behalf Of Thomas Beale
>> Sent: Tuesday, 19 August 2008 7:59 AM
>> To: For openEHR technical discussions
>> Subject: Re: Differential display
>>
>>
>> I won't contribute much to this discussion, except to say that the
>> 'problem' here is /duplication/ of information - that is, the same
>> information occurring in a document or being created in a system in two
>> different ways, usually narrative and structured, but not always this
>> combination. CDA is always constructed of narrative, with optional
>> structured content which in theory duplicates the narrative content, or
>> may be a subset of it. The problem for clinicians therefore is to get
>> rid of the duplicate stuff for display.
>>
>> So the need to display or not is a consequence of the duplication which
>> is the underlying problem. Perhaps a better name for the 2 parts would
>> be 'primary' and 'duplicate' or 'alternative rendition' or similar.
>>
>> - thomas
>>
>>
>> Thilo Schuler wrote:
>> 
>>> Hi everybody
>>>
>>> I know CDA which requires *all* information to be in human-readable,
>>> textual form (Level 1). Optionally there can be references to
>>> machine-readable entries (Level 3). This design makes sure no
>>> information is disclosed from a clinician that views the document only
>>> with as simple XSLT-transformed XHTML.
>>>
>>> I must admit I didn't quite understand the use case.
>>>
>>> 
>>>
>>> This does mimic the CDA approach but does have the added benefit
>>> that the displayed information can be structured as well (a
>>> requirement from our customers who want to mix the textural
>>> content and structured medication orders (ie not duplicate these
>>> in the textural display).
>>>
>>>  
>>>
>>> Maybe you could explain it a bit further.
>>>
>>> But in general I feel - probably similar to Ian and Gerard - it is not
>>> a good idea to bring view-related stuff into an archetype. Thus, I
>>&

Is there a UML class diagram for templates?

[Thomas Beale]

Adam Flinton wrote:
> Preferably in Eclipse UML2...?
>
> If so does it then include the archetypes class model as well?
>
>
>   
*The UML for the forthcoming openEHR template model is online in the 
latest AOM draft (some changes to AOM of ADL 1.4 vintage) and Templates 
draft, available at the page 
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes

However, if you are after UML for the current .oet file format, I don't 
think it is published, but I would imagine it already exists - 
publishing it should be no problem. Can you indicate which one you are 
after?

- thomas beale

*

Differential display

[Thomas Beale]

Andrew Patterson wrote:
>
>
> I agree that the narrative form "wins" but I think the HL7 people
> would be horrified by the thought that CDA structured content
> was generating textual content which could then be secondarily
> changed - it is a clearly broken use case and noone would
> design new software that way - but I understand that there
> are some legacy systems in Australia that do it this way and
> that Ocean needs to come up with solutions around this. But
> I am quite keen that solutions to this particular outlying
> use case don't impact on solutions to (b) and (c) unless
> we all understand the ramifications.
>
>   
well, Ocean is just one vendor that has products that have to interface 
with Medical Director, which is the most widely entrenched GP desktop 
package in Australia. I think the main thing is how the semantics of 
data in a package like MD translates to archetyped structures, which are 
independent of the vendor product trying to extract data from the GP 
dekstop.

- thomas beale

[openEHR-announce] UK openEHR training 24/25 July CHIME, UCL (Archway, London)

[Thomas Beale]

Paria,

See the openEHR home page > Events

- thomas beale

P?ria Kashfi wrote:
> Hi all,
> Has anyone any idea about this course?
> I want to apply but it seems that the link doesn't work anymore
>
> Regards
> paria
>
> On Jul 10, 2008, at 12:59 PM, Thomas Beale wrote:
>
>>
>> Dear all,
>>
>> there is an openEHR training course at CHIME, UCL, in London on 24/25
>> July. This course will run for 2 days, and will be presented by myself,
>> Dr Ian McNicoll of NHS Scotland and Dr Dipak Kalra of CHIME. See
>> http://www.chime.ucl.ac.uk/news/latest/news-20080616a.htm for details.
>>
>> - thomas beale
>>
>>
>> ___
>> openEHR-announce mailing list
>> openEHR-announce at openehr.org <mailto:openEHR-announce at openehr.org>
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce
>
> PhD Student 
> IDC | Interaction Design Collegium 
> Department of Computing  Science and Engineering 
> Chalmers University of Technology
>
> Email: hajar.kashfi at chalmers.se <mailto:hajar.kashfi at chalmers.se>
> Office:+46 (0)31 7725407 
> Mobile Phone: +46 (0)707222815 
> Postal adress:
> IT University of G?teborg
> 412 96 G?teborg, Sweden 
> Visit: Room Simula B, House Svea, Campus Lindholmen
>
> 
>
> _______
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Is there a UML class diagram for templates?

[Thomas Beale]

At the moment I would say that we are not too far off where you want to go. As
you know there are a couple of efforts to produce an up-to-date tool-based UML
expression of openEHR. Hopefully one or both will come to fruition quickly.
>From there we can add in the TOM part of the model, which as you can see from
the draft is only a small number of classes.

- thomas beale


> Thomas Beale wrote:
> > Adam Flinton wrote:
> >   
> >> Preferably in Eclipse UML2...?
> >>
> >> If so does it then include the archetypes class model as well?
> >>
> >>
> >>   
> >> 
> > *The UML for the forthcoming openEHR template model is online in the 
> > latest AOM draft (some changes to AOM of ADL 1.4 vintage) and Templates 
> > draft, available at the page 
> >
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes
> >
> > However, if you are after UML for the current .oet file format, I don't 
> > think it is published, but I would imagine it already exists - 
> > publishing it should be no problem. Can you indicate which one you are 
> > after?
> >
> > - thomas beale
> >
> > *
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >   
> Sorry for the delay.
> 
> What I was wondering about is whether we had/could have a complete model 
> for OpenEHR Templates + Archetypes.
> 
> i.e. if one had the AOM in Eclipse XMI then one could generate Java 
> classes or 
> 
> e.g.
> 
> http://www.eclipse.org/modeling/m2t/?project=jet
> 
> or if you want to go the whole hog:
> 
> http://www.openarchitectureware.org/
> 
> & one could create Graphical editors via GMF, compare models, run OCL 
> constraints etc.etc.
> 
> What is more, maintaining the AOM /TOM via the Eclipse UML tools means 
> that the model is machine readable/processable and the tooling is 
> free/open source (though you could use tooling based on the eclipse UML 
> e.g. Rational etc.)
> 
> It also means that the model can be maintained with a degree of 
> isolation from persistence formats per se via OAW mappers etc allowing 
> one to bring in/emit differing versions of ADL, differing versions of 
> templates etc.
> 
> We are nearly there wrt the AOM. What we are lacking is a UML class 
> model of the "TOM".
> 
> So if you have the UML class diagram for Templates, that would be great. 
> If it's already in Eclipse XMI/UML that would be even better.
> 
> Adam
> 
> ***
> This  message  may  contain  confidential and  privileged  information.
> If you  are not the  intended recipient  you should not  disclose, copy
> or distribute information in this e-mail or take any action in reliance
> on its contents.  To do so is strictly  prohibited and may be unlawful.
> Please  inform  the  sender that  this  message has  gone astray before
> deleting it.  Thank you.
> 
> 2008 marks the 60th anniversary of the NHS.  It's an opportunity to pay
> tribute to the NHS staff and volunteers who help shape the service, and
> celebrate their achievements.
> 
> If you work for the NHS  and  would like  an NHSmail  email account, go
> to: www.connectingforhealth.nhs.uk/nhsmail
> ***
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



-- 
Thomas Beale
Chief Technology Officer Ocean Informatics

Is there a UML class diagram for templates?

[Thomas Beale]

oops - one or both of you is using an out of date version of teh template
model - the current draft is quite different, and also note that the AOM 1.5
draft includes a couple of UML changes needed for templates - see section 5 of
the Template specification  on the wiki page at
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes

- thomas


> Hi!
> 
> I imported an openEHR UML (XMI) file created by Eric Browne (using
> BOUML) into the Eclipse-based Topcased environment a couple of minutes
> ago and saw that most template related classes were implemented. Using
> Topcased autolayout and some manual adjustments produced a diagram,
> see http://www.imt.liu.se/~erisu/2008/08/rough-template-diagram.gif. A
> nicer diagram by Eric Browne is available at
> http://www.healthbase.info/openehr/UML/index.html#refpackage138545
> (The entry link to start exploring his work is at
> http://www.healthbase.info/openehr/UML/index-withframe.html)
> 
> Eric: What is the copyright status of your model files? Can I share
> the source XMI file and any derived works in public? If  you don't
> have another license in mind I'd suggest using
> http://creativecommons.org/licenses/by/3.0/
> 
> As written in some other threads, more info about a related experiment
> (aoutoconverted from openEHRs MagicDraw files) is available at
>
http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML
> Links to source files are available in a recent comment on that page.
> 
> Thomas: What tool are you currently using to produce UML for the
> template spec document?
> 
> Best regards,
> Erik Sundvall
> erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
> 
> On Wed, Aug 27, 2008 at 13:49, Adam Flinton  wrote:
> > Thomas Beale wrote:
> >> Adam Flinton wrote:
> >>
> >>> Preferably in Eclipse UML2...?
> >>>
> >>> If so does it then include the archetypes class model as well?
> >>>
> >>>
> >>>
> >>>
> >> *The UML for the forthcoming openEHR template model is online in the
> >> latest AOM draft (some changes to AOM of ADL 1.4 vintage) and Templates
> >> draft, available at the page
> >>
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes
> >>
> >> However, if you are after UML for the current .oet file format, I don't
> >> think it is published, but I would imagine it already exists -
> >> publishing it should be no problem. Can you indicate which one you are
> >> after?
> >>
> >> - thomas beale
> >>
> >> *
> 
> > Sorry for the delay.
> >
> > What I was wondering about is whether we had/could have a complete model
> > for OpenEHR Templates + Archetypes.
> >
> > i.e. if one had the AOM in Eclipse XMI then one could generate Java
> > classes or 
> >
> > e.g.
> >
> > http://www.eclipse.org/modeling/m2t/?project=jet
> >
> > or if you want to go the whole hog:
> >
> > http://www.openarchitectureware.org/
> >
> > & one could create Graphical editors via GMF, compare models, run OCL
> > constraints etc.etc.
> >
> > What is more, maintaining the AOM /TOM via the Eclipse UML tools means
> > that the model is machine readable/processable and the tooling is
> > free/open source (though you could use tooling based on the eclipse UML
> > e.g. Rational etc.)
> >
> > It also means that the model can be maintained with a degree of
> > isolation from persistence formats per se via OAW mappers etc allowing
> > one to bring in/emit differing versions of ADL, differing versions of
> > templates etc.
> >
> > We are nearly there wrt the AOM. What we are lacking is a UML class
> > model of the "TOM".
> >
> >
> > So if you have the UML class diagram for Templates, that would be great.
> > If it's already in Eclipse XMI/UML that would be even better.
> >
> > Adam
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



-- 
Thomas Beale
Chief Technology Officer Ocean Informatics

text and description

[Thomas Beale]

Koray Atalag wrote:
> Hi there,
>
> I had a similar issue lately and just came up with an idea for 
> local/custom terminology bindings - i.e. linking at codes to external 
> terminologies not formally defined in UMLS or elsewhere.
>
> My problem was to bind terms to latest version of SNOMED through which 
> I access from UMLS. In the Ocean Archetype Editor when you want to add 
> a new terminology, a list is presented (possibly taken from UMLS 
> knowledge sources) which contains only SNOMED CT 2002 version. So I 
> added SNOMED_CT manually via text editor:
>
> ontology
> terminologies_available = <"MST2", "UMLS", "SNOMED_CT">
>
> NOTE: editor does not like spaces in term name!

Hi Koray,

that's because it is illegal in the openEHR specification - 
TERMINOLOGY_ID type in the Identification packge in the Support IM. Also 
note that the only names that can be used are (crrently) the UMLS names 
- see the spec. Also the version/revision should be indicated in () 
after, e.g.

SNOMED_CT(2008v2)::123456

or however they are identifying it. We need to determine how UMLS is 
naming all of these variants / releases.

>
> So custom/local terminologies can be handled this way and the 
> implementation will be left to developersBUT this may result in 
> different implementations which may render interoperability in the 
> long run
>
> So I suggest a sub-section within ontology section where used 
> terminologies are declared explicitly; i.e. "umls": 2008AA version of 
> NLM UMLS knowledge sources. Perhaps an URI and other details can be 
> specified (i.e. WSDL). I think it is easier for the community to agree 
> on such a naming convention.

you can already do this -

umls(2008AA)::123456 etc


- thomas beale

text and description

[Thomas Beale]

Gerard Freriks wrote:
> Dear all,
>
> The European Institute for Health Records has created a registry of 
> coding systems.
> In the (near) future they expect to be the place where coding systems 
> and their meta-information are registered so an URL and unique 
> identifying number will suffice.
>
> Will this be the way to go?

I didn't know of this body. How does their registry correlate to the 
UMLS list? How do they handle revisions of terminologies? How do they 
handle language variants (including ones that are of earlier revisions, 
or are partial)?

- thomas beale

text and description

[Thomas Beale]

Ian McNicoll wrote:
> Hi Thomas,
>
> According to Support_IM 5.3.2
>
> "Valid identifiers that can be used for this attribute for 
> terminologies include but are not limited to the
> following:
> ? "openehr"
> ? "centc251"
> ? an identifier value from the first column of the US National Library 
> or Medicine (NLM)
> UMLS terminology identifiers table below, in either of two forms:
> - as is, e.g. "ICD10AM_2000", "ICPC93";
> - with any trailing section starting with an underscore removed, e.g. 
> "ICD10AM"."
>
> So, as far as I can see it should be possible to use a local 
> identifier, although not supported by the editors at present, the 
> issue being how to namespace the terminology uniquely.
>
> I could not see anything in other documentation
> For Olof's project I am proposing to use e.g.
>
> "se.chalmers.MUKOS::mukos-reaktion"

Ian,

only problem - that identifier would not be allowed in the (imminent) 
Release 1.0.2 of openEHR (see 
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/roadmap.html)

4.3.12.1 Identifier Syntax
The syntax of the value attribute is as follows:
#  production rules 
terminology_id: name [ ?(? version ?)? ]
name: V_NAME
version: V_VERSION
#  lexical patterns 
V_NAME: [a-zA-Z][a-zA-Z0-9_-/+]+
V_VERSION: [a-zA-Z0-9][a-zA-Z0-9_-/.]+



*
*

ADL workbench - specialisation beta

[Thomas Beale]

We unfortunately recently uploaded an installer for the specialisation 
version of the ADL Workbench that contained a bug which makes it hang 
for locales other than "en" locales. Anyone who has downloaded this 
please download the latest version now there instead (see 
http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/doc/adl_workbench_help.htm).

- thomas beale

{Disarmed} Re: text and description

[Thomas Beale]

Sam Heard wrote:
>
> Hi All
>
> I think we are addressing an issue that will come up in templates as 
> well. How to add terms from a local terminology directly into a 
> template. Local is used for the archetype terms ? I have wondered if 
> we should use a template: namespace for terms that are created only in 
> the template but for internationalisation.
>

I would expect to do it in the same way as for archetypes - binidings. 
Just the same, but in templates.

- thomas beale

Q on openEHR XML-schema versioning

[Thomas Beale]

We are about to publish Release 1.0.2 of the openEHR specifications. The 
CRs in this release have necessitated some very small (non-data 
affecting) changes in the schema BaseTypes.xsd (impact statement of 
Release 1.0.2 at 
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/release_notes_1.0.2.htm
 
; published Release 1.0.1 schemas at 
http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html)

The question has come up as to how changes in versions of the schemas 
should be identified. Currently the schemas have the following kind of 
heading:




http://www.w3.org/2001/XMLSchema"; 
xmlns="http://schemas.openehr.org/v1";
targetNamespace="http://schemas.openehr.org/v1"; 
elementFormDefault="qualified" version="v1.0.1"
id="BaseTypes.xsd">


Firstly, openEHR publishes a number of schemas, not just one. Each 
carries only the release id, but not an individual version number. I 
would argue that they should carry an individual version id (and 
possibly not the Release number?). Can the XML experts here comment on 
what the usual way to manage the kind of componentised schemas we use in 
openEHR is? Should we, as of this release put a per-schema version id in 
each schema?

Secondly, you will notice that these schemas are authored by Ocean 
Informatics. This has been the case historically (I believe the 
community understands the 'bootstrap' nature of openEHR development), 
but of course is unlikely to remain so. Adam Flinton (NHS) and others 
will certainly propose an improved Archetype.xsd, and most likely 
similar improvements to the other schemas for forthcoming releases. When 
this happens, I expect that the 'author' line will change to something 
like "Authored by openEHR XML Schema project" or similar. However, for 
this 1.0.2 release, I guess it should stay as is, since at least it 
allows people to know the author, and who to blame, rather than the 
schemas being anonymous. Objections to this are welcome of course.

I am more concerned to correct the version id situation.

All feedback welcomed.

- thomas beale

Q on openEHR XML-schema versioning

[Thomas Beale]

Andrew Patterson wrote:
>> CRs in this release have necessitated some very small (non-data
>> affecting) changes in the schema BaseTypes.xsd (impact statement of
>> Release 1.0.2 at
>> http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/release_notes_1.0.2.htm
>> ; published Release 1.0.1 schemas at
>> http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html)
>> 
>
> I am going through the 1.1 release candidate changes and it appears
> that some of these are going to be 'breaking' changes to the
> schema. So our plan for handling the 1.0.2 schema should have
> an eye out to 1.1, which will need to be handled in a
> somewhat compatible manner..
>   

there will certainly be breaking changes in the archetype schema, which 
doesn't not cause a great problem as long as it is handled properly. 
Handling it properly means tools of the future knowing the difference 
between the current Archetype.xsd schema and later more efficient variants.

>   
>> Firstly, openEHR publishes a number of schemas, not just one. Each
>> carries only the release id, but not an individual version number. I
>> would argue that they should carry an individual version id (and
>> possibly not the Release number?). Can the XML experts here comment on
>> what the usual way to manage the kind of componentised schemas we use in
>> openEHR is? Should we, as of this release put a per-schema version id in
>> each schema?
>> 
>
> I don't think the version id etc _inside_ the schema file is too
> important - I worry a great deal about the XML instances that are out
> there and how instances can be automatically matched up to their
> corresponding schema files. That to me is the fundamental issue.
> I would contend that 1.1 will require a change to the schema
> namespace to "http://schemas.openehr.org/v1.1"; or
> "http://schemas.openehr.org/v2"; or "http://schemas.openehr.org/2008/12";
>  (if we decide to break
> the correspondance between schema set version and openehr
> release version)
>   

ok - this approach more or less replicates the release id approach 
already in use, but converts it to a URL. We already have the URL 
pattern http://www.openehr.org/releases/N.M.P, so we could do 
http://www.openehr.org/releases/N.M.P/schemas

Apparently it is not always expected that the URL mentioned in a schema 
actually exists so http://schemas.openehr.org/v1.0.2 could be used as 
well. Or we could create it for real. (What are the requirements here?)


> I do not know how the instance versioning will work with
> multiple indepedant schemas (I presume Thomas is referring
> to the Template schema vs AM schema etc). I think schemas
>   

well actually in this case I was thinking more of the RM schemas like 
Basic_types.xsd and the others - 
http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html . 
Starting from Composition.xsd, there is a cascade of nested inclusions 
down to Basic_types.xsd. If an XML document representing a Composition 
is to correctly indicate its schema, it should point to e.g. 
http://www.openehr.org/releases/1.0.2/schemas/Composition.xsd or 
http://schemas.openehr.org/1.0.2/Composition.xsd

Inclusions are curently done with a statement like



which does not mention the version of the included schema, so one 
assumes it is from the same release, which is the effect we want. Is 
this the orthodox way to do this in XML land?


- thomas

definition of object_path

[Thomas Beale]

Andrew Patterson wrote:
> The grammar (pasted in the spec) for the use_node
> slot refers to object_path which is not actually
> defined in the path grammar. Furthermore, I can't
> actually tell from the spec whether use_node
> is restricted to absolute paths, or whether it can
> also accept relative paths.
>   

this should be 'absolute_path', which is in the path syntax section. 
Must be a typo that slipped by some time ago... I have corrected it now 
in the ADL 1.5 draft.

> archetype_internal_ref:
>   SYM_USE_NODE type_identifier c_occurrences object_path
>
> So obviously the grammar needs to be updated to
> use the right path rule, but I am also thinking that
> perhaps the use_node section needs some
> explanation of what types of paths are allowed
> to be used and what the ramifications are
> if relative paths are also acceptable.
>   

only absolute paths are allowed (so far; I think anything else will be 
too complicated and I don't see any strong need)

- thomas beale

list_open

[Thomas Beale]

Andrew Patterson wrote:
> I have a vague recollection of discussing this before,
> but I can't for the life of me work out what the
> "list_open" field in AOM C_STRING class is
> for. It is described as being for when a
> constraint is "non-exhaustive" but I don't know what
> this means in practical terms. I also can't
> work out how the "non-exhaustive" lists would be
> specified in ADL - I was guessing
>
> "a","b", ...
>
>   

In dADL, the feature you are thinking of is there to allow the parser to 
correctly determine the types of:

<1.0, 2.0, 3.0>   -> List
<1.0>  -> Integer
<1.0, ...>-> List

same syntax for any other basic type. It's not a wonderful piece of 
syntax design, but it enabled us to stick to the goal of having no 
typing information at all for basic types in dADL

In C_STRING, list_open is a constraint flag that says whether or not 
only the values in the list are allowed to be used; True = other values 
possible (i.e. the listed values are just 'preferred'). The same syntax 
is used, e.g. {"a", "b", ...} is an open list.


- thomas beale

{Disarmed} Re: Q on openEHR XML-schema versioning

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

{Disarmed} Re: {Disarmed} Re: Q on openEHR XML-schema versioning

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

XML 1.0 fifth edition

[Thomas Beale]

How much of a problem is the issue reported here to openEHR - 
http://dpcarlisle.blogspot.com/2008/10/xml-10-fifth-edition.html ?

- thomas beale

{Disarmed} Re: Q on openEHR XML-schema versioning

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 

{Disarmed} Re: Q on openEHR XML-schema versioning

[Thomas Beale]

I can see some better schemes in the offing from the experts! I would 
not think we should change anything in the current schema approach, as 
this is a minor release. I propose to change only the version ids in the 
relevant schemas to reflect the small change in Base_types. We will 
leave it to a new major version (1.1 or later) to change tack on how to 
manage schema versions. I would suggest that XML experts here would need 
to develop a bullet-proof approach to this (as opposed to just 
suggestions), so that we can implement it in a major release.

- thomas beale

Heath Frankel wrote:
> Hi Andrew,
> See below.
>
> Heath
>
>   
>>> The question is, what do we do when we do have a data breaking schema
>>> change, like potentially in r1.1?  I suggest that we just go with
>>> http://schemas.openehr.org/v1.1 and we can assume the old
>>> http://schemas.openehr.org/v1 meant r1.0.x.  It wasn't expected to have
>>>   
> such
>   
>>> a substantial schema change until r2 but I guess that is the reality of
>>> software.
>>>   
>> I am also concerned about 'non-breaking' changes though - well, it depends
>> on your definition of a breaking change - but say we add an
>> optional element to a xml type? This doesn't break any existing data
>> because all instances will still comply with the new schema - however,
>> new instances will now potentially not comply with the old schema. Do
>> we consider these breaking changes? Are we expecting to create a
>> new namespace if we do this type of change?
>> 
>
> [Heath Frankel] 
> I understand your point here but if we cannot have some kind of schema
> migration mechanism we will need a new schema per release, which is
> something that I don't think anyone wants.
>
> Using your example, adding an optional element will cause systems that use
> an older schema to invalidate an instance that populates that element but at
> least an older system can continue to produce validate instances.  I am not
> sure how much schema validation will be used in a production system, the
> overhead to validate every instance may be to great so schema validation
> will probably be just a testing and accreditation issue.  
>
> We may need to have some parser rules a bit like HL7 V2 where you accept
> additional elements that you don't expect, within reason, so that we can
> support this forward-compatibility.  This will mean that we may not be able
> to use auto-generated XML serialisers but there are other XML APIs that can
> be used to support this kind of rules.  
>
>   
>>> Jumping ship to another style such as http://schemas.openehr.org/2009/03
>>> would also be reasonable, it would just mean we have to correlate
>>>   
> release
>   
>>> dates with release numbers.
>>>   
>> This has one advantage in that it is possible to release new major
>> versions of the spec _without_ updating the schema. So if v1.2 needs
>> no schema changes over v1.1, the 1.2 released schemas can be left as
>> http://schemas.openehr.org/2009/03 - and people won't be confused
>> thinking that their data isn't the right 'version'.
>> 
>
> [Heath Frankel] 
> So your suggesting moving to a date oriented namespace so that there is no
> tie to the release number?
>   
>>> There is an optional rm_version in the archetype_details attached to any
>>> archetyped locatable.  We currently populate this only when we specify a
>>> template_id on the composition, which is all compositions in our
>>> applications.  We could suggest that this is required for all
>>>   
> compositions
>   
>>> and make this the handle to determine what schema to use for validation.
>>>   
>> Yes, but we would also need a similar mechanims for all top-level XML
>> artifacts (archetype instances, extracts, PARTY? etc).
>> 
> [Heath Frankel] 
> All archetyped locatables can have this and I would expect all top-level
> objects to be archetyped otherwise they have no domain semantics.
>  
>   
>> The other suggestion I have seen on the interwebs is to make the
>> xsi:schemaLocation attribute compulsory in instances
>>
>> http://schemas.openehr.org/v1
>>
>> 
> http://www.openehr.org/releases/1.0.1/its/XML-schema/Composition.xsd";>
>   
>> http://schemas.openehr.org/v1.1
>>
>> 
> http://www.openehr.org/releases/1.1.3/its/XML-schema/Composition.xsd";>
>   
>> The schema checker would not actually go and 'fetch' the XSD but would
>> be looking for known U

{Disarmed} OpenEHR evaluation

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 

openehr-technical@lists.openehr.org

[Thomas Beale]

Charlie McCay wrote:
>
> All
>
> I do not recognize this description of RMIMs as modifications to the 
> HL7 RIM. RMIMs express constraints on the HL7 RIM ? the RMIM is a 
> static model that is defined as a constraint on the RIM, with all the 
> semantics defined in the RIM and associated vocabularies. There is NO 
> additional semantics introduced in the refinement process, just a 
> restriction on the set of conforming structures.
>
> It is true that the HL7 XML ITS uses the association names from the 
> RMIM for the XML element names, as a pragmatic choice to aid 
> implementation. It would be perfectly possible to write an ITS that 
> used the underlying RIM association names. This was considered and 
> felt to be less useful by those doing implementations
>
> I am yet to see an openEHR XML ITS for instance data, but am sure that 
> a similar implementation trade-off between serializing the underlying 
> reference model or serializing based in the archetype definitions 
> would be worth considering
>
*Charlie,

all the XSDs for openEHR data are here: 
http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html

see the top group. These schemas hold for all openEHR data, regardless 
of archetype, template or terminology.

There is a different kind of machine-generated schema which we call the 
Template Data Schema (TDS); any openEHR template can have this generated 
for it. This enables messages to be created specific to a template, e.g. 
a specific kind of path result. The data that conform to a TDS can be 
machine converted into standardised openEHR data for addition to an 
openEHR system. The key in all this is that TDSs are completely machine 
generated, not hand-built; the source of truth is always the archetypes 
and templates. The descriptions and diagrams on this page provide a 
high-level explanation.

- thomas beale

*

Understanding XML archetypes..

[Thomas Beale]

Oxford Partnership wrote:
> Erik
>
> Many thanks for the quick reply.
>
> I have no issues with the two level models used in OpenEHR, it makes 
> perfect sense to me to have an underlying RM for all archetypes to be 
> based on.
>
> If I am understand you correctly, then :
>
>   - No attributes within an OpenEHR class can be assumed to be 
> mandatory within the XML representations, as in all cases the RM can 
> be defaulted to.
as Erik says, if the archetype says nothing, then whatever the RM model 
(i.e. the particular classes in question) says goes.
>   - The fact that the current tools do not expose or use these 
> attributes, is a design decision made by the people writing the tools.
well, in hindsight, it was a bad idea - just that the initial builders 
knew the models very well but underestimated the importance of making 
the RM visible in these tools. Now we know better, but effort is needed 
to add this facility to the tools. There is a tool made by the group at 
Valencia Polytech in Spain that does this aspect quite well actually, 
but doesn't do many of teh editing tasks yet. So - no tool available 
today does all that is needed.

- thomas

Understanding XML archetypes..

[Thomas Beale]

Heath Frankel wrote:
> "An archetype not based on a reference model is impossible (or at least
> pointless)."
> Erik Sundvall
>
> Erik,
> I love this comment, it should be put up on the openEHR Web Site as the
> "Play of the Day".  
>
> So many times I see people trying to use Archetypes without a RM, or even
> worse using openEHR Archetypes without using the specified underlying
> openEHR RM.  Although the later is better than the former, it still causes
> major confusion and badly designed Archetypes that cannot be used for
> implementation.  
>   
or another permutation... since all archetypes are using some RM or 
other - this is mathematically unavoidable - then we should say: 
creating archetypes without knowing what reference model you are using 
is pointless.

- thomas

persistence

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

persistence

[Thomas Beale]

Bert Verhees wrote:
>
> People discuss very seriuous all kind of subjects, very deeply, that is
> OK, but why do they never discuss a solution to a Persistence-layer-API?
> (not the layer itself, only the API.)
> Another thing that is never discussed, that is the service-layer-API,
> same question, not the service-laer itself is needed to discuss, only
> the API.
>
> Why is that?
>
> I never found an answer to these questions, so I can only guess. Or
> maybe I missed them, I do not read all emails. Possible. Please tell me,
> don't stay quiet, but tell me what is happening, not only me, but I
> think many silent people would want to know.
>
> Bert
>
>
>   
the main reason is that a persistence layer API is not an essential part 
of openEHR - anyone can make up their own, and it makes no difference to 
the semantics of openEHR. It is only really useful if there is going to 
be a market in archetype-driven databases, which is not happening just 
yet

- thomas

*
*

EQL was: persistence

[Thomas Beale]

Bert Verhees wrote:
>
> But is has, in my opinion nothing to do with that. Maybe when the EQL
> definition is ready to use (I don't see much of discussion about this
> subject, but maybe the EQL discussion is a private discussion?), than
> again a way to implement it must be found,a nd maybe this changes the API.
>
> But that is a normal process in software-development, it is called
> innovation
>
>   
no, it is not a private discussion. EQL, now called AQL (archetype query 
language) will also have a draft specification soon on openEHR.org. Just 
a matter of time to put the documentation together

- thomas
*
*

EQL was: persistence

[Thomas Beale]

Bert Verhees wrote:
>
> The most important reason (amongst others) is that a defined API would
> speed up the development of more implementations, also other
> architectures could benefit from this. At this moment, there is hardly a
> market for OpenEhr, a market needs products, a market with only a few
> products does not invite people to come and look.
> An well defined API would facilitate other developers, would facilitate
> a growing market and demand for OpenEhr.
>   
Bert,
we need to be careful with what we say here - there is certainly a 
market for openEHR - it is called the EHR/EMR/GP desktop market, and it 
is worth many hundreds of ?m. But markets are for products, so we have 
to talk about 'products based on openEHR', which can be many and 
diverse. Clearly there are not that many around yet - it is the early 
part of the productisation cycle, just like with any other new technology.

In my view the APIs that are of the most use right now are the vEHR and 
the EHR service model. Ocean will publish theirs in the coming weeks, 
and others are encouraged to do the same, in order to work towards a 
standardised EHR interface for openEHR. This is of more importance than 
the current standards activities in my view, since the result will have 
running software behind it and will be known to work. It will also have 
been designed rather than put together by committee.

- thomas beale

persistence

[Thomas Beale]

Bert Verhees wrote:
>
> What I need is a strongly expressed intention to do something in a way I
> suggest.
> Serious people, not , say, pbublish your thing, and we will see. That is
> not good enough.
>
> If we have a few people which want to join, and  they seriously have
> thought about in what way to join, then we discussi further how to proceed.
>
>   
*I would think the problem here is that no-one knows at this stage what 
you are asking them to consider. Is it:
- just an idea (i.e. why don't we write a new persistence layer together)
- an implementation that you have running or partly running, but you 
need more effort on it

Probably you need to clarify the concrete basis of this discussion from 
your point of view.

- thomas
*

EQL was: persistence

[Thomas Beale]

Bert Verhees wrote:
> Thomas Beale schreef:
>   
>>
> Thanks, I am very interested.
> Will this be a part of a following version of OpenEhr?
> (this is good to know in the context of conformance)
>
>   
*yes it will - it will appear in the next minor release as a draft 
document (like the existing draft documents). It will become a non-draft 
specification in a subsequent release like 1.1, according to what makes 
sense for the community.

- thomas

*

path of ArchetypeInternalRef

[Thomas Beale]

Bert Verhees wrote:
> Sam Heard schreef:
>   
>> Heath has said it how it is:
>>
>> Archetype paths - that is the path to each node in an archetype - is
>> unique. This is what the ADL statement you have seen refers to.
>>
>> In data, in contrast, an individual archetype node which has
>> occurrences set as (1...2) in the archetype could exist twice in the
>> data. That is what occurrences of 2 means. How then to differentiate
>> between the two instances of this node. The answer is in the name of
>> that thing - which can be coded or free text. What this means is that
>> you can ask for something in the data as a specific instance (unique)
>> which may have a name in the path as well as the archetype_node_id's -
>> for example:
>>
>> /items[at0002 and name/value="xxx"]
>>
>> or as a path as in the archetype
>>
>> /items[at0002]
>>
>> which will return all instances of the node.
>>
>> Both paths transform to XPath in a very straightforward manner and
>> give the same results.
>>
>> Hope this is helpful.
>> 
> Thanks Sam, for explaining, so, if I may resume:
>
> If you have a node in your ADL
> /items[0002]
>
> and you have a node
> /items[0003]
>
> and /items[0003] contains a Internalref to items/[0002], what will be
> the ADL-path?
>   
the paths /items[at0002] and /items[at0003] always stand for themselves. 
The latter would not be able to have an internal reference to the 
former, because that would imply that the latter information structure 
could contain the former as a sub-structure. You can always work out 
what internal references are valid by imagining how the archetype would 
like by not using one, and just expanding out a copy of the part you 
want. Use the Archetype workbench to see the paths that result from 
internal references - e.g. have a look at Apgar result and BP 
measurement, to name two.

- thomas

Developing with Archetypes

[Thomas Beale]

Richard Kavanagh wrote:
> Hello everyone
>
> I am attempting to build some tools to help in the 
> development/publication of archetypes, as such I have a couple of 
> questions :
>
> - Is it possible to get an up to date copy of the schemas for 
> archetypes, I see the versions on SVN but they seem to be a little out 
> of date ( certainly the type "C_CODE_PHRASE" seems to be missing )
Hi Richard,

not sure where you are looking, but you could easily be in the wrong 
place, because I just noticed that the XML -schema page links are 
somewhat broken, due I think to more recent Apache remapping rules 
designed to give standard URLs to the XSDs, in the manner of W3C. I am 
looking into this.

In the meantime, the raw reference to the release page is: 
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/its/XML-schema/index.html

You will find 2 archetype schemas - the Archetype.xsd and the 
OpenehrProfile.xsd. The latter schema contains the special types 
C_CODE_PHRASE, C_ORDINAL and C_QUANTITY. They are defined in a separate 
package in the specifications (see links under 'Archetype Model' at 
http://www.openehr.org/releases/1.0.1/roadmap.html). Originally the 
reason for this was to ensure that the main Archetype XSD was completely 
general to all industries, by only assuming types available in UML, ISO 
11404 and similar standards. However, the added types for health are so 
useful and heavily used that I suspect in a future release we may simply 
combine the two schemas.

Ocean Informatics also has a bidirectional XML <-> ADL parser component 
which can be open sourced if the funding is available.

- thomas beale

{Disarmed} Comparison of EHR models

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 

Iconography & Screen shots.

[Thomas Beale]

Oxford Partnership wrote:
> Are there are screen shots available for the template editor available 
> from Ocean. I can see the contents of the *.oet files and can make a 
> guess at how these would be derived, but seeing something would be nice.
>
> Also, are there standard icons for use within tools used within the 
> OpenEHR world. If so where would I get hold of them.
>
> Thanks again
> Joe
*not standardised yet, but there is a rather large set in 
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/apps/adl_workbench/app/icons/

A new ADL workbench will be released soon that uses all these icons.

- thomas
*

Redux: Circular Imports

[Thomas Beale]

Tim Cook wrote:
> Hi All,
>
> This is different than the issues brought up by Rong in the Java
> implementation.
>
> I brought this up before when reading the specs. But now as my code has
> matured my fears are confirmed.  
>
> Using Python:
>
> In an interface I define attributes of a class. In addition to some
> meta-data I define the 'type' of that attribute.  
>
> Code is here; 
> http://www.openehr.org/wsvn/ref_impl_python/TRUNK/oship/src/oship/openehr/am/archetype/?rev=0&sc=0
>
> For example in IArchetype (the Archetype interface) I define ontology as
> an ArchetypeOntology type.  Now Archetype of course is supposed to
> implement IArchetype.  IArchetypeOntology defines parentArchetype as an
> Archetype type. This creates a circular dependency when the interfaces
> try to create a datatype based on a class that depends on itself.
>   

Tim,

just to be clear - I believe the problem here is that you are having 
trouble serialising to and deserialising from a database (Zope in your 
case) from in-memory objects because some objects have circular 
references? If so, we need to be clear (or at least I do;-) about a few 
things:

1. some attributes don't need to be persisted at all. generally parent 
attributes do not need to be persisted, although they can. If they are 
not, you reconstruct the parent link on deserialisation. Your 
implementation may not even need the parent link but most do.

2  the difference between circular references in the object model, and 
circular references in instances graphs. When a circular reference 
occurs in an instance graph, you have to deal with it when serialising 
to any medium - and this is done by doing a 2-phase 'mark & store' 
traversal on the in-memory objects. This enables any complexity of 
circular links in an isntance graph to be correctly stored.

3. a self-reference in the class model, such as for DV_MULTIMEDIA 
doesn't necessarily mean a circular reference in an instance graph (and 
it doesn't in this case) - it just means there are 2 or more instances 
of the same class with references between. This should cause no problems 
at all for serialise / deserialise.

The main reason for parent references by the way is for path processing 
code to traverse back up and down the object trees. In my Eiffel 
implementation of the ADL parser this is used ubiquitously. There are 
other approaches of course. Anyway, it won't hurt your openEHR data not 
to have these references!

- thomas beale

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

[Thomas Beale]

Erik Sundvall wrote:
>
> I obviously did not explain clearly what I meant by GUI-hints. What I
> was thinking of was a bit more towards the "left" side of the spectrum
> trying to capture some some of the "semantics" of the
> human-computer-interaction when entering the things described by
> templates. I was not thinking of colors, fonts, detailed component
> placement etc. Instead I'm thinking of things like:
> - Greg's suggestion that one could specify whether a text node in a
> template will likely be short (e.g. a name) or if it is more likely to
> be a paragraph that would benefit from a multiline-type of text entry
> widget.
> - In a long template that also includes a section about "tobacco use"
> you might want to specify that the detailed parts regarding amount of
> consumption don't need to be shown if the person has been documented
> with the status "Never used". (I.e. implemented using simple
> conditional statements).
> - In the a particular use case in mind you might want to assign the
> the subtree "Consumption, Amount of substance" a higher priority in
> GUIs than the "Previous attempts to quit smoking" subtree so that the
> latter gets pushed to a normally hidden collapsed/hidden subform if
> there is a lack of space. (I.e. using a detail level mechanism)
> - Mechanisms like "hide_in_ui" to skip intermediate things that are
> meaningful in information modelling but are distracting or unnecessary
> in a GUI.
>   

most of the above are part of the CUI design ideas in the NHS, and I 
agree, are more 'semantic'. I think of them as 'workflow' semantics, 
rather than data semantics. They are a logical concept that could be 
implemented in presentation in more than one way. The conditionality 
idea (Erik's 2nd point above) is included in the new template / 
specialised archetype specification. Some things like the priority have 
not yet been considered (even by the CUI group) but probably need to be.
> As you can see these things have a bit of a semantic touch also, but
> maybe a different kind of semantics than we usually refer to as
> semantics in this community.
>
> When it comes to template design it would be interesting to know if
> the clinicians always are comfortable only having the on/off (set zero
> occurrence) of templates (or are there more restrictions available)?
> Don't you get a lot of "it depends"-answers whether to include
> something in a template or not? Do you believe that answers what to
> "kill" from (for the use case) overly detailed archetypes templates
> would be different if the clinicians are aware of the possibilities to
> change priorities, set conditional statements etc?
>   

hence the need to add conditionality to the template spec;-)

> I don't suggest that these hints necessarily should be created
> simultaneously with the template editing, but I guess that the very
> same clinical experts that design the template would be also good
> candidates to give some GUI-hints after the template creation.
> Thoughts?
>
> When it comes to what I call GUI-hints above I believe it would be
> useful to specify a model (like the with the AM) and one or many
> serialization formats of it rather than going straight for a markup
> language. 

some of these hints will be covered by the new specialised archetype / 
template model. but some are not yet. I wonder if we can construct a 
definitive list?


> Artifacts built using that model could then be used for auto
> generation of GUIs (whenever that is necessary) and as input to other
> steps specifying things more to the "right" in the spectrum like
> dealing with specific widgets, component positioning etc. for example
>   
I think this is true as well...

>
> One last thing...
>
> On Sat, Jun 28, 2008 at 00:18, Thomas Beale
>  wrote:
>   
>> ... there are more semantic indicators being built
>> into the template designer, some based on the NHS CUI project, that will
>> provide good hints on GUI generation, including some temporal workflow
>> aspects.
>> 
>
> Are these things or the principles behind them something you can and
> would like to like detail a bit more or share with the community when
> time permits?
>   

as far as I know the CUI group's work is not secret; we have been given 
a list of about 10 things they want to see in a GUI, but I have to admit 
I have not even checked to see if this is on the relevant website. We 
need to find that out and make it public if it is not.

- thomas beale

Reusable Archetypes

[Thomas Beale]

Tim Cook wrote:
> Hi P?ria,
>
> On Fri, 2008-07-04 at 14:18 +0200, P?ria Kashfi wrote:
>   
>> Hi there, 
>> I feel the most important thing in developing suitable templates is to
>> understand the openEHR reference model and its basic concepts very
>> well and to be able to analyze the case and extract required
>> information that may help finding proper archetype clues while
>> designing. It may sounds simple at first glance but is a tedious
>> task. 
>> 
>
> I do not think that it is a requirement for knowledge workers to have a
> deep understanding of the reference model.  
>
> I believe (I hope) that one of the tenets of openEHR is to separate the
> clinical element design (knowledge work) from the implementations
> (software).  
>
>   
*
It is, but we need to be careful of what we mean by saying clinical 
people don't need to know the reference model. It is true that clinical 
people should not need to know the reference model in its role as 
software, i.e. all the functionality built into an implementation and so 
on. And there are large parts of the reference model that are of no 
interest to clinical people, e.g. most of the Support and Common models. 
However, the reference model also stands for something else - it 
functions as the base ontology of openEHR - and makes semantic 
commitments to certain kinds of Entries, data types, data structures and 
so on. This aspect of the reference model needs to be understood by 
everyone involved in openEHR. To take a concrete example: a clinician 
building an archetype who doesn't know that Observation takes care of 
representing a Historical time-series of samples won't know how to build 
an archetype for Apgar or rolling BP. Similarly, someone who does not 
realise that an Instruction is different from an Action won't understand 
how to build archetypes for orders and results. Someone who doesn't 
understand that there are 5 or so quantity data types might make the 
mistake of using the Quantity one for everything.

The semantics of the RM that need to be understood in this way probably 
constitute somewhat over 50% of the total classes and attributes. 
Probably we need this cut down version to be visible in some way, e.g. 
as an exported view from a UML tool.

- thomas beale

*

Computation of time data in openEHR ...

[Thomas Beale]

Bruno Cadonna wrote:
> Hi all,
>
> After a thread on the openehr-clinical list about associated symptoms 
> (cf. subject "Associated symptoms" on openehr-clinical) some technical 
> questions about computation of time came to my mind.
>
> In openEHR the time data can be found in different places in different 
> ENTRY types.
>
> OBSERVATIONs have HISTORYs for attributes "data" and "state". Time 
> data in HISTORY represent the timing of observations, they may be used 
> for computations. Time data in the ITEM_STRUCTURE of the attribute 
> "data" of an EVENT in a HISTORY should not be used for computation.
> An example for the latter is archetype 
> openEHR-EHR-OBSERVATION.symptom_check.v1 which includes CLUSTER 
> archetype openEHR-EHR-CLUSTER.symptom.v3.adl. 
> openEHR-EHR-CLUSTER.symptom.v3.adl defines time data at archetype node 
> at0063 "Date / time of onset". This time data should not be used for 
> computation to avoid contradiction with time data recorded in the 
> HISTORY of the OBSERVATION.
>
> Is this right?
Any timing information that is correct in the EHR should be usable for 
computation - there is no reason not to. BTW times like 'date/time of 
onset' will usually occur in Evaluation archetypes, not Observation 
archetypes.
>
>
> EVALUATIONs have time data somewhere in the ITEM_STRUCTURE of their 
> attribute "data". This time data may be used for computation.
> For example archetype openEHR-EHR-EVALUATION.problem-diagnosis.v1 
> defines time data at archetype node at0003 "Date of initial onset" 
> which may be used for computation.
>
> Is this right?

same meaning as above.

>
>
> ACTIONs have time data in attribute "time" which states when the 
> action completed and in the ITEM_STRUCTURE of the attribute 
> "description". Both time data may be used for computation.
> An example for the latter is archetype 
> openEHR-EHR-ACTION.medication.v1 which includes archetype 
> openEHR-EHR-ITEM_TREE.medication.v1. 
> openEHR-EHR-ITEM_TREE.medication.v1 defines time data at archetype 
> node at0019 "Date (time) of first administration". This time data may 
> be used for computation.
>
> Is this right?
> What about archetype node at0032 "Date (time) of last administration" 
> of openEHR-EHR-ITEM_TREE.medication.v1? Does it contradict time data 
> in attribute "time" in ACTIONs?

I assume that this wouldbe more properly named 'date/time of previous 
administation' - I assume it is there to provide an idea of the period 
between administrations - useful e.g. in the case of painkiller medication.
>
>
> INSTRUCTIONs have time data in "expiry_time" and in the ITEM_STRUCTURE 
> of the attribute "description". Both time data may be used for 
> computation.
> An example for the latter is archetype 
> openEHR-EHR-INSTRUCTION.medication.v1 which includes archetype 
> openEHR-EHR-ITEM_TREE.medication.v1. 
> openEHR-EHR-ITEM_TREE.medication.v1 defines time data at archetype 
> node at0019 "Date (time) of first administration". This time data may 
> be used for computation.
>
> Is this right?
> Here archetype node at0032 "Date (time) of last administration" of 
> openEHR-EHR-ITEM_TREE.medication.v1 could also contradict the 
> attribute "expiry_time" of INSTRUCTIONs, but the semantics of these 
> time data is quite different, thus this should not be a problem, right?
*
all of the times you have mentioned occur somewhere on a notional real 
world timeline concerning the individual patient. Some are built-in to 
the openEHR reference model because they are universal, e.g. the times 
in History and Action (it dosn't matter what the data being collected 
are, these times always make sense). Others are completely dependent on 
the data being collected and are defined in archetypes. The latter are 
no less meaningful on the patient timeline however.
*

- thomas beale

proposal for managing migration to .adls (source form) archetypes

[Thomas Beale]

Dear all,

as some at least have noticed from previous posts, there is the 
intention to move toward what we call 'source form' or 'differential' 
archetypes, whereby archetypes contain only changes with respect to a 
specialisation parent archetype. This move has no effect on the majority 
of archetypes (since they are top-level archetypes) but specialised 
archetypes are changed from being 'flat-form' archetypes (where 
inherited, unchanged elements are repeated in the descendant) to 
differential form, where they contain only new or redefined elements 
with respect to the parent archetype. Doing this makes specialised 
archetypes sustainable to maintain.

So far in the reference parser, we have implemented a fair bit of the 
specialisatoin semantics, and are generating .adls (source form) files 
from the existing .adl files. However, clearly in the future the aim is 
to be authoring from the outset in .adls form. The Archetype Editor has 
not had this capability added, but there are places where we want to do 
this anyway.

As a result, we have the situation where for some time both .adl and 
.adls files will be the authored form of an archetype, and therefore, 
both .adls and .ald files may be generated - the former from current 
.adl files, and the latter from de novo authoring in .adls (or an XML 
equivalent).

My proposal is to add a single flag to the .adl grammar that indicates 
whether an archetype, in either format, is 'generated', meaning was it 
machine generated from the other form. If this flag is  not set, it 
means that the file is the original authored form of an archetype. The 
actual form of the flag would be in the first line, in the bracketed 
part after the 'archetype' keyword. For example, in the archetype at 
http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.ecg.v1draft.html
 
the first line is:

archetype (adl_version=1.4)

my proposal would be that if it were generated, it would be as follows:

archetype (adl_version=1.4; generated)

in a similar manner to the 'controlled' indicator defined in section 
8.3.2 of the ADL 1.4 specification 
(http://www.openehr.org/releases/1.0.1/architecture/am/adl.pdf). The 
equivalent change would be made in the openEHR archetype XSD to allow 
XML archetypes to include this flag.

This allows tools to know which form can safely be discarded, allowing 
bugs and development to continue on the tools themselves. To move 
forward on this, we would need the agreement of all archetype toolbuilders.

all feedback welcome.

archetypes - distniguishing multiple alternative constraints of a single-valued attribute

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

archetypes - distniguishing multiple alternative constraints of a single-valued attribute

[Thomas Beale]

Ian McNicoll wrote:
> Hi Thomas,
>
> Other than the requirement for specialisation, am I correct in 
> thinking that this would give us 'named choices' which I have 
> suggested in the past (along with named slots)? This would be very 
> helpful in understanding the thinking behind the choice construction 
> which is not always evident, particularly when selecting appropriate 
> an appropriate choice at template time.

yes - you could think of it like that.

>
> Does a similar issue apply to archetype slots? A common construct is 
> to place archetype slots within a cluster so that they can be 'named'. 
> This seems to me to unnecessarily overcomplicate the archetype.
>
this is certainly the wrong thing to do, and the specification already 
supports at-codes on slots, just that the current tools don't, or there 
is mixed support at best (hence this workaround). This needs to be fixed.

- thomas

archetypes - distniguishing multiple alternative constraints of a single-valued attribute

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Archetypes including inherited content

[Thomas Beale]

Hi Adam,

Adam Flinton wrote:
> Dear All,
>
> Given we have a lot of archetypes which are then further versioned etc 
> moving archetypes from one version to another can become a real pain 
> based on their inherited content.
>
> i.e. if B.v1 specializes A.v1 then it includes the content of A.v1
>
>
> If we then create an A.v2 & wish to create a B.v2 which specialises A.v2 
> (or even we have a b.v1draft which we we to change to 
> specializing/extending A.v2) a manual process must ensue so that the 
> content brought in from A.v2 replaces the content brought n from A.v1.
>
> I have heard comment that this is changing so that Archetypes become 
> like normal classes i.e. the superclass content does not appear in the 
> subclass & if a given method does appear in the subclass then it 
> overrides that in the superclass.
>
> A) Is this so? If not it should be
>   

it is certainly the case. See the latest Archetype Workbench for details 
- 
http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/doc/adl_workbench_help.htm

Start the AWB, set its repository to where your archetypes are, then hit 
F7. You will see all archetypes being compiled, and .adls files being 
created by differencing the existing .adl files. Have a look at the 
.adls files of some specialised archetypes in a text editor. Also, you 
can use the 'flat' and 'differential' views in the workbench to show the 
effects of he new representation.

> B) If this is so, any ideas wrt dates & tooling etc to support this (inc 
> wrt the java tooling)?
>   

I can't speak for the Java tooling, but the new version of the reference 
ADL parser (which is in the workbench) will go into the Archetype Editor 
during the next few months. Other changes that will be included are 
described in the new specialisation semantics in the ADL specification. 
See 
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes
 
for details.

As ever the speed of this work is dependent on funding.

- thomas beale

Is there an OpenEHR technical commitee?

[Thomas Beale]

Just to add to Tim's reply, there is a workplan here: 
http://www.openehr.org/specifications/spec_roadmap_2008.html . Each row 
in the table is a major work item and has or will have its own wiki 
page, found under this page: 
http://www.openehr.org/wiki/display/spec/Specifications+Home

Currently the groups who work on the specifications are formed by those 
who are interested registering on the wiki page / or with the team lead.

All changes large or small are documented by CRs, and all CRs are 
publicly online at the Jira server - http://www.openehr.org/issues . You 
can look here at any time and see the current status of CRs in the next 
release (the next release right now is 1.0.2).

openEHR doesn't use a committee structure like the standards bodies 
because we have not found it useful for developing good quality 
engineering specifications or implementations. (It is also very 
expensive in time, money and costly for the environment). Committees 
might one day be created for review purposes, but the implementation 
community already performs the main role here. (Personally I think 
official standards organisations would be far more useful by providing a 
review function on IP developed elsewhere by proper 
analysis/design/build processes than trying to create their own IP, 
which is generally not very good. This is how ISO, IEC, CCITT and many 
other SDOs worked in the past. Somehow some of them have become confused 
about their role and competence in the e-health space.)

With respect to what standard a given piece of software adheres to, it 
will always be one of the official releases of the openEHR 
specifications. You can always see a detailed view of each release here: 
http://www.openehr.org/issues/browse/SPEC?report=com.atlassian.jira.plugin.system.project:changelog-panel
 
(this link is Home page > Specifications > Change History). It is up to 
the project team releasing the software to indicate which release the 
software conforms to. So for example, if two different archetype editors 
both implement Release 1.0.1 ADL specification (ADL 1.4) then they 
should be able to communicate .adl and .xml archetypes. This is indeed 
currently the case.

hope this helps

- thomas beale


Tim Cook wrote:
> Hi Adam,
>
> On Wed, 2008-07-16 at 13:31 +0100, Adam Flinton wrote:
>   
>> Dear All,
>>
>> I have raised 2 changes wrt archetypes (wrt regex'es and superclass 
>> content in subclasses) & a thought occurred which had been troubling me 
>> for a while which is:
>>
>> Where exactly are these changes made/agreed to etc?
>> 
>
>   
>> i.e. wrt say HL7 (or other std orgs I have been involved with (e.g. the 
>> W3C) there are technical committees where I would put these changes, 
>> possibly there would be a trac/bugzilla so that things don't "slip off 
>> the radar", votes would be taken & recorded etc.
>>
>> 
>
> The changes to the RM,AM, etc are handled by the Architecture Review
> Board (ARB).  
>
> There is a formal change process documented here:
> http://www.openehr.org/specifications/specs_governance.html 
>
> and here:
>
> http://www.openehr.org/svn/specification/TRUNK/publishing/CM/CM_plan.pdf
>
> and you can enter your problem Report/Change Request here: 
> http://www.openehr.org/issues/browse/SPEC?report=com.atlassian.jira.plugin.system.project:changelog-panel
>
>
>   
>> I have been looking at the java archetype code & have been considering 
>> putting some time in there but.how would I know that the code is up 
>> to a given standard (e.g. say if the regex requirement was changed or 
>> the super/subclass thing was resolved) given I can find no such committee?
>>
>> 
>
> You should ask this question on the Java project mailing list:
> http://www.openehr.org/projects/java.html I'm not sure what their bug
> management process is but the Python project uses Launchpad:
> https://launchpad.net/oship/ 
>
>   
>> This can only be the case if the changes/standards etc are out in the 
>> open such that coders can have sufficient pre-warning of impending 
>> changes (or indeed possibly wholly new structures) in advance so that 
>> different tooling in different languages by different groups be the 
>> coordinated.
>> 
>
> This is certainly the case as you'll see from the above links.
>
>   
>> i.e. if I were to generate XML from ADL using the ocean tools will I get 
>> the same result as if I were to wrap the java tools as ant tasks & use 
>> them for the same purpose? How would I know?
>> 
>
> A question that others can answer as well. ;-)
>
> HTH,
> Tim
>
>
>   
> -

archetypes - distniguishing multiple alternative constraints of a single-valued attribute

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Where is the Archetype spec?

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Where is the Archetype spec?

[Thomas Beale]

Adam,

see 
http://www.openehr.org/releases/1.0.1/architecture/computable/UML/uml.html

This model is in XMI 1.1 and was done in MagicDraw 9.5. This computable 
format is not that up to date, i.e. it is not XMI 2.0. Erik Sundvall at 
Linkoping is looking into replacing this with a new expression done 
under another tool. See 
http://www.openehr.org/mailarchives/openehr-technical/msg03577.html

- thomas

Adam Flinton wrote:
> Thomas Beale wrote:
>   
>> Adam Flinton wrote:
>> 
>>> Dear All,
>>>
>>> I have been poking about the openEhr site looking for something which 
>>> definitively says what an archetype is, preferably in a computable form.
>>>
>>>
>>> is there a UML model/adl/XML schema which is downloaded & which is the 
>>> definative/normative definition.
>>>
>>>   
>>>   
>> Adam,
>>
>> 
> Cheers.
>
> One more quick question.
>
> It states in the aom.pdf
>
> "The AOM defines the object model equivalent, in terms of a UML model."
>
> Can I get a useful copy of that model? E.g. in XMI?
>
> If so what version of XMI/What UML tool is required?
>
> Adam
>
>   
>> the resources you seek are as follows (all available from the 
>> specifications page, which is here: 
>> http://www.openehr.org/releases/1.0.1/roadmap.html and always 
>> reachable by the 'specifications' hotlink on the home page)
>>
>> * archetype definition language (ADL 1.4) -
>>   http://www.openehr.org/releases/1.0.1/architecture/am/adl.pdf
>> * archetype object model (AOM) -
>>   http://www.openehr.org/releases/1.0.1/architecture/am/aom.pdf
>> * openEHR extra archetype semantics -
>>   
>> http://www.openehr.org/releases/1.0.1/architecture/am/openehr_archetype_profile.pdf
>> * XSD - available from
>>   http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html
>>
>> The AOM is the normative computable specification for archetypes. The 
>> ADL specification currently contains more explanation of the 
>> semantics, and is a direct syntactic equivalent to the AOM.
>>
>> New work being done for specialisation and templating, including the 
>> ADL 1.5 draft,  is found here:
>>
>> * 
>> http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes
>>
>> *
>> - thomas beale
>>
>> *
>> 
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>   
>> 
>
>
> ***
> This  message  may  contain  confidential and  privileged  information.
> If you  are not the  intended recipient  you should not  disclose, copy
> or distribute information in this e-mail or take any action in reliance
> on its contents.  To do so is strictly  prohibited and may be unlawful.
> Please  inform  the  sender that  this  message has  gone astray before
> deleting it.  Thank you.
>
> 2008 marks the 60th anniversary of the NHS.  It's an opportunity to pay
> tribute to the NHS staff and volunteers who help shape the service, and
> celebrate their achievements.
>
> If you work for the NHS  and  would like  an NHSmail  email account, go
> to: www.connectingforhealth.nhs.uk/nhsmail
> ***
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

proposal for managing migration to .adls (source form) archetypes

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Regex in Archetypes must include TYPE

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 

Release 1.0.2 change - SPEC-260 - Correct the regex published for the ARCHETYPE_ID type (due date 304/Aug/08)

[Thomas Beale]

Dear all,

The CR SPEC-260 (http://www.openehr.org/issues/browse/SPEC-260) being 
processed for Release-1.0.2 proposes an updated regular expression and 
syntax to match Archetype identifiers. The changes are visible in 
section 4.3.10 of the Support IM document at 
http://www.openehr.org/svn/specification/BRANCHES/Release-1.0.2-candidate/publishing/architecture/rm/support_im.pdf

Any feedback on the proposed regular expression would be appreciated.

- thomas beale

Regex in Archetypes must include TYPE

[Thomas Beale]

Sam Heard wrote:
> Hi Thomas
>
> I had a look at the AOM and did not see anything, just include and 
> exclude statements - didn't read the ADL spec. The point here is that 
> we could have a slot that allowed different classes which would 
> simplify things for the archetype authors.

in the AOM all C_OBJECTs have the rm_type_name attribute.

>
> Could we have a slot that allows two different classes?

We already have that you can put more than one object constraint in a 
slot, either as alternatives for a single-valued attribute or as 
multiple co-existing items under a multiply-valued attribute.

- thomas

*
*

new draft of ADL 1.5 available

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

Release 1.0.2 change - SPEC-260 - Correct the regex published forthe ARCHETYPE_ID type (due date 304/Aug/08)

[Thomas Beale]

I knew someone would leap in and help ;-)

Peter Gummer wrote:
>
> The first surprise is that single-character specialisation concepts are now 
> rejected. They used to be accepted. (An example would be "blood_type-o".) 
> It's now consistent with the pattern for the concept name. Was this change 
> intentional?
>   

It was - whether or not it is correct or required is another matter - 
the archetype community needs to decide that. I would suggest that 
"blood_type-o" could not be a sensible archetype name from a clinical 
point of view, because 'o' is not a specialisation of the blood type 
reporting concept, it is a blood type in reality. I.e. in Snomed would 
would find

blood type
^
|
blood type O

but it doesn't make sense in archetypes that I can see.

I think we would need at least one realistic example of where a name 
needs to be only one character long before we allowed it.

>
> The version_id part of the regex -- v[1-9]\d*(\.\d)* -- has bigger problems. 
> In section 4.3.10, the regex matches these version_ids:
>
>   v1   -- good
>   v10 -- good
>   v1.0-- is this intentional to allow a zero in a minor version 
> part?
>   

yes

>   v1.1-- good
>   v1.1.1  -- is this intentional to allow three parts?
>   

yes

>   v1.1.1.1   -- or even more than three parts?
>   

yes you are right - we probably should limit it to 3, which will require 
a change

> The version_id regex rejects these:
>
>   v0   -- good, this was Eric Browne's point that version_id 
> shouldn't be zero
>   v1.10   -- surely this should be allowed!
>   

yes - that's an error. I think this part of the regex should be:

.v[1-9]\d*(\.[0-9]+){0,2}

> I believe the version_id regex should be one of the following:
>
>  [R1]v[1-9]\d*(\.\d+)*   -- allows v1.10
>  [R2]v[1-9]\d*(\.[1-9]\d*)*-- allows v1.10 and disallows v1.0
>  [R3]v[1-9]\d*(\.\d+)?   -- allows v1.10 and disallows v1.1.1
>  [R3]v[1-9]\d*(\.[1-9]\d*)?-- allows v1.10 and disallows v1.1.1 and 
> v1.0
>
>
> Another error is that the production rules in section 4.3.10 are 
> inconsistent with the version_id regex:
>
> version_id: 'v' V_NATURAL_DIGIT { '.' V_NUMBER }*
> V_NUMBER: [0-9]*
> V_NATURAL_DIGIT: [1-9]
> V_NAME: [a-zA-Z][a-zA-Z0-9_]+
>
> The corresponding regex would be v[1-9](\.\d*)* , which differs from section 
> 4.3.10's regex in three respects:
>
>  * It allows "v1.10", which surely is good; but
>  * It allows "v1.", and
>  * It disallows "v10"!
>
> So, once the regex is right, the production rules have to be fixed too.
>   

yep...!

- thomas beale

Release 1.0.2 change - SPEC-260 - Correct the regex publishedforthe ARCHETYPE_ID type (due date 304/Aug/08)

[Thomas Beale]

I now have the grammar and PERL regex as below. This is slightly 
improved (I believe) from Peter's last version.



archetype_id: qualified_rm_entity ?.? domain_concept ?.? version_id

qualified_rm_entity: rm_originator ?-? rm_name ?-? rm_entity
rm_originator: V_NAME
rm_name: V_NAME
rm_entity: V_NAME

domain_concept: concept_name { ?-? specialisation }
concept_name: V_NAME
specialisation: V_NAME

version_id: ?v? V_NONZERO_DIGIT [ V_NUMBER ] [ ?.? V_NUMBER [ ?.? 
V_NUMBER ] ]

V_NONZERO_DIGIT: [1-9]
V_DIGIT: [0-9]
V_NUMBER: [0-9]*
V_NAME: [a-zA-Z][a-zA-Z0-9_]+


The PERL regular expression equivalent of the above is as follows:
[a-zA-Z]\w+(-[a-zA-Z]\w+){2}\.[a-zA-Z]\w+(-[a-zA-Z]\w+)*\.v[1-9]\d*(\.\d+){0,2}

Peter Gummer wrote:
> Thomas Beale wrote:
>   
>>>   v1.1.1.1   -- or even more than three parts?
>>>   
>> yes you are right - we probably should limit it to 3, which will
>> require a change
>>
>> 
>>> The version_id regex rejects these: ...
>>>   v1.10   -- surely this should be allowed!
>>>   
>> yes - that's an error. I think this part of the regex should be:
>>
>> .v[1-9]\d*(\.[0-9]+){0,2}
>> 
>
> Ok, so in Perlesque it would be:
>
> v[1-9]\d*(\.\d+){0,2}
>
> And the "classic regular expression equivalent" would be:
>
> v[1-9][0-9]*(\.[0-9]+){0,2}
>
> Therefore, the production rule would be:
>
>  version_id: 'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } ] 
> [ '.' V_DIGIT { V_DIGIT } ]
>  V_DIGIT: [0-9]
>  V_NONZERO_DIGIT: [1-9]
>
> - Peter 
>
>
> _______
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Release 1.0.2 change - SPEC-260 - Correct theregex publishedforthe ARCHETYPE_ID type (due date 304/Aug/08)

[Thomas Beale]

Peter Gummer wrote:
> Thomas Beale wrote:
>
>   
>> archetype_id: qualified_rm_entity ?.? domain_concept ?.? version_id
>>
>> qualified_rm_entity: rm_originator ?-? rm_name ?-? rm_entity
>> rm_originator: V_NAME
>> rm_name: V_NAME
>> rm_entity: V_NAME
>>
>> domain_concept: concept_name { ?-? specialisation }
>> concept_name: V_NAME
>> specialisation: V_NAME
>>
>> version_id: ?v? V_NONZERO_DIGIT [ V_NUMBER ] [ ?.? V_NUMBER [ ?.?
>> V_NUMBER ] ]
>>
>> V_NONZERO_DIGIT: [1-9]
>> V_DIGIT: [0-9]
>> V_NUMBER: [0-9]*
>> V_NAME: [a-zA-Z][a-zA-Z0-9_]+
>>
>>
>> The PERL regular expression equivalent of the above is as follows:
>> [a-zA-Z]\w+(-[a-zA-Z]\w+){2}\.[a-zA-Z]\w+(-[a-zA-Z]\w+)*\.v[1-9]\d*(\.\d+){0,2}
>> 
>
>
> This all looks correct to me now, Thomas, except for the version_id 
> production rule:
>
> ?v? V_NONZERO_DIGIT [ V_NUMBER ] [ ?.? V_NUMBER [ ?.? V_NUMBER ] ]
>
> I considered but rejected this idea, because it permits amputated version 
> numbers such as these:
>
> v1.
> v1..
> v1..1
> v1.1.
>
> I abandoned the "V_NUMBER" idea because it allows the two optional suffixes 
> to have no digits! You could of course fix that by redefining V_NUMBER like 
> so:
>
> V_NUMBER: [0-9]+
>
> But then it would force you to start with a two-digit version number. v1, v2 
> through to v9 would all be illegal versions. Not good!
>
>   
*The following permits v1, etc, since in **V_NONZERO_DIGIT [ V_NUMBER ] 
the latter part is optional.*
*
version_id: ?v? V_NONZERO_DIGIT [ V_NUMBER ] [ ?.? V_NUMBER [ ?.? 
V_NUMBER ] ]

V_NONZERO_DIGIT: [1-9]
V_NUMBER: [0-9]+


* - thomas

DADL optional rm-type

[Thomas Beale]

Bert Verhees wrote:
> Hi,
>
> I wrote another message before, earlier this week, but that was addresses to 
> the Java-list, but I now think it is a problem of specification.
> --
> I want to know, is it in all cases possible to guess the rm-type in a dadl-
> construct? I ask this, because the specification says:
>
> ---
> http://www.openehr.org/releases/1.0.1/architecture/am/adl.pdf (page 23)
> The basic design principle of dADL is to be able to represent data in a way 
> that is both machineprocessible and human readable, while making the fewest 
> assumptions possible about the information model to which the data conforms. 
> To this end, type names are optional; often, only attribute names
> and values are explicitly shown.
> ---
>
> This spec worries me, because in my opinion, the "guessing" routine for an rm-
> type is hard to write efficient (it contains loops, and will use many CPU 
> when 
> processing large amounts of data).
> What is more, is it safe? 
> I say this because, some attributes are optional, maybe there can be more rm-
> types which can be found with a certain attribute.
>
> Example:
> I am thinking about DV_TEXT, it only has one required attribute, called 
> "value".
> This is also the case for most ID-classes, like HierObjectID. How can a DADL-
> rprocessing routine know what kind of rm-type must be stored?
>
>   

Bert,

in these cases the type name is needed. It can be left out if your 
software knows a priori what kind of object a given dADL text is, e.g. 
an archetype parser knows that the dADL at the top of an archetype is an 
instance of RESOURCE_DESCRIPTION, so it can proceed on this basis, even 
though we don't include any typename in the archetype.

- thomas

DADL optional rm-type

[Thomas Beale]

Bert Verhees wrote:
> On Thursday 24 July 2008 17:29:41 Thomas Beale wrote:
>   
>>
>
> Thanks, Thomas, for your reply.
> What I am afraid of, is that, when allowing to NOT specify the rm-type name, 
> error-prone dadl-files can occur. Possibly an application receives erroneous 
> dadl's as a form of communication.
> Also, when there is no doubt possible, when looking into the broader context, 
>  
> a routine, it has to analyze this broader context, can be difficult to write, 
> as I already said before, but the longer I think about it, the more difficult 
> it seems.
>
> Anyway, in my case, I will not allow not typed dadl's in the first, maybe 
> later.
>
> Thanks for thinking with me.
> Bert
>
>
>   
*Bert,

the dADL text is just one element of the system - the syntax is designed 
to be flexible. But there is nothing stopping you requirinng more than 
the syntax demands.

- thomas

*

Release 1.0.2 change - SPEC-260 - Correct the regex publishedforthe ARCHETYPE_ID type (due date 304/Aug/08)

[Thomas Beale]

We just need to decide how many parts the version number could possibly 
have in the future - if it is 2, then fine by me - we can easily adjust 
the regex.

- thomas

Sam Heard wrote:
> Hi Tom
>
> I just want to make it known that I am concerned about archetype Ids 
> with two decimal points in the version. I am not sure that we will 
> know what this means. To me there are only two possibilities:
>
>1. a new archetype revision means that all data out there is still
>   compatible
>2. a new archetype version that means that some data out there is
>   incompatible
>
> A revised archetype means that queries against the old archetype will 
> still work in the new archetype and visa versa. It is for this reason 
> that I have been relucent to have revisions labelled in the ID. It 
> makes sense at one level, but it greatly adds to the complexity of 
> running queries, managing templates etc. I know it makes the 
> technicians faint to think that a revised and fully backwardly 
> compatible archetype might be released with the same ID, but with the 
> generally extensible nature of the approach this has a lot of benefits 
> (see below). Clearly, this can only be done from a central source - 
> local changes (ie not done at the openEHR level) will need to be 
> specialised to ensure that there is clear governance and control.
>
> I think we need to stay out on this one until we are clearer on 
> whether Templates having to be manually updated each time an archetype 
> is updated, or allowing features of the new archetype to appear in 
> templates as the default (given that peer nodes in the archetype do 
> appear in the template).
>
> Whatever the way we go with this, I do not think we want 1.1.1 unless 
> people can come up with a sensible reason to have three levels. I 
> can't think of any benefit.
>
> Cheers, Sam
>
> Thomas Beale wrote:
>> I now have the grammar and PERL regex as below. This is slightly 
>> improved (I believe) from Peter's last version.
>>
>>
>>
>> archetype_id: qualified_rm_entity ?.? domain_concept ?.? version_id
>>
>> qualified_rm_entity: rm_originator ?-? rm_name ?-? rm_entity
>> rm_originator: V_NAME
>> rm_name: V_NAME
>> rm_entity: V_NAME
>>
>> domain_concept: concept_name { ?-? specialisation }
>> concept_name: V_NAME
>> specialisation: V_NAME
>>
>> version_id: ?v? V_NONZERO_DIGIT [ V_NUMBER ] [ ?.? V_NUMBER [ ?.? 
>> V_NUMBER ] ]
>>
>> V_NONZERO_DIGIT: [1-9]
>> V_DIGIT: [0-9]
>> V_NUMBER: [0-9]*
>> V_NAME: [a-zA-Z][a-zA-Z0-9_]+
>>
>>
>> The PERL regular expression equivalent of the above is as follows:
>> [a-zA-Z]\w+(-[a-zA-Z]\w+){2}\.[a-zA-Z]\w+(-[a-zA-Z]\w+)*\.v[1-9]\d*(\.\d+){0,2}
>>
>> Peter Gummer wrote:
>>   
>>> Thomas Beale wrote:
>>>   
>>> 
>>>>>   v1.1.1.1   -- or even more than three parts?
>>>>>   
>>>>> 
>>>> yes you are right - we probably should limit it to 3, which will
>>>> require a change
>>>>
>>>> 
>>>>   
>>>>> The version_id regex rejects these: ...
>>>>>   v1.10   -- surely this should be allowed!
>>>>>   
>>>>> 
>>>> yes - that's an error. I think this part of the regex should be:
>>>>
>>>> .v[1-9]\d*(\.[0-9]+){0,2}
>>>> 
>>>>   
>>> Ok, so in Perlesque it would be:
>>>
>>> v[1-9]\d*(\.\d+){0,2}
>>>
>>> And the "classic regular expression equivalent" would be:
>>>
>>> v[1-9][0-9]*(\.[0-9]+){0,2}
>>>
>>> Therefore, the production rule would be:
>>>
>>>  version_id: 'v' V_NONZERO_DIGIT { V_DIGIT } [ '.' V_DIGIT { V_DIGIT } 
>>> ] 
>>> [ '.' V_DIGIT { V_DIGIT } ]
>>>  V_DIGIT: [0-9]
>>>  V_NONZERO_DIGIT: [1-9]
>>>
>>> - Peter 
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>
>>>
>>>   
>>> 
>>
>>
>>   
>
> -- 
>
>   Dr Sam Heard
> Chief Executive Officer
> Director, openEHR Foundation
> Senior Visiting Research Fellow, University College London
> 214 Victoria Avenue
> Chatswood, NSW, 2067
> Phone: +61 2 9415 4994
> Mobile: +61 4 1783 8808   21 Chester Cres
> London E8 2PH
> Phone: +44 20 7249 7085
> Mobile: +44 77 9871 0980
>
>
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Updating government, commercial and academic use of openEHR

[Thomas Beale]

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

[Thomas Beale]

As part of the ongoing specification work this year, we have started to 
build some resource pages for the various specifications. One of them 
concerns a querying solution for openEHR - see the wiki page at: 
http://www.openehr.org/wiki/display/spec/openEHR+Query+Specifications

I have uploaded the Ocean Informatics developed 'Archetype Query 
Language' (AQL) as a candidate solution for querying archetype-based 
data. As explained in the query specification home page, AQL can be 
treated as a starting point for defining a normative openEHR querying 
language, or it may be considered to be one candidate amongst several, 
if there are others available. Ocean Informatics undertakes to continue 
the development of this language in the openEHR space, so that if the 
openEHR community wishes to use AQL, the most recent modifications will 
be available.

The timetable we have initially suggested for openEHR is to have a solid 
development draft ready in Q3 2008, i.e. before end September. See the 
roadmap for the current delivery plan - 
http://www.openehr.org/specifications/spec_roadmap_2008.html . A stable 
release should probably be available by mid 2009.

The current material is therefore intended as a resource for discussion 
and definition of a query language for openEHR. A team can be defined 
after sufficient time for the community to react to this material and 
determine if it makes sense to use AQL as the basis or to seek other 
solutions or candidates.

- thomas beale

openEHR Querying specifications

[Thomas Beale]

Stef Verlinden wrote:
> I'm not a technical person but to me it seems very cumbersome if such 
> 'differences' could exist between 2 versions of the same archetypes. 
> This would mean that for every query one has to go into detail of 
> every version of that AT which could mean al lot of work.
>
> To my understanding versions of AT's should be 'backward compatible'. 
> One can only add (and maybe remove) items, but never rename an 
> existing item. Only then a lot of unnecessary work for 'query-makers' 
> can be avoided.
>
> Is this assumption indeed correct?
>
all,
we need to be very clear about archetype 'versions'. There are two 
dimensions to the problem of 'archetype change' that need to be 
remembered. Firstly, archetype development lifecycle. Before an 
archetype is finally released after progressing through the quality 
assurance process, it will undergo many changes as part of normal 
authoring. During this period, no production data are created, and there 
is no issue about backward or forward compatibility of archetypes or 
queries with data.

The second dimension is to do with the kinds of change that can be made. 
First of all, many variations in data can be accommodated with no change 
at all - archetypes are constraint models, not cookie-cutter templates. 
Most archetypes are designed to be very open. Many changes to 
archetypes, including all translations, and any semantic change that 
loosens the constraints can be accommodated by a 'revision'. Only 
incompatible changes result in a version change, i.e. a change in the 
'.v1', '.v2' etc part of the archetype identifier. Now, after an 
archetype is released, such changes should be minimal, if not 
non-existent. Remember: this is only incompatible changes, such as ones 
that change the structure of information, make optional items mandatory 
and other such things. When a new version is created, a data migration 
algorithm has to be published with it.

The result of this is that new _versions_ of officially released 
archetypes should be very low in number and should always have a formal 
definition of how to migrate data created using an older version.

The confusing factor that people are seeing now is that due to the 
current tooling, most archetype authors are creating new 'versions' when 
in fact the changes are only new revisions. We are also seeing many 
archetypes that have not been quality assured. These limitations are 
being addressed with new tooling that will soon be available, and a 
better defined version numbering system, using a 3 part identifier. One 
of the things the new ADL parser will be able to do is to determine 
whether a given change requires a new version or not. The algorhitms for 
doing this are not trivial and it has taken some time to get them worked 
out.

In production systems different archetype versions may give rise to the 
following:
- automatic data migration of data from an old version to a new version 
of an archetype
- automatic on-the-fly translation of data from an old version to the 
form required by a new version

If either or both facilities are in operation, then only one version of 
any given archetype will effectively be vsible in the database - the 
latest. For situations where data created by more than one is left 
intact, we consider this as if it were two archetypes. I.e. there is a 
general need if you are querying 'systolic blood pressure' to find all 
archetpes in which this could be recorded and to generate an appropriate 
query. If let's say 2 out of 3 found archetypes happen to be two 
versions of one logical archetype, this is essentially the same 
situatoin as if 3 distinct archetypes had been found that carried this 
data item. The key to managing this is the forthcoming online archetype 
repository classification ontology which allows you to do this search. 
This ontology already exists in a basic form, and is what supports the 
querying at the old prototype repository at http://archetypes.com.au.

I hope this clarifies things

- thomas

openEHR templates specification draft proposals available

[Thomas Beale]

An important part of the specfications work this year is the upgraded 
archetype specification and the new template specification. These 
specifications define specialised archeytpes and also openEHR templates. 
The latter will now have the equivalent of the Archetype Definition 
Language (ADL) and the Archetype Object Model (AOM) - known as the 
Template Definition Language (TDL) and the Template Object Model (TOM). 
There will also be an Operational Template Model (OTM). The XSD 
expression of the AOM will be upgraded and made more efficient (there 
will be a new version, the old one will remain available, and an XSLT 
conversion script will need ot be created); a new XSD for templates will 
be created from the TOM; this will largely re-use the AOM XSD.

The basis of the template work has been tooling built by Ocean 
Informatics and used in various environments, but principally at the NHS 
since February 2007. This experience has provided the requirements and 
lessons needed to build what we believe is a solid open specification 
for templates that is compatible with the existing openEHR oeuvre. The 
acceptance of these proposals of course rests on validation via 
implementation, and the normal community and ARB review processes.

The home page for this work can be found on the openEHR wiki at 
http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes
 
. The community is encouraged to get involved in reviewing and 
contributing to the material.

- thomas beale

Parsing archetype xml with JAXB

[Thomas Beale]

Greg - I think this question would be better on the implementers list - 
to avoid causing too many heart attacks among the readers of this list 
on seeing actual code ;-)

- thomas beale

Greg Caulton wrote:
> Hi,
>
> I used JAXB to generate java files from the XSD files but I am not
> getting very far with the unmarshalling, currently I get:
>
> javax.xml.bind.UnmarshalException: Unable to create an instance of
> test123.COBJECT: Unable to create an instance of test123.COBJECT
>
> when executing the following code:
>
> JAXBContext jc = JAXBContext.newInstance(ARCHETYPE.class);
> Unmarshaller unmarshaller = jc.createUnmarshaller();
> JAXBElement root = unmarshaller.unmarshal(new
> StreamSource(new File(filename)), ARCHETYPE.class);
>
> I've tried both XML from subversion and XML freshly generated from the
> Ocean Archetype Editor.  the test123 is just the package I put the
> JAXB generated java files into, not related to the problem.
>
> I don't suppose anyone has run in this issue...?
>
> thanks!
>
> Greg
>
>
> http://www.patientos.org
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

Archetypes - regex question

[Thomas Beale]

Andrew Patterson wrote:
> Sam, without putting words in Adams mouth, I think he was asking about
> the precedence of include/exclude sections. It is a common problem is
> coming up with rule system like this - for instance one can look at the
> allow/deny pattern of the apache2.conf file for how to setup IP address
> ranges. In the apache case, there is an explicit clause that allows the
> order to be changed - either allow first then deny, or deny first then allow.
>
> In the ADL spec, this is mentioned as a "yet to be defined" (section 5.3.8).
>   
Indeed. I don't think the requirements have been adequately defined, so 
this remains one of the few little holes to plug properly in ADL.

- thomas

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

[Thomas Beale]

Georg Duftschmid wrote:
>
>  
> So I have the impression that an EHR reference model helps to achieve 
> some kind of "advanced functional interoperability", but I would not 
> say that it is REQUIRED to achieve functional interoperability 
> (refering to the PDF-exchange as a counter-example).
>  
*
no reference model = no computability, including queryability. To 
overcome that, if you use PDFs, plain text etc, you need structured 
meta-data. As soon as you need that (e.g. like IHE) you need a model of 
it. As soon as it tries to be more sophisticated, the model becomes more 
complex. If we want queryable, computable data (e.g. for decision 
support, research), you have to have models. Otherwise the software 
doesn't know what the data mean.

- thomas beale

*

Question on the role of EHR reference models for achievingfunctional interoperability

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

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

[Thomas Beale]

J.P. Freriks wrote:
>
> Or, another tool could be designed for GUI design. The clinicians will 
> work with this tool, after which Template designers distil the semantics 
> for the templates.
>
>   
*I think it will be one tool that writes two artefacts, one of which is 
GUI 'hints'. However, there are more semantic indicators being built 
into the template designer, some based on the NHS CUI project, that will 
provide good hints on GUI generation, including some temporal workflow 
aspects.

- thomas beale

*

Can you open a template (.oet) from an Href?

[Thomas Beale]

Hi Adam,

with respect to extensions:
- the XML archetypes could well become .xadl or .xaom (aom = archetype 
object model) files.
- the XML templates should probably become .xts (ts = template 
specification), because there will also be an operational template file, 
which is a template with all substitutions done, with an extension like 
.xot (ot = operational template) or .xtom (tom = template object model). 
The current 'templates' are template 'specifications', i.e. a set of 
differences with respect to archetypes. The 'operational' form is what 
can be used to create message definitions from, and can be used at runtime.

These changes plus the forthcoming standardised template models 
themselves will come through the openEHR process, so the final results 
in the template area will most likely differ from the current .oet files.

- thomas beale


Adam Flinton wrote:
> Dear All,
>
> I have build a complete publishing system for OpenEHR.
>
> It ends up in part with a bunch of href's in an HTML page e.g. if it 
> finds errors then it creates a link to the file in the relevant working 
> copy.
>
> 2 points:
>
> A) Wrt .adl I can set the filetype etc in windows & when I clik on a 
> link to an adl, the archetype editor opens with that file.
>
> Hurray.
>
> However..If I click on a .oet even if I set the template designer to 
> be the default file handler I just get a Dr Watson with
>
> EventType : clr20r3 P1 : templatedesigner.exe P2 : 1.0.1244.410
> P3 : 47608b1a P4 : mscorlib P5 : 2.0.0.0 P6 : 4333ab80 
> P7 : 26bb
> P8 : 38 P9 : system.argumentexception   
>
>
> Can the template designer open a .oet if passed by a browser or clicked 
> with a mouse having set the file association?
>
> It would be nice if it could as for instance wrt errors, this allows the 
> user to simply click on the file link, the relevant editor opens, the 
> fix can be made & the file saved.
>
>
> B) Obviously .xml is a commonly used extension..as such is there 
> any plan to swap to say .xadl before too many peopel start building 
> round .xml files? e.g. right now it will be easy for me to re-adjust 
> form .xml to .xadl.
>
>
> Adam
>
>
>
>
>
> **
> This message  may  contain  confidential  and  privileged information.
> If you are not  the intended  recipient please  accept our  apologies.
> Please do not disclose, copy or distribute  information in this e-mail
> or take any  action in reliance on its  contents: to do so is strictly
> prohibited and may be unlawful. Please inform us that this message has
> gone  astray  before  deleting it.  Thank  you for  your co-operation.
>
> NHSmail is used daily by over 100,000 staff in the NHS. Over a million
> messages  are sent every day by the system.  To find  out why more and
> more NHS personnel are  switching to  this NHS  Connecting  for Health
> system please visit www.connectingforhealth.nhs.uk/nhsmail
> ******
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

xml archetypes to xforms

[Thomas Beale]

Ime Asangansi wrote:
> Hi Adams et al,
>
> Nice to hear that.
> But I think the tough issue is converting the archetypes xml to xforms.
> Please how do you do that?
> especially converting the definition section...
>
there are already answers to this, but you don't want to convert 
archetypes to Xforms, you want to convert openEHR Templates. The new 
specifications for templates are underway and drafts will be available 
in the next few weeks.

- thomas beale

TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

New directions for openEHR 2008

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

New directions for openEHR 2008

[Thomas Beale]

KOBAYASHI, Shinji wrote:
> Dear Thomas,
>
>
> On Sat, 03 May 2008 13:12:59 +0100
> Thomas Beale  wrote:
>
>   
>> - openEHR Specification Roadmap 2008 - 
>> http://www.openehr.org/specifications/spec_roadmap_2008.html 
>> 
>
> I found ADL 1.5 in this roadmap. Otherwise, ADL 2.0 specification was
> announced last year. Would you explain the difference between ADL 1.5
> and 2.0?
>
>   
ADL 1.5 will contain extensions for supporting openEHR templates, i.e. 
some extra semantics (not much). ADL 2 is a more regular syntax for 
archetypes. When ADL 2 is adopted, it will contain all the semantics 
released in all previous versions, i.e. 1.4, 1.5 etc.

- thomas beale

Datatype questions

[Thomas Beale]

Adam,

by way of reference...

if you browse the UML pages at 
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/computable/UML/uml_start_view.html
 
via the lefthand side links starting with rm.data_types.*, you will see 
all the openEHR data types in a quick fashion. Else see the PDF on the 
specs page; link is 
http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf

These data types deal with rich text and similar: 
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109699984287_125592_6582Report.html

The XForm questions I leave for others...

- thomas beale


Adam Flinton wrote:
> Dear All,
>
> I am still mulling over how to validate openEhr messages (wrt testing) & 
> how to create Xforms etc.
>
> 3 separate questions
>
>
> A) I noticed this:
>
> http://www.openehr.org/wiki/display/dev/Data+type+widgets
>
> Has any progress been made?
>
>
> B) Is there a datatype for rich text (e.g. XHTML (possibly CData'ed))?
>
>
> C) Assuming a starting point of XMLwhat are the current ideas wrt 
> representing datatypes etc in a form which can be useful in a XForms 
> environment (e.g. datatypes as W3C schema objects, or as schematron 
> rules or...etc).
>
>
> E.g. assume 2 use cases:
>
> A) An XML message containing OpenEHR structures/information - now I need 
> to validate that everything is OK including the datatypes
> B) An XForm with in place/browser validation (e.g. wrt lists of possible 
> values, patterns etc.etc.).
>
>
> Adam
>
> **
> This message  may  contain  confidential  and  privileged information.
> If you are not  the intended  recipient please  accept our  apologies.
> Please do not disclose, copy or distribute  information in this e-mail
> or take any  action in reliance on its  contents: to do so is strictly
> prohibited and may be unlawful. Please inform us that this message has
> gone  astray  before  deleting it.  Thank  you for  your co-operation.
>
> NHSmail is used daily by over 100,000 staff in the NHS. Over a million
> messages  are sent every day by the system.  To find  out why more and
> more NHS personnel are  switching to  this NHS  Connecting  for Health
> system please visit www.connectingforhealth.nhs.uk/nhsmail
> **
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
*Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>


*
*

ARCHETYPE_ONTOLOGY

[Thomas Beale]

Tim Cook wrote:
> While implementing ARCHETYPE objects I ran into an odd thing.  Maybe I
> am missing something or there is a mistake in the documentation?
>
> The ontology attribute of ARCHETYPE is of the type ARCHETYPE_ONTOLOGY.
> The AOM then says that the attribute ARCHETYPE_ONTOLOGY.parent_archetype
> is of type ARCHETYPE and it is described as the; "Archetype which owns
> this ontology."
>
> Is that REALLY what it should be or should
> ARCHETYPE_ONTOLOGY.parent_archetype be an ARCHETYPE_ID?
>
> Thanks,
> Tim
>   
*Tim,

this attribute is populated in memory when an archetype is deserialised, 
so it points to the actual ARCHETYPE object. In almost every case (of 
the few that there are) that there is a 'parent' reference, it works 
like this.

- thomas

*

ARCHETYPE_ONTOLOGY

[Thomas Beale]

Tim Cook wrote:
> On Wed, 2008-05-07 at 18:04 +0100, Thomas Beale wrote:
>
>   
>> this attribute is populated in memory when an archetype is deserialised, 
>> so it points to the actual ARCHETYPE object. In almost every case (of 
>> the few that there are) that there is a 'parent' reference, it works 
>> like this.
>> 
>
> Okay, so now my understanding is that;  the attribute contains the
> parent archetype of this archetype?  Not the current ("owner of this
> ontology") archetype (which is circular).   That kind of clears that up.
>   
no - it is the latter - the owner archetype. 'parent' was a poor choice 
of name
> But according to the AOM spec:
> "2.3.3  Archetype Specialisation
> ...
> reach them.
> "
>
> I originally read this to say that the specialization section was really
> for information and not an operational requirement for an archetype
> instance. 
>   
there is a whole new section in the forthcoming version 1.5 of ADL that 
(finally;-) deals with specialisation semantics.
> However, from your explanation.  It seems to me that an archetype
> instance with layers of specialization will require instances of all
> parents nested within.  If this is true; what value are they at
> implementation?  
>   
in the archetype workbench we have implemented the idea of an 'archetype 
lineage', i.e. specialisation trees of archetypes. Each specialised 
archetype in the tree is in its 'differential' form, and also in its 
'flat' generated form. Now, a confusing factor here in this is that the 
current .adl files for specialised archetypes are in the flat form, i..e 
they contain copies of inherited elements from parents. Clearly this is 
not maintainable, so in the new generation of tools, .adls will be used 
as the source files and these will be in differential form. For the 
majority of archetypes that are not specialised, the result is the same. 
The .adl files of the future will be generated from the .adls files; for 
specialisation archetypes this is done by doing an 
'inheritance-flattening' procedure. This is already implemented in a 
basic way in the latest release of the Archetype Workbench.

Drafts of the new version of the ADL specification will be available as 
soon as they are in a comprehensible form.

- thomas