Technology Working Group
Specification / Technical Outline
Primary Health
Forms Server & Forms Rendering Engine (PHForms)
Protocol 5 revision 1 – Forms
Server 5.145/HTTP1.1
Copyright ©2004 Primary Health Ltd
All trademarks &
registered trademarks mentioned are for illustration purposes only, and remain
the property of their respective owners. ALL OTHER RIGHTS RESERVED.
This document is indexed with status 410. The
information contained herein is PRIVALEDGED INFORMATION and is strictly
internal. Please ensure that you follow the document confidentiality rules when
viewing or printing this document.
Status 410 documents MUST be protected – Leaking this information may result in
termination of employment.
Contents
What is the Primary Health Forms Engine?
Further Information & Suggested Reading
Introduction
This is the technology outline and development specification for the Primary Health Forms Engine, or PHForms. We are concerned here with version 5 of the PHForms protocol.
PHForms is very much the centre of Primary Health – it is this subsystem that has responsibility for storage, enumeration, retrieval, rendering and control of the on-screen forms used by Clinician. PHForms has designed to be a totally extensible, scalable solution to paperless forms, meaning that it can grow with Primary Health, and can always provide enough flexibility to allow any form to be implemented.
PHForms is implemented as a two-tier client/server software subsystem for Microsoft® Windows® 95/98/ME/2000/NT/XP. This design gives maximum flexibility both with the design of the application, and of the forms themselves.
As well as this, the modular implementation allows us to re-use PHForms in any software application that requires on-screen form-filling.
In specifying and designing PHForms we have taken great care to ensure that we use tried-and-tested industry standards where appropriate (and have correctly and completely implemented those standards).
In short, The Primary Health Forms Engine represents the state-of-the-art in computerised form filling and data entry. By taking advantage of technologies as varied as Microsoft’s ActiveX, ODBC, and XML we have created a high-performance, extensible, scalable, reusable solution with a validated architecture based on tried and trusted technology.
Version 5 of the PHForms protocol represents a turning point in computerised forms technology – never before has a solution such as this been available.
Terms used in this document
The term “Primary Health” is used throughout this document, to refer to both Primary Health Limited and the Primary Health Solution. Usually context will make it obvious which Primary Health is being referred to. Where this is not the case, however, we will specify. Since this is a technical document, we assume some technical knowledge on the part of the reader. You should be at least aware of the following terms, and the technologies that lie behind them: Software, Application, Microsoft® Windows®, Executable, Dynamic Link Library (DLL), Client, Server, Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML) and Extensible Markup Language (XML).
In the context of this document, the word Forms refers to on-screen versions of paper-based forms. We do use the word as it is used in a GUI Development context, to refer to windows on screen.
What is the Primary Health Forms Engine?
The Primary Health Solution centres around the Clinician application, which is used at the pharmacy end of the system for the actual entry data. Clinician is designed to replace the paper-based forms that are normally used by these schemes.
Providing on-screen versions of paper forms, and handling the logic behind them is, at first glance, a relatively simple task. Of course, we could take the most basic approach of just using standard controls (buttons, check boxes, etc) and creating the forms as application code. However, what happens when new forms are needed? Or old ones updated? In this scenario, even a simple update would require code-level rewrites to the application itself, followed by the standard testing cycle and then redeployment. Obviously this is not an attractive solution.
How does it work?
The Primary Health Forms Engine, or PHForms, takes a modular approach to the problem of on-screen form provision and management. PHForms is designed around a two-tier (or client-server) architecture, communicating via TCP/IP. Communication between the two is facilitated over the Hypertext Transfer Protocol (HTTP).
The forms engine takes responsibility not only for storage, provision and rendering of the forms, but also for the associated logic control and data storage. The PHForms protocol defines a rich Module Programming Interface (MPI) with routines for interfacing with the Primary Health Local Store (PHStore) engine, and the rest of Primary Health.
Forms Implementation
Forms are distributed as modules, implemented as Windows Dynamic Link Libraries (DLLs). These libraries conform to a standard interface specification (which is part of the PHForms specification), and are totally self-contained. These modules are enumerated dynamically by the PHForms Server at start-up, and each one is assigned an “address”, based on the forms GUID, which is used by the forms renderer to retrieve forms as needed.
Communication within the system uses the Hypertext Transfer Protocol over TCP/IP. The Forms Server is essentially a custom-written, non-file-based HTTP server, to which the Rendering Engine connects to retrieve the forms. When such connections are made, the server links to the appropriate module DLL and retrieves the XHTML source for the form. This is then returned to the rendering engine over the HTTP connection for rendering.
Forms Server
The server runs within a background application on Windows 95/98 and ME, or as a full network service on NT, 2000 or XP. The reasons for, and differences between, these two methods are beyond the scope of this document (refer to the Win32 Platform SDK for more information) but suffice to say that the server is started with the computer and runs in the background until shutdown. Server control is quite limited (configuration being largely automatic) but is accessible either from the control panel or a system-tray icon, depending on the OS version being used.
When connections are received by the server, the requested URL is analysed and translated into the appropriate forms module and command. If the client is requesting the form source then this is retrieved from the DLL and returned as XHTML content. If the request is a data storage or manipulation request then the appropriate calls are made to the PHStore engine, and status information is returned as appropriate.
Total flexibility and platform/protocol independence is maintained at all times by keeping the server separate from the forms and data. The server knows how to use the module DLL, and how to interface with PHStore. Apart from that the structure, layout or format of the data is irrelevant.
Forms Renderer (Client)
The forms renderer is provided as a DLL, ready to be linked to an application. The functions and data-types exported by this library form part of the PHForms API, and are thus standardised and well defined. This allows us to use the PHForms engine, unchanged, in other applications, or to license it for use by other vendors, without providing any source-code (other than the PHForms MPI interfaces).
The forms renderer is responsible for retrieving forms from the server, rendering them within the application, managing the logic involved as they are filled in, and sending appropriate requests to the server to retrieve and store the form data. Again, the renderer is designed as a self-contained ‘sealed’ subsystem, ready to be dropped in to any application as required. The MPI provides a rich set of functions to provide fine-grained control over forms rendering and management.
The rendering itself is provided by the Microsoft HTML rendering library, which is distributed with Internet Explorer and later versions of the Windows OS. Since the libraries that provide this are freely distributable (subject to the Microsoft licence agreement) PHForms does not require IE to be installed on the host machine – the required libraries are distributed with PHForms.
When handling a form, the renderer first sends a HTTP ‘GET’ command to the Forms Server, with an appropriate URL comprised of a module GUID (Globally Unique Identifier), and a ‘Retrieve Form’ method. The server responds by searching the list of installed modules for the appropriate module, and calls the appropriate function to obtain the XHTML form code.
Once the XHTML source is received, the rendered checks it authenticity against a list of legal form signatures. If the form is valid then it is parsed and rendered (drawn) by the Microsoft HTML rendering library into the containing application.
The form logic (i.e. the order in which the fields must be filled, field validation and so on) are handled at the client side. This logic can be implemented in standard client-side manner, although JavaScript would be the natural choice.
Once the form is filled in (and has been validated according to the rules set by the code contained in the form source), the user clicks the ‘Accept’ button. This causes a Server request to be generated with the same module GUID as before. This request includes the data from the form, which is passed by the server back to the form’s module library, which uses the routines provided by the PHStore MPI to store the data in whatever format is appropriate.
The Extensible Solution
As previous mentioned, the client/server implementation of PHForms gives us a highly scalable and extensible solution. Because the implementation of specific forms is insulated from the architecture used to deploy and deliver those forms we have a totally flexible system, especially when coupled with the programmable client-side rendering.
Consider the example of a large chain of pharmacies, where the same forms are used throughout. Thanks to the two-tier form delivery method a single Forms Server can serve multiple clients over a Local Area (or even Wide Area) Network.
In fact, as long as the network transport layer supports the TCP protocol PHForms can be configured to work with any networked system.
The two-tier implementation of the forms themselves continues this theme of scalability with it’s reliance on industry-standard technologies and protocols. Because the forms themselves are programmable there are no limits on what each form can achieve, and by delegating responsibility for data storage to the module we place no limitations on the information a form can store.
A truly modern solution
As mentioned previously, PHForms represents the state-of-the-art in modern computerised data entry and processing. Thanks to it’s distributed design and programmable interfaces PHForms is a powerful, flexible foundation.
With no limitations as to what can be achieved, PHForms represents a truly twenty-first century paperless solution to distributed people-systems.
Further Information & Suggested Reading
More information about PHForms and the Primary Health Solution can be found at:
www.primaryhealth.co.uk/products.html.
For more details about XML, XHTML, or any of the other web technologies mentioned in this document, see the World Wide Web Consortium (W3C) website:
The following Primary Health Technology Documents are also relevant to PHForms:
PHForms MPI Developer Reference (Document 041-14122604-0420-021)
PHForms URI Specification (Document 041-15710603-0420-021)