Reporting Patient Safety Events By: Adrian Blakey email@example.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.
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 workﬂow 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 workﬂow.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.
Representation & Modeling • The published logical data model was represented in Infogrid by encoding a forms model into IG’s schema deﬁnition 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 speciﬁc XML that IG understands asits schema deﬁnition. This XML is passed through a schema generator and declared to theapplication.
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.