Reporting Patient Safety Events


Published on

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Reporting Patient Safety Events

  1. 1. Reporting Patient Safety Events By: Adrian Blakey adrianblakey@gmail.comFriday, August 31, 12 1These slides present a solution to the Reporting Patient Safety Events HC 2.0Challenge. They are a high level description of the solution to the challenge that wasimplemented using a combination of Open Source software products that comprises:java, Tomcat, Infogrid, MySQL and jQuery.
  2. 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 2The application was implemented by extending and implementing components of theInfogrid (IG) framework. More can be learnt about it here: http://infogrid.orgIG has several features powerful features that make it easy to integrate with an EHR (orindeed any type of reference data source), share it with multiple users, store datapersistently, render it graphically, and support workflow.Other datasources can be integrated into the database by IG’s capability to poll or listen forexternal changes and then cache them in a similar representation to the stored objects. Anyobject in the MeshBase can be related to other objects by typing and relating them togetheraccording to the rules applied through the schema.A simple relationship was modeled in the demo schema between an Incident form’s patientand an EHR patient.
  3. 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 3IG has a very powerful modeling capability. Models are divided into subject areas, whichcontain entity types. Entity types may have property types which are single valued andstrongly typed using several primitive datatypes. EntityTypes are related by bi-directionalrelationships through RelationshipTypes.The solution comprises two subject area models - one for the PSO forms and the other for thesimulated EHR.The PSO forms model contains several EntityTypes and RelationshipTypes. The model closelyresembles the AHRQ published logical information model, and is richer by having IG modelingconstructs such as enumerated datatypes, and bi-directional relationships types with explicitcardinality.The EHR was modeled by creating a subject area that contains only a single patient entity typeto represent a patient stored in an EHR.The models are described to IG by encoding them into a specific XML that IG understands asits schema definition. This XML is passed through a schema generator and declared to theapplication.
  4. 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 4A patient EHR was simulated in the demonstration by mocking a connection to an EHRsystem. The solution implements an integration between an Incident form patient, and acorresponding EHR patient.In the incident form, selecting a patient mrn causes a RESTful ajax call to be made from thebrowser to IG. This in turn causes IG to invoke a “probe” which simulates a call to an EHR tofetch the patient record. This is cached in the IG MeshBase as an IG MeshObject. The data isrepresented 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 newlycreated form patient in the MeshBase.IG integrates with any data source through its probe framework. It’s the developer’sresponsibility to implement an IG probe (java class) to read from the EHR data source inwhatever way the EHR presents itself. This could range from reading from the EHR’sdatabase, 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 werestored locally in the IG MeshBase (database). Probes can be instructed to poll periodically torefresh the local copy, or wait for an event from the source system.Being RESTful, every object in IG, including those read from other datasources areaddressable as unique URL’s which can be rendered in different forms, such as json, html,XML etc.
  5. 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 5IG renders objects through a java abstraction called a viewlet. IG has several viewletimplementations 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 JavaScriptto manage the detailed display, form context, and transitions. The jQuery js library was usedto make coding the forms simpler and allow them to be themed and changed by anyoneadopting 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 tospecification. The component could easily be made to submit forms directly to a PSO.