Tag Archives: patients

Mobile EMR, Part III

This is continuation of previous posts Mobile EMR, Part I and Mobile EMR, Part II

We’ve met with Mr.Tufte and demo’ed this EMR concept. He played with it for a while and suggested list of improvements, from his point of view.

‘All Data’ charts

Edward Tufte insists that sparklines work better than dots. It is OK that sparklines will be of different sizes. It is natural that each measurement has its own normal range. Initially we tried to switch the charts to the lines, but then we rolled back. Seems that we should make this feature configurable, and use sparklines by default. But if some MD wants dots, she can manually switch it in app settings.

Partially our EMR concept has been switched to sparklines – for display of Vital Signs. Below is a snapshot:

Vital Signs

One more thing related to the Vital Signs, we did great by separating on the widget on top, and grouping them together. It adds much value, because they are related to each other. It is important to see what happened to them at each moment. Our approach, based on user testing, appeared to be a winning one!

Space

Current use of the space could be improved even more. First reason is that biggest value of that research was keeping ‘All Information’ on single screen. Human eye recognizes perfectly which type of information is needed. All space is tessellated into multiple locuses of attention. Then human eye locks the desired locus and then focuses within that locus. Second reason is iPad resolution. We can squeeze more from retina resolution without degradation of usability (like size of labels and numbers). It is possible to scale to the newspaper typography on iPad, hence fit more information into the screen estate.

Genogram

This confirms the modern trend to genetics and genetic engineering. Genogram is a special type of diagram, visualizing patient’s family relationships and medical history. In medicine, medical genograms provide a quick and useful context in which to evaluate an individual’s health risks. Many new treatments are tailored by genotype of the patients. E.g. Steve Jobs’s cancer was periodically sequenced and brand new proteins where applied, to prevent disease spread. All cells are built from the proteins, reading other proteins as instructions. This is true for the cancer cells. Thus if they read instructions from fake proteins, then they can not build themselves properly. We like this idea immediately, because its value is instant and big, its importance is as high as allergy. Below is sample genogram, using special markers for genetically influenced diseases.

Sample Genogram

There are other cosmetic observations which will be improved shortly. We continue usability testing with medical doctors. More to come. It could be Mobile EMR on iPhone. Stay tuned.

UPDATE: Continued on Mobile EMR, Part IV.

Advertisements
Tagged , , , , , , , , , , , , , , , , , , , , , , ,

Mobile EMR, Part I

At SoftServe we do some researches, I’m in charge of them. This time I’d like to describe one of our researches. It is called Mobile EMR. EMR stands for Electronic Medical Record. This research is intended to find what will hospitals, agencies, practitioners will use tomorrow. Mobile EMR aka mEMR is a hot intersection of booming Mobility, Big Data, Touch Interface, Cloud trends. Today we research it, tomorrow they will use it. SoftServe works with multiple ISVs which build solutions for hospitals, agencies, hence we have influence on evolution of medical solutions.

Part I will be about how we started and what we get up to date, with conclusion for next steps, which will be described later in Part II.

Beginning

It has started some time ago during UX research for medical data visualization. Then famous government initiative has been launched to transfer healthcare industry to EMR. Mixing that soup we figured out that it is possible to propose really new concept for the EMR for physicians. We found research by Seth M. Powsner and Edward R. Tufte, “Graphical Summary of Patient Status” published in far 1994. They work at Yale University. One of them is MD, another is PhD in statistics and guru of presenting data. It was oriented onto All Data paradigm that Mr.Tufte loves. I love it too. I love the idea of having All Data on single pager. As soon as Apple released iPad we understood that it is perfect one pager to put the EMR onto. In 2011 I attended E.Tufte one-day course, and found a moment to speak about healthcare data visualization. Mr.Tufte confirmed there was nothing done in the industry still! He pointed to the printed copy of mentioned research and proposed to implement it. After that we had one more face-to-face contact with Mr.Tufte on that research, we god some additional clarifications and recommendations (mainly related to low level details such as sparklines). Below is a snapshot of the proposed visualization by Powsner/Tufte:

Seth M. Powsner and Edward R. Tufte, “Graphical Summary of Patient Status”, The Lancet 344 (August 6, 1994), 386-389.

All Data has to be handled by special kind of chart, that shows three periods of data. Rightmost biggest part shows week or 10 days, middle narrow part shows previous year, and leftmost part shows all possible data prior to last year. Having such data presentation we are capable to display all anomalies and trends for the whole period that has data logs.

'All Data' chart

“All Data” chart. Seth M. Powsner and Edward R. Tufte, “Graphical Summary of Patient Status”, The Lancet 344 (August 6, 1994), 386-389.

 

We were aware there was web implementation. It was 100 percent copy of the research (charts part of it). Below is a screenshot from the browser:

Web EMR by KavaChart

First Version

We took our Mobile IP and SDK (such as authentication, cache, cryptography etc reusable blocks; Big Image(tm), SaaS SDK) and built first app for iPad. Obviously we lacked deep domain knowledge, hence first version is not perfect. But idea was to do technology feasibility rather than ready-made solution (because we work with healthcare ISVs who keep deep domain expertise). There were few cycles for visualization and layout of the charts and other UI elements. As a result, we got this “first version”:

mEMR Default Screen

All remarks and proposed improvements will be listed herein a bit later! Right now I’d like to show few more screenshots what we have got. Physicians identify the patients by MRN or by name, if the patient stays at the hospital for some time. Hence, we introduced two-way patient identification: via My Patients list, and via wristband/MRN scan. Below are screenshots: My Patients and Wristband/MRN Scan. First one is My Patients:

mEMR My Patients

This one is Wristband/MRN Scan:

mEMR Wristband Scan

User Testing and Recommendations

“First Version” has been shown to MD from New York large hospital. Impressions were mixed :-O
In general – idea of such mEMR is good. But using it with its current data is not so valuable. I’ve got recommendation for data presentation improvements. They are listed in unsorted order below. The format is the following: subheader represents an issue or proposal for improvement. The text after it describe reasoning and clarifies details.

User Info

In the left top corner next to the photo we show basic patient information. It happened that both DOB and age is required simultaneously. Year serves as additional identification for multiple Johm Smiths. Ok, the information about age should be like 56 y.o. F, where F stands for female. M stands for male. Sex must follow the age, and must be encoded into single letter F or M. It should be next to the patient name. DOB should be on second line. Look below:

Photo    John Smith  62 y.o. M

    DOB 05/24/1950

In the right top corner we shown Discharged. It happened that nobody cares about discharge, while everybody needs Admitted. Hence, right below the MRN we have to add new line. MRN and Admitted record must be kept together. Look below:

MRN: 221881-5

Admitted: 08/24/2012

Those requirements are related to the integrity of  the data, what is kept with what. There is no requirements to UI layout. Current layout was confirmed as good.

Diagnosis

There is a widely used abbreviation for diagnoses. It is OK to use smth like HTN and MDs will understand it. Writing Depression is also good, but often names are long and abbreviation works better. Important information that is mission in our “first version” is Allergy. It is “the must” that complements the diagnosis. We have to allocate some space below Diagnosis and specify there Allergy. If Allergy is present, then it must be very contrast, may be highlighted in red. Look below:

HTN, Depression

Allergy: Aspirin (rash)

Medication

The patient can be currently on some medications. They must be listed on top of our single pager. Current Medication is such important as Diagnosis. We can specify it as a simple list of what the patient takes. Look below:

Metoprolol 50 daily [sorry, I can’t put units here right now]

Norvase 5 mg daily

Paroxetine 20 mg daily

Medication can be labeled as Meds. It should be in the upper area of the screen, as well as improved User Info and Diagnosis. Other info such as hospitalization and clinic visits should be kept within the upper area of the screen. Later sections describe the middle area of the screen.

I will provide typical medications for those 4 diagnosis: HTN, CAD/HLD, CHF, Asthma. Please update patients data to those 4 diagnosis only. This is our restriction for demo purposes. Medications will take max 4 lines on text, each line up to 25-30 chars.

Vital Signs

We shown then as separate charts: chart per temperature, chart per pressure, chart per heart rate. It sucks. The reason is that it does not represent information. What MDs see as information from vital signs? The relation between all signs together! Hence we must pack all 5 vistal signs into single chart so that all peaks or dropdowns are visible relatively to each other. The labeling for vital signs is the following: t for temperature, HR for heart rate, BP for blood pressure, RR for respiratory, SpO2 for something I don’t remember right now. The order of vital signs should be as listed with t on top and SpO2 at the bottom. Chart should be from sparklines, not for dots. All mins and maxs should be visualized properly. Now I understood what Mr.Tufte explained to our UX designer about use of sparklines. We though it was for all charts, but it happened it is only for vital signs. Look here for visualization spec. The chart with vital signs must be on top. Let’s keep it alwas in left top corner. If there is insufficient space, stretch it to the width of two charts.

Notes

They suck. Usually doctors put a lot of secondary info there. Hence there is no place for such irrelevant notes on the Home Screen. All doctors need is an entry point into the Notes. Doctors read them on demand. As a secondary screen opened intentionally. Implement it if possible.

Significant Events

Those are important! Significant Event is some even that is related to the life of the patient. E.g. patient fall and got head injury. In other words, non-typical events according to the diagnosis. If vomiting is common for that diagnosis, then vomiting is not a significant event, hence not worth big attention.

Probably we can redesign the right pane to show Medication on top, then Significant Events on top and in the middle, and has Notes as entry point at the bottom. If Medication takes too much space, then we can group it with Vital Signs (increased horizontally chart) and keep them together on top as a separate section. All other charts and Significant Events should be below them. Personally I like first alternative better – to use current right pane for both Medications and Significant Events.

EKG

Electrocardiology is “the must” on home screen. Add it as a separate chart, as in Tufte’s research and in web demo (see links above). It is OK to keep EKG on same place, hence keep it hear Vital Signs for example, at same horizontal level.

Imaging (aka Radiology)

This is a section of all scans. MDs call them interchangeably Imaging and Radiolody.  They have it as secondary information. Hence we have to put probably 1 or 2 images on the Home Screen, but implement separate screen with thumbnails to all imagery available for that patient. For our demo we can keep few images on Home Page, then we will see. But they (images) should be organised in some group labelled as Imaging.

Labs

Our “first version” doesn’t have Labs data at all. How Labs look like? It is a list of text and numbers. Furthermore, MDs get used to the order how to read the labs (BTW I confirm the same for vital signs). E.g. Labs called Hepatic Panel is shown as a sequence of AST, ALT, Alkaline Phosph. Labs called Coagulation is shown as PT, PTT, INR. It is common that Labs list contains 5+ sets of results (named as Panel here). Superscripts are used to represent K+, Na+, Cl-, CO3-, Ca2+ and so on.

We can allocate the space at the bottom of the Home Screen to visualize Labs and Imaging. Labs should grab more space than Imaging. As I’ve told, having 2 thumbnails as an entry point to Big Image is sufficient. Then physician should click either title Imaging or “…” next to the title, to get to the separate screen with all other images. Re Labs, they could be shown in tab format. Look below:

              date1  date2  date3

Erythr.    4.5    4.3    2.8

HGB    140    138    100

Disease Profiles

It could be useful to have layout presets for chronic diseases like Diabetes etc.

Continued on Mobile EMR, Part II.

Tagged , , , , , , , , , , , , , , , , , , , ,