OpenMRS Concept Collaborative (OCC)
The OpenMRS Concept Collaborative will allow concepts and eventually other metadata (ie, forms) to be shared between implementations. When an implementation creates a concept or form that definition gets sent up to the parent OCC server which will display it on its site. When another implementation comes along that wants to create a new form, they will be able to download concepts from the OCC (as though they were creating them themselves).
The OCC uses the concept mapping architecture. You will not get the same primary keys.
A lot of people came to OpenMRS two or three years ago and asked 'Why doesn't OpenMRS maintain a vocabulary of the concepts that would be most valuable to implementations? Really, OpenMRS should not be in that business (software not terminology). Sometimes process of building up vocabulary is flawed (Paul's opinion). Some anecdotal decisions made when creating a concept.
Example: Screening for children walking at a certain date. One could imagine a simple way is 'Does the child walk at a year of age (yes/no)?' Another could be 'What developmental milestones have been met at a year of age (walking, talking, etc)'.
The current standards developers make an arbitrary decision, which is sort of like throwing a dart.
The 'Wisdom of crowds' premise is that the crowd will always be wiser than the individual or organization. We would like to harnass that wisdom by finding a way to incentivize the contribution that leads to a standard. You would imagine that once a number of people have sent their concepts in, that the ones that have been used most often are the 'standard' since they are inherently successful. We want to find out the top one, and the highest rated one, which might come from the reputation of the person and other metrics.
If the OCC is keeping track of mappings between implementations, we know there are comparions that can be made there. You see every concept for every implementation.
One thing that is hard is, how do I do a query that shows all of the concepts that map to a particular topic. This is where references (ie, SNOMED) could play in.
The big idea is that we build something that is community-based not mandated.
Should we be looking at the reference maps in a more direct way?
It does look at the reference maps. There is no OCC id. There are as many occ ids are mappings. The mappings are what define the whole collection of the concepts in the OCC.
When you pull a concept you're pulling all mappings for concepts in the OCC. MVP might have a problem with the volume of mappings that this would create, and it might help to just pull the occ_id.
When you bring up a concept, are you bringing up all of the concept names for that concept?
Andy likes the idea of seeing all of the data as though you had entered it, and being able to hit 'OK'.
Does changing which flag is the preferred name change the concept?
Within an implementation, no. So you should be able to change the preferred name as you do the import. Does this break the model of leaving the concept in the OCC untouched? Removing an answer breaks the mapping.
When you bring the concept over, you should bring over all of the answers, but just limit it in the form.
What if you download a concept and then edit it (ie, add a name, add answers)?
This is ok. The concept collaborative might have to decide whether that gets added as the second concept or as a new concept.
The OCC module should let you specify that you were going to break things.
When someone makes a change, it should go up to the OCC. Should people who use the concept be notified? This is a good idea, but would be a burden to put on people.
If Andy is going in and adding a whole bunch of mappings to SNOMED, people should notified.
When can we use it?
A GSOC student is working on this, date unclear.
Malawi and Rwanda could really use it ASAP.
At PIH, we have the same dictionary at multiple sites. If there was someone else taking on a bit of work, it would be great.
What are we starting with in terms of conntent?
MVP will not be in yet