Darius, sorry if I misinterpreted what you had mentioned before, and now I understand more about the vision of OCC. My only point was that I think whoever is going to build the OCC should check in with OpenEHR to see if they've already built something like OCC, but for archetypes i.e. a way to share between implementations, have multiple per archetype, and all the other functions for OCC because if there is, then perhaps instead of building the OCC we should build a concept-archetype connector and then just use their tools. If someone has already done this check and it's not feasible, then no problem. Am I making sense?
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 Dave Thomas Sent: Thursday, August 04, 2011 4:24 To: [email protected] Subject: Re: [OPENMRS-DEV] OCC discussion I could be totally wrong about this, but the last time I looked at the openehr archetype repository, there were no entries for malaria, tb and hiv? (although they must exist somewhere and are just not published, and the last time I looked was six months ago) The occ has actually has a good opportunity to inform openehr archetypes going forward, in an evidence based way by providing metrics around how things are being modeled across quite a few varied implementations, in parts of the world where archetypes aren't being used as widely. D On Aug 4, 2011 2:23 AM, "Darius Jazayeri" <[email protected] <mailto:djazayeri%[email protected]> > wrote: > 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] ________________________________ 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]
