Agree that the UUIDs for the concept mapping types should be standardized. -------------------- 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 11:56 AM >Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! > > >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 > > _________________________________________ 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]
