Electronic Health Records – What Are The Issues and Challenges of Implementation?

It’s week 8 of our health informatics class which means we’re halfway through the semester! 🙂

So for this week’s driving question, we were asked…

What are the issues and challenges in implementing electronic health records in primary care?

I have discussed the Philippine Health Information Exchange program (read it here) and have also broken down the components of the electronic medical records we use in our own company (read it here).

I can honestly say that this is one of the more relatable posts that I had to do, aside from the blog where I had to trace a patient’s steps as he consulted as an outpatient until he was admitted to the hospital. As a designated superuser of an electronic medical record system in a third-world country but working for a private, multinational first-world company, I have had my share of issues and challenges with EMRs. Being an initial end-user and then later being assigned as a superuser (my tasks include administrative components aside from plain use of the EMR for delivering primary health care), I have definitely encountered some of the difficulties and challenges in the implementation of the EMR.

Unlike the previous posts, however, I shall answer the driving question with the short presentation below:

To be honest, I was initially one of those who was (slightly) resistant to change when the EMR system was rolled out in the company, because I felt we were not adequately prepared for such a comprehensive system. I also have the same issues when it comes to ready availability of data (although my concern is more on the availability of statistics for reporting) given the system that we have. On the contrary, however, I am highly confident when it comes to the privacy and security of our system, since the company has always emphasized the importance of data privacy, even those data not related to health.
Let me know what you think! As always, comments, suggestions and questions will be appreciated. Let us discuss and learn together!




Enterprise Architecture – What Is It and How Can It Be Applied to HIS?

It’s week 7 for Health Informatics 201 and this week, the driving question we were asked was…

In a multistakeholder, multicomponent health information system, how can you ensure that all the players are doing their part?

The assignment is for us to also answer the question, “What enterprise architecture frameworks are available and which one is the best for the health sector?”

Before diving into the driving question, let’s tackle enterprise architecture first.

What is enterprise architecture? Enterprise architecture (EA), according to Sessions (2007), is a field that emerged to answer two major problems – system complexity and poor business alignment. The use of IT systems in businesses, while they contributed to success and competitiveness, also came with increasing cost and complexities. EA aims to reduce those problems while increasing business value and effectiveness.

There are 4 methodologies that are most commonly used in EA and they are: 1) Zachman Framework for Enterprise Architectures, 2) The Open Group Architectural Framework, 3) The Federal Enterprise Architecture, and 4) The Gartner Methodology. I will be briefly discussing each below.

The Zachman Framework, as described by its creator, is a “logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of Enterprise, as well as to the development of the Enterprise’s system.” He proposed that there are 6 descriptive foci (data, function, network, people, time, and motivation), and six player perspectives (planner, owner, designer, builder, subcontractor, and enterprise). When all are plotted against a grid, each focus will have six perspectives; conversely, each perspective will have six foci. Through the use of this framework, it will be easier to show a stakeholder’s perspective from all angles; it will also be easier to see who is assigned to what, as the relationships are more clearly defined. The downside of this system, however, is that while it shows relationships or categories, it doesn’t show process for creating the enterprise architecture.

On the other hand, The Open Group Architectural Framework or TOGAF, gives us what Zachman doesn’t – methodology. It describes the process for creating the categories. It has what it calls an Enterprise Continuum – a continuum of architectures ranging from the highly generic to the highly specific. The most generic of the levels is Foundation Architectures. As you go along the continuum, from Common Systems Architectures to Industry Architectures and finally to Organizational Architectures, the architectural principles become more specific. The process that drives the movement from the most generic to the specific level is the Architecture Development Method (ADM). ADM consists of eight phases that are cycled after preliminary phase, and they are: 1) architecture vision, 2) business architecture, 3) information systems architecture, 4) technology architecture, 5) opportunities and solutions, 6) migration planning, 7) implementation governance, and 8) architecture management. I will not discuss the phases individually but what is important to point out is that there are tasks/deliverables for each phase. After implementation (phase 7) and modification of the architectural change-management process (phase 8), the cycle is repeated. One of the main goals of ADM is the transfer of information, so that as more iterations of the cycle are completed, there will less and less need to involve the TOGAF enterprise architect.

The third framework is the Federal Enterprise Architecture or FEA. This was created in an attempt to unify the different agencies and functions under the federal government. It is a combination of the two previous frameworks I discussed, Zachman and TOGAF, as this includes both categories and processes. It has five reference models for performance, namely – business, service, components, technical, and data. The purpose of the interrelated reference models is to establish common language to have standard terms and definitions; consequently, communication, cooperation, and collaboration across political boundaries will be facilitated. FEA is also composed of segments that are considered subsets for the overall enterprise (ie. a government agency is considered a segment under the enterprise that is the federal government). By using the FEA framework, architectures are created for each segment, which should contribute to the realizing the vision for the overall enterprise.

The last of the frameworks I am going to discuss is that of Gartner. Unlike the last three where it is more focused on either categorization or methodology or both, this framework focuses on practice and strategy. Gartner believes that enterprise architectures must start with a vision of where the organization is headed and not where it currently is. Consequently, it is imperative that the constituents – business owners, information specialists, and technology implementers – understand and share that same vision. Once everybody is on board, they can now begin to discuss the implications of their vision on the business, technical, information, and solutions architecture of the enterprise. Gartner, however, does not propose a methodology or step-by-step process with which to achieve this vision.

With all that being said, I feel that the framework that best applies to the health, at least for the public sector, is the FEA. Especially if we’re considering the Philippine Health Information Exchange (PHIE) which I talked about in this blog post, I feel like the FEA framework would work best. I see the FEA as a more complete and comprehensive framework, one that incorporates the advantages of both Zachman and TOGAF. In our setting, the PHIE would correspond to the overall enterprise, under the direction of the DOH. Under PHIE will be the various programs such as iHOMIS, CHITS, RxBox, etc. under the different government agencies that would serve as the segments. The FEA reference models would also serve as the basis for standards and interoperability, which was also emphasized as one of the keys factors for success of the PHIE.

Lastly, to answer the driving question, I think that the best way to ensure that all players in a multistakeholder, multicomponent HIS are doing their parts is to first make sure that all players know their parts (which is what the Zachman framework specifically offers). Each stakeholder, whether they are the businessmen, the governance board or management team, the developers, and so forth, must know their roles and responsibilities in the enterprise. There should be no ambiguity about it, and it would be best if said roles and responsibilities are in black in white so that even when new leader, users or developers arrive, they would know what exactly is expected of them. Another important thing to ensure is that the different stakeholders are not only aware of the vision of the HIS, but also understand and agree with it (as in Gartner’s framework, which would then more likely lead to their commitment to the HIS). Third, the development process should also be dynamic and flexible (recall TOGAF’s  architecture development method) and have several iterations so that there is continuous engagement of the different stakeholders involved. Finally, a framework for measuring HIS (as an enterprise) success should also be in place. The FEA framework has a Federal Enterprise Architecture Program EA Assessment Framework, which is used to rate the different agencies or segments in three main categories – completion (maturity level of the architecture), use (how effectively the segment uses the architecture to drive decision-making), and results (benefits being realized by using the EA framework). The ratings would be a good way to assess and monitor how a segment is doing and in a way also assess if stakeholders are doing their parts right (although stakeholders may do things right and still not be successful), and also provide a means to objectively give feedback to a segment regarding their performance and how that particular segment is doing in terms of achieving the overall vision of the HIS.

That is it for week 7 of HI 201. To be honest, this has been the most challenging assignment so far. Enterprise architecture feels so Greek to me. I hope that I was able to at least shed a little light on the different frameworks (as I’m still struggling to understand them).

As always, questions, clarifications, comments are very much welcome. Let us discuss so that we could learn together.



Philippine Health Information – How Can It Be Accessed and Exchanged?

Of the blogs I have had to publish in the last 5 weeks, I think this is the one I was most excited to do because the task relates to something I experience on a regular basis.

The question were were asked was…

How can patients access their data from different health care providers as they transfer care?

We were assigned to also draw a flowchart that details the information collected at every step for a patient with diabetes with a non-healing wound who consults at outpatient patient but subsequently admitted in the hospital.

Currently, there are only very few institutions in the country using electronic medical records. Most hospitals, clinics and centers, even the most advanced, still rely heavily on paper charts. While some components are through eHealth (laboratory results can be checked online, etc.), the actual patient encounters are still documented through paper and pen. No national program has been implemented that allows for transfer of and/or access to data among institutions, especially those between the private and public sectors.

For a patient, then, who will seek consultation in an outpatient clinic for the first time, the process can be tedious. Aside from providing general data, he/she will have to relay his/her entire medical history to the attending health care professional. Although the prudent thing to do, especially for physicians seeing patients for the first time, is to do a comprehensive history and physical examination, the process can be complicated as well. More often than not, patients – especially the elderly – are unable to give an accurate past medical history. Unfortunately, they also tend to be the ones with several comorbidities. They may not remember all the illnesses they were diagnosed with, the medications they are taking (especially the dose), the exact operations they underwent and in what year, etc., and some of those data can significantly impact their care. Afterwards, if they need to be admitted to a hospital where a different physician will have to attend to them, the whole process of eliciting the biographic data and entire medical history (from diagnosis to procedures to medications) has to be repeated. Generally speaking, manual systems like the one described above are inaccurate, cause delay, non-standardized, and use different terms for the same meaning or have different meanings for the same terms (Herbosa, 2015).

But if there was a standardized system data from different institutions (whether private or public) that can be accessed by health care providers attending to a singular patient, then the process would look something like the one shown below.


Assuming the diabetic patient has not had any previous consults, or his previous consults were done when there was still no standardized interoperable system, upon initial consult at the the outpatient clinic, he/she will be asked to register. The biodata entered should be able to generate a unique identifier for the patient, which will be used for future reference. An alternative would be using the Unified Multipurpose ID, which is a government-issued card that can be used for different government agencies (SSS, PAG-IBIG, PhilHealth and GSIS). This will be associated with a singular electronic medical record (EMR) for the patient, where all information will be in a single view at the point of care. The physician’s evaluation and management will then be documented in the EMR, from his complete medical history, physical examination, assessment and management plan. Ideally, the EMR should also be equipped with decision support tools and knowledge based information to guide the health care provider in managing the patient. If the patient needs to be admitted, he will only have to indicate his unique identifier code or present his UMID, which should allow the health care team in the hospital to pull up his EMR. Instead of doing the entire process and trying to elicit the entire history, what the inhospital physician could do is verify what was already written in the EMR. Not only does this save time and effort on both ends, but more importantly it allows for more accurate “endorsement” of medical care, since the physician could review the notes of the previous physician. While in the hospital, the patient’s course will be documented in the same EMR. After discharge, it is common especially for patients who have chronic illnesses to follow-up. During this time, the use of a unique identifier or UMID will help facilitate pulling up of records and enable continuity of medical care.

As I mentioned earlier, there is still no national program that has been implemented that allows for transfer of and/or access to data among institutions. However, efforts towards this have been in the works for several years.

The Department of Health (DOH) and Department of Science and Technology (DOST) have signed a Joint National Governance on eHealth. These two departments are the leads in attaining the vision of the Philippine eHealth Strategic Framework and Plan (PeHSFP).

The main purpose of the PeHSFP is to describe how the eHealth vision will be achieved to guide national coordination and collaboration, as well as set a clear direction and guidance to the ongoing future eHealth activities in the country.  And that vision is that …

By 2020, eHealth will enable widespread access to health care services, health information, and secure share and exchange patients’ information in support to a safer, quality health care, more equitable and responsive health system for all Filipino people by transforming the way information is used to plan, manage, deliver, and monitor health services.

In particular, one of the tools to achieve the vision will be through the Philippine Health Information Exchange (PHIE), which I already briefly discussed in this blog post. The key words here are standards and interoperability because the PHIE is a platform that allows authorized users to gain access to health information and share it across geographical and health sector boundaries. It is also a means for implementation of innovative ways to deliver health services and information. As long as the data are entered via a standardized format, they can be integrated into the system and later accessed. Examples of information which could be exchanged through the PHIE are demographics, health profiles, care plans, prescriptions, test orders and results, referrals, etc. Basically, it integrates all the different sources of health data (from the different EMRs – whether from private or public institutions, from urban or local areas – and different databases, etc.) into a national platform that is accessible to health consumers, health care providers, health care managers, policy makers, and researchers.


Health Information Exchange Diagram (DOH, 2014)

Specific to the health consumers, the idea is also for them (i.e. patients) to have controlled access to their individual health data, and for them to have the capacity to manage their health records. This step, I think, is crucial for empowering the Filipino people when it comes to taking charge of their health, since they will be more active players.

I sincerely hope that we achieve the eHealth vision by 2020. In particular, I’m very much interested in the full scale deployment of the PHIE because I think it would be a game changer in the way health care is delivered to the Filipino people.

That concludes this week’s blog post. It actually excites me to think that this is the direction we are headed. As a health consumer and a health care provider, I feel that the planned programs are promising.

As always, comments are welcome. Leave them down below and let’s discuss, yes?



Governance and Management – Why Are They Necessary in Health Informatics?

It’s been over a month of learning and we are currently on Week 5 of HI 201. For this week’s blog, the question we were asked was…

Why are governance and management important in health informatics?

In addition, we were also asked to identify an existing health informatics project and dissect it into its component parts.

As in the previous blogs, let me start by defining what governance and management are. Health informatics was already discussed in detail in this previous blog post.

Governance, according to UNESCO (2016) , refers to structures and processes that are designed to ensure accountability and transparency, responsiveness, rule of law, stability, equity and inclusiveness, empowerment and broad-based participation. It is about how power is distributed and shared, how policies are formulated, priorities are set, and stakeholders are made accountable. Specifically, from a business or enterprise perspective, the main objective of governance is to create value for the enterprise. The team is a representation of all stakeholders, and is composed of the board of directors and headed by the chairman. Their main responsibilities include: 1) evaluating and prioritizing stakeholder needs, conditions, and options; 2) deciding on balanced, agreed-on enterprise objectives; 3) setting the direction for the enterprise, and; 4) monitoring the performance and compliance against agreed-on directions and objectives. Having an effective governance is one of the factors determining success of an enterprise (Kadam, 2012). We also have a more specific definition on data governance coming from the American Health Information Management Association (2014) that refers to data governance as the management, compliance, and control of health information in a given organization.

Management, on the other hand, refers to the individuals or groups of  people who are given the authority to achieve the desired results. They operate based on the parameters the governance sets (UNESCO, 2016). From an enterprise IT perspective, there are four main areas of responsibility for management and they are as follows: 1) planning – aligning, planning, organizing; 2) building – building, acquiring, implementing; 3) running – delivering, servicing, supporting, and; 4) monitoring – monitoring, evaluating, assessing (Kadam, 2012).

The definitions are straightforward and the simple answer to this week’s driving question is that governance and management are important in health informatics because they are crucial to the success for health informatics projects and/or systems.

To elaborate, below are the principles for governance and management based on the COBIT 5 business framework (Kadam, 2012). First, they should be able to meet the stakeholders’ needs. Governance, in particular, should be able to balance and address the diverse needs of both internal and external stakeholders. Another principle is covering the enterprise from end-to-end which means that there should be clear and defined roles and responsibilities for, as well as relationships among, governance, management, stakeholders, and operations and execution team. The third principle is applying a single integrated framework, and the COBIT 5 framework integrated on a macro level serves as an operations guide for both governance and management. Fourth principle is enabling a holistic approach. There are 7 identified enterprise enablers (1. principles, policies and framework; 2. processes; 3. organization structure; 4. culture, ethics and behavior; 5. information; 6. services, infrastructure and applications, and; 7. people, skills and competencies), and the performance of each should be managed and monitored to see whether they are contributing to the achievement of the overall goals of the enterprise. Finally, there should be a separation of governance and management. As seen from the definitions above, they each have separate functions and responsibilities.

For the next part, I will be presenting and dissecting an existing health informatics project. As a quick background, I work as medical programs team lead in the shared services office of a multinational company. We have an electronic medical record program that was initially rolled out in our business units in the Americas where the Global Health and Medical officers and managers are (also where our global head office is) before it was implemented for use in the Philippines in December 2015. I was initially assigned as an end-user clinician, but have recently taken on the superuser role (in charge all-things related to the EMR for the Philippine H&M business unit).

Based on the Philippine eHealth Strategic Framework and Plan 2014-2020, eHealth projects have 7 component parts. I will briefly define or explain each one below and identify its counterpart in the EMR that I am currently using.

  1. Governance
    • Directs and coordinates eHealth activities at all levels
    • Company counterpart
      • EMR Governance Board, chaired by the  Global Health and Medical General Manager with regional medical managers (Asia-Pacific, Europe, North America, South America, Africa) as members
      • Overall decision makers in the development and implementation of the company’s EMR program
  2. Legislation, Policy and Compliance
    • Formulates of the required legislations, policies and compliance to support the attainment of the eHealth vision
    • Company counterpart
      • Center of Excellence Manager
      • Works closely with the governance board in the creation of policies pertaining to the EMR program
      • Reviews and endorses proposed changes based on established criteria and ensures that changes are aligned with health and medical (H&M) strategy and roadmap
  3. Standards and Interoperability
    • Promotes and enables exchange of health information across geographical and health sector boundaries through use of common standards on data structure, terminologies, and messaging
    • Company counterpart
      • Since the eHealth program was specifically designed for the company and the initiative was from the Global Health and Medical team, there is no issue with interoperability. The same program was deployed and implemented in all business units across the globe.
      • The fact, however, that the same program was deployed across all business units (from shared services, upstream, midstream, and downstream), there were certain requirements from particular locations that were not met by the system. For example, there are several fields in the EMR that I barely use since I focus more on delivering primary care compared to counterparts who do disability evaluation, incident investigation, etc. The EMR has been made in such a way that it is very comprehensive and does not discriminate the work a clinician does – which can be good, except that the interface appears very complex and overwhelming. There are also certain reports that are cannot be generated by the system (for now) because they are unique to the Philippine H&M business unit.
  4. Strategy and Investment
    • Develops, operates and sustains the eHealth vision
    • Company counterpart
      • The Corporate EMR Governance Team, which is a separate entity from the EMR Governance Board, has the main task of developing a strategy for operation and sustainability of the eHealth vision for the project.
      • Since this is a company program, investment/funding was internal.
  5. Infrastructure
    • Establishes and supports health information exchange
    • Includes physical technology and software platforms, services and applications to support health information exchange.
    • Company counterpart
      • A third-party vendor was tapped to help create the EMR program for the company and was therefore responsible for the creation of the software. The program was run using existing company infrastructure such as computers and network printers, and also largely depended on the company’s high-speed connectivity and virtual private network.
  6. Human Resource
    • Workforce or manpower that develops, operates or implements the eHealth environment
    • Company counterpart
      • Aside from the third-party vendors who created the software for the company, all other human resource were existing employees. A corporate EMR project support team, composed of H&M, IT and HR personnel, was created to train superusers and end-users of the program. The superusers and end-users,  on the other hand, were the already existing clinicians belonging to the different H&M teams from all the company’s business units (or offices around the globe), who were previously encoded their health data in non-standardized formats.
  7. eHealth Solutions
    • Required services and applications that enables widespread access to health care services, health information, health reports, health care activities, and securely shares and exchanges patient’s information in support to health system goals
    • Company counterpart
      • The EMR program in itself is the eHealth solution
      • Some of the features of the EMR program
        • Documentation of all of employees’ primary care visits (HPI, ROS, diagnosis/es, treatment per visit)
        • Documentation of employees’ full medical history (past medical history, personal/social history, family history, allergies, previous medications taken, procedures undergone, etc.)
        • Documentation of vaccinations given with ability to notify employee when next dose is due
        • Health surveillance of employees requiring periodic examination such as having an audiogram, also with the ability to notify employee when next medical examination/test is due
        • Creation of laboratory requests and prescriptions
        • Secure transnational transfer of medical records especially for expatriates and their dependents
        • Generation of reports for internal use and for compliance to national laws as well

I personally think that for a private company not in the healthcare field, the mere fact that we have an EMR program at all is already a big deal. In the 9 months that I have been using it, I can definitely say that it is comprehensive and it seeks to provide solutions to several H&M eHealth concerns. However, there is still much room for improvement. Since there are several business units across the globe and our needs are not the same (we cater to upstream, midstream, downstream and shared services), those differences need to be addressed.

As a side note, maybe there’s  a possibility that I can be part of the corporate EMR governance team or the corporate EMR project support team so I can be more hands-on in helping improve the system.

And that is it for this week’s blog! I hope that you learned something and that this, along with the previous posts, has been helping you better understand the science and art of health informatics.

Comments, questions, and discussion are very much welcome. Leave a comment down below so we can discuss and learn together.



Health Information Systems in Developing Countries – How Can We Sustain It?

It’s week 4 of our HI 201 class. Time has been flying! Or maybe it’s the opposite. It feels like it’s been over a month since I wrote a blog, when in fact that was just last week.

Anyway, for this week we were tasked to answer the question…

How can health information systems be sustainable in developing countries?

We were likewise asked to present a mind map, and below is what I came up with:

HI 201 - W4 - Mind Map Ver. 2

Before I answer the question and discuss my mind map, let me first define the following – health information systems and sustainability.

Health information systems, according to Pacific Health Information Network, refer to “any system that captures, stores, manages or transmits information related to the health of individuals or the activities of organizations that work within the health sector.” Meanwhile, sustainability has several definitions, depending on context. Reynolds and Stinson said that the term implies maintaining something that already exists over time. In IT in particular, it implies the ability to identify and manage risks threatening the long-term viability of IT (Korpela, et. al, 1993). But for our purpose, the most fitting definition is the  one presented by the Australian Agency for International Development. They defined sustainability as “the continuation of benefits after major assistance from a donor has been completed.” Notice that the emphasis was on the term benefits and it did not specify that the project or program per se should be sustainable. They argued that sustainability should be an ongoing process, and that it needs review and revision as the circumstances change and lessons are learned from experiences.

So why do HIS fail in the first place? A model that could best answer this is the ITPOSMO dimensions of health information system design-reality gap. The acronym refers to information, technology, process, objectives and values, staffing and skills, management systems and structures, and other resources. This model presents the seven dimensions between design and reality, and the basic premise is that the bigger the gap, the more likely it is for a HIS to fail. This model is applicable to HIS in all countries.

However, things are more complex in developing countries. In terms of stakeholders (see orange boxes above), usually two out of the three are international players. The donors who provide funding are commonly international organizations, such as the World Health Organization, or are first-world countries. Developers of the HI system may be brought in as well from other countries. Because of this, they are likely not familiar with the many aspects of the developing country (referred to as user organization; may refer to either private or public organizations, whether at the local or national level) they are trying to help.

Kimaro and Nhampossa (2007), in their paper The Challenges of Health Sustainability of Health Information Systems in Developing Countries: Comparative Studies of Mozambique and Tanzania, mentioned several examples of why HIS failed (refer to green items in mind map above). The use of top-down development approach is one, whereby ownership and control of the project rest on the donors and top-level managers. This excludes the end-users who are ultimately going to regularly use the planned project/proposed system. Another is the lack of ownership and responsibility of the user organization, which may happen when the donor prioritizes the needs and requirements of the donor rather than the user organization. Third is the absence of an explicit sustainable strategy. Since donor funding is usually short-term, not having an explicit sustainable strategy can lead to early failure of the HIS when user organizations are unable to continuously fund the project. In relation to this, lack of training for and long-term support for users who are expected to utilize the system can also lead to failure.

In contrast, examples of factors that can lead to success of a HIS are mainly through addressing the gaps between design and reality. For example, the use of iterative approach in the implementation of the system, either through modules or increments, or even though pilot-and-scale-up, help reduce the amount of change that the users must endure at any one time. This is better combined with effective two-way communication among the key actors/stakeholders, in particular the developers and end-users. It can be a learning process whereby the current design and reality are examined and emergent gaps are readily addressed.  It can also help the users better understand the design, and the designers to better understand the reality. Prototyping can also lead to HIS success because it allows for all stakeholders to get an overall sense of the design-reality gap. A final example is having the right people, with a special mention on hybrids. The hybrids are also referred to as bridgers or spanners, and are of central importance because they understand both the world of the developer and the world of the user.

I especially mentioned the hybrids because that, in particular, is what I am hope to be once I have completed my masters in health informatics. I want to be the bridge between the developers and the users, and hopefully positively impact the field of health informatics in the Philippines, particularly in the development of health information systems.

Anyway, so to answer this week’s question, let me briefly run through what I have put in the mind map. I want to focus on the lower half depicting the process which I think is essential to developing a successful HIS.

The first step is initiation. It is at this time that stakeholders are identified. Aside from donors, user organizations and developers, they can also refer to politicians or law-makers, or any key player that could significantly influence the new project or program. The main problem must be identified and afterwards alignment of resources, interest and responsibilities should be aligned. It is important to do this at the onset because conflicting interests will ultimately lead to failure of the HIS.

In the planning phase, I separated bottom-up approach to put more emphasis on it. This is in contrast to the top-down approach that I mentioned earlier, which usually only involved top-level managers. With this bottom-up approach, end-users are involved. I strongly feel that they should be part of the process even in the planning because their current reality and experiences will affect how they understand, accept, and integrate the project. They are key to sustainability long after the donors and developers are gone, and should therefore be involved at the very latest in the planning phase. As for the second part, I incorporated the project management body of knowledge categories mentioned in Satzinger’s System Analysis and Design. They are: 1. scope (functions to be done by system, what will be done by team); 2. time frame (detailed schedule of tasks); 3. cost (initial expenses, cost/benefit analysis); 4.  quality (quality plan and control activities for each phase of the project); 5. human resource (recruiting and hiring of project members); 6. communications (establishing team communications); 7. risk (reviewing risks for failure and developing plan for mitigation); 8. procurement (developing request for proposals, writing contracts); and 9. integration. They hybrids (aka. me in the future) are highlighted under human resource because they will be an important asset in the success of the HIS. I also put the design-reality gap model as a means for assessing the risk and feasibility of the proposed project. Finally, I added planning sustainability analysis and strategy because I have the impression that planning for integration is more focused on how the project will be initially rolled out and not how it will be maintained.

In design and development, several things must be considered. For example, is there a current HIS? What is the current HIS offering? Will the proposed HIS be similar, different, or complementary? What do the top-level managers think of the proposed project? What about the end-users? Are they amenable to it? How important will this system be to the users? Can the users sustain the proposed system once it is turned over to them? As development of health information systems usually require a lot of resources in terms of money, time and manpower, we do not want to create a system that will be inefficient, complicated, or deemed as something that yes, has benefits, but are not worth it.

For the execution and control phase, the system may be better implemented in steps. It can be rolled out in one module at the a time or in increments, or pilot-tested in one department or location and then scaled up. As mentioned earlier, this will decrease the amount of change users have to endure at any one point in time. By implementing it this way, every step of the process can be readily evaluated for gaps and the gaps can be addressed early on. In addition, this will better help with institutionalization, since it will be easier for the system to be absorbed and integrated within organizational structures and routine activities. Moreover, those types of delivery, compared to the “big bang” approach (or implementing it all at once), will also facilitate the better belief in, acceptance of, and understanding of the system for the users. While the project is being executed, building local capacity should be done as well. In preparation for the transition or closing, the people who will ultimately manage and use the system, whether they are managers or end-users or IT staff who will do technical support, should be trained to handle the system once they are on their own.

Finally, the closing is when the program is turned over to the user organization. Typically this is when donor funding ceases and the developers end their contract as well. However, it might be better if some form of technical support will still be provided for the users while they continue to navigate the new system, especially if local capacity building was insufficient.

Personally, I truly believe that involvement of the end-users (or at least a core group of them) is one of the keys to having a successful HIS. That and the continued training and knowledge-sharing will help sustain any HIS. I am currently using an EMR software that was developed way before I entered into the company I am working at. I couldn’t have been part of the planning process, but as an end-user now, I can see the many gaps that need to be addressed. Our system is neither a success nor a failure at this point because it hasn’t been fully rolled out to all the international clinics/offices. But interacting with other end-users like myself, I can see why some of them are disappointed and some of them find it difficult to work with the current system. I feel that even though the medical staff see the value of the system, it is very complicated and not user-friendly. It also does not address some important healthcare needs (like generating reports for government-compliance purposes), so users like myself are burdened with using the program along with continuing the old system (aka. paper charts, manually generated reports). It was actually one of the reasons that sparked my interest in Health Informatics, since I wanted to know what else could be done to improve the system.

That concludes my post for this week! It was a lengthy one (I apologize if I’m too rambly), which will most likely be the way the rest of my succeeding posts will be.

I have no question for this week, but I’d love to hear your thoughts on whatever was written above. Leave a comment down below and let’s discuss and learn together.