Great initiative. Let's go for it. Even though I agree with your previous remarks that this probably won't provide a long term solution, IMHO it's absolutely necessary in order to secure short term progress.
Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this. Cheers, Stef Op 9 sep 2011, om 14:24 heeft Thomas Beale het volgende geschreven: > > As you may have noticed, the new release of the ADL Workbench enables > exploration of multiple reference models and their classes. Although the > 13606 schema is not yet complete (in particular the data types require work), > it is now possible to see the differences and similarities of the 13606 and > openEHR reference models. Similarly, archetypes based on both reference > models can be viewed, validated and compared. > > I see various possibilities: > convergence of 13606 and openEHR onto one reference model. The opportunity to > do this is coming up in May 2012, where 13606-1 and 13606-2 reach their 3 > year review point, at which ISO has to decide to either retire them or > continue their use, depending on their use in industry. I don't know what use > in industry they have to date, but let's assume the decision is made to > continue - it is clear that changes could be made. Implementers of both > openEHR and 13606 have now had some 3 years to discover real problems and > deficiencies. In openEHR there are around 150 Problem Reports and Change > Requests generated over this time; clearly some of these would apply equally > to 13606. Some possible changes: > it is now possible to see how 13606 and openEHR could be merged into one > reference model at the Entry level, e.g. with changes like: > openEHR has richer 'design-based' Entry types like Observation, Instruction > and Action, but also a generic type called Integration_entry, which nearly a > mirror image of the EN13606 ENTRY. A future standard could support all of > these types, with the users choosing which ones best supported their data. > openEHR's data structures (ITEM_STRUCTURE, ITEM_TREE, ITEM_TABLE) etc may be > able to be retired in lieu of the only simpler CLUSTER/ELEMENT structure in > use by both standards, and a 'structure marker' as used by 13606 - this would > further ease merging of the reference models. > a common data types model could be found. At the moment, openEHR's data types > work very well and have been shaped by archetyping as well as normal software > considerations. For 13606, in theory the ISO 21090 data types are supposed to > be used. In their current state, they cannot be, and are both completely > normalised and optimised for HL7v3 use, as well as suffering from key > modelling problems. It has been stated that an ISO 21090 'profile' will be > developed for 13606, although this has not yet been done. In my view, the HL7 > 'profiling' process is almost unworkable, and I think a completely different > set of data types is needed for 13606 - a far simpler set, e.g. based on a > simplified version of openEHR, or Grahame Grieve's Resources for Health data > types (which include both openEHR and HL7 influences, as well as > using proper object modelling). > a few useful Change Requests have been made based on CDA. Once these are > done, the merged RM would be a superset of all models in use today, with the > added value of being more rigorously defined and therefore usable for > tool-based code generation, data transformation and the like. > adoption of ADL/AOM 1.5 as a new 13606 part 2. Although it seems as if ADL > 1.5 is taking a long time (it is ;-) it is being continuously tested in real > software on the way, so that what emerges will be something close to a > 'stable' standard (openEHR might decide to give it DSTU status from the > outset for example) rather than an untested set of proposals. It is > backwardly compatible with ADL 1.4, while fixing all the main problems and > limits of 1.4. It includes many (in fact almost only) features proposed by > people working with real archetypes in real environments, so I think it is > safe to say that the 40 or so changes (most very small) really reflect the > last 4-5 years' industry validation rather than any kind of theorising. If > ADL/AOM 1.5 were to become the next version of 13606-2, then we can > contemplate: > shared tooling: doing this would mean that all 13606 efforts can use the > openEHR tooling, which is growing by the day, and that people working with > openEHR can use tooling that is currently 13606 ADL specific. > shared archetypes: if the reference models were merged then '13606 > archetypes' and 'openEHR archetypes' are just the same thing - it is just a > question of different parts of the same reference model being archetyped. > How could we go about this work? > we can all run back to our comfort zones and stick with our current models, > and make the usual half-hearted attempt at harmonisation within the official > standards processes, OR > we could, starting today, develop a hybrid RM, using the schema definition > capability of the ADL Workbench, and analyse it, build some test archetypes > against it and so on. In this way, we could come up with a proposal that > could more or less be directly used by the ISO process to update 13606. > now, doing this is not just a case of - let's build a new model - we probably > need a strategy where copies were made of both the current 13606 and current > openEHR models, and agreed changes applied to each that brought them closer > together, with the impact of the changes being known for existing users of > the current models. But with a bit of discipline, I think it is doable. > At this point, I would like to see what interest there is in an initiative > like the above. If there is interest, we could create a dedicated mailing > list and project workspace for it, and start to do some work on it. > > So - what are people's thoughts on this? > > - thomas beale > > _______________________________________________ > 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/20110909/0bd9f515/attachment.html>
