Enterprise Architecture

I do think that for countries to harmonise their systems, they need to define how the system should be and the interactive relationships; That is all about a system enterprise architeture (pictoral view) including the what is it/information? when should the data/information be required/collected? who should collect what? and HOw? (Just use the five wives and one husband principle).

an enterprise architecture should be discussed and agreed upon by all stakeholders but under the leadership of government; This will help good data governance structure be build and exchange the information;

Pepela Wanjala: Health information specialist MOH/ Kenya

I like to think of Enterprise Architecture as a blueprint for the health information system. You wouldn’t build your house without a blueprint, and you shouldn’t build your HIS without one either. I must confess that I find some of the language around EA to be opaque. I took and would recommend a course on The Open Group Architecture Framework (TOGAF) which really helped me to understand EA better.

To me, “Enterprise” just means that it’s holistic, you are talking about all the health information systems and data and the vision is big enough to accommodate the scale you want to achieve, i.e. the whole country with room to grow.

“Architecture” just means how it is put together. So the “Enterprise Architecture” is the blueprint, or plan, for putting together the health information system that considers how the data are generated (the business processes), where it needs to end up, who the users are and their data needs, and how it all should fit together rationally. It should maximize efficiency and accommodate growth (scale-ability).

Dave

One of the challenges I’ve seen with the Enterprise Architecture approach is how to keep it a manageable process. The health sector is a large and complex enterprise, and trying to develop a comprehensive architecture for every business processes is a daunting prospect. By using EA at the very highest levels to define (in very simplistic terms) the essential business processes and how they interrelate is a start, then one can use an EA approach to delve more deeply into discrete building blocks or domains of the health system. I’ve used EA strictly for developing architecture and requirements for supply chain MIS, and I know others have used the same approach for human resource MIS and hospital management systems. This all happen before there was a comprehensive EA defined, and the learning on these subsystems has been beneficial in getting stakeholders on board to tackle the need for higher level EA definition to guide interoperability between existing and proposed subsystems.

We all agree here that EA is something needed to guide our HIS Strengthening activities. We need a Plan or Blueprint (David Boone) to guide our action but the existing framework TOGAF, DoDAF, GEA and alike are well developed but somehow not easy adapt to the HIS context. HIS as many subsystems with so many internal workflow making it difficult to be fully pictured in a single EA, therefore having “High level EA and specific EA for the different building blocks (Chris Wright) can be one approach to solve the problem. I think that following the work started by Sally and all [1] our focus should be on customizing or adapting existing EA frameworks to make them easy to understand and apply to Health Information System Strengthening domaine. Simplification is key to democratize the process and make it a tool at the disposal of all stakeholders to use it under the leadership of government to plan their HIS strengthening interventions as said earlier by Pepela Wanjala.

[1]Sally Stansfield, MD, Nosa Orobaton, MD, DrPH, MBA, David Lubinski, MA, MBA, Steven Uggowitzer, B.Eng. Elec., and Henry Mwanyika, MS, “Case for a National Health Information System Architecture; a Missing Link to Guiding National Development and Implementation,” 2008.