Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Clinical notes (narrative reports) are a core part of any medical record system. A "note" table was introduced into OpenMRS core early in its development, anticipating the need; however, several years passed before it became a priority for implementations. The core
note table is not design properly nor has it been wired into the API. Furthermore, a project involving notifications used a
Note object, which has been left unused within core.
OpenMRS needs notes (narrative text) to be a component of encounters (just like orders and observations) to accommodate clinic notes, inpatient progress notes, admission notes, discharge summaries, etc. Notes should also accommodate binary notes (e.g., scanned notes).
A clinical note within OpenMRS may be thought of as:
"Any patient-centric narrative that is not a test or procedure result and has (or would ideally have*) a plain text view."
* "ideally" is used here to include scanned documents that may only be understood as images, but ideally would have perfect OCR performed to retrieve text from them.
Notes within OpenMRS are meant for narrative text (from plain text to CDAs to scanned documents), not images like x-rays or other multimedia that are observations (i.e., complex observations).
Noteobject within the notifications package.
notetable to meet requirements.
NoteServiceto manage clinical notes.
note.mime_type– used to describe the content type (distinguish plain text from PDF from a particular XML format).
note.text– contains content for text-based notes, may be empty or contain indexable text for complex (binary) notes
note.uri– describes location of note for complex/external notes (used by handler)
note_type.concept_id– provides an optional mapping to a concept
note_type.is_complex– true if the note type requires a handler to set/get/render content
note_type.complex_handler– reference to Java class the implements complex handler interface