Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Why care about managing concepts?

...

  • CIEL dictionary is the "master" and your implementation subscribes to modifications
  • Multiple servers are connected via sync module.  Concepts are only updated on the sync parent and changes are replayed on the child servers.   This is used at Partners In Health Rwanda (Inshuti Mu Buzima).
  • A "golden" metadata server has curated concepts for various implementation.  Concepts have been managed over time, additional concepts are added from CIEL and locally.  All concepts are managed here and subsets are packaged here using mds or groovy and exported to individual implementation. 

Image RemovedImage Added

Partners In Health implementations (Haiti, Liberia, and Lesotho) use centralized concept management and the "golden" server.   The "golden" concept server is maintained in the cloud and used for PIH concept management with a curated set of concepts.  These steps outline the process for creating mds packages for implementations along with the "PIH Concept Management workflow" figure:

...

  • Use one central OpenMRS server for "golden" metadata (concepts, etc)
  • When possible, use the CIEL dictionary for new concepts instead of recreating a new one.
  • Use the Open Concept Lab (OCL) or Maternal Concept Lab (MCL) for viewing the CIEL, PIH, AMPATH dictionaries.  
  • Use Metadata sharing (MDS) for getting existing concepts.  
    • Use MCL to generate an export package with concepts for import into your local "golden" server  OR
    • Use the CIEL dropbox to get the latest mysqldump of the CIEL concept* tables.  Install this on a local OpenMRS server along with the MDS module.  Export packages from this server for your local "golden" server.
  • Create a concept source for this server (ie.  Rwanda, PIH) where the concept_ids will be used for mappings (ie.  PIH: 12)
  • Add unique mappings terms for use with forms and reports (ie. "PIH: 12", "PIH: Anemia", "CIEL:123456", "Rwanda: 388").  The names must be unique. See https://wikiopenmrs.openmrsatlassian.orgnet/wiki/display/docs/Concept+Terms+and+Mappings
  • These mappings should have a concept reference map type of "SAME-AS".
  • Sentence case (ie. "Easter egg hunt") is preferred for concept names. 
  • Each concepts on a Metadata Server should have one or 2 maps (ie.  "RWANDA: 12" and/or "RWANDA: Anemia")
  • Add terminology mappings where useful (ie. SNOMED, ICD10, RxNORM, ICPC2, LOINC). These are helpful for standardizing diagnoses, procedures, and billing.  These are already populated in CIEL and PIH.
  • Locale - Concepts should be in appropriate language:  English, French, Spanish, Haitian Kreyol, Kinyarwanda, etc.
  • Validate the following with the validation module:
    • concepts
    • concept names
    • concept description
  • Confirm that all user fields in concept* tables have existing users.  A variety of fields (creator, voided_by, changed_by, and retired_by) are on the concept* tables and correspond to the user_id in the users table.  If concept* tables have been directly updated via mysql (mysqldump and source), then users might not exist for concept* tables.
  • Cleanup and possibly delete unused concepts
  • Delete or retire duplicate concepts.  If a concept is retired, it can still be used in the system for past or future obs; however, it will not appear by default in concept dictionary searches or htmlform dropdowns.  Retiring a concept doesn't cause any problems.  Deleting a concept when it's used is a problem.  If a form uses the concept, it will break the form.  If an obs used the concept, that will also produce an error.
  • Check for appropriate classes and datatypes 
    • diagnosis, symptom, finding, program, workflow, state or misc should have a datatype of N/A
    • LabSet, MedSet, and ConvSet should have set members
    • questions should not have a datatype of N/A

...