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

2. 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

3. 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

4. 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

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

6. 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.

7. 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^C HOSEN|^^^~^^^~^^^~^^^|ERS||||1|3|N|6789^Doctor^Best^D.|I|87654321|FRAN KLIN 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

8. 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

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

10. 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.

11. 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.

12. CCD Document – Medication Entry Template IDs specifying constraints

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

14. 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.

15. 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

16. 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

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

18. 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)

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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, …)

25. 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

26. 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

27. 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

28. 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.

29. 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.

30. 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

31. 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

32. 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.