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]
OpenEHR conversation.rtf
Description: OpenEHR conversation.rtf
