Applying the XForms Standard to Public Health Case Reporting and Alerting.

Notifiable condition reporting and alerting are two important public health functions. Today, a variety of methods are used to transfer these types of information. The increasing use of electronic health record systems by healthcare providers makes new types of electronic communication possible. We used the XForms standard and nationally recognized technical profiles to demonstrate the communication of both notifiable condition reports and patient-tailored public health alerts. This demonstration of bi-directional communication took placein a prototypical health information exchange environment. We successfully transferred information between provider electronic health record systems and public health systems for notifiable condition reporting. Patient-specific alerts were successfully sent from public health to provider systems. In this paper we discuss the benefits of XForms, including the use of XML, advanced form controls, form initialization and reduction in scripting. We also review implementation challenges, the maturity of the technology and its suitability for use in public health.

INTRODUCTION

Surveillance of the public's health depends on the collection, investigation and distribution of data and information about illness and health. Timely reporting of notifiable conditions (e.g., tuberculosis, vibriosis, or chlamydia, among numerous other conditions) to public health agenciesby health care providers (HCPs), health care facilities, laboratories, veterinarians, food service establishments, child day care facilities, and schools supports early detection of risks to the community such as outbreaks of infectious or foodborne diseases. Public health and other government organizations use the information collected in these case reports to prevent and control diseases. Also important to the protection of the population’s health is the communication of health information from public health agencies to the community. One specific type of communication is public health alerting, e.g., public health warnings about outbreaks, preventive measures, and recommendations sent to HCPs.

Case reporting, also referred to as notifiable condition reporting, and public health alerting are part of a bi-directional transfer of information in which information in the form of case reports are transferred from HCPsto public health agencies and information in the form of public health alerts is transferred from public health agencies to HCPs. In the US, this bi-directional communication is being carried out with varying levels of sophistication and success: approaches topublic health alerting cover a broad range of communication types, including print, fax, email, and text message (1). Notifiable condition reporting methods are similarly varied, ranging from faxed case-report forms to sophisticated electronic laboratory reporting systems.

Public health informaticians recognize the importance of data and information exchange standards which define the structure and syntax for sending and receiving information (2–5). Strengthening the connection between public health and provider systems requires interoperability and the use of standards in both public health and clinical care settings. Although public health organizations in the US have been slow to adopt these standards, public-private partnerships (6–8) have been working to ensure that bi-directional communication between public health and HCPs is incorporated into national health information infrastructure standards.

Public health use cases describe the interactions between the various components of an information exchange based on a real-life scenario, thus providing a common focus for the different activities to inform development of specific requirements, architecture, and standards. This paper describes our experience using technical profiles and implementing XForms in a notifiable condition reporting and patient-tailored alerting public health use case. XForms were implemented in a prototypical health information exchange (HIE) demonstration and testing environment. We also explore the feasibility and possible implications of the use of these profiles and standards in public health.

BACKGROUND

Notifiable Condition Reporting (Case Reporting)

The timeliness and completeness of notifiable conditions data which public health agencies rely on to track diseases, target interventions, mitigate harmful exposures, initiate investigations, and develop program activities and policies vary widely. In an analytic literature review, Doyle et al. (2002) found that reporting completeness varied from 9% to 99% and was strongly associated with the specific disease reported. For example, active surveillance systems for certain diseases, like sexually transmitted infections, had higher completeness rates (9). And while timeliness requirements are often specified by health jurisdictions or state law, measures of timeliness do not always meet the specified standards. (10)

Timely and complete case reports are essential to public health surveillance work. Technological developments such as the adoption of electronic laboratory reporting systems have improved the timeliness and completeness of reported notifiable conditions data (11–13). For example, National Electronic Disease Surveillance System (NEDSS) was introduced in 2000 as a new method for US notifiable condition reporting and surveillance. NEDSS was designed to facilitate electronic surveillance of infectious diseases outbreaks, emerging or reemerging pathogens and to identify possible bioterrorist attacks. This system further evolved to become a reporting system which would allow rapid communication among public health authorities of varying size and technical capacity (14). NEDSS also prompted some state and municipal health departments to begin researching and building electronic surveillance systems for their regions, resulting in significant improvements in reporting rates and data quality (15).

Many health departments in the US share similar work practices (16); however, nationally recognized standards for content, collection and delivery of notifiable condition data have not been widely adopted. To accelerate adoption, in 2007 the Centers for Disease Control and Prevention (CDC), in cooperation with the Council for State and Territorial Epidemiologists (CSTE), began work on an Implementation Guide for Health Level 7 (HL7) Version 3 Clinical Document Architecture (CDA). The Implementation Guide provides a framework and related standards for the exchange, integration, sharing, and retrieval of notifiable condition reporting from an electronic health record (EHR) to public health (17). In 2010 a more general, non-disease-specific model for automated public health case reporting using HL7 version 2.5 was proposed (18).

Rapid development in the areas of messaging and data standards in health care, as well as the ever increasing technical capability of both public health and provider organizations, suggest that electronic notifiable condition reporting may soon be feasible on a large scale. These same advancements in technology also provide the infrastructure to support changes in the way public health communicates information to providers, such as context-specific public health alerts.

Public Health Alerting

Alerting systems that facilitate the delivery of public health information to HCPs rely on the interactive contribution of HCPs both prior to and during a public health event. Bi-directional communication between HCPs and public health has been well-documented, particularly since 2001. A systematic review of US disease outbreak detection reported that the coordination necessary for aggregating, analyzing, and sharing data between the clinical health care system and local and state public health agencies was a key component in prompt detection of infectious disease outbreaks (19). Additionally, many infectious disease agents are initially difficult to identify: signs may be nonspecific and illnesses may be scattered geographically (20). Increasing numbers of individuals presenting to HCPs, pharmacists, hospital emergency rooms, and others can serve as sentinel events for disease outbreaks in the community (21–23). In the event of a bioterrorist attack, in which there may be a delay between exposure and symptom onset, public health relies on HCPs and laboratories to report cases of unexplained or unusual illness to public health officials who, in turn, may be able to identify specific epidemiologic patterns or characteristics indicative of a bioterrorist act (24).

Several programs are designed to facilitate alert communications between public health agencies and HCPs, however, few specify the appropriate timing of communications or contain details regarding which specific organizations or providers should be contacted in a particular type of emergency. While the 2001 anthrax attacks identified electronic communications systems as high priority in facilitating effective infectious disease surveillance and investigation, it is not known the extent to which systems such as the Epidemic Information Exchange and the CDC’s Health Alert Network have improved surveillance or communications. These public health alerting systems use electronic communication methods such as e-mail and broadcast fax to link public health agencies with HCPs and other community groups (25). However, coverage of messages relayed via these methods is unknown or lower than it could be as the system relies on HCP registries that may contain incomplete, missing or out-of-date e-mail and/or fax contact information.

The receipt and assimilation of messages by providers is a pre requisite to any related subsequent action, including enhanced event reporting and responsible communication of information to patients (26). Though alerts can be communicated using various methods, using EHRs as the communication resource offers the potential to provide both timely and context specific information to HCPs (27). In Indiana, public health alerts have been added to the current clinical results delivery service in order to integrate the communication into the physician’s workflow (28). Unfortunately, overwhelmed providers often suffer from ‘alert fatigue,’ dismissing even context-specific alerts from clinical decision support or computerized provider order entry systems (29–31). More research is needed to measure the impact of different types of public health alerts as technological developments offer the chance to augment public health-provider communication. One such development is the XForms standard.

XForms

Web forms are a common tool used on websites to accept user input for activities such as searches, surveys, file uploads, and purchases. They are also common in other areas where structured communication is important, including public health. Some simple web forms can be built using HTML. The data collected using an HTML form, as a set of name-value pairs, can be submitted to a server or sent using email. However, HTML forms have several limitations: reliance on scripting for managing form behavior and dynamic content; difficulty initializing a form with existing data; and constraints of the formats for encoding HTML form data (32). HTML forms are appropriate for some simple tasks, but the complex needs of users and the limitations of HTML forms have led to the development of web form alternatives. One alternative is XForms.

In 2000, recognizing the limitations of HTML forms, a World Wide Web Consortium Forms Working Group (FWG) was created to help guide the development of new web forms technology (33). The FWG leveraged existing XML recommendations (34) in meeting the following development goals: support for structured data; improvement in accessibility; support for interrupted form completion; and decoupling of the data, logic, and presentation of a form (33). While the FWG goals are compelling, it is important to note that XForms does not represent a document type that can stand alone, but is meant to be integrated into other markup languages such as XHTML.

However, XForms was touted as the “next generation of web forms” because of its flexibility, portability, and unique separation of data and presentation (35). Additional advantages include: the ability to incorporate metadata to describe the history and attributes of a particular form instance; the capability to include validation information for data elements on the form which reduces the amount of script needed for data validation; and the availability of components that allow the user to interact with XForms using either stand-alone programs or a web browser.

XForms has been demonstrated, used, and explored in a variety of settings ; XForms specification has proved useful in dynamic query development and enabling exploration of data for those with no knowledge of the structure of the data to be queried (36). Researchers have described successful implementations of XForms processors across diverse environments using different layout models (37) and in support of dynamic and adaptable document types (38). Other work has explored the use of XForms with web services (39), for enhancing accessibility of web interfaces (40), and for linking data models to commonly used forms in the insurance industry (41).

XForms is still an under utilized specification with an uncertain future and has been slow to gain acceptance within the healthcare industry. However, some early adopters in public health and provider settings have realized the advantages of using XForms to standardize the presentation of, and data collected by, web forms. In Germany, developers successfully implemented an information system to manage details of a prescription drug formulary using XML and XForms (42). Researchers in Australia used XForms for decision support system development (43) and scientists in South Korea proposed a radiology information system using XForms for a report management module (44).

XForms has also been used in clinical and public health systems. One example is its successful implementation within Open MRS, an open source Medical Record System, as an alternative to Microsoft’s Info Path web forms solution (45).XForms has also been considered for use in public health surveillance. A group from the CDC proposed use of XForms as a part of the framework for public health form creation and management (46).

Although the technologies in use today range from primitive to sophisticated, it is clear that improved efficiency, timeliness, and completeness could be gained by improving connections between public health and provider systems. We saw a potential match between XForms’ capabilities and the need to facilitate bi-directional electronic communication between public health and provider systems. In this paper we present our experience using the XForms standard in the public health context for provider-initiated notifiable condition reporting and patient-specific public health alerting.

METHODS/EXPERIENCE

Beginning in 2005, we participated in a series of large national development and demonstration projects as a part of the Integrating the Healthcare Enterprise’s Connectathon and Interoperability Showcase. We played several parts in the demonstrations, including roles that required the use Interoperability Profiles such as Retrieve Forms for Data Capture (RFD) and use of the XForms standard for notifiable condition reporting and patient-specific public health alerting. Below we describe our experiences in bi-directional communication demonstrations at two large health informatics conferences.

Integrating the Healthcare Enterprise

Integrating the Healthcare Enterprise (IHE)was formed in 1998 by a group of healthcare and industry professionals with the goal of improving interoperability in healthcare information systems (7).The organization encourages the adoption of standards by developing, promoting and demonstrating Interoperability Profiles which are implementation guides for incorporating standards and that describe the business rules, specific transactions and standards which can be used in a structured way to address specific clinical and population health use cases. In the public health domain, the standards are typically those identified by the Health Information Technology Standards Panel (HITSP) (6). Annually, vendors and other participants gather to test interoperability and implementation of profiles during the IHE Connectathon; this testing is followed by the Interoperability Showcase which takes place at the Healthcare Information Management Systems Society annual conference and demonstrates the implementation of standards and IHE Profiles. In addition, the CDC’s Public Health Information Network conference has also hosted a smaller-scale, public health focused showcase. The demonstrations use scenarios to tell a story, usually about a patient’s experience in the healthcare system.

We participated in several population health scenarios and implemented interoperability profiles, including those to support notifiable condition reporting and patient-specific public health alerting (47).

Retrieve Forms for Data Capture and XForms for Public Health

The primary profile we used for the demonstration of the reporting and alerting public health use cases was RFD, which uses XForms and enables viewing, pre-population, completion, and submission of forms and form data. The RFD profile specifies how different roles will function during the transaction: forms manager; forms filler; forms receiver; and forms archiver. These roles can be filled by any organization but are fundamentally descriptions of computer systems that are equipped to satisfy the needs of each role. The general exchange of data that takes place in an RFD transaction can be broken down into three steps as illustrated in Figure 1: retrieve form request; form delivery; and submission of a completed form to the forms receiver and the forms archiver.

Figure 1

Roles and steps for Retrieve Forms for Data Capture transactions

To further illustrate the details of how XForms functions within the RFD transaction, we describe our role in two public health use cases: notifiable condition reporting and patient-specific public health alerting.

Notifiable Condition Reporting

In the notifiable condition reporting scenario we used RFD and XForms to enable the capture of provider initiated notifiable condition case-report data from within an EHR. In this scenario, a patient has tested positive for Salmonella, a notifiable condition. The scenario includes several steps:

The patient’s medical record on the local EHR system is open while the HCP is explaining the test results to the patient. 2) Knowing Salmonella is a notifiable condition, the HCP clicks a “retrieve case-report form” button within the EHR. 3) The EHR system (form filler) sends a message to a local public health system (form manager) requesting a Salmonella case-report form. The form request includes a structured document called a CCD (Continuity of Care Document). 4) The form manager finds the requested form and pre-populates it with data from the CCD. Most of the patient demographic information is pre-populated on the Salmonella case-report form (Figure 2), but some fields about exposure are left blank because they were not included in the CCD. 5) The pre-populated form is returned to the provider, who is able to view the form, complete the empty fields, and click “submit.” 6) The form is submitted as an XML document to public health, the form receiver, and to a backup location, the form archiver.

Figure 2

Salmonella case-report form using XForms

This part of the case reporting scenario demonstrates public health as a form manager, i.e., serving as a repository of available case-report forms, as well as a form receiver, i.e., accepting completed case-report forms from providers. In this demonstration, public health used a case-report management system to import, access, and edit the submitted XML instance data.

Patient-Specific Public Health Alerting

We also used the RFD profile for a demonstration of patient-specific public health alerting. In this scenario, a patient visits her HCP complaining of diarrhea, vomiting, fever, and headache. The scenario includes several steps:

After examining the patient, the HCP enters the patient's data into the electronic patient record. Because the symptoms sound like a possible food borne pathogen, the provider clicks a button within the patient record to “check for public health alerts.” 2) This mouse-click initiates a retrieve form request to a public health system serving as the form manager. As in the first scenario, a CCD is attached to the request, providing some of the patient’s basic demographic and symptom information. The public health system accepts the request for a form and examines several fields within the CCD: patient age, patient zip code, and conditions and dates from the problems section. Using this information, public health’s form manager determines the appropriate form to return to the provider. In this case, based on the zip code and symptoms, the “Salmonella Outbreak Alert” form is delivered because public health officials have been made aware of an ongoing outbreak of Salmonella in the area. 3) This form appears within the EHR and provides all relevant details about the current outbreak with recommendations for laboratory testing and treatment as well as contact information for the local public health department. (Note that if no matching alerts were found, an unobtrusive “no current alerts” message would have been sent).

Combining notifiable condition reporting and patient-specific public health alerts

Because the alert “form” is not asking for any input, the alerting scenario could end after the HCP views and acknowledges the context-specific alert. In the case of an infectious disease outbreak when the disease is also a notifiable condition, public health may want to not only provide alert information, but also collect case information from the provider. To demonstrate this, we included a button on the alert form to “retrieve a case-report form”. Clicking this button initiated another “retrieve form request” to public health, this time for a specific form, the Salmonella case-report form. Again, the CCD data were used to pre-populate the case-report form and the provider needed only to complete the empty fields and click “submit,” sending the instance data as an XML file back to public health.

RESULTS

Through this work we have demonstrated that notifiable condition reporting and patient-specific public health alerting can be accomplished with a set of technical profiles that use nationally identified standards. The flexibility of the RFD profile was essential in implementing these two use cases. We found that the versatility of both RFD and XForms were beneficial, but significant challenges arose with use of XForms technology in RFD.

Retrieve Forms for Data Capture

The RFD interoperability profile provides a method for collecting data from within one system while meeting the requirements of an external system and enables interoperability with other systems that have implemented RFD. We provided the URL of our form manager to participating vendors and this URL served as the endpoint for the vendor form requests.

Although CCD is an optional component of RFD, the ability of the form manager to use the CCD was an important part of the success of these demonstrations. Including CCD data in the form request allows for both the pre-population of case-report forms and tailoring public health alerts to a particular patient. Most EHR vendors participating in these demonstrations have the ability to create CDA documents, including CCDs, but without this capability, much of the benefit of using RFD is lost.

At the time of this publication, XForms are specified within the RFD profile. XForms were included in this profile because of their ability to negotiate issues such as partial completion of forms, series of forms, and forms filled out across different user sessions. We benefited from the ability of XForms to support series of forms when we combined the alerting and case reporting use cases. We also found some of XForms’ fundamental traits to be useful in our implementation.

For our project the most important feature of XForms was the use of XML to define form data. The use of XML documents to not only build a form, but also to store and transport form instance data, combined with the near universality of XML, made this one of the key benefits to using XForms. Another major benefit is the ease of use of advanced controls available in XForms. One control available in XForms is the range-selection control, adding a volume-control like slider to a form for ease of user data input. Range selection only recently became available for HTML forms. The reduction in the need for scripting to add logic to form controls also reduced development time for some components of the work, but the barriers we encountered were significant as was the time spent on XForms-related problems.

Challenges of XForms Implementation

We experienced significant challenges related to the development and implementation of XForms. First, two of the most common browsers, Internet Explorer and Mozilla Firefox, do not include native support for XForms. They require plug-ins in order to display the forms, and, when the same form is displayed in different browsers, different issues arise. In some cases, an XForms document displays properly in one browser but is not recognized as a form in the other enabled browser. This issue necessitates scripting within the forms to identify the browser and specify conditional code. Although it was not an issue for this demonstration, form developers need to be mindful of the complexities of plug-in installation when browsers are used by forms fillers. Second, although several XForms editors were tested, none provided adequate support and hand-coding was necessary for all of our form development. Without the help of an editor, and with little online support, the coding of forms was significantly more time-consuming than developing HTML forms. Third, though XML is ubiquitous in computing today, XForms is not and vendors are often unwilling to integrate support for XForms. This limited the number of partners for our demonstration, and could have more significant implications for use in practice.

Overall, our demonstrations were successful. The RFD profile, including the XForms standard, was implemented by our team and by participating vendors. Use of XForms had benefits, including its use of XML, availability of advanced form controls and reduction in necessary scripting for form behavior. However, our experience developing and using XForms, and the challenges we encountered, such as compatibility issues and time-consuming development, indicate that this technology may not yet be mature enough for widespread use for public health form development.

DISCUSSION

We have identified and demonstrated technology that enables two public health functions, case-reporting and patient-specific public health alerting, where communication between public health and provider is essential. Using electronic information exchange from provider to public health for case-reporting, and from public health to provider for alerting, the RFD profile and the XForms standard were sufficient to meet the simplified set of user needs represented in our demonstration scenarios.

The use of RFD and XForms not only helped integrate case-reporting into the provider’s workflow, but it also leveraged a standard XML representation of patient data to initialize the case-report form, thus demonstrating the potential to reduce the burden of reporting for the provider. The use of this technology also has the potential to positively influence timeliness and completeness of reported data. Implementations in practice settings are called for in order to quantify these effects. Implementing a system such as this for case-reporting would be a significant change to the way many providers currently go about notifiable condition reporting activities. If EHR-integrated, provider-initiated case-reporting is to be successful, provider and public health practitioner workflow should be further studied, and used to inform system design.

Our demonstration of patient-specific public health alerting is, in practice, more similar to the way clinical decision support is currently implemented than the way most public health alerts are distributed. Today, public health alerting is rarely context or patient-specific; the alerts we demonstrated represent a significant change to current practice. Before patient-specific public health alerts are implemented in the field, it will be important to assess the information needs, preferences, resources and capacity of both public health and provider organizations.

Both of our scenarios used provider initiated events, i.e., public health’s action was triggered by an event within the provider’s system, in both cases a mouse-click. This trigger could be any type of event; instead of the provider asking for the case-repot form, the form’s appearance might be triggered by code running in the background to check patient characteristics. Similarly, instead of the provider asking if there are any relevant public health alerts, these alerts could appear before a patient’s record is closed or after a problem list is updated.

Though the ideal format for this type of information exchange has not yet been established, enabling bi-directional information flow between providers and public health is becoming increasingly important. Interoperability between provider systems and public health systems is emphasized in parts of the US Health Information Technology for Economic and Clinical Health Act of 2009. Under this act, Medicare and Medicaid will provide financial incentives for the “meaningful use” of EHRs. Published rules indicate that communication of public health information from providers to public health, as well as patient-specific decision support services will be among the criteria used to certify and assess EHR systems (48).

Standards are one important part of achieving interoperable public health and clinical systems. Determining which of the existing standards will be adopted is a challenging task. By participating in IHE’s Interoperability Showcase we’ve engaged with one of the largest groups of vendors actively testing and demonstrating specific use cases and standards. We believe that our participation has helped encourage a more prominent role for public health in the scenario development process, and has increased our awareness of some of the benefits and drawbacks of use of RFD and XForms.

XForms technology is still immature and its trajectory is uncertain. Recently, the development of HTML5 has led to questions about the future of web forms. Though HTML5, the most recent update to HTML, offers simpler support for more complex multimedia elements, it’s most important overlap with XForms is in the area of more advanced validation and controls. HTML5 does not replace XForms, in fact some XForms implementations use HTML and will be able to take advantage of some of the new HTML5 features.

We believe that as XForms or a similar standard is used and tested, as support becomes more widely available, and as we gain a better understanding of provider and public health preferences related to these functions, it is likely that tools using forms standards to facilitate bi-directional communication between EHR systems and public health information systems will become more practical.

LIMITATIONS

Our findings are limited in several ways. First, the environment in which we implemented XForms was unique in that the collaborating EHR vendors are, as evidenced by their participation in the Interoperability Showcase, early-adopters, and therefore this sample may not be representative of all vendors. Future work should engage with vendors who do not participate in the Interoperability Showcase or similar venues.

Despite engaging with the public health practice community regarding the impact of implementation of XForms on work practice, we may have encountered different challenges if this technology was implemented in a state or local health department. Future work needs to explore the barriers and facilitators to XForms implementation and the impact of this technology on current HCP and public health practices. It is well-known that health departments across the US have heterogeneous work practices, thus potentially limiting the generalizability of our conclusions.

Because this work took place as part of a demonstration project, we were not able to fully explore user information needs related to bi-directional communication, workflow in the HCP office and public health departments, or the suitability of the technology for other use cases, for instance other notifiable conditions. We suggest that future work regarding XForms and other data capture technology for public health reporting and alerting continue to explore the use of standards and nationally recognized profiles, but also explores the information needs and workflow of the users in public health practice and the healthcare providers targeted.

Lastly, our report is limited by the fast pace of technology development and adoption. New tools, e.g., HTML5, became available after our initial demonstration. A side-by-side comparison of XForms and some of the newer tools would be a useful artifact. and a comparison between these tools and the XForms technology described here would have been useful.

CONCLUSION

Although XForms present significant development and implementation challenges, we believe the benefits of using a standardized method for representing form content, presentation, and logic is an important step for public health. We suggest that health departments with some system development capacity consider exploring the use of XForms or similar technologies to use and re-use XML documents for notifiable condition reporting and patient-specific public health alerting. Early projects making use of XForms should, if possible, measure the impact of the technology on timeliness and completeness of reporting and on effectiveness of context-specific alerting. Most resource-constrained organizations will benefit from continued migration of data toward an XML model. However, we suggest these organizations wait to implement XForms until the technology is more mature, tools for development have been proven, and the capacity within local EHRs has reached a level that will make the investment worthwhile.