Phoenix Ambulatory Blood Pressure Monitor Project
Sub-project: 2007-04-29 Sphygmochron.org Implementation Meeting Notes

Attendees

Discussion

Topic
Meetings are not regularly scheduled.  It is not even clear that we will have more than one.

Topic
DeeDee is wearing a monitor for 7 days.  "Annoying."  (Worse than "obtrusive".)  Chase and I have previously worn monitors for two weeks; we officially don't really feel sorry for her.

Topic
There is a distinct lack of materials that are accessible to home users.  We specifically need materials that explain why anyone would ever go through the pain of 7 days of monitoring, and user guide information.  I will send some bits and pieces for both to DeeDee to start looking at.  DeeDee would like to take a shot at writing a user guide after her monitoring experience is over.  Both DeeDee and I know of technical writers that we'd like to recruit into the project.

Topic
The current sphygmochron report form is full of numbers, doesn't satisfy the home user's desire to know the "bottom line" right away:  "am I OK or not???  I want to know now."  A report showing no problems (i.e., with no red, bolded, or italicized numbers, nor any comments in the comments field) is particularly hard for a home user to interpret due to the complete lack of instantly-understandable positive feedback.  From her experience, DeeDee pointed out that people also have a strong desire to see a chart that shows all the data; this helps the user trust the report.  After some discussion, I suggested a new front page with
This would seem to satisfy the usability issues we discussed.  Germaine has suggested in the past that any re-design of the sphygmochron should be a somewhat formal procedure, with appropriate reviews.  I will eventually mock-up this potential new front page of the report and discuss with her.  I believe other suggestions for modifications to the sphygmochron will come along, also; there's no need to rush to try to complete this topic.

[There is a potential downside to making the first page of the report too easy to understand.  It may give the home user the false impression that there's no value in advanced interpretation of the rest of the report when there might, in some cases, be value in that.]

The sphygmochron report can list about a half-dozen out-of-spec conditions automatically.  (It does not do this yet, but I've discussed what to do with Germaine a couple of times over the past year or so.)  We want to have a statement printed about every automated test that the software does, regardless of whether it found a problem or not, so the home user can quickly skim them in the comments section look for "DO / DO NOT have a problem" phrases.  I suggest the wording be along the following lines:

"Based on the recorded/analyzed data and reference limits computed by the Halberg Chronobiology Center, the tests for the following conditions were performed, with the indicated results:

    SYSTOLIC    High Blood Pressure                (NONE, SYSTOLIC, DIASTOLIC, BOTH)
    NONE        Low Blood Pressure                 (NONE, SYSTOLIC, DIASTOLIC, BOTH)
    NONE        Systolic MESOR-hypertension        (NONE, MILD, SEVERE)
    MILD        Diastolic MESOR-hypertension       (NONE, MILD, SEVERE)
    NONE        Systolic MESOR-hypotension         (NONE, MILD, SEVERE)
    MILD        Diastolic MESOR-hypotension        (NONE, MILD, SEVERE)
    NONE        High Heart Rate (pulse rate)       (NONE, MILD, SEVERE)
    DIASTOLIC   Circadian Hyper-Amplitude Tension  (NONE, SYSTOLIC, DIASTOLIC, BOTH)
    NONE        High Pulse Pressure                (NONE, MILD, SEVERE)
    NONE        Deficient Heart Rate Variability   (NONE, MILD, SEVERE)
    NONE        Ecphasia/ BP out of phase          (NONE, SEVERE)

I need a better word for SEVERE that doesn't sound so drastic.  There's more than 6 statements when I write it out that way.  It seems like a table format would work, with single-word results filled in on the left, or perhaps circling the appropriate choice from the entire list I show on the right.  More work on how this would look can occur later.

I left out the detail about which version of reference values are used in the tests on purpose, on the theory that it confuses the issue and will show up in a more detailed part of the report.

An alternative to this that is used in dabl (http://www.pmsinstruments.co.uk/DABL%20ABPM%20Software.htm) would be to write prose statements like:

"Based on the recorded/analyzed data and reference limits computed by the Halberg Chronobiology Center, SYSTOLIC High Blood Pressure (SHBI 97.3, SBP MESOR 110, DHBI 38.0, DBP MESOR 72) is indicated.

Based on the recorded/analyzed data and reference limits computed by the Halberg Chronobiology Center, NO Low Blood Pressure (SHBI 97.3, SBP MESOR 110, DHBI 38.0, DBP MESOR 72) is indicated.

Based on the recorded/analyzed data and reference limits computed by the Halberg Chronobiology Center, SYSTOLIC MESOR-hypertension (SBP MESOR 151.1, DBP MESOR 78.5) is indicated.

etc.
"

I don't think this helps at all from the usability point of view.  It shows the complexity of the conditions we're looking for (sometimes combinations of the measurements are looked at to determine if a certain condition exists within the subject), so it points out a need for an easily-understandable definition of each of the conditions.  Also need definitions for the measurements (MESOR, Double Amplitude, etc.)


Topic
There's 3 types of users of the website (home users, caregivers, researchers).  Their needs are different enough that we might end up with 3 different websites in the long run.  On the theory that caregivers and researchers are technical people that can adapt to using a website designed for home users, I think we should concentrate on design of a website for home users first.

Topic
Chase suggested that getting an NIH Certificate of Confidentiality (see resources) might help the IRB feel more comfortable with the website.  However, my reading of the NIH pages (http://grants1.nih.gov/grants/policy/coc/background.htm) is that the IRB has to fully approve the project first: "In addition to the completed form, the Principal Investigator (PI) will be required to provide documentation of Institutional Review Board (IRB) approval ..."  Further, a U of MN IRB page (http://www.research.umn.edu/irb/guide/humanGuide4.cfm#TCC) says "The certificates are granted sparingly."  Dropping the subject of NIH Certificates of Confidentiality for the moment.

Chase suggested I read "DECIDE: A Scheme for Decentralized Identity Escrow", Noburou Taniguichi et. al.  Apparently from a conference titled "DIM '05".

Chase described his design for an identity escrow implementation.  It seems powerful, flexible, dynamic, and somewhat complex to program and maintain.  I described my design for simple encryption of the data on the website, not nearly as powerful, flexible, dynamic, or complex.  This design is now dubbed the "pipeline system", from the characteristic of shipping the encrypted raw data off to BIOCOS as quickly as possible without providing the authorization features of a full identity escrow system.  I would prefer to stick with the easier-to-program-and-maintain system if it meets the needs.  So far, the only significant requirement I know of is "Using encryption software to encode patient data." (IRB website: http://www.research.umn.edu/irb/guidance/data/)  This seems too loose to both Chase and I, based on our experiences in the commercial world.

Chase has some interest in prototyping some data protection code.  I must have convinced him that it makes sense to start small and prototype the pipeline system.

Question: Does the website (its owner/operator) have any responsibility to detect and shut off access by "bad" medical practitioners.  I don't quite remember the point of this question.  It arose because the identity escrow design can be used to disable access to a "bad" practitioner easier than the pipeline system can.  It wasn't the simple case of a doctor submitting too many reports for his patients trying to unbalance the reference limits, but I just can't remember what the case was.  I remember thinking that we'd never do it anyway, partly because it's not up to us to define what are "good" and "bad" uses of the sphygmochron reports.

Topic
The next meeting will be held when someone has something interesting to report or pressing questions to be answered.

About This Page

This page is maintained by Larry A. Beaty.  It was last updated on 2 May 2007.

The author(s) provide this information as a public service, and agree to place any novel and useful inventions disclosed herein into the public domain. They are not aware that this material infringes on the patent, copyright, trademark or trade secret rights of others. However, there is a possibility that such infringement may exist without their knowledge. The user assumes all responsibility for determining if this information infringes on the intellectual property rights of others before applying it to products or services.

(C) 2007 Larry A. Beaty. Copying and distribution of this page is permitted in any medium, provided this notice is preserved.

Back to the Phoenix Home Page