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 OrdersCDA R1 - Clinical DocumentsCCD 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|||201105181535||RDE^O01|20110518153507018|P|2.2

PID|||87654321^^^^MPIID||PATIENT^OUR^TEST||1955-11-26.00:00:00|M||W|200 First St.^^Anytown^MN^55905|||||||

PV1||E|DSCH^DSCH|2||4321|6789^Doctor^Best^D.|8888^PHYSICIAN^NOT^CHOSEN|^^^~^^^~^^^~^^^|ERS||||1|3|N|6789^Doctor^Best^D.|I|87654321|FRANKLIN BLUE CROSS||||||||||||||||3|||AV|||||201105032316|201105081600 |||||||5432^DOCTOR^NEXT^J

ORC|XO|5|||CURRENT||||201105181535|EHRX-987654321|987654321 |6789^Doctor^Best^D.^|MS~$V752

RXE|^BID &0800,1730^^201105181730|070008003001^METFORMIN(GLUCOPHAGE), TABLET (1000 MG)|1000||MG|TABLET||||0||||987654321|||||||||||||^HOLD X 48 HOURS AFTER CT 3/18

RXR|ORAL

ZHX||||||||||||||||||O|201105181530

ZRX|||0|||||0

Z- Segments are site-specific.

Sample

Segments in SampleCode Segment Name Purpose

MSH Message Header Segment Identifies the intent, source, destination...

PID Patient Identification Segment

Patient identifying and demographic info.

PV1 Patient Visit Segment Used for account or visit specific info.

ORC Common Order Segment Used for common order field exchanges.

RXE Pharmacy / Treatment Encoded Order Segment

Details the pharmacy or treatment orders, it also contains several related status fields.

RXR Pharmacy / 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.