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] > _________________________________________ 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]
