CEN meeting and data types
Gerard Freriks wrote: > Thomas, > > I agree with you that in the case CEN (13606) adopts the OpenEHR data > types they know that it is proven technology. > Just now, when any moment CEN/tc251 EN13606 will get published, we > dearly need proven data types to implement it. > > In the case that CEN will make the choice for OpenEHR, my remaining > questions are: > What harm is done? > How can CEN/tc251 EN13606 be aligned, some years from now, with the > forthcoming ISO data type standard? > Can it be aligned? Or can't it? > I think Grahame will ensure that it is not only 'aligned', but safely inter-convertible... - he is working on it now. - thomas ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
hey Sam I'll bite ;-) > but the openEHR data types are ready for > archetypes and the cluster element (leaf node) architecture. it you want, we can go round and round on semantic issues. Always a pleasure ;-). But is there anything specific that makes you think that it would be inappropriate or unwise to use the iso datatypes in the document with 13606? (so not including general issues) Grahame Sam Heard wrote: > Dear All > > I have been at the CEN working group meetings representing Standards > Australia. > It is clear to me that CEN needs to take on the openEHR data types in order > to > progress quickly. The ISO data types are likely to be appropriate for the HL7 > environment and will map to openEHR - but the openEHR data types are ready > for > archetypes and the cluster element (leaf node) architecture. > > You can have a look at the ISO data type proposal likely to come through HL7 > soon at: > > http://informatics.mayo.edu/wiki/index.php/ISO_Datatypes > > user name: wiki > > password: wikiwiki > > > It will be helpful to make your views known on this list. > > Cheers, Sam > -- o ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Thomas, I agree with you that in the case CEN (13606) adopts the OpenEHR data types they know that it is proven technology. Just now, when any moment CEN/tc251 EN13606 will get published, we dearly need proven data types to implement it. In the case that CEN will make the choice for OpenEHR, my remaining questions are: What harm is done? How can CEN/tc251 EN13606 be aligned, some years from now, with the forthcoming ISO data type standard? Can it be aligned? Or can't it? Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 22-feb-2007, at 11:27, Thomas Beale wrote: > Grahame Grieve wrote: >> hey Sam >> >> I'll bite ;-) >> >>> but the openEHR data types are ready for >>> archetypes and the cluster element (leaf node) architecture. >> >> it you want, we can go round and round on semantic issues. Always >> a pleasure ;-). But is there anything specific that makes >> you think that it would be inappropriate or unwise to use the >> iso datatypes in the document with 13606? (so not including >> general issues) >> >> > I guess it depends on what CEN wants to achieve, and also what the > implementation state and intention of the ISO types is. > Possibilities I see: > > * Let's say that the ISO types provide a set of types whose > purpose > is to facilitate data type conversion between HL7 & HL7-like > (e.g. > various flavours of v2, v3 etc), openEHR, others (UN-cefact? > ASTM? > etc). Then the kind of implementations will be limited to XML > conversion. > * On the other hand, if they were used as "real data types", > say in > CEN, then there is now the job of implementing them in all the > major technologies and testing them. Plus they need to be > checked > for use with archetypes. > * If CEN used the openEHR data types, they get something > implemented > in Java, C#, Eiffel, XSD (others?), that are heavily debugged > and > in production use now, and for which the constraint semantics > and > syntax are already known and tested in ADL. This includes > constraint types for String (C_STRING), Integer (C_INTEGER), > Date (C_DATE)..plus specialist constrainer types for > DV_ORDINAL (C_DV_ORDINAL), DV_QUANITTY (C_DV_QUANTTY) and > CODE_PHRASE (C_CODE_PHRASE). These have all been tested and are > known to work, and numerous archetypes have used them. Also, the > openEHR data types are founded on existing standard data types > (ISO11404), and assume the standard semantics for all the usual > built-in things (String, Integer, Boolean, Array<>, List<>,...) > plus the ISO8601 date/time types (Date, Time, etc) > > Now, since CEN is an archetype-enabled standard, it might make > sense to > use data types that are known to work in software and known to work > for > archetypes. > > So one question is: what is the intended use of the new ISO date types > (conversion, or to be the 'real thing')? Secondly, how will CEN > EN13606 > be validated with a new set of data types? > > - thomas beale > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070222/34fb2ebf/attachment.html> -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Archetype lists and possible archetypes
Dear Sam, Excludes and Includes, open/closed might serve most requirements. We do need certain rules as well, e.g. can we set a slot which "excludes all". Like Gerard and Koray had mentioned, I agree to have a way to categorise the archetypes. That would make the includes and excludes lots easier. I guess an ontology might play a role here. Regards, Chunlan Sam Heard wrote: > Dear All (apologies for cross posting) > > I have been discussing the slot assertions off line and want to make > sure the clinical requirements in this space are understood by the > clinical guys. At the moment the Ocean tools work on the same basis as > the Apache url include and exclude statements but I won't go into that. > > My view on the slots is that they have to be open by default (ie let > other archetypes in) as the archetype is an absolute rule which cannot > be broken. If we close slots in the usual case then people who > specialise archetypes and make new ones will have to negotiate the > slot authors in other archetypes. This means that the include > statements are generally guidelines and help people compose sensible > information structures. > > We do, however, want to close some archetype slots - I will give two > examples: > > SECTION: Vital Signs > > It is clear that vital signs section should only contain a limited set > of observations - although this might change over many years with the > introduction of Oxygen sats for example. Even then, perhaps a > specialisation of the archetype is better - or a new one. So here the > slot may allow temperature, pulse, blood pressure, respirations and O2 > sats. > > So we may need to say here that no other archetypes are allowed. > > CLUSTER: Symptom > The proposed symptom cluster has a cluster for associated symptoms - > and these can only be symptom cluster archetypes. This seems sensible. > > There are many examples where we will not want to limit the > inclusions, such as the O: heading in SECTION: SOAP where almost any > observation might be required, though we might have the most usually > used archetypes specifically included (in the archetype or the > template). I do not believe that we will know at design time all the > suitable archetypes for a slot - but we might know many that are > definitely suitable. > > BUT, we do need to say when one or more archetypes is not suitable - > and we need to say when the set is closed (ie no more). > > What do others think about the requirements for slots? > > Cheers, Sam > > > -- > > > Dr. Sam Heard > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > CEO and Clinical Director > Ocean Informatics Pty. Ltd. > <http://www.oceaninformatics.biz/>Adjunct Professor, Health > Informatics, Central Queensland University > Senior Visiting Research Fellow, CHIME, University College London > Chair, Standards Australia, EHR Working Group (IT14-9-2) > /Ph: +61 (0)4 1783 8808/ > /Fx: +61 (0)8 8948 0215/ > > > > >___ >openEHR-clinical mailing list >openEHR-clinical at openehr.org >http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070222/58d3d7af/attachment.html> -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Grahame Grieve wrote: > hey Sam > > I'll bite ;-) > > > but the openEHR data types are ready for > > archetypes and the cluster element (leaf node) architecture. > > it you want, we can go round and round on semantic issues. Always > a pleasure ;-). But is there anything specific that makes > you think that it would be inappropriate or unwise to use the > iso datatypes in the document with 13606? (so not including > general issues) > > I guess it depends on what CEN wants to achieve, and also what the implementation state and intention of the ISO types is. Possibilities I see: * Let's say that the ISO types provide a set of types whose purpose is to facilitate data type conversion between HL7 & HL7-like (e.g. various flavours of v2, v3 etc), openEHR, others (UN-cefact? ASTM? etc). Then the kind of implementations will be limited to XML conversion. * On the other hand, if they were used as "real data types", say in CEN, then there is now the job of implementing them in all the major technologies and testing them. Plus they need to be checked for use with archetypes. * If CEN used the openEHR data types, they get something implemented in Java, C#, Eiffel, XSD (others?), that are heavily debugged and in production use now, and for which the constraint semantics and syntax are already known and tested in ADL. This includes constraint types for String (C_STRING), Integer (C_INTEGER), Date (C_DATE)..plus specialist constrainer types for DV_ORDINAL (C_DV_ORDINAL), DV_QUANITTY (C_DV_QUANTTY) and CODE_PHRASE (C_CODE_PHRASE). These have all been tested and are known to work, and numerous archetypes have used them. Also, the openEHR data types are founded on existing standard data types (ISO11404), and assume the standard semantics for all the usual built-in things (String, Integer, Boolean, Array<>, List<>,...) plus the ISO8601 date/time types (Date, Time, etc) Now, since CEN is an archetype-enabled standard, it might make sense to use data types that are known to work in software and known to work for archetypes. So one question is: what is the intended use of the new ISO date types (conversion, or to be the 'real thing')? Secondly, how will CEN EN13606 be validated with a new set of data types? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN meeting and data types
Sam, It would be helpful to provide (more) arguments for your opinion. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 22-feb-2007, at 0:42, Sam Heard wrote: > Dear All > > I have been at the CEN working group meetings representing > Standards Australia. It is clear to me that CEN needs to take on > the openEHR data types in order to progress quickly. The ISO data > types are likely to be appropriate for the HL7 environment and will > map to openEHR - but the openEHR data types are ready for > archetypes and the cluster element (leaf node) architecture. > > You can have a look at the ISO data type proposal likely to come > through HL7 soon at: > > http://informatics.mayo.edu/wiki/index.php/ISO_Datatypes > > user name: wiki > > password: wikiwiki > > > It will be helpful to make your views known on this list. > > Cheers, Sam > -- > Dr. Sam Heard > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > CEO and Clinical Director > Ocean Informatics Pty. Ltd. > Adjunct Professor, Health Informatics, Central Queensland University > Senior Visiting Research Fellow, CHIME, University College London > Chair, Standards Australia, EHR Working Group (IT14-9-2) > Ph: +61 (0)4 1783 8808 > Fx: +61 (0)8 8948 0215 > > ___ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070222/d3ef26c7/attachment.html> -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Release 1.0.1 Final drafts coming online
See the Release 1.0.1 specification page, look for Status = FINAL DRAFT. The remainder of the specifications will be appearing in final draft over the next few weeks before we announce the release. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
