Dear Erik, Some personal comments in the text below.
GF Gerard Freriks +31 620347088 gfrer at luna.nl ===================================== On 15 dec. 2011, at 15:02, Erik Sundvall wrote: > Hi! > > On Thu, Dec 15, 2011 at 08:52, David Moner <damoca at gmail.com> wrote: >> The unofficial renewal process of 13606 (or pre-SDO process, as you prefer >> :-) will start next February at the EN 13606 Association General Assembly in >> Seville with an open and public consultation. > > Is there any formal link between the 13606 Association and the actual > standardisation process or is the "pre-SDO process" to be seen as > traditional lobbying? There are personal bonds. The EN13606 Association has asked for a formal Liaison status with CEN/tc251. ISO/tc215 will follow. > > Perhaps the best thing would be if the 13606 Association and openEHR > could bring forward a unified co-authored suggestion to the SDO > process rather than two suggestions? Perhaps we can use the new > mailing list Thomas suggested for mail conversations combined with the > wiki of the EN 13606 Association, instead of having separate mailing > lists and separate wikis for the alignment discussions in each > community? Yes: that would be nice. No: it is not essential. > >> Before that, to prepare a >> draft starting point, during January a consultation will be made to key >> actors, implementers and users of the standard, including openEHR. > > A great thing would be to actually have at least two independent > _implementations_ of change suggestions (both AM and RM) after initial > discussions but before any revisions to the standard are made. That is > how some other SDOs work with technical artefacts and it could avoid > some of the previous suboptimal approaches. So you agree with my NO. > > I assume AOM 1.5 is a candidate for AM? Is anybody already working on > an AOM 1.5 implementation in addition to Tom's Eiffel version? Are > there people interested in updating the Java implementation (or some > other implementation) before or during the SDO process? I think that some additions to AOM 1.5 will be supported by us. And we will have new requirements, possibly. > > Regarding the RM I know Tom is experimenting with simplified > ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other > RM-redesign experiments going on anywhere? In my personal thinking the model around the Entry, Cluster and Element will be simplified. We need to reduce the number of degrees of freedom producing archetypes. This is an important driving factor behind the new requirements based on our experiences producing archetypes. In addition I'm of the opinion that in the Composition and Section the Entry Class must be 'reached' via a reference to an existing committed Entry, only. In this way there is a more strict separation between functionality dealing with presentation/structure and the essential clinical relevant data and information that is documented. These new RM's are not tested in working EHR applications. They are 'tested' in a sense because we investigate what kind of archetypes can be produced. And whether the number of degrees of freedom is less, but sufficient. > > What is happening in the 13606-world regarding thoughts about > practical datatypes? My personal ideas: - in Archetypes we need to have defined a set of "Leaf-node-Type", being indications what a healthcare provider can expect. For the techie it is an indication what real data type will be used. - We need at the minimum the CEN data types, with exclusion of the ordinal data type, because at a higher level we will define 'Semantic Ordinals' as subpatterns used to model archetypes. These 'Semantic Ordinals' have additional functionality so more than one can be selected, the order in which presented can be recorded, additional inclusion and exclusion criteria and signaling range plus attached value that can be used for calculations. - It would be nice, but not essential, to have these 13606 datatypes as profiles of the ISO standard. > > What about (optional) reusable ENTRY subtypes in the 13606 world? (see > http://www.openehr.org/mailarchives/openehr-technical/msg05285.html > under the heading "2. OBSERVATION et. al. (ISO 13606 CR)") We need to be able to use specialisations of the Entry class. My thinking is that these health specific specialisations ( Observation, Evaluation, Instruction, Action, etc.) must not play a role in the RM. We are working on an addition to the 13606 standard that defines how semantic interoperability artefacts are structured, used in other semantic artefacts, how standardised modeling patterns are used, etc. In this scheme all these things define a standard for the semantic layer on top of the present technical 13606 layer. I foresee a strict separation between the technical 13606 standard (as we know it) and a semantic artefact layer (that we will need to wok on) The technical layer is very generic, healthcare a-specific. The Semantic artefact layer will have some health specific items incorporated: e.g. Observation, etc. but even then contain many health a-specific constructs that can be used outside of healthcare. This thinking will have consequences for the present 13606 parts 1, 2 and 3. Some of the ideas ended up in the EN13606 WIKI. > >> As you know, my opinion is that an harmonisation or at least a seamless >> transition between 13606 and openEHR is a key element to succeed. > > I totally agree. What I'm after is a specification in the public domain owned by a formal SDO. And that is what we all need. > > Bringing the communities tighter together is another important thing. > The way some leaders sometimes talk of the other organisation's > approaches might not be helpful in that sense. Those of you having > formal powers in each organisation please ask your leaders to speak as > honestly and nicely as possible of each others > organisations/communities/approaches, or else please change leaders. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/b2765baa/attachment.html>
