While I agree that from an OpenMRS general use perspective, the designs seem to be sound.
What I’m left wondering after thinking around this for a while is whether CDA document should really be stored as clinical notes. From reading the descriptions of clinical notes on the design doc page it seems like notes are really shorter narrative text about a patient where as CDA documents are just that; documents. I’m starting to think that a document is quite different from a note. Document may even contain notes and observations. Perhaps a document should be a separate data structure within OpenMRS (perhaps supplied by a module).
What do others think? Is storing of CDA document as notes in OpenMRS appropriate?
···
On Tue, Nov 12, 2013 at 10:49 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:
Aloha,
Now that we have a good idea of what we want, shall we discuss how we want to complete this ?
- I’m assuming this work will be fully incorporated into the core.
- Our complex note will reflect existing complex obs design (complex note handlers etc.).
- As per Burke’s recommendation, an encounter should have zero to many notes.
Do we have enough info to begin work on this ?
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Mon, Nov 11, 2013 at 1:06 PM, Burke Mamlin burke@openmrs.org wrote:
-Burke
Encounters as clinical transactions can have any combination of notes, observations, and/or orders, which means 0-to-n of each. So, an encounter that comprises just one narrative text (note) would be fine/expected (e.g., a nutritionist recording a consult note for the patient in the hospital, a specialist completing a consult note for a referral, etc.)
–
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@openmrs.org.
Suranga
–
Best Regards,
On Mon, Nov 11, 2013 at 11:25 AM, Jeremy Keiper jeremy@openmrs.org wrote:
Burke, at the minimum, would you say that encounter could house zero observations but one large narrative text (note)? I think so, but want to be sure that’s acceptable. In fact, I don’t think any observations are currently required for encounters.
–
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support
On Mon, Nov 11, 2013 at 8:49 AM, Burke Mamlin burke@openmrs.org wrote:
For OpenMRS:
- An encounter represents a clinical transaction – a provider sitting down and entering any combination of notes, orders, observations for a patient.
- A visit represents a collection of one or more encounters into a real-world patient visit (e.g., a clinic visit or a hospitalization).
We see a note as part of an encounter. See Notes within OpenMRS (Design Page) for some initial design ideas for notes within OpenMRS. I didn’t have notes from our conversation at OMRS13, so I may have dis-remembered some points. 
-Burke
–
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
On Mon, Nov 11, 2013 at 6:00 AM, Ryan Crichton ryan@jembi.org wrote:
Hi everyone,
While we have been thinking about creating a Shared Health Record out of OpenMRS we have begun thinking about how notes should be implemented in OpenMRS. We have had a bit of discussion around this topic and you can read below for some more details of that discussion.
Basically, there are 2 main use cases for storing notes:
- Storing narrative text in a patient medical record such as discharge summaries, clinical notes etc.
- The second is to store other unstructured information about a patient that could be classified as a note. Such as a scanned document (image), CDA document (XML), etc.
We have so far been thinking of implementing notes functionality with the addition of “complex notes” similar to the complex obs functionality to store unstructured data. We have faced a few difficulties in thinking about notes. I’ve listed some here but refer to the below discussion for more details.
- At what point should a note be attached in the OpenMRS data model? - ie, does it belong to an encounter? Does it belong to a vists? How should it be linked to a patients record?
- Does it make sense to store unstructured content such as images and CDA content in this sort of structure?
To those who were apart of the original discussion, perhaps you could do a better job of expanding upon these issues and your thoughts on notes?
What are other people thoughts on storing notes in OpenMRS.
Cheers,
Ryan
–
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
On Mon, Nov 11, 2013 at 12:42 PM, Ryan Crichton ryan@jembi.org wrote:
Hi All,
There has been some very valuable discussion here. I think it has come to a stage where we should be discussing this more closely with the OpenMRS community. I’m going to post our discussion there in a few mins time so we can continue discussing this with the wider community. I’d urge you to join the OpenMRS developers mailing lists to be able to continue to contribute to this discussion without your email bouncing. You can do that here: https://wiki.openmrs.org/display/RES/Mailing+Lists if you are not already part of that mailing list list.
Cheers,
Ryan
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
On Sun, Nov 10, 2013 at 6:30 PM, David Aronow uncle0wacko@gmail.com wrote:
Hello,
This is a good discussion, and one where my experience and views are bit orthogonal to the comments made. This is how I see notes in general terms.
I define a note as a unit of unstructured text. I do not include data types other than text as being notes, they are other wonderful thing. Notes comes in a wide range of character lengths and how they are recorded/captured, stored, processed and retrieved is highly dependent on their size and the IS design.
In healthcare, notes come from several sources including transcribed dictation (ex: discharge summary or path report), provider typed short answers (ex: sig in an eprescription or chief complaint or description of an observation), fabrication from template and picklist data entry (ex: the sig or PE findings), and clerical entry of written provider notes. In my work we generally refer to large pieces of text, typically dictations, as ‘notes’ to help distinguish from short pieces of unstructured text, that we generally call ‘text’.
All notes and text are linked to other data by identifiers and datetime stamps. Some notes are values of attributes, some are (in essence) the entities themselves, and some are entity-centric, some encounter-centric, and others are patient-centric, because for me, notes means chunks of text.
Handling of notes is size and IS design dependent - short text (< 128 char, or < 256 char, whatever) is like coded or numeric data, just plopped into the correct db cell, while big text is specially stored, sometimes in tables by themselves, in unique structures such as CLOBs or the like. Either way, the identifiers of the entity or encounter or patient (or other objects) and their datetime stamps allow access, processing and retrieval of the text data. That processing might involve sql ‘like’ expressions or regular expression, or serious NLP, or just retrieval as the unstructured text itself.
On the encounter level, when speaking of specific notes, we try to be explicit in the name, such as Encounter Note, or Radiology Note. These are examples of encounters {{little ‘e’ encounter = is an interaction, event or activity involving a healthcare organization
or its agent, and a patient or their health record that generates data to be
stored in a database. Each
encounter occurs at a specific place and time, with a specific part or agent of
the healthcare organization, and for a specific reason.}} where the valuable data is embedded in a large amount of unstructured text, whose structure, as well as encounter attributes other than the note, depend on the Note type.
On the entity level, we often add a short note or comment attribute in the design of an entity - always optional and rarely populated, but available for anything the data creation or entry person wants to say to annotate the otherwise highly structured entity.
Thanks,
David
On Tuesday, November 5, 2013 5:12:57 PM UTC-5, Suranga Kasthurirathne wrote:
Hi,
As discussed on the SHR call, I though i’d get the conversation on OpenMRS notes started, and see where we can take it from here.
So my two cents are,
As Ryan suggested, there are two types of notes,
- Simple Notes - Store text notes that links to the patient record in the OpenMRS data model
- Complex Notes - documents (PDFs, scanned docs) could be stored as a complex note rather than as an observation (a PDF-MIME type)
As per my previous discussion on the OpenMRS mailing list, an OpenMRS Note is tied to an encounter. A Note is not intended to store an HL7 NTE segment - we have obs.comment for that.
Does this correspond with what you had in mind ?
And also, is it our intention to store complex notes using the same mechanism used to store unstructured complex obs ? if so, we may have some trouble getting our changes into the OpenMRS core…
–
Best Regards,
Suranga
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org