We've been in touch with the WHO from the beginning stages of the OCC and they have a long term goal of being able to import/export archetypes into/out of the occ. I would hope if they knew about some other archetype sharing tool they would have instead guided us in that direction!
Ben On Fri, Aug 5, 2011 at 12:57 AM, Darius Jazayeri <[email protected]> wrote: > You are making sense. > But OCC is far enough along that not writing it isn't an option at this > point. :-) > > -Darius > > On Thu, Aug 4, 2011 at 1:52 PM, Blaya, Joaquin Andres > <[email protected]> wrote: >> >> 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] > > ________________________________ > Click here to unsubscribe 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]
