Document Standards Faced and Lessons Learned Calvin Beebe, Tom Oniki, Hongfang Liu, Kyle Marchant.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Helmut König, Siemens Medical Solutions
Archetypes in HL7 v2 Andrew McIntyre Medical-Objects HL7 International May 2009.
CDA for HAI Reporting January 2007 Update. Project Outline Deliverables –Sample instances BSI, SSI, Denominator for Procedure, Denominiator for ICU –Stylesheets.
Building FHIR Servers on Existing Applications
Health IT Workforce Curriculum Version 1.0 Fall Networking and Health Information Exchange Unit 4e Basic Health Data Standards Component 9/Unit.
C-CDA Constraints FACA - Strategy Discussion June 23, 2014 Mark Roche, MD.
Data Normalization Milestones. Data Normalization  Goals –To conduct the science for realizing semantic interoperability and integration of diverse data.
Mpeg-21 and Medical data A strategy for Tomorrow ’ s EMR.
S.R.F.E.R.S. State, Regional, and Federal Enterprise Retrieval System Inter-Agency & Inter-State Integration Using GJXML.
José Costa Teixeira January 2015 Medication Data Capture and Management.
LRI Validation Suite Meeting November 1st, Agenda Review of LIS Test Plan Template CLIA Testing EHR testing (Juror Document)—Inspection Testing.
Mint-user MINT Technical Overview October 8 th, 2010.
FHIRFarm – How to build a FHIR Server Farm (quickly)
Microsoft Office Word 2013 Expert Microsoft Office Word 2013 Expert Courseware # 3251 Lesson 4: Working with Forms.
Harmonization of SHARPn Clinical Element Models with CDISC SHARE Clinical Study Data Standards Guoqian Jiang, MD, PhD Mayo Clinic On behalf of CDISC CEMs.
FHIM Overview How the FHIM can organize other information modeling efforts.
The Final Standards Rule John D. Halamka MD. Categories of Standards Content Vocabulary Privacy/Security.
Objectives of the Lecture :
SHARPn Data Normalization November 18, Data-driven Healthcare Big Data Knowledge Research Practice Analytics Domain Pragmatics Experts.
1 SPL Technology Presentation The Technology of Structured Product Labeling Presented by Robert H. Wallace 06 June 2004.
Initial Prototype for Clinical Data Normalization and High Throughput Phenotyping SHARPn F2F June 30,2011.
Aurora: A Conceptual Model for Web-content Adaptation to Support the Universal Accessibility of Web-based Services Anita W. Huang, Neel Sundaresan Presented.
Using Styles and Style Sheets for Design
NHS CFH Approach to HL7 CDA Rik Smithies Chair HL7 UK NProgram Ltd.
Copyright © 2012 Accenture All Rights Reserved.Copyright © 2012 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are.
XP 1 CREATING AN XML DOCUMENT. XP 2 INTRODUCING XML XML stands for Extensible Markup Language. A markup language specifies the structure and content of.
Agenda Introduction to MDHT MDHT Capabilities MDHT support using Consolidated CDA 1.
How do professional record standards support timely communication and information flows for all participants in health and social care? 1 Gurminder Khamba.
December 15, 2011 Use of Semantic Adapter in caCIS Architecture.
HL7 HL7  Health Level Seven (HL7) is a non-profit organization involved in the development of international healthcare.
National Institute of Standards and Technology Technology Administration U.S. Department of Commerce 1 Patient Care Devices Domain Test Effort Integrating.
Standards Analysis Summary vMR – Pros Designed for computability Compact Wire Format Aligned with HeD Efforts – Cons Limited Vendor Adoption thus far Represents.
Development Process and Testing Tools for Content Standards OASIS Symposium: The Meaning of Interoperability May 9, 2006 Simon Frechette, NIST.
©2003 Paula Matuszek CSC 9010: Text Mining Applications Document Summarization Dr. Paula Matuszek (610)
Clinical Document Architecture. Outline History Introduction Levels Level One Structures.
2005 Epocrates, Inc. All rights reserved. Integrating XML with legacy relational data for publishing on handheld devices David A. Lee Senior member of.
Chapter 17 Creating a Database.
The european ITM Task Force data structure F. Imbeaux.
Architectural Patterns Support Lecture. Software Architecture l Architecture is OVERLOADED System architecture Application architecture l Architecture.
1 Incorporating Data Mining Applications into Clinical Guidelines Reza Sherafat Dr. Kamran Sartipi Department of Computing and Software McMaster University,
HealthBridge is one of the nation’s largest and most successful health information exchange organizations. An Overview of the IT Strategies for Transitions.
Keyword Searching Weighted Federated Search with Key Word in Context Date: 10/2/2008 Dan McCreary President Dan McCreary & Associates
Efficient RDF Storage and Retrieval in Jena2 Written by: Kevin Wilkinson, Craig Sayers, Harumi Kuno, Dave Reynolds Presented by: Umer Fareed 파리드.
MATT REID JULY 28, 2014 CCDA Usability and Interoperability.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
vMR – Virtual Medical Record
© 2013 The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 The Office Visit.
WSDL in a Healthcare Enterprise Architecture Lorraine Constable, Constable Consulting John Koisch, Guidewire Architecture Jean Henri Duteau, GPI.
Issues in Ontology-based Information integration By Zhan Cui, Dean Jones and Paul O’Brien.
LRI Validation Suite Meeting Prototype Tool Demonstration December 20th, 2011.
Commentary: The HL7 Reference Information Model as the Basis for Interoperability George W. Beeler, Jr. Ph.D. Co-Chair, HL7 Modeling & Methodology.
Data Interchange Standards in Healthcare Rev'd Sunday A. Folayan General Data Engineering Services, Ibadan, Nigeria
Part I: Introduction to SHARPn Normalization Hongfang Liu, PhD, Mayo Clinic Tom Oniki, PhD, Intermountain Healthcare.
Sally McCallum Library of Congress
Standards Analysis Summary vMR – Pros Designed for computability Compact Wire Format Aligned with HeD Efforts – Cons Limited Vendor Adoption thus far Represents.
SNOMED CT Vendor Introduction 27 th October :30 (CET) Implementation Special Interest Group Tom Seabury IHTSDO.
PIX/PDQ – Today and Tomorrow Vassil Peytchev Epic.
CDA Overview HL7 CDA IHE Meeting, February 5, 2002 Slides from Liora Alschuler, alschuler.spinosa Co-chair HL7.
CCD and CCR Executive Summary Jacob Reider, MD Medical Director, Allscripts.
Connecting to External Data. Financial data can be obtained from a number of different data sources.
Tung Tran, Ph.D. What is the EMR? Computerized legal medical record created by healthcare organizations Enables storage and retrieval of patient information.
Rendering XML Documents ©NIITeXtensible Markup Language/Lesson 5/Slide 1 of 46 Objectives In this session, you will learn to: * Define rendering * Identify.
C-CDA Scorecard Rubrics Review of CDA R2.0 Smart C-CDA Scorecard Rules C. Beebe.
Clinical Data Exchange using HL7 and Mirth Connect Lecture 14 - DICOM connectors - Encoding/decoding Base64 data - Message Attachments - System Events.
Networking and Health Information Exchange
Practical Office 2007 Chapter 10
Data Normalization Architecture
Managing Medical Records Lesson 1:
Presentation transcript:

Document Standards Faced and Lessons Learned Calvin Beebe, Tom Oniki, Hongfang Liu, Kyle Marchant

Data Normalization Process Adopt a hybrid agile process: combining both top-down and bottom-up approaches -Identify gaps through normalizing real EMR data -Modify components to close the gaps -Evaluate the CEM results -Iteratively improve

Overview  How the real EMR data looks like – by Calvin Beebe  Modeling - Lessons learned – by Tom Oniki  Process – Lessons learned – by Hongfang Liu  Database – Lessons learned – by Kyle Marchant

Overview  How the real EMR data looks like – by Calvin Beebe  Modeling - Lessons learned – by Tom Oniki  Process – Lessons learned – by Hongfang Liu  Database – Lessons learned – by Kyle Marchant

Source Inputs  HL7 V2.x - Pharmacy Orders  CDA R1 - Clinical Documents  CCD R1 - Continuity of Care Documents

HL7 2.x Encoding Rules  Message formats prescribed in the HL7 encoding rules consist of data fields that are of variable length and separated by a field separator character. –Rules describe how the various data types are encoded within a field and when an individual field may be repeated.  The data fields are combined into logical grouping called segments. –Each segment begins with a three-character literal value that identifies it within the message. –Segments may be defined as required or optional and may be permitted to repeat. –Individual data fields are found in the messages by their position within their associated segments.

HL7 2.x Pharmacy Encoded Order MSH|^~\&||116||| ||RDE^O01| |P|2.2 PID||| ^^^^MPIID||PATIENT^OUR^TEST|| :00:00|M||W|200 First St.^^Anytown^MN^55905||||||| PV1||E|DSCH^DSCH|2||4321|6789^Doctor^Best^D.|8888^PHYSICIAN^NOT^C HOSEN|^^^~^^^~^^^~^^^|ERS||||1|3|N|6789^Doctor^Best^D.|I| |FRAN KLIN BLUE CROSS||||||||||||||||3|||AV||||| | |||||||5432^DOCTOR^NEXT^J ORC|XO|5|||CURRENT|||| |EHRX | |6789^Doctor^Best^D.^|MS~$V752 RXE|^BID &0800,1730^^ | ^METFORMIN(GLUCOPHAGE), TABLET (1000 MG)|1000||MG|TABLET||||0|||| |||||||||||||^HOLD X 48 HOURS AFTER CT 3/18 RXR|ORAL ZHX||||||||||||||||||O| ZRX|||0|||||0 Z- Segments are site-specific. Sample

Segments in Sample CodeSegment NamePurpose MSHMessage Header SegmentIdentifies the intent, source, destination... PIDPatient Identification Segment Patient identifying and demographic info. PV1Patient Visit SegmentUsed for account or visit specific info. ORCCommon Order SegmentUsed for common order field exchanges. RXEPharmacy / Treatment Encoded Order Segment Details the pharmacy or treatment orders, it also contains several related status fields. RXRPharmacy / Treatment Route Segment Reference Chapters 2, 3 & 4 in the HL7 Version 2.x Standards

Patient Context in CDA Documents Both CDA R1 & R2 support patient identification within the header of the document.

CDA Narrative Documents CDA narrative documents, support structured headers, with section narrative content. –As can be seen below the Medications Section is based on a simple HTML like syntax.

CDA Narrative Content  Both CDA R1 & CDA R2 support and actually require narrative content.  Both support Section codes, which can be used to identify sections of interest.  CDA R1 only contain narrative, while CDA R2 Documents may contain clinical statements based upon RIM Classes.  For those documents with narrative sections, content normalization requires the used of Natural Language Processing.

CCD Document – Medication Entry Template IDs specifying constraints

CCD Document – Medication Entry Supply reference with quantity dispensed. continued

Summary  Various sources were utilized to obtain Medication information.  Legacy application still leverage HL7 2.x messages to convey order information between systems.  CDA narrative and structured documents are coming on-line which convey snapshots of patient’s current state and medications.

Overview  How the real EMR data looks like – by Calvin Beebe  Modeling - Lessons learned – by Tom Oniki  Process – Lessons learned – by Hongfang Liu  Database – Lessons learned – by Kyle Marchant

Lessons Learned - Modeling  Open tools would be a great contribution to the interoperability. Examples: –mapping terminology, e.g., local codes to LOINC/HL7/SNOMED –mapping models, e.g., HL7 messages/CDA documents to CEMs, CEMs to ADL, etc. –generating sample instances –communicating information  browsers  generating documentation

Lessons Learned - Modeling  Documentation is essential – we didn’t produce enough of it. But...

Lessons Learned - Modeling  Documentation is essential – we didn’t produce enough of it. But...  It’s hard to communicate (verbally or in written word) the intricacies and complexities needed to make an effort like this work (much less keep information up- to-date)

Lessons Learned - Modeling  “One model fits all” won’t work –Clinical Trials (e.g., CDISC CSHARE) vs Secondary Use (e.g., SHARPn) –Proprietary EMR (e.g., GE Qualibria) and Open Secondary Use (e.g., SHARPn) –value set differences

Lessons Learned - Modeling  The root of all modeling questions: Precoordination vs. postcoordination and what to store in the model instance vs. leave in the terminology –Clinical drug vs. drug name/form/strength/ route –LOINC code vs lab test/method –Display names –Drug classes

Overview  How the real EMR data looks like – by Calvin Beebe  Modeling - Lessons learned – by Tom Oniki  Process – Lessons learned – by Hongfang Liu  Database – Lessons learned – by Kyle Marchant

Lessons Learned - Process  The design of the pipeline needs to be flexible enough to accommodate all kinds of changes – (agile)  UIMA is a nice architecture – Configurable – Model-driven  e.g., taking an XSD specification of CEM and translating into UIMA types –Seamless integration with NLP pipeline

Lessons Learned - Process  Diverse input formats – Structured ­- semantics may be different from different institutions  Needs to understand the data – Unstructured - there is a gap between the semantics of free text and the semantics of standards  Semantics in free text may be at coarse granularity level or can be paraphrased into different expressions

Lessons Learned - Process  Different requirements for different use cases - All normalization tasks but the necessary fields can be different for different use cases –Medication Rec (ClinicalDrug - critical) –Phenotyping (Gender, Race, AdministrativeDiagnosis, Lab, …)

Lessons Learned - Process  Too many standards to choose when implementing HL7 standards –Mapping from local codes to standard value sets – non-trivial  Versioning of standards is crucial –Do not assume the mapping will be trivial if the EMR data has already adopted the same standard as SHARPN value sets

Lessons Learned - Process  Different granularities between CEMs and original structures –Dose Strength “50-mg” –NotedDrug CEM: Unit=MG Value=50  Inference –TakenDoseUpperLimit needs to be inferred from TakenDoseLowerLimit

Overview  How the real EMR data looks like – by Calvin Beebe  Modeling - Lessons learned – by Tom Oniki  Process – Lessons learned – by Hongfang Liu  Database – Lessons learned – by Kyle Marchant

Database – CEM to DB mapping  Relational structure for the Demographics data worked well – This provided a nice view into the patients data without having to have a lot of knowledge of the Patient CEM structure. –Allowed for both adds and updates –Was not intended to be a full MPI but does meet the minimal need of linking a given patients records for a given institution.

Database – CEM to DB mapping  XML Sample data for the Clinical CEMs –XML samples proved very valuable for validation against the XSD's and for providing an initial set of test messages to Channels. –The more complete these records were the more useful. –Assumed all mappings to code sets were done prior to receiving on the CEM to DB channel.

Database – CEM to DB mapping  Code re-use across the Clinical CEM Channels proved very useful –Standardized CEM DB Structure - IndexData, SourceData, and PatientData –Common patient “matching” code used –Currently only supports Add but Updates now possible due to SourceSystemID that was added recently

Database – CEM to DB mapping  Issues and Challenges –Date formatting was one example of needing to understand how the data was being received and used. –Field level storage VS storing of full XML - Tradeoff - Decided to always store full XML – May need to look at additional relational fields on clinical CEMs for better searching support

Database – CEM to DB mapping  A few Miscellaneous Items –Mirth support for XML, HL7, etc proved very useful for traversal of structures in code and for field validations. – Supporting Add and Updated for Patient (base) record was useful. –Always create the Patient base record first regardless if Patient or Clinical CEM was received as first CEM to the DB.