HCLS/OntologyTaskForce/BIONTDSEDCM/EMRwrapper

EMR Wrapper

Picture a freely downloadable SPARQL interface [see footnote], which can be independently customized to any EMR system. In each version, however, a collection of query forms will retain their shared original names and annotation, which express a standard domain-level "patient" model.

Wrapping each query in a JSP would let each of several remote protocol-matching services interoperate concurrently with all the EMR systems so wrapped. Each caller could then evaluate (among other things) all of the predicates it needs to do its "matching" job.

With proper social engineering and support, this kind of API should grow at each EMR system into a model for interoperability that works in COI's main use case, in related COI use cases, and perhaps generally for many EMR-reuse applications.

• A) ASSUMED MECHANICS

The wrapper is one client endpoint in a distributed suite of tools extending each caregiver's EMR system. It helps to meet the system deployment requirements 4 and 6-8, and it clearly should handle specific matching requirements [details TBDL]. Privacy issues can be met by using anonymized patient IDs, and security issues can be met by taking requests only from pre-registered users and IP addresses. The requests to the wrapper include:

1. Track EMR Changes - For each EMR "recently" changed, list in the return a patient ID and a brief summary of the changes, phrased in standard clinical narratives and/or codes. The time range for "recently" can be a parameter, defaulting per each caller's usage history. (This usage lets a search engine index patient treatment summaries, and produce alerts when new matches occur)
2. Run EMR Predicates - For each line in a posted file holding [patient ID + predicate] pairs, the ASK forms in the API compute and return a corresponding line with a boolean value or error code. The predicates may include arguments. (This usage lets potential matches be inspected and validated in more detail).
3. Process "mapping-support" requests - Local staff may review and expand the set of predicate names and descriptions in local use, and adjust the related ASK-form mapping functions which translate predicates into equivalent queries of the EMR system. (These requests let the system "get smarter" as new protocols of interest pop up, and pushes the "mapping" work at each client onto those best qualified to do it.)

B.  DETAILS OF THE MAPPING PROCESS

The wrapper gets called only from a browser-based UI. It depicts each predicate as a web-form, which a user may fill and post to add the related predicate to a "target" model developing for one clinical trial. The mapping process has these distinct aspects:

1. The identity of each predicate reflects patient requirements from related protocols. Standards for protocols may help us choose a set, and domain models of patients also. But absent mass standard adoptions soon, the predicates locally USED depend only on local needs.
2. The execution of each USED predicate maps it into the local EMR data. This requires arguments to the predicate for EACH target model. They can probably just be copied right out of the protocol document, then submitted. The combo may later run many times in the wrapper
3. The ASK-form logic of each predicate is not actually needed until it is USED locally for the first time. Adding it will require special help and training about installing and fitting SPARQL tolocal EMR system APIs (all in IT?) plus talent in EMR query-writing.

Support needed for the last step is probably the most complex, as it involves a combination of skills. It seems doable, but in practice it may take a fair bit of documentation, training, support tools, and social engineering. They all get much easier if initial goals stay modest - few predicates, easy to understand. Pilot sites should focus only on "low hanging fruit" until a base of experience and users builds up to help.

C.  SPECIFIC WRAPPER BENEFITS

1. This API evaluates complex predicates for a standard "patient" model using local EMR queries. The patient model is deliberately kept general enough to work well as a ontological bridge. It uses only widely accepted medical terminology and codes to summarize each patient. It lets boolean predicates be locally probed on simple quantitative properties of a patient
2. The API helps find local candidates for virtually any protocol of local interest - it is useful! It is easy to grasp, use, install, and customize, so service utility outweighs its local costs. That vital inequality, plus word of mouth (and email), may cause its widespread adoption. That shows off SPARQL, and exposes many EMR systems under a shared domain model
3. As local users adopt it, they will also enhance it, web-2.0 style, with improved predicate libraries. User motives may be selfish - they want to weed out mis-matches - but they do work. Users can select locally customized predicates from a list, which then become web forms. New predicates can be pulled from higher levels, which can grow in response to demand.

[footnote on SPARQL and JSPs: an EMR system need not actually install a SPARQL interface to write the JSP wrappers, and the JSPs could in reality be any dynamic pages. SPARQL is a useful language in which to document wrappers, however, and in practice, JSPs might be a good choice for wrapper downloads.]