-------------------- Andrew S. Kanter, MD MPH
- Director of Health Information Systems/Medical Informatics Millennium Villages Project, Earth Institute, Columbia University - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology Columbia University Email: [email protected] Mobile: +1 (646) 469-2421 Office: +1 (212) 305-4842 Skype: akanter-ippnw Yahoo: andy_kanter ----- Forwarded Message ----- >From: Andrew Kanter <[email protected]> >To: [email protected] >Sent: Friday, March 30, 2012 2:22 PM >Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! > > >I would NOT default to SAME-AS this is a narrower and special status... The >more common would be IS-A or narrower-than. Our concepts in general are >usually NARROWER than the concept being mapped to... > > >Andy > >-------------------- >Andrew S. Kanter, MD MPH > >- Director of Health Information Systems/Medical Informatics >Millennium Villages Project, Earth Institute, Columbia University >- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology >Columbia University > >Email: [email protected] >Mobile: +1 (646) 469-2421 >Office: +1 (212) 305-4842 >Skype: akanter-ippnw >Yahoo: andy_kanter > > > >>________________________________ >> From: Wyclif Luyima <[email protected]> >>To: [email protected] >>Sent: Friday, March 30, 2012 12:02 PM >>Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! >> >> >>An implementation is only required to have at least one map type that will be >>used as the default for concept mappings when sharing metadata through occ >>and metadata from versions earlier than 1.9, and there is a global property >>for it. I would be fine with explicitly picking the default map type, i think >>should be 'same-as' and then only hard code its uuid. >> >> >>Wyclif >> >> >>On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[email protected]> wrote: >> >>The reason i guess why we never hard corded the uuids is because typically >>implementations can create their own concept map types which will still >>result in having map types with differing uuids. The reason we added these is >>to simplify this process for them by defining the widely known/used map types. >>> >>>Wyclif >>> >>> >>> >>>On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[email protected]> wrote: >>> >>>I've just been looking through the 1.9 liquibase changesets that handle the >>>migration from the old concept_source/concept_map tables to the >>>concept_reference_* tables... >>>> >>>>I've got a question regarding changeset 20110301-1030f. This change >>>>inserts the core concept map types that are coming "pre-package" with >>>>OpenMRS... when is does so, it assigns a random UUID to each type. Don't >>>>we want to define uuids for these types beforehand, to confirm that the >>>>same concept map type has the same uuid across all implementations? I know >>>>this isn't how we've been doing things in the past, but it seems like >>>>something we really should be considering going forward. Don't we want to >>>>be able to identify that, say, concept map type "NARROWER-THAN" in one >>>>implementation is the same as the "NARROWER-THAN" type used in another >>>>implementation? This would ease Metadata sharing, for one thing, and >>>>would also ease the sharing of any other things like reports/scripts/etc >>>>that might need to be shared across implementations. >>>> >>>>My apologies if this has been debated before... I feel like I was part of >>>>discussion previously, but I can't entirely remember the reasoning for >>>>assigning random UUIDS (and obviously I wasn't convinced by that >>>>arguement... :) >>>> >>>>Take care, >>>>Mark >>>> >>>> >>>> >>>> >>>>________________________________________ >>>>From: [email protected] [[email protected]] On Behalf Of >>>>Daniel Kayiwa [[email protected]] >>>>Sent: Friday, March 30, 2012 7:01 AM >>>>To: [email protected] >>>>Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! >>>> >>>>Greetings to everyone!!! >>>> >>>>We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release >>>>Candidate) which you can get from the downloads >>>>page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. >>>> It has a number of bugs fixed in the core application and some bundled >>>>modules. See changes since the first release candidate in the release >>>>notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>. >>>> >>>>The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> >>>>version has a new option which configures OpenMRS with the MVP/CIEL >>>>dictionary, but without any patient data. If you are familiar with OpenMRS >>>>and want to start a new system, this is a good place to start. >>>>For developers, the standalone version now lets you specify vm arguments >>>>for adjusting memory, running in debug mode, profiling with YourKit, and >>>>more as per details from >>>>here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>. >>>> >>>>We have also improved the module to help you test this second release >>>>candidate using your existing data. Read more about it from: Release >>>>Testing Helper >>>>Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, >>>> and download it from >>>>here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>. >>>> >>>>Please help us get there sooner by giving feedback on this second release >>>>candidate. If you find any bugs, report them in our ticket tracking >>>>system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>. >>>> >>>> >>>>If no major bugs are found, this will become the official 1.9.0 release in >>>>a couple of days. >>>> >>>>Upcoming End Of Life Announcements: >>>>The 1.6.x line will reach EOL with the next major release (1.9.0) >>>> >>>>A big thank you to the 70 developers and all who have, in various ways, >>>>contributed towards this release!!! >>>> >>>>Daniel Kayiwa >>>>On Behalf of the OpenMRS community >>>> >>>>-- >>>>The greatest want of the world is the want of men—men who will not be >>>>bought or sold, men who in their inmost souls are true and honest, men who >>>>do not fear to call sin by its right name, men whose conscience is as true >>>>to duty as the needle to the pole, men who will stand for the right though >>>>the heavens fall. >>>>________________________________ >>>>Click here to >>>>unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> >>>> from OpenMRS Implementers' mailing list >>>>_________________________________________ >>>> >>>>To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to >>>>[email protected] with "SIGNOFF openmrs-implement-l" in the body >>>>(not the subject) of your e-mail. >>>> >>>>[mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >>>> >>> >> >>________________________________ >> Click here to unsubscribe from OpenMRS Implementers' mailing list >> >> >________________________________ > Click here to unsubscribe from OpenMRS Implementers' 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]
