eHealth Enterprise Architecture for Emerging and Developing Countries - ISO/TC 215 WG 8 - Business Requirements for Electronic Health Records

The vast majority of resource-impoverished countries do not have national eHealth policies. Instead they adopt a vertical approach towards health information systems collecting data for specific diseases such as AIDS, Malaria and TB, often to satisfy the different donors demands for aggregate data for those specific diseases.

In July 2008, Rockefeller Foundation organized the 'Making the eHealth Connection' conference in Bellagio, Italy [1]. Two hundred invited experts discussed themes such as Interoperability, Capacity Building for eHealth, Information Sharing, EHR and eHealth Policies. The Africans participating in the Interoperability Group, in the first week of the Bellagio meeting, made a clear plea to to develop a harmonized long-term strategy (5 to 10 years) with immediate action driven by the urgent disease burden and implications of ongoing unguided and uncoordinated eHealth deployment. This translates into providing the tools to assist countries in developing eHealth Architectures based on best practices, standards, international guidance documents, and local conditions.

The reality where, in almost any single African country, several different vertical systems are present with no common framework or standards was pointed out as a major problem that needs urgent attention. These “siloed systems” fragment information and make it more difficult to integrate the information they produce over time. It has also been identified that conceiving, selecting, developing, deploying and maintaining a national eHealth infrastructure has a complexity that is difficult for stakeholders to grasp.

From the Bellagio meeting there was an agreement that Global South countries urgently need an architectural framework from which to conceive eHealth systems, plan implementations, make build-or-buy decisions, decide on acquisitions and undertake related activities [2]. This NWIP proposal is a first reponse to that demand and aims to develop an ISO Technical Report (TR) document to identify the business requirements of an eHealth architecture. The TR is organized in a two-parts document. Part 1 provides a landscape of what exists on eHealth architecture and standards currently in use, and compares the actual standards used for individual and aggregate data collection to fullfill the different needs, such as Monitoring and Evaluation (M&E), surveillance, public health, management, and policy functions.

[[Back|Part 1 - Environmental Scan]]

[[Back|Part 1 - Environmental Scan]]

!!Section 1
This section reviews the Health Metrics Network Framework(HMN) and Standards for Country Information Systems [3]. The Health Metrics Network (HMN) is a not-for-profit organization, associated with WHO, whose focus is the strengthening of countries' health systems through the appropriate use of IT. The TR will build on the HMN framework to include references to standards to promote development of standards-based health information systems. 

[[HMN]]

!!Section 2
This section will review international experiences on the construction of national eHealth architectures. The following ongoing initiatives have already been identified as relevant for this TR:

[[Australia]]

[[Brazil]]

[[Canada]]

[[Germany]]

[[Kenya]]

[[Netherlands]]

[[New Zealand]]

[[Turkey]]

[[USA]]

[[United Kingdom]]

[[eHealth Europe]]


!!Section 3
This section identifies the current international experience on data collection at the point of care, considering surveillance, vital statistics, and health services and programme monitoring. Since this TR focus is resource-poor countries, the emphasis will be on primary care, socio-demographic issues, monitoring, and public health. Standards currently used to define and transmit aggregrate data and indicators will be reviewed in this Section. 

Other frameworks, such as the The Global Fund to Fight AIDS, Tuberculosis and Malaria (GFATM) M&E Toolkit [4], Joint United Nations Programme on HIV/AIDS (UNAIDS)  Guidelines on Construction of Core Indicators [9], and various maturity models, will be considered to insure that the architecture is aligned with current M&E activities in low-resource environments.

[[Global Fund for HIV/AIDS, TB, and Malaria (GFATM)]] 

[[Joint United Nations Programme on HIV/AIDS (UNAIDS)]]

[[PAHO]]	

[[Brazil]]

[[Canada]]

!!!Other Resources
[[WHO Indicator and Metadata Registry]]

[[Maturity Models]]

[[Routine Health Information Network (RHINO)]]



[[Back|Part 1 - Environmental Scan]]

!!1.2.2.1 Underlying Principles
The eHealth architecture should support and facilitate access to the most relevant health research, information and educational materials, for managers, providers, researchers, and the general population. It should facilitate the construction of eHealth systems to support the wellness of the individual, family, and community. In addition, it should also support frontline health care professions, as well as, public health services, health promotion, and preventative interventions in resource-poor environments. Furthermore, It should be an essential resource to system designers, developers and implementers.

!!1.2.2.2 Terms and Definitions
[[Aggregate Data]]
[[Architecture]]
[[eHealth]]
[[Health Information System]]


!!1.2.2.3 General Requirements
The following general requirements for a reference Global eHealth architecture have been identified:

[[Methodology]]
[[Identifiers]]
[[Provider Registry]]
[[Patient-centered]]
[[Continuity of care]]
[[Telehealth]]
[[Workflow]]
[[Monitoring and Evaluation]]
[[Real-time Surveillance]]
[[Monitoring Framework]]
[[Reporting]]
[[Privacy and Confidentialy]]
[[Interoperability]]
[[Connectivity]]

!!1.2.2.4 Business Processes
The overall objective is to identify the core business processes of an enterprise eHealth Architecture (EA). A TOGAF like approach, linked to relevant examples, will be used to identify the different services required in the EA:

[[Enterprise services]]
[[Security services]]
[[Integration services]]
[[Presentation/User interface]]
[[Health services]]


[[Back|Part 1 - Environmental Scan]]

[[Aggregate Data]]
[[Architecture]]
[[eHealth]]
[[Health Information System]]
[[Monitoring and Evaluation]]


[[Back|Part 1 - Environmental Scan]]

[[Making the eHealth Connection: Global Partnerships, Local Solutions. Bellagio Center, Rockefeller Foundation, Italy, July 2008|http://www.ehealth-connection.org]]

[[Bellagio eHealth Call to Action, Bellagio Center, Rockefeller Foundation, Italy, July 2008|http://www.ehealth-connection.org/content/bellagio-ehealth-call-action]]

[[Health Metrics Network Framework and Standards for Country Information Systems|http://www.who.int/entity/healthmetrics/documents/hmn_framework200803.pdf]]

[[Global Fund for HIV/AIDS, TB, and Malaria (GFATM) Monitoring and Evaluation Toolkit|http://www.theglobalfund.org/documents/me/M_E_Toolkit.pdf]]

[[Electronic Health Record Solution Blueprint. Canada Health Infoway|http://knowledge.infoway-inforoute.ca/EHRSRA/index.html]]

[[Federal Health Architecture|http://www.hhs.gov/fedhealtharch/index.html]]

[[NHS Care Record|http://www.nhscarerecords.nhs.uk/]]
   
[[Logical Record Architecture for Health and Social Care from UK|http://www.connectingforhealth.nhs.uk/systemsandservices/data/lra]]

[[eHealth Europe – European Electronic Health Record Project and the eHealth-INTEROP|http://www.ehealth-interop.nen.nl/]]

[[Joint United Nations Programme on HIV/AIDS (UNAIDS) - Guidelines on Construction of Core Indicators|http://data.unaids.org/pub/Manual/2009/JC1676_Core_Indicators_2009_en.pdf]]

[[Routine Health Information Network (RHINO)|http://www.rhinonet.org/]]

[[Basic Indicators – Pan-American Health Organization – PAHO| http://www.paho.org/english/dd/ais/BI_2007_ENG.pdf]]

[[Brazilian Basic Health Indicators and Indicators from the Primary Care Pact|http://www.datasus.gov.br/idb]]

[[Canada Health Indicators|http://www.cihi.ca/cihiweb/dispPage.jsp?cw_page=AR_152_E]]

[[WHO Indicator and Metadata Registry (IMR)|http://www.who.int/gho/IndicatorRegistry]]

[[WHO Statistical Data and Metadata Exchange-Health Domain (SDMX-HD)|http://groups.google.com/group/sdmx_hd?hl=en]]

[[ISO/TS 17369:2005 Statistical Data and Metadata Exchange (SDMX)|http://www.sdmx.org]]

[[ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR)|http://www.astm.org]]

[[CEN/TC 251- Published standards|http://www.cen.eu/CENORM/BusinessDomains/TechnicalCommitteesWorkshops/CENTechnicalCommittees/Standards.asp?param=6232&title=CEN%2FTC+251]]

[[Global Fund to Fight AIDS, Tuberculosis, and Malaria(GFATM)|http://www.theglobalfund.org]]

[[International Classification of Diseases (ICD)|http://www.who.int/classifications/icd/en]]

[[ISO 15836:2003 Dublin Core Metadata Initiative|http://www.dublincore.org]]

[[ISO 22857:2004 Guidelines on data protection to facilitate trans-border flows of personal health information|http://www.iso.org]]

[[ISO Information Technology Task Force (ITTF)|http://standards.iso.org/ittf/PubliclyAvailableStandards]]

[[ISO/CD TR 28380-1 IHE global standards adoption -- Part 1: Process|http://www.iso.org]]

[[ISO/CD TS 21298 Health informatics -- Functional and structural roles|http://www.iso.org]]

[[ISO/DIS 17113.2 Exchange of information between healthcare information systems -- Method for development of messages|http://www.iso.org]]

[[ISO/HL7 21731:2006 HL7 version 3 -- Reference information model|http://www.hl7.org]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments|http://www.hl7.org]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments|http://www.hl7.org]]

[[ISO/HL7 NP 27951 Common terminology services|http://www.iso.org]]

[[ISO/NP 12967-3 Service architecture -- Part 3: Computational viewpoint|http://www.iso.org]]

[[ISO/TR 18307:2001 Interoperability and compatibility in messaging and communication standards -- Key characteristics|http://www.iso.org]]

[[ISO/TR 20514:2005 Electronic health record -- Definition, scope and context|http://www.iso.org]]

[[ISO/TR 21089:2004 Trusted end-to-end information flows|http://www.iso.org]]

[[ISO/TR 22221:2006 Health informatics - Good principles and practices for a clinical data warehouse|http://www.iso.org]]

[[ISO/TR 27809:2007 Measures for ensuring patient safety of health software|http://www.iso.org]]

[[ISO/TS 17117:2002 Controlled health terminology -- Structure and high-level indicators|http://www.iso.org]]

[[ISO/TS 18308:2004 Requirements for an electronic health record architecture|http://www.iso.org]]

[[ISO/TS 21667:2004 Health indicators conceptual framework|http://www.iso.org]]

[[ISO/TS 25238:2007 Classification of safety risks from health software|http://www.iso.org]]

[[Logical Observation Identifiers Names and Codes(LOINC)|http://www.loinc.org]]

[[Patient Monitoring Guidelines for HIV Care and ART|http://www.who.int]]

[[PEPFAR (Presidents Emergency Plan for AIDS Relief)|http://www.pepfar.gov]]

[[SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms)|http://www.ihtsdo.org/snomed-ct/]]

[[UNAIDS/USG Confidentiality and Security Guidelines|http://data.unaids.org/pub/manual/2007/confidentiality_security_interim_guidelines_15may2007_en.pdf]]

[[UNGASS (UN General Assembly Special Session on HIV and AIDS)|http://www.unaids.org/en/AboutUNAIDS/Goals/UNGASS/default.asp]]


[[Back|Part 1 - Environmental Scan]]

Part 2 represents the core contibution of this TR and aims at providing a roadmap for identifying business requirements that define an eHealth enterprise architecture. 


[[Back|Part 2 - Business Requirements]]

The eHealth architecture should support and facilitate access to the most relevant health research, information and educational materials, for managers, providers, researchers, and the general population. It should facilitate the construction of eHealth systems to support the wellness of the individual, family, and community. In addition, it should also support frontline health care professions, as well as, public health services, health promotion, and preventative interventions in resource-poor environments. Furthermore, It should be an essential resource to system designers, developers and implementers.


[[Back|Part 2 - Business Requirements]]

[[Aggregate Data]]
[[Architecture]]
[[eHealth]]
[[Health Information System]]
[[Monitoring and Evaluation]]


[[Back|Part 2 - Business Requirements]]

The following general requirements for a reference Global eHealth architecture have been identified:

[[Methodology]] - be constructed using a framework of unified best practices of software engineering methodologies, leading to robust, scalable, distributed, user-friendly software and health architecture based on thoroughly documented functionalities and interoperability requirements;

[[Identifiers]] - be ideally supported by unique identifiers for citizens, health care workers and health care organizations. Unique identifiers would then support a Client Registry or at minimum an Enterprise Master Patient Index; 

[[Provider Registry]] - incorporate a national registry of health care providers and description of resources such as type of service provided, medical equipment available and health care personnel currently working, as well as their profiles for accessing data;

[[Patient-centered]] - be a person/patient centered system leading to the construction of the EHR (electronic health record) with inclusion of information such as immunization status, family history, risk factors (smoking, drug abuse, community context, family and housing information). Data should be collected only once, wherever the patient is being attended. That data could be stored in a local EMR/EPR system and/or assuming interoperability, and based on national policies/clinical expert opinion & consensus, relevant shareable data from local systems could be transmitted to the individual’s national EHR record (stored in a national EHR repository. The architecture, however, should allow for the collection of community information such as facilities, services, health determinants given the existence of indicators not derived from the EHR;

[[Continuity of care]] - allow systems to be delivered which provide for continuity of access to care across all levels of the community;

[[Telehealth]] - offer support to Telehealth applications such as teleconsultations; 

[[Workflow]] - offer support for patient flow management, facilitate intelligent scheduling such as that required for patient’s referral and counter-referral;

[[Monitoring and Evaluation]] - support and facilitate health management activities such as resource allocation, budget allocation and follow-up, M&E of health services and programmes to allow decision makers and stakeholders to measure the success of their activities. Specifically M&E consists of routine tasks to collect, evaluate and act on program indicators in an effort to achieve overall success.

[[Real-time Surveillance]] - provide real-time surveillance of diseases and other emergencies (natural as well as human-induced), such as epidemics, and to allow rapid community-based response;

[[Reporting Systems]] - support data aggregation and reporting to attend to all of the needs of information stated by governments, donors and other stakeholders, which supports population-based reporting of aggregate data while clinical systems are deployed;

[[Privacy and Confidentiality]] - include appropriate methods to guarantee privacy and confidentiality of identified health data, through single sign-on role-based security layer, including personal rights to health information;

[[Interoperability]] - offer open standardized interfaces and services to interoperate with clinical and M&E systems already deployed in the region;

[[Connectivity]] - support for off-line data-entry for those places where Internet or appropriate communications are not present. 

!!Relevant standards

[[ISO 12967 - Service Architecture Part 1: Enterprise Viewpoint]]

[[ISO 12967 - Service Architecture Part 2: Information Viewpoint]]

[[ISO 12967 - Service Architecture Part 3: Computational Viewpoint]]

[[ISO/ IEC 11179 Metadata Registries (MDR)]]

[[Health Metrics Network Framework 2008]]


[[Back|Part 2 - Business Requirements]]

The overall objective is to identify the core business processes of an enterprise eHealth Architecture (EA). A TOGAF like approach, linked to relevant examples, will be used to identify the different services required in the EA:

[[Enterprise services]] – describes the business processes that are common to all domains, such as demographic services, terminology services, and clinical models

[[Security services]] – describes the business processes to guarantee privacy and confidentiality of health data

[[Integration services]] - describes the business processes to allow for the construction of interoperable systems through standardized interfaces. Special attention will be given to the interfaces needed between public and private health systems, since many African countries have a public/private health delivery model

[[Presentation/User interface]] – describes the requirements of the presentation layer of the EA. Issues such as use of mobile devices and off-line devices should be addressed here

[[Health Services]] – describes the health domains that the EA will cover, with initial focus on primary care activities such as: immunization, child and maternity care, chronic diseases and special programmes such as TB, malaria and AIDS. M&E, program management, and surveillance should also be included here.

!!Relevant standards

[[ISO/TS 16308 - Requirements for an electronic health record architecture]]


[[Back|Part 2 - Business Requirements]]

[1] Making the eHealth Connection: Global Partnerships, Local Solutions. Bellagio Center, Rockefeller Foundation, Italy, July 2008. http://www.ehealth-connection.org

[2] Bellagio eHealth Call to Action, Bellagio Center, Rockefeller Foundation, Italy, July 2008. 
http://www.ehealth-connection.org/content/bellagio-ehealth-call-action

[3]Health Metrics Network Framework and Standards for Country Information Systems – Second Edition – June 2008. World Health Organization. ISBN 978 92 4 159594 0. http://www.who.int/entity/healthmetrics/documents/hmn_framework200803.pdf

[4] Global Fund for HIV/AIDS, TB, and Malaria (GFATM) Monitoring and Evaluation Toolkit. http://www.theglobalfund.org/documents/me/M_E_Toolkit.pdf

[5] Electronic Health Record Solution Blueprint. Canada Health Infoway. Available at: http://knowledge.infoway-inforoute.ca/EHRSRA/index.html
[6] Federal Health Architecture. http://www.hhs.gov/fedhealtharch/index.html

[7] NHS Care Record and the Logical Record Architecture for Health and Social Care from UK. Available at: http://www.nhscarerecords.nhs.uk/   
 http://www.connectingforhealth.nhs.uk/systemsandservices/data/lra
[8] eHealth Europe – European Electronic Health Record Project and the eHealth-INTEROP' European Project. http://www.ehealth-interop.nen.nl/

[9] Joint United Nations Programme on HIV/AIDS (UNAIDS) - Guidelines on Construction of Core Indicators. Available at: http://data.unaids.org/pub/Manual/2009/JC1676_Core_Indicators_2009_en.pdf

[10] Routine Health Information Network – RHINO.   http://www.rhinonet.org/

[11] Basic Indicators – Pan-American Health Organization – PAHO. http://www.paho.org/english/dd/ais/BI_2007_ENG.pdf

[12] Brazilian Basic Health Indicators and Indicators from the Primary Care Pact. http://www.datasus.gov.br/idb

[13] Canada Health Indicators,  http://www.cihi.ca/cihiweb/dispPage.jsp?cw_page=AR_152_E

[14] WHO Indicator and Metadata Registry. http://www.who.int/gho/IndicatorRegistry

[15] WHO Statistical Data and Metadata Exchange-Health Domain (SDMX-HD) aggregate data transmission format.  http://groups.google.com/group/sdmx_hd?hl=en

[16] ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR), http://www.astm.org

[17] CEN/TC 251- Published standards, http://www.cen.eu/CENORM/BusinessDomains/TechnicalCommitteesWorkshops/CENTechnicalCommittees/Standards.asp?param=6232&title=CEN%2FTC+251

[18] GFATM M&E Toolkit, http://www.theglobalfund.org

[19] ICD (International Classification of Diseases), http://www.who.int/classifications/icd/en

[20] ISO 15836:2003 Dublin Core Metadata Initiative, 	http://www.dublincore.org 

[21] ISO 22857:2004 Guidelines on data protection to facilitate trans-border flows of personal health information, http://www.iso.org

[22] ISO ITTF, http://standards.iso.org/ittf/PubliclyAvailableStandards

[23] ISO/CD TR 28380-1, IHE global standards adoption -- Part 1: Process,	http://www.iso.org

[24] ISO/CD TS 21298 Health informatics -- Functional and structural roles, http://www.iso.org

[25] ISO/DIS 17113.2 Exchange of information between healthcare information systems -- Method for development of messages, http://www.iso.org

[26] ISO/HL7 21731:2006 HL7 version 3 -- Reference information model -- Release 1, http://www.hl7.org

[27] ISO/HL7 DIS 27931 	HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments,	http://www.hl7.org

[28] ISO/HL7 DIS 27931 	HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments,	http://www.hl7.org

[29] ISO/HL7 NP 27951 Common terminology services, release 1,	http://www.iso.org

[30] ISO/NP 12967-3 Service architecture -- Part 3: Computational viewpoint, http://www.iso.org

[31] ISO/TR 18307:2001 Interoperability and compatibility in messaging and communication standards -- Key characteristics, http://www.iso.org

[32] ISO/TR 20514:2005 Electronic health record -- Definition, scope and context, http://www.iso.org

[33] ISO/TR 21089:2004 Trusted end-to-end information flows, http://www.iso.org

[34] ISO/TR 22221:2006 Health informatics - Good principles and practices for a clinical data warehouse,	http://www.iso.org

[35] ISO/TR 27809:2007 Measures for ensuring patient safety of health software,	http://www.iso.org

[36] ISO/TS 17117:2002 Controlled health terminology -- Structure and high-level indicators, http://www.iso.org

[37] ISO/TS 17369:2005 SDMX (Statistical Data and Metadata Exchange), http://www.sdmx.org

[38] ISO/TS 18308:2004 Requirements for an electronic health record architecture, http://www.iso.org

[39] ISO/TS 21667:2004 Health indicators conceptual framework,	http://www.iso.org

[40] ISO/TS 25238:2007 Classification of safety risks from health software,	http://www.iso.org

[41] ISO/TS 25238:2007 Classification of safety risks from health software,	http://www.iso.org

[42] LOINC (Logical Observation Identifiers Names and Codes),	http://www.loinc.org

[43] Patient Monitoring Guidelines for HIV Care and ART, http://www.who.int

[44] PEPFAR (Presidents Emergency Plan for AIDS Relief),	http://www.pepfar.gov

[45] SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms), http://www.ihtsdo.org/snomed-ct/

[46] UNAIDS/USG Confidentiality and Security Guidelines, http://www.unaids.org

[47] UNGASS (UN General Assembly Special Session on HIV and AIDS), http://www.unaids.org


[[Back|Part 2 - Business Requirements]]

!! The Challenge 
Policy makers are faced with the task of providing leadership and national laws about health care information. It is a fast moving and highly technical field and the decisions made will affect millions of people. 

!! The Solution 
Policy makers should gather health system stakeholders together and work towards developing a nationally interoperable health system. An interoperable health system will allow stakeholders to capture, share and report on data (data use) that, through regular monitoring and evaluation reveal whether the goals of a program or intervention are successful (indicators). Important policy issues include patient identification, privacy and confidentiality and the adoption of international standards.

!! Discussion
What is the role of government policy in building a national health infrastructure?
Who are the stakeholders in my country/province/city?
Who else would be interested in reading this document?

<<options>>



[[Back|Overview]]

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

by Alvin Marcelo

In 1999 I received a small grant from our research unit. I thought about bringing together the stakeholders in the Philippine Healthcare System, to talk about standards. I don't remember what came into my mind, why I wanted them to come together, but I think many of the discussions in many of the health informatics mailing lists from that time were about interoperability and standards. I read about HL7 even if I didn't understand what HL7 was all about the source code level, I sort of agreed with what it meant at the conceptual level.

I brought together the Philippine Medical Association, which is like AMA, the Philippine Hospital Association, the Philippine Health Insurance Corporation, the Department of Health, edition 1999 and together, we crafted what we call the Standards for Health Information in the Philippines, version 99, or SHIP99.

I tried to have as wide a base as possible. They were all really just looking at me when I was talking about standards to them. They really couldn't understand why it was needed. Health informatics was very new then, even to myself, who was trying to be the proponent.

We came up with three recommendations: First, is that we should use a common minimum data set, and that the minimum data set would be the set that that is needed for reimbursement. The lead there was the Philippine Health Insurance Corporation, which is like Medicare in the US. They just listed down what elements were important to them and then we grabbed the CDC data elements for emergency department systems, by David Paula, and we got the way that DEEDS wrote update element, it should be thirty characters string, it should be alpha numeric, the last name is the name that's shared amongst all the siblings and things like that, how to redefine identification details. That was the first component.

The second component was ICD-10 for diagnosis codes. It is easy because a year before that, the Department of Health came out with a memorandum that it would be the standard coding system. I think they were just implementing a WHO recommendation.

The third component was HL7. That was where I sort of pushed my own agenda. No one knew what HL7 was all about. I didn't even understand what HL7 was all about, except that conceptually, the idea was correct. The problem was, we all signed off on that document. The problem was right before that was supposed to be published, I had to leave for my Post Doc. in National Library of Medicine. There wasn't much leadership after I left. No one took it on to push it, to get all the participating stakeholders to use ICD-10, use DEEDS, and use HL7, and even have an awareness campaign of what all of these three components mean and how they relate to the larger health informatics community, which was not really all that big at the time.

I didn't get the necessary traction that it needed. SHIP99 was published in 2001, after my two-year fellowship in NLM when I returned. It was crafted in 1999, but was not published until I came back in 2001.

So nothing came of that, except ICD-10. Because it was a law, that you cannot get reimbursement if you don't code in ICD-10. People started putting attention on ICD-10 and trying to get training from WHO on ICD-10 because if they didn't code their claims on ICD-10 then they wouldn't get paid. I thought that was a good stick to get the standards adopted.

Of course, ICD-10, many of the complaints on admissions where it was not descriptive enough clinically to store all of the clinical concepts. So in terms of interoperability, there's actually no problem right now in the Philippines because there's no exchange in data between facilities right now. The most experienced there would be HL7 within the hospitals.

A hospital would have five laboratory machines and they would like all of these machines to feed data from the machines to the clinical data repository so they would have to understand what HL7 is all about, so they can massage the data streams from the laboratories towards the clinical data repository.

So that's mostly what interoperability is working at, what level right now. It's mostly an integration of machines.

!! Recommended Reading
[[Interoperability]]
[[ICT Issues]]

!! The Challenge
An interoperable health system requires software applications to collect, process, transport and report on health data. These applications may be required at the facility, district and or national level. How do we fill this need?

!! The Solution
Applications may be acquired as ready to use applications, as systems requiring modification or they can be developed from scratch. When developing applications from scratch, effort should be made to avoid building something that already exists and to consider how the application will be supported and maintained. Furthermore, interoperability can be strengthened by releasing newly developed applications with an open source license and encouraging developers to make use of existing open source tools.

Applications written for an interoperable health system must have clearly defined points of contact between other applications that they will be interacting with. This point of contact is called an interface. For instance an application may collect data at the clinic level and pass it through an interface to a distinct district level system which then may pass it off to a different national system. These interfaces define the separate domains and make clear the domain of a specific application. Data standards are then used to communicate between applications.

Determining where to start and how to prioritize application development is a critical step. Setting priorities should be done in collaboration with both software developers and non-technical stakeholders.

Once these domains are understood and priorities are set, a software development process can guide the developers through their required activities. Software development processes and best practices are often skipped when software is developed by an individual or a team with little training or experience. However, adopting processes and best practices will lead to happier stakeholders and usually better outcomes.

Software development processes include:

* waterfall approach
* agile development and other iterative processes

These processes guide the software development team through the process of gathering requirements, developing software and quality assurance. Most modern software development follows an agile development approach, as waterfall approaches tend to result in software that is unable to adapt to changing requirements which are particularly common for the healthcare context.

Application developers should be encouraged to adhere to the following software development best practices:

* Use source control to track code revisions (git, subversion)
* Maintain a bug database (trac, lighthouse)
* Always fix bugs before writing new code or implementing new features
* Keep an up to date schedule
* Refer to a written specification
* Work in quiet conditions free from distractions
* Use dedicated testers to look for bugs and ensure that the application meets the specification

(from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000043.html)

Support and maintenance capabilities will be strengthened by having in country experts who have knowledge of how to modify the application or ideally were the original application developers.

!! Further Information
[[Maturity Model]]
[[Open Source Software]]
Source control - http://github.com, http://subversion.tigris.org/
Bug database - http://github.com, http://trac.edgewall.org, http://lighthouseapp.com

!! Examples from the Field
[[Developing a System that People Will Use - Philippines]]
Local Application Development Capacity in Malawi

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References
Brazilian Basic Health Indicators and Indicators from the Primary Care Pact [12] 


[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References
Electronic Health Record Solution Blueprint [5]
Canada Health Infoway Indicators [13]  



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!! Recommended Reading
[[Data Use]]

!! The Challenge
Getting data into an electronic format is a difficult task. Even if an appropriate question gets asked during a patient visit, it might not be recorded. Even if is recorded, it will often just be written onto a piece of paper that gets filed into a room from where it will never be seen again.

!! The Solution
Getting data into an electronic format will make it easier to be used and to be reported on than if it is just written on a piece of paper. There are three different approaches for getting data into an electronic format: first, fast and last.

FIRST: Captures electronic data at the point of care. During the caregiving session, the healthcare worker captures the data directly into some kind of electronic system. Devices that facilitate this process include: traditional computers, touchscreen computers, PDAs and cellphones. FIRST systems can provide the patient and or the healthcare worker with a printout, label or some other token to indicate that their data had been captured. In addition to capturing electronic data , the FIRST approach can also facilitate data use at the point of care. It can also improve data quality by validating data and stopping invalid data from being captured (see Improving Accuracy of Data Collection).

FAST: Data gets captured onto paper, but is quickly transcribed into a computer before the patient's visit is complete. Transcription is usually done by a data entry clerk who sits either in the room with the caregiver or close by. When FIRST is not possible, this is an important approach for patient held records like Smartcard based systems that require the data to be in an electronic format before the patient leaves the clinic.

LAST: Data gets transcribed from paper forms sometime after the patient has left the clinic. This might require moving the paper forms to a data entry site that is not located at the health facility. This is the most common approach to capturing electronic data.

!! Further Information
[[National, International and Donor Reporting]]
[[Improving Accuracy of Data Collection]]

!! Examples from the Field
First-Baobab
Fast-Smartcare
Last-Eldoret

Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #18f
PrimaryMid: #04b
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88

Connectivity - support for off-line data-entry for those places where Internet or appropriate communications are not present.

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! The Challenge
Meetings, whether face-to-face or virtual, are a primary vehicle for organizing coordinated action. How meetings are prepared, executed, and followed up on, can make the difference between success or stagnation. Because meetings are a means to an end, attention to how they are conducted is often overlooked. The result can be a waste of participants' time and the result can be very little action. This can happen even when there are very experienced and capable people meeting together with the best of intentions.

!! The Solution
Constructive meetings among stakeholders lead to group consensus and individual action. In order to have meetings where these things happen it is important to keep these goals in mind when planning, running and following up after a meeting. Some steps for having constructive meetings are described below:

1. The meeting organizers identify and engage with meeting participants well in advance of the meeting date. The initial communications include a formal meeting invitation and logistics information. A second line of communications are then be established to invite participants into the planning process. Discussion of issues is opened up, and ideas for what should be addressed at the meeting are raised. Some prompting is usually required to encourage participation in this planning process.

It is easy to discount the value of pre-meeting preparation - participants are busy, will wait for the meeting to address issues, etc. However early and wide engagement is critical to fostering a sense of ownership and responsibility for later action and follow through.

As the planning process progresses, discussions and ideas are crystallized into sessions and programmed on an agenda. This agenda can then be circulated prior to the meeting.

2. Ensure that the right stakeholders with appropriate authority or technical expertise are at the meeting. Often the wrong people are sent to meetings. Communicate the intention to hold a meeting through your networks and wider fora such as mailing lists, if appropriate. A good planning process will also encourage the right people to attend.

3. During the meeting, a meeting chair or facilitator must pay attention to the meeting dynamics and progress. Individual session leaders may have varying levels of presentation and facilitation expertise. Consensus can happen when everyone has a chance to voice their opinion and when everyone is listening. The facilitator should aim for discussion between stakeholders and try to avoid monologues. Attention to time will help keep speakers on point.

Consider thinking of the small group format as the "default" session format. This principle follows from the observation that often, the most interesting and productive time spent at meetings happens in the break times and over lunch. At these times, we see small groups of individuals having multiple conversations simultaneously. Bringing the small group format onto the agenda, we find that some degree of redundancy is a small price to pay for moving forward on several fronts at once. Then, some time for integration of the different groups can bring everyone together and up to speed. This does not need to be a comprehensive reporting back from each group: not everyone needs to know everything to the same depth as everyone else, in order to be able to act effectively. Consider other debriefing formats, therefore, other than the report back to plenary.

4. Once consensus is reached, invite individuals to commit to clear, time-bound action items.

5. Meeting notes must be taken during the meeting and sent out as soon as possible afterwards. Minutes are a great way to keep momentum going and a way to publicly remind all stakeholders about their individual action items.

6. Participants need to be engaged after the meeting, to remind them to follow up on action items and report back to the stakeholders, either as written communication or by including follow up on the agenda for subsequent meetings.

!! Discussion
1. Describe the worst meeting you have ever been to.
2. Describe the best meeting you have ever been to.
3. What motivates you to act?

!! Further Information
The Secret Sauce of Great Meetings - http://www.thepracticeofleadership.net/2008/03/24/context-purpose-dramas-and-conflict-the-secret-sauce-of-great-meetings/
Meeting Best Practices - http://hwebbjr.typepad.com/openloops/2006/05/meeting_best_pr.html

!! Experiences in the Field
[[An Interoperability Initiative - Philippines]]

|!Country|>|!Name|>|!Email|
|Australia|>|Anthony Maeder|A.Maeder@uws.edu.au|
|~|>|Ken Tallis|ken.tallis@aihw.gov.au|
|~|>|Richard Dixon Hughes|richard@dh4.com.au|
|Brazil|>|Beatriz de Faria Leão|Bfleao@gmail.com|
|Canada|>|Derek Ritz|derek.ritz@ecgroupinc.com|
|Germany|>|Bernd Blobel|bernd.blobel@klinik.uni-regensburg.de|
|Kenya|>|Samuel Cheburet|samuelcheburet@gmail.com|
|Netherlands|>|J.L.Talmon|talmon@mi.unimaas.nl|
|New Zealand|>|Mike Mair|mikemair@ihug.co.nz|
|Turkey|>|Nihat Yurt|Nihat.Yurt@saglik.gov.tr|
|United States|>|Andrew Grant|Andrew.Grant@usherbrooke.ca|
|~|>|Gora Datta|gora@cal2cal.com|
|~|>|Robert Owens|owensrlo@sbcglobal.net|

[[Back|Overview]]

Continuity of care  - allow systems to be delivered which provide for continuity of access to care across all levels of the community.

[[Lost to Followup]]


!!Relevant Standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading
[[Indicator Selection]]
[[Monitoring and Evaluation]]
[[National, International and Donor Reporting]]

!! The Challenge
A problem in health information systems is the lack of common precise definitions for data elements. Definitions may be ambiguous and there may be multiple definitions from different programs that differ in important details. Data that is collected with imprecise or diverse definitions cannot be aggregated or compared and is a significant barrier to interoperability. At the individual patient care level, mobile patients may have data generated using different definitions. This can impact the quality of patient care.

!! The Solution
Everyone generating and using data should use a shared data dictionary with agreed definitions. Definitions should be clear, complete and unambiguous. This will most likely require consensus at the national level involving all stakeholders. There are existing international vocabularies (see below) for many frequently used health data terms.

The data dictionary contains "metadata" (literally, data about data). This should be maintained by a central authority with open access. It should be mandated for all activities to use the standard data dictionary.

A data dictionary will serve as the foundation for a data warehouse which can link data from multiple sources.

!! Further Information
[[International Standards]]

!!! Vocabularies
* Logical Observation Identifiers Names and Codes (LOINC) - http://loinc.org
* Systematized Nomenclature of Medicine--Clinical Terms (SNOMED CT) - http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html
* International Classification of Diseases (ICD) - http://www.who.int/classifications/icd/en/

!! Examples from the Field

!! Recommended Reading

!! The Challenge
Useful data is tediously gathered but often used only for high level reporting. How can data be used more effectively?

!! The Solution
Using data routinely at all levels increases the value of that data. As data becomes more valued throughout the health system a data driven culture will develop. Not only does this lead to better decision making, but it can also lead to more careful data collection, and ultimately better overall data quality.

For instance, a policy maker will make better procurement decisions if they have data about which drugs are being consumed and at what rate in the field. Or, consider a nurse who has to collect data on side effects from a patient. The next time the nurse sees that patient it would be useful to know that last time they reported side effects, so that the nurse can followup with that patient. Even an aggregate report pinned to the wall at a facility can help staff know what are the most common ailments to be looking for.

Giving the data back to the initial collector at a useful time and in an appropriate format can support decision making thereby helping them do their job better. Data can also be used at points other than the point of collection and the final donor report. Patients, facility managers, districts and other donors can benefit from data as well.

When data is being used by the data collectors it tends to be captured more carefully. This is for the simple reason that the data collector knows that they will be using their own data again - hence they are motivated to make their own job easier by capturing quality data. This positive feedback loop is motivation to put electronic systems at the point of care, as they facilitate not only data collection but the use of data for patient care.

!! Further Information
[[Use it or Lose it]]
[[Data for Patient Care]]
[[Operations Management]]

!! Examples from the Field

!! Recommended Reading 
[[Enterprise Architecture]]
[[Interoperability]]
[[Business Requirements]]

!! The Challenge 
Health care systems collect a large amount of information from disparate sources. Some of this information is from multiple sources relates to the same subject. This information is potentially useful when combined and analysed as it can give a broader view and also a more comprehensive view of health. How can we collect information from multiple sources and view it in aggregate?

!! The Solution 
When the entire suite of interoperability principles are applied, aggregating and analyzing data from multiple sources becomes possible. It is necessary to have a common data dictionary, good indicator selection, and adopted international standards for data. When these are in place, data can be collected in a data warehouse. A data warehouse makes use of metadata that describes each data source so that it can be appropriately combined and analysed. 

The data warehouse also serves as a repository to allow broad access to data across activities for purposes of comparison. 

!! Further Information 
[[Data Use]]
[[Monitoring and Evaluation]]

Data Warehouse on wikipedia - http://en.wikipedia.org/wiki/Data_warehouse

!! Examples from the Field

!! Recommended Reading
[[Interoperability]]
[[Patient Identification]]

!! The Challenge
Data required for patient care is often considered to be completely separate from public health information. Does this make sense? Can we make data for patient care part of the health information ecosystem?

In resource rich environments, sharing of patient data, either within the facility, between facilities, or vertically up and down a national health information system is often a low priority. Patient data is often seen as something that is shared between patient and provider only as part of the patient encounter with a single provider.

In resource poor settings, there may not be a single provider within the facility dedicated solely to that patient. Furthermore the patient may be geographically mobile yet still require a continuity of care. Often the community or national approach would require aggregated patient data. These aggregated reporting requirements are even greater when donors are involved and have specific reporting requirement for program monitoring and evaluation.

When the reporting system is the primary driver of facility level health information systems, there is very little incentive for timely and accurate data as the reporting requirement is often not sufficient to ensure proper investment in the information system.

The scope of facility based information systems may include in resource poor settings ensuring compliance with established patient treatment guidelines, improving facility workflows, surveillance of health outcomes of patients, continuity of care of mobile populations or chronic conditions, as well as integration with other HIS systems such as laboratory results, pharmacy ordering and management, radiology and diagnostics, as well as a robust admissions and calendaring system to help manage patient flow. Some facilities may choose one aspect or another as the primary business problem depending on the most pressing needs, but all must eventually be interconnected either through interoperability standards or some form of integration to improve efficiency and quality.

!! The Solution
For any of these functions to happen in a timely and accurate way, the basic areas of interoperability from patient identification, to data dictionaries, to international standards for data transmission, to minimum data sets, as well as data quality issues must be addressed.

Using available clinical ontologies and data dictionaries to maintain comparable data, adopting existing international standards for data reuse between systems (eg lab and patient care), between facilities for mobile populations, and the reporting of data to district, national and international level, can provide a basic informatics infrastructure to use patient data effectively throughout a health information system.

When facility based information systems can provide some benefit to patient management and facility management improving the lives of the patients and the work lives of the health care workers, a stronger incentive is in place for the entry and use of timely and accurate data. The facility systems may be able to share basic practices to make facility systems more effective for local quality improvement in care and facility management. These approaches could include basic patient summaries for better triage and care, built in alerts and quality checks to improve patient care, and the ability to view patient data, either individual or from a community, to monitor outcomes and view hidden patterns for better response and resource management.

!! Further Information
[[Data Use]]
[[International Standards]]
[[Data Dictionary]]

* WHO Patient Monitoring Guidelines for HIV Care and ART - http://www.who.int/hiv/pub/imai/PatientGuide/en/index.html

!! Examples from the Field
[[An Interoperability Initiative - Philippines]]

Stories can include the dog bite story, patterns of CD4 counts to monitor potential drug resistence, Eldorets story of improving clinical perfomance of clinical team from 30 patients a day to 90 using patient summaries for better triage, Baobabs use of 'fast food technology' to reduce wait time at admissins by hours. Such improvements are drivers for more interoperable systems which can only function effectively if health informatics standards are in place and commonly implemented up front.

[[Overview]]

by Alvin Marcelo

We coded side by side with the user, more than just the rapid application development, just really having the health workers tell us, "You put this field here, you make this look red, and then the next page should look like this," and things like that. I think for the first pilot health facility, it's really their baby because they were seeing things develop in front of their eyes.

That really worked. It's still working six years later. It's a Linux based system. We're not troubleshooting anything at all. They just start on the server, they turn on the workstations, and they are still using it. I guess that's a successful story from that perspective.

The second health center was a near failure. We were thinking the first center succeeded [bad connection] with asking them to configure it, to make comments about it. As a matter of fact, what we learned there was that it actually helps for them to see the application grow along with them, and that it was a hard thing for the second health center because we were just ramming a whole application down their throat. We were telling them, "Hey! We have this electronic health record now, it's working in the first health center. We have six month's use. There's maternal care, there's vaccines, there's child's ICD Plan, etcetera etcetera." We thought we were the heroes bringing them the goods.

The second health center was a near failure. Coming from the success of the first center, we were so confident that the next one would only be too happy to get the whole system in full (and not have to bother with seeing the software develop what with all the bugs). So we essentially skipped asking them to comment on the software and rushed headlong to training them on all the modules that were available inside. Bad move. The reluctance was strong and there was no immediate ownership of the software ("It's the first center's software isn't it? not ours"). So what we learned is that it actually helps for healthworkers to see the application grow along with them (one module at a time), and that the second health center had a lot of difficulty because we were just ramming a whole application down their throat within a short period of time. Things got fixed much later (they're now going to their 6th year of using CHITS) but that was a close call. We attribute its success to the leadership and persistence of the physician in charge.

What salvaged it for us, for the second health center, was the leadership of the doctor in charge of the facility. He had the leadership to just tell the people, "Quitting is not an option, you just have to do it." As a matter of fact, for about a year, they were doing both paper and computer, can you imagine that?

They didn't get a buy-in of themselves, of the midwives. They didn't have a buy-in that the computer was stable.

On the third health center, even though we had a complete set of modules, we delivered the application to them in metered doses.

We just gave them the registration, and then two months later we showed them the maternal care, and then nine months later, because that's the time when a mother would give birth, that's the time we introduced the childcare vaccination module. That worked well from then on. In all the other health centers, we would do that kind of an approach.

It's a metered exposure to the modular system. So they get to mask one module first before going to the next one, even if the modules were already made; even if the modules are already inside. So that's the lesson we have in terms of introducing thematics at the ground level.

Right now what we're doing is we're converting the training program into a certification program so you can be certified in the registration module and then later on you can be certified in the internal care module.

So we're looking at this as a way for the midwives to start collecting their certifications and use this as sort of badges. Like Girl Scouts or Boy Scouts where you have a badge for registration because you are a master at the registration module another badge for maternal care and EPI.

So we haven't done an evaluation on that yet but we've seen a lot of interest from the participants because they feel like they've achieved something because they have a certificate to show for it.

!!!Download
This entire website (without graphics) can be downloaded as a single file that you can use even when there is no internet connection. 

Right click on the following link to save ('Save Link As') it to your local machine:
[[Downloadable Interoperability Wiki|wiki.html]]

Graphics can be saved the same way (Save Image As) in an /images directory.

After downloading the file you can double click it and the saved file will open in your browser.

[[Back|Overview]]

Type the text for 'Electronic Health Record Solution Blueprint.'

!! Recommended Reading

!! The Challenge
When confronted with the broad task of 'improving interoperability', it is easy to get confused about where to start. This document contains information about approaches to specific problems or situations but does not provide a process. It is easy to get bogged down and confused about all of the different interrelated parts that form a health information system and in the whole, the problem can seem overwhelming. Often attempts to fix one part of the system result in unintended consequences that adversely impact other parts of the system.

!! The Solution
The Open Group Architecture Framework (TOGAF) Enterprise Architecture (EA) approach provides a well documented comprehensive method to approach information system improvement. It is a cyclic iterative process to information system strengthening that ensures that the changes are aligned with the core principles and functions of the organization as well as ensuring that they have institutional support and proper design.

EA begins with a preliminary phase where the support of key stakeholders and governance structures are aligned behind the project. The effort cannot be successful without this key foundation.
Next, the enterprise architecture is articulated. This defines the scope and vision of the project.

Following that, the business architecture is developed. The business architecture phase first describes the current baseline business objectives and processes and then a target business architecture. Business architecture describes the service strategy and the information architecture to support that as well as the business environment. A gap analysis is done by looking at the differences between the current and target business architectures.

The Information Architecture includes both application and data architectures. Based on the gap analysis, the information architecture formulates the requirements for applications and data structures to support the organization's activities. These manage data and present information which is complete, consistent and stable.

Next, the Technology Architecture looks at the changes which need to be made to information, communication and technology (ICT) infrastructure to support the business, data and applications.

Following this, there is first high level and then more detailed implementation planning and execution. Following implementation, a 'Change Management' process is initiated which evaluates the impact of the changes and looks at the context of the enterprise. This is an ongoing process which can alert to organization to the need for an additional iteration of the EA process.

!! Discussion
1. What are you working on that could benefit from the Enterprise Architecture process?

!! Further Information
[[Policy and Governance]]
[[Constructive Meetings]]
[[Where Do I Start]]
[[Software Selection]]
[[Interoperability]]
Open Group TOGAF resource site - http://www.opengroup.org/togaf/

!! Examples from the Field
Papua New Guinea HIS strengthening under Sector-Wide Approach (SWAp)

Enterprise services – describes the business processes that are common to all domains, such as demographic services, terminology services, and clinical models.

[[Data Warehouse]]
[[Software Artifacts]]

!!Relevant standards

[[Electronic Health Record Solution Blueprint.]]

[[NHS Care Record and the Logical Record Architecture for Health and Social Care from UK.]]

[[eHealth Europe – European Electronic Health Record Project and the eHealth-INTEROP European Project.]]

[[WHO Statistical Data and Metadata Exchange-Health Domain (SDMX-HD).]]

[[ISO/TS 17369:2005 SDMX (Statistical Data and Metadata Exchange).]]

[[ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR).]]

[[CEN/TC 251- Published standards.]]

[[ICD (International Classification of Diseases).]] 

[[ISO 15836:2003 Dublin Core Metadata Initiative.]]

[[ISO 22857:2004 Guidelines on data protection to facilitate trans-border flows of personal health information.]]

[[ISO ITTF.]]

[[ISO/CD TR 28380-1 IHE global standards adoption -- Part 1: Process.]]

[[ISO/CD TS 21298 Health informatics -- Functional and structural roles.]]

[[ISO/DIS 17113.2 Exchange of information between healthcare information systems -- Method for development of messages.]] 

[[ISO/HL7 21731:2006 HL7 version 3 -- Reference information model -- Release 1.]] 

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments.]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments.]] 

[[ISO/HL7 NP 27951 Common terminology services, release 1.]]

[[ISO/NP 12967-3 Service architecture -- Part 3: Computational viewpoint.]] 

[[ISO/TR 18307:2001 Interoperability and compatibility in messaging and communication standards -- Key characteristics.]]

[[ISO/TR 20514:2005 Electronic health record -- Definition, scope and context.]]

[[ISO/TR 21089:2004 Trusted end-to-end information flows.]] 

[[ISO/TR 22221:2006 Health informatics - Good principles and practices for a clinical data warehouse.]]

[[ISO/TR 27809:2007 Measures for ensuring patient safety of health software.]] 

[[ISO/TS 17117:2002 Controlled health terminology -- Structure and high-level indicators.]]

[[ISO/TS 18308:2004 Requirements for an electronic health record architecture.]]

[[ISO/TS 21667:2004 Health indicators conceptual framework.]] 

[[ISO/TS 25238:2007 Classification of safety risks from health software.]]

[[ISO/TS 25238:2007 Classification of safety risks from health software.]]

[[LOINC (Logical Observation Identifiers Names and Codes).]] 

[[Patient Monitoring Guidelines for HIV Care and ART.]] 

[[SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms).]] 

[[UNAIDS/USG Confidentiality and Security Guidelines.]] 



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

/***
|''Name:''|ForEachTiddlerPlugin|
|''Version:''|1.0.8 (2007-04-12)|
|''Source:''|http://tiddlywiki.abego-software.de/#ForEachTiddlerPlugin|
|''Author:''|UdoBorkowski (ub [at] abego-software [dot] de)|
|''Licence:''|[[BSD open source license (abego Software)|http://www.abego-software.de/legal/apl-v10.html]]|
|''Copyright:''|&copy; 2005-2007 [[abego Software|http://www.abego-software.de]]|
|''TiddlyWiki:''|1.2.38+, 2.0|
|''Browser:''|Firefox 1.0.4+; Firefox 1.5; InternetExplorer 6.0|
!Description

Create customizable lists, tables etc. for your selections of tiddlers. Specify the tiddlers to include and their order through a powerful language.

''Syntax:'' 
|>|{{{<<}}}''forEachTiddler'' [''in'' //tiddlyWikiPath//] [''where'' //whereCondition//] [''sortBy'' //sortExpression// [''ascending'' //or// ''descending'']] [''script'' //scriptText//] [//action// [//actionParameters//]]{{{>>}}}|
|//tiddlyWikiPath//|The filepath to the TiddlyWiki the macro should work on. When missing the current TiddlyWiki is used.|
|//whereCondition//|(quoted) JavaScript boolean expression. May refer to the build-in variables {{{tiddler}}} and  {{{context}}}.|
|//sortExpression//|(quoted) JavaScript expression returning "comparable" objects (using '{{{<}}}','{{{>}}}','{{{==}}}'. May refer to the build-in variables {{{tiddler}}} and  {{{context}}}.|
|//scriptText//|(quoted) JavaScript text. Typically defines JavaScript functions that are called by the various JavaScript expressions (whereClause, sortClause, action arguments,...)|
|//action//|The action that should be performed on every selected tiddler, in the given order. By default the actions [[addToList|AddToListAction]] and [[write|WriteAction]] are supported. When no action is specified [[addToList|AddToListAction]]  is used.|
|//actionParameters//|(action specific) parameters the action may refer while processing the tiddlers (see action descriptions for details). <<tiddler [[JavaScript in actionParameters]]>>|
|>|~~Syntax formatting: Keywords in ''bold'', optional parts in [...]. 'or' means that exactly one of the two alternatives must exist.~~|

See details see [[ForEachTiddlerMacro]] and [[ForEachTiddlerExamples]].

!Revision history
* v1.0.8 (2007-04-12)
** Adapted to latest TiddlyWiki 2.2 Beta importTiddlyWiki API (introduced with changeset 2004). TiddlyWiki 2.2 Beta builds prior to changeset 2004 are no longer supported (but TiddlyWiki 2.1 and earlier, of cause)
* v1.0.7 (2007-03-28)
** Also support "pre" formatted TiddlyWikis (introduced with TW 2.2) (when using "in" clause to work on external tiddlers)
* v1.0.6 (2006-09-16)
** Context provides "viewerTiddler", i.e. the tiddler used to view the macro. Most times this is equal to the "inTiddler", but when using the "tiddler" macro both may be different.
** Support "begin", "end" and "none" expressions in "write" action
* v1.0.5 (2006-02-05)
** Pass tiddler containing the macro with wikify, context object also holds reference to tiddler containing the macro ("inTiddler"). Thanks to SimonBaird.
** Support Firefox 1.5.0.1
** Internal
*** Make "JSLint" conform
*** "Only install once"
* v1.0.4 (2006-01-06)
** Support TiddlyWiki 2.0
* v1.0.3 (2005-12-22)
** Features: 
*** Write output to a file supports multi-byte environments (Thanks to Bram Chen) 
*** Provide API to access the forEachTiddler functionality directly through JavaScript (see getTiddlers and performMacro)
** Enhancements:
*** Improved error messages on InternetExplorer.
* v1.0.2 (2005-12-10)
** Features: 
*** context object also holds reference to store (TiddlyWiki)
** Fixed Bugs: 
*** ForEachTiddler 1.0.1 has broken support on win32 Opera 8.51 (Thanks to BrunoSabin for reporting)
* v1.0.1 (2005-12-08)
** Features: 
*** Access tiddlers stored in separated TiddlyWikis through the "in" option. I.e. you are no longer limited to only work on the "current TiddlyWiki".
*** Write output to an external file using the "toFile" option of the "write" action. With this option you may write your customized tiddler exports.
*** Use the "script" section to define "helper" JavaScript functions etc. to be used in the various JavaScript expressions (whereClause, sortClause, action arguments,...).
*** Access and store context information for the current forEachTiddler invocation (through the build-in "context" object) .
*** Improved script evaluation (for where/sort clause and write scripts).
* v1.0.0 (2005-11-20)
** initial version

!Code
***/
//{{{

	
//============================================================================
//============================================================================
//		   ForEachTiddlerPlugin
//============================================================================
//============================================================================

// Only install once
if (!version.extensions.ForEachTiddlerPlugin) {

if (!window.abego) window.abego = {};

version.extensions.ForEachTiddlerPlugin = {
	major: 1, minor: 0, revision: 8, 
	date: new Date(2007,3,12), 
	source: "http://tiddlywiki.abego-software.de/#ForEachTiddlerPlugin",
	licence: "[[BSD open source license (abego Software)|http://www.abego-software.de/legal/apl-v10.html]]",
	copyright: "Copyright (c) abego Software GmbH, 2005-2007 (www.abego-software.de)"
};

// For backward compatibility with TW 1.2.x
//
if (!TiddlyWiki.prototype.forEachTiddler) {
	TiddlyWiki.prototype.forEachTiddler = function(callback) {
		for(var t in this.tiddlers) {
			callback.call(this,t,this.tiddlers[t]);
		}
	};
}

//============================================================================
// forEachTiddler Macro
//============================================================================

version.extensions.forEachTiddler = {
	major: 1, minor: 0, revision: 8, date: new Date(2007,3,12), provider: "http://tiddlywiki.abego-software.de"};

// ---------------------------------------------------------------------------
// Configurations and constants 
// ---------------------------------------------------------------------------

config.macros.forEachTiddler = {
	 // Standard Properties
	 label: "forEachTiddler",
	 prompt: "Perform actions on a (sorted) selection of tiddlers",

	 // actions
	 actions: {
		 addToList: {},
		 write: {}
	 }
};

// ---------------------------------------------------------------------------
//  The forEachTiddler Macro Handler 
// ---------------------------------------------------------------------------

config.macros.forEachTiddler.getContainingTiddler = function(e) {
	while(e && !hasClass(e,"tiddler"))
		e = e.parentNode;
	var title = e ? e.getAttribute("tiddler") : null; 
	return title ? store.getTiddler(title) : null;
};

config.macros.forEachTiddler.handler = function(place,macroName,params,wikifier,paramString,tiddler) {
	// config.macros.forEachTiddler.traceMacroCall(place,macroName,params,wikifier,paramString,tiddler);

	if (!tiddler) tiddler = config.macros.forEachTiddler.getContainingTiddler(place);
	// --- Parsing ------------------------------------------

	var i = 0; // index running over the params
	// Parse the "in" clause
	var tiddlyWikiPath = undefined;
	if ((i < params.length) && params[i] == "in") {
		i++;
		if (i >= params.length) {
			this.handleError(place, "TiddlyWiki path expected behind 'in'.");
			return;
		}
		tiddlyWikiPath = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the where clause
	var whereClause ="true";
	if ((i < params.length) && params[i] == "where") {
		i++;
		whereClause = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the sort stuff
	var sortClause = null;
	var sortAscending = true; 
	if ((i < params.length) && params[i] == "sortBy") {
		i++;
		if (i >= params.length) {
			this.handleError(place, "sortClause missing behind 'sortBy'.");
			return;
		}
		sortClause = this.paramEncode(params[i]);
		i++;

		if ((i < params.length) && (params[i] == "ascending" || params[i] == "descending")) {
			 sortAscending = params[i] == "ascending";
			 i++;
		}
	}

	// Parse the script
	var scriptText = null;
	if ((i < params.length) && params[i] == "script") {
		i++;
		scriptText = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the action. 
	// When we are already at the end use the default action
	var actionName = "addToList";
	if (i < params.length) {
	   if (!config.macros.forEachTiddler.actions[params[i]]) {
			this.handleError(place, "Unknown action '"+params[i]+"'.");
			return;
		} else {
			actionName = params[i]; 
			i++;
		}
	} 
	
	// Get the action parameter
	// (the parsing is done inside the individual action implementation.)
	var actionParameter = params.slice(i);


	// --- Processing ------------------------------------------
	try {
		this.performMacro({
				place: place, 
				inTiddler: tiddler,
				whereClause: whereClause, 
				sortClause: sortClause, 
				sortAscending: sortAscending, 
				actionName: actionName, 
				actionParameter: actionParameter, 
				scriptText: scriptText, 
				tiddlyWikiPath: tiddlyWikiPath});

	} catch (e) {
		this.handleError(place, e);
	}
};

// Returns an object with properties "tiddlers" and "context".
// tiddlers holds the (sorted) tiddlers selected by the parameter,
// context the context of the execution of the macro.
//
// The action is not yet performed.
//
// @parameter see performMacro
//
config.macros.forEachTiddler.getTiddlersAndContext = function(parameter) {

	var context = config.macros.forEachTiddler.createContext(parameter.place, parameter.whereClause, parameter.sortClause, parameter.sortAscending, parameter.actionName, parameter.actionParameter, parameter.scriptText, parameter.tiddlyWikiPath, parameter.inTiddler);

	var tiddlyWiki = parameter.tiddlyWikiPath ? this.loadTiddlyWiki(parameter.tiddlyWikiPath) : store;
	context["tiddlyWiki"] = tiddlyWiki;
	
	// Get the tiddlers, as defined by the whereClause
	var tiddlers = this.findTiddlers(parameter.whereClause, context, tiddlyWiki);
	context["tiddlers"] = tiddlers;

	// Sort the tiddlers, when sorting is required.
	if (parameter.sortClause) {
		this.sortTiddlers(tiddlers, parameter.sortClause, parameter.sortAscending, context);
	}

	return {tiddlers: tiddlers, context: context};
};

// Returns the (sorted) tiddlers selected by the parameter.
//
// The action is not yet performed.
//
// @parameter see performMacro
//
config.macros.forEachTiddler.getTiddlers = function(parameter) {
	return this.getTiddlersAndContext(parameter).tiddlers;
};

// Performs the macros with the given parameter.
//
// @param parameter holds the parameter of the macro as separate properties.
//				  The following properties are supported:
//
//						place
//						whereClause
//						sortClause
//						sortAscending
//						actionName
//						actionParameter
//						scriptText
//						tiddlyWikiPath
//
//					All properties are optional. 
//					For most actions the place property must be defined.
//
config.macros.forEachTiddler.performMacro = function(parameter) {
	var tiddlersAndContext = this.getTiddlersAndContext(parameter);

	// Perform the action
	var actionName = parameter.actionName ? parameter.actionName : "addToList";
	var action = config.macros.forEachTiddler.actions[actionName];
	if (!action) {
		this.handleError(parameter.place, "Unknown action '"+actionName+"'.");
		return;
	}

	var actionHandler = action.handler;
	actionHandler(parameter.place, tiddlersAndContext.tiddlers, parameter.actionParameter, tiddlersAndContext.context);
};

// ---------------------------------------------------------------------------
//  The actions 
// ---------------------------------------------------------------------------

// Internal.
//
// --- The addToList Action -----------------------------------------------
//
config.macros.forEachTiddler.actions.addToList.handler = function(place, tiddlers, parameter, context) {
	// Parse the parameter
	var p = 0;

	// Check for extra parameters
	if (parameter.length > p) {
		config.macros.forEachTiddler.createExtraParameterErrorElement(place, "addToList", parameter, p);
		return;
	}

	// Perform the action.
	var list = document.createElement("ul");
	place.appendChild(list);
	for (var i = 0; i < tiddlers.length; i++) {
		var tiddler = tiddlers[i];
		var listItem = document.createElement("li");
		list.appendChild(listItem);
		createTiddlyLink(listItem, tiddler.title, true);
	}
};

abego.parseNamedParameter = function(name, parameter, i) {
	var beginExpression = null;
	if ((i < parameter.length) && parameter[i] == name) {
		i++;
		if (i >= parameter.length) {
			throw "Missing text behind '%0'".format([name]);
		}
		
		return config.macros.forEachTiddler.paramEncode(parameter[i]);
	}
	return null;
}

// Internal.
//
// --- The write Action ---------------------------------------------------
//
config.macros.forEachTiddler.actions.write.handler = function(place, tiddlers, parameter, context) {
	// Parse the parameter
	var p = 0;
	if (p >= parameter.length) {
		this.handleError(place, "Missing expression behind 'write'.");
		return;
	}

	var textExpression = config.macros.forEachTiddler.paramEncode(parameter[p]);
	p++;

	// Parse the "begin" option
	var beginExpression = abego.parseNamedParameter("begin", parameter, p);
	if (beginExpression !== null) 
		p += 2;
	var endExpression = abego.parseNamedParameter("end", parameter, p);
	if (endExpression !== null) 
		p += 2;
	var noneExpression = abego.parseNamedParameter("none", parameter, p);
	if (noneExpression !== null) 
		p += 2;

	// Parse the "toFile" option
	var filename = null;
	var lineSeparator = undefined;
	if ((p < parameter.length) && parameter[p] == "toFile") {
		p++;
		if (p >= parameter.length) {
			this.handleError(place, "Filename expected behind 'toFile' of 'write' action.");
			return;
		}
		
		filename = config.macros.forEachTiddler.getLocalPath(config.macros.forEachTiddler.paramEncode(parameter[p]));
		p++;
		if ((p < parameter.length) && parameter[p] == "withLineSeparator") {
			p++;
			if (p >= parameter.length) {
				this.handleError(place, "Line separator text expected behind 'withLineSeparator' of 'write' action.");
				return;
			}
			lineSeparator = config.macros.forEachTiddler.paramEncode(parameter[p]);
			p++;
		}
	}
	
	// Check for extra parameters
	if (parameter.length > p) {
		config.macros.forEachTiddler.createExtraParameterErrorElement(place, "write", parameter, p);
		return;
	}

	// Perform the action.
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(textExpression, context);
	var count = tiddlers.length;
	var text = "";
	if (count > 0 && beginExpression)
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(beginExpression, context)(undefined, context, count, undefined);
	
	for (var i = 0; i < count; i++) {
		var tiddler = tiddlers[i];
		text += func(tiddler, context, count, i);
	}
	
	if (count > 0 && endExpression)
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(endExpression, context)(undefined, context, count, undefined);

	if (count == 0 && noneExpression) 
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(noneExpression, context)(undefined, context, count, undefined);
		

	if (filename) {
		if (lineSeparator !== undefined) {
			lineSeparator = lineSeparator.replace(/\\n/mg, "\n").replace(/\\r/mg, "\r");
			text = text.replace(/\n/mg,lineSeparator);
		}
		saveFile(filename, convertUnicodeToUTF8(text));
	} else {
		var wrapper = createTiddlyElement(place, "span");
		wikify(text, wrapper, null/* highlightRegExp */, context.inTiddler);
	}
};


// ---------------------------------------------------------------------------
//  Helpers
// ---------------------------------------------------------------------------

// Internal.
//
config.macros.forEachTiddler.createContext = function(placeParam, whereClauseParam, sortClauseParam, sortAscendingParam, actionNameParam, actionParameterParam, scriptText, tiddlyWikiPathParam, inTiddlerParam) {
	return {
		place : placeParam, 
		whereClause : whereClauseParam, 
		sortClause : sortClauseParam, 
		sortAscending : sortAscendingParam, 
		script : scriptText,
		actionName : actionNameParam, 
		actionParameter : actionParameterParam,
		tiddlyWikiPath : tiddlyWikiPathParam,
		inTiddler : inTiddlerParam, // the tiddler containing the <<forEachTiddler ...>> macro call.
		viewerTiddler : config.macros.forEachTiddler.getContainingTiddler(placeParam) // the tiddler showing the forEachTiddler result
	};
};

// Internal.
//
// Returns a TiddlyWiki with the tiddlers loaded from the TiddlyWiki of 
// the given path.
//
config.macros.forEachTiddler.loadTiddlyWiki = function(path, idPrefix) {
	if (!idPrefix) {
		idPrefix = "store";
	}
	var lenPrefix = idPrefix.length;
	
	// Read the content of the given file
	var content = loadFile(this.getLocalPath(path));
	if(content === null) {
		throw "TiddlyWiki '"+path+"' not found.";
	}
	
	var tiddlyWiki = new TiddlyWiki();

	// Starting with TW 2.2 there is a helper function to import the tiddlers
	if (tiddlyWiki.importTiddlyWiki) {
		if (!tiddlyWiki.importTiddlyWiki(content))
			throw "File '"+path+"' is not a TiddlyWiki.";
		tiddlyWiki.dirty = false;
		return tiddlyWiki;
	}
	
	// The legacy code, for TW < 2.2
	
	// Locate the storeArea div's
	var posOpeningDiv = content.indexOf(startSaveArea);
	var posClosingDiv = content.lastIndexOf(endSaveArea);
	if((posOpeningDiv == -1) || (posClosingDiv == -1)) {
		throw "File '"+path+"' is not a TiddlyWiki.";
	}
	var storageText = content.substr(posOpeningDiv + startSaveArea.length, posClosingDiv);
	
	// Create a "div" element that contains the storage text
	var myStorageDiv = document.createElement("div");
	myStorageDiv.innerHTML = storageText;
	myStorageDiv.normalize();
	
	// Create all tiddlers in a new TiddlyWiki
	// (following code is modified copy of TiddlyWiki.prototype.loadFromDiv)
	var store = myStorageDiv.childNodes;
	for(var t = 0; t < store.length; t++) {
		var e = store[t];
		var title = null;
		if(e.getAttribute)
			title = e.getAttribute("tiddler");
		if(!title && e.id && e.id.substr(0,lenPrefix) == idPrefix)
			title = e.id.substr(lenPrefix);
		if(title && title !== "") {
			var tiddler = tiddlyWiki.createTiddler(title);
			tiddler.loadFromDiv(e,title);
		}
	}
	tiddlyWiki.dirty = false;

	return tiddlyWiki;
};


	
// Internal.
//
// Returns a function that has a function body returning the given javaScriptExpression.
// The function has the parameters:
// 
//	 (tiddler, context, count, index)
//
config.macros.forEachTiddler.getEvalTiddlerFunction = function (javaScriptExpression, context) {
	var script = context["script"];
	var functionText = "var theFunction = function(tiddler, context, count, index) { return "+javaScriptExpression+"}";
	var fullText = (script ? script+";" : "")+functionText+";theFunction;";
	return eval(fullText);
};

// Internal.
//
config.macros.forEachTiddler.findTiddlers = function(whereClause, context, tiddlyWiki) {
	var result = [];
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(whereClause, context);
	tiddlyWiki.forEachTiddler(function(title,tiddler) {
		if (func(tiddler, context, undefined, undefined)) {
			result.push(tiddler);
		}
	});
	return result;
};

// Internal.
//
config.macros.forEachTiddler.createExtraParameterErrorElement = function(place, actionName, parameter, firstUnusedIndex) {
	var message = "Extra parameter behind '"+actionName+"':";
	for (var i = firstUnusedIndex; i < parameter.length; i++) {
		message += " "+parameter[i];
	}
	this.handleError(place, message);
};

// Internal.
//
config.macros.forEachTiddler.sortAscending = function(tiddlerA, tiddlerB) {
	var result = 
		(tiddlerA.forEachTiddlerSortValue == tiddlerB.forEachTiddlerSortValue) 
			? 0
			: (tiddlerA.forEachTiddlerSortValue < tiddlerB.forEachTiddlerSortValue)
			   ? -1 
			   : +1; 
	return result;
};

// Internal.
//
config.macros.forEachTiddler.sortDescending = function(tiddlerA, tiddlerB) {
	var result = 
		(tiddlerA.forEachTiddlerSortValue == tiddlerB.forEachTiddlerSortValue) 
			? 0
			: (tiddlerA.forEachTiddlerSortValue < tiddlerB.forEachTiddlerSortValue)
			   ? +1 
			   : -1; 
	return result;
};

// Internal.
//
config.macros.forEachTiddler.sortTiddlers = function(tiddlers, sortClause, ascending, context) {
	// To avoid evaluating the sortClause whenever two items are compared 
	// we pre-calculate the sortValue for every item in the array and store it in a 
	// temporary property ("forEachTiddlerSortValue") of the tiddlers.
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(sortClause, context);
	var count = tiddlers.length;
	var i;
	for (i = 0; i < count; i++) {
		var tiddler = tiddlers[i];
		tiddler.forEachTiddlerSortValue = func(tiddler,context, undefined, undefined);
	}

	// Do the sorting
	tiddlers.sort(ascending ? this.sortAscending : this.sortDescending);

	// Delete the temporary property that holds the sortValue.	
	for (i = 0; i < tiddlers.length; i++) {
		delete tiddlers[i].forEachTiddlerSortValue;
	}
};


// Internal.
//
config.macros.forEachTiddler.trace = function(message) {
	displayMessage(message);
};

// Internal.
//
config.macros.forEachTiddler.traceMacroCall = function(place,macroName,params) {
	var message ="<<"+macroName;
	for (var i = 0; i < params.length; i++) {
		message += " "+params[i];
	}
	message += ">>";
	displayMessage(message);
};


// Internal.
//
// Creates an element that holds an error message
// 
config.macros.forEachTiddler.createErrorElement = function(place, exception) {
	var message = (exception.description) ? exception.description : exception.toString();
	return createTiddlyElement(place,"span",null,"forEachTiddlerError","<<forEachTiddler ...>>: "+message);
};

// Internal.
//
// @param place [may be null]
//
config.macros.forEachTiddler.handleError = function(place, exception) {
	if (place) {
		this.createErrorElement(place, exception);
	} else {
		throw exception;
	}
};

// Internal.
//
// Encodes the given string.
//
// Replaces 
//	 "$))" to ">>"
//	 "$)" to ">"
//
config.macros.forEachTiddler.paramEncode = function(s) {
	var reGTGT = new RegExp("\\$\\)\\)","mg");
	var reGT = new RegExp("\\$\\)","mg");
	return s.replace(reGTGT, ">>").replace(reGT, ">");
};

// Internal.
//
// Returns the given original path (that is a file path, starting with "file:")
// as a path to a local file, in the systems native file format.
//
// Location information in the originalPath (i.e. the "#" and stuff following)
// is stripped.
// 
config.macros.forEachTiddler.getLocalPath = function(originalPath) {
	// Remove any location part of the URL
	var hashPos = originalPath.indexOf("#");
	if(hashPos != -1)
		originalPath = originalPath.substr(0,hashPos);
	// Convert to a native file format assuming
	// "file:///x:/path/path/path..." - pc local file --> "x:\path\path\path..."
	// "file://///server/share/path/path/path..." - FireFox pc network file --> "\\server\share\path\path\path..."
	// "file:///path/path/path..." - mac/unix local file --> "/path/path/path..."
	// "file://server/share/path/path/path..." - pc network file --> "\\server\share\path\path\path..."
	var localPath;
	if(originalPath.charAt(9) == ":") // pc local file
		localPath = unescape(originalPath.substr(8)).replace(new RegExp("/","g"),"\\");
	else if(originalPath.indexOf("file://///") === 0) // FireFox pc network file
		localPath = "\\\\" + unescape(originalPath.substr(10)).replace(new RegExp("/","g"),"\\");
	else if(originalPath.indexOf("file:///") === 0) // mac/unix local file
		localPath = unescape(originalPath.substr(7));
	else if(originalPath.indexOf("file:/") === 0) // mac/unix local file
		localPath = unescape(originalPath.substr(5));
	else // pc network file
		localPath = "\\\\" + unescape(originalPath.substr(7)).replace(new RegExp("/","g"),"\\");	
	return localPath;
};

// ---------------------------------------------------------------------------
// Stylesheet Extensions (may be overridden by local StyleSheet)
// ---------------------------------------------------------------------------
//
setStylesheet(
	".forEachTiddlerError{color: #ffffff;background-color: #880000;}",
	"forEachTiddler");

//============================================================================
// End of forEachTiddler Macro
//============================================================================


//============================================================================
// String.startsWith Function
//============================================================================
//
// Returns true if the string starts with the given prefix, false otherwise.
//
version.extensions["String.startsWith"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.startsWith = function(prefix) {
	var n =  prefix.length;
	return (this.length >= n) && (this.slice(0, n) == prefix);
};



//============================================================================
// String.endsWith Function
//============================================================================
//
// Returns true if the string ends with the given suffix, false otherwise.
//
version.extensions["String.endsWith"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.endsWith = function(suffix) {
	var n = suffix.length;
	return (this.length >= n) && (this.right(n) == suffix);
};


//============================================================================
// String.contains Function
//============================================================================
//
// Returns true when the string contains the given substring, false otherwise.
//
version.extensions["String.contains"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.contains = function(substring) {
	return this.indexOf(substring) >= 0;
};

//============================================================================
// Array.indexOf Function
//============================================================================
//
// Returns the index of the first occurance of the given item in the array or 
// -1 when no such item exists.
//
// @param item [may be null]
//
version.extensions["Array.indexOf"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.indexOf = function(item) {
	for (var i = 0; i < this.length; i++) {
		if (this[i] == item) {
			return i;
		}
	}
	return -1;
};

//============================================================================
// Array.contains Function
//============================================================================
//
// Returns true when the array contains the given item, otherwise false. 
//
// @param item [may be null]
//
version.extensions["Array.contains"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.contains = function(item) {
	return (this.indexOf(item) >= 0);
};

//============================================================================
// Array.containsAny Function
//============================================================================
//
// Returns true when the array contains at least one of the elements 
// of the item. Otherwise (or when items contains no elements) false is returned.
//
version.extensions["Array.containsAny"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.containsAny = function(items) {
	for(var i = 0; i < items.length; i++) {
		if (this.contains(items[i])) {
			return true;
		}
	}
	return false;
};


//============================================================================
// Array.containsAll Function
//============================================================================
//
// Returns true when the array contains all the items, otherwise false.
// 
// When items is null false is returned (even if the array contains a null).
//
// @param items [may be null] 
//
version.extensions["Array.containsAll"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.containsAll = function(items) {
	for(var i = 0; i < items.length; i++) {
		if (!this.contains(items[i])) {
			return false;
		}
	}
	return true;
};


} // of "install only once"

// Used Globals (for JSLint) ==============
// ... DOM
/*global 	document */
// ... TiddlyWiki Core
/*global 	convertUnicodeToUTF8, createTiddlyElement, createTiddlyLink, 
			displayMessage, endSaveArea, hasClass, loadFile, saveFile, 
			startSaveArea, store, wikify */
//}}}


/***
!Licence and Copyright
Copyright (c) abego Software ~GmbH, 2005 ([[www.abego-software.de|http://www.abego-software.de]])

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.

Neither the name of abego Software nor the names of its contributors may be
used to endorse or promote products derived from this software without specific
prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
***/

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!References
[4] Global Fund for HIV/AIDS, TB, and Malaria (GFATM) Monitoring and Evaluation Toolkit. 



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

National level leadership on interoperability via policy and governance is critical for effecting large scale, sustainable change. This leadership needs to work towards creating a recognized authority that will set priorities, unite stakeholders and ensure that progress is being made.

Large scale mappings of business requirements to application functionality will help a wide array of stakeholders understand the benefits of having an interoperable system. Benefits include improved health care delivery and advanced reporting. In order to bring these stakeholders to a shared vision, many meetings must take place. Constructive meetings require agendas and minutes, include the right people moving towards group consensus and result in individual action. Out of these meetings new programs will be designed according to the decisions created in these meeting. As these programs are implemented they must be carefully managed, monitored and evaluated. Key learnings must be documented and communicated back to the key stakeholders at the government level. (see program design and program management)

As new activities and programs are undertaken a careful assessment of risk is required. A clear analysis of risk will allow stakeholders to manage their risk. Risk management involves identifying, mitigating, and monitoring risks inherent to a system, project or activity. It is an attempt to systematically eliminate surprise, or at least to be well prepared for when they occur.

!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Health Services – describes the health domains that the EA will cover, with initial focus on primary care activities such as: immunization, child and maternity care, chronic diseases and special programmes such as TB, malaria and AIDS. M&E, program management, and surveillance should also be included here.

!!Relevant standards:

[[ISO/TR - Electronic health record- Definition, scope and context]]

[[ISO/TR - Good principles and practices for a clinical data warehouse (CDW)]]

[[ISO/TS 29585 - Deployment of a Clinical Data Warehouse]]

The HSR is intended to propote interoperability between patient-care systems in environments with limited connectivity. It can provide an entry-point for managing transfers of patients across systems by using a human and computer-readable transmission format.


[[Part One|http://www.healthmetricsnetwork.info/ehealtharchitecture/images/ISOTR127731.pdf]]

[[Part Two|http://www.healthmetricsnetwork.info/ehealtharchitecture/images/ISOTR127732.pdf]]

Health Services – describes the health domains that the EA will cover, with initial focus on primary care activities such as: immunization, child and maternity care, chronic diseases and special programmes such as TB, malaria and AIDS. M&E, program management, and surveillance should also be included here.

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

 



!! The Challenge 
Data collection, input, processing, and analysis is often managed by untrained personnel recruited from public health services. Results are poor data quality, a low level of analysis capacity, and limited feedback that could result in more meaningful information production. This also leads to a high rate of staff turnover and a constant need for training and retraining of data managers. 

In general, being a data technician is not a recognized career within most ministries of health. Hence a low level (salary scale wise) person is trained in an ad-hoc fashion to manage data collection. Salary level is accordingly very low and in general working with data is seen as an un-challenging and un-appealing career. The results are not surprising: low data quality and low accountability/reliability/credibility which leads to low utilization of data/reports for decision making by health service managers and policy makers.      

How can we optimize human resource systems to support health information?

!! The Solution
Data management must become a recognized professional career in public health. Creating clear job descriptions will help managers and policy makers to appreciate the role's importance. This should coincide with attractive salary schemes and clear career development paths.

Of course, good recruiting and human resource descriptions are not enough. Candidates must have the skills necessary to accomplish the job and many countries have limited technical training facilities available. Private and public universities and training institutions have to develop courses which are geared towards  the observed needs/skills of future health information system technicians. Curricula development has to be coordinated between various public health training facilities and Ministries of Health, diplomas have to be accredited/recognized by the Ministry of Education and Health. 

Good human resources practices like performance reviews and incentive schemes will help to further improve the health information system ecosystem.

!! Further Information
[[Training]]
[[Policy and Governance]]

!! Examples for from the Field
Financing of HIS, legislative/budgetary issues, coordination with Ministries of Education,  Ministries of Health, and Civil Service entities, coordinating with regional WHO regional offices  to develop “Medical Data Technician CVs“ and standards .

!! Recommended Reading

!! The Challenge
It is rare to find a healthcare context that uses no information and communications technology. Installed systems are often referred to as 'legacy systems'. Many people view legacy systems as a problem because they are often poorly designed; not collecting useful information. They can also reinforce inefficient work flow and business rules. Their advantage is that they may work and an investment has already been made in software, hardware, and training to make these systems function.

!! The Solution
In order to determine the value of existing systems, an assessment must be done. This should be an objective assessment of the software, hardware, communications infrastructure and the work flow, information streams and business processes that they represent. Human resource skills should also be assessed. These include an assessment of how well individuals understand and operate the existing systems as well as more general skills including understanding of computer operation, data manipulation, analysis, and use of data in their job performance.

The assessment should be done with the view of creating a complete picture of the existing ICT infrastructure that can be used to recommend changes. Some systems can be kept in place, some will need to be modified, others may need to be replaced completely. Special attention should be paid to interoperability of the existing systems since this will make it easier to replace parts of systems and to have the resulting structure work together smoothly.

!! Discussion
1. What software, hardware, and communications infrastructure are already in place?
2. How much training do individuals have on the existing systems? What sort of training have they received?

!! Further Information
[[Business Requirements]]
[[ICT Issues]]
[[Work Flow]]
[[Too Much Data]]
[[Software Selection]]

!! Examples from the Field
Assessment example from Ethiopia.

 
!! The Challenge 
Information and Communications Technology (ICT) is supposed to make life easier. Things are supposed to be faster, more organized and more efficient. Yet ICT often leads to frustration. Using ICT to facilitate interoperability is fraught with these same challenges. These include issues of human resources, training, support. These challenges are further compounded in a developing country context.

!! The Solution 
Strong ICT leadership by experts who have dedicated resources for providing planning and ongoing support is essential to achieving success with ICT within the health system context.

ICT is a dynamic and highly technical field. In order to derive maximum benefit from ICT an expert needs to be part of the team. This person will need to have dedicated time and other resources like computer equipment and internet access to be able to do the job effectively.

The ICT expert will facilitate the planning process. The ICT planning process (see enterprise architecture) should include lots of time for planning meetings that will result in clear action items and a timeline of activities aimed at achieving tangible goals.

Once ICT systems are in place, the expert or team of experts will need to provide support for it. Often projects get funded, built, and deployed and work for a short time before dying due to a lack of ongoing support. 

Typical support issues that may arise will include training of new staff, handling privacy, security and confidentiality issues, dealing with viruses, fixing problems with the existing system,  and responding to feature requests.

Furthermore, for ICT systems to be successful in developing countries unreliable the very physical issues of unreliable electricity, heat, dust and a general lack of understanding about electronic equipment must be considered.

!! Further Information 
[[Privacy and Confidentiality]]
[[Security]]
[[Human Resources]]
[[Constructive Meetings]]
[[Work Flow]]
[[Enterprise Architecture]]
[[Application Development]]
[[Software Selection]]
Inveneo is an NGO focusing on ICT for developing countries - http://www.inveneo.org/

!! Examples from the Field

Identifiers - be ideally supported by unique identifiers for citizens, health care workers and health care organizations. Unique identifiers would then support a Client Registry or at minimum an Enterprise Master Patient Index.

!!Relevant standards

[[ISO/TS 22220 - Identification of Subjects of Health Care]]

!!Relevant Standards


!!References




[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading 

!! The Challenge 
Health information systems and applications need to manage several types of identities for different purposes.  These identities include but are not limited to patients, health workers, applications, machines, locations and facilities. How can so many different identities across so many contexts be easily and safely reused?

!! The Solution 
Complete identity management requires a strategy for all of the following processes: 
* creation of an identity
* describing an identity
* following an identity
* revocation or deletion of an identity

Identities are linked to a specific entity. This can be a person, place, application, or an object. Being able to identify an entity enables:
* authentication of that entity for access to systems or information
* validation of that entity as the source of a message or information. This can be accomplished by using public signatures.
* role based access, which allows for a system to grant a specific level of access when the entity authenticates to that system
* auditing or attribution of activities within a system. Hence it is possible to know who or what is responsible for a given action or piece of collected data.

Different sets of identities can be managed differently, for example, maintaining a list of health facilities with a unique facility identifier for a country or region is a different process than what is used to assign a national level health identifier to all patients or all clients of a particular national or regional health system.

Identities can (but do not necessarily need to) be managed using public key infrastructure (PKI) where every entity is given a set of certificates that store the relevant details.  Public certificates are made available to the whole health system so that any application or system can request them as needed.  Private certificates (essentially private keys) are maintained only by the entity that owns the identity.  Depending on local regulations, it may be necessary to also keep a copy of private keys under escrow with an appropriately mandated authority.  Note that the PKI approach requires an advanced level of technical development and infrastructure in order to work effectively.

Software solutions for implementing different approaches to identity management are well understood and broadly available in both the commercial and open source world.  If you're writing your own directory server or certificate authority, you're doing something wrong.

!! Further Information 
[[Patient Identification]]
[[Security]]
[[Privacy and Confidentiality]]
Lightweight Directory Access Protocol (LDAP - http://en.wikipedia.org/wiki/LDAP)
Public Key Infrastructure - X.509 certificates PKI - http://en.wikipedia.org/wiki/X.509
Single sign-on

!! Examples from the Field

!! Recommended Reading 
[[Monitoring and Evaluation]]

!! The Challenge 
Life and death decisions are made everyday within the health system. Sometimes the decisions are for individual patients, and sometimes the decisions are policy and planning choices at the government level and affect large  populations.  Data (and sometimes politics and personalities) drive these decisions, but often the data that is used is inaccurate and unreliable. This data, or indicators are our condensed view of the world and determine the actions we take.  It is important that the data that goes into the indicators is timely, complete and accurate.
Often, poor quality data is blamed on the people responsible for collecting the data.  Upon closer inspection and understanding of the process it often becomes clear that the system itself contributes to poor data quality. 

!! The Solution 
Before trying to improve the quality of the data that is being collected we must ensure that we are collecting the right data (and only the necessary data so as to avoid burdening the system... see indicator selection). 

Next, we need to ensure that each data element has a complete, unambiguous definition. A regularly updated data dictionary and an accountable process is a good way to accomplish this. 

We must then design systems that collect this information accurately and reliably. Important factors include application design, work flow, training, and feedback.

Data collection systems that are well designed can both motivate people to do a good job and prevent common sources of error. Many of the topics below provide concrete approaches for improving data quality.

!! Further Information 
[[Data Dictionary]]
[[Too Much Data]]
[[Work Flow]]
[[Training]]
[[Use it or Lose it]]
[[ICT Issues]]
[[Human Resources]]
[[Interoperability]]


!! Examples from the Field 
GSM implementation
PNG RHIS and DX collection (mhs - RHIS worked and why, Dx collection didn't and why)

!! Recommended Reading
[[Monitoring and Evaluation]]

!! The Challenge
Selecting the right indicators means selecting which data can be routinely captured and will provide a clear measure of the impact of a given intervention. Unfortunately, the number of indicators tends to proliferate faster than the ability to collect good quality data. This combined with requirements by the international donor community for data for 'performance-based' reporting makes indicator management challenging.

!! The Solution
Indicators should be relevant, sensitive and accurate. They are integral part of the monitoring and evaluation process.

Many stakeholders often lead to too many indicators for the program to successfully monitor and evaluate. The "use it or lose it" approach is a simple framework to help with this.

Efforts are underway to develop global and national infrastructure for indicator management. The links below provide references for selected guidelines documents from which countries can select internationally agreed upon indicators. Successful efforts have been made to harmonize indicators in various thematic areas, more work is necessary to provide unambiguous machine-readable indicator definitions to facilitate M&E efforts. Work is underway to produce tools such as indicator and metadata registries that support robust electronic indicator definitions.

Indicator selection requires a process for definition, adoption, and harmonization. Typically, countries establish a Monitoring and Evaluation (M&E) working group to facilitate this process. Without this process in place, fragmented indicator management may persist.

!! Further Information
[[Use it or Lose it]]

http://groups.google.com/Group/Ixf-Group/Web/Indicator Reference Documents|Guidelines Documents for Selected Indicators
http://www.sdmx.org - Statistical Data and Metadata Exchange (SDMX) Standard
http://groups.google.com/Group/Ixf-Group|Indicator Transmission Format (IXF) SDMX Based Health Indicator Standard

!! Examples from the Field
UNAIDS reduction of HIV indicators from 450 to 60 by the Monitoring and Evaluation Reference Group (MERG).

Interoperability is all about making a diverse set of systems work together and ultimately accomplish tasks that could never be done if the systems were isolated. Information systems enable interoperability because of their ability to rapidly move, replicate and process data.

Successfully using information and communication technology (ICT) to enable an interoperable health system will require expert ICT leadership. The ICT field is a dynamic one that requires lots of planning. Ongoing support and training are critical ICT issues that often get overlooked. Embracing a maturity model can be a good way to move towards robust and efficient ICT management while affirming the potential for incremental success and progress during early stages.

Enterprise Architecture is a well documented and comprehensive method used to improve information systems. With a goal like "improving interoperability" or "implementing electronic health information systems", the enterprise architecture approach provides specific approaches and activities to move from broad vision to a realised system.

A critical step of the design process is an objective ICT assessment of the software, hardware and communications infrastructure. This assessment should result in an understanding of how work flow, information streams and business processes are currently operating.

An interoperable system provides a means for communication and coordination of electronic data between the various domains within a health system. This approach allows multiple applications (and stakeholders) to work together with a diverse set of tools to form a cohesive national health system. An interoperable system is contrasted with an integrated system, where all components and sub components have been adapted so that they are interlinked together from a functional, management, and data perspective. An integrated system is effectively a single system. Integrated systems are typically implemented and supported by a single vendor. Integrated systems may provide a quick path to electronic health data capabilities, but is probably not the right choice for a long term, national scale system.

When designing an information system an identity management scheme is often the right place to begin. Identities requiring management include people, places, applications and more. Management of these entities must include the full life cycle from creation, maintenance to deletion of the entity. These identities can then be used for authentication and access control. Perhaps the most important example of identity management within healthcare is the issue of patient identification. Being able to consistently identify patients across the health system enables greater leverage of any single piece of information about a patient. Algorithms exist to create uniquely identifying numbers which employ mechanisms like checkdigits to avoid error during use. Care should be taken to ensure that patient identification approaches are scalable and don't lead to abuse.

Patient information must be protected from inappropriate access and use while ensuring that proper continuity of care can be provided and that appropriate reporting and monitoring can still be carried out. Privacy and confidentiality policies should follow fair use principles like accountability, consent, limited use, openness and others. Any patient identification scheme needs to work hand in hand with privacy and confidentiality policies. Security is a related concept, and indeed good security is required for privacy and confidentiality to exist, but it certainly doesn't provide privacy and confidentiality. Security is a more general concept that enables confidentiality, integrity and availability. A security policy should be in place that ensures that all electronic health data is secured according to security best practices.

With a solid base of identity management, security, privacy and confidentiality a role based access scheme can be created. This scheme will enable the proper level of access for the appropriate people. Creating a role based access scheme depends on a careful definition of who is allowed to do what during various activities.

Most situations will require some new application development. Developers will need to have clear requirements that will help them to create the interfaces that actually enable interoperability. Development should follow proven processes and best practices.

While there are many different electronic health systems, they can generally be categorized into one of three categories when it comes to their approach for capturing electronic data: first, fast and last. "First" is when data is entered by the health care provider during the patient visit. "Fast" is when data is transcribed before the patient leaves the clinic, and last is when it is done after a patient leaves, sometimes even off-site.

The data collection approach is one of the functional requirements that must be determined when selecting software. Besides functional requirements, existing software should be examined, along with other resources like infrastructure, technical expertise and finances. Working groups can then have constructive meetings to make informed selections.

Open source software is freely available and open to modification. It is usually of a high standard, and can provide a good base from which to develop. Releasing newly developed software as open source can improve long term sustainability and connect software developers into a global team of expertise.

/***
|Name|InlineJavascriptPlugin|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.4|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|Insert Javascript executable code directly into your tiddler content.|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Documentation
>see [[InlineJavascriptPluginInfo]]
!!!!!Revisions
<<<
2009.02.26 [1.9.4] in $(), handle leading '#' on ID for compatibility with JQuery syntax
|please see [[InlineJavascriptPluginInfo]] for additional revision details|
2005.11.08 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.InlineJavascriptPlugin= {major: 1, minor: 9, revision: 3, date: new Date(2008,6,11)};

config.formatters.push( {
	name: "inlineJavascript",
	match: "\\<script",
	lookahead: "\\<script(?: src=\\\"((?:.|\\n)*?)\\\")?(?: label=\\\"((?:.|\\n)*?)\\\")?(?: title=\\\"((?:.|\\n)*?)\\\")?(?: key=\\\"((?:.|\\n)*?)\\\")?( show)?\\>((?:.|\\n)*?)\\</script\\>",

	handler: function(w) {
		var lookaheadRegExp = new RegExp(this.lookahead,"mg");
		lookaheadRegExp.lastIndex = w.matchStart;
		var lookaheadMatch = lookaheadRegExp.exec(w.source)
		if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
			var src=lookaheadMatch[1];
			var label=lookaheadMatch[2];
			var tip=lookaheadMatch[3];
			var key=lookaheadMatch[4];
			var show=lookaheadMatch[5];
			var code=lookaheadMatch[6];
			if (src) { // load a script library
				// make script tag, set src, add to body to execute, then remove for cleanup
				var script = document.createElement("script"); script.src = src;
				document.body.appendChild(script); document.body.removeChild(script);
			}
			if (code) { // there is script code
				if (show) // show inline script code in tiddler output
					wikify("{{{\n"+lookaheadMatch[0]+"\n}}}\n",w.output);
				if (label) { // create a link to an 'onclick' script
					// add a link, define click handler, save code in link (pass 'place'), set link attributes
					var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",wikifyPlainText(label));
					var fixup=code.replace(/document.write\s*\(/gi,'place.bufferedHTML+=(');
					link.code="function _out(place){"+fixup+"\n};_out(this);"
					link.tiddler=w.tiddler;
					link.onclick=function(){
						this.bufferedHTML="";
						try{ var r=eval(this.code);
							if(this.bufferedHTML.length || (typeof(r)==="string")&&r.length)
								var s=this.parentNode.insertBefore(document.createElement("span"),this.nextSibling);
							if(this.bufferedHTML.length)
								s.innerHTML=this.bufferedHTML;
							if((typeof(r)==="string")&&r.length) {
								wikify(r,s,null,this.tiddler);
								return false;
							} else return r!==undefined?r:false;
						} catch(e){alert(e.description||e.toString());return false;}
					};
					link.setAttribute("title",tip||"");
					var URIcode='javascript:void(eval(decodeURIComponent(%22(function(){try{';
					URIcode+=encodeURIComponent(encodeURIComponent(code.replace(/\n/g,' ')));
					URIcode+='}catch(e){alert(e.description||e.toString())}})()%22)))';
					link.setAttribute("href",URIcode);
					link.style.cursor="pointer";
					if (key) link.accessKey=key.substr(0,1); // single character only
				}
				else { // run inline script code
					var fixup=code.replace(/document.write\s*\(/gi,'place.innerHTML+=(');
					var c="function _out(place){"+fixup+"\n};_out(w.output);";
					try	 { var out=eval(c); }
					catch(e) { out=e.description?e.description:e.toString(); }
					if (out && out.length) wikify(out,w.output,w.highlightRegExp,w.tiddler);
				}
			}
			w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
		}
	}
} )
//}}}

// // Backward-compatibility for TW2.1.x and earlier
//{{{
if (typeof(wikifyPlainText)=="undefined") window.wikifyPlainText=function(text,limit,tiddler) {
	if(limit > 0) text = text.substr(0,limit);
	var wikifier = new Wikifier(text,formatter,null,tiddler);
	return wikifier.wikifyPlain();
}
//}}}

// // GLOBAL FUNCTION: $(...) -- 'shorthand' convenience syntax for document.getElementById()
//{{{
if (typeof($)=='undefined') { function $(id) { return document.getElementById(id.replace(/^#/,'')); } }
//}}}

!! Recommended Reading
[[Interoperable System]]

!! The Challenge
Two approaches are apparent when designing a national health information system: build (or buy) a single, monolithic integrated system or build a framework of interoperability. How can we weigh these approaches and make an informed decision about which is best?

!! The Solution
A fully integrated health information system is one where all components and sub components have been adapted so that they are interlinked together from a functional, management, and data perspective. In effect, they create a "single system". There may or may not be distinct interface points defined between the various components and several different approaches can be used to link the individual components together from common APIs, messaging buses, data standards, etc. Advantages to this approach include a potentially (but not always) lower initial cost, potentially easier management of the overall system, and a more global availability of information and functions across the entire system. There are several disadvantages however. Such systems often bind the owner of that system to a specific vendor (vendor lock-in). The level of detail of available information is often lowered for certain areas and overall requirements can impose restrictions on specific components that limit their usefulness to their direct users. (A global set of requirements and restrictions needs to be formulated for the entire user base, rather than have specific requirements so that the needs of individual stakeholders groups can be net).

Unlike in an interoperable system where the interface points are clearly defined, in an integrated system, the onus is on the owner of that system to integrate new components into the existing system. This integration exercise is specific to the component and the system itself rather than reusable, thus leading to potentially increased resource cost and risk to the owner.

Integrated systems are not better or worse than interoperable ones. They are different approaches. They may be less appropriate at the regional or national level than interoperable ones, but may be more appropriate within specific settings such as a district or a large health facility such as a hospital.

Selecting which approach to take requires a long term resource cost and risk analysis.

!! Further Information

!! Examples from the Field
Sao Paulo system
Belize system - http://health.gov.bz/moh/index.php?option=com_content&task=blogcategory&id=39&Itemid=66

Integration services - describes the business processes to allow for the construction of interoperable systems through standardized interfaces. Special attention will be given to the interfaces needed between public and private health systems, since many African countries have a public/private health delivery model.

!!Relevant Standards

[[EU Mandate 403]]

[[WHO Indicator and Metadata Registry]]

[[WHO Statistical Data and Metadata Exchange-Health Domain(SDMX-HD) aggregate data transmission format]]

[[ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR)]]

[[ISO/CD TR 28380-1 IHE global standards adoption -- Part 1: Process]]

[[ISO/CD TS 21298 Health informatics - Functional and structural roles]]

[[ISO/DIS 17113.2 Exchange of information between healthcare information systems - Method for development of messages]]

[[ISO/HL7 21731:2006 HL7 version 3 - Reference information model - Release 1]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 - An application protocol for electronic data exchange in healthcare environments]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 - An application protocol for electronic data exchange in healthcare environments]]

[[ISO/NP 12967-3 Service architecture - Part 3: Computational viewpoint]]
[[ISO/TR 18307:2001 Interoperability and compatibility in messaging and communication standards - Key characteristics]]

[[ISO/TS 17369:2005 SDMX (Statistical Data and Metadata Exchange)]]
[[ISO/DIS 21090 Health Informatics Harmonized Data Types]]

[[ISO 13606-1:2008 Health informatics - Electronic health record communication - Part 1: Reference model]]

[[ISO 13606-2:2008 Health informatics - Electronic health record communication - Part 2: Archetype interchange specification]]

[[ISO 13606-3:2009 Health informatics - Electronic health record communication -- Part 3: Reference archetypes and term lists]]



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

International reporting can include reporting to multilateral organizations, bilateral organizations, and private foundations for either Monitoring and Evaluation(M&E), annual reporting, or performance monitoring purposes. For donor organizations, continued funding is often dependant on satisfying performance measures.    

!!Relevant Standards

[[PEPFAR (Presidents Emergency Plan for AIDS Relief)|http://www.pepfar.gov/guidance/index.htm]] 

[[Joint United Nations Programme on HIV/AIDS (UNAIDS) - Guidelines on Construction of Core Indicators.|http://data.unaids.org/pub/manual/2009/jc1676_core_indicators_2009_en.pdf]]

[[Basic Indicators – Pan-American Health Organization – PAHO|http://new.paho.org/hq/index.php?option=com_content&task=blogcategory&id=1775&Itemid=1866]]

[[Brazilian Basic Health Indicators and Indicators from the Primary Care Pact|http://www.ibge.gov.br/english/estatistica/populacao/indic_sociosaude/2009/default.shtm]]

[[Canada Health Indicators|http://www.cihi.ca/cihiweb/dispPage.jsp?cw_page=indicators_e]]

[[WHO Indicator and Metadata Registry (IMR)|http://www.who.int/gho/indicatorregistry]]

[[Global Fund for HIV/AIDS, TB, and Malaria (GFATM) Monitoring and Evaluation Toolkit|http://www.theglobalfund.org/documents/me/M_E_Toolkit.pdf]]



[[Back|Overview]]

!! Recommended Reading
[[Interoperability]]

!! The Challenge
As technology becomes more integrated into the healthcare system a great diversity of software and systems proliferate. To effectively leverage these systems beyond their local contexts they need to work together. Working together means sharing data and sending reports between systems. What tools exist that can facilitate sharing data and sending reports? How do we know which standard is the right one? Isn't it easier to ignore these complex standards and just build something simple that meets our immediate needs?

!! The Solution
Sharing data and reports requires a messaging system to exchange data in a manner that defines structure and meaning. Numerous internationally accepted and used standards are listed below. Unfortunately there are many standards and quite a lot of overlap and redundancy among them.

In theory, adopting international standards seems easy and straightforward. On first glance it appears that someone has already done all of the hard work of figuring out the optimal way of sharing information. In practice, it can be quite difficult to adapt international standards to local use. There are often many (often subtle) differences in the definitions and other meta data that must be resolved. In the short term, it may be easier to use local or national standards while the process of harmonization with international standards proceeds. However, the effort should be made to adopt international standards since this will be a good investment in technologies that will enable interoperability amongst future systems and international organizations. Like many short-term/long-term trade-offs this can be a difficult sell, but staying focused on the big picture of interoperability will help encourage prudent policy making.

It is also important to become an active participant in the development of these standards. This sort of feedback can help make the standards more robust and generally applicable.

!! Further Information
[[Business Requirements]]
[[Policy and Governance]]
[[Use of Data Standards]]

!!! System Integration
* Health Level Seven (HL7 - http://hl7.org) - patient level data exchange format.
* Statistical Data and Metadata Exchange (SDMX - http://sdmx.org) - Aggregate data exchange format.
* SDMX-HD (Health Domain) - WHO supported summary data exchange format for health indicators (http://groups.google.com/group/sdmx_hd).

!!! Web standards
* REST - a simple web services API that enable web based applications to gain interoperability - http://en.wikipedia.org/wiki/Representational_State_Transfer

!!! Standards Organizations
* International Organization for Standardization (ISO) - http://www.iso.org
* European Committee for Standardization (CEN) - http://www.cen.eu

!!! Other Resources
* Standards Wiki - http://www.healthmetricsnetwork.info/site/standards
* Healthcare Information and Management Systems Society (HIMSS) - http://www.himss.org
* American Medical Informatics Association (AMIA) - http://www.amia.org
* International Medical Informatics Association (IMIA) - http://www.imia.org

!!! Organizations Developing International Reporting Standards
* Global Fund to Fight AIDS, Tuberculosis, and Malaria (GFATM) - http://theglobalfund.org
* Presidents Emergency Plan for AIDS Relief (PEPFAR) - http://www.pepfar.gov
* UN General Assembly Special Session on HIV/AIDS (UNGASS) - http://www.un.org/ga/aids

!! Examples from the Field
UNAIDS case study - How standards streamlined international reporting.

!! Recommended Reading 
[[Data for Patient Care]]

!! The Challenge
The world of healthcare is full of systems. Sometimes they are paper based, sometimes they are electronic. They are operated in different locations by different people for different purposes. While the ultimate goal might be improving health, the systems tend to be focused on generating reports, supporting healthcare workers, billing patients, and many other things. Sometimes the systems work with patient level data and sometimes they work with aggregated data and statistics. Most of the time these systems are unable to share information. This results in a lot of data being collected and recollected, or transcribed by hand from printouts or registers, or simply never used. How can these systems be connected to work together?

[[Vertical Systems]]

!! The Solution 
"'Interoperability' means the ability to communicate and exchange data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks in various settings, and exchange data such that clinical or operational purpose and meaning of the data are preserved and unaltered."1 (From Executive Order of the President of the United States)

Data interoperability among electronic systems can be facilitated by adopting international standards for messaging and content like HL7 and SDMX, and SNOMED, ICDx, and others, respectively. The use of data standards does not necessarily make for an effective M&E system. 

Clinical Data:
[[HL7]]
[[Terminologies]]
[[Health Summary Record (HSR)]]

Summary Data:
[[SDMX-HD]]
[[WHO Indicator and Metadata Registry]]

!! Further Information 
[[Interoperable System]]
[[Integrated System]]
[[International Standards]]
[[Data Use]]

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!!References
Guidelines on Construction of Core Indicators [9]  



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

/***
|Name:|LessBackupsPlugin|
|Description:|Intelligently limit the number of backup files you create|
|Version:|3.0.1 ($Rev: 2320 $)|
|Date:|$Date: 2007-06-18 22:37:46 +1000 (Mon, 18 Jun 2007) $|
|Source:|http://mptw.tiddlyspot.com/#LessBackupsPlugin|
|Author:|Simon Baird|
|Email:|simon.baird@gmail.com|
|License:|http://mptw.tiddlyspot.com/#TheBSDLicense|
!!Description
You end up with just backup one per year, per month, per weekday, per hour, minute, and second.  So total number won't exceed about 200 or so. Can be reduced by commenting out the seconds/minutes/hours line from modes array
!!Notes
Works in IE and Firefox only.  Algorithm by Daniel Baird. IE specific code by by Saq Imtiaz.
***/
//{{{

var MINS  = 60 * 1000;
var HOURS = 60 * MINS;
var DAYS  = 24 * HOURS;

if (!config.lessBackups) {
	config.lessBackups = {
		// comment out the ones you don't want or set config.lessBackups.modes in your 'tweaks' plugin
		modes: [
			["YYYY",  365*DAYS], // one per year for ever
			["MMM",   31*DAYS],  // one per month
			["ddd",   7*DAYS],   // one per weekday
			//["d0DD",  1*DAYS],   // one per day of month
			["h0hh",  24*HOURS], // one per hour
			["m0mm",  1*HOURS],  // one per minute
			["s0ss",  1*MINS],   // one per second
			["latest",0]         // always keep last version. (leave this).
		]
	};
}

window.getSpecialBackupPath = function(backupPath) {

	var now = new Date();

	var modes = config.lessBackups.modes;

	for (var i=0;i<modes.length;i++) {

		// the filename we will try
		var specialBackupPath = backupPath.replace(/(\.)([0-9]+\.[0-9]+)(\.html)$/,
				'$1'+now.formatString(modes[i][0]).toLowerCase()+'$3')

		// open the file
		try {
			if (config.browser.isIE) {
				var fsobject = new ActiveXObject("Scripting.FileSystemObject")
				var fileExists  = fsobject.FileExists(specialBackupPath);
				if (fileExists) {
					var fileObject = fsobject.GetFile(specialBackupPath);
					var modDate = new Date(fileObject.DateLastModified).valueOf();
				}
			}
			else {
				netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
				var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
				file.initWithPath(specialBackupPath);
				var fileExists = file.exists();
				if (fileExists) {
					var modDate = file.lastModifiedTime;
				}
			}
		}
		catch(e) {
			// give up
			return backupPath;
		}

		// expiry is used to tell if it's an 'old' one. Eg, if the month is June and there is a
		// June file on disk that's more than an month old then it must be stale so overwrite
		// note that "latest" should be always written because the expiration period is zero (see above)
		var expiry = new Date(modDate + modes[i][1]);
		if (!fileExists || now > expiry)
			return specialBackupPath;
	}
}

// hijack the core function
window.getBackupPath_mptw_orig = window.getBackupPath;
window.getBackupPath = function(localPath) {
	return getSpecialBackupPath(getBackupPath_mptw_orig(localPath));
}

//}}}

!! The Challenge
Chronic medical conditions and treatments such as tuberculosis treatment or anti-retroviral therapy require regular visits to monitor progress and adjust therapy. This typically means that a patient has to visit a clinic every few months, but could consist of other arrangements, for example through home visits by community health workers.
When a patient stops visiting the facility, after some period of time the patient is referred to being "lost to followup". It is important to quickly and accurately identify patients that are lost to followup in order to return them to proper treatment. Lost to followup also has an impact on programme monitoring and patient populations. Lack of clear and consistent definitions around lost to followup can also cause confusion.

!! The Solution
Developing a precise definition of lost to followup is probably the most critical issue when it comes to interoperability. Some times lost to followup is when a patient has exceeded a certain number of days since they were last seen at the clinic. This works fine when all patients are on the same treatment program and all visit the clinic at regular intervals. This is not an effective approach when some patients are given a one month supply of medication and expected to return in four weeks while others are more stable and may not be back for six months. If the definition states that lost to followup is "has not been to the clinic in three months" then many of the most stable patients will be flagged as lost to followup. A more precise definition then might be "a patient has not been to the clinic within one month of their most recent drug supply running out". This definition is more precise, but requires additional data points to determine a patient's lost to followup state. A more sophisticated lost to followup calculation tends to require an electronic data system so that health care workers are not spending too much time doing complex calculations.

Identifying when a patient is lost to followup is the first step. A patient that is lost to followup needs to be located to find out why they have stopped treatment. Good procedures for patient identification in particular are critical. Patient demographic information like address, age and phone number must be recorded either in an electronic system or in paper registers and kept up to date so that patients can be found.

The act of going out and finding a patient is often performed by community leaders, community health workers, home based health care providers, expert patient peer groups as well as nurses and clinicians.

Systems must be able to account for patients that transfer out, that die or that successfully complete treatment and are no longer part of the program in order to properly account for their entire population.

!! Further Information
[[Patient Identification]]
[[Identity Management]]
Aidsmap article about loss to follow-up - http://www.aidsmap.com/en/news/2FEE60BA-1C95-4577-9CB7-B6480FC153B3.asp

!! What is this document?
This document gives policy makers, implementors, donors and other health information stakeholders tools and perspectives that will enable them to create effective and efficient national scale electronic health information systems.  Because every hospital, disease, country and indeed the individual using this document is different, it has been designed to be responsive to different needs. Hence, it was not designed as a document to be read from beginning to end. Instead it is an extensively hyperlinked (cross referenced) document that encourages the user to follow a uniquely relevant path through the work. We have not tried to provide all of the answers -- an impossible task given the wide range of situations -- but instead raise important questions to consider and provide suggestions on how to arrive at the answers.

[[Patient Care]]
[[Monitoring and Evaluation]]
[[International Reporting]]

[img[http://www.healthmetricsnetwork.info/ehealtharchitecture/images/eHealth_Landscape.gif]]

!!Other
[[Handbook Introduction]]

[[Download or Print]]

[[Overview]]
!!
[[Part 1 - Environmental Scan]]

[[Part 2 - Business Requirements]]
!!
[[Contacts]]
[[Download]]

[[AdvancedOptions]]

A maturity model is a way of describing how far along something has evolved. It works like a long term road map with the eventual goal being to formalize processes, programs and systems. But instead of simply being a path that must be followed in order for eventual success to occur a maturity model affirms that incremental success and progress can occur during early stages.

A typical maturity model defines the following five stages:

1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.

2. Repeatable (project management, process discipline) the process is used repeatedly.

3. Defined (institutionalized) the process is defined/confirmed as a standard business process.

4. Managed (quantified) process management and measurement takes place.

5. Optimizing (process improvement) process management includes deliberate process optimization/improvement.

These can also be thought of as a continuum, where one end is focused on simple problem solving, followed by innovation, scaling up and then full interoperability between all involved components.

A variety of 'Maturity Models' exist for evaluating capacity. These can be useful for developing a phased strategy for development. The following graphic, adapted from Walker et al., shows how this might be a useful way to describe the situation in low-income countries.

!!Monitoring Maturity Model (MMM)

!!Requirements Analysis and Project Phasing
Note that both individual and summary data are part of a population-based monitoring system. With a lag between the rollout electronic medical record systems and an immediate need for natioal and international reporting both individual and summary systems may be needed to obtain population-based data. Within this context, the requirements for a monitoring system need to be prioritized and phased to guide project progress.

!!References

Software Development
http://www.sei.cmu.edu/cmm/

Interoperability
http://www.nehta.gov.au/index.php?option=com_docman&task=doc_view&gid=220&Itemid=139

http://ec.europa.eu/idabc/servlets/Doc?id=19529

Walker et al. http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.10/DC1

Open Source Software
http://qualipso.org/node/103

Walker et al. http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.10/DC1

[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

Methodology - be constructed using a framework of unified best practices of software engineering methodologies, leading to robust, scalable, distributed, user-friendly software and health architecture based on thoroughly documented functionalities and interoperability requirements.

[[Phasing]]
[[Vendor Relations]]
[[Information System Design]]

!!Relevant Standards


!!References




[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Monitoring Framework - to develop a recognized quality monitoring framework which includes a staged developmental model for both health care professionals and IT providers. Creating a fully interoperable health system is a long process with a far reaching long term goal. Often the task is so daunting that stakeholders don't know where to start. The following graphic illustrates various scenarios for the development of a monitoring system.

In low-income countries, a strategy that balances development of systems for patient-care and international reporting can provide a path to timely population-based monitoring. Since both types of systems often pre-exist in a country, such a strategy would be cost-effective if effective data exchange can be implemented via a mechanism to exchange summary data with standard meaning in a standard format.

Results-based Monitoring and Evaluation, which requires documented performance measures, is driving enhancements such as target-setting and reporting of facility-level project and financial data. This presents an opportunity to develop a global monitoring infrastructure to enable seamless flow of data between the facility, subnational, national, and international levels.
Monitoring in addition to development of patient-care systems is consistent with public health history. Indeed, four of the top ten Global Fund indicators do not come from a clinical record.

The ISO 21667 Health Indicators Conceptual Framework elaborates a broad view of health further in a framework for classifying indicator definitions, as seen below.

A monitoring system framework could be based on an infrastructure consisting of three parts:
*Indicator Vetting and Harmonization Processes
*Indicator Registries
*Individual and Summary Country Reporting Systems

The system is based on a system of interoperable computer applications using a common data exchange format for summary data.

The diagram above shows the use of Health Level Seven (HL7)and Statistical Data and Metadata Exchange - Health Domain(SDMX-HD)to exchange data. Logically similar to the use of transmission formats like HL7 to link hospital systems containing patient data, the SDMX-HD is used to link systems producing or consuming aggregate data. A format for sharing aggregate data makes data available in low-connectivity environments, facilitating development of monitoring infrastructure.

!!Current Situation
Monitoring systems in low-resource countries have historically depended on tools like spreadsheets, vertical systems, and geographic mapping applications to store and manage data. A need for more robust data repositories emerged to support Monitoring and Evaluation (M&E) analyses as disaggregation, indicator management, and other weaknesses in design and scalability of applications became apparent.

In the absence of a common means to standardize and exchange indicator definitions, a proliferation of guidelines documents from international organizations paralleled the proliferation of systems in countries to collect that information as shown below.

Increasingly, countries complained of being burdened with international reporting requirements, often reporting the same information in different required formats to multiple recipients and diverting scarce expertise to this task.

!!Development of Monitoring Infrastructure
Central to the development of this framework are contributions from the informatics community in data standards. The Statistical Data and Metadata Exchange (SDMX) standard, an ISO standard for describing statistical data, in particular, has been useful. Other aspects include increasing maturity of organizational work processes, the UNAIDS Monitoring and Evaluation Reference Group (MERG) being a notable example, and development of a variety of monitoring applications like CRIS (UNAIDS), DHIS, Devinfo (UNICEF). The three components are described as follows:

!!!Indicator Vetting and Harmonization Processes
Global organizations typically develop separate guidelines for local programme management and reporting. As indicator definition shifts from being organization or program-specific to being reference group-based, development of universally-accepted definitions will be encouraged. The UNAIDS MERG is a good example of inter-organizational indicator development.

!!!Indicator Registries
Development of the [[WHO Indicator and Metadata Registry|http://apps.who.int/gho/indicatorregistry/App_Main/browse_indicators.aspx]] is a tool to facilitate harmonization of indicator definitions across organizations. Analysts in reference groups can create, manage, harmonize, and publish global indicator definitions, which can be downloaded directly into computer applications. Multi-organizational views of metadata provides support for duplicative indicator definitions while harmonization efforts proceed.

Complete indicator specifications, i.e. concept and metadata, provide guidance on data collection methodology, metadata required, and disaggregation, giving clear direction to both analysts and system developers. Electronic indicator definitions help to promote standard data-collection methodology and international standards with documentation and structure built into indicator definitions.
The SDMX-HD is the health domain's implementation of the ISO SDMX standard for aggregate data exchange3. Adoption of a standard transmission format alone, however, is not sufficient to permit data exchange. If a process for insuring conformance between implementations is not in place, then the data will not be comparable despite a standard syntax. The IMR addresses the harmonization of semantic content while the SDMX-HD addresses the syntax or 'boxcar' for the information. SDMX Metadata Common Vocabulary takes this further by attempting to standardize both for common statistical concepts across domains.

!!!Individual and Summary Country Reporting Systems
An added benefit of implementing data interchange standards in applications has been to promote differentiation of software. A combination of clinical, monitoring, analytic and geographic mapping software which can exchange data can provide a cost-effective comprehensive solution for countries.

!!Way Forward
Integration of clinical systems with HL7 messaging complements integration of M&E systems with the SDMX-HD. Use of the two standards permits horizontal integration of clinical systems and vertical interoperability in the M&E system, helping to break down 'silos' of data, providing a seamless flow of data from the facility to district, national, and international levels. An opportunity exists to strengthen monitoring systems in addition to the improvement of patient care with international reporting requirements for UNGASS, Global Fund, and PEPFAR driving demand for facility-level data. This does not preclude the development of national clinical data warehouses as a longer-term goal, when required.

The global monitoring system schematic includes multiple domains in addition to different implementation scenarios. These scenarios vary depending on country circumstances such as existence of clinical systems, administration, connectivity, the location of aggregation of individual data, and other factors.

The mix of aggregate and individual-data systems and their location in the country reporting system will vary. Development of a Monitoring Maturity Model (MMM), adding another dimension to the one below for example, would be useful to describe individual and summary data systems in countries.

Being able to accomodate both types of systems, data can move seamlessly from the facility or from the district to the international level, establishing the processes upon which future systems can evolve.

The data exchange standards are the heart of the monitoring architecture. The data exchange formats enable legacy, vertical, and local systems to be integrated into 'one' national Monitoring and Evaluation system, which includes clinical, population-based, geographic, financial or programmatic data.

Creating a process for distribution of global indicator definitions, implementing standard data exchange formats, and developing technical capacity will accelerate the development of a global monitoring system. Components of this architecture have been developed and implemented at WHO with the development of the SDMX-HD and IMR.

Indicator registries provide a link between developers of indicator definitions and the informatics staff responsible for implementing them in systems. By pursuing development of interoperable systems, the Public Health Informatics community has the opportunity to simultaneously de-verticalize reporting systems, build sustainable country monitoring infrastructure, and satisfy international reporting requirements.

!!Relevant standards
Health informatics – Health Indicators conceptual framework. ISO/TS 21667:2004(E). April 2004.

[[Health Level Seven (HL7)|http://www.hl7.org]]

[[SDMX-HD|http://www.sdmx-hd.org]]

[[Statistical data and Metadata Exchange (SDMX)|http://www.sdmx.org]]

[[Maturity Models|http://www.sei.cmu.edu/cmm/]]

Other Interoperability references:
http://www.nehta.gov.au/index.php?option=com_docman&task=doc_view&gid=220&Itemid=139
http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.10/DC1
http://ec.europa.eu/idabc/servlets/Doc?id=19529

[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Good ideas are launched, new programs deployed and interventions implemented, but how do we know when they succeed? How can we measure success? Even when a monitoring and evaluation system is in place to measure success they may measure things that don't really indicate success. Often, there are so many different data elements to measure and collect that the team is overwhelmed with too much data and is unable to do useful analysis and provide meaningful results.

In many cases the measured indicators do help determine when success is happening, but the results are not shared with the people managing the program. This information gap means that the people that might benefit most from the information never see it.

[[Monitoring Framework]] - to develop a recognized quality monitoring framework which includes a staged developmental model for both health care professionals and IT providers;

!!Indicator Selection
Indicator selection is core to the M&E process, and these indicators should be relevant, sensitive and accurate. Having a large number of stakeholders often leads to too many indicators for the program to successfully monitor and evaluate.

Another problem is that similar programs monitor and evaluate their programs in different ways, with different success indicators and with different tools. This makes it difficult to compare programs. Comparing similar programs is a great way to tease out critical success factors.

[[WHO Indicator and Metadata Registry]]

!!Data Use for Improved Patient Care and Project Management
It is critical that the collected information and reports from the M&E activities is used for the routine management of the program. Often M&E is not integrated with program management but rather used only at higher levels at long intervals. This reduces the management potential of the information. This can be as simple as sending a copy of the M&E report to a clinic, or something more complex like using the results of the collected to indicators to determine staff pay and bonuses. If data for patient care is used for M&E activities then the analysis done will almost certainly support patient care as well. This sort of data use can create feedback loops that can lead to improved data quality and more effective programs. Indicators will give decision makers the information they need to make adjustments to personnel, resources, activities, and supervision to fine tune the program performance.

In order for these indicators to have meaning between clinics, districts and even countries, the indicators must be clearly defined with accepted standards. This facilitates interoperability. M&E should be an integral and ongoing activity throughout the life of the project.

As the stakeholders guide the roll out of activities and programs, monitoring and evaluation tools and approaches will be used to measure impact. Monitoring and Evaluation (M&E) fills in the gap of being unable to manage that which is not measured. Specifically it consists of implementing routine tasks to collect, evaluate and act on program indicators in an effort to achieve overall success. Besides simply measuring success in isolation, monitoring and evaluation activities should facilitate comparison of similar programs both within the country and abroad by adopting international standards.

Monitoring of systems isn't just useful for measuring success, but also for delivering some very specific health care services. Finding patients who have been lost to follow up is a good example of the importance of creating precise definitions and capturing data that will enable a specific activity - in this case locating patients and getting them back on treatment.

As data is leveraged for more effective monitoring and decision making, the importance of the data's accuracy increases exponentially. Hence improving the accuracy of data collection is important. Making sure that the right data is being collected, that its meaning is clear and that the system themselves facilitate accurate data collection can help. One simple approach for improving the accuracy of data collection is to simply remove all data elements that are not used. Use it or lose it - far too often extraneous data elements are added to monitoring and evaluation requirements, but these additions can jeopardize data quality and all of the decisions that depend on them.

Understanding how data flows from patient to healthcare worker all the way up to policy makers and donors enables further monitoring, management and leverage of data. By creating a visual map of this work flow, these processes may be coordinated and made more efficient and the information can be used effectively throughout all levels of the system.

!!Relevant standards:

[[GFATM M&E Toolkit.]]

[[PEPFAR (Presidents Emergency Plan for AIDS Relief).]]

[[UNGASS (UN General Assembly Special Session on HIV and AIDS).]]

[[Joint United Nations Programme on HIV/AIDS (UNAIDS) - Guidelines on Construction of Core Indicators.]]

[[Routine Health Information Network – RHINO.]]

[[Basic Indicators – Pan-American Health Organization – PAHO.]]

[[Brazilian Basic Health Indicators and Indicators from the Primary Care Pact.]]

[[Canada Health Indicators.]]

[[WHO Indicator and Metadata Registry (IMR).]]

[[Health Metrics Network Framework and Standards for Country Information Systems.]]

[[Global Fund for HIV/AIDS, TB, and Malaria (GFATM) Monitoring and Evaluation Toolkit.]]

[[ISO/TS 21667:2004 Health indicators conceptual framework]]

[[Back|2.4 General Requirements]]

!! Recommended Reading
[[Indicator Selection]]
[[Interoperability]]

!! The Challenge
Reports attempt to present useful information to decision makers in a concise fashion. Within the health system context there are so many different uses for the information gathered that each use tends to require their own report. This is particularly true when the reports are at the national, international and donor levels. Creating these reports places a large burden on the stewards of the information. How can we reduce this burden?

Furthermore, there is an inherent tension between an immediate demand for international reporting of summary data and a longer-term goal to develop systems that improve patient care. Because the demands for the international reporting systems come from funding sources, they tend to be prioritized. Is there a way to create the required reports and strengthen patient care?

!! The Solution
While international agreements and donor reporting requirements require countries to report summary indicators progress has been made in harmonising these indicators. This means that various international organizations like the WHO, the US Government and the Global Fund are working together to ensure that their reporting requirements are not different. The goal is that only one report will be needed to satisfy multiple donors. Implementors can take advantage of this harmonisation by aligning their indicators accordingly. Policy makers, donors, and stakeholders need to ensure that implementors are aware and using these indicators.

While it may appear that there is tension between high level reporting and patient level data, the former can not exist without the latter. Without high quality patient level data it is impossible to have reliable high level reports. Therefore priority must be given to capturing high quality data for patient care.

Modern Monitoring and Evaluation systems support importing standard indicator definitions defined at national or international levels. Standard data exchange formats like the WHO SDMX-HD help to promote standard information exchange. Parallel efforts to implement summary Monitoring and Evaluation systems and patient care systems will provide population-based data as the monitoring and reporting infrastructure evolves.

!! Further Information
[[Data Use]]
[[Data for Patient Care]]

!! Examples from the Field

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!! Recommended Reading

!! The Challenge
Governments and healthcare providers around the world are building electronic systems for health care. Buying software is expensive, and developing it from scratch even more so. Is there a way that all of this work and expense can be shared thereby enabling even better systems to exist?

!! The Solution
Open source software is software that does not require paying for a license in order to use. But is is more than just free. Open source software also comes with the source code freely available. Having the source code means that the system is completely open for modification. This means that an open source patient registration system used in Argentina could be downloaded and the software modified to make it work in Armenia. Instead of having to start from nothing, open source software can provide a solid base upon which to build interoperable health systems. Open source software is typically of very good quality as the source code tends to more heavily scrutinized as a result of its open nature. Policies should be put in place and developers should be encouraged to adopt open source software.

Furthermore, when software is developed it should be released as open source. Releasing and publishing software as open source can improve its sustainability if other sites adopt the same software. Open source software that is being developed locally can benefit from being part of a global community of expert software developers and in many cases healthcare information system experts. It is also a good model to match government and donor intentions around intellectual property.

!! Further Information
[[Application Development]]

Open Medical Record System - http://openmrs.org
Open Source Healthcare Alliance - http://www.oshca.org

!! Examples from the Field

!! Recommended Reading
[[Monitoring and Evaluation]]
[[Indicator Selection]]

!! The Challenge
Without access to reliable, timely and compatible data from a variety of information sources, managing a health system at a district or national level becomes extremely difficult. Some countries may not have current or accurate data on their health work force, their health services, financial flows or stock management. Without this, waste and ineffective health systems result.

!! The Solution
Health officers at the district and national level need coherent and accurate data to manage resources within a health system. Data about facilities, patients, and services must be uniquely identified and collected in a usable way. Disparate data sources can be combined and compared for better resource management. For example, comparing overall expenditure to morbidity can help to target critical health needs, or comparing patient information with pharmaceutical ordering can reduce the likelihood of dangerous stock outs or waste from expired medical materials that have been over ordered. The data transfer standards may be individual or aggregate, and may cover a variety of distinct sources within an Health Information System, from EMRs, to pharmaceutical tracking systems, to stock management, to human resources management.

!! Further Information
[[Identity Management]]
[[Patient Identification]]
[[Data Use]]

!! Examples from the Field
TEHIP experience in Morogoro district Tanzania making the funding case for bednets for malaria prevention by using district morbidity and expediture data, DHIS, HIVQual in Uganda, IRIS for HR management, National Medical stores system in Tanzania, PIH pharma ordering in Rwanda

Note: Make sure 'Hide editing features when viewed over HTTP' in Advanced Options is unchecked. 

!! What is this document?
This document gives policy makers, implementors, donors and other health information stakeholders tools and perspectives that will enable them to create effective and efficient national scale electronic health information systems.  Because every hospital, disease, country and indeed the individual using this document is different, it has been designed to be responsive to different needs. Hence, it was not designed as a document to be read from beginning to end. 

[[Patient Care]]
[[Monitoring and Evaluation]]
[[International Reporting]]

<html><img src="http://www.healthmetricsnetwork.info/ehealtharchitecture/images/eHealth_Landscape.gif" style="width: 350px; "/></html>

It is designed to allow the reader to follow their interests through the relevant sections of the work.  An excellent electronic health care system requires a large number of people to work together towards a common vision, and to consider topics that they might not be regularly exposed to.

!!References

Basic Indicators – Pan American Health Organization [11]


[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

<div class='header' macro='gradient vert #FFF #FFF '>
 <div class='gradient'> 
 <div class='titleLine' >
<span class='searchBar' macro='search'></span>
 <span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
 <span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
 </div>
<div id='topMenu' refresh='content' tiddler='MainMenu'></div>
 </div>
</div>
<div id='bodywrapper'>
<div id='sidebar'>
 <div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
 <div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
 <div id='messageArea'></div>
 <div id='tiddlerDisplay'></div>
</div>
<div id='displayFooter'></div>
</div>

Version 1.9P1.1 – June 2009 

[[1.1 Introduction]]

[[1.2 Scope]]

The initial proposition is to organize this TR in two documents, as follows:

[[1.2.1 Part 1 - International Initiatives on eHealth Systems]]
Part 1 is a landscape document whose objective is to inform on current initiatives in the area of eHealth systems. It is divided into three sections.

[[1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]
Part 2 represents the core contibution of this TR and aims at providing a roadmap for identifying business requirements that define an eHealth enterprise architecture.

[[1.2.3 Terms and Definitions]]


[[1.3 References]]


[[Back|Overview]]

Version 1.9P2.1 – June 2009

[[2.1 Introduction]]

[[2.2 Underlying Principles]]

[[2.3 Terms and Definitions]]

[[2.4 General Requirements]]

[[2.5 Business Processes]]

[[2.6 References]]

Systems are often selected without a clear understanding of the problems that they are expected to solve (business requirements). When a system's capabilities do not match the requirements it is being tasked for, it will fail. 

A critical step during system selection is the mapping of business requirements to application functionality. A transparent and documented approach should be taken and will involve knowledgeable information technology staff as well as management. This can help to avoid decisions being made for marketing, funding, political, or other reasons. Requirements and constraints such as functionality, near and long-term needs, financial and technical resources, sustainability, and analytic needs must be carefully considered. 

Advanced monitoring system requirements can include programmatic and financial reporting with advanced features such as support for multi-dimensional data (disaggregation), target support, project cloning, and full customization. These latter requirements may not be obvious in the early stages of monitoring system definition. 

IT infrastructure considerations include connectivity, open source, proprietary systems, and software development. Interoperability, as discussed elsewhere, supports a mix of solutions as appropriate to local needs and phasing implementation of systems.

!! Relevant standards

Health Metrics Network Framework - http://www.who.int/healthmetrics/documents/framework/en/index.html


[[Back|Overview]]

/***
|''Name:''|PasswordOptionPlugin|
|''Description:''|Extends TiddlyWiki options with non encrypted password option.|
|''Version:''|1.0.2|
|''Date:''|Apr 19, 2007|
|''Source:''|http://tiddlywiki.bidix.info/#PasswordOptionPlugin|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0 (Beta 5)|
***/
//{{{
version.extensions.PasswordOptionPlugin = {
	major: 1, minor: 0, revision: 2, 
	date: new Date("Apr 19, 2007"),
	source: 'http://tiddlywiki.bidix.info/#PasswordOptionPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	license: '[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D]]',
	coreVersion: '2.2.0 (Beta 5)'
};

config.macros.option.passwordCheckboxLabel = "Save this password on this computer";
config.macros.option.passwordInputType = "password"; // password | text
setStylesheet(".pasOptionInput {width: 11em;}\n","passwordInputTypeStyle");

merge(config.macros.option.types, {
	'pas': {
		elementType: "input",
		valueField: "value",
		eventName: "onkeyup",
		className: "pasOptionInput",
		typeValue: config.macros.option.passwordInputType,
		create: function(place,type,opt,className,desc) {
			// password field
			config.macros.option.genericCreate(place,'pas',opt,className,desc);
			// checkbox linked with this password "save this password on this computer"
			config.macros.option.genericCreate(place,'chk','chk'+opt,className,desc);			
			// text savePasswordCheckboxLabel
			place.appendChild(document.createTextNode(config.macros.option.passwordCheckboxLabel));
		},
		onChange: config.macros.option.genericOnChange
	}
});

merge(config.optionHandlers['chk'], {
	get: function(name) {
		// is there an option linked with this chk ?
		var opt = name.substr(3);
		if (config.options[opt]) 
			saveOptionCookie(opt);
		return config.options[name] ? "true" : "false";
	}
});

merge(config.optionHandlers, {
	'pas': {
 		get: function(name) {
			if (config.options["chk"+name]) {
				return encodeCookie(config.options[name].toString());
			} else {
				return "";
			}
		},
		set: function(name,value) {config.options[name] = decodeCookie(value);}
	}
});

// need to reload options to load passwordOptions
loadOptionsCookie();

/*
if (!config.options['pasPassword'])
	config.options['pasPassword'] = '';

merge(config.optionsDesc,{
		pasPassword: "Test password"
	});
*/
//}}}

!!Relevant standards:

[[Electronic Health Record Solution Blueprint.]]

[[NHS Care Record and the Logical Record Architecture for Health and Social Care from UK.]]

[[eHealth Europe – European Electronic Health Record Project and the eHealth-INTEROP European Project.]]

[[ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR).]]

[[CEN/TC 251- Published standards.]]

[[ICD (International Classification of Diseases).]] 

[[ISO 22857:2004 Guidelines on data protection to facilitate trans-border flows of personal health information.]]

[[ISO/CD TR 28380-1 IHE global standards adoption -- Part 1: Process.]]

[[ISO/CD TS 21298 Health informatics -- Functional and structural roles.]]

[[ISO/DIS 17113.2 Exchange of information between healthcare information systems -- Method for development of messages.]] 

[[ISO/HL7 21731:2006 HL7 version 3 -- Reference information model -- Release 1.]] 

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments.]]

[[ISO/HL7 DIS 27931 HL7 Messaging Standard Version 2.5 -- An application protocol for electronic data exchange in healthcare environments.]] 

[[ISO/HL7 NP 27951 Common terminology services, release 1.]]

[[ISO/NP 12967-3 Service architecture -- Part 3: Computational viewpoint.]] 

[[ISO/TR 20514:2005 Electronic health record -- Definition, scope and context.]]

[[ISO/TR 22221:2006 Health informatics - Good principles and practices for a clinical data warehouse.]]

[[ISO/TR 27809:2007 Measures for ensuring patient safety of health software.]] 

[[ISO/TS 17117:2002 Controlled health terminology -- Structure and high-level indicators.]]

[[ISO/TS 18308:2004 Requirements for an electronic health record architecture.]]

[[ISO/TS 25238:2007 Classification of safety risks from health software.]]

[[ISO/TS 25238:2007 Classification of safety risks from health software.]]

[[LOINC (Logical Observation Identifiers Names and Codes).]] 

[[Patient Monitoring Guidelines for HIV Care and ART.]] 

[[SNOMED CT (Systematized Nomenclature of Medicine-Clinical Terms).]] 

[[UNAIDS/USG Confidentiality and Security Guidelines.]] 



[[Back|Overview]]

!! Recommended Reading
[[Identity Management]]

!! The Challenge
People appear as patients throughout various parts of the health system throughout their lifetimes and even throughout the course of a particular treatment. If patients are required to re-register every time, and healthcare workers depend on oral histories or carried documents for information, then time is wasted, errors in treatment may occur, patients may get double counted and other problems will occur. How can a patient be consistently identified throughout an interoperable health system?

!! The Solution
Patient identification enables an interoperable health system to follow patients and more importantly, collect and reuse their data whenever they access health services.

One of the most fundamental issues in patient identification is the calculation of a unique number or string of characters to associate with each patient. Best practices will include a prefix, version number and checkdigit. A prefix, such as the letter "P", is used so that when an id is read by humans it can quickly be identified as a certain type of identifier - in this case for a patient. A version number will be used to differentiate various versions of an identifier. For instance, an identifier may need to add additional digits to handle more patients. A version digit could be incremented to signal this change and reduce confusion when two patient identifiers of differing lengths or formats are presented. Finally, and arguably most importantly is the checkdigit. A checkdigit is a single digit that is calculated via a simple calculation of all of the preceding numbers. A (too) simple checkdigit scheme might simply add all of the preceding numbers and use the final digit. So if the number was P125, the checkdigit would be 1+2+5 = 8, and the resulting id number would be P1258. A simple calculation indicates that the number is "internally consistent". Now, imagine that one of those numbers changed: P1268 then the checkdigit won't add up and we know we have an invalid number. This can be a great way for catching transcription errors.

Things to avoid when creating version numbers is using codes or numbers that have inherent meaning. For instance, using the string "NY" to identify patients registering at the New York clinic might lead to people trying to infer information from the patient identifier. Visual identifiers should never be able to indicate what diseases a patient has been treated for. Another potential pitfall is the use of numbers and letters that look similar like 0 and O or Q. These potentially ambiguous characters should be eliminated.

Tools that can help enable patient identification include barcodes, biometric readers (fingerprint), smart cards, RFID tags, and more.

!! Further Information
Checkdigits - http://en.wikipedia.org/wiki/Check_digit

!! Examples from the Field

Patient-centered - be a person/patient centered system leading to the construction of the EHR (electronic health record) with inclusion of information such as immunization status, family history, risk factors (smoking, drug abuse, community context, family and housing information). Data should be collected only once, wherever the patient is being attended. That data could be stored in a local EMR/EPR system and/or assuming interoperability, and based on national policies/clinical expert opinion & consensus, relevant shareable data from local systems could be transmitted to the individual’s national EHR record (stored in a national EHR repository. The architecture, however, should allow for the collection of community information such as facilities, services, health determinants given the existence of indicators not derived from the EHR.

!!Relevant Standards

[[ISO/TR 22221 - Good principles and prectices for a clinical data warehouse (CDW)]]
[[ISO/TS 29585 - Deployment of a Clinical Data Warehouse]]



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading 
[[Use of Data Standards]]

!! The Challenge 
Without national or international governance over health informatics standards around interoperability, differing interpretations of key terms and standards issues will be implemented by different stakeholders.  This may result in loss of data, degraded quality of data, compromised security and confidentiality of personal data, and an increased and inefficient burden of data collection on health care workers.

!! The Solution 
National governments and international organisations should establish clear governance mechanisms over key areas to ensure common usage of interoperability standards.  The creation of a Technical Working Group that can evolve into a mandated government authority on interoperability and related standards is useful to determine which standards should be implemented first and what governance questions need to be asked within a given context for them to be universally adopted and to be useful for their intended purpose.  These areas may  include identity management which includes everything from patient identification to service and facility identification, to defining policies and parameters for role based access, to establishing clear guidance around common minimum datasets for reporting (indicator selection), to technical guidance on the use of data standards that ensure data can be shared in a national health information system in an accurate, timely and safe way.  

!! Further Information 
[[Patient Identification]]
[[Indicator Selection]]
[[Security]]
[[Privacy and Confidentiality]]
UK NHS Information Governance Standards - http://www.dh.gov.uk/en/Managingyourorganisation/Informationpolicy/Informationgovernance/index.htm
US Health and Human Services Policies - http://www.hhs.gov/policies/index.html

!! Examples from the Field 
[[An Interoperability Initiative - Philippines]]

Security, privacy and confidentiality meeting in which the Americans and the Eastern Europeans agreed on the importance of role based access without realizing they meant two opposite things by it
Use of public records to politically target vulnerable population groups in Africa
Consensus building efforts on minimum data sets and indicator selection both locally and internationally in the HIV sector
Differing attempts at creating national identifiers for patient identification with and without using international standards in Africa
Differing governance structures in Canada, Denmark, UK, Brazil and Turkey.  
China wanting to learn more about international data standards in order to create a non compatible national standard to prevent health data from leaving the country.

Presentation/User interface – describes the requirements of the presentation layer of the EA. Issues such as use of mobile devices and off-line devices should be addressed here.

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading
[[Security]]
[[Patient Identification]]
[[Data for Patient Care]]

!! The Challenge
Patient information must be protected from inappropriate access and use across a health information system while ensuring that proper continuity of care can be provided to the individual and that appropriate reporting and monitoring can still be carried out in accordance with local, regional, and national policies and requirements.

!! The Solution
Protecting privacy and confidentiality of patient information relies on solid security. However, security on its own does not provide privacy or confidentiality protection.

Privacy and confidentiality protection should be designed into systems and applications and, where applicable, infrastructure right from the onset of a project. Although it is sometimes possible to retro-fit such protections into existing system, this is often more expensive and less efficient than including them in the initial design.

Countries, regions, or districts may often have privacy and confidentiality policies that must be adhered to, however, these may not be explicitly geared for the health sector but still apply. It is important to identify these early on so that system design can take them into account. Failure to do so may result in the system being unusable because of legal issues.

In the absence of policies governing the collection, use, and dissemination of personal information, the following fair information principles are a useful start to implement in a system:

* Accountability: Maintain a clear process and contact point to ensure accountability for how data is collected, used, and disseminated.
* Identifying purposes. Clearly specify why personal information needs to be collected.
* Consent. Individuals should be asked for consent in the collection and use of their information. If the information is to be put to a new use after consent has been given, this new use should be presented to the owner of the information and consent should be given first.
* Limiting collection. Only collect information that is needed, use it or lose it.
* Limiting use, disclosure, and retention. Information should be disclosed and retained according to clear policies and destroyed when no longer needed for the specified use.
* Accuracy. If data is being collected then there is a responsibility to make sure it is valid and accurate.
* Safeguards. Implement good security in systems that collect, use, or disseminate personal information
* Openness. Being transparent about the who, what, why, when and where will ensure that privacy and confidentiality don't rely on secrecy, but on solid systems.
* Individual access. Individuals should have access to the information pertaining to them.
* Provide recourse. There should be clear and simple mechanisms for individuals to file complaints and corrections to the data pertaining to them.

The concept of ownership of personal information varies from jurisdiction to jurisdiction. It is important to identify and clearly communicate who owns and is responsible for specific items of personal information about an individual. Note that some items can sometimes be tricky, for example, a health care worker's clinical notes about an individual may be "owned" by the health care worker, but specific details in those notes may be "owned" by the patient.

Care must be taken with distribution of reporting data sets as these can inadvertently breach patient confidentiality and privacy by identifying small groups of or single individuals because of boundary values in the sets or unusual combinations of values for common observations. For example, a data set identifying counts of women giving birth in a particular geographic area disaggregated by age and HIV+ could lead to the explicit identification of older individual's HIV status.

There exists methods and algorithms to anonymise personal information as well as to pseudonymise it so that personal information from different sources can be linked without compromising the identity of individuals.

A well designed patient identification system can be used to support privacy and confidentiality.

!! Further Information
[[Interim Guidelines on Protecting the Confidentiality and Security of HIV Information (UNAIDS/CDC/WHO) | http://data.unaids.org/Pub/Manual/2007/Confidentiality Security Interim Guidelines 15may2007 en.pdf]]
Principles described in the Canadian Personal Information Protection and Electronic Documents Act (PIPEDA) - http://en.wikipedia.org/wiki/Personal_Information_Protection_and_Electronic_Documents_Act
OECD guidelines on protection of personal information
Office of the Privacy Commissioner of Canada - http://www.privcom.gc.ca
[[UK Department of Health Patient Confidentiality Policy | http://www.dh.gov.uk/en/Managingyourorganisation/Informationpolicy/Patientconfidentialityandcaldicottguardians/DH_4084181]]

!! Examples from the Field
NHS connecting for health system ground to a halt because of privacy and confidentiality concerns. Basically, this was not really considered at design time and patients started to complain when consequences of incorrect information started to spread across the system with no means to correct the errors.

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Provider Registry - incorporate a national registry of health care providers and description of resources such as type of service provided, medical equipment available and health care personnel currently working, as well as their profiles for accessing data.

!!Relevant standards

[[ISO/TS 27527 - Provider Identification]]

!!Relevant Standards


!!References




[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Real-time Surveillance - provide real-time surveillance of diseases and other emergencies (natural as well as human-induced), such as epidemics, and to allow rapid community-based response.

[[A Summary for Policy Makers]]
[[Governance]]
[[Capturing Electronic Data]]

!!Relevant Standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

/***
|Macro|redirect (alias)|
|Author|[[Clint Checketts]] and Paul Petterson|
|Version|1.1 Jan 26, 2006|
|Location|http://checkettsweb.com/styles/themes.htm#RedirectMacro|
|Description|This macro tells TW to find all instances of a word and makes it point to a different link.  For example, whenever I put the word 'Clint' in a tiddler I want TiddlyWiki to turn it into a link that points to a tiddler titled 'Clint Checketts' Or the word 'TW' could point to a tiddler called 'TiddlyWiki' It even matches clint (which is lowercase) [[Clint]] leet lEEt LEET|
|Usage|{{{<<redirect TW TiddlyWiki>>}}}   |
|Example|<<redirect TW "TiddlyWiki">>  <<redirect Clint "Clint Checketts">> (Nothing should appear, its just setting it all up)<<redirectExact lEEt Elite>>|

!Revisions
1.1- Fixed tiddler refresh so a tiddler declaring a redirect will also render the redirect
1.0- Updated to work with TiddlyWiki 2.0 (thanks to Udo Borkowski)
0.9- Original release October 2005

!Code
***/
//{{{
version.extensions.redirectExact = {major: 1, minor: 2, revision: 0, date: new Date(2005,10,24)};
config.macros.redirectExact = {label: "Pickles Rock!"};
config.macros.redirectExact.handler = function(place,macroName,params,wikifier,paramString,tiddler){
	config.macros.redirect.handler(place,macroName,params,wikifier,paramString,tiddler);
}

version.extensions.redirect = {major: 1, minor: 2, revision: 0, date: new Date(2005,10,24)};
config.macros.redirect = {label: "Pickles Rock!"};

config.macros.redirect.handler = function(place,macroName,params,wikifier,paramString,tiddler){

var redirectExists = false
// Check to see if the wikifier exists
for (var i=0;i<config.formatters.length;i++)
	if (config.formatters[i].name == "redirect"+params[0])
		redirectExists = true;

//If it doesn't exist, add it!
if (!redirectExists){
	for( var i=0; i<config.formatters.length; i++ )
		if ( config.formatters[i].name=='wikiLink') break ;

	if ( i >= config.formatters.length ) {
		var e = "Can't find formatter for wikiLink!" ;
		displayMessage( e ) ;
		throw( e ) ;
	}

var pattern;
	if (macroName == 'redirect'){pattern=params[0].escapeRegExp().replace(/([A-Z])/img, function($1) {return("["+$1.toUpperCase()+$1.toLowerCase()+"]");});
	} else {
		pattern=params[0].escapeRegExp();
	}

	config.formatters.splice( i, 0, {
		name: "redirect"+params[0],
		match: "(?:\\b)(?:\\[\\[)?"+pattern+"(?:\\]\\])?(?:\\b)",
		subst: params[1],
		handler:  function(w) {
			var link = createTiddlyLink(w.output,this.subst,false);
			w.outputText(link,w.matchStart,w.nextMatch);
		}
	});
	formatter = new Formatter(config.formatters); //update the tiddler
	if(tiddler) story.refreshTiddler(tiddler.title,null,true); //refresh tiddler so the new rule is applied
} // End if
}
//}}}

Reporting systems tend to be the place where the benefits of electronic health systems and interoperability in particular are most apparent. Indicators are the key data points that appear on reports. They should be relevant, sensitive and accurate. It is important to maintain a small number of indicators that can be managed well. There are many international efforts to develop common indicators which will encourage good indicator selection and also enable internationally comparable reports.

Besides indicator selection, international standards can be used for transferring data and reporting formats. While it may require more work at the beginning to adopt international standards, the benefits in the long run for interoperability are important. National, international and donor reporting are all embracing standards, which means that multiple stakeholders are in agreement over what needs to  be present in a report. Monitoring and evaluation systems are adopting these standards as well. Donor driven projects tend to create vertical solutions that don't have a wide ranging impact within the entire health system. However, making sure that these vertical programs deploy good interoperable systems can help the benefits spread to beyond the vertical systems. An example might be a patient registration system that is deployed for HIV care, but used throughout a hospital.

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading

!! The Challenge
All activities involve some element of risk. Some activities are more risky than others. Engaging in activities without being aware of the risks involved can lead to disaster. This is not to say that risky situations or activities must be avoided, because engaging in new risky activities is often the only way progress can be made.

!! The Solution
Risk management involves identifying, mitigating, and monitoring risks inherent to a system, project or activity. It is an attempt to eliminate surprise or at least be well prepared for problems.

Risk can be roughly calculated as the likelihood of an adverse event occurring times the severity of its impact. This calculation facilitates the prioritization of individually identified risks.

For instance, compare the risk of a deadly accident occurring when a high level official drives to a rural health clinic versus the risk of losing power for a critical lab service that relies on grid electricity.

In the first case, the likelihood of the event occurring might be very small: .01%, but the impact might be estimated at $500,000 (cost of funeral, car, time lost in replacing the position). So the risk would have a value of 50 (0.0001 * 500000).

In the second case, the likelihood could be quite high if the electricity provider is prone to power cuts, say 12% chance of a 15 minute failure every day. The impact might be valued at $10 (samples need to be rerun and use more materials, patients waste time waiting for results). In this case the risk would have a value of 1.2 (0.12*10).

Once a particular risk is identified, there are four broad approaches to mitigation, or reducing risk:
* Avoidance, where the risk is eliminated
* Reduction, where the level of risk is lowered, but it it is not eliminated
* Transfer, where the risk is transferred to some other entity
* Retention, where you accept the risk and plan for its eventual occurrence

Which approach to use will depend on the impact of the risk vs the cost to mitigate it to a particular level, as well as the system's or the system owner's overall level of risk tolerance. Note that one must generally be able to tolerate a certain level of risk, as a zero risk tolerance means than all identified risks are eliminated - a costly and often impossible proposition.

Part of risk management is business continuation planning, an aspect of disaster recover than covers plans for continuing the functions of a system at some level in case of a major failure.

The cost of managing risk must take into account the impact of the risk itself. For example, it is not worthwhile to eliminate a risk with an estimate impact of $1000 with a $10000 solution, thus the process of risk management must add value.

Project managers and others must be encouraged to identify risks regardless of the overall mitigation strategy. Even if a risk cannot be managed for whatever reason, it is still better to have identified it and know it as possibility rather than have it strike later as a surprise.

!! Further Information
[[Security]]
[[ICT Assessment]]

http://en.wikipedia.org/Wiki/Risk_management
http:///www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43170 - Principles and guidelines on implementation"
[[Disaster recovery]]
[[Business continuation]]

!! Examples from the Field

!! Recommended Reading

!! The Challenge
The privacy and security of health information should always be protected. However, various people involved in patient care and program monitoring need to have access to information. The specific information and level of detail they need to access depends on the job they are performing or decision that they need to make. How can we enable secure information access to the right individuals for appropriate activities?

!! The Solution
The solution is to allow access to specific information on a "need to know" basis depending on their role in the organization. For example, a person involved in direct patient care would need access to all of the clinical information about the patient he or she is caring for at the time. They do not need access to demographic or payment information. They do not need access to any patients other than the one they are seeing. One could design a "Patient Care" role with these parameters.
Another example would be a facility manager who would need access to information about the number of patients seen each day by each provider of care as well as support services such as lab, x-ray, and ancillary services. They would not need access to individual patient information but only the specific aggregate information necessary to manage the facility. A role of "Facility Manager" could be designed with these parameters.

In a similar fashion, all of the potential roles for people accessing information can be defined. Every individual can then be assigned a role (or more than one role if they have several job functions). They then log into the computer system and are assigned the data access for their role(s).

!! Discussion
1. Compare and contrast two different roles from a health information context you are familiar with.
2. How do we solve the problem of individuals who fulfill many different roles?

!! Further Information
[[Identity Management]]
[[Security]]
National Institute of Standards and Technology RBAC page - http://csrc.nist.gov/groups/SNS/rbac/

!! Examples from the Field

!!References



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Introduction
The adoption of the ISO/TS 17369:2005 Statistical Data and Metadata Exchange standard (SDMX) standard by the UN for aggregate data exchange will contribute to efforts to promote computer system interoperability and data use. The SDMX-HD (Health Domain) is the WHO implementation of the SDMX standard which is implemented in the WHO Indicator and Metadata Registry (IMR), a facility for harmonizing, managing, and publishing computer-readable indicator definitions.

An interoperability-based strategy for health information system (HIS) strengthening is appropriate given the heterogeneity of the PHI and Monitoring and Evaluation (M&E) landscapes. Country resource and capability levels also support this strategy.

The SDMX-HD is intended to become part of countries' HIS and M&E infrastructure strengthening strategy, facilitating seamless flow of information from facility to district, national, and international levels in the absence of well-developed Internet access.

!!Scenarios
Some of the scenarios that SDMX-HD is intended to support include:
*Capacity-building, M&E, and International Reporting
**An NGO unaware of international indicator harmonization efforts imports an SDMX-HD indicator definition file into an existing application. It is now clear what data is required by national and international groups for reporting, including information on methodology, providing collection guidance. Prior to import, the existing application was modified to accept the SDMX-HD, including addition of a dimension required by donors not existing in the database.
**The data is combined and analyzed for all districts at the national level. In turn, data aggregated across countries at WHO, received via SDMX-HD enables timely creation of a global report.

*Patient Care and Development of Monitoring Infrastructure
**Indicator definitions are imported into a clinical system that supports the SDMX-HD. Another clinic in a different location imports the same indicator definitions which include clinical concepts.
**A patient transferred to the other clinic will encounter a system that has clinical data defined in the same manner, enabling both patient data exchange and standard summary reporting, horizontally in the clinical system and vertically up through the M&E system.

*Application Interoperability
**SDMX-HD enables specialized functionality of systems supporting the standard to be leveraged, making application development more cost-effective.
**For example, for geographic mapping, data can be imported into GIS applications supporting the format, eliminating the need to replicate the mapping functionality in multiple applications.

!!Data Exchange Requirements
Data exchange has historically occurred through negotiation of file formats between partners with documentation consisting of a file format and dictionary. The further data is removed from its source the more important metadata, or data about data, becomes to unambiguously describe data. The SDMX-HD defines attributes of a data items, which reduces the negotiation required to exchange data, providing more complete context and meaning of data.

The SDMX-HD incorporates both M&E and informatics requirements for content, providing a guide for computer applications and data to conform to international standards. It will be a useful benchmark for countries to evaluate applications being considered for M&E systems. In some cases, applications may need to be revised to support the standard, support for dimensional data for performance-based M&E being a prominent example.

!!Standards
The standards considered when creating the SDMX-HD include:

*ISO/TS 17369:2005, SDMX Metadata Common Vocabulary (MCV)
*ISO 15836:2003, Dublin Core Metadata Element Set (DCMES)
*Data Documentation Initiative (DDI)
*ISO/IEC 11179, Information Technology -- Metadata registries (MDR)

The concepts in the SDMX-HD provide an entry point for metadata management, with a subset of concepts from the above standards having been incorporated into the SDMX-HD model. It is expected that more metadata attributes will be included as the business cases for interoperability in countries mature.

!!SDMX Standard
The SDMX standard describes statistical data and metadata through a data structure definition (DSD), which defines concepts that define dimensions, attributes, codelists and other artifacts necessary to describe the structure and meaning of data. A parallel metadata structure definition(MSD) describes metadata associated with data at observation, series, group, and dataset levels.

With the SDMX-HD, these structures define metadata concepts recommended in international standards and programmes, creating a message that will satisfy a majority of PHI requirements with common and programme-specific needs.

Harmonization of globally-reported indicators and metadata is a priority, which the IMR intends to address. However, enhancements to SDMX-HD were needed to accommodate all reporting requirements in the absence of harmonized and centrally-managed indicator definitions and metadata.

Additional documentation is available online from SDMX, the standard developing organization(SDO) supporting SDMX. A website has also been created to promote the development of a community around the SDMX-HD and support its use.

!! Relevant standards

[[Health Metrics Network Framework (HMN)|http://www.who.int/healthmetrics/documents/framework/en/index.html]]

[[Statistical Data and Metadata Exchange (SDMX)|http://www.sdmx.org]]

[[SDMX-HD (Health Domain)|http://www.sdmx-hd.org]]

[[Back|Monitoring Framework]]

Security services – describes the business processes to guarantee privacy and confidentiality of health data.

!!Relevant standards

[[ISO 27799 Information Security Management System in health using ISO/IEC 27002]]

[[ISO/TS 22600 Priviledge Management and Access Control Parts 1-3]]



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

!! Recommended Reading 
[[Risk Management]]

!! The Challenge 
Health information applications, systems, and infrastructure need to implement security measures to protect the data and functions managed by these systems from unauthorized and unaudited access and use.  Across the health system, different components and actors must also be able to authenticate each other and communicate securely.
Note that a good security implementation is a basic foundation for providing privacy and confidentiality but on its own does not provide these functions.

!! The Solution 
Security should implement the CIA triad:
* Confidentiality.  Access must only be granted to individuals or roles that are properly authorized
* Integrity.  Information cannot be modified by an individual or role that is not authorized to do so
* Availability.  Information must be made available when it is needed

The ISO/IEC 27002:2005 Code of practice for information security management recommends examining the following during a security risk assessment:
* security policy,
* organization of information security,
* asset management, human resources security,
* physical and environmental security,
* communications and operations management,
* access control,
* information systems acquisition,
* development and maintenance,
* information security incident management,
* business continuity management, and
* regulatory compliance.

From an interoperability perspective, this may lead to adopting the following:
* Security policies across heterogeneous systems (perhaps as part of the enterprise architecture)
* Identity management and access control
* Auditing standards
* Certificates and public key infrastructure
* Link level security (message and data stream encryption)
* Regulatory compliance
* Development standards for software components

It is important to identify security requirements and to develop a threat model against the system, the information it contains and the communications in which it may engage.  This allows the implementation of appropriately scoped security methods for the system as well as clarifying risk management and mitigation plans in cases of security breaches.

Some methods for implementing security:
* Role based access
* Cryptography
* Public key cryptography
* Identity management
* Authenticated access control
* Audit logs
* Digital certificates
* Security policies
* Operational policies
* Application/system/infrastructure policies implemented in software

!! Further Information 
[[Role Based Access]]
[[Privacy and Confidentiality]]
http://en.wikipedia.org/wiki/ISO/IEC_27007
[[Information Security Management: NHS Code of Practice|http://www.dh.gov.uk/en/Publicationsandstatistics/Publications/PublicationsPolicyAndGuidance/DH_074142]]
Certified Information Systems security Professional certification
 
!! Examples from the Field

<<closeAll>><<permaview>><<newTiddler>><<newJournal 'DD MMM YYYY'>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel 'options »' 'Change TiddlyWiki advanced options'>>

/***
|Name|SinglePageModePlugin|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.6|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Story.prototype.displayTiddler(), Story.prototype.displayTiddlers()|
|Options|##Configuration|
|Description|Show tiddlers one at a time with automatic permalink, or always open tiddlers at top/bottom of page.|
This plugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one tiddler displayed at a time.
!!!!!Documentation
>see [[SinglePageModePluginInfo]]
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)

Notes:
* The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}.
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2008.10.17 [2.9.6] changed chkSinglePageAutoScroll default to false
| Please see [[SinglePageModePluginInfo]] for previous revision details |
2005.08.15 [1.0.0] Initial Release.  Support for BACK/FORWARD buttons adapted from code developed by Clint Checketts.
<<<
!!!!!Code
***/
//{{{
version.extensions.SinglePageModePlugin= {major: 2, minor: 9, revision: 6, date: new Date(2008,10,17)};
//}}}
//{{{
config.paramifiers.SPM = { onstart: function(v) {
	config.options.chkSinglePageMode=eval(v);
	if (config.options.chkSinglePageMode && config.options.chkSinglePagePermalink && !config.browser.isSafari) {
		config.lastURL = window.location.hash;
		if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
	}
} };
//}}}
//{{{
if (config.options.chkSinglePageMode==undefined)
	config.options.chkSinglePageMode=true;
if (config.options.chkSinglePagePermalink==undefined)
	config.options.chkSinglePagePermalink=true;
if (config.options.chkSinglePageKeepFoldedTiddlers==undefined)
	config.options.chkSinglePageKeepFoldedTiddlers=false;
if (config.options.chkSinglePageKeepEditedTiddlers==undefined)
	config.options.chkSinglePageKeepEditedTiddlers=false;
if (config.options.chkTopOfPageMode==undefined)
	config.options.chkTopOfPageMode=false;
if (config.options.chkBottomOfPageMode==undefined)
	config.options.chkBottomOfPageMode=false;
if (config.options.chkSinglePageAutoScroll==undefined)
	config.options.chkSinglePageAutoScroll=false;
//}}}
//{{{
config.SPMTimer = 0;
config.lastURL = window.location.hash;
function checkLastURL()
{
	if (!config.options.chkSinglePageMode)
		{ window.clearInterval(config.SPMTimer); config.SPMTimer=0; return; }
	if (config.lastURL == window.location.hash) return; // no change in hash
	var tids=decodeURIComponent(window.location.hash.substr(1)).readBracketedList();
	if (tids.length==1) // permalink (single tiddler in URL)
		story.displayTiddler(null,tids[0]);
	else { // restore permaview or default view
		config.lastURL = window.location.hash;
		if (!tids.length) tids=store.getTiddlerText("DefaultTiddlers").readBracketedList();
		story.closeAllTiddlers();
		story.displayTiddlers(null,tids);
	}
}


if (Story.prototype.SPM_coreDisplayTiddler==undefined)
	Story.prototype.SPM_coreDisplayTiddler=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler,template,animate,slowly)
{
	var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
	var tiddlerElem=document.getElementById(story.idPrefix+title); // ==null unless tiddler is already displayed
	var opt=config.options;
	var single=opt.chkSinglePageMode && !startingUp;
	var top=opt.chkTopOfPageMode && !startingUp;
	var bottom=opt.chkBottomOfPageMode && !startingUp;
	if (single) {
		story.forEachTiddler(function(tid,elem) {
			// skip current tiddler and, optionally, tiddlers that are folded.
			if (	tid==title
				|| (opt.chkSinglePageKeepFoldedTiddlers && elem.getAttribute("folded")=="true"))
				return;
			// if a tiddler is being edited, ask before closing
			if (elem.getAttribute("dirty")=="true") {
				if (opt.chkSinglePageKeepEditedTiddlers) return;
				// if tiddler to be displayed is already shown, then leave active tiddler editor as is
				// (occurs when switching between view and edit modes)
				if (tiddlerElem) return;
				// otherwise, ask for permission
				var msg="'"+tid+"' is currently being edited.\n\n";
				msg+="Press OK to save and close this tiddler\nor press Cancel to leave it opened";
				if (!confirm(msg)) return; else story.saveTiddler(tid);
			}
			story.closeTiddler(tid);
		});
	}
	else if (top)
		arguments[0]=null;
	else if (bottom)
		arguments[0]="bottom";
	if (single && opt.chkSinglePagePermalink && !config.browser.isSafari) {
		window.location.hash = encodeURIComponent(String.encodeTiddlyLink(title));
		config.lastURL = window.location.hash;
		document.title = wikifyPlain("SiteTitle") + " - " + title;
		if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
	}
	if (tiddlerElem && tiddlerElem.getAttribute("dirty")=="true") { // editing... move tiddler without re-rendering
		var isTopTiddler=(tiddlerElem.previousSibling==null);
		if (!isTopTiddler && (single || top))
			tiddlerElem.parentNode.insertBefore(tiddlerElem,tiddlerElem.parentNode.firstChild);
		else if (bottom)
			tiddlerElem.parentNode.insertBefore(tiddlerElem,null);
		else this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
	} else
		this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
	var tiddlerElem=document.getElementById(story.idPrefix+title);
	if (tiddlerElem&&opt.chkSinglePageAutoScroll) {
		// scroll to top of page or top of tiddler
		var isTopTiddler=(tiddlerElem.previousSibling==null);
		var yPos=isTopTiddler?0:ensureVisible(tiddlerElem);
		// if animating, defer scroll until after animation completes
		var delay=opt.chkAnimate?config.animDuration+10:0;
		setTimeout("window.scrollTo(0,"+yPos+")",delay); 
	}
}

if (Story.prototype.SPM_coreDisplayTiddlers==undefined)
	Story.prototype.SPM_coreDisplayTiddlers=Story.prototype.displayTiddlers;
Story.prototype.displayTiddlers = function() {
	// suspend single/top/bottom modes when showing multiple tiddlers
	var opt=config.options;
	var saveSPM=opt.chkSinglePageMode; opt.chkSinglePageMode=false;
	var saveTPM=opt.chkTopOfPageMode; opt.chkTopOfPageMode=false;
	var saveBPM=opt.chkBottomOfPageMode; opt.chkBottomOfPageMode=false;
	this.SPM_coreDisplayTiddlers.apply(this,arguments);
	opt.chkBottomOfPageMode=saveBPM;
	opt.chkTopOfPageMode=saveTPM;
	opt.chkSinglePageMode=saveSPM;
}
//}}}

ISO/TC 215 WG 8 - Business Requirements for Electronic Health Records

eHealth Enterprise Architecture for Emerging and Developing Countries

[[Business Rules]]
[[Health Architecture]]
[[Use Cases]]
[[Conceptual Modeling]]
[[Test Cases]]

!! Recommended Reading 
[[ICT Issues]]


!! The Challenge 
Selecting which software to use can be a daunting task. Should it be an interoperable system or an integrated system? Should we buy it or build it? Do we use open source software or proprietary software? Should we hire a local software development firm or use international consultants?

!! The Solution 
A common understanding of any already existing systems (through an ICT assessment), reporting requirements, functional requirements, available technical and financial resources, and ICT issues and infrastructure will inform a strategy for development of an appropriate health information system. Working groups that gather a diverse group of expert stakeholders (ICT, healthcare, public health) should be established to develop business requirements and provide guidance from which to base these decisions.

!! Discussion
1. Create a list of all of the software being used in your context. Include Microsoft Word, the internet - anything that is helping to get the job done. Try and create an exhaustive list and understand the big picture.  Identify the functions performed by each piece of software.
2. What experts should we consider recruiting as stakeholders?
3. Evaluate the suitability of each software system against your [[Business Requirements]].  Could this be done more efficiently by different software?
4. Often the barriers to efficient use are lack of [[Interoperability]] functionality and standards.  What are your interoperability issues?

!! Further Information 
[[Business Requirements]]
[[Monitoring and Evaluation]]
[[Interoperable System]]
[[Indicator Selection]]

!!! Electronic Medical Record Software
* http://openmrs.org
* http://www.openehr.org
* http://worldvista.org

!!! Monitoring and Evaluation Software
* http://www.cdc.gov/epiinfo - data management and epidemiologic analysis
* http://www.census.gov/ipc/www/cspro - Census and Survey Processing System
* http://www.who.int/health_mapping/tools/healthmapper/en - WHO HealthMapper 
* http://www.unaids.org/en/KnowledgeCentre/HIVData/CRIS/cris.asp - UNAIDS Country Response Information System (CRIS) 
* http://www.undg.org/?P=90 UNDG DevInfo 
* http://kids.fao.org - FAO Key Indicator Data System (KIDS) 
* http://en.wikipedia.org/wiki/DHIS - District Health Information Software (DHIS) 
* http://en.wikipedia.org/wiki/Development_Assistance_Database - Development Assistance Database (DAD) 
* http://www.voxiva.com - Voxiva 

http://www.healthmetricsnetwork.org - global partnership facilitating better health information
http://www.cchit.org - Certification Commission for Healthcare IT

!! Examples from the Field

/***
!General
***/
/*{{{*/
body {
 background: #EDEDED;
}

 #contentWrapper{
 background: #fff;
 border:1px solid #DDD;
 margin: 0 1em;
 padding:0;

height:1%;
}
/*}}}*/


/***
!Links
***/
/*{{{*/
a,
a.tiddlyLink,
a.button,
a.externalLink,
#sidebarOptions .sliderPanel a{
 color: #1D65BC;
 text-decoration: none;
 background: transparent;
 border: 0;
}

a:hover,
a.tiddlyLink:hover,
a.button:hover,
a.externalLink:hover,
#sidebarOptions .sliderPanel a:hover
{
 border: 0;
 color: #1D65BC;
 text-decoration: underline;
background:transparent;
}
/*}}}*/

/***
!Header
***/
/*{{{*/
.gradient {margin-top:1em; background:#3371A3;}

.titleLine{padding: 30px 40px 15px 30px;}

.titleLine a:hover{color:#fff; border-bottom:1px dotted #eee; text-decoration:none;}

.titleLine a{color:#fff; border-bottom:1px dotted #ccc;}

.siteTitle {
 font-size: 2.2em;
 font-weight: bold;
 color:#fff;
}

.siteSubtitle {
 font-size: 1.0em;
 display: block;
 margin: .3em auto 1em;
color:#fff;
}
/*}}}*/

/***
!TopMenu
***/
/*{{{*/
#topMenu br {display:none; }
#topMenu { background: #3371A3; font-size:1em; }
#topMenu { padding:5px 32px; }
#topMenu .button, #topMenu .tiddlyLink {
 margin-left:0.1em; margin-right:0.1em;
 padding:0.5em;
 color:white; font-weight:bold;
}
#topMenu a.button:hover, #topMenu a.tiddlyLink:hover { background:#fff; color:#333; text-decoration:none;}

 
/*}}}*/

/***
!Display
***/
/***
!!!Display General
***/
/*{{{*/


#displayArea { margin: 0em 15.7em 0em 0em; }

#displayFooter {
 clear: both;
}
/*}}}*/
/***
!!!Tiddler
***/
/*{{{*/
.tiddler {margin-bottom:1em; padding-bottom:1em;}

.tiddler {padding-left:1.5em;}

.title {color:#333; font-size:1.8em; border-bottom:1px solid #333; padding-bottom:0.3px;}

.subtitle { font-size:90%; color:#bbb; padding-left:0.25em; margin-top:0.1em; }

.shadow .title {
 color: #aaa;
}

h1,h2,h3,h4,h5 { color: #333; background: transparent; padding-bottom:2px; border-bottom: 1px dotted #666; }

* html .viewer pre {
 margin-left: 0em; 
}



.viewer hr {
 border: 0;
 border-top: solid 1px #333;
 margin: 0 8em;
 color: #333;
}

.viewer a.button {color:#000; border:1px solid #1D65BC; font-weight:bold;}

.viewer a.button:hover{color:#fff; background:#3371a3; text-decoration:none;}

.tagClear {clear:none;}
/*}}}*/
/***
!!!Editor
***/
/*{{{*/

* html .editor textarea, * html .editor input {
 width: 98%;
}
/*}}}*/







/***
!Sidebar
***/
/*{{{*/
#sidebar{
position:relative;
float:right;
margin-bottom:1em;
display:inline;
width: 16em;
}
/*}}}*/


.toolbar .button {color:#bbb; border:none;}
.toolbar .button:hover, .toolbar .highlight, .toolbar .marked, .toolbar a.button:active {background:transparent; color:#111; border:none; text-decoration:underline;}


.tiddler {border-bottom:3px solid #EEF1F3; padding-bottom:2em; padding-top:0em;}
.title {border-bottom:none; margin-right:8em;}

h1,h2,h3,h4,h5 { color: #333; background: transparent; padding-bottom:2px; border-bottom: none; }

#sidebar {background: #EBEEF1 ; right:0;}



#displayFooter {
 clear: both;
}

#tiddlerDisplay{padding-top:1em;}



#sidebar .tabSelected, #sidebar .tabSected:hover {
 color: #000;
 background: #dbdee3;
 border-top: solid 1px #B2B6BE;
 border-left: solid 1px #B2B6BE;
 border-right: solid 1px #B2B6BE;
 border-bottom:solid 1px #dbdee3 !important;
padding-bottom:1px;
text-decoration:none;
}

#sidebarOptions, #sidebarTabs {border-left: 1px solid #B2B6BE;}
#sidebarTabs {border-bottom: 1px solid #B2B6BE;}



#sidebar .tabUnselected, #sidebar .tabUnselected:hover {
color: #F0F3F5;
background: #B2B6BE ;
border: solid 1px #B2B6BE ;
padding-bottom:1px;
}

#sidebarTabs .tabContents {border:none; background:#DBDEE3; }

#sidebarTabs .tabContents {border-top:1px solid #B2B6BE;}

#sidebarTabs .tabContents .tabContents {border-left:1px solid #b2b6be;}









.viewer pre, .viewer code {
border: 1px solid #B2B6BE;
background: #EBEEF1;} 

#sidebarOptions .sliderPanel {
 background: #EBEEF1; border:none;
}

#sidebarOptions input {
 border: 1px solid #1d65bc;
}

#sidebarOptions input:hover, #sidebarOptions input:active, #sidebarOptions input:focus {
 border: 1px inset #3371a3;
}

.tagging, .tagged {
 border: 1px solid #dbdee3;
 background-color: #ebeef1;
}

.selected .tagging, .selected .tagged {
 background-color: #dbdee3;
 border: 1px solid #B2B6BE;
}

 .tagging .listTitle, .tagged .listTitle {
 color: #bbb;
}

.selected .tagging .listTitle, .selected .tagged .listTitle {
 color: #014; 
}

.tagging .button:hover, .tagged .button:hover {
 border: none; background:transparent; text-decoration:underline; color:#014;
}

.tagged .highlight, .tagged .marked, .tagged a.button:active {text-decoration:underline; background:transparent; color:#014;}

.tagging .button, .tagged .button {
 color:#bbb;
}

.selected .tagging .button, .selected .tagged .button {
 color:#014;
}

.viewer blockquote {
 border-left:7px solid #ebeef1;
}

.viewer table {
 border: 1px solid #3371a3;
}

.viewer th, thead td {
 background: #3371a3;
 border: 1px solid #3371a3;
 color: #fff;
}

.viewer td, .viewer tr {
 border: 1px solid #3371a3;
}

.editor input, .editor textarea {
 border: 1px solid #1d65bc; background:#ebeef1;
}

.editor {padding-top:0.3em;}

.editor textarea:focus, .editor input:focus {
 border: 1px inset #3371a3; background:#fff;
}










.popup {
 background: #3371a3;
 border: 1px solid #333;
}

.popup hr {
 color: #333;
 background: #333;
 border-bottom: 1px;
}

.popup li.disabled {
 color: #333;
}

.popup li a, .popup li a:visited {
 color: #eee;
 border: none;
}

.popup li a:hover {
 background: #3371a3;
 color: #fff;
 border: none;
 text-decoration:underline;
}

.viewer .button:active, .viewer .marked, .viewer .highlight {
color: #fff !important;
background: #3371a3;
border: 0;
}

.button:active {background:#1d65bc; border:0;}

#sidebar .button:active, #sidebar .marked, #sidebar .highlight {color:#014; background:transparent;text-decoration:none}

#messageArea {
 border: 2px dashed #3371a3;
 background: #dbdee3;
 color: #fff;
 font-size:90%;
}

#messageArea .button {
 color: #1d65bc;
 background: #ebeef1;
 text-decoration:none;
 font-weight:bold;
 border:none; 
}

#messageArea a.button {color:#1d65bc;}

#messageArea .button:hover {text-decoration:underline;}

.viewer .tabSelected, .viewer .tabSelected:hover{
 color: #014;
 background: #eee;
 border-left: 1px solid #B2B6BE;
 border-top: 1px solid #B2B6BE;
 border-right: 1px solid #B2B6BE;
}

.viewer .tabUnselected, .viewer .tabUnselected:hover {
 color: #fff;
 background: #B2B6BE;
}

. viewer .tabContents {
 color: #014;
 background: #ebeef1;
 border: 1px solid #B2B6BE;
}

.searchBar {float:right; font-size:0.9em;}
.searchBar .button {display:block; border:none; color:#ccc;}
.searchBar .button:hover{border:none; color:#eee;}

.searchBar input{
 border: 1px inset #1d65bc; background:#dbdee3;
}

.searchBar input:focus {
 border: 1px inset #3371a3; background:#fff;
}

.blog h2, .blog h3, .blog h4{
  margin:0;
  padding:0;
border-bottom:none;
}
.blog {margin-left:1.5em;}  


.blog .excerpt {
  margin:0;
margin-top:0.3em;
  padding: 0;
  margin-left:1em;
  padding-left:1em;
  font-size:90%;
  border-left:1px solid #ddd;
}

#tiddlerWhatsNew h1, #tiddlerWhatsNew h2 {border-bottom:none;}
div[tags~="RecentUpdates"], div[tags~="lewcidExtension"] {margin-bottom: 2em;}


#topMenu .fontResizer {float:right;}

#topMenu .fontResizer .button{border:1px solid #3371A3;}
#topMenu .fontResizer .button:hover {border:1px solid #fff; color:#3371A3;}
#sidebarTabs .txtMainTab .tiddlyLinkExisting {
 font-weight: normal;
 font-style: normal;
}

#sidebarTabs .txtMoreTab .tiddlyLinkExisting {
 font-weight: bold;
 font-style: normal;
}

In Malawi, Baobab noted several key differences in the overall success of the same system deployed at Dedza District Hospital and Salima District Hospital, likely due to different training approaches used at each site. At Dedza, Baobab worked with the Lighthouse to offer a comprehensive training program that included all staff certified by MOH to provide ART care and treatment at that site, not just active ART clinic staff. Participants included the DHO. All of the Dedza staff were brought to Lilongwe for one day to visit the Martin Preuss Centre and to observe how the system is currently working.
At present, new users are trained by their peers to a reasonable standard, and there is an overall feeling of ownership of the system.
At Salima, much less effort was put into training. On-the-job training was provided to only the clerks, nurses and clinicians that would actually use the system.
The result was that users at Salima reported relatively more problems during the pilot. The specific issues included:
Incomplete patient records: time pressure, technical issues or user confusion resulted in incomplete entry of nurse visit or drug visit records
Unregistered patients: patients visited on non-clinic days and were seen by untrained staff
Transfer-In patients: patients who were transferring-in were registered before being given drugs
Hop-in Hop-out patients: patients were being registered twice because they had transferred out and then transferred in again
Dual-entry: staff complained about the extra work of entering data in the master card as well as the electronic system
Baobab has worked with the Salima staff to resolve these issues, and all parties have agreed on a plan to improve data quality and ensure consistent system use.
These problems were largely confined to Salima, while Dedza has encountered far fewer problems.

by Alvin Marcelo

There's a lot of problems with introducing technology, especially in health center facilities in the Philippines, where it's possible health workers haven't used computers the whole of their lives.

So can you imagine taking them from not having touched a computer their whole life and they're in their 40's and 50's and asking them to use a computer right there and then, instantly? For something they have to do on a daily basis. And we have a program and we're proud of that program because it's worked very well.

Imagine these are old women, never touched a computer their whole lives. So they were saying that CHITS was difficult to use, but actually it was really that they couldn't handle the mouse and the keyboard very well.

So learning from that we just decided: No CHITS until you can play Solitaire by yourself and you can beat your other co-worker with the highest score in Tetris or whatever. So we eliminated the interface problem. We wanted to make sure that there was no interface problem before we showed them the application. I think that's important.

On the actual training, this is after the two to four weeks interface exercise, we don't let them use the application immediately. We make sure that we have a proper orientation about the value of good quality, that it would be accurate, timely, legible, complete and useful things like the WHO definition.

The computer is now the tool to help them come up with their quality data. We have to link it from their analysis of the current situation where their data are inaccurate, delayed illegible so forth and so on and then bring them to a understanding that the computer is now the tool that helps them solve many of those poor quality data issues. That gets them to understand why these [people] are introducing computers into the facility in the first place. We thought that was important because unless they understand that it will always be an externally driven motivation rather than an internal motivation that was coming in from their own understanding and analysis of why they need technology to improve their systems.

We spend half a day to one day doing that. We use games to introduce the concepts. I will try to send you a URL of one particular video of that game. It's just a game but in the post game processing and analysis the concepts of system integration come to play: teamwork and communication. Thats where we bring them to the understanding of why computerization for your facility is the most logical way to go if you want to [improve] quality. After that is the time that we introduce the application because now they know why they need to learn the application. As a matter of fact they know that they will have difficulty using the application because in the games they had difficulty playing them at first and the lesson from the games is, "hey this is something new you're supposed to have difficulty at first". So it's not like when you immediately expose them to the application and they have difficulty they don't have handles or they don't have the coping mechanisms to understand why they have to suffer through all of the difficult mode use like registration and child care. So by creating that awareness and orientation on the importance of good quality data and role of computers in good quality data they're more emotionally and attitudinally ready for the stress that follows which is the learning of how to use the application we really can't remove the stress because it's a new system. What we try to do is to give them the defense mechanisms early on in the program so that than we eventually come to the point where they will use CHITS they already have the defense mechanism and the coping mechanisms to understand why they have to go through all of these difficulties. From then on it's downhill.

Actually the younger ones are more advanced. Some of the older ones are really hopeless, yet they help each other and it really builds confidence because they never thought [that they would ever learn to use a computer]. Many of them tell us thank you very much or "Doctor Alvin, you know I didn't even know that I could actually use a computer". Some of them have actually attended classes already on how to use Microsoft Word, how to use Microsoft Excel, or how to do power point slides. But they quickly forget it because in the end when they go back to the facility they don't use those programs. They don't type documents, they don't maintain spreadsheets and they don't do power point slides but with CHITS right after the training they go back to the facility and start using the electronic health record and almost every five minutes you have to interface with the system because you have to record the services that you have provided for the patient.

So we thought that that was something that we didn't want to do. We didn't want to give them any new computer skills that were not related to the work that they are supposed to do. So that's our experience of training and were bundling our training program into a package. The reason we're doing that is because their is so much interest already in electronic health records and in CHITS and I think I need to train more and more trainers to be able to scale up.

We have a lot of good stories on training because I think it was something that we did on top of the software. I don't really think it's like super software. It's not bad software, but it's not like MATLAB or anything like that. It's just a simple database, actually.

I think it's the training and the capacity building that got it in for CHITS. Not to detract any credit for Herman who developed the source code, but I think that the training program that came out of the software, I think that's the real value that we have right now. I think the software is going to change. We don't have AJAX in the old version, I think we should have AJAX in the new version, and things like that.

The training program, I think it will stick.

Telehealth - offer support to Telehealth applications such as teleconsultations.

!!Relevant Standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

[[Diagnosis]]

[[Medication]]

[[Laboratory]]

[[Snomed-CT]]

[[Nursing]]

[[International Classification Functionalities and Disabilities (ICF)]]

[[International Classification for Primary Care (ICPC)]]

 


!! Recommended Reading 

!! The Challenge 
Health information systems often lead to a huge mount of data collection forms. Much of the data collected for a patient is redundantly recorded as many forms duplicate fields. Not only does this make a mess for data managers, but it also is an inefficient use of human resources, particularly for clinicians.

Sadly most of the data never even appears in a report or is used for any purpose whatsoever. These “data-graveyards” are a pertinent problem that absorb IT storage capacity and human resources. Huge amounts of mostly unused data makes it more difficult to find useful information in these databases.

!! The Solution 
Centralized policies for routine data collection requirements and reporting can help reduce these problems. Core indicators should be identified that are needed for management, reporting and supervision. Knowing what these core indicators are will then allow a reduction in the number of forms and data elements on forms, and in general help to concentrate on basic data requirements. A “paper work reduction initiative” can be a good mechanism for fighting the problem of too much data.

This “less is more” approach will keep staff from wasting time on unnecessary work filling out forms and performing data aggregation procedures. 

Interoperability opportunities can improve synchronization between data sources either within a hospital or even countrywide. An operational data warehouse may become a critical technical component of the interoperability solutions.

!! Further Information 
[[Use it or Lose it]]
[[Indicator Selection]]
[[Monitoring and Evaluation]]
[[Data Use]]
[[Improving Accuracy of Data Collection]]
[[Human Resources]]
[[Training]]

!! Examples from the Field

!! Recommended Reading
[[Human Resources]]

!! The Challenge
Interoperable systems require many different human resources: users, operations managers, programmers, support staff. How can we train these positions to get the most out of these human resources?

!! The Solution

Proper training can make the difference between success and failure of any system component as well as the system as a whole. Issues to be aware of when developing any sort of training include: curriculum, trainee selection and methodology.

The curriculum must be properly targeted. This means that the curriculum should assume the right level of prerequisite knowledge of trainees. Getting this right requires a clear picture about how much experience and knowledge the existing trainees have. Furthermore the curriculum must provide enough material to ensure that upon completion the trainee can do the tasks required of them.

Trainees should be selected to ensure that important stakeholders, sometimes even those that will not use the system are included. Training non-users who might benefit from having a successful system help to ensure champions and organizational buy-in.

Specific training methodologies are beyond the scope of this pattern, but some approaches to consider include:

* training of trainers
* peer learning / on the job training
* conferences

Simple monitoring and evaluation techniques should be performed to understand the effectiveness of the trainings and to enable improvement. This can be facilitated by using exams and by gathering feedback from trainees.

!! Further Information
[[Use of Data Standards]]

!! Examples from the Field
[[System Training in Malawi]]
[[Targeted Training Using Games - Philippines]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References




[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References
Federal Health Architecture [6] 



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Is there a national health system in your country?
!!Is it focused in any particular area?
!!What systems or components are in place in the HIS, for example:
*Formal architecture described
*Human Resources
*Supply Chain Mgt.
*Laboratory Reporting
*Patient Care 
!!Is there a policy present in your country for:
*Health Information Systems
*Electronic Health Record
*Vertical Systems, e.g. HIV/AIDS, TB, Malaria
*Monitoring and Evaluation (M&E)
!!Is there a national eHealth Architecture? What is its stage of development?
!!Is a national data warehouse present?
*None
*Summary data
*Individual data
!!What types of standards are in use, for example:
*Vocabularies
*Interoperability 
*Security
*National Identifier/Registries
!!What associations or Standards Development Organizations (SDO) are present in your country, for example:
*Health Informatics Association (IMIA member?)
*HL7 Affiliate
*ISO MTC 215 Mirror Committee
*Health Informatics
*Monitoring and Evaluation (M&E)
!!Does your country have a national reporting infrastructure from facility to national level for individual and/or summary data?
!!What percentage of households have Internet access?



!!References
Care Record and the Logical Record Architecture for Health and Social Care from UK [7]  



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

/***
|''Name:''|UploadTiddlerPlugin|
|''Description:''|Upload a tiddler and Update a remote TiddlyWiki |
|''Version:''|1.2.2|
|''Date:''|2008-09-13|
|''Source:''|http://tiddlywiki.bidix.info/#UploadTiddlerPlugin|
|''Usage:''|Uses {{{<<uploadOptions>>}}}<br>with those UploadTiddler Options : <br>chkUploadTiddler: <<option chkUploadTiddler>><br>txtUploadTiddlerStoreUrl: <<option txtUploadTiddlerStoreUrl>><br>chkUploadTiddlerFromFile: <<option chkUploadTiddlerFromFile>>|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''[[License]]:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''CoreVersion:''|2.3.0|
***/
//{{{
version.extensions.UploadTiddlerPlugin = {
	major: 1, minor: 2, revision: 2, 
	date: new Date("2008-09-13"),
	source: 'http://tiddlywiki.bidix.info/#UploadTiddlerPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	coreVersion: '2.3.0'
};

if (!window.bidix) window.bidix = {}; // bidix namespace
bidix.debugMode = false;
bidix.uploadTiddler = {
	messages: {
		aboutToSaveTiddler: "About to update tiddler '%0'...",
		aboutToRemotelySaveTiddler: "About to REMOTELY update tiddler '%0'...",
		storeTiddlerNotFound: "Script store tiddler '%0' not found",
		tiddlerSaved: "Tiddler '%0' updated in '%1' using '%2' "
	},
	upload: function(title,tiddler,oldTitle) {
		var callback = function(status,params,responseText,url,xhr) {
			if (xhr.status == 404) {
				alert(bidix.uploadTiddler.messages.storeTiddlerNotFound.format([url]));
				return;
			}
			if ((bidix.debugMode) || (responseText.indexOf("Debug mode") >= 0 )) {
				alert(responseText);
				if (responseText.indexOf("Debug mode") >= 0 )
					responseText = responseText.substring(responseText.indexOf("\n\n")+2);
			} else if (responseText.charAt(0) != '0') 
				alert(responseText);
			else 
				displayMessage(bidix.uploadTiddler.messages.tiddlerSaved.format([params[0], params[1], params[2]]));
				store.setDirty(false);
			}

		if ((config.options['chkUploadTiddler']) && 
				((document.location.toString().substr(0,4) == "http") || config.options['chkUploadTiddlerFromFile'])) {
			clearMessage();
			if (document.location.toString().substr(0,4) != "http")
				displayMessage(bidix.uploadTiddler.messages.aboutToRemotelySaveTiddler.format([title]));
			else
				displayMessage(bidix.uploadTiddler.messages.aboutToSaveTiddler.format([title]));
			var ExtTiddler = null;
			var html = null;
			if (tiddler) {
				ExtTiddler = store.getSaver().externalizeTiddler(store,tiddler);
				html = wikifyStatic(tiddler.text,null,tiddler).htmlEncode();
			}
			var form = "title="+encodeURIComponent(title);
			form = form + "&tiddler="+(ExtTiddler?encodeURIComponent(ExtTiddler):'');
			form = form + "&html="+(html?encodeURIComponent(html):'');
			var filename = (config.options['txtUploadFilename']?config.options['txtUploadFilename']:'index.html');
			form = form +"&oldTitle="+encodeURIComponent(oldTitle);
			form = form +"&fileName="+encodeURIComponent(filename);
			form = form +"&backupDir="+encodeURIComponent(config.options['txtUploadBackupDir']);
			form = form +"&user="+encodeURIComponent(config.options['txtUploadUserName']);
			form = form +"&password="+encodeURIComponent(config.options['pasUploadPassword']);
			form = form +"&uploadir="+encodeURIComponent(config.options['txtUploadDir']);
			form = form +"&debug="+encodeURIComponent(0);
			var storeScript = (config.options.txtUploadTiddlerStoreUrl 
								? config.options.txtUploadTiddlerStoreUrl : 'storeTiddler.php');
			var r = doHttp("POST",storeScript,form+"\n",'application/x-www-form-urlencoded',
				config.options['txtUploadUserName'],config.options['pasUploadPassword'],callback,Array(title,filename, storeScript),null);
		}
	}
}
TiddlyWiki.prototype.saveTiddler_bidix = TiddlyWiki.prototype.saveTiddler;
TiddlyWiki.prototype.saveTiddler = function(oldTitle,newTitle,newBody,modifier,modified,tags,fields,clearChangeCount,created) {
	var tiddler = TiddlyWiki.prototype.saveTiddler_bidix.apply(this,arguments);
	var title = (newTitle?newTitle:oldTitle);
	if (oldTitle == title)
		oldTitle = '';
	bidix.uploadTiddler.upload(title, tiddler, oldTitle);
}
TiddlyWiki.prototype.removeTiddler_bidix =TiddlyWiki.prototype.removeTiddler;
TiddlyWiki.prototype.removeTiddler = function(title) {
	TiddlyWiki.prototype.removeTiddler_bidix.apply(this,arguments);
	bidix.uploadTiddler.upload(title, null);
}

//
// Initializations
//

bidix.initOption = function(name,value) {
	if (!config.options[name])
		config.options[name] = value;
};

// styleSheet
setStylesheet('.txtUploadTiddlerStoreUrl {width: 22em;}',"uploadTiddlerPluginStyles");

//optionsDesc
merge(config.optionsDesc,{
	txtUploadTiddlerStoreUrl: "Url of the UploadTiddlerService script (default: storeTiddler.php)",
	chkUploadTiddler: "Do per Tiddler upload using txtUploadTiddlerStoreUrl (default: false)",
	chkUploadTiddlerFromFile: "Upload tiddler even if TiddlyWiki is located on local file (default: false)"
});

// Options Initializations
bidix.initOption('txtUploadTiddlerStoreUrl','');
bidix.initOption('chkUploadTiddler','true');
bidix.initOption('chkUploadTiddlerFromFile','');


// add options in backstage UploadOptions
if (config.macros.uploadOptions) {
	if (config.macros.uploadOptions.options) {
		config.macros.uploadOptions.options.push("txtUploadTiddlerStoreUrl","chkUploadTiddler", "chkUploadTiddlerFromFile");
	}
}

//}}}

!! Recommended Reading 
[[Monitoring and Evaluation]]

!! The Challenge 
Systems are often designed by multiple stakeholders who each have their own data needs. As a result it is common for data to be collected but never used. This places a burden on the system and that often leads to poor outcomes.

!! The Solution 
Despite this topic's name, the solution is not to figure out how to use all of the data that is collected but rather how to 'lose' extraneous ones.

If a data element is not being used it should be eliminated and not collected. By eliminating unused data elements more time and care can be spent collecting, analyzing and using the data. 

While this sounds like a simple approach, in practice it can be quite difficult. Stakeholders will argue that someday they will analyze the data and that it will be very useful. It can be helpful to remind stakeholders that extra data for research purposes can be collected via statistically significant surveys. It is better to have fewer data elements of high quality than many that are unreliable.

It may also be difficult to eliminate extraneous processes at the clinic level. If healthcare worker has "always done it that way", then they may need careful convincing or at least a direct order from their manager. 

!! Further Information 
[[Data Use]]
[[Indicator Selection]]
[[Too Much Data]] 
[[Improving Accuracy of Data Collection]]

!! Examples from the Field 
[[Story About VCT Data in Malawi]]

 


!! Recommended Reading 
[[Data Use]]

!! The Challenge 
Applications within a national health system are usually built by different organizations for different stakeholders. It is critical that these different applications share data, but creating policies, protocols and interfaces for transferring data between these applications is a tedious process.

!! The Solution 
International standards for data already exist that provide consistent and usually sufficient means for transferring data between most types of health applications. When applications need to share data, they should be chosen or developed so that they that implement and use data standards. Adopting data standards is not only an efficient approach to solving problems, it also helps applications follow conventions that are based on best practices learned elsewhere.

Data standards can address issues of how to:

* store patient data
* transfer lab information
* transfer aggregate indicators
* structure reports

When selecting which data standards to use it is critical to consider how that data will be used. For example, if data is used only to generate aggregate reports you would probably use a different data standard than if the data was used for patient care.

!! Further Information 
[[Application Development]]
[[International Standards]] (contains links to many standards)

!! Examples from the Field

!! Recommended Reading 
[[National, International and Donor Reporting]]

!! The Challenge 
International reporting often focuses on a single disease or focus (like maternal health) resulting in vertical reporting systems. While addressing the needs of a particular program, integration of data and overall health system strengthening can suffer. For example, AIDS programmes have been criticized for diverting resources from other equally serious diseases. How can we strengthen the overall health system while acknowledging that particularly serious problems will be prioritized?

!! The Solution 
A growing acknowledgement of the potential adverse impact of vertical systems has led to development of 'horizontal' system strengthening where vertical programmes also support health system strengthening. Efforts have been made to incorporate activities beneficial to overall health and monitoring system strengthening such as health data standards, software development, and harmonization of indicators to address this.

By adopting interoperable architectures horizontal system strengthening may occur as well. For instance, a good patient identification scheme is not disease dependent and can be used to track inpatient care at a hospital. These kind of horizontal value adds may need policy making or general awareness building in order to elicit widescale adoption.

!! Further Information

!! Examples from the Field 
PEPFAR support for vertical health system strengthening.

Multiple sources of indicator definitions containing discrepancies or incomplete metadata limit our ability to collect comparable data upon which to base analyses. Efforts to rationalize and streamline computer and human processes associated with indicator management are needed.

To address this need, the WHO Indicator and Metadata Registry (IMR) attempts to leverage the strengths of knowledge in data exchange and Monitoring and Evaluation (M&E) to build a more mature infrastructure for managing indicator definitions.

Guidelines documents produced by reference groups may not contain sufficient information to create a computer application, i.e. calculation or disaggregation information may not be present. Further, when multiple groups define ostensibly the same indicators, differences occur, including differences in metadata and representation, making exchange of data difficult.

The IMR works with programme profiles and codelists for indicators similarly to controlled vocabularies for clinical concepts. Efforts are ongoing to link indicators and clinical concepts to insure consistency between the two. Eventually, clinical concept definitions will be incorporated into the SDMX-HD (Health Domain) indicator exchange format to provide indicator definitions to clinical systems in a compatible manner.

By studying lessons learned in the clinical world, the IMR manages indicator definitions in a similar way, supporting the differences that occur while providing a means to accommodate and harmonize them.

!!Impact
An indicator management infrastructure can improve our ability to define, collect, and analyze indicator data. The accuracy and timeliness of analyses will improve as variant definitions converge and data moves in a more streamlined manner via more automated international reporting.

Using the SDMX-HD in software development will make software development more cost-effective by leveraging existing application's functionality, e.g. geographic mapping, and elimination of costly data mapping between systems. Through web services, applications can access these definitions directly over the Internet, enabling the use of common indicator definitions among disparate systems.

!!Solution
a) Work Processes
Indicator management includes both human and computer components. While indicator management processes may exist, they are contained in separate programmes with limited opportunity for sharing across other groups or for insuring compatibility with international and organizational standards. Internal and external programmes can adopt the parts of the IMR application's functionality that match their work processes.

b) WHO Indicator and Metadata Registry (IMR)
The IMR includes functionality to support development, harmonization, vetting, and sharing of programmatic indicator definitions.
The IMR provides the missing link between M&E analysts and software developers. By implementing international standards for metadata and semantic content, indicator definitions can be constructed that can be shared and implemented in multiple computer systems. Complete data dictionaries can be easily prepared, historically a labor-intensive and neglected task that promotes data comparability.

An added benefit of centralized indicator management is assignment of global identifiers, which facilitates aggregation of data and preparation of reports at the international level. Ambiguity about indicator equivalence is removed for sources supporting the SDMX-HD with definitions distributed from the IMR.

The data returned is self-contained, having the metadata included, and ready for validation, publication, and sharing. Translation utilities for the IMR reduce the burden of multi-lingual support, facilitating sharable translations for computer applications, dictionaries, and data from a single source.

!!References
WHO Indicator and Metadata Registry [14]
WHO SDMX-HD Indicator transmission format [15]

[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!! Recommended Reading

!! The Challenge
Where and how do you start in working with interoperability within the health information system?

!! The Solution
First identify your immediate business needs and drivers as well as your initial entry point into the health information system. For the purposes of this pattern, this is that aspect of the health information system that makes the most sense to deal with first in terms of impact across the system, greatest need, available funding, executive support and likelihood of success. It can range from clinical admissions of patients, to national drug stock management, to management of lab data to reporting of indicators and so on.

Once this entry point has been identified it must be put into context so that it is clearly understood how it interacts with the health information system. What are the connection points? what kinds of information is exchanged and how? who are the entities involved in managing it? what are the governance and policy issues around that concern the entry point?[[Enterprise Architecture]] approaches can help to define this context.

Defining this context around the entry point will lead to the identification of the interoperability issues that need to be addressed from a technical, resource, and governance/policy perspective. As these are addressed, you can work your way outwards to cover more and more of the health information system in a systematic and orderly way.

Usually a good idea to create a [[Technical Working Group]] to manage and coordinate issues around this process

Prioritization

!! Further Information
[[Enterprise Architecture]]
[[Technical Working Group]]

!! Examples from the Field
The development of the health informatics working group in Malawi?

!! Recommended Reading
[[Data Use]]

!! The Challenge
A health system, and an interoperable system in particular, consists of many different people and processes capturing and using information for many different purposes. Coordinating these processes so that they are efficient and the information is leveraged appropriately throughout the system is a large and complicated process.

!! The Solution
The key driver for interoperable systems is the compelling use of data in a different context. Data collected and shared for its own sake or without a clear use is not likely to serve a real purpose or have any built in incentive to be timely or of quality. A lack of interoperability prevents data from being available for specific tasks within a given work flow.

The first step to understanding existing work flows is to create a map of how information flows through the system being scrutinized. For example, by examining who needs whose data to accomplish what essential tasks, critical interoperability issues and junctures become apparent. This map can also help eliminate redundant data collection.

As this map develops it becomes clear how to distribute the data collection processes and how to included feedback loops that make sure data is being used to its full potential. The key work flows, the paths of really critical information will also become evident and can be prioritized.

Finally, this high level view can make it easier to compare the work flows of two related systems or countries. This can make possible collaboration, reuse, and the identification of which international standards are appropriate.

!! Discussion
1. Discuss a time when you were asked the same question twice.
2. Collaborate on mapping a work flow for a health system. Start with something small like a clinic. Show the individuals involved and the data that flows between them.

!! Further Information
[[Monitoring and Evaluation]]

!! Examples from the Field

In Malawi at Kamuzu Central Hospital patients arrive very early to ensure that they get the healthcare services they need. Before an electronic patient registration system was created patients would queue for hours every morning, stretching off from the hospital into the parking lot exposed to the sun or rain. Whether or not a patient had been to the hospital before they were required to fill out a paper form. For many this was not a straightforward process, and moving each patient registration window would require a lot of time. Of course, registering patients, and being able to know how many people are coming and for what services is a fundamental requirement for managing a hospital.
When Baobab Health created an electronic patient registration system it was important to be able to provide the hospital with the information they needed for management purposes. It was also important to not dramatically alter the workflow. As a result, Baobab studied the existing workflow and built a touchscreen based system that enabled clerks with little training to be able to register patients.

Malawi CD4 lab data transfer for patient management.
Malawi HIV reporting.
IHI work in South Africa Joburg General hospital on patient flows.
Kisumu team meetings on patient flows.
Eldoret use of patient summaries to provide just in time data for clinical teams.
CRIS collection on HIV indicators.
Rwanda Partners in Health work of using patient data for better stock management of pharmaceuticals.

Workflow - offer support for patient flow management, facilitate intelligent scheduling such as that required for patient’s referral and counter-referral.

!!Relevant Standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

Type the text for 'YourName'

!!References
European Electronic Health Record Project and the 'eHealth-INTEROP' European Project (response to the European Mandate 403) [8]



[[Back|1.2.1 Part 1 - International Initiatives on eHealth Systems]]

!!Relevant standards



!!References



[[Back|1.2.2 Part 2 - Business Requirements for an eHealth Enterprise Architecture]]

{{{
// Specify your account number here!
_uacct = "UA-1234567-1";

// AutoLinkTiddler as a namespace for tracking related functions
var AutoLinkTiddler = {
  // store a reference to the original displayTiddler function
  displayTiddler: story.displayTiddler
};

AutoLinkTiddler.addLinks = function() {
  /*if (readOnly) {
  urchinTracker.apply(this, arguments);
  }
  */
  /* TODO add action here */
};

AutoLinkTiddler.addLinksAndDisplayTiddler = function(srcElement, titles) {
  // log with the tracker
  AutoLinkTiddler.addLinks('/' + titles);
  // call the original displayTiddler function
  AutoLinkTiddler.displayTiddler.apply(this,arguments);
};

// replace the default displayTiddler function with a tracking version
story.displayTiddler = AutoLinkTiddler.addLinksAndDisplayTiddler;

// Call once for the initial page load
AutoLinkTiddler.addLinks();
}}}

<<forEachTiddler
  where
  '! tiddler.tags.containsAny([["excludeLists"]])'
  write
  '"<<redirect \""+tiddler.title+"\" [["+tiddler.title+"]]$))<<redirect  interoperable [[Interoperability]]$))<<redirect  meetings [[Constructive Meetings]]$))"'
>>