Why Social Distancing is a Must Right Now

The concept of interrupting the spread COVID19 is not radical. Travel bans enacted in the early outbreak could have short-stepped the process of dispersal of the contagion, but that time has, sadly, passed. Social distancing is the practice of purposefully reducing close contact between people. According to the CDC, social distancing means remaining out of “congregate settings” as much as possible. Everyone should avoid mass gatherings and maintain distance of about 6 feet from others when possible.

This chunk from the below-referenced article explains what happened in South Korea, triggering the wildfire effect:

Patient 31 - It’s not clear where Patient 31 became infected with the virus, but in the days before her diagnosis, she travelled to crowded spots in Daegu, as well as in the capital Seoul. On February 6 she was in a minor traffic accident in Daegu, and checked herself into an Oriental medicine hospital. While at that hospital, she attended services at the Daegu branch of the Shincheonji Church of Jesus, on February 9 and again on February 16.

It seems South Korea has stabilized its outbreak. Social distancing is crucial for preventing the spread of COVID-19 (coronavirus). COVID-19 can spread through coughing, sneezing and close contact. By minimizing the amount of close contact we have with others, we reduce our chances of catching the virus and spreading it to our loved ones and within our community.

Read more here...

Unsecured Data Communication at the Health Care Exchange? Shouldda gone with My TRA

In May of 2011, I presented a back-end web services architecture for U.D. Dept of Health and Human Services Center for Medicaid & Medicare to the CTO (Mark Hogle). If the contractors for the public portal had gone with the technical reference architecture (TRA) as it was written and approved by the CTO, the concerns regarding back-end data in-transit, unsecured, would not be warranted.

Specifically, the reference architecture I developed called for,

Where the highest level of practical protection is called for, encrypting all message fields should be included in the architecture. XML Encryption (and decryption) requires fully parsing the XML transaction and then, for select message section(s), performing a set of processing-intensive XML and cryptographic encryption (decryption) operations. Deploying both XML Encryption and XML digital signatures can significantly affect the performance of high-transaction applications due to their resource-intensive nature. This can be mitigated by using hardware (an appliance, for example) rather than a software-based solution.

What are the implications of ignoring this (common-sense?) policy? Typically, a man-in-the-middle attack could be orchestrated. This breach is a form of active eavesdropping by which the attacker makes independent connections with the targets and relays messages between them, making them believe that they are talking directly to each other over a private connection. Data could be modified or absconded with.

Another problem is the repudiation -- where did this message originate from? Without this assurance, a provider is unable to ensure that a party to a SLA cannot deny the authenticity of their signature on a document or the sending of a message that they originated. Repudiations ensure electronically signatures are trustworthy, to ensure that a person cannot later deny that they furnished the signature. Any financial transaction needs this.

Plus, there's a bonus! The TRA specified performance testing! The issues around poor performance (that, of course, are not client-specific such as poor HTML coding) would never have made it from the test lab to deployment. In the TRA, CMS mandates Web Services testing and performance engineering. Specifically, these processes should use a systematic, quantitative approach to building Web Services that meets both business and performance objectives. While crafting software to meet business objectives is the developer’s primary focus, performance engineering should also map to critical use cases that take into account performance objectives, including response time, throughput, resource utilization, and workload.
Web Services testing should focus on regression testing and benchmarking against stated performance goals for individual services. The UDDI directory should be employed to document those goals. The purpose of such testing is to demonstrate that a service meets performance criteria, thus testing should assess load and stress.

The rationale for measuring Web service performance is multifold:
• Consumers need to know response times and anticipated throughput via APIs.
• Service resource demands are needed for different workloads.
• SLAs or other contractual obligations will rely on performance as a key concept.

Nobody wants problems with the President's attempt at reforming the health care insurance marketplace in this country. But just by applying the existing design constraints at the outset, HHS/CMS would have plugged another hole in the leaky dike that the Health Care Exchange has become, before any drips started.

Inquiries into the Obamacare Exchange launch

Fox News is reporting:

Leaders of the chamber’s Energy and Commerce Committee are pressing for public answers after the Obama administration and companies involved in the site's development and launch said the online health care exchange was “on track” for the October 1 start.

However, the site, which provides a menu of insurance plans for Americans in the 36 states without their own site, has instead been plagued by such problems as crashing under heavy user traffic, failing to let customers register or purchase plans and reportedly logging inaccurate information.

Committee Chairman Fred Upton began focusing on Secretary Sebelius after she went to Comedy Central’s “The Daily Show with Jon Stewart” last week to talk about the website.

“Secretary Sebelius had time for Jon Stewart, and we expect her to have time for Congress,” the Michigan Republican has repeatedly said.

The committee is scheduled to hold a hearing Thursday that will focus on whether officials involved with the site “Didn't Know or Didn't Disclose” problems.

==update==

The NYT has more on the government's attempts to correct some of the problems:

One major problem slowing repairs, people close to the program say, is that the Centers for Medicare and Medicaid Services, the federal agency in charge of the exchange, is responsible for making sure that the separately designed databases and pieces of software from 55 contractors work together. It is not common for a federal agency to assume that role, and numerous people involved in the project said the agency did not have the expertise to do the job and did not fully understand what it entailed.

And of course the classic problem,

Communications between the administration and contractors improved over the weekend as the Centers for Medicare and Medicaid Services began negotiating agreements with contractors on responsibility and deadlines for repairs, people involved in the project say. They hope to have a plan before a Congressional hearing set for Thursday. “The issue right now is between C.M.S. and the White House,” a specialist said Friday before communications improved. “Everybody sits and waits and the meter runs.”

The article discusses the prime, a Canadian firm,

CGI Federal, a unit of the CGI Group, based in Montreal, has the biggest contract and is responsible for the architecture of major parts of the system, but not for its integration. Quality Software Services Inc., or Q.S.S.I., a unit of the UnitedHealth Group, developed the identity management system, another major component that allowed consumers to register and establish accounts. The identity management system from Q.S.S.I., which also taps into government databases to retrieve users’ personal information, was a particular source of trouble when the exchange opened. Change orders show that on Oct. 4 — after millions of people had been trapped in technological loops trying merely to log in — the government asked CGI to help it devise a new identity management system to replace the one provided by Q.S.S.I. But specialists said that approach was abandoned as too risky. Ultimately it was decided to fix the current identity system.

Of course, I mentioned in a previous post the architecture and prototype I developed while detailed to MITRE, but that seems to have been ignored in favor of an off-shore solution. Which seems crazy, in these uncertain economic times. Why is the federal government going outside our borders for technological expertise of this nature?

The Cloud Saves Obamacare

Whatever the side of the Congressional aisle you are on (or maybe in the middle?), one of the more interesting aspects of the Patient Protection and Affordable Care Act (Obamacare) is its emphasis on technology’s role in curbing healthcare costs.

As David Linthicum notes, “No matter where you sit on Obamacare, it’s going to change the processes in how organizations deliver healthcare.” But nowhere is cloud approached more cautiously than in the healthcare industry. Yet evidence suggests that cloud and healthcare are poised to push the industry forward into its next phase, while reducing costs. But with so much negative press recently on overall government and healthcare, might cloud be an agent of change?

There is a lot of concern among the organizations supporting this healthcare IT push around security, but especially with maintaining compliance. HIPAA compliance is still opaque, requiring a great deal of guidance for implementation. This becomes especially tricky as an organization begins creating business associate agreements among vendors.

The federal government is aware of the value of cloud computing -- the U.S. Department of Defense has identified concurrent steps that enable a phased implementation of the DoD Enterprise Cloud Environment:
• Foster adoption of cloud computing
• Optimize data center consolidation
• Establish the DoD enterprise cloud infrastructure
• Deliver cloud services
This plan describes a defined transformation strategy that takes the DoD from its current state, preps the department for cloud computing, then concludes when DoD information systems can finally take advantage of public and private cloud computing providers or technology.


Read more here.

Poor Architecture Hampers Obamacare Exchanges

A few IT experts question the architecture of the Obamacare website. Government officials blame the persistent glitches on an overwhelming crush of users - 8.6 million unique visitors by Friday - trying to visit the HealthCare.gov website during its launch.

Disappointedly, the U.S. Dept of Health and Human Services did not implement the prototype architecture I developed for them, while on detail to MITRE. Instead, they opted for a Canadian firm's approach. (One wonders, why does the U.S. need to go "off-shore" for IT architecture when we have such talent widely available here?) CGI Group Inc, the Canadian contractor that built HealthCare.gov, is "declining to comment at this time," said spokeswoman Linda Odorisio. According to one analyst,

One possible cause of the problems is that hitting "apply" on HealthCare.gov causes 92 separate files, plug-ins and other mammoth swarms of data to stream between the user's computer and the servers powering the government website, said Matthew Hancock, an independent expert in website design. He was able to track the files being requested through a feature in the Firefox browser.

Of the 92 he found, 56 were JavaScript files, including plug-ins that make it easier for code to work on multiple browsers (such as Microsoft Corp's Internet Explorer and Google Inc's Chrome) and let users upload files to HealthCare.gov. It is not clear why the upload function was included.

Hancock's analysis suggested that the security questions were coming from a separate server and that better system architecture would have cached the questions on the main HealthCare.gov server. In the architecture I developed over a six-month engagement, the front-end web site was streamlined with minimal Javascript, and was served up via a WebObjects application handling the back-end connectivity to various data services.

I had applied my expertise in service oriented architecture — particularly how to apply SOA for cloud efforts — to come up with a prototype that could support 10's of thousands of concurrent users. I leveraged my expertise to demonstrate:
• How SOA 'automatically' improves end-to-end visibility and responsiveness.
• How to massively scale SOA in the cloud for extreme high-traffic, high-bandwidth applications.
• How current on-premises SOA can foster cloud architectures and deployments.
• How WebObjects frameworks will make web services and web-based user interface efforts more productive.
• How 'intelligent ESBs' help the cloud solution react in real-time.
• What SOA 'best practices' today offer the best ways to improve a cloud strategy, at little cost.

Health care and capitalism -- together like haggis and stout

The basic need for insurance and pension arrangements stems from personal risk and uncertainty -- and it is not a modern phenomenon. Even ancient civilizations fostered early versions of the concept of the insurance fund, with the grant of pensions in ancient Greece and the formation of burial societies in ancient Greece and Rome. In the Middle Ages it was sometimes possible to secure one's old age with a pension or even to purchase a room at a monastery with board and lodging provided. Marine insurance was invented, in order to help the expansion of trade, and this was followed by the beginnings of life insurance. Inevitably this is partly a book about "firsts".
Of course, the concept of deceit is not new, either. The earliest insurance fraud apparently was attempted in 350BC, when the owner of a ship tried to sink it.

Other examples of early insurance can be found: The earliest insurance policy seems to have been issued in 1350, on a cargo of wheat supplied from Sicily to Tunis. Life insurance goes back at least as far a 1399, when a policy was issued covering someone on a voyage from Barcelona to Italy. Astonishingly, the first occupational pension fund was established as early as 1590, the Chatham Chest, which paid pensions to disabled seamen and was financed by members' contributions deducted from their pay.

There was a great concern about the losses which people suffered in the Great Fire of London and in other fires in towns, and the first British fire insurance company was founded in 1680.
Many believe Napier, the Scottish inventor of logarithms (1614), may have been inspired to do so by studying the properties of compound interest tables. And Scotland provides the source of many a source about the use of insurance: the grant of pensions by Edinburgh Burgh Council in the 17th centuries; the pensions payable by Leith Trinity House in 1747; and, of course, the pioneering pension fund for Scottish ministers' widows (established 1743). Later, some prominent Scotsmen gathered in the Royal Exchange Coffee Rooms in Edinburgh to discuss setting up ‘a general fund for securing provisions to widows, sisters and other female relatives’ of fundholders so that they would not be plunged into poverty on the death of the fundholder during and after the Napoleonic Wars. Scottish Widows Fund and Life Assurance Society opened in 1815.

One might recall that Scotland is the home of Adam Smith, father of capitalism. Today's state of capitalism might, for Smith, demonstrate not the intrinsic faults of the system, but what happens when the moral dimension is neglected. In his 1759 book, Theory of Moral Sentiments, Smith takes on social and moral psychology and sociology: how one might understand how individuals and societies function not in separate compartments, but as parts of a complex whole. One of the key themes of the book is an opposition to the view that all morality or virtue is reducible to self-interest, as if individuals operated in isolation only concerned with their own particular well-being. Failure to craft an insurance approach to our society's medical needs is one such example of moral failure -- we need to look out for one another. When Smith later wrote The Wealth of Nations, he made it clear that the 'wealth' lay in the well-being of the people.


Want to learn more? Read Pensions and Insurance Before 1800: A Social History By C.G. Lewin and look up Adam Smith.


- Posted by Tom/Bluedog

Health Care in the Cloud - public portals as a solution

At the dawn of the dot-com era, portals and information exchanges were all the rage (I designed oversaw construction of a few, myself). My recent work at MITRE on the Affordable Health Care Act's federal information hub involve my designing a portal for those states who did not want to build their own.

Patient portals are the information aggregation and user interface engines now linking several applications, such as the organization’s electronic health record, including admission, transfer, discharge, or any hospital information system.

In this article,the idea of making use of publicly available solutions is raised:

The idea is to place this very complex data into an understandable context to provide the patient with a complete view of their health, including recent diagnostics, treatments, medications, and, most importantly, the monitoring of current health data to work more productivity with their doctors.

The article rightly points out that many in health care technology personnel push back on the use of cloud computing because of the privacy and security issues around patient data. But well-architected solutions with adequate security measures abound.

Read more here...

Health care giver information access expands with a SAAS offering

Here's a software-as-a-service (saas) that meets the growing need to share health care information when being a care giver. If your parents are growing old, or you have a spouse who needs your attention, this could be a good way to share the data, and burden. CareZone addresses the need for a safe place to keep information about doctors, diagnosis, and medicines. CareZone lessens the burden when sharing among a select (and trusted) group -- your spouse, your immediate family and trusted neighbors. The service was introduced last February with little notice, and is growing.

http://bits.blogs.nytimes.com/2012/11/13/the-anti-facebook/


- Posted by Tom/Bluedog