Home » Readers Write » Currently Reading:

Readers Write 11/1/10

November 1, 2010 Readers Write 6 Comments

Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!

A Step Towards the Cloud
By Mark Moffitt

People tend to use the terms SaaS and cloud interchangeably, when in fact, they are two different things.

Software as a Service (SaaS) delivers software as a service over the Internet, eliminating the need to install and run the application on the customer’s own computers and simplifying maintenance and support.

Cloud computing is about using economies of scale and sharing cheap, commoditized computing resources to lower overall costs. To realize these economies of scale large data centers are built and managed to protect and secure customer data at the lowest possible cost. These data centers are huge (see photo below).

Cloud software takes full advantage of the cloud paradigm by being service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. Cloud storage uses shared-nothing, distributed data stores so that low-cost, commodity storage technology can be utilized. Traditional RDBMS don’t fit into these new storage models. The reason is RDBMS need to join data from multiple tables. This requirement is incompatible with the distributed storage configuration found in cloud storage services.

clip_image002

Google’s Dalles, OR data center on the Columbia River

On the banks of the windswept Columbia River, Google is working on a secret weapon in its quest to dominate the next generation of Internet computing. But it is hard to keep a secret when it is a computing center as big as two football fields, with twin cooling plants protruding four stories into the sky. New York Times, June 8, 2006

Few HCIT vendors have architected their system for the cloud. The good news is that healthcare systems don’t have to wait for HCIT vendors. They can take advantage of cloud computing today by storing and archiving clinical results such as lab results, transcribed reports, images, and waveforms in the cloud.

Clinical results are well suited to take advantage of cloud storage for reasons such as:

  • Results do not require a schema or other features of a RDBMS to store and access data. Yes, that includes lab results.
  • Key-value (object) stores are better suited for storing results than RDBMS.
  • Key-value data stores can use cloud storage technologies that are less expensive than the cost of using a vendor’s RDBMS to store and archive data.
  • Clinical results often need to be shared beyond the walls of an organization and, therefore, ideally suited to being stored in the cloud.

Amazon’s S3 cloud storage prices run about $18,000 per year for 10 terabytes of data. These prices include storage, archiving, and security. 500 terabytes is priced around $800,000 per year. There are additional fees related to access, but this number gives the reader a ballpark estimate of the price for the service. Other vendors such as Google and Rackspace offer a similar service at about the same price.

Other potential costs include deploying a system to provide local caching of often-used data in the cloud. This is accomplished by deploying a hybrid cloud to include local storage as depicted in the diagram below.

clip_image004

Savings are real and immediate when an organization pursues the cloud storage strategy for clinical results when replacing hardware such as moving from MEDITECH Magic to 6.0 or MEDITECH Magic to Cerner; or upgrading an image archive system. Cloud storage can eliminate the need for hardware and software that would otherwise be needed to store and archive existing and future clinical results.

It seems to me that cloud storage is a better model for an HIE than reposing clinical results into yet another fixed-schema RDBMS. The reasons are:

  1. Providers are obligated to maintain a copy of results for legal and reimbursement obligations.
  2. Providers save money by storing and archiving clinical results in the cloud.
  3. HIE organizations can use clinical results stored in the cloud and focus their efforts on providing services unique to an HIE such as electronic opt-in/opt-out functionality, security, and record locator services for clinical results as a way to offer personalized EHRs to patients.

The transition to cloud computing in HCIT will take years as the business case for the approach becomes financially and operationally attractive as compared to alternatives and customers understand and accept the new paradigm of cloud computing and cloud storage. The transition to cloud computing will not be a waterfall event, but rather a gradual diffusion of the technology into HCIT. Storing, archiving, sharing, and securing clinical results in the cloud may be the first step in moving HCIT to the cloud.

Mark Moffitt, MBA, BSEE, is a former CIO and is working as a consultant while looking for his next opportunity.

Why IT Can Never Be Irrelevant
By Shubho Chatterjee

Over the last few years, journals, trade magazine articles, editorials, and even a textbook (Does IT Matter by Nicholas Carr) have prognosticated the irrelevance and strategic demise of IT. Many thought-provoking articles and blogs have debated the pros and cons of this prognostication.

I am going to add one more and argue that IT can never be irrelevant in organization, strategically or operationally. Here is my argument.

Firstly, IT is a discipline, much like engineering, finance, marketing, and others. Within engineering and finance exist multiple disciplines. As long as the world exists, both disciplines will exist. IT is similarly an assembly of different disciplines providing a very important outcome. Do we come across arguments that engineering or finance is irrelevant? No. Similar rationality will negate the IT “demise” thought leadership.

Secondly, following from the first argument, can we imagine today any organization operating without technology and IT? Take out IT — ERP, EMR, CRM, data networks, Web sites, ad infinitum — from any organization and the entire organization will collapse. Who plans for this, who should strategically plan for this, and who operates these systems? IT. IT is probably the most critical component of a functioning organization.

Thirdly, let’s examine IT functions and how it provides context to this debate. At the lowest level, Tier 1, is the basic infrastructure support, such as, help desk, network management, telecommunications support, and others. These activities are very commoditized and often outsourced, on-shore or off-shore. Outsourcing has also provided a rationality support for the “IT irrelevance” thought camp. But let us examine what happens and who does it.

Even when such functions are outsourced, somebody in IT has to do it, even though it is done by another organization. Often the outsourced employees are absorbed in the outsourcing organization. Therefore, in this case, we cannot say that IT is irrelevant — the function and activity has shifted organizationally and is also managed by IT of the vendor. The outsourced vendor relationship is also managed by the customer IT organization. Similar arguments hold for application development and support activities. For off-shored activities, the job losses are a fact, but it does not make IT irrelevant.

At the middle level (Tier 2) of IT operations, let’s say, at the business analyst, project management, vendor management, or network operations management levels, the IT aspects are critical. For example, the business analysts are key to developing IT product or service development and delivery requirements and pipelines, the IT vendor managers are key to selecting, evaluating, and managing vendor relationships. Can any other disciplines perform these functions? No. Why? Because these activities require domain knowledge and experience. For example, who other than IT can plan how a wireless network will integrate with a wired network to provide a point-of-service usage of EMR for medication management at a patient’s bedside?

Finally, no other function can be responsible for, perform, and meet the strategic technology requirements. Here, IT leadership is key in determining and ensuring the alignment of organization business strategies with technology strategies.

Consider the following example of Miami Jewish Health Systems operating the EMR, HR, Enterprise Content Management, and other applications operating in a cloud (SaaS) environment. The strategic planning and business case for moving to a cloud environment was completed by IT leadership, in collaboration with executive management, as were the tactical and operational aspects.

IT is uniquely positioned to provide results-oriented technology and process leadership to an organization. The future also holds enormous significance for IT, not only in healthcare, but in all industries. Let’s think about the healthcare landscape and the technology leadership requirements. For example, how will Accountable Care Organizations (ACO) function, who will plan and implement the strategic ACO technology requirements, how will cloud computing change service delivery and how will data security be impacted at all levels? These are some of the many very strategic questions that require deep IT involvement.

I believe IT can never be irrelevant. The discussion, while sensational, is moot.

These opinions are mine and do not reflect current or previous employer views.

Shubho Chatterjee, PhD, PE was formerly chief information officer of Miami Jewish Health Systems of Miami, FL.

What Tom Munnecke Is Thinking About Today

I exchanged e-mails with Tom Munnecke after mentioning his VistA-related Congressional testimony. I was fascinated with his 1998 HealthSpace concept paper and asked him if he had updated it or what he was thinking about twelve years later. Here is his reply.

My thinking now largely deals with the deeper implications of time. Here’s a talk I gave at the International Society for the Study of Time and some more in this interview from 2005 for the Pew Internet Visionaries. 

I’ve been also very interested in the physics of anticipation. As this relates to health IT: a deeper understanding of what is sometimes called the placebo effect, but in a broader sense is the self-referential feedback loop between our anticipation of the system and its net effect on us. Also, the need to support the notion of flow or state in our communication systems. 

The Web was built on a stateless protocol, but health information is very stateful, linking things over time. So, I think a "diachronic" model (flow of things over time) is a critical addition to our current "synchronic" (everybody synchronize their transactions, protocols, interfaces, and standards to current).

VistA was designed to be an evolutionary approach from the git-go. We created a "good enough" seed system, and planted it to see it grow. As I’ve learned in my studies of complex adaptive system (Stu Kauffman in particular), the most critical factor shaping evolution is the fitness function, the metric by which "survival of the fittest" is determined. 

In VistA, this fitness function was user acceptance. If people didn’t like or use a module, then it wasn’t fit and fell off the evolutionary path. The finer the granularity of these experiments and the quicker you can get a lot of feedback, the faster you can accomplish the error-making and error-correcting evolutionary process. When you try to do a $100 million centrally-planned change, you lose this graceful process and end up in front of a Senate panel asking what happened when it inevitably crashes.

I think we need to come to grips with the notion of personalization (see my 1999 "personalizing health" paper) beyond just today’s FaceBook craze. While the HHS/ONC focus is weighted to the enterprise-centric (aka the Disease Industrial Complex), turning patients into "consumers," I think we need to turn the healthcare system upside down, putting the patient at the top and the providers as supporting elements. I talked about this a bit in the Opening Chapter (co-authored with Rob Kolodner) in Person-Centered Health Records: Toward HealthePeople. 

What we are seeing now is a heroic battle between rigid, hierarchical top-down control (Blumenthal telling vendors, for example, that it is "imperative" that vendors support less insured populations) and grassroots, peer-to-peer, Net-based activities (FaceBook, Patients Like Me, Cure Together). Looking at the evolutionary fitness functions, I think that the grassroots will eventually win out, but only if the proper constraints can be applied (Tim Berners-Lee constrained the evolution of the web to TCP/IP, for example, a "good fence" that made "good neighbors").

So, I think we need to rethink health IT as a "space" rather than a "system." Perhaps people think that we can keep adding thousands of pages of legislation per year to the 125,000 we already have to end up with a "more perfect" health care system, but sooner or later we are going to have to declare a complexity crisis and admit that our intellectual paraphernalia with dealing with health care is inadequate.

It’s a bit like if Tim Berners-Lee tried to create the Web by going to the UN and asking for the UN High Commission on Innovation to create a Web subcommittee, who would then create global subcommittees and standards for specific applications. The sub-subcommittee of the high commission would meet with all the auction houses to collect all the stakeholders (Christies, Sothebys, etc) to create an integrated approach respectful of all parties and complying with all international regulations, UN regulations, etc. The very thought that Pierre Omidyar would write a simple program to auction off a broken laser pointer and turn it into eBay would be totally beyond belief 🙂

Yes, I’ve been doing a lot of thinking about the future of health and health care IT and dropping notes into my blog. Try the tags for VistA and AHLTA. You can read some of my early thinking at the bottom of this page. And here is some of my early thinking on the personal health record.

Tom Munnecke is a leading expert on healthcare IT, having been involved in the creation of both the VA’s VistA and the DoD’s CHCS and served as VP and chief scientist of SAIC. He is a consultant, entrepreneur, and board member of several health IT startups. He holds frequent workshops, salons, and networking events in a cabana at his home in Encinitas, CA.

Dreaming IT to Reality
By Ron Olsen

11-1-2010 6-10-55 PM

For years as a hospital IS manager, I had the tag-line of ‘Dream It To Reality’ in my e-mail signature. I meant that. You dream it and I, the humble IT guy, will do my best to bring it to reality.

Einstein once said, “Innovation is not the product of logical thought, although the result is tied to logical structure.” Thinking about that quote, I realized that to truly innovate, you must not necessarily think illogically, but you must think outside the sandbox you play in every day.

To meet the ever-changing needs of your organization, you have to empower your IS/IT team to approach problems from different angles — every day — and to not be afraid of failing once in a while. The logical structure is all around us, so when looking at processes, give everyone the freedom to question what you’re doing, at all levels.

With the many masters a hospital IT staff serves, what was once good enough for yesterday will never be good enough for tomorrow.

Ron Olsen is a product specialist at Access.



HIStalk Featured Sponsors

     

Currently there are "6 comments" on this Article:

  1. RE: Step toward the Cloud. Mark Moffitt has it exactly right. Cloud storage and data transmission is the way to go. eMix is the one I’m most familiar with, for radiology images and reports as well for other medical information. But there are others developing apps in related areas.

    And why HIE’s would want to commit to proprietary RDBMS and closed systems of sharing info is beyond me. It seem obvious that cloud-based solutions are much cheaper and far more flexible — especially given all the other challenges involved in creating and sustaining and HIE.

  2. A couple of significant issues seem to be left out of this discussion of cloud computing:

    1) Security and Privacy – how confident are you that your patient data will be mainted to the security standards and privacy requirements that healthcare institutions require? Rememger that HIPAA breaches are now indivdiually actionable. If the CIO makes the decision to utilize a cloud for clinical data storage, and there is a breach, who will the plainiff go after? The corporate cloud provider (cost of suing Microsoft or Google is llikely beyond the reach of most mortals!) or the one who made the decision to use the cloud?

    2) Cloud storage is cheap not only because there is lots of it, but because it is typically the lowest level of archival storage. One would be advised to have a strong SLA in place for response time–our clinicians expect sub-second response time for their clinical data retrievals, which is not likely if the data is in a cloud and there are multiple hops to get from the user to the data. And data transmission costs needed to be added into the equation.

    3) The assumption that no data schema is needed for access to clinical data is incorrect; when you are dealing with the challenges of harmonizing multiple vocabularies across medical domains, and the increasing demand for integration of genomic findings with clinical annotations, key value data stores simply aren’t adequate. And if you want to go to the next level of data discovery and analysis, which is the semantic layer, the cloud proposals discussed above fail miserably. Plopping data elements into a file is what we did 20 years ago; we should be looking ahead if we want to continue to be relevant to the field of medicine, not backwards.

  3. Lynn,

    Thanks for your long response. I appreciate the time spent on responding to the article. I have a few comments to add to your comments.

    1) Security and Privacy – how confident are you that your patient data will be maintained to the security standards and privacy requirements that healthcare institutions require? If the CIO makes the decision to utilize a cloud for clinical data storage, and there is a breach, who will the plaintiff go after?

    I’m confident that these companies run the best security of any data center – public or private. Anyone from Google, Amazon or Rackspace care to comment?

    As far as who owns the risk of a breach – that is a great question. The only way these companies will win the healthcare business is if they assume the risk of a breach. I expect these vendors will address this requirement in order to penetrate the HCIT market and will charge and profit from this added service.

    2. Cloud storage is cheap not only because there is lots of it, but because it is typically the lowest level of archival storage. One would be advised to have a strong SLA in place for response time–our clinicians expect sub-second response time for their clinical data retrievals.

    This is where a hybrid cloud comes into play. Recent data is stored locally and persisted to the cloud in the background. See the second diagram in the article. M.D. Anderson is not a typical healthcare facility and the need for prior results, especially imaging, is much greater than other organizations so cloud computing may not be a solution for your facility. However, for a more typical healthcare organization the need for prior imaging is not as great and saving money at the cost of slower access to older results may be appealing.

    3. The assumption that no data schema is needed for access to clinical data is incorrect; when you are dealing with the challenges of harmonizing multiple vocabularies across medical domains, and the increasing demand for integration of genomic findings with clinical annotations, key value data stores simply aren’t adequate.

    I am talking about data stores for sharing information, not analytics. For that you don’t need a RDBMS. In fact it is overkill. Analytics is a different story. You might not have read the first article I wrote several weeks ago on HISTalk. You can read it here:
    http://histalk2.com/2010/09/29/readers-write-93010/ – second article down. This describes a new model for thinking about HCIT data. See “three buckets.”

  4. Lynn Vogel makes excellent points about the ramifications associated with the choice to use a Cloud solution to share PHI – and this is in fact a choice. On the medical imaging side the alternatives remain CD-burning and point-to-point VPN connections.

    I can offer a couple of perspective to explore Lynn’s concerns:

    First I’d like to suggest that, at least at this time, the Cloud approach should constitute a supplemental method for data sharing, not a substitute for current clinician workflows. For 20+ years PACS solutions have done a very adequate job of image management and distribution and, as Lynn point out, clinicians have come to expect lightspeed response times from request to 1st image display.

    The Cloud approach addresses workflow challenges that are typically not addressable internally unless you throw unlimited budgeting at the problem. Patients and physicians are highly mobile, and therefore, cause workflows to be highly unpredictable. If all Providers could fit into the same IT profile, seamless image transfer would be possible without requiring a substantial investment in interface engines and customization.

    By utilizing strictly industry-accepted standards such as DICOM, HL7, CDA, SSL, TLS and various IHE profiles, a Cloud solution can easily become a common-denominator, neutral platform for image sharing regardless of a hospital’s choice of IT vendors. The “best of breed” approach historically taken by many CIOs to address their various organizational needs has essentially resulted in a colorful quilt of disparate technologies that, although individually well conceived, were never architected to play well together when thrown into the same IT infrastructure. I recently heard Jonathan Manis, Sutter CIO, refer to this as the Frankenstein approach to IT.

    So what do we do in a Meaningful Use world? We look for a unified EHR approach that favors the adoption of a neutral, central sharing point for exchange of data with institutions that are not related to one another, and do not wish to be in the business of establishing and maintaining hundreds of VPN connections. Again, the Cloud isn’t a substitute, it should be viewed as a low-cost supplement to existing infrastructure. The Cloud has a way of instantly and virtually expanding your infratructure without having to make a capital investment in that expansion – thus the PaaS model (Platform as a Service).

    As Internet access and broadband become faster, more ubiquitous and reliable, it is conceivable that Cloud solutions will essentially perform as reliably and responsively as if they belonged to your own internal Gigabit network. We are probably 3-5 years away from this.

    INFOSEC perspective: from an ARRA-HITECH perspective, new HIPAA rules regarding security breaches are clear: Providers and technology vendors are equally liable in the eye of the Law, jointly and/or severally. Even if a plaintiff ends up only going after a Provider or a vendor, neither can assume immunity. This means that the relationship between an institution and its Cloud service provider should not only involve a BAA / Infosec agreement, but the Cloud vendor should also have an titanium-clad Security policy.

    Threats and breaches can manifest themselves in a wide variety of ways, therefore the Cloud service provider’s Security policy should encompass not only any measures a Hospital CIO would expect to deploy for his/her own infrastructure, but also a whole new set of policy elements related to using the Internet rather than a private network. Even though a hospital isn’t acquiring Capital Assets, a hospital Infosec team should scrutinize the Cloud vendor’s Security policy just as thoroughly before electing to deploy their solution.

    STORAGE perspective: just like a Cloud should be considered a supplemental technology strategy, it should not be automatically considered a Cloud storage solution, unless that is a service you are specifically buying from the vendor. After all, your PACS is really meant to be your LTA. There are companies that specialize in long-term disaster recovery archiving, which is nothing more than an insurance policy everyone hopes they will never need to use.

    The Cloud should really be considered a transfer mechanism with temporary Cloud storage. Some CIOs are comfortable with keeping PHI in a Cloud for several years, and others several minutes. These are two extremes of the same spectrum, and the primary differentiating factor is whether or not the CIO has been on the wrong end of a Security Breach in the past.

    CONNECTING data: Lynn’s comment about Cloud solutions failing miserably – is there any other kind of failure? 🙂 to constructively connect disparate data is very much on point. This is why industry standards are so pivotal. The reason for this failure can be summarized in two words: unrealized potential. The concept of interoperability has been around for a long time in our industry, but how many solutions actually interoperate (affordably)? Sure, vendors generally adhere to industry standards. But they still don’t play nice with one another because, at least on the surface, the best interest of the healthcare provider is diametrically opposite that of the shareholders. More actual interoperability means less power over the customer. This is especially true of publicly-traded IT solution vendors, whose best interest is to make sure a hospital never needs to buy from anyone else.

    This traditional approach to IT sales is the antithesis of Web 2.0 possibilities. In a Web 2.0 world, solutions should not only adhere to industry standards, but also make the technology accessible and affordable to all. The Cloud essentially makes it possible for the right data to be available at the right time and in the right place to benefit the patient’s health.

    The CDA standard, in particular, shows a lot of promise – especially if deployed in a Cloud environment. By using XML-formatted document/objects with cross-referenceable content, we make sure that the clinical context of each document and report contains actionable data that are usable in other contexts. If a document is converted to a PDF, it’s individually actionable, but offers little more than burning the data to a CD: its web 2.0 value in terms of connectedness has been diminished to residual levels. However, if the same document is available in CDA format, it can now become a part of a Cloud archive and can be mined for relevant data, anonymized and cross-referenced with other findings.

    So yes, the Cloud offers some potential security and performance challenges in the short run. However, the immense benefits and potential data connectedness the Cloud offers far outweigh these initial growing pains.

  5. Florent Saint-Clair,

    Well said/written. Thank you for adding to the discussion. A discussion about cloud storage in HCIT was my only objective for writing the article.







Text Ads


RECENT COMMENTS

  1. I think Disingenuous is confused (or simply not aware of how it has been architected). How control of Epic is…

  2. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  3. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  4. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  5. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.