Skip to end of metadata
Go to start of metadata
Objectives:
- Learn about the data model
- ... how concepts are related to other things
- ... how to extend the data model
- ... more about drug orders and encounters
- "As an implementer, sometimes I don't understand why the programmers did things the way they did. I'd like to learn."
- ... how to deal with mental health data (lots of free text)
- ... so I can write better SQL queries
- Push towards better documentation
- ... how much am I (i.e. Baobab) abusing it now?
- ... and learn what changes are coming
- ... more about problem lists and allergies
- ... how to manipulate the data
Notes
- See an image of the data model on the OpenMRS wiki, under Developer Documentation
- Broken down into domains (by color on the image)
- Encounters
- started off representing a visit, filled out from a form
- we are growing beyond this
- Encounters have types (e.g. initial visit, return visit, ...)
- ... link to a form (that was used to fill out the encounter)
- ... take place at a location (i.e. a physical, geographic location)
- ... have a timestamp
- Upcoming change in 1.9: adding 'Visit' to the data model, which can group multiple encounters
- Visits will have a start date and an end date
- Upcoming change (after 1.9): adding 'Episodes of Care' which can group multiple encounters and visits
- lots of overlap with program enrollments, workflows, and states
- "Tags": this term to refer to "folksonomy" i.e. user-created tags that are not part of the core system
- EAV (Entity-Attribute-Value)
- the typical approach is for each question to be a column in the encounter table. As you start asking more questions, you need to add many many more columns. (This looks like a spreadsheet.)
- EAV means you "turn this sideways" so instead of having one encounter with 50 columns, you would store one encounter and 50 observations.
- Concepts represent the "questions" that would have been the many columns in a non-EAV encounter table
- Observations
- The core data in OpenMRS (as opposed to metadata)
- concept_id -> the 'question' for this observation
- value_xyz -> one of the value_xyz columns is filled in as the 'answer' for this observation
- accession number -> used to link an observation back to a lab order that it originated from
- value_group_id -> links multiple values for the same question
- example 1: Chest Xray shows pneumonia AND infiltrate; as opposed to two chest xrays, one showing pneumonia, and another showing infiltrate
- example 2: "Left" + "Upper Lobe" + "Pneumonia"
- obs_group_id -> links multiple related observations that are all part of the same higher-level data point (e.g. Allergy cause, Allergy reaction, Allergy date)
- Drugs
- Why not just make these concepts? So we can representing both "Isoniazid" (a concept representing the generic drug) and "Isoniazid 300mg tablets" (an entry in the drug table)
- UUIDs
- Universally Unique IDs
- You can create one of these anywhere, and you "always" (99.999...%) get a unique one
- Concepts
- Because of concepts we do not need to change the data model when we start asking new questions. We just add a row to the concept table
- ... has a datatype
- for questions, this specifies the datatype of the answer
- datatype=N/A means this concept is only an answer, not a question
- ... can be put in sets
- ... can be complex (i.e. datatype is not just a primitive String or Number, but rather something like a video or an xml document)
- complex concepts have "handlers" which know how to store and display things (e.g. a video of an echo loop is stored in some database)
- image and text handlers are built into the core system
- multi-valued datatypes can be represented as an obs group (commonly done for allergies) or you can use complex concepts to store this as xml
- 'derived concepts' -> represents a calculation which lets you derive a value from other data (but you don't store data for a derived concept directy)
- Example: "Pregnant?" -> diagnosis of pregnancy, or positive urine pregnancy test, or ...
- Example: allows a report that has a "Pregnant?" question to be used against either obs for a boolean "is patient pregnant" or a datetime "expected delivery date"
- Orders
- Currently it's very simplistic in the data model
- PIH is using the drug_order table now
- Upcoming changes (not yet scheduled): much more sophisticated implementation of drug orders, lab orders, etc.
- Regenstrief if building this on a data model derived from OpenMRS. We will copy a lot of what they do.
- How do things get on the road map (e.g. why is order entry being built, but not billing)
- "The community can drive whatever they want"
- "If there's a portion of the data model that needs work from your perspective, then propose it"
- Actually order entry is being worked on by Regenstrief for their own needs, and we're trying to leverage that work as much as possible
- Upcoming changes to the data model that we know about:
- In 1.7
- Problem lists
- Allergies
- Location Hierarchy
- Changes to Concept Name Tags
- Boolean changes from 0/1 -> coded
- In 1.9
- Multiple providers per encounter
- Visits
- Addition attributes for Concept Mapping
- Program Locations (when Jembi code is merged)
- Orders (will change significantly if Regenstrief does a good job of implementing this)
- How do you add a new address layout
- You have to write xml, and put it openmrs-servlet.xml
- We can probably commit your proposal to OpenMRS core
- The columns in person_address can be renamed in the UI
- Problem Lists
- Can we support "continuing problems" (i.e. they have Fever, but this it's continued from before)
- Allergies
- Do these connect to the drug_ingredient table? Not yet. You can store allergies, but they don't do anything yet.
- Can we support marking people as test patients? Would be nice--not quite sure how to do it?