=== added file 'src/docbkx/en/dhis2_implementation_guide_as_a_platform.xml'
--- src/docbkx/en/dhis2_implementation_guide_as_a_platform.xml	1970-01-01 00:00:00 +0000
+++ src/docbkx/en/dhis2_implementation_guide_as_a_platform.xml	2011-12-26 10:56:40 +0000
@@ -0,0 +1,62 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This document was created with Syntext Serna Free. --><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" []>
+<chapter>
+  <title>DHIS as a platform</title>
+  <para>DHIS can be perceived as a platform on several levels. First, the application database is designed ground-up with flexibility in mind. Data structures such as data elements, organisation units, forms and user roles can be defined completely freely through the application user interface. This makes it possible for the system to be adapted to a multitude of locale contexts and use-cases. We have seen that DHIS supports most major requirements for routine data capture and analysis emerging in country implementations. It also makes it possible for DHIS to serve as management system for domains such as logistics, labs and finance.</para>
+  <para>Second, due to the modular design of DHIS it can be extended with additional software modules. These software modules can live side by side with the core modules of DHIS and can be integrated into the DHIS portal and menu system. This is a powerful feature as it makes it possible to extend the system with extra functionality when needed, typically for country specific requirements as earlier pointed out.</para>
+  <para>The downside of the software module extensibility is that it puts several constraints on the development process. The developers creating the extra functionality are limited to the DHIS technology in terms of programming language and software frameworks, in addition to the constraints put on the design of modules by the DHIS portal solution. Also, these modules must be included in the DHIS software when the software is built and deployed on the web server, not dynamically during run-time. </para>
+  <para>In order to overcome these limitations and achieve a looser coupling between the DHIS service layer and additional software artifacts, the DHIS development team decided to create a Web API. This Web API complies with the rules of the REST architectural style. This implies that:</para>
+  <itemizedlist>
+    <listitem>
+      <para>The Web API provides a navigable and machine-readable interface to the complete DHIS data model. For instance, one can access the full list of data elements, then navigate using the provided hyperlink to a particular data element of interest, then navigate using the provided hyperlink to the list of forms which this data element is part of. E.g. clients will only do state transitions using the hyperlinks which are dynamically embedded in the responses.</para>
+    </listitem>
+    <listitem>
+      <para>Data is accessed through a uniform interface (URLs) using a well-known protocol. There are no fancy transport formats or protocols involved - just the well-tested, well-understood HTTP protocol which is the main building block of the Web today. This implies that third-party developers can develop software using the DHIS data model and data without knowing the DHIS specific technology or complying with the DHIS design constraints. </para>
+    </listitem>
+    <listitem>
+      <para>All data including meta-data, reports, maps and charts, known as resources in REST terminology, can be retrieved in most of the popular representation formats of the Web of today, such as HTML, XML, JSON, PDF and PNG. These formats are widely supported in applications and programming languages and gives third-party developers a wide range of implementation options.</para>
+    </listitem>
+  </itemizedlist>
+  <graphic fileref="resources/images/implementation_guide/dhis_platform.png" width="80%" format="PNG" align="center"/>
+  <para>There are several scenarios where additional software artifacts may connect to the DHIS Web API.</para>
+  <section>
+    <title>Web portals</title>
+    <para>First, Web portals may be built on top of the Web API. A Web portal in this regard is a web site which functions as a point of access to information from a potential large number of data sources which typically share a common theme. The role of the Web portal is to make such data sources easily accessible in a structured fashion under a common look-and-feel and provide a comprehensive data view for end users.</para>
+    <para>Aggregate data repository: A Web portal targeted at the health domain may use the DHIS as the main source for aggregate data. The portal can connect to the Web API and communicate with relevant resources such as maps, charts, reports, tables and static documents. These data views can dynamically visualize aggregate data based on queries on the organisation unit, indicator or period dimension. The portal can add value to the information accessibility in several ways. It can be structured in a user-friendly way and make data accessible to inexperienced users. It can provide various approaches to the data, including:</para>
+    <itemizedlist>
+      <listitem>
+        <para>Thematic - grouping indicators by topic. Examples of such topics are immunization, mother care, notifiable diseases and environmental health.</para>
+      </listitem>
+      <listitem>
+        <para>Geographical - grouping data by provinces. This will enable easy comparison of performance and workload.</para>
+      </listitem>
+    </itemizedlist>
+    <para>Mash-up: The Web portal is not limited to consuming data from a single Web API - it can be connected to any number of APIs and be used to mash up data from auxiliary systems within the health domain. If available the portal might pull into specialized data from logistics systems tracking and managing ARV medicines, from finance systems managing payments to health facilities and from lab systems tracking lab tests for communicable diseases. Data from all of these sources might be presented in a coherent and meaningful way to provide better insight in the situation of the health domain.</para>
+    <para>Document repository: The Web portal can act as a document repository in itself (also referred to as content management system). Relevant documents such as published reports, survey data, annual operational plans and FAQs might be uploaded and managed in terms of ownership, version control and classification. This makes the portal a central point for document sharing and collaboration. The emergence of high-quality, open source repository/CMS solutions such as Alfresco and Drupal makes this approach more feasible and compelling.</para>
+    <para>Knowledge management: KM refers to practices for identifying, materializing and distributing insight and experience. In our context it relates to all aspects of information system implementation and use, such as:</para>
+    <itemizedlist>
+      <listitem>
+        <para>Database design</para>
+      </listitem>
+      <listitem>
+        <para>Information system usage and how-to</para>
+      </listitem>
+      <listitem>
+        <para>End-user training guidelines</para>
+      </listitem>
+      <listitem>
+        <para>Data use, analysis and interpretation</para>
+      </listitem>
+    </itemizedlist>
+    <para>Knowledge and learning within these areas can be materialized in the form of manuals, papers, books, slide sets, videos, system embedded help text, online learning sites, forums, FAQs and more. All of these artifacts might be published and made accessible from the Web portal.</para>
+    <para>Forum: The portal can provide a forum for hosting discussions between professional users. The subject can range from help for performing basic operations in the health information system to discussions over data analysis and interpretation topics. Such a forum can act as interactive source for information and evolve naturally into a valuable archive.</para>
+  </section>
+  <section>
+    <title>Apps</title>
+    <para>Second, third-party software clients running on devices such as mobile phones, smart phones and tablets may connect to the DHIS Web API and read and write to relevant resources. For instance, third-party developers may create a client running on the Android operating system on mobile devices targeted at community health workers who needs to keep track of the people to visit, register vital data for each encounter and receive reminders of due dates for patient care while travelling freely in the community. Such a client application might interact with the patient and activity plan resources exposed by the DHIS Web API. The developer will not be dependent on deep insight in the DHIS internal implementation, rather just basic skills within HTTP/Web programming and a bit of knowledge of the DHIS data model. Understanding the DHIS data model is made easier by the navigable nature of the Web API.</para>
+  </section>
+  <section>
+    <title>Information Systems</title>
+    <para>Third, information system developers aiming at creating new ways of visualizing and presenting aggregate data can utilize the DHIS Web API as the service layer of their system. The effort needed for developing new information systems and maintaining them over time is often largely under-estimated. Instead of starting from scratch, a new application can be built on top of the Web API. Developer attention can be directed towards making new, innovative and creative data representations and visualizations, in the form of e.g. dashboards, GIS and charting components.</para>
+  </section>
+</chapter>

=== modified file 'src/docbkx/en/dhis2_implementation_guide_en.xml'
--- src/docbkx/en/dhis2_implementation_guide_en.xml	2011-06-19 13:38:03 +0000
+++ src/docbkx/en/dhis2_implementation_guide_en.xml	2011-12-26 10:56:40 +0000
@@ -58,4 +58,5 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dhis2_implementation_guide_users_and_user_roles.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dhis2_implementation_guide_data_analysis_tools_overview.xml" encoding="UTF-8"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dhis2_implementation_guide_pivot_tables_and_mydatamart.xml" encoding="UTF-8"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dhis2_implementation_guide_as_a_platform.xml" encoding="UTF-8"/>
 </book>

=== added file 'src/docbkx/en/resources/images/implementation_guide/dhis_platform.png'
Binary files src/docbkx/en/resources/images/implementation_guide/dhis_platform.png	1970-01-01 00:00:00 +0000 and src/docbkx/en/resources/images/implementation_guide/dhis_platform.png	2011-12-26 10:56:40 +0000 differ