As some of you may have noticed, I set up a wiki page with some ideas about how openEHR experience could contribute to the next revision of 13606. In my view, there are two kinds of ‘experience’ - things that have worked well, like the EHR Extract model, demographic model, ADL/AOM 1.5, and things we learned we need to fix - particularly various RM issues (See the SPEC PR tracker to get some idea). There are also various 13606 implementations around, although I don’t have much direct knowledge of them - others here will hopefully contribute on that matter.
One thing I do know, having worked with people in various government programmes is that they are tired of not know ‘what standard to use’, and what they perceive as confusion in the EHR standards space.
And yet, if we think about it, the technology we are trying to use is the same: reference model, archetypes, templates, and all the tooling that goes with it. That tells me that it makes sense for a single community to work together on such technology, and as a side effect, produce specifications that can be accepted as official standards.
These are just my thoughts. Others here may see things differently. So my questions are: does it make sense to try to build an integrated openEHR/13606 proposal for the next revision of 13606? If so, what should the basic strategy be?
Hi Tom,
Perhaps its time for openEHR lite. This might seem scary and we might need to give up on some modelling purity but I can’t see how we can achieve convergence without give and take.
I think we should start in the scope of 13606 part 1. EHR extracts for single subject. But this includes its dependencies, data types, entries without item_structures, sections, composition, distributed versions and audit details. We obviously need a demographic party representation which seems to need some work still. Not so lite after all, but my point is we should attempt to tone down for standardisation but in a way we can still use extensions in openEHR. Backward compatibility is possibly more important in the openEHR case but those in 13606 circles may disagree so we need to accept some change in both directions for the better good.
To me first steps are accept openEHR datatypes or subset thereof, remove item_structure with backward compatibility, distributed versions and demographic party model.
The issues with the demographic model is its limited rules for use and generic yet powerful structure. To powerful without rules. We need those with experience to get together and share implentation approaches to develop patterns, perhaps this can be done on a wiki for starters but maybe some conference call presentations may accelerate the process. My experience is that the by reference relationship between actor and role is hard to utilise and the mandatory idendity inherited from party requires duplication of the identity on actor and role. Although I understand the need to reference a party rather than an actor with multiple roles, I am thinking there may be another way to do this rather using an object uid so that the roles is a containment relationship rather than by reference.
Perhaps this was best in another email on a different list.
Heath