Lost in EPIC Land

One of the many unanswered questions about the handling of the first Ebola case in the United States is the role of the Electronic Health Record (EHR).  Initial reports put at least some of the blame for the patient’s being sent home from the hospital despite a high risk travel history on a failure of communication between the triage nurse and the emergency room doctor, aided and abetted by the EHR system.  Very quickly this story was altered.  On October 2 Texas Health officials were blaming the EHR, stating that “[a]s designed, the travel history would not automatically appear in the physician’s standard workflow.”  The next day, the same officials changed their tune, stating “[t]here was no flaw in the EHR in the way the physician and nursing portions interacted related to this event.” Texas Health Presbyterian Hospital in Dallas uses the EPIC EHR system.  Texas Health officials and EPIC deny that the reversal was related to any “gag order” in the hospital contract with EPIC.  It is not clear (to me at least) if these statements imply that there actually is no gag order in the contract, or the gag order is there but was not a factor in the changed story.  It should be noted that such gag orders are apparently common in contracts with EHR systems.  It should also be noted that EHR systems are very powerful companies.  EPIC’s CEO’s net worth in 2012 was estimated by Forbes to be $1.7 billion.  EPIC has benefited immensely from government largesse in the form of the taxpayer subsidies and mandates requiring physicians and hospitals to purchase EHR systems or risk losing Medicare dollars.  Politicians (especially Democrats) have also benefited from EPIC, with hundreds of thousands of dollars donated to political campaigns.  EPIC is in the running for a huge government contract to provide EHR services to the Department of Defense.  They certainly wouldn’t want the Texas Ebola snafu to sidetrack this.

Could the EHR have played a role in the confusion in the Dallas emergency room the day Thomas Eric Duncan was sent home with some oral antibiotics?  Perhaps we could understand better how communication failures between nurses and doctors using the EPIC EHR might arise if we could look at relevant screenshots.  When a nurse enters a travel history into EPIC, what then appears on the doctor’s screen?  How easy is it to see?  How easy could it be to miss?  Where does it appear on the screen?  How big is the font?  Does it even show up on the screens the emergency room doctor is usually looking at?

One can argue that it shouldn’t matter.  The nurse should have verbally communicated with the doctor the travel history, or the doctor should have taken his own travel history.  This is all true, but remember, EHR systems were supposed to make medicine better.  They were supposed to make sure everything was documented and nothing would fall between the cracks.  So it would be useful to see some screenshots to understand why something entered by the nurse into EPIC was not seen by the doctor.

Don’t hold your breath waiting for the screenshots.  Whether or not EPIC has gag orders in their contracts, they definitely do not allow posting of screenshots.  I found this out personally when I tried to post some EPIC screenshots in the past.  EPIC has a group of people whose job is to be on the lookout for EPIC screenshots on the internet.  When they find them, they contact the offending party and demand their removal.  I had prepared a screenshot with annotations to show how confusing the EPIC user interface is, and how easily one simple fact (Travel History: recent travel to Liberia) could be lost in the morass of toolbars, sidebars, tabs, and menus that is the EPIC user interface, but I can’t chance having the EPIC SWAT Team descend on my house.  So I have attached a blurred redacted screenshot.  If a news agency wants to take on EPIC, I would be happy to provide an unblurred screenshot.  I’m not willing to take the chance, but somebody should.

 

The EPIC UI, hopefully blurred sufficiently for the EPIC Screenshot Police (click to enlarge)
The EPIC UI, hopefully blurred sufficiently for the EPIC Screenshot Police (click to enlarge)

How Much Money Do Academic Experts Get From Drug and Device Companies?

Screen Shot 2014-10-09 at 9.50.04 AMNow that Open Payments data is available to the public I decided to do some snooping around.  It’s not hard to do.  I was curious as to how much drug and device company money academic experts receive.  As a cardiologist specializing in electrophysiology I have been to many national meetings, and it is always the same people year after year who chair the sessions, are on the policy committees, and write the guidelines.  If you are an electrophysiologist you know whom I am talking about.  I suppose every specialty has its own cadre of experts: the 1% who set the agenda for the rest of the us.  The big names in our respective fields.

So I picked 3 names at random and downloaded their Open Payments data.  Keep in mind that there are only 6 months of payment data available, and a third or more of the data has been withheld including most of the research payments.  I only included data from the general payments database and excluded the research payments.  I just picked the first 3 names that popped into my head, and won’t identify who these doctors are.  My intent isn’t to embarrass anyone.  They are all well known and meet the criteria for being an expert given above.

Expert A had 91 payments made over 6 months totaling $58,101.  Most of the payments were from Medtronic and Boston Scientific.  The majority of payments were listed under the categories of Food and Beverage or Travel and Lodging, but the larger payments were for Consulting Fees or speakers fees.  The largest individual payment though was for travel, at just over $6000 from Medtronic.

Expert B had fewer payments (34) but a larger total.  Over 6 months this expert was paid $112,115.  The majority of payments were by Medtronic, with individual payments as high as $24,500.  The description for one of these large payments was “Compensation for services other than consulting, including serving as faculty or as a speaker at a venue other than a continuing education program.”

Screen Shot 2014-10-09 at 9.45.58 AM
A sample from Expert B

Expert C had absolutely no entries in the database.  Zero.  Good for him!  Or should we wait until the full dataset is released before coming to conclusions?

In this extremely unscientific sampling of 3 experts, compensation from drug and device companies ranged from zero to 6 digits in 6 months.  Certainly one shouldn’t draw any firm conclusions from this.  Nevertheless, the fact that money changes hands between drug and device companies and the experts who help write guidelines and lecture about these drugs and devices is concerning.  Actual dollar amounts seem more stark and disconcerting than bland statements like Doctor X serves as a consultant for Company Y. Perhaps the Open Payments dollar amounts should be added to the disclosure slides that are shown at national meetings.  A more thorough look at this data is warranted.

How to View Your Doctor’s Drug Company Payments

The CMS Open Payments database is up for the public to view, but the site is difficult to navigate.  Here is a step by step guide to using the site.

  1. Go to openpaymentsdata.cms.gov
  2. From the list of databases, click on the General Payment Data with Identifying Recipient Information – Detailed Dataset 2013 Reporting Year (or skip step one and just click on the link) as in the image.

    Click on the highlighted database link.
    Click on the highlighted database link.
  3. The page opens with a spreadsheet and a number of filter conditions.  Write in how you want to filter the spreadsheet (e.g. filter for last name and city/state).  You can add filters, such as the first name on the page too (see Add A New Filter Condition in lower right corner).

    Filter the spreadsheet data.
    Filter the spreadsheet data.
  4. Horizontally scroll the spreadsheet to see the columns you are interested in.  There are a lot of blank or useless columns.  You can remove unwanted columns by clicking on the Manage button (brown button with a gear).

    The money column.  You can exclude columns using the Manage button.
    The money column. You can exclude columns using the Manage button.
  5. Make sure you are looking at just one physician’s data.  In the figure below I have horizontally scrolled to the list of physician names.  Note that there is a Physician_Profile_ID with a unique ID number for each physician.  Pick out the physician you want to look at and add a filter for that ID number.  Remove other filters.  This should give you the data you want on an individual physician.

    Screen Shot 2014-10-08 at 12.05.46 PM
    Physician names and ID numbers. Filter on a specific ID number to get all that physician’s data.

And that’s it.  I haven’t explored the other databases.  I haven’t found any tool (other than a calculator) to sum the dollar amounts.   [ADDENDUM: Use the Export button to export the data in a form compatible with your spreadsheet.  Options include Excel and CSV formats.] This information should be enough to get you started with the Open Payments database.

 

Ebola – Missing the Diagnosis

The first “wild” Ebola case in the United States has occurred in Dallas, Texas. The patient, who is from Liberia and had contact with a pregnant Ebola victim in his native country, was initially sent away from the Emergency Department (ED) of a Dallas hospital after reporting there with viral symptoms. He told the triage nurse that he had just arrived from Liberia, but despite this was sent home. How could this happen?

The media are reporting that there was a failure of communication between the nurses and the doctors but in truth we don’t know exactly what happened. Having worked in hospitals with busy EDs (though not as an emergency doctor) I can identify some factors that might have been in play.

  •  Common things occur commonly, rare things occur rarely. Don’t look for zebras. We are taught this in medical school. If it looks like a horse and acts like a horse, most of the time it is a horse, and not a zebra.  The principal as it applies in this case would be: even with this patient’s travel history, statistically speaking the most likely diagnosis is still the common cold. But this saying can lull doctors and nurses into complacency.  This maxim does not deny the possibility that a zebra will come into the ED, and medical personnel should always keep the possibility that they are dealing with a zebra in the back of their minds.
  • ED Overload. EDs are still the primary care entry point for the majority of patients in this country.  We lack easily accessible primary care facilities.  EDs are the go-to place for all kinds of acute illnesses, even minor ones. The result is that EDs are overloaded with patients with illnesses that would be better treated in other settings. I remember days when ED patients were stacked in the hallways on stretchers. The ED docs were running around harried and hassled without any time to even think about what they were doing. Such stress is not conducive to good communications and good diagnostic skills. People get sent home that shouldn’t be sent home, and people get admitted that shouldn’t get admitted.
  • Hospital Romper Room. Rather than giving in-services on detecting Ebola virus, hospitals torture medical professionals with hours and hours of elementary school level computer-based “education.” Courses on identifying different types of electrical sockets, what code pink vs code yellow means, compliance training, module after stupid module. And because no one can remember what a red electrical socket is for more than a year, the identical training and testing are repeated every single year. All this “education” and yet not a single in-service on Ebola or other threats. Hospitals aren’t interested in education. They only want to fulfill the requirements that have been imposed on them by regulatory agencies in order to maintain certification.
  • General knowledge. Doctors and nurses are well-educated, but may be suffering from the general lack of knowledge that afflicts the overall US population. For example, in the McCormick Tribune Freedom Museum poll only 8% of Americans polled could name at least 3 First Amendment freedoms, whereas 40% could name 2 of the 3 judges on American Idol  For a depressing litany of things Americans don’t know, see this.   Or watch episodes of Jaywalking with Jay Leno.  As about half of Americans don’t know where New York is, how many have even heard of Liberia?  It’s possible that no connection was made between a febrile patient from Liberia and Ebola due to lack of knowledge of geography and current events. Remember Sarah Palin (among others) didn’t even know Africa was a continent.

I’m not trying to make excuses. Sending this patient home was a horrible mistake. But in the US Health Care system we reap what we sow, and we are making a mess of it. It will only get worse as the medical field becomes less and less attractive to our best and brightest.

AutoLayout Revisited

My initial experiences with Apple’s iOS AutoLayout were pretty negative. Using Interface Builder’s (IB) ability to generate AutoLayout constraints automatically based on the positioning of views turned out to be frustrating, as it would generate constraints that were incompatible with iOS 7. As iOS 8 has only been out for a few weeks, I definitely want to keep supporting iOS 7 in my app. But Xcode 6 generates these incompatible constraints anyway, even though the deployment target is iOS 7. Furthermore the automatically generated constraints don’t really do what I want, such as keeping views centered on the screen when the screen enlarges from iPhone size to iPad size. So I was forced to go back to the drawing board and really try to understand how AutoLayout works.

My impetus for all this was my desire to upgrade one of my apps from an iPhone only app to a Universal app — optimized for display on both the iPhone and iPad. The app (EP Mobile) has a big storyboard and many different views. By using AutoLayout I hoped to avoid having two different storyboards, one for iPhone and another for iPad, and just use one storyboard for both devices. I decided to check the Use Size Classes option in IB. Supposedly this allows for designing separate layouts in a single storyboard for different size devices. As it turns out, this was not helpful, as apparently this feature only works on pure iOS 8 apps. Moreover, as the compiler seems to generate code for each possible device, building your app after making a change in the storyboard takes much longer than it did before enabling this option. After a while I grew tired of this and decided to turn off Size Classes. However trying to do this resulted in a warning dialog from Xcode that stated a lot of nasty things that might happen (I hate dialogs that use the word “irreversible”) and so I decided to just live with the longer build times.

I watched some YouTube videos on AutoLayout that were helpful (here and here), but in truth the best way to learn AutoLayout is to play around with it. Take a view, clear any constraints that are there, put the subviews where you want them, and then add your own constraints manually. While doing this, ignore warning messages from Xcode about ambiguous constraints and misplaced views. Ignore the yellow and red lines that show up on the screen indicating these errors. Until you have completely specified all the constraints needed to  determine unambiguously the location of the subviews without conflicts, these warnings will show up. Prematurely asking IB to Update Frames before all the constraints are specified will make the subviews jump around or disappear. Unfortunately even when all constraints are specified and correct, the yellow warnings don’t go away. IB is not capable of automatically applying your constraints and misplaces your controls in your views whenever you change constraints. Sometimes it misplaces controls even when you are just changing the storyboard metrics from one size to another. Update All Frames then puts everything where it belongs.

One way to start is by putting constraints on heights and widths of controls that you don’t want to resize when the screen size changes or the device rotates. Note that some controls, such as buttons, have an intrinsic size based on the button label, and it is not always necessary to add specific constraints to these controls. However, it looks to me like the system will ignore the intrinsic size at times, especially if you are trying to do something fancy with constraints, and your button will grow to a ridiculous size to satisfy your constraints. So it doesn’t hurt to specify width and height constraints manually even in these controls. Of course if you want controls to expand in one direction or another, don’t specify a constraint in that direction.

Next step is to align controls that are lined up horizontally. You can select multiple controls and then align their vertical centers using Editor | Align | Vertical Centers on the menu. If there are rows of controls like this you can take the leftmost control and working from the top to bottom, pin each row to the row above (or to the superview for the first row) to make sure there is vertical separation between the rows. Finally, usually you want your controls to be centered on the screen, even when using different screen sizes and with rotation. If you have one wide control, such as a segmented control or a large text field, you can horizontally center that control. You can then pin the leading edge of that control to the leading edge of the superview (i.e. the window) and that view will grow as the screen width increases. Aligning the leading edges and trailing edges of the other controls to this view will allow the whole set of controls and expand and contract with the width of the screen. If you have rows of controls, you may still need to put constraints between individual controls to control the horizontal distance between them.

One issue I noticed was that, while it’s nice to have controls expand to fill the screen of the iPhone when going from the small iPhone 4s to the 5.5 inch iPhone 6, sometimes the controls get too wide when viewed in landscape mode or on the iPad if they are just pinned to the superview leading edge.  For example, this segmented control is centered horizontally and vertically in the superview, and the leading edge is pinned to the superview leading edge.

Screen Shot 2014-10-01 at 10.03.52 AM
Segmented control has centering constraints and is pinned to the leading edge of the superview.

On the iPhone 4s, with rotation the view remains centered and enlarges when the device is rotated.

iPhone 4s portrait
iPhone 4s portrait
iPhone 4s landscape.  Control remains centered and expands to fill screen.
iPhone 4s landscape. Control remains centered and expands to fill screen.

To show the flexibility of AutoLayout, we can limit the expansion of the segmented control to a maximum we select, by making the width less than or equal to a value (in this case 350) and lowering the priority of the pinning of the leading edge to the superview. This achieves the desired effect.

Width of control constrained to ≤ 350 and priority of pinning to left margin decreased to 750
Portrait view is unchanged, but landscape view (shown here) limits the width of the control to a max of 350
Portrait view is unchanged, but landscape view (shown here) limits the width of the control to a max of 350

You can do a lot with AutoLayout just using IB if you are patient and try out various effects. You can do more by attaching your constraints to outlets and manipulating them in code. It is unfortunate that some glitches in the implementation of AutoLayout in Xcode 6 Interface Builder make using AutoLayout more frustrating than it needs to be.  To those who are discouraged like I was by AutoLayout, I urge you to keep experimenting with it.  The a-ha moment will come and it will be worth it.

How Secure is Your Medical Data?

Script showing my Mac is vulnerable to ShellShock.
Script showing my Mac is vulnerable to ShellShock.

With the recent discovery of the ShellShock vulnerability affecting a large number of computers, the question comes up again: how secure is medical data? Thanks to the federally mandated push to transfer medical data from paper charts to computer databases, most if not all of this data is now fertile ground for hackers. As pointed out in this article medical data is more valuable to hackers than stolen credit cards. The stolen data is used to create fake IDs to purchase drugs or medical equipment, or to file made-up insurance claims. Hackers want our medical data and hackers usually find a way to get what they want.

In going from paper to silicon, we have traded one set of disadvantages for another. Paper charts are bulky, require storage, can get lost or destroyed, are not always immediately available, can be difficult to decipher, and so on. Electronic Heath Records (EHR) systems were intended to avoid these disadvantages and to a large part do; however, we have traded the physical security of the paper chart, which can be locked up, for the insecurity of having our medical data exposed to open ports on the Internet. And make no mistake, the Internet is a wild and scary place. My own website, certainly not containing anything worth much to hackers, is subject to multiple daily bruteforce password guessing attacks to login. Fortunately I have security software in place, but despite this the site was successfully hacked in the past from Russia. There is no doubt that more important sites than mine are subject to more intense attacks. Millions of credit cards have been stolen in attacks on Target and Home Depot. Celebrity nude photos have been stolen from “secure” sites. And if you are not worried about hackers getting your medical data, thanks to Edward Snowden’s revelations you can be sure that it is freely available to the NSA.

But certainly, you ask, given the sensitivity of the data, EHRs must be amongst the most secure of all computer systems? Well it’s difficult to answer that question. Most EHR systems use proprietary software, so the only people examining the source code for bugs are the people that work for the EHR company. It is unlikely that any bugs found would be publicized; rather they would be silently fixed. As critical as some people have been about the existence of bugs in open source software, such as the HeartBleed and ShellShock bugs, at least there is a potential for such bugs to be found by outside code reviewers. There is no such oversight over the code of the EHR purveyors.

Even if one for the sake of argument assumes that EHR systems are secure from online hacking, they are still very vulnerable to what is known as “hacking by social engineering” or “social hacking.” Social hacking involves the weakest link of all security systems, the computer users: doctors, nurses, medical assistants, unit secretaries and others. People who use easy to guess passwords like “123456” or who tape the password to the bottom of the keyboard. People who get a call from someone pretending to be from IT asking for the user’s ID and password in order to fix some supposed problem. There are a large number of cons that rely on human gullibility that can be used to break into “secure systems.”

Besides these issues, I observed a great deal of laziness in regard to security when working in the hospital. Doctors would often log into the EHR system, review patient data, and then leave the computer to visit the patient room without logging out of the system. Anyone could sit down at that computer and view confidential patient information. Some of the systems would automatically log off after a few minutes, but even so there was plenty of time for a dedicated snoop to get into the system. And the problem can occur in doctor’s offices too, now that many exam rooms have a built-in computer. Just yesterday at my eye doctor’s office I was left alone in the exam room for about 15 minutes while my eyes were dilating. Sitting next to me was a desktop computer running Windows 7, left with the user logged on. This doctor’s entire network lay vulnerable. How easy would it be to read patient files, or copy a rootkit or a virus onto the system using a USB drive? Real easy.

Bug-free and 100% secure software probably is a pipe-dream that can’t be achieved in the real-world. In addition, hospitals, with hundreds of computer terminals everywhere, some still running such outdated and vulnerable operating systems as Windows XP, and with busy, security-unconscious users like doctors and nurses, are a security disaster waiting to happen. Now that we have put all our medical data metaphorically into one basket, I am convinced it is only a matter of time before there is a massive data breach that will make the Target credit card breach seem trivial by comparison. Better training of medical personnel who use EHRs may help prevent this, and this should doubtless be done. But we will never have the level of security again that existed in the era of paper charts.

The Approaching Sunshine Apocalypse

On September 30, a week from today as I write this, the US government will release the long-anticipated Sunshine Act Open Payments data to the general public. Or at least some of it, maybe two thirds. It’s not clear. What is clear is that Open Payments has gotten off to a rocky start, reminiscent of the snafu with the inauguration of HealthCare.gov last year.

Our story so far: Back in 2011 as part of the Affordable Care Act, aka ObamaCare, measures were put into place to shed light on the here-to-fore undisclosed direct financial dealings between Big Pharma and physicians. All payments, whether in the form of honoraria, ball-point pens, or bagels from Panera were to be accounted for, tallied up, and presented on a web site for the public to peruse starting this September 30. As a concession to the physicians and drug or device companies, there was a period of review this summer (45 days), during which payments could be viewed by physicians and potentially disputed.  Payments disputed after this time period would be marked as undisputed in the database.  Thus it was important for physicians to dispute these payments before the release to the general public (BTW it’s too late now).  I’m not sure how many physicians participated in the review process. Getting into the Open Payments website initially is onerous.  In order to register for the site, two separate processes of authentication are required, during which applicants are challenged to answer questions based on their credit report history (!), as well as answer a series of questions while a timer runs, including providing a subspecialty code which, if you are lucky and have a fast internet connection, you can google just in time before the buzzer runs out.

Having gotten into the system, one can laboriously go through each payment in a spreadsheet and try to ascertain whether or not various payments are legitimate. When I did this I found that, despite providing very specific information in the login process (such as my NPI number), my payment records were mixed in with another physician with my name who practiced in a different state (Florida vs Kentucky) in a different specialty (oncology vs cardiology). Via Charles Orstein and ProPublica this story was published.   This resulted in CMS shutting down the Open Payments website to fix this problem.  The site was shut down for 12 days, from August 3 to August 15. The time allotted for physicians to review their data was extended correspondingly, to September 11.  However, upon reopening the site not only were the mixed up payments gone, but most of the legitimate ones were also missing from the database. CMS then stated that some companies’ data was still being withheld due to data inconsistencies in company submissions. The companies dispute that the problem is theirs, instead blaming the government. The amount of data missing is supposed to be about a third, but, at least in my case, almost all the legitimate payments previously listed in database prior to the closure of the site are now missing.  For example there is no data listed at all from Medtronic, despite payments from them in the database before the “glitch.”  Meanwhile, further glitches shut down the Open Payments system intermittently between August 30 and September 5. Despite all this, the imperfect data is still planned to be released to the public on September 30.

What will the public make of this? Will some consider any payments at all to doctors in the form of food or honoraria a sign of corruption or at least conflict of interest? Will the trivial nature of some of these payments be reassuring to the public? Will the data reveal blockbuster damning revelations about the nature of the relationship between industry and physicians?   Or will the data be just ho-hum?  Who knows? My question is, why release the data now if it is incomplete or questionable? Why stick to this arbitrary timeline? If we are going to supply this data to public, shouldn’t it be as accurate as possible?

I just checked the Open Payments website. It is down again. Not reassuring.

Down again
Down again

AutoLayout Headaches

The new larger iPhones and iOS 8 are here. Xcode 6, upgraded to deal with these new beasts, is also ready for download. Anyone who has written apps designed for the iPhone has to make sure their apps run on these new devices and the new iOS. Previous iPhones had two different heights (3.5 and 4 inches) but were the same width. The new iPhones are not only longer, but are wider. With the previous devices, it was relatively easy to design for the slightly different heights. Now the developer has to deal with layouts that work with many different aspect ratios. If your app is a universal app (i.e. runs on iPhone and iPad) there are even more sizes that you must deal with.

Anticipating this, Apple, a few versions back, introduced AutoLayout to take the place of their older layout system using springs and struts. With AutoLayout, you place your widgets where you want and, automagically, they retain their relationship with different screen sizes or when rotating the screen. Or so it’s supposed to work in theory.

As it turns out, AutoLayout introduces its own set of headaches which rank up there with your worst migraines. Let’s begin.

Intrinsic AutoLayout

If you have AutoLayout turned on (which is the default now), any prior layouts you have, whether you used springs and struts or absolute layouts, will be converted to the AutoLayout system. Any new layouts will use the AutoLayout system automatically. When placing widgets, the dotted blue guidelines will have more meaning than they did before. For example, if you center a widget using the blue lines, that widget will appear centered with different device sizes or with rotation. This is called intrinsic AutoLayout, and the effect is added at run-time. That means, somewhat surprisingly, that when you change device size using Interface Builder (IB), the layout won’t look right.

 

Layout appears off center on 5.5" iPhone 6 Plus
Layout appears off center on 5.5″ iPhone 6 Plus (click to enlarge)

But if you run the simulator, the layout will look fine.

Same layout appears nicely centered when running on iPhone 6 Plus simulator
Same layout appears nicely centered when running on iPhone 6 Plus simulator (click to enlarge)

Hopefully that will be true when running on the new hardware itself, but since I don’t have an iPhone 6 I can’t test this. The moral of this story is don’t start fiddling with your layout because it looks weird on IB. Run your app on the simulator at each size (and on hardware if you have it). Most of your layouts will look OK on the larger iPhones due to intrinsic AutoLayout.

Explicit AutoLayout

If you need to alter what is produced by intrinsic AutoLayout, you have to manually add constraints. Constraints are a rigorous description of a relation between two views. Examples include centering a widget in a superview, fixing a widget’s height, but allowing width to change, and setting a fixed distance between two widgets. Constraints are actually pretty cool in theory and can be added in code. But using IB, once you start adding constraints all hell breaks loose.

Suppose everything about your view looks good, but you want the bottom of your widget to be pinned to the bottom of the view it is contained in. So you add that one constraint. With that one action you have blown away the intrinsic AutoLayout system and IB will inform you that you have all sorts of ambiguous heights and widths. So if you add any constraints in IB, you have to add constraints to all the widgets. There is a menu item to do this, and suddently there are about 50 constraints added to your view. And here you hit your first surprise. Even though you are targeting your app for iOS 7, Xcode adds constraints that are incompatible with iOS 7!

Constraints incompatible with iOS 7 are automatically added by Xcode 6!
Constraints incompatible with iOS 7 are automatically added by Xcode 6! (click to enlarge)

Constraints can’t be relative to the superview margin in iOS 7 but IB blithely adds them anyway. So you go through the constraints, one by one, edit the ones that have “relative to margin” checked, which ends up changing the appearance of your view. It is then that you discover that changing a constraint tends to mess up your view or mess up the other constraints. You often get a message saying that the view at runtime will not appear the same as it appears on IB. I found that pressing Option-Command+= fixes that. It is easy to get frustrated when editing constraints in IB. The “Clear Constraints” menu item is your friend here, so you can start all over.

AutoLayout and ScrollViews

It gets worse. If you have any ScrollViews in your app, with AutoLayout they appear to work on the simulator, but they don’t work on actual hardware! Turning off AutoLayout fixes this, but DON’T DO THIS! You cannot turn off AutoLayout for a single view. It goes off for your whole storyboard. And your carefully laid out and tweaked constraints disappear. Version control is your friend here. Using AutoLayout and ScrollViews is complicated, as you can see from this. After reading this and playing around, I was able to get my views to scroll by pinning the ScrollView to the superview on all four sides. Interestingly, when setting up a ScrollView with AutoLayout, you no longer have to add any code about the ScrollView as was necessary before (you would have to add the content size of the ScrollView for it to work). But again, this is a real trap, especially as if you do it wrong, it looks like it is working on the simulator but won’t work on an actual device.

And so…

Handling resizing and rotation is one thing that is a lot easier when developing for Android than for Apple iOS. AutoLayout has a steep learning curve, and others have had these same problems (search for AutoLayout on StackOverflow, or see this. I hope that Apple can improve this experience. I like the concept of AutoLayout, but the devil is in the details.

Update: Since writing the above, I have gone back to basics with AutoLayout and made a concentrated effort to understand the system.  I don’t think the AutoLayout system is bad; however, using AutoLayout in Interface Builder can be rough going for the reasons given above.  AutoLayout itself though is very flexible and I do think you can do just about anything you want with it if you understand it well.  I am trying to achieve this level of understanding.  I have found that the best way to learn is to play around with a view, adding constraints and seeing what happens.  I have also discovered the new feature of Size Classes in Interface Builder  in Xcode 6 which makes developing a Universal App using a single storyboard much easier.  So I’ll keep plugging away until I have conquered this beast.

Don’t Turn Your Back on Your Patient

One of the most important “tricks of the trade” that I learned in Medical School was what some might have considered a little “throw-away” bit of advice. During my psychiatry clinical rotation the preceptor advised that, when applying the stethoscope to the patient’s back, one should rest the other hand gently on his or her shoulder. Human touch was important. It would relax the patient and convey subconsciously a sense of compassion, a feeling that “we’re in this together.” I decided to take that advice and throughout my career always touched my patient’s shoulder with my left hand while I was listening to his or her lungs. I don’t know whether this technique “worked.”  Not one patient ever commented on it. But there must be some reason I had such a good rapport with the majority of my patients. Of course this may have been unrelated to the shoulder touch. Maybe it had more to do with looking patients in the eye when talking to them, paying attention to what they said, showing I paid attention by asking appropriate questions, expressing concern and compassion, always shaking their hand when I entered their room, or perhaps some other unconscious body language that put them at ease.

When I was Professor of Medicine at the University of Colorado I told students that Medicine is both a Science and a Humanity. This is what is emblemized by the phrase “the Art of Medicine.” In recent years there have been great advances in the Science of Medicine, and one could be forgiven for believing that science is all there is to it. Medicine as a Humanity is less well studied, less well understood. Changing age-old practices that affect the doctor-patient relationship may have unforseen consequences. Changes like more rushed, shorter patient visits;  doctors turning away and seemingly ignoring their patients while furiously entering text into an electronic health record (EHR) on a computer; or telemedicine with doctors miles away in front of a television camera. Changes like doctors who don’t relate to patients on a personal level, who don’t have long-standing relationships with patients, who aren’t in touch with their patients.

Long ago, when there were only a few legitimate drugs, and many bogus ones — maybe 50 years ago, certainly 100 years ago or even take it back to Greek and Roman times — there were still doctors. They didn’t have much to work with scientifically. They didn’t get results the way doctors today do. But I wouldn’t discount the possibility that they got some results, in fact sometimes good results. The science of the mind is not well understood. Placebo effects are small, but real effects. Calling in the wise-looking, well-dressed gentleman with the black bag full of mysterious pills and injections, with the comforting voice, with the laying on of hands, the careful physical exam — I’m sure all this had a beneficial effect, regardless of the lack of treatments backed by randomized clinical trials . I’m not for going back to those times — we are far better off with good science backing our therapies! But aren’t we losing an important tool in our armamentarium? Patients need our firm handshakes, the touch of the stethoscope, our thoughtful advice.

When our healthcare practice purchased an EHR I resisted the urge to use the computer in the exam room, even though it was slower for me to do my notes in the privacy of my office. I didn’t want to turn my back to my patients. The people who want to increase constantly the amount of electronic documentation we need to enter into the computer don’t understand this. We need to increase the time with the patient and decrease the time with the computer. We need to be in close communication with our patients as one human being to another. We need to relate on a human level, not electronically.

We should never turn our backs to our patients.

What Motivates Doctors?

As a recently retired physician, I still maintain an interest in medical research, though I have to ask myself: Why? Surely not just from the point of view of a potential future patient. But not from the point of view of a practicing physician either. Perhaps I keep up just from a lifetime of habit?  Or is there something I miss about my old job?

These thoughts came to mind as I was reading some of the reports from the European Society of Cardiology meeting in Barcelona, Spain last week, in particular the results of the PARADIGM-HF trial in which a new, so far not brand-named drug, LCZ696, out-performed traditional ACE inhibition in patients with heart failure, and, in my own field of electrophysiology, the results of the STAR AF 2 study  which imply that a more limited is better than a more aggressive approach in ablation of persistent atrial fibrillation. I read these reports with a combination of excitement, my usual dose of skepticism, and perhaps a tinge of regret that, while the science of medicine advances inexorably, my own participation in this process ended as of December 31st, 2013, the day when I performed my last catheter ablation procedure for atrial fibrillation. Yes it seems odd that I was performing procedures one day and then retiring on the next, but that’s the way it was. At least I wasn’t on call my last night. And although I have written that doctors shouldn’t hesitate to retire when they are ready, sometimes I do look at my still-practicing colleagues with a bit of envy, feeling I am missing out on some of the fun of being a doctor.

Doctors just starting their medical careers, residents, fellows or newly appointed attendings, can easily get discouraged reading many of the online posts and comments from older doctors — including my own. There is a lot of negativity in these posts. We read about increasing work loads, decreasing salaries, competition from associated professionals, unmanageable electronic health record systems, terrible on-call nights, malpractice suits, loss of respect for the profession, Obamacare — the list goes on. It is probably tougher to be a doctor today than it ever has been. As my own career progressed, I had more and more of a feeling that I was swimming upstream against an opposing current of non-medical administrative, regulatory sewage. I found it easier to retire at a relatively early age (62) rather than continue the struggle. It wasn’t a brave decision, nor is it a practical decision for younger physicians, in particular those new physicians just out of medical school saddled with enormous debt. To those physicians, I would like to sound a note of optimism (which unfortunately might be drowned out in the comments section to this post).

Everyone who goes into medicine knows it is going to be hard. This was as true back when I started my internship as it is now. But there are rewards in medicine, and they still exist. I’m not talking about the traditional rewards of past years: financial success, stature in the community, pride in taking part in an old and honorable profession. Unfortunately much of this has evaporated in recent years. Nor am I talking about the occasional uplifting story whereby a patient heeds your exhortations to stop smoking and comes back years later to thank you for changing his life — as wonderful as such stories can be. No, I am talking about another aspect that is not frequently mentioned: the challenge of medicine.  Medicine is a battle against disease.  We doctors are on the front lines of this battle, and we are winning.

The challenge was there in every patient with atrial fibrillation, in every patient with ventricular tachycardia, in every patient with supraventricular tachycardia. These diagnoses were relevant to my field, but I’m sure that similar challenges exist in each specialty of medicine, and in general internal medicine as well. To me each diagnosis was a challenge, and the battle was fought using the weapons I had at hand: the ablation catheter, the pacemaker or implantable defibrillator, antiarrhythmic drugs, or simply persuasion, attempting to alter self-destructive life styles. It was immensely satisfying to ablate a pathway and control a life-threatening arrhythmia. But just as in the Wide Wide World of Sports, there was both the thrill of victory and the agony of defeat. Failures, especially complications, which, if you do enough procedures, statistically have to occur, always disproportionately tempered the successes, even though the latter were thankfully much more the norm. Such is human nature. But I think that which motivated me the most during my medical career was the wonderful adrenaline surge that came from ablating a tough atrial tachycardia or other arrhythmia. This is the sort of thing that motivates doctors despite all the other nonsense that we face. This is what keeps us going, or it least it was in my case.

And I sort of miss it.