Pan-SHARPS: MEDICATION LIST RECONCILIATION-SECURE MANAGEMENT

Lead Institution: University of Illinois at Urbana-Champaign

Project Leader: Carl Gunter and Bernard A’cs

Research Progress

  • Abstract
    In a 2011 ONC meeting of the SHARP teams, a decision was made to explore a demonstration based on Medication Reconciliation (MR) that would showcase the diverse capabilities from SHARP. This was called the Pan-SHARP project. SHARPS participated in this by exploring security and privacy issues for a centralized repository design for MR that could interoperate with the MR aspects developed by the other SHARP teams.

  • Focus of the research/Market need for this project
    MR is a complex process that impacts all patients as they move through all health care settings. Medication lists and records maybe constantly updated by a variety of members of a clinical care team. To have confidence making clinical decisions based on the data in the record, it is important to understand where that data came from. We call metadata that describes the origin of data, i.e. where the data came from, “provenance” as well as supplemental information describing artifact handling-events throughout the lifecycle of the artifact. To carry the appropriate information for reliable provenance, a number of questions must be addressed: What should be captured in metadata? Which ontological vocabulary or schema need to be supported? What form of serialization need to be supported: XML, JSON, or some other? What should the longevity of metadata records be? Who needs to query metadata, and how? Where and how will artifacts be stored and remain accessible to the population that should be able access them?

  • Project Aims/Goals (SHARPS)
    The process of MR poses specific provenance handling challenges. Each MR record event has “source” artifacts (i.e. the medication lists to be reconciled) and a “target” artifact, the resulting reconciled medication list. The source artifacts are retrieved from storage, queried from database systems, or handled, in general prior to an interactive MR session. The target artifact is likewise handled at the end. To supply the necessary provenance information related to all relevant clinical artifacts, we distinguished between two kinds of provenance, which we call “mechanical” and “clinical” provenance:

    • Mechanical provenance: This is analogous to an audit trail: which system performed what operation, when, with whose user ID, on what computer, etc.
    • Clinical provenance: This encapsulates is the “clinical source” of the data. For example, medication list A comes from pharmacy fulfillment data, while medication list B is self-reported.

    SHARPS created an operational model that tracks mechanical provenance to enable revision histories, provides digital signature for artifacts, and provides basic packaging methodology that enables encrypted artifacts to be transported over public networks. The mechanical provenance and clinical provenance are transported within the secured artifact component of the packaging. However, the system only updates mechanical provenance automatically and leaves handling of clinical provenance to the components that handle clinical data (i.e. the EHR, or in our case the SMARTn data). This model was created as a collection of related web-service endpoints and a predefined set of advertised end-points exposed as an Applications Programmatic Interface (API). These were used to implement a stand-alone central service manifestation to act as an artifact broker and persistent storage service. This approach provides the opportunity and serves as an example for implementers to leverage the API.

  • Key Conclusions/Significant Findings/Milestones reached/Deliverables
    The SHARPS Pan-SHARP implementation demonstrated the feasibility of building a “centralized service” model with basic functional features provided through an API empowering developers to integrate the service features within the context of their own applications. The overall architecture is illustrated as follows.

    A key aim was to determine key aspects of the architecture that require security protections and to demonstrate the feasibility of implementing them with current tools and libraries. The system used the OpenSSL libraries to implement both transport security and security of the data at rest. The overall conclusion from the project was that the tools and technical capabilities are adequate from existing systems, but to make a scalable solution would require an additional level of standards work surrounding many key aspects of provenance.

  • Materials Available for Other Investigators/interested parties

    • PanSharp Medication Reconciliation contribution, the POC Broker service: secure document handling server. URL: http://sourceforge.net/projects/securefilestore/
    • Completes making programmatic resource available for others
    • Server-side document store (en/de-cryption and key management)
    • Document submission and retrieval functions
  • Market entry strategies
    The core interfaces provide an assembled exemplar of a basic document management service that demonstrates the use of both digital signatures and secure file-system storage supporting audit-style providence capture of mechanical handling of artifacts, origin of the source artifact, and versioning features for artifacts stored. The packaging and logical mechanics are constituted as a web service end-point(s) exposing network callable functions API. This approach, rudimentary in sophistication, directly focused on a narrow set of features that could be easily integrated and/or leveraged by other application implementations that desires use of the features it provides either as a programmatic library and/or a stand-alone server.

    There are a significant number of potential enhancements and improvements to define, design, and develop extensions to capture a more expressive vocabulary of metadata encompassing the spectrum of clinical providence. For example, consider the case where the functions provided by the under laying API where fitted such that an abstracted vocabulary of XML encoded fragments could be incorporated within artifact versioning package. XML phrases could be embedded to identify encounter categories, characteristics, or encounter types to be captured, persistently recorded, and useful as semi structured components of an artifact archive.