www.gdhealth.com Efficiently Sharing All of a Patient s Data With All their Providers Completing the Model Multi-Source Longitudinal Medical Record (MLMR) Thomas Pole and Robert Guajardo 6.13.2017
Our Goal We are not saying that the enhancements we present here are our invention Multiple vendors and adopters have worked on these same enhancements We are advocating extending the HIE model to include these enhancements Our goal is to help everyone, even those with little experience with HIE s to benefit from the Multi-Source Longitudinal Medical Record design pattern. 2 www.gdhealth.com
Agenda Defining the problem we are trying to solve Defining the longitudinal patient record Unmet needs of the existing ONC HIE model What are we doing to complete the model? How our model extends the ONC HIE model How do we solve the problem? What makes our model complete? The Multi-Source Medical Record Design Pattern A software/system design pattern that has three variations to: Make available all usable data from all available sources Establish platform/programming language neutral API s so data can be more easily shared Organize and format data to make it easier to find and use Completes the model that the HIE approach began 3 www.gdhealth.com
Longitudinal Patient Record Traditional patient record all the information available on a patient from the provider organization e.g. local office, clinic or hospital s HIT Longitudinal patient record all the information available on a patient from all sources, local or external e.g. local office, clinic or hospital as well as other providers that have served this patient 4 www.gdhealth.com
Existing ONC HIE Model Traditional HIE (ONC CONNECT model) Accomplishments Aggregating local EHRs data in an ONC style HIE Makes sharing of information possible Make all exported data searchable Unmet Needs Automated, hands off method for merging patient data from multiple healthcare IT sources (e.g., EHR and PACS), and making it available on the HIE A more intuitive and accurate method for finding complete specific patient histories on the HIE 5 www.gdhealth.com
Extending the ONC HIE Model Add a pre-step and a post-step to HIE model Pre-step: automate the merging of all available patient data Not just the CDA exports, unless you export everything to CDA Transport data across systems in a platform neutral format This is what ONC HIE already does well using SOAP & XML Post-step: intuitive accurate search and retrieval of patient data Not just searchable but findable the data New capabilities in viewing the data 6 www.gdhealth.com
How Do We Solve The Problem Complete Longitudinal Record Pre-step requires that there be an automated function that looks for new patient data, converts it to the ONC HIE model s platform independent format, and shares it via the HIE Post-step requires that the metadata in the registry have more than the currently required fields; date range on procedure, type of lab report, specific categories or medications, etc. Make HIE available content as complete and findable as EHR content 7 www.gdhealth.com
What Makes the MLMR Model Complete? Pre-Step Middle-Step Post-Step Automated generation of sharable content Automated submission of content to repository Automated submission of metadata to registry Distributed (current HIE model) or merged registry metadata (e.g. HAIMS) Distributed (current HIE model) or merged repository content (e.g. CDR) Enhanced registry indexing Improved user search and viewing Enhanced federated access 8 www.gdhealth.com
The MLMR Design Pattern Our MLMR design pattern is a tool to help networks of providers to build a system which creates a Complete Longitudinal Patient Record This pattern represents the common design features that any MLMR system requires This flexible pattern has three distinct model variations to tailor the pattern to different requirements at different networks of providers Small, medium or large networks Limited, modern or advanced IT infrastructure 9 www.gdhealth.com
Three Variants of the MLMR There are 3 variations of the MLMR, for each of which there are existing systems implemented Copy and merge variation Merged Registry, Merged Repository Example: The DHA CDR Gateway variation Distributed Registry, Distributed Repository ONC CONNECT other HIE products which follow the ONC model Hybrid variation Merged Registry, Distributed Repository BHIE v5 HAIMS 10 www.gdhealth.com
A Few Terms Defined Design Pattern A generic design of not a single system, but a family of similar systems; often a design with multiple variations to serve similar but different circumstances Registry An index of all the available health data, tagged and searchable by patient, provider, condition, dates etc. Repository A collection of medical record data, that includes encounter notes, prescriptions, medications, radiology images and lab results etc. Merged Registry and Repository model (Copy and Merge) Records from multiple sources are copied, merged, normalized and indexed in a new master repository and registry (e.g. Dept. of Veteran Affairs Blue Button model and CMS Blue Button on FHIR) Merged Registry and Distributed repositories (Hybrid) Records, documents, images etc. are left in their original source systems, but a master registry of all records in all source is produced (e.g. Department of Defense HAIMS model) Distributed Registries and Repositories (Gateway) Each data source retains full control of its data and registries but a central querying mechanism allows multiple source to be searched and accessed from a single connection point (ONC HIE Model) 11 www.gdhealth.com
MLMR Design Pattern Includes Three Primary Components Purpose of the Multi-Source Medical Record Design Pattern: To make health data more interoperable and to enable a patient to control and share their medical record to improve their quality of care. Federated HIE s are designed to make medical information from multiple sources available from one central access point. In reality pulling from multiple clinics, hospitals, practices, etc. but acting like all the data is in one convenient to access location. Data Access Component(s) one or more applications that can access the data from the system e.g. Patient Portal, Web Page or Mobile Application Data Aggregation Component a single data system which collects, aggregates, normalizes and makes data from multiple source systems available Data Source Component(s) one or more data systems, each usually supplying data from a single enterprise (e.g. hospital, lab or GP practice) which can be combined into each patients complete longitudinal record 12 www.gdhealth.com
Generic Design Pattern Creates data about care given Data Creator (e.g. Provider) Consumes data about care they've received Data Consumer (e.g. Patient) Consumes data about care previously given Creates data about care given Data Consumer and Creator (e.g. Provider) 13 www.gdhealth.com
Copy and Merge: Merged Registry, Merged Repository Variant of Design Pattern Data Creator (e.g. Provider) Creates data about care given Registry Repository Consumes data about care they've received upload Data Consumer (e.g. Patient) Merged Regstries Merged Repositories upload Consumes data about care previously given Creates data about care given Registry Data Consumer and Creator (e.g. Provider) Repository 14 www.gdhealth.com
Copy and Merge: Merged Registry, Merged Repository Advantages All data and metadata remains in the source systems All data and metadata to support data search and retrieval in one system. Easier maintenance Fast, predictable performance if size of data and metadata does not swamp available hardware and infrastructure Disadvantages All data must be stored twice, once in source system and once in aggregator component Higher cost Change control problems, if one copy changes, which copy is the right one? Updates must be sent regularly, and must be merged with existing data Between updates system does not reflect truth in real time Best Used For Relatively small collections where cost of hardware for duplicate storage is a minor cost, but cost of regular updates and merges are manageable 15 www.gdhealth.com
Gateway: Distributed Registry, Distributed Repository Variant of Design Pattern Creates data about care given Data Creator (e.g. Provider) Registry upload Repository Data Consumer (e.g. Patient) Consumes data about care they've received Multi-Registry Search Service search retrieve Multi-Repository Retrieval Service search Consumes data about care previously given retrieve upload Registry Data Consumer and Creator (e.g. Provider) Creates data about care given Repository 16 www.gdhealth.com
Gateway: Distributed Registry, Distributed Repository Advantages All data and metadata remains in the source systems Disadvantages Distributed searches takes significantly more time than a single search against a single registry When one system in the network is not available, it will not respond with its registry or repository contributions. Will give the impression that system is not predictable, giving different results at different times because of problems with connectivity or individual source systems Best Used For Relatively large collections where resources for building a sophisticated aggregator component are not available Usage scenarios where availability of data is not critical in terms of urgency, and predictable behavior 17 www.gdhealth.com
Hybrid: Merged Registry, Distributed Repository Variant of Design Pattern Data Creator (e.g. Provider) Creates data about care given Registry Repository Data Consumer (e.g. VA Benefit Clerk) Consumes data about care they've received Merged Regstries upload retrieve Multi-Repository Retrieval Service upload Consumes data about care previously given retrieve Creates data about care given Registry Data Consumer and Creator (e.g. Provider) Repository 18 www.gdhealth.com
Hybrid: Merged Registry, Distributed Repository Variant of Design Pattern Advantages All metadata to support data search and retrieval in one system. Easier maintenance Fast, predictable performance if size of metadata does not swamp infrastructure (which is likely as metadata is much smaller than data size) All data remains in source systems, no worries about duplicate data, data change management, etc. As they are smaller than content updates, updates to registry can be performed in real time, no need to wait for daily updates. Disadvantages All metadata (e.g. registry) must be stored twice, once in source system and once in aggregator component Higher cost, but not nearly as high as storing duplicate repository data When one source system is unavailable, you can identify available repository data, but not always access it. Registry updates must be sent regularly, and must be merged with existing registry meta data Best Used For Large collections with many source systems, and significant cross-referencing of one patient across multiple source systems 19 www.gdhealth.com