Skip to content

KaTiPuNaN — limang parametro ng kalidad ng datos

I divert into the vernacular for the title of this post to share a Filipino mnemonic to help remember the five parameters of data quality as prescribed by the World Health Organization’s publication “Improving Data Quality”

I used  “KaTiPuNaN”  to make it easy for field health workers to remember the five parameters:

Kumpleto (completenes)

Tama (accuracy and validity)

naPapanahon (timeliness)

Nababasa (legibility)

Nagagamit (accessibility)

This acronym does  not include “reliability” which is part of the original publication. I guess in Filipino that will be “Maasahan”.

 

 

Draft Implementing Rules and Regulations for the Data Privacy Act of 2012: Public Consultation

After four years from enactment of the Data Privacy Act of 2012, President Benigno S Aquino appointed commissioners in the National Privacy Commission. Buckling down to work, the NPC quickly crafted a draft IRR which will be presented in a series of public consultations. The first one is on July 13 at UP Diliman. The registration page is here: privacyph.org/irrsignup

Reprint: Blueprint for National Health Information Systems

(Original PDF version can be downloaded from Scribd. Reposted with permission from Health Intel 2011 magazine of the Zuellig Foundation)

When a man decides to build a house, he does so with great apprehension. This is because the costs tend to be beyond his means and he probably will need to take a loan from the bank. Another reason is that the building process itself is complex, involving huge investments and commitment from many people ranging from the architect who designs the house to the plumber who lays down the pipes to the owner who will eventually live there. Adding to the anxiety is the fact that they do not know each other nor trust each other that much. It is therefore customary to prepare a blueprint prior to construction. The blueprint serves as a common reference point for every stakeholder involved in the project. Between the owner and the architect, they share the same vision of how the whole structure will appear and function. For the engineer and the contractors, the blueprint tells them what materials will be used. Once the structure is built, then it’s the interior designers’ turn to put in the appropriate furniture and fixtures in each room. At the end of it all, if the blueprint is followed faithfully, the owner is satisfied. It will be a coherent structure built by many hands pursuing a common goal of a comfortable home for a family. The blueprint serves as a contract of sorts.

This analogy works well for the ideal national health information system. If the country had this blueprint, various stakeholders from the public and private sectors can contribute to building their own specific systems that can fit the larger national health information system. Let’s then identify the counterparts of this analogy to the national health system. The owners of the national health information system are the Filipino people. They benefit the most from having an efficient, effective, and responsive system. As they are a diverse set of people, they are represented in this process by the Government of the Philippines, specifically, the Department of Health. It must be pointed out that a national health information system must involve the public and private sectors, the academe, non-government organizations and civil society groups. Internal informational need of the DOH is a mere component of the larger system. The department must practice openness to become a responsible and trustworthy representative of the people in the blueprinting
process.

Architecture is a specialization that is both science and art. In effect, when it comes to selecting an architect for the national health information system, it is best to identify people and organizations that have done this before, and have failed and succeeded many times over. At the minimum, they should have documented everything, especially the failures so that the Philippine process can avoid the same pitfalls. Several countries have successfully crafted their Enterprise Architecture. Some of them are in Africa with direr situations than the Philippines. The Enterprise Architecture process is not cheap but it is also not impossible. Governance and leadership of DOH is a key component of the whole process. The resulting blueprint is called the “Health Sector Enterprise Architecture.” It will detail the major elements in the architecture, how they work within and with other elements in the larger health system. Once this sector-wide Enterprise Architecture is published, it can serve as a guide for organizations when they start building their own local health information systems from the large PhilHealth membership database to the rural health unit electronic medical records system. They can start confidently interacting with outside systems, knowing these systems are also compliant with the sector-wide
Enterprise Architecture.

So what’s next?

The DOH needs to carry this responsibility seriously and involve other stakeholders to make this happen. Health Secretary Enrique Ona has empowered Assistant Secretary Nemesio Gako to chair a multi-sectoral technical working group on information and communications technology for health (ICT4H). Collegially, they can come up with the sector-wide
Enterprise Architecture, which can then serve as a guide for all other stakeholders in the national health information system. DOH then shifts to technical assistance
and monitors if the blueprint is being implemented correctly. This may require re-orienting DOH into a regulatory and supervisory role (which is its primary mandate) rather than software development (which is not its core competency). More fundamentally, the more DOH creates the software, the less credible it becomes as a regulatory body on
information systems. To use another analogy, DOH should not be producing drugs because it may compromise its regulatory function
especially when its own drug fails the quality tests.

As a significant stakeholder in the larger health system, the private sector should be involved as soon as the organizational structure and processes for the sector-wide enterprise architecture efforts are clarified. This participation is crucial for the following reasons: first, the private sector has extensive experience with Enterprise
Architecture methodologies. Second, it recognizes the importance of the private sector in collecting and submitting data from their respective institutions. It is a well-accepted fact that a significant number of Filipinos access private healthcare facilities. Ignoring the data accrued from these facilities will result in epidemiologically
flawed analysis and we will not be able to see the complete picture of the country’s health situation. Lastly, they have the flexibility to implement the Enterprise Architecture and the accompanying standards in their local health systems. A true and sincere partnership with the private sector will result in faster deployments which can redound to more effective information systems on the ground.

In the end, if DOH does the right thing right now, Juan dela Cruz can enter any health facility and get the service he needs without worrying about whether it will be covered by PhilHealth or not. Repetitive lab tests are detected and avoided, and the health system is financed more viably because it is more efficient. Filipinos can now appreciate their health system, and begin to understand universal healthcare.

Any Juan will be happy to live in a home like this.

(Note that since this is an analogy, it is by no means perfect nor comprehensive. Its purpose is to pose a certain view of an abstract thing called the national health information system. Other views should be considered as well, but they should also be subjected to the same level of scrutiny that this will receive. The author’s contact details are Alvin Marcelo (alvin dot marcelo at gmail dot com).

#HI201 #EA @jdonsoriano @abbysantos @TDMontalesMD

 

@jdonsoriano

Q: How do we deal with current existing vertical information systems under the EA plan?

Ans: Vertical systems are results of poor (or lack of) architectural design. Often we blame information systems for these vertical programs but if you look closely, these information systems were simply artifacts that reflect the realities of the business processes. If you dissect the business architecture layer, you will see that the health programs are in fact operating in silos themselves.

These silos/vertical programs are detrimental to health service delivery and must be fixed — but how? This is one of the biggest challenges in eHealth right now — When you have mature information systems for vertical programs such as the TB and malaria, how do we re-integrate them?

Interestingly enough the answer seems obvious — re-orient information systems around the point-of-care (at the patient level) since all services converged with the patient and not with the programs. Thus while programs may be vertical, the patient remains the locus of interest or the hub where these vertical programs intersect. Therefore, a patient-oriented electronic health record design could be an effective way of dealing with vertical programs — a system where the patient’s longitudinal records are accessible from his/her perspective.

 

Q: Is UMID part of the EA plan for data collection? Is a unique ID an integral part of HIS?

Ans: Not yet. The reason is that the UMID still does not assign a common reference number (CRN) for every citizen in the Philippines. Only formal employees have SSS. Only government officials have GSIS. Pag-ibig is optional. Only PhilHealth assigns a unique number for every person (including those below 18 years of age) thus the PhilHealth number is the national health identifier for use in the national eHealth plan.

Having said that, there is a Citizen Registry project in the works. This could be the client registry component of the Philippine Health Information Exchange.

 

Q: What’s the bigger problem for capacity building – tech infrastructure or human capital?

Ans: Human capital because all tech are operated by humans in the end. But there should be parallel build-up of tech infrastructure with human capacity so they are in sync.

 

@abbysantos

 

Q1: If TOGAF is used as the #EA for the Philippines, who are the process owners of TOGAF categories Biz,Tech,Data, App?

The priorities of the PeHSFP are:

1) MDG5 (decrease maternal deaths) – business process owner is DOH – Family Health Office

2) Increase UHC – business process owner – PhilHealth

3) Complete the health facility enhancement program – business process owner – National Health Facility Development Bureau

Data ownership is by the business process owner.

Application and technology owner is KMITS (formerly IMS).

 

Q2: How will the private sector’s role be articulated in the current EA being used for the Philippines?

Ans: The private sector is represented in three groups:

  1. the ICT for Health Technical Working Group
  2. the Advisers’ Group
  3. the EMR Committee

 

@TDMontalesMD

Q: In the DOH #EA under service access & delivery, there is no mention of a network provider, should a specific company be identified to set the service standard?

Ans: Usually, no specific brands are placed in an enterprise architecture, rather it contains specifications. This provides leverage to the client as to who to contract within the constraints of those specifications.

 

Q: What does the “for conversion” status mean in the Political Profiling System of the DOH Application System?

Ans: This means that the existing system will be upgraded/converted into a newer version.

 

Q: Is the DOH getting additional funding to improve its ICT or is it just working around the govt budget allotted?

Ans: Yes. The DBM has created the Medium-term IT Harmonization Initiative (MITHI) to fund integrated electronic services between agencies.

 

#HI201 #EA @mtres23

Q1: As a well respected person in Health Informatics, can you give us an example where you championed strategic enterprise architectural thinking to positively impact a local health organization’s operations (in whatever field they may be)?

Ans: Yes, in two instances. First, when I was CIO at PhilHealth (scope of enterprise = PhilHealth), we came up with PhilHealth Enterprise Architecture version 1.5 as a way to visualize the scope and extent of IT in the corporation and how it can be strategically reformed to meet its new business requirements (eg, eClaims). This was an important activity as it organized the many different applications (and business mindsets) into unifying framework and aligned them to the core business of the Corporation (that is, universal health coverage and financial risk protection). Prior to this, there was only an information systems strategic plan (ISSP) which was more tactical than strategic.

Second, in the Philippine eHealth Strategic Framework and Plan (scope of enterprise = national health sector), there is an effort to use EA methodology in defining the business architecture and from there, the data/application and technology architectures. This is easier said than done due to the complexity of the stakeholders relationships and our relative naivete with IT governance at national scale.

You can also apply EA in your next project. If you are implementing a health IT project in a clinic or hospital, the systems analysis part of your work will be easier if you apply EA principles (looking at the enterprise continuum and searching of existing artifacts/solutions).

Q: What are their current business demands and evolving IT needs?

Ans: In terms of business demand, the Steering Committee wishes to see the following benefits from eHealth – decrease maternal deaths, increase universal health coverage, and completion of the health facility enhancement program. IT will always evolve due to the rapid changes in technology but the business demands will not change that fast. The key is to ensure that the business demands are being met while IT changes are managed. Not all new IT features are desirable especially if it will disrupt operations. This is why an EA method is important in deciding which of the new changes can be adopted and which ones can wait.

Q: Any updates as of this day of the organization’s current status?

Ans: I can’t speak for PhilHealth now but for the PeHSFP, there is a top-level business architecture that will be sharable in the public hearings on Oct 20-21.

Q: With the scarce resources, how did you finally decide on which to take on first and what led to this decision?

Ans: That decision is made by the most accountable entity (the National eHealth Steering Committee) with information/advice from the Technical Working Group. Major decisions on funding and directions are always made by the highest governing authority. And since the Steering Committee set its priorities (decrease maternal mortality, increase universal health coverage, complete the health facility enhancement program) it clarifies the priority activities that will require support and funding.

Q: Since we are aiming for a unification operating model, what areas/processes in the eHealth strategy would you classify as belonging to high level integration and which would be classified for standardization?

COBIT5 EDM processes (evaluate, direct, monitor) and APOs (align, plan, and organize) are high-level. When you get down to BAI (build, acquire, implement), you may want to use EA methodology to determine (and weigh in on the) opportunities and solutions. Definitely there should be standardization at the data layer (semantic and synctactic) but we don’t need to reinvent the wheel. A review of existing standards and matching them to our business needs can help with deciding which ones are appropriate to the country (enterprise continuum).

This goes for the national eHealth strategy but the same delineation can be used within a clinic. They key is enterprise continuum — being aware of artifacts that are already out there and leveraging them (rather than reinventing).

COBIT5 processes

 

Q: What principles of Service Oriented Architecture are being referenced to by PeHSFP?

At the outset, just Standardized Service Contract (http://serviceorientation.com/static/pdf/SOA_Principles_Poster.pdf). But the rest of the principles need to be addressed systematically. The adoption of enterprise service buses will help with complying with some of these principles.

Q: Is there such a thing as a turnaround time to get things done? Or is it an iterative process?

Ans: They’re the same actually. One iteration is one turnaround time. It is the definition of “done” that determines if the iteration was successful. A clear product vision helps in determining whether the iteration was able to achieve its objective.

#HI201 #EA @lazyjayc

Question#4: What is the difference between COBIT 5, ITIL, and EA? (I’m confused.. hehe) #MSHI #HI201 #EA

Ans: COBIT5 is a business framework for the governance and management of enterprise IT. It is an all-encompassing framework for enterprise IT. More at www.isaca.org

IT Infrastructure Library is a framework for the delivery, service, and support to enterprise IT. ITIL maps to COBIT5’s “Deliver, Service, Support” domain.

EA is enterprise architecture or blueprint of an enterprise IT. EA maps to COBIT5’s “Align, Plan, and Organize process 03” (APO03).

See this image which shows how all other frameworks fit within COBIT5.

COBIT5 mapping to other frameworks

Q1: Between the 4 EA framework, w/c would be the most applicable to the Philippines and why?

Question#2: What are the characteristics of the PeHSP for us to use your answer in Question#1?

Ans: I asked JayC to try answer first and then I will share mine. I have my own answer but it would be good to hear how the students think.

 

 

#HI201 #EA @bumblebest

From @bumblebest Q1: How often should we adjust an EA? What are the prime factors causing these possible changes? #HI201 #EA

Ans: Any change is inevitable. But the change should be managed so that the stakeholders can accommodate it. TOGAF’s Architecture Development Method (ADM) Phase H shows that change management occurs after the opportunity (in Phase E) has been identified, migration planning has been done (in Phase F) and implementation governance has been applied (Phase G).

TGOAF_ADM_CYCLE

 

Q2: What steps can we do to institutionalize and insulate the EA and PeHSP from partisan politics? #HI201 #EA

Ans: An Architecture Board is key to managing the EA. The EA Board ensures that the EA is clearly depicted and communicated to the relevant stakeholders of the enterprise. They are also responsible to ensuring that the changes can be realistically made. The eHealth TWG stands as the Enterprise Architecture Board for Health and they report to the National eHealth Steering Committee. This means that the TWG is the responsible entity to ensuring that an EA is created and maintained on behalf of the Steering Committee.

Q3: @amarcelo How can we include the private sector in the process? Can we compel them to follow and toe the line? If so, how? #HI201 #EA

Ans: Although private sector can be compelled with policy, the best approach is to make them see the benefit from their own perspective. The private sector is included in the PeHSFP through the ICT4H TWG and the Adviser’s Group> They are consulted for their insights and opinions.

#HI201 #EA @grz_ie23

From @grz_ie23

Q1: How do we strike the right balance between centralised coordination and decentralised implementation of #EA initiatives? #HI201

Ans: Striking the balance is the role of good governance. The WHO-ITU Toolkit described three ways government can control the national eHealth development plan. The National eHealth Governance Steering Committee (through the TWG) agreed that the Philippine style is “Guided Market” (see image).

WHO-ITU-TOOLKIT-GOVT-ROLE

Q2: Several countries utilize service-oriented architecture (SOA), will this be part of implementation of #EA in our country? #HI201

Ans: Yes. SOA is a given in any environment where there is diversity of systems and business processes. Monolithic systems (systems that are not SOAs) have not been successful in environments that are multi-stakeholder. In fact, even within single enterprises, monolithic approaches are almost impossible where there are many departments with different applications.

#HI201 #EA @kidseyes88

1) Will open EMR prevent this? Billing dispute leads to blocked patient data in Maine bostonglobe.com/news/nation/20… via @BostonGlobe

No it will not. There are at least three layers of interoperability that need to exist before data flows effectively — business, information, technology. Open electronic medical records can address information and technology interoperability but cannot assure that there will be business interoperability (that is, two entities agreeing to do business with each other). The article is interesting that it actually states that information and technical interoperability already existed but a disagreement in how to run the business prevented the exchange of information. Similar cases abound in healthcare.

2) Doctors Find Barriers to Sharing Digital Medical Records nyti.ms/YHit7M

In the US, the EMRS got bigger before the Health Information Exchanges became mature (the information and technology interoperability layer). In such a situation, it becomes harder for mature EMRS (like EPIC) to connect “back” to an HIE (this is logical because the EMR has more features than an emerging HIE). The lesson is to quickly define the HIE and ask the EMRs to connect to it.

3) Is interoperability addressed by using open EHR? http://t.co/51gFjvqv9M

Up to a certain point but not beyond it. openEHR helps organize clinical knowledge and structure it consistently. That helps with managing the complexity of clinicians having varying ways of representing their knowledge (see the mindmaps of those who participated in the openEHR workshop). All group members were given the same clinical scenario but all groups have varying mindmaps for that case. If they proceeded to create the EMRs from the mindmap, for sure, their EMRs will not be interoperable because they had already diverged at the clinical knowledge layer.

openEHR is like a bucket of lego blocks from where you can get pre-built blocks (representing clinical knowledge) which you can then put together to create your EMR. Since all of you got your building blocks from the same bucket, the chances that your EMRs can connect is higher.

4) First things first, EMR for different departments in PGH and make them interoperable, fully accessible by healthcare provider?

First definitions: an EMR is an electronic system for recording patient data in one facility. An EHR on the other hand is a person’s longitudinal record which may comprise of data coming from different EMRs.

So in PGH, ISIS is the EMR of the Department of Surgery. In IM, they have their own EMR. But patient Juan dela Cruz should only have one EHR which is a collection of his data from Surgery and IM.

How is this possible? Through interoperability — a system that allows the collection of Juan’s data from the different EMRs where his data resides. Do we need to design this from scratch? No, the Integrating the Healthcare Enterprise (www.ihe.net) has already described how this could be done in a health system.

#HI201 #EA (@wendijoyce)

For my part in MSHI’s HI201 class, I asked the students to post questions on Twitter. So far only @wendijoyce has complied. Here are my answers to her questions:

Q: Where are we in the development of #EA for the Philippine eHealth or HIS?

A: In a proper EA methodology, you need to first identify the scope of your enterprise and then its stakeholders. In a national eHealth strategy, the enterprise is the whole country making it a very complex enterprise with many stakeholders often with competing interests. One way to approach this activity is to partition by consolidating the government perspective first and then widen through public discourse and hearings.

So the answer to the question is that DOH, PhilHealth and DOST have consolidated their viewpoints into the eHealth Common Government Platform (view) and they will present this for public comments on October 20-21, 2014. It is far from over and far from perfect. It is through participation that the EA can reflect the viewpoints of as many stakeholders as possible.

Viewpoint: a stakeholder’s perspective
View: a unified blueprint that contains all the stakeholders’ perspectives

Q: If #EA serves as a framework, should we stick to it, or can it be revised/evolve along the way while it’s practiced?

Frameworks are attempts at organizing complexity. Have you tried arranging your books? Sometimes you try one (alphabetical) but then change your mind (by height). Then you Googled and learned that there is Dublin Core – a way to arrange books properly so that you can go to another library and find your way without knowing the librarian there. You learn that Dublin Core is a standard. Arguably, EA’s need to be well-thought out and researched. And there is a science to building EAs (TGAF, Zachman, etc).

For sure, building expensive complex health IT systems without an EA is formula for disaster. And having an EA does not mean you won’t fail — but you’ll know you’re in a path to failure early.

Having said that, you also need to be on the lookout for risks and if those risks are related to a wrong EA. In these cases, you should revise the blueprint through the agreed change management process.

Q: How do we know we’re in the right path to building them? That it’s “correct”?

In COBIT5, you set the benefits, risks and resources based on your engagement with the stakeholders. These are your milestones. Are you achieving your benefits? Are the risks being controlled? Are your resources enough? These tell you that you are on the correct path. Monitoring the “benefit-risk-resources” triumvirate is the key to governing your IT project.