Concept Naming Discussed on Conf Call Oct 29th

[Ben Wolfe]

Some javascript/style in this post has been disabled (why?)

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

[Michael Seaton]

Some javascript/style in this post has been disabled (why?)

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Darius Jazayeri-3]

In some cases (e.g ours) I think that having concept names in other languages showing up like synonyms do would be good. But I imagine that wouldn't work at all for the MVP use case where they have lots of random languages.

Maybe we want an additional method that does a broader name search? (This may already exist) that we use at certain points in the UI, per a global property which specifies whether to limit to the current locale only.

-Darius

On Wed, Nov 4, 2009 at 6:17 AM, Michael Seaton <[hidden email]> wrote:

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Johnathan L. Brown]

Some javascript/style in this post has been disabled (why?)

 Yesterday, while attempting to squash some startup bugs in the NCD module, we encountered a case where a call to updateConceptSetDerived was failing because of a Hibernate error (see attached log entry).  Investigating this, it appears that while ConceptSetDerived extends from BaseOpenmrsObject, it does not have a uuid field in its corresponding DB table.  Was this done purposefully or do I need to file an issue?

 

-- John Brown

---

[hidden email] from OpenMRS Developers' mailing list
ERROR - LoggingAdvice.invoke(111) |2009-11-03 15:30:17,394| An error occurred while executing this method. Error message: could not retrieve snapshot:
 [org.openmrs.ConceptSetDerived#component[concept,conceptSet]{concept=org.openmrs.Concept#6102, conceptSet=org.openmrs.Concept#6152}]
org.hibernate.exception.SQLGrammarException: could not retrieve snapshot: [org.openmrs.ConceptSetDerived#component[concept,conceptSet]{concept=org.ope
nmrs.Concept#6102, conceptSet=org.openmrs.Concept#6152}]
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
        at org.hibernate.persister.entity.AbstractEntityPersister.getDatabaseSnapshot(AbstractEntityPersister.java:1048)
        at org.hibernate.engine.StatefulPersistenceContext.getDatabaseSnapshot(StatefulPersistenceContext.java:246)
        at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:189)
        at org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:512)
        at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:80)
        at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
        at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:507)
        at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:499)
        at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:495)
        at org.openmrs.api.db.hibernate.HibernateConceptDAO.updateConceptSetDerived(HibernateConceptDAO.java:914)
        at org.openmrs.api.impl.ConceptServiceImpl.updateConceptSetDerived(ConceptServiceImpl.java:700)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        at $Proxy69.updateConceptSetDerived(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.openmrs.aop.LoggingAdvice.invoke(LoggingAdvice.java:107)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        at $Proxy70.updateConceptSetDerived(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        at $Proxy70.updateConceptSetDerived(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
        at $Proxy137.updateConceptSetDerived(Unknown Source)
        at org.openmrs.module.ncd.utilities.NCDUtilities.manageConcepts(NCDUtilities.java:984)
        at org.openmrs.module.ncd.utilities.NCDUtilities.start(NCDUtilities.java:574)
        at org.openmrs.module.ncd.NCDActivator.initialize(NCDActivator.java:87)
        at org.openmrs.module.ncd.NCDActivator.run(NCDActivator.java:75)
        at java.lang.Thread.run(Thread.java:619)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'conceptset_.uuid' in 'field list'
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
        at com.mysql.jdbc.Util.getInstance(Util.java:381)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1912)
        at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76)
        at org.hibernate.persister.entity.AbstractEntityPersister.getDatabaseSnapshot(AbstractEntityPersister.java:1021)
        ... 61 more

[Andrew Kanter]

Some javascript/style in this post has been disabled (why?)

We are doing a lot of French translation of our properties files and the concepts... 

Also, there is a user property about which locales are understandable by the user... and this can be both en_uk and fr... then searches will return both...

-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: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

---

From: Michael Seaton <[hidden email]>
To: [hidden email]
Sent: Wed, November 4, 2009 9:17:18 AM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Darius Jazayeri-3]

Mike,

Would it work to add a global property that gets used whenever the user does *not* have a proficient-locales userproperty set?

-Darius

On Wed, Nov 4, 2009 at 10:52 AM, Andrew Kanter <[hidden email]> wrote:

We are doing a lot of French translation of our properties files and the concepts... 

Also, there is a user property about which locales are understandable by the user... and this can be both en_uk and fr... then searches will return both...

-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: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

---

From: Michael Seaton <[hidden email]>

To: openmrs-devel-l@LISTSERV..IUPUI.EDU

Sent: Wed, November 4, 2009 9:17:18 AM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Darius Jazayeri-3]

I don't know if this was done intentionally, but my first thought is that ConceptSetDerived should follow the same pattern as ConceptWord, which does not implement OpenmrsAnything.

Maros, Ben, do you know how this would affect sync?

-Darius

On Wed, Nov 4, 2009 at 8:57 AM, Johnathan L. Brown <[hidden email]> wrote:

 Yesterday, while attempting to squash some startup bugs in the NCD module, we encountered a case where a call to updateConceptSetDerived was failing because of a Hibernate error (see attached log entry).  Investigating this, it appears that while ConceptSetDerived extends from BaseOpenmrsObject, it does not have a uuid field in its corresponding DB table.  Was this done purposefully or do I need to file an issue?

 

-- John Brown

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Michael Seaton]

Some javascript/style in this post has been disabled (why?)

I think I really just want the system to behave in expected and transparent ways.  If I have 20 concepts in my system, then switch languages, and can subsequently only find 5 of them in the dictionary, that seems like a problem.

 

I don't think all use-cases will have the same requirements for this.  In some places – like parsing Logic tokens and finding the relevent concept – we need to have a certain strategy for finding Concept by name.  In other places, like in a Dictionary management interface, we need another strategy.  I see the dictionary as the kind of tool that should be as greedy as possible – it would be far better to return more results than less results when searching for a concept to view in the dictionary.

 

I think if this is not acceptable to some implementations, then perhaps we provide a means, directly on the dictionary page, that allows you to limit results to only certain locales.  But my point from before was that I think the default should be to return all, and allow for configuration to get less – not the other way around.

 

Mike

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, November 04, 2009 1:55 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Mike,

Would it work to add a global property that gets used whenever the user does *not* have a proficient-locales userproperty set?

-Darius

On Wed, Nov 4, 2009 at 10:52 AM, Andrew Kanter <[hidden email]> wrote:

We are doing a lot of French translation of our properties files and the concepts... 

Also, there is a user property about which locales are understandable by the user... and this can be both en_uk and fr... then searches will return both...

 

-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: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

 

 

---

From: Michael Seaton <[hidden email]>

To: openmrs-devel-l@LISTSERV..IUPUI.EDU

Sent: Wed, November 4, 2009 9:17:18 AM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

 

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Burke Mamlin]

Some javascript/style in this post has been disabled (why?)

There are two use cases here...

As a concept administrator (i.e., via the concept management interface), I might appreciate the ability to see all of my concepts, across all locales, as I work.  Whether I get that by default or turn it on is probably something we shouldn't irreversibly commit to -- i.e., set a default and when users tell us we got it wrong, set the default to the other value.

As a user of the system, the user property setting of "here's my list of languages" seems best.  I definitely wouldn't want to see results in languages I don't understand.  And it could be really confusing if I saw non-sensical hits to searches in my own language because there were index entry matches to my search in other locales.

-Burke

On Nov 4, 2009, at 2:26 PM, Michael Seaton wrote:

I think I really just want the system to behave in expected and transparent ways.  If I have 20 concepts in my system, then switch languages, and can subsequently only find 5 of them in the dictionary, that seems like a problem.

 

I don't think all use-cases will have the same requirements for this.  In some places – like parsing Logic tokens and finding the relevent concept – we need to have a certain strategy for finding Concept by name.  In other places, like in a Dictionary management interface, we need another strategy.  I see the dictionary as the kind of tool that should be as greedy as possible – it would be far better to return more results than less results when searching for a concept to view in the dictionary.

 

I think if this is not acceptable to some implementations, then perhaps we provide a means, directly on the dictionary page, that allows you to limit results to only certain locales.  But my point from before was that I think the default should be to return all, and allow for configuration to get less – not the other way around.

 

Mike

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, November 04, 2009 1:55 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Mike,

Would it work to add a global property that gets used whenever the user does *not* have a proficient-locales userproperty set?

-Darius

On Wed, Nov 4, 2009 at 10:52 AM, Andrew Kanter <[hidden email]> wrote:

We are doing a lot of French translation of our properties files and the concepts... 

Also, there is a user property about which locales are understandable by the user... and this can be both en_uk and fr... then searches will return both...

 

-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: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

 

 

---

From: Michael Seaton <[hidden email]>

To: openmrs-devel-l@LISTSERV..IUPUI.EDU

Sent: Wed, November 4, 2009 9:17:18 AM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

 

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Burke Mamlin]

Some javascript/style in this post has been disabled (why?)

Agreed.  Concept set derived is -- oddly enough, derived information (a de-normalization of set-member relationships for performance purposes) and can be re-generated at any point programmatically.  UUID doesn't really make sense for this.  It's like checking build files into a repository.  Meh.

-Burke

On Nov 4, 2009, at 2:02 PM, Darius Jazayeri wrote:

I don't know if this was done intentionally, but my first thought is that ConceptSetDerived should follow the same pattern as ConceptWord, which does not implement OpenmrsAnything.

Maros, Ben, do you know how this would affect sync?

-Darius

On Wed, Nov 4, 2009 at 8:57 AM, Johnathan L. Brown <[hidden email]> wrote:

 Yesterday, while attempting to squash some startup bugs in the NCD module, we encountered a case where a call to updateConceptSetDerived was failing because of a Hibernate error (see attached log entry).  Investigating this, it appears that while ConceptSetDerived extends from BaseOpenmrsObject, it does not have a uuid field in its corresponding DB table.  Was this done purposefully or do I need to file an issue?

 

-- John Brown

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Andrew Kanter]

Some javascript/style in this post has been disabled (why?)

I agree with Burke, and I would not want the default to be returning all concept names regardless of locale. There can be a default user property to set new users to all locales, but if this was changed, then only the locales I can understand should be returned....

-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: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

---

From: Burke Mamlin <[hidden email]>
To: [hidden email]
Sent: Wed, November 4, 2009 4:30:30 PM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

There are two use cases here...

As a concept administrator (i.e., via the concept management interface), I might appreciate the ability to see all of my concepts, across all locales, as I work.  Whether I get that by default or turn it on is probably something we shouldn't irreversibly commit to -- i.e., set a default and when users tell us we got it wrong, set the default to the other value.

As a user of the system, the user property setting of "here's my list of languages" seems best.  I definitely wouldn't want to see results in languages I don't understand.  And it could be really confusing if I saw non-sensical hits to searches in my own language because there were index entry matches to my search in other locales.

-Burke

On Nov 4, 2009, at 2:26 PM, Michael Seaton wrote:

I think I really just want the system to behave in expected and transparent ways.  If I have 20 concepts in my system, then switch languages, and can subsequently only find 5 of them in the dictionary, that seems like a problem.

 

I don't think all use-cases will have the same requirements for this.  In some places – like parsing Logic tokens and finding the relevent concept – we need to have a certain strategy for finding Concept by name.  In other places, like in a Dictionary management interface, we need another strategy.  I see the dictionary as the kind of tool that should be as greedy as possible – it would be far better to return more results than less results when searching for a concept to view in the dictionary.

 

I think if this is not acceptable to some implementations, then perhaps we provide a means, directly on the dictionary page, that allows you to limit results to only certain locales.  But my point from before was that I think the default should be to return all, and allow for configuration to get less – not the other way around.

 

Mike

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Wednesday, November 04, 2009 1:55 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Mike,

Would it work to add a global property that gets used whenever the user does *not* have a proficient-locales userproperty set?

-Darius

On Wed, Nov 4, 2009 at 10:52 AM, Andrew Kanter <[hidden email]> wrote:

We are doing a lot of French translation of our properties files and the concepts... 

Also, there is a user property about which locales are understandable by the user... and this can be both en_uk and fr.... then searches will return both...

 

-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: [hidden email]
Mobile : [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter

 

 

---

From: Michael Seaton <[hidden email]>

To: openmrs-devel-l@LISTSERV..IUPUI.EDU

Sent: Wed, November 4, 2009 9:17:18 AM
Subject: Re: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

Hi Ben,

 

As background, our implementation in Haiti is used mainly in French by the user base.  However, the primary language of our concept dictionary (and all development) is in English.  I tend to set my language during development to French to make sure what I see is consistent with what the users will see.

 

Now, our concept dictionary is only partially translated to French – let's say 20%.  As currently designed, the default behavior of the concept dictionary search page will only return results that have names in the user's locale.  This means that the concept dictionary will _appear_ to be only 20% of it's actual size if you happen to have your default Locale set to French.  Also, many users speak both languages, but if they happen to be viewing the EMR in French, and look for "weight" in the concept dictionary, they will be unable to find it.

 

This is not the behavior that I would expect.  I understand your point that each user can set their preferred locales for searching, but I don't want to put the onus on the users for this – it should be more of a system preference that can be applied to all users.  I also think that the default behavior should be to return any concepts that match the search string – not only those in the passed locale – which users can opt out of by specifying how they want to _limit_ their results.  This seems less likely to cause confusion for the large majority of users.

 

I'm interested in other's thoughts on this…

 

Thanks,

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ben Wolfe
Sent: Wednesday, November 04, 2009 1:58 AM
To: [hidden email]
Subject: [OPENMRS-DEV] Concept Naming Discussed on Conf Call Oct 29th

 

This is in the minutes of the conference call from last week:

Concept Naming
   * Allow search for Concept to be configurable in term of on what locale the Concept will be returned. The user might wants to search on French locale or English locale.

Can someone expound on that?  Is this specifically for the logic service or just for concept searching in general?  If the latter, there is a user preference that each user can set for preferred locales to search in.  The user can set it to en,fr to have all searches return hits on both english and french regardless of their current locale.

Ben

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

 

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Ben Wolfe]

Some javascript/style in this post has been disabled (why?)

Only things that implement OpenmrsObject (aka, hava UUID) will be sync-able. Things like concept_word, concept_set_derived, should be recreated on the new system after things are sent over the wire.

This seems like a bug and needs a ticket. 

Are we even using concept-set-derived anywhere?  I remember the reasons for making it (flattening the concept sets) but I don't remember implementing anything using it (Which might mean that we don't do anything with multi-level sets right now)

Ben

Burke Mamlin wrote:

Agreed.  Concept set derived is -- oddly enough, derived information (a de-normalization of set-member relationships for performance purposes) and can be re-generated at any point programmatically.  UUID doesn't really make sense for this.  It's like checking build files into a repository.  Meh.

-Burke

On Nov 4, 2009, at 2:02 PM, Darius Jazayeri wrote:

I don't know if this was done intentionally, but my first thought is that ConceptSetDerived should follow the same pattern as ConceptWord, which does not implement OpenmrsAnything.

Maros, Ben, do you know how this would affect sync?

-Darius

On Wed, Nov 4, 2009 at 8:57 AM, Johnathan L. Brown <[hidden email]> wrote:

 Yesterday, while attempting to squash some startup bugs in the NCD module, we encountered a case where a call to updateConceptSetDerived was failing because of a Hibernate error (see attached log entry).  Investigating this, it appears that while ConceptSetDerived extends from BaseOpenmrsObject, it does not have a uuid field in its corresponding DB table.  Was this done purposefully or do I need to file an issue?

 

-- John Brown

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list