Joaquin, Thanks for reaching out to them.
I don't actually recall making any argument related to OpenEHR. I actually think that the "super-concepts" that the OCC will be able to construct out of multiple OpenMRS concepts aren't dissimilar from OpenEHR archetypes. (But the idea behind OCC is that the archetype-like thing arises from crowds of people all configuring their concepts in different ways, with better ways being more common. But the OCC will also contain *bad* representations of the same concept, just those should be less-commonly copied.) -Darius On Wed, Aug 3, 2011 at 3:06 PM, Blaya, Joaquin Andres < [email protected]> wrote: > Hi guys, > In the spirit of seeing if others have done this before, I emailed the > openEHR technical email list with this. And I'm attaching the email > discussion below (as well as the text attachment). I also don't know that > much about OpenEHR, but I wanted to inquire about the argument that Darius > made that they wouldn't be able to house many concepts for a single idea > i.e. multiple ways of saying gender. And it seems that they have found a > way to do it. So I guess what I'm saying is that if we where to do mappings > of OpenMRS concept to OpenEHR archetypes, it seems (obviously someone would > have to do a feasiblilty check) we wouldn't have to build an OCC, but rather > use the openEHR editors and resources. > > Joaquin > > Date: Wed, 3 Aug 2011 09:46:55 +0100 > From: Ian McNicoll <[email protected]> > Subject: Re: Multiple archetypes in a single concept as a way to > create an archetype collaborative > To: For openEHR technical discussions <[email protected]> > Message-ID: > <cag-n1kzz1ev24ottj3g2a_7w3u7qcrezb3yxv_mtkj9oyqx...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Joaquim, > > Just to add to Hugh's excellent comments. One of the issues you will find > is that it is sometimes impossible to harmonise all the competing > perspectives, even for something as seemingly simple as demographics. > The archetype driven approach, with maximal dataset philosophy, allows > these competing views to co-exist, very visibly and acts as a spur for > future harmonisation. 'Minimal dataset' philosophies lose this knowledge and > any future attempts at rationalisation essentially have to start from > scratch. So, as well, as capturing shared, agreed requirements, we are also > capturing dissent, which we can try again to resolve in the future. > > You should have a look at the Demographics model archetypes on CKM at > www.openehr.org/knowledge > > e.g. Person > http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.479 > > We have had a few discussions with openMRS people in the past, and I am > sure there is real value in collaboration. I think the archetype methodology > and review process would be of great value, even if openEHR was not used > formally at the back-end of openMRS systems. > > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > [email protected] > > > Op 3 aug 2011, om 09:44 heeft Hugh Leslie het volgende geschreven: > > > Hi Joaquin > > > > Just to add another view... > > > > The issue of openMRS implementations having different representations of > the same thing is a common problem across clinical systems everywhere. Its > this problem that is one of the things that we are trying to solve with > archetypes. In general, what we find is that most clinical concept > representations in clinical systems are subsets (based on a use case) of a > fully specified concept. What we try to do in the archetypes is produce > the fully specified concept and then constrain it for all the use cases. > The different names that you see used for different concepts are not just > language dependent, but are also region and usage dependent. This is also > usually a matter of constraining the archetype or using a particular > terminology subset to represent the information. > > > > What openEHR offers openMRS is a single way of representing clinical > information that becomes a logical record architecture. If openMRS adopted > this approach, then any openMRS system could immediately share information > with any other even if the other system hadn't seen the information before. > It also means that the burden of developing high quality, clinician > validated information models is shifted away from the application developer > to a global or regional space. This is going to become more and more > critical, as we try to capture more complex clinical information and compute > on it as well as share it. > > URL: > http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/20110803/71e07b6c/attachment-0001.html > > > > regards Hugh > > > > > > > Date: Tue, 2 Aug 2011 23:15:56 +0430 > From: Abbas Shojaee <[email protected]> > Subject: Re: Multiple archetypes in a single concept as a way to > create an archetype collaborative > To: For openEHR technical discussions <[email protected]> > Hi Joaquin > > OpenEHR is a language and ontology neutral, standard. Archetype class is > ready for translations via its ancestor: AUTHORED_RESOURCE that has > unbounded instances of TRANSLATION_DETAILS. Several phrases (words) > pertaining to a sole concept can be implemented via Terminology package that > helps with assigning terminologies of any kind to map to Archetype parts. > > Regards > > > Joaquin, > > obvious a proper analysis would require a more detailed requirements > expression, but in terms of languages, archetypes most likely do what you > need. For an example, see the Apgar archetype at openEHR.org Clinical > Knowledge Manager <http://www.openehr.org/knowledge/>(CKM): > > * in the left hand side explorer, navigate to EHR Archetypes > Entry > > Observation >Apgar Score > * double click > * in the toolbar in the main pane, choose any of the first 3 views > (one page HTML, tabbed HTML, mind-map) and then choose the language > you want on the right hand drop down > > To see how this is represented in the raw form, use the 4th or 5th views > (ADL or XML). > > - thomas beale > > > Message: 2 > Date: Tue, 2 Aug 2011 13:29:43 -0400 > From: "Blaya, Joaquin Andres" <[email protected]> > Subject: Multiple archetypes in a single concept as a way to create an > archetype collaborative > To: "[email protected]" <[email protected]> > Message-ID: > < > 678428b8ceb52d4d9ace73c4946d7ade01fcdcc4b...@itccrmail01.med.harvard.edu> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > Apologies in advance if this is the incorrect email list for this topic, > but I thought it was the most relevant. > > I'm a member of OpenMRS and there we are discussion a way to have users > share the concepts (a limited form of an archetype) created in their > systems. This means that for a single concept you could have many concepts > from different implementations. This could be because of language or because > different words refer to the same concept. For example, Gender in the US > might be Sex in another country and Sexo in spanish. > > I would like to see if OpenEHR has solved this problem so that perhaps > OpenMRS could begin to use archetypes. > > Thanks > > Joaquin > > ___________________________________________________________________ > Chief Technology Officer, eHealth Systems Chile > Research Fellow, Harvard Medical School/Partners In Health > Moderator, GHDOnline.org > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Darius > Jazayeri > Sent: Saturday, July 30, 2011 0:20 > To: [email protected] > Subject: Re: [OPENMRS-DEV] OCC discussion > > I was actually thinking we allow you to either download a specific variant, > OR get a non-specific archetypal concept. > > The default updating behavior would differ. I imagine we can implement the > specific-variant update behavior quickly this sprint. (Which is why I'm > pushing for that.) > > -Darius (via his phone) > > On Jul 29, 2011 6:58 PM, "Burke Mamlin" <[email protected]> > wrote: > > So, when you go to create a MARITAL STATUS concept, discover that 30 > sites are already using the a MARITAL STATUS concept that meets your needs, > and you say "I want that too", who is the original source? > > If we created an "OCC ORIGIN" mapping that contained the UUID of the > original source, we could satisfy your use case (notify you when the origin > has changes) while still keeping the "purity" of the OCC design by > maintaining local ownership (i.e., if you add a mapping, you can because > it's always "your" concept). When you ask OCC for a copy of a specific > implementation's concept, the "OCC ORIGIN" mapping would be added. In the > case that you were searching the OCC, found 30 sites using the same MARITAL > STATUS concept, and wanted a copy for yourself, we would have the option of > either (1) making you pick one of the 30 (and get that site's UUID as a OCC > ORIGIN mapping or (2) let you get a copy without selecting a specific site, > in which case there would be no OCC ORIGIN mapping. > > I think something like an OCC ORIGIN mapping could let us have our > cake & eat it too. I'm not convinced that using a mapping to track the > origin is the best choice, but it has the nice feature of not requiring data > model changes to 1.6 to work. :-) > > -Burke > > > > On Fri, Jul 29, 2011 at 8:20 PM, Darius Jazayeri < > [email protected]> wrote: > > > > > ...stupid phone. > > > > I'm ok doing the own uuid thing if we can guarantee that > at the end of this... > > ________________________________ > > Click here to unsubscribe <mailto: > [email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS > Developers' mailing list > > > ________________________________ > > Click here to unsubscribe > <mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > ________________________________ > > Click here to unsubscribe > <mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
