Slides which describe an java Web app. that implements a solution to the HC 2.0 Patient Safety Events Challenge.

1. Reporting Patient
Safety Events
By: Adrian Blakey
adrianblakey@gmail.com
Friday, August 31, 12 1
These slides present a solution to the Reporting Patient Safety Events HC 2.0
Challenge. They are a high level description of the solution to the challenge that was
implemented using a combination of Open Source software products that comprises:
java, Tomcat, Infogrid, MySQL and jQuery.

2. Features of the Solution
• Implements components of an open source, integrating, java,
graph database framework called Infogrid (IG), that
demonstrates a scalable solution for:
• Patient health record (EHR) integration.
• Data model representations of: all safety forms, and a
simulated EHR.
• Saving safety forms, and caching EHR patient records in
the IG MeshBase.
• Entering forms in a browser, and exporting the AHRQ
common formats XML for communication to a PSO.
• Constructing a workflow with callbacks and listeners.
Friday, August 31, 12 2
The application was implemented by extending and implementing components of the
Infogrid (IG) framework. More can be learnt about it here: http://infogrid.org
IG has several features powerful features that make it easy to integrate with an EHR (or
indeed any type of reference data source), share it with multiple users, store data
persistently, render it graphically, and support workflow.
Other datasources can be integrated into the database by IG’s capability to poll or listen for
external changes and then cache them in a similar representation to the stored objects. Any
object in the MeshBase can be related to other objects by typing and relating them together
according to the rules applied through the schema.
A simple relationship was modeled in the demo schema between an Incident form’s patient
and an EHR patient.

3. Representation & Modeling
• The published logical data model was represented in Infogrid
by encoding a forms model into IG’s schema definition XML
and using the IG schema generator.
• Enumerated datatypes allowed a direct expression of the
forms’ answers.
• A single form instance is an overlay of several “blessings” of
single types i.e. Header, InitialReport, SIR, Patient.
• One or zero, to many associations were represented with bi-
directional relationships. e.g. Form-has-Device, 0:2.
Friday, August 31, 12 3
IG has a very powerful modeling capability. Models are divided into subject areas, which
contain entity types. Entity types may have property types which are single valued and
strongly typed using several primitive datatypes. EntityTypes are related by bi-directional
relationships through RelationshipTypes.
The solution comprises two subject area models - one for the PSO forms and the other for the
simulated EHR.
The PSO forms model contains several EntityTypes and RelationshipTypes. The model closely
resembles the AHRQ published logical information model, and is richer by having IG modeling
constructs such as enumerated datatypes, and bi-directional relationships types with explicit
cardinality.
The EHR was modeled by creating a subject area that contains only a single patient entity type
to represent a patient stored in an EHR.
The models are described to IG by encoding them into a specific XML that IG understands as
its schema definition. This XML is passed through a schema generator and declared to the
application.

4. Patient EHR Integration
• An EHR was modeled by creating a subject area containing a
single patient demographics entity type.
• A bi-directional relationship was modeled between the Form
Patient and the EHR patient.
• Polling and fetching the EHR patient from its source system
was simulated by implementing an IG “Probe” component.
• Two integrations are implemented:
• A mashup - RESTful http GET of the EHR json representation, into
the UI.
• Database cache - of the saved EHR patient record related to the
Form patient by the model.
Friday, August 31, 12 4
A patient EHR was simulated in the demonstration by mocking a connection to an EHR
system. The solution implements an integration between an Incident form patient, and a
corresponding EHR patient.
In the incident form, selecting a patient mrn causes a RESTful ajax call to be made from the
browser to IG. This in turn causes IG to invoke a “probe” which simulates a call to an EHR to
fetch the patient record. This is cached in the IG MeshBase as an IG MeshObject. The data is
represented in the same way as if it were an object that was created locally in the MeshBase.
When the form is submitted it makes a relationship between this EHR patient and the newly
created form patient in the MeshBase.
IG integrates with any data source through its probe framework. It’s the developer’s
responsibility to implement an IG probe (java class) to read from the EHR data source in
whatever way the EHR presents itself. This could range from reading from the EHR’s
database, capturing its screen, connecting as an http client etc.
The integrated data is cached locally as objects by IG and presented to the user as if it were
stored locally in the IG MeshBase (database). Probes can be instructed to poll periodically to
refresh the local copy, or wait for an event from the source system.
Being RESTful, every object in IG, including those read from other datasources are
addressable as unique URL’s which can be rendered in different forms, such as json, html,
XML etc.

5. Visualization and Output
• The PSO forms are rendered from an IG viewlet jsp in a
browser window, as a single page of HTML5 & JavaScript,
using jQuery.
• Responsive design separates form style from semantics to
permit customization, and re-platforming to mobile.
• The forms behave contextually, disclosing elements in
response to different input and guide the user.
• The AHRQ Common Formats XML is an alternative RESTful
rendering, of the forms library.
• The XML renderer is data-driven from MySQL tables of form
elements, loaded from the supplied spreadsheets.
Friday, August 31, 12 5
IG renders objects through a java abstraction called a viewlet. IG has several viewlet
implementations and ways to render them with a rich set of jsp tags.
A jsp viewlet was written to render all the forms in a single html page that contains JavaScript
to manage the detailed display, form context, and transitions. The jQuery js library was used
to make coding the forms simpler and allow them to be themed and changed by anyone
adopting the application for use in their own organization.
The CDA-compliant XML rendering of the entered forms was also implemented as a viewlet.
This viewlet calls into a java component to read forms from IG and format them according to
specification. The component could easily be made to submit forms directly to a PSO.