Roger Baker, VA CIO on Refactoring

Roger Baker, VA CIO on Refactoring

We have heard conflicting statements from Roger Baker on refactoring and reuse of legacy VistA code.

  • Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD so that we end up with a single, common electronic health record system,” Roger Baker, VA CIO said in March.
  • "The key phrase is single common electronic health system. It's two large systems, and... the intention is to get to a point where there is a single repository for all the data related to an individual' s medical record whether generated in DoD or VA, and I might add through the nationwide health information network." Roger Baker, VA CIO said in July.
  • OSEHRA now is involved in the analysis of the refactoring or restructuring of VistA into something that is more easily modified by private sector organizations. That analysis will be posted in the open source community for comment before we move forward based on it.” Roger Baker, VA CIO said in November.

As a result, we are conflicted on where to invest our energies. 1) refactoring of legacy or integration of new iEHR modules. In either case we need to integrate with the Enterprise Service Bus and iEHR data store.

See the Architecture Work Group slides with the 13 & 20 December 2011 AWG minutes (under "Documents") for presentations on refactoring by Talent and Ray Group.

VistA contains approximately 168 packages, 26,000+ routines, 12 million lines of code. As we transition to a 3-tiered interoperable EHR Services Platform architecture, the data store, GUI and EHR Services Platform will be prescribed. Plug-and-play applications can be purchased, built or refactored; what should be the goals, objectives and scope of refactoring?

Your thoughts?

 

like0

Comments

Are we enterprise-centric or patient-centric?

Tom Munnecke's picture

I have been hearing about "plug and play" health IT architectures for several decades.  This is a very appealing concept.  It would be wonderful if we could take a system as large and complex as a local or nationwide EHR, buy or build "best of breed" components, and then plug them in for a smoothly functioning system.

My experience, however, has been that these approaches have not worked.  It wasn't due to lack of funds, smart people, or enough resources.  It was due to underestimating the overwhelming complexity of what goes on in a hospital - which Peter Drucker calls the most complex organization in our society.

Imagine someone trying to see you the world's best car by offering the engine of a Corvette, the transmission of a Ferrari, the seats of a Rolls Royce, and the chassis of a Porsche.  He dumps the parts on your driveway, saying, "All it takes is a bit of integration. And we've made it simple for you because we've standardized on metric nuts and bolts, so all the parts will fit together.  For the non-metric components, we've included adapters so that SAE parts will bolt on to metric fittings."

For each pair-wise integration effort, things don't appear too difficult.  You could build an adapter to connect the Corvette engine to the Ferrari Transmission.  And with some brutal work with a cutting torch, you could probably fit the Rolls Royce seats into a Porsche body.  But integrating the integrated drive train to the integrated seat/chassis components is probably an impossible task.

In other words, the system in-the-small is much different than the system in-the-large.  Even if we get two components to work together, we have no guarantee that larger assemblies are going to fit together.  And, we have no way whatsoever of assuring that the whole assembly will end up a drivable car.

Scientists use a phrase "Extradordinary claims require extraordinary proof."  An integrated VA/DoD electronic health record system is an extraordinary system - the largest health IT system ever proposed, and perhaps the largest scale software development project ever attempted in the Federal government.  There have been many massive failures in large scale health IT: 

On the other hand, VistA was designed from its early days to be an integrated system.  I liked to say it was integrated by viture of "not disintegrating."  We tried to make it easier to use the integrated approach - what I called "creating a path of least resistance." It was a co-evolutionary process intertwining feedback loop between users, metadata, software developers, and clinical practices.  In today's terms, this approach could be called agile development, evolutionary design, communities of practice, learning communities, and open systems development.

If you talk to any physicians under the age of 45, they are likely to have used VistA during their residency, as all US residents rotate through a VA hospital.  If you ask them what they thought about VistA, they will likely comment on something to the effect that it was "integrated," that the information they needed was "at their finger tips,"  or that it was designed by "folks who understood medicine."  They don't talk about any particular package, but rather the level of integration they found at the clinical level.

VistA has also integrated itself into the larger whole of clinical practice.  In Meaningful Use and Beyond, Trotter and Uhlman talk about VistA's role in saving lives of VA patients: 

 

“years before the healthcare profession as a whole was aware of the dangers of Vioxx, the VA discovered on its own that it was a dangerous medication. Data from the VA’s electronic healthcare record, VistA, had alerted the VA that something was amiss with Vioxx. The VA took steps to ensure that Vioxx was prescribed only with careful monitoring and only in special circumstances, a drug of last resort. By doing so, the VA saved thousands of lives.

 

This is an amazing but underappreciated accomplishment.  Thousands of lives are lost in a terrorist attack cause global repercussions, yet thousands of lives saved through intelligent integration of information and clinicians is all but ignored.  (Here is a video interview of Washington VAMC Chief of Staff Ross Fletcher, MD, talking about the way that VistA has changed clinical practice in the VA.)

I noticed early in my career at the VA that no matter where I went in the organization chart, folks wanted things decentralized above them and centralized below them.  Given the computer power and communication capabilities of the era, we settled on the hospital as the focal point for centralization.

Today, whether we like it or not, we are looking at personalized medicine, personal genomics, nanotech, personal health records, quantified self, Health 2.0, social networks, Twitter, cloud architectures, and ubiquitous computing.

It seems to me that this all dictates that we move the slider towards the patient-centered end of the spectrum.

VistA's patient-centric perspective was key to its success.  It has saved lives, won clinical acceptance, and changed the way that VA practices medicine.

I think it essential that we maintain a patient-centric approach, serving as a platform for enterprise-centric activities.  

 

like0

What's Down the Road?

Russell Davis's picture

Technology is moving in many directions simultaneously. In the past, the big bang theory applied to developing complex systems was the norm. In contrast, we are now exposed to thousands of apps that can load onto small devices. A challenge going forward is how best to utilize advances. Consider the pre-IPv4 days when some there were multiple networking protocols. Does anyone recall windows for Workgroups or the Novell products? What happened was a slow progression to a standard exchange protocol. There were side effects such as the lack of security (not unlike early versions of HL7 or SCADA). Nevertheless, today we are reliant on IPv4 (and IPv6).

Just as IPv4/IPv6 is not a complete solution, how effectively software integrates in will be an important metric. With the current MUMPS code posted, any person or company now has information to improve on the current processes. Due to the potential heterogeneity of potential products, there will be some significant challenges ahead. And, as we dive deeper into SOA approaches we are going to uncover new issues that will require improved interoperability specifications and definitions. For these reasons, the architecture foundation is a keystone for the path forward.

Happy New Year – Russell Davis, D.Sc.

like0

Refactor Legacy or New Modules- Options A/B/C

Tony Shannon's picture

Refactor Legacy or New Modules- Options A/B/C

 

Thanks Steve, Tom,

 

This post and reply raise deep questions that have international informatics relevance…

 

*Refactoring of legacy or integration of new modules*

 

The point has been well made that hospitals are amongst the most complex organisations in society. Most all of us working to tackle and improve the complexities of the healthcare system have to tackle legacy systems (in the broadest sense of the siloed people, process, information, technology systems). Few of us have the luxury of “greenfield” site development.

 

Tom has already had a huge impact on eHealth with the tried and tested, ie proven Vista approach. Bravely he is embracing a refactoring of Vista, directing the effort towards user centred design, agile development approach and a core patient centred kernel to be at the heart of development, which I also agree with.

 

There may be some gap between these approaches to legacy integration or new build but it must be tackled;

 

 

Options for moving forward in eHealth

 

I often use this diagram to illustrate the challenge for many of us outside the VA, with A B and C options.

 

A - the status quo in many healthcare systems, many disparate teams, with disparate views of their healthcare processes, using disparate proprietary technology that does not easily integrate or interoperate

 

B - a middle ground, whereby one integrates legacy and moves incrementally towards improved SOA (towards an enterprise wide, modular, open standards based EHR system) via portal & ESB approaches.

 

C - current enterprise wide EHR systems (Vista 1.0, Epic etc)

In the future this may represent the open source, modular, open standards based SOA that Vista 2.0 or iEHR has the potential to offer.

 

 

Tackling legacy- we need to bring some key folk with us.

 

I’m an outsider so am guessing here, but if the VA/DOD have a legacy environment anything like where I am (we have 200+ legacy clinical systems within our healthcare organisation) then needs to move from A to C via the middle ground B (portal & ESB approach).

So for most of us an Integration/ESB is a useful thing. While I accept Toms point that true plug  n play interoperability is v hard to achieve via this route, at least key legacy data and information can be ported into the new world this way. So legacy data can be catered for and reused rather than ripped out.

 

Towards future proof, care oriented, EHR architecture = new modular approach required

 

When refactoring the enterprise wide Holy Grail (e.g. Vista 2.0) as Tom suggests the heart/core of any new system should be a patient centric kernel.

 

When I explore the current Vista architecture with over 100+ clinical modules, I note they are independently factored, yet have been a great success.

However they do explain the “complicated” nature of the vista architecture, with significant room for improvement in any refactoring. My view is that to crack and improve this, one needs to seek and see those few common patterns that underpin all healthcare.

*This is a key point worth highlighting*

On the assumption that this change journey is about healthcare improvement, parallel healthcare improvement methods in healthcare (e.g. lean) could/should be more effective if the service oriented architecture that underpins a healthcare IT system directly supports the key core generic processes of physician - patient interaction that underpin healthcare.

The patterns that I particularly suggest worth a focus are those generic processes of healthcare (so suggest the terms observations, evaluations, instructions, actions that underpin the generic cycle of healthcare, etc.

 

The challenge thereafter is what technical architecture is needed to support this move forward?

 

If building the patient centric platform of the future, I’d suggest a closer look at openEHR. The approach that underpins this international effort is based on the core clinical process cycle mentioned (Observations, Evaluations, Instructions, Actions) and to very simply explain its “two-level modelling” approach splits information system building into generic archetypes that can be reused (e.g. Blood Pressure measurement, EKG record) and specific templates which can be specified for specific use cases (e.g. Emergency Medicine). The lego brick and lego toys analogy is often used.

http://frectal.wordpress.com/book/healthcare-change-the-way-forward/healthcare-chasing-the-right-fit-between-process-and-it/

 

http://frectal.wordpress.com/book/healthcare-change-the-way-forward/healthcare-openehr%e2%80%99s-potential-to-handle-complexity-diversity/

 

(Of note the recent CIMI group led by Stan Huff, with reps from many key players including the VA, have recently agreed to further explore openEHR)

http://www.openehr.org/326-OE.html?branch=1&language=1

 

 

The long road. moving from legacy, via integration, towards the ideal SOA

My current informatics work in England is based on these principles. We are building an open source clinical portal, using an integration engine, working towards leveraging some key legacy systems, at the early stages of exploring how to use archetypes within a new SOA, in an incremental, user centred fashion.

http://frectal.com/2011/10/21/leeds-takes-a-lead/

 

When exploring the VA DOD plans I see the same principles applied within the iEHR outline plans. My sense is that the iEHR portal + ESB should help leverage the best of legacy systems, 0 while affording an opportunity for user centred agile development of Vista 2.0 elements required?

https://www.fbo.gov/?s=opportunity&mode=form&id=dbeae122c0e8787c94c96b94925c1fd4&tab=core&_cview=0

 

 

In reply to your questions my sense is we all seek;

 

Goals: Higher Quality. Safer, Faster Health IT Platform,

Easier to scale and maintain.

 

Objectives:

Integrate key legacy data (not 100%) via portal & ESB

            Develop new iEHR via modular approach  based on top 5/10 core clinical processes

            Agile & User Centred Development to review and improve those 10

            Reiterate that loop continually

 

Scope: e.g. start the journey of new modules/refactoring

            Admission to Hospital and

            Discharge from Hospital

 

Hope that helps

 

Tony

 

Dr Tony Shannon

Consultant in Emergency Medicine, Leeds Teaching Hospitals

Clinical Lead for Informatics, Leeds Teaching Hospitals

Honorary Research Fellow, University College London

www.frectal.com

 

like0

Lessons learned from the NHS Health IT fiasco

Tom Munnecke's picture

 

Thanks, Tony... There are many, many, layers of issues to deal with - one of which is the engineering issues of things like SOA, scalability, etc.   But a broader issue is the relationship between IT, users, and medical care. I spent some time reading up on the history of the NHS' efforts with the National Program for IT (NPfIT), and was amazed at the familiarity of the issues - and the relevance to the OSEHRA efforts today.  The most ominous relevance of the NHS fiasco to the OSEHRA architecture is the repeated assessment that a major reason for the NHS is that it ignored its users.  Direct, continuous, and intense user involvement was the hallmark of the early VistA development.  I liked to quote "Success has many parents, but failures are an orphan."  So we tried to get as many "parents" involved in the design and "evangelization" of the system.... to this day, there are thousands of people who feel that they were one of the "parents" of VistA.  NHS had a team of 23 academic critics of the NHS effort.  Rather than pulling that intellectual energy into improving the system, they were reduced to outsiders, only able to throw criticism at the effort.  Imagine if all that intellectual horsepower of that team were directed to improving the NHS system.  My general reaction to reading the NHS history: VistA has already crossed most of the hurdles that NHS was trying to overcome.  Docs are using it to save lives; it has 25 years of clinical data available; it has scaled; it is secure; it is integrated.  So, why aren't we using lessons learned from VistA as the foundation for the next generation?  Here are some clips relating to the NHS history:  http://news.bbc.co.uk/1/hi/health/7839235.stm   "No matter how routine the operation, learning that you need surgery is an unsettling and pivotal moment in anyone's life and requires confidence in the abilities of those caring for you. A much underestimated and unmeasured factor in healthcare in this country is the importance of the rapport that develops between doctor and patient. This trust is now being eroded by a system that has reduced healthcare to a factory production line where over-reliance on numerical targets and computerisation has broken down care into a series of procedures. I believe this is driving a wedge between patients and doctors in a way that is becoming detrimental to patient care."   http://www.computerweekly.com/feature/NHS-Focus-Open-Letter-Questions-that-need-to-be-answered
The NHS Confederation has said, "The IT changes being proposed are individually technically feasible but they have not been integrated, so as to provide comprehensive solutions, anywhere else in the world."  http://www.e-healthinsider.com/News/4219/assist_says_idea_nhs_like_a_bank_%27fundamentally_flawed%27  "NHS informatics professional body ASSIST has published a paper saying the original NHS National Programme for IT plan based on a one size fits all "does not work". The paper says attempting to treat the NHS as if it were a bank failed to understand the structure and characteristics of the health service. ASSIST says there has been too much focus on standardisation of systems rather than standards. Thepaper says both national and local systems have a role to play but cannot succeed if they are imposed.   http://computerworld.co.nz/news.nsf/news/12022EA9678822A0CC2574110076BC3E  . . . Almost everywhere that health executives or authorities have pursued the goal of integrated electronic healthcare the dream has fallen well short of reality — and usually cost a bucket of money along the way. Most prominently right now, there is the UK National Health Service’s NPfIT (National Programme for IT) project, which has redefined the term “project failure”. So many things have gone wrong with this project that it is hard to enumerate them quickly, but, like our 1990s Police INCIS project, it was based on the wrong technology, and that’s never a good place to start. NPfIT was based on a technology that hadn’t been fully developed, iSoft’s elusive Lorenzo, while INCIS was based on one — IBM’s OS2 – that was shortly to be discontinued, despite IBM’s insistence to the contrary. . .  http://www.computerweekly.com/Articles/2009/04/29/235849/no-npfit-black-box-to-be-found.htm  "If the NHS IT scheme, the NPfIT, were a jumbo jet, its frequent crashes would have put fear-of-flying courses out of business. But because the NPfIT is not an aircraft crash, there is no wreckage. The damage is not visible. The Trust's undiagnosed, sick, or injured patients have been on a hidden waiting list, lost in the systems. As delays in their treatments are below the perception of the general public they don't seem to matter. The disorder we've highlighted this week at Barts and The London NHS Trust, a year after it went live with the NPfIT Cerner Millennium Care Records Service, is the most serious problem to afflict the national programme. The trust's managers are uncertain who among their patients have gone untreated within the government's 18-week target. They have been trying to reduce a waiting list of more than 2,100 patients on their 18-week waiting list. Some of the trust's patients have been discovered months after they should have been treated. When patients go untreated they are likely to get worse. Some might now be seriously ill because of the delays. We don't know. Worse, Barts does not know. Fortunately the NPfIT is not an aircraft crash. So there is nothing unsightly for the the TV cameras to broadcast across the world; there is no public clamour for information; no demand for the common causes of all the crashes to be quickly established.   http://www.guardian.co.uk/technology/2009/aug/12/nhs-computerisation-independent-report  As the song goes, a man hears what he wants to hear and disregards the rest. Of all the indictments in the Conservative-sponsored independent review of the NHS's £12bn computerisation programme, the most damning may be its account of the way that the programme's originators wilfully disregarded painfully acquired wisdom. The new study, led by the healthcare informatics veteran Dr Glyn Hayes, observes that the National Programme for IT followed closely on the heels of two important reports. The first was on a series of IT pilot projects at 19 NHS demonstrator sites between 2000 and 2003. That programme, called ERDIP, tested the technical and ethical boundaries of creating community scale electronic health records. You would have expected the national programme to absorb and build on this work, rather as the Apollo moon programme learned from the Gemini programme about manoeuvring spacecraft in orbit. Instead, ERDIP was airbrushed from history. The independent review finds it "extraordinary that the ERDIP recommendations were largely ignored". The reason, of course, was that the ERDIP findings were inconvenient. The evaluations stressed the need for closely involving system users - and patients - in the design of electronic records, and for introducing IT as part of improvements to patient care, not as an end in itself. This implied that the national programme's massive scale and gung-ho timetable were unrealistic...The NHS could dismiss inconvenient criticisms and, in the national programme's early years, it was doing its best to control the flow of information about its IT projects. Executives deployed "commercial confidentiality", misleading press releases (including one covertly modified after publication) and even the threat of legal action to deter critics.   http://www.publictechnology.net/modules.php?op=modload&name=News&file=article&sid=22108  Once proudly spoken of by Prime Minister Tony Blair as the biggest civil IT project in the world, NPfIT has come to represent all that is wrong with public sector computing. The errors and mistakes pile up one by one: from the dark days of former CIO Richard Granger taunting suppliers to metaphorically 'come and have a go if you think you're hard enough' through the shocking fact that the Lorenzo care records have only 174 regular users to the Kafka-esque defence from Whitehall that the project is well under its £12.7 billion budget, but only because it's so far behind schedule that payments haven't had to be made to suppliers!   http://www.e-health-insider.com/news/5865/rotherham:_npfit_has_put_us_back_10_yrs  The chief executive of The Rotherham NHS Foundation Trust has said the National Programme for IT in the NHS has "put back the contribution of IT in the NHS by more than ten years." In a controversial speech at the Health Informatics Congress 2010 in Birmingham, Brian James renamed the programme "NFFPIT - Not Fit for Purpose IT." He also said it had "not only impacted on systems within healthcare but also on the skills of the IT profession to scope and manage projects." Last year, The Rotherham became one of the first NHS trusts to go outside the national programme for an electronic patient record programme. It rejected iSoft's Lorenzo system from CSC and instead decided to implement a £40m Meditech v6.0 system from FileTek.   (Tom's Note:  Meditech is a company started by Neil Pappalardo, the original designer of MUMPS, who created a proprietary version called MIIS, which eventually became internal-only to Meditech.  I wrote my first hospital information system in MIIS)  http://www.telegraph.co.uk/opinion/main.jhtml?xml=/opinion/2007/04/17/do1702.xml  “. . . The project is costing more than £12 billion, enough to pay for 60,000 nurses for 10 years, or for Britain’s participation in Iraq and Afghanistan twice over. . . By now, almost every hospital in England is supposed to have key administrative software deployed as the essential first step in introducing the shiny new electronic patient record. They are miles behind schedule, yet the limited deployment has already caused havoc, with significant delays in providing inoculations to children, waiting list breaches, missing patient records and the inability to report activity statistics. Not to mention the trifling matter of the largest computer crash in NHS history, when 80 hospitals had no access to patient administration systems for four days. This is a truly grim tale. More than £2 billion has been spent, and although there is no detailed record of overall expenditure on the programme, estimates of its total cost have ranged from £6.2 billion up to £20 billion. There have been six bosses in five years. Timetables are fictitious and the programme is now years behind. Doctors, nurses and hospital managers have been left spitting with rage.  http://www.bmj.com/cgi/content/full/326/7394/860407  “Enormous investment has gone into computerised hospital information systems worldwide. The estimated costs for each large hospital are about $50m (£33m), yet the overall benefits and costs of hospital information systems have rarely been assessed. When systems are evaluated, about three quarters are considered to have failed, and there is no evidence that they improve the productivity of health professionals. To generate information that is useful to decision makers, evaluations of hospital information systems need to be multidimensional, covering many aspects beyond technical functionality. A major new information and communication technology initiative in South Africa gave us the opportunity to evaluate the introduction of computerisation into a new environment. We describe how the project and its evaluation were set up and examine where the project went wrong. The lessons learnt are applicable to the installation of all hospital information systems.”   http://www.e-health-insider.com/news/item.cfm?ID=2854  “The departing head of the NHS IT programme Richard Granger has said he is ashamed of the quality of some of the systems put into the NHS by Connecting for Health suppliers, singling Cerner out for criticism. Going further than he before in acknowledging the extent of failings of systems provided to some parts of the NHS - such as Milton Keynes – the Connecting for Health boss, said “Sometimes we put in stuff that I’m just ashamed of. Some of the stuff that Cerner has put in recently is appalling.” He said a key reason for the failings of systems provided was that Cerner and prime contractor Fujitsu had not listened to end users. “It really isn’t usable because they have building a system with Fujitsu without listening to what end users want.  Mr Leigh said the project was turning into "one of the biggest IT disasters of all time" and the only solution was for it to be broken up into smaller, more manageable chunks.  http://www.telegraph.co.uk/news/uknews/1548813/Patients-wont-benefit-from-12bn-IT-project.html  http://www.publications.parliament.uk/pa/cm200607/cmselect/cmpubacc/390/39004.htm  Q267  Chairman: Did you say: "What we are trying to do is run an enormous programme with the techniques that we are absolutely familiar with for running small projects. And it isn't working. And it isn't going to work"?  This programme is on a scale beyond anything attempted before and I believe, therefore, requires some innovative thinking and some of the best minds to be applied in terms of structuring it so that it can succeed over the long-term. It is naive to assume, in my view, that because something may go well in the early stages when things are relatively simple, crossing the foothills, if you like, as you start to climb what is going to be an enormous mountain that those techniques will still work. Therefore, I believe this needs to be carefully thought out. If I may use another analogy, and it is one I used in the conference, it makes the point better than a thousand words could. It was when Boeing sought to replace the 707 in the late 1950s with a new aeroplane, they realised very early on that scaling it up to be a jumbo jet would not work because it would never take off, it would be too heavy. They had to go back to first principles and ask what is it that makes an aeroplane fly. Consequently, the 747 was a totally new design, totally different, but it works, of course, and it is highly successful. I believe we are in a situation where we need to be looking at the programme in that kind of light: what is it going to take in terms of project management techniques, in terms of vision and leadership, to actually make this work over the ten-year life of the programme. I do not think we are asking those questions yet.  

Q275  Chairman: We are not asking those questions. Finally, before I pass to colleagues, you said: "There is a belief that the National Programme is somehow going to propel transformation in the NHS simply by delivering an IT system. Nothing can be further from the truth. A vacuum, a chasm, is opening up. It was always there". Do you believe that?

 

Q341  Mr Williams: You said it should not be IT-driven. Is it, and why should it not?

 

  Mr Rollerson: The history of the IT projects is that typically where they are left to an IT department they fail. The reason they fail is because the people who are expected to use the application in the end have not been engaged. I suppose, if I may turn it the other way around and talk about best practice in this case, best practice in the commercial world for many, many years has been that a business need is identified, the business solution is described and only part of that business solution will be technology. There will be restructuring, retraining, all sorts of things, redesigning of processes in order to deliver the business solution. The technology will then be delivered as part of that solution. The danger that I foresee in this situation is that we will be heading too far in the other direction, that the driver, if we are not careful, will become the technology itself.

 

 
like0

formatting problem

Tom Munnecke's picture

my apologies for the formatting problems on the above post... it seems to have lost many of my line breaks and web links... 

like0

Have moved on from that ..

Tony Shannon's picture

Thanks Tom,

I am most familiar with the failures of the NHS National Programme for IT, having spent 5 years as a clinician within, trying to effect change.

I wont repeat many of the points you have made from the report, but the bottom line is that I left it 2 years ago to progress an open standards, open source agenda, inc back in my own hospital base (our own OS portal efforts have nothing to do with the formal NPfIT project, though based in the same city, Leeds..)

Some may be particularly interesting in some related posts I've done since leaving.

http://frectal.com/book/

http://frectal.com/book/healthcare-change-the-way-forward/

http://frectal.com/book/healthcare-change-the-way-forward/healthcare-change-why-%e2%80%9copen-source%e2%80%9d-is-part-of-the-recipe/

The key lessons for me were;

Complex systems, this is an ecosystem we are tackling not a machine

The key elements within are ; People, Process, Information, Technology, Standards & Value

+There is an important  gap between;

-the health IT market (with some vendors quite happy with their proprietary lockin approach thank you)

-the health IT standards field (too many players, not enough collaboration between)

-frontline innovators who want to develop fast, scalable,maintainable solutions and share the lessons of their work, as medics do

Which is why agile, iterative, user centred, clinical process oriented, open source developments are needed in healthcare and the VAs leadership on that is welcome+

The question for me back to you is what do you feel OSEHRa needs to learn from the NHS lessons you have read..

i.e. is it not using agile and user centred approaches?  

 

like0

Clarification?

Carol Monahan's picture

Dr. Shannon, 

I would suggest digging a little deeper into the current systems that VA and DOD have, since I believe that the situation is very different from the one you are confronting in the UK.

You said, "I’m an outsider so am guessing here, but if the VA/DOD have a legacy environment anything like where I am (we have 200+ legacy clinical systems within our healthcare organisation) then needs to move from A to C via the middle ground B (portal & ESB approach)." In our case, both VA and DOD have (mostly) C systems - VA has VISTA, and DOD has AHLTA (each with a certain amount of additional peripheral systems). Both VISTA and AHLTA are even developments from the same common architectural base. In essence, the iEHR concept is an attempt to move from 2 "C" solutions to a joint "A" solution, where a whole host of disparate software elements will be bolted together, with a common communications layer. 

Unfortunately, despite the basic solidity of VISTA, there is a prevailing ideology that the offerings of private-sector providers are always preferable to "home grown" government solutions, and thus there has been a multi-decade push to outsource government software acquisition. This has led to many expensive attempts to buy closed-source wholesale replacements or upgrades, none of which has been successful. Meanwhile, VISTA has plugged along, making incremental progress, but nothing like the innovation it produced during the (fairly brief) period when it was the fully-supported, preferred solution. The move to open-source could herald a new age of real innovation, but only if it does not simply take old documents that said "commercial off-the-shelf" and do a find-and-replace with "open source". Instead we should be opening up communication between all of the current government programmers with their open-source colleagues, in order to unleash the potential within those organizations to innovate - which is significant.

From a technical perspective, it's important to know that VISTA is a system that has internal tight integration - there is no "clean" separation between code and data - and that is part of its strength. The creation, use, change, or deletion of any element in the system can trigger events in any other part of the system, as requested by the users, and indeed sometimes programmed by trained users. The system is robust and accessible enough that minor changes can be made outside of the IT department. The organic nature of this essentially hybrid database system (it can act as either relational or object-oriented) gives it a real advantage in modeling human decision paths. That is the source of the words of caution being raised about trying to treat is as some sort of "outdated" "legacy" flat data-store that other outside programs will simply "access" or "interface with". 

VISTA already supports "The Best Care Anywhere". Yes, it can be better tended, extended, improved. But trying to radically change it - without taking into account what it currently accomplishes, and how - seems a poor approach. 

like0

Correction?

Peter Li's picture

Rather than a joint "A" solution, the iEHR with the Enterprise Service Bus and iEHR data store is more of a joint "B" solution - allowing legacy systems, i.e., current VistA and AHLTA to coexist with iEHR during a transition period.

like0

thanks

Tony Shannon's picture

Thanks Peter

Thats what I had understood from what I had read and seen

Have posted related questions to Carol

Tony

like0

some questions about the move

Tony Shannon's picture

Thanks Carol

(So sorry for delayed reply, Been trying to , but this site has been v slow to get around the last week, some server issue at osehra?).

Appreciate your clarification, you're quite right to point those out, my A to B to C suggestion (See my comment above) was very simplistic, for the sake of discussion.

Your helpful reply raises more questions which I hope might be helpful to probe with.. 
If I then assume that Vista and AHLTA are both effectively C systems already raises several interesting questions;

If Vista & AHLTA share some elements of a common architectural base as you say...I'm assuming they have grown far enough apart that they are now seen as two distinct and seperate architectures?

If they are seen as the same coherent architecture then I assume there the joint VA-DOD iEHR project would not be needed?

 

You're absolutely right to suggest a move towards a joint A solution with multiple commercial off the shelf solutions would be pretty backward step... you would lose the "conceptual integrity" within the architecture that you currently have in Vista for a start.

Furthermore there is no doubt that there must be merit in the MUMPS language from what you say and what I've heard and the limited reading I've done on it. Vista and EPIC being based on it must tell a story.. So I have no issue with suggesting MUMPS should/should not be used.

 

I would suggest that the Legacy to Leadership paper for the VA surely was a line in the sand to say, for all the merits of the current Vista stack there are constraints and these need significant change? refactoring ?

If so then surely at some time , old Vista data can be treated as legacy? ie accessed via an ESB?

Then, regardless of the MUMPS debate, it surely is time for a fresh look at key elements of the architecture.  Again I'd suggest not having any thing like the two level modelling of the archetype/template approach I mentioned from openEHR strikes me as an important gap in the current Vista stack, as one example.

 

Perhaps my interest is more representative of those outside the VA/DOD who are interested in the potential of OSEHRA.

Well outside of the UK, within the US, I'm sure there is a wide diversity of A (chaos of disconnected) type scenarios in the US. I came across these 2 interesting articles on this subject in the last week.

http://www.practicefusion.com/ehrbloggers/2012/01/the-myth-of-hospital-ehr-integration.html

 "Of most urgency, though, is the desire to connect a clinician with the local hospital. And, of all of the integrations, this one is the most difficult."

http://hitexchangemedia.com/articles/janfeb-2012/still-craving-paper/

"Practitioners frustrated by a disparate array of software interfaces are stalling the transition to electronic health records. Blame the lack of cooperation between vendors—and the reluctance of C(EO/CIO)-level leadership to drive process change."

 

So on two counts my sense is many of us are working towards a B approach.

If you work in A type land, you need to go via B on any journey towards C, otherwise your into big bang , rip and replace territory.

If the VA-DOD are both in C land, unless they decide to stick with one of those Cs eg Vista and make no changes, they need to also move together via a middle ground ie B?... albeit via an innovative open source and agile route. 

Thanks for help with the discussion on this. Hope its useful to others too.

Tony

 

 

 

 

 

like0

refactoring

Robert Sax's picture

 I think that you should refactor the legacy code to provide a solid and consistent foundation for the iEHR modules to utilize. Refactoring should focus on:

* Separate business logic from data and from interface logic. This will allow the iEHR module to utilize business logic without issues related to interspersed display logic.

* Build the most performant/scalable solution possible at the business/data layer in a manner that is optimized for servicing read and update requests. This will be greatly helped by unit testing capabilities.

* Document business logic within the code. The lack of documentation makes it very difficult to build test cases.

* Build automated test support. Build infrastructure that allows for easy development and execution of automated tests. Make automated tests a core part of the development cycle.

 

like0

I agree with you about

Carol Monahan's picture

I agree with you about separating the business logic from the interface logic: it is very desirable (and completely feasible) to make it so that changes to interface needs do not require retooling of the underlying system.

I also agree about increasing in-line documentation.

However, as VISTA folks have been pointing out, in a mature complex system where there is - purposefully - no clear distinction between "data" and "code", attempting to separate out the business rules from the data is much like trying to separate the nervous system from the rest of the body. It would be very clean and tidy to have the nervous system in one box and the organs and structures in another, but you would lose more than a little in the process. VISTA derives its power from being strongly horizontally-integrated - every part of an instance has the ability to sustain linkage to any other part - no matter in which "modules" the data or processes reside. This creates a highly-adaptable network of support for the best current clinical practice. If creation, initation, change or deletion of a particular data point needs to trigger action elsewhere, that behavior will be inherent in the datastructure, and it may be either an outward "push" by the part of the system that owns the data, or it may be a "pull" - a subscription from another part. It is an elegant and incredibly efficient methodology, and incompatible with models which call for isolating data from process. 

Your point about optimizing for "read and update" requests implies a flat-data store, as if for a relational system. Such optimization makes little sense in a more object-oriented linked-data environment.

Also, we should be wary of being too reliant on automated testing, which will only tell us if each small part of the code is "correct". What we want to know is if the code does what we intended it to do, and whether it interacts with the ecosystem appropriately. These are better served by concentrating on troubleshooting and improving readability.

like0

Roger Baker, VA CIO on Refactoring

Peter Groen's picture

Aside - Several of us have been commenting on the slowness and related issues for months and haven't seen much improvement, unfortunately. I cut back by use of the site significantly, as a result. It's kind of a minimal requirement that needs to be fixed for good. I don't like to air dirty linen. The tech staff have said it was probably something wrong with my system - though I've not had any problem with any other system on the web at all. I don't like that type of response.

-----Original Message-----
From: tonyshannon <tony.shannon@frectal.com>
To: Architecture <architecture@groups.osehra.org>
Sent: Tue, Jan 10, 2012 10:16 am
Subject: Re: [architecture] Roger Baker, VA CIO on Refactoring

Thanks Carol
(So sorry for delayed reply, Been trying to , but this site has been v slow to get around the last week, some server issue at osehra?).
Appreciate your clarification, you're quite right to point those out, my A to B to C suggestion (See my comment above) was very simplistic, for the sake of discussion.
Your helpful reply raises more questions which I hope might be helpful to probe with..
If I then assume that Vista and AHLTA are both effectively C systems already raises several interesting questions;
If Vista & AHLTA share some elements of a common architectural base as you say...I'm assuming they have grown far enough apart that they are now seen as two distinct and seperate architectures?
If they are seen as the same coherent architecture then I assume there the joint VA-DOD iEHR project would not be needed?

You're absolutely right to suggest a move towards a joint A solution with multiple commercial off the shelf solutions would be pretty backward step... you would lose the "conceptual integrity" within the architecture that you currently have in Vista for a start.
Furthermore there is no doubt that there must be merit in the MUMPS language from what you say and what I've heard and the limited reading I've done on it. Vista and EPIC being based on it must tell a story.. So I have no issue with suggesting MUMPS should/should not be used.

I would suggest that the Legacy to Leadership paper for the VA surely was a line in the sand to say, for all the merits of the current Vista stack there are constraints and these need significant change? refactoring ?
If so then surely at some time , old Vista data can be treated as legacy? ie accessed via an ESB?
Then, regardless of the MUMPS debate, it surely is time for a fresh look at key elements of the architecture. Again I'd suggest not having any thing like the two level modelling of the archetype/template approach I mentioned from openEHR strikes me as an important gap in the current Vista stack, as one example.

Perhaps my interest is more representative of those outside the VA/DOD who are interested in the potential of OSEHRA.
Well outside of the UK, within the US, I'm sure there is a wide diversity of A (chaos of disconnected) type scenarios in the US. I came across these 2 interesting articles on this subject in the last week.
http://www.practicefusion.com/ehrbloggers/2012/01/the-myth-of-hospital-e...
Of most urgency, though, is the desire to connect a clinician with the local hospital. And, of all of the integrations, this one is the most difficult.
http://hitexchangemedia.com/articles/janfeb-2012/still-craving-paper/
"Practitioners frustrated by a disparate array of software interfaces are stalling the transition to electronic health records. Blame the lack of cooperation between vendors—and the reluctance of C(EO/CIO)-level leadership to drive process change."

So on two counts my sense is many of us are working towards a B approach.
If you work in A type land, you need to go via B on any journey towards C, otherwise your into big bang , rip and replace territory.
If the VA-DOD are both in C land, unless they decide to stick with one of those Cs eg Vista and make no changes, they need to also move together via a middle ground ie B?... albeit via an innovative open source and agile route.
Thanks for help with the discussion on this. Hope its useful to others too.
Tony

--
Full post: http://www.osehra.org/discussion/roger-baker-va-cio-refactoring
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/410

like0

Agree there must be an osehra.org server issue

Tony Shannon's picture

Agree Peter

The problem is not with your machine or mine.
The issue is with the osehra site.. the only one I've had problems within online of late..
Needs sorting.

Tony

like0

ditto on the performance problem

Tom Munnecke's picture

it is agonizingly slow for me, as well...

and can we lose the Capta when posting a reply?  We're already signed in...

and can we fix the problem that clicking on help while editing a document clobbers the document in progress?

like0

Web Site performance

Conrad Clyburn's picture
Conrad Clyburn's picture

Submitted by Conrad Clyburn(378)

Contributor

January 12, 2012 - 18:58

Dear Tom, Pete, VistCarol and OSEHRA Members at Large,

As you are aware, a number of members have noted that the web site performance has been unacceptably slow, and that over the last few days it seems to be getting slower. 

We too have noted this problem, and are taking steps to isolate it, identify its cause and correct it.

As you may be aware, OSEHRA is built upon the Drupal open source content management platform.  The platform is maintained and developed by a large community of international users and developers.  So we are not only attempting to resolve the issue within our own internal resources, but are also reaching out to the Drupal open source community to improve the user experience.

As a community we will keep you informed.  We appreciate your continued support and interest in OSEHRA and hope to have this problem resolved soon, so we can focus our efforts on the serious business of improving the Open EHR.

Thank you in advance for your patience,

Conrad ClyburnCommunity DevelopmentOSEHRA (Open Source EHR Agent), Inc.clyburnc@osehra.org(571) 858-3205(301) 404-9128 (cell)

 

like0