1. GELLO Andrew McIntyre Medical-Objectswww.medical-objects.com.au HL7 Meeting, Atlanta, September 2007

2. Background Joint project Between Medical-Objects Haematology Society Leukaemia Foundation of Australia Supported by Australian Gov. ITOL grant Existing Guidelines in Printed format Tend to sit on shelf – thick book Hard to update Lymphoma registry was long term aim GELLO/GLIF based prototype developed

3. Why GELLO? Curly Braces vs vEMR Abstract data access n-tier implementation – have native access to HL7 data model and not directly to database Can implement data access directly on HL7 or via SQL Observation data abstracted, abstracts Term-info issues Object Oriented Powerful logic, iterators and terminology abstractions Functional Language

4. From Concept to Compilation

5. GELLO Implementation details The GELLO as implemented by MO-GELLO has been developed as an embedded component within a GLIF, Archetypes and HL7 framework. It was developed using a LALR(1) parser framework in conjunction with a Delphi Object Pascal HL7 framework. It is interpretive in nature. Gello expressions are compiled at run time and stored as an internal object oriented expression tree. Execution speed is facilitated by the use of object oriented techniques. There is no “byte code” to execute, all calls are made natively to the HL7 framework. GELLO expressions can be implemented using an embedded IDE called “Mowgli”. Library facilities have been developed whereby frequently used GELLO expressions can be run indirectly from within another GELLO expression Queries executed on client against native HL7 data without use of SQL Applications and GELLO environments mentioned are available for free download from Medical-Objects website

6. High Level Observations GELLO BNF errors No formal definition of vEMR Inferred by V3 model and examples Need for presentation logic GLIF Chosen - GELLO interface needed Guideline required data structures to be persisted CEN 13606 Archetypes used All data was in V2 format Abstraction layer used to represent V3 model in v-EMR SNOMED-CT interaction very useful

7. GELLO Definition BNF is a strict language definition! For interoperability must be 100% correct GELLO based on OCL – OCL grammar has issues Requires operator precedence to parse GELLO extends and deviates from OCL already Opportunity to create non-ambiguous grammar GELLO is likely to require libraries of common code GELLO needs to accept Parameters from eg: GLIF GELLO needs to be clinician user friendly

8. BNF Suggestions Completed definitions Collection literal CollectionLiteral::= CollectionType "{" ( CollectionLiteralElement ( "," CollectionLiteralElement )* )? "}" Tuple literal... Collection Type... Tuple Type... Enumeration Type... Add Implies to grammar (missing) ‏ ConditionalExpression::= OrExpression ( OrExpression)*

9. BNF Suggestions Allow Expressions for function arguments eg: FirstN() "(" Expression ")" vs "(" ")" "(" Expression ")" vs "(" ")" Also LastN(), Intersection(), Union(), SubString(), GetElemName(), GetElemType() Allows these values to be calculated at run time rather than hard coded in source

10. Statement Lists Current grammar only allows single expression in Statement Ideally should allow LET statements to improve readability (vs very complex expression) Multiple statements cause issues Places where one construct next to another resulted in an ambiguity i.e. when an “Expression” appeared next to another “Expression”. These two examples are identical syntactically but have different meaning Example 1. Let A: Integer = C + D (A * 20) ‏ Example 2. Let A: Integer = C + D(A *20) ‏

11. Statement List Solutions Only Allow a subset of Statements to appear in List Interim solution - does not start with “+, “-”, “(“ Add OCL “IN” operator Produces difficult to read code with multiple LET Statements as have to nest with multiple “IN”s Use specific statement separator eg: “;” Let A: Integer = C + D; (A * 20) ‏ This was in earlier versions of the grammar and is our favoured solution

12. BNF Suggestions Library Management Discovered much common code Eg: “Is LDH elevated” No formal definitions in grammar for Libraries Used Model as stop gap measure: let answer: Boolean = Model.run('LDH_above_normal”) ‏ Desirable to have formal definition of “Modules” and use compile time checking of in and out types Allows for code reuse and sharing/testing MethodDeclaration::= MethodID '(' ParameterDeclarations? ')' ':' MethodTypeSpecifier MethodBody?...

13. BNF Suggestions Class definitions GELLO classes designed to be extendable No way to inform compiler about new classes Would allow compile time checking Would allow true GELLO classes ClassDeclaration::= ClassHeader '{' InterfaceBody '}' ClassHeader::= ClassID ( ScopedClassName)? ScopedClassName::= ClassID ('::' )*....

14. Minor Corrections Had to cut & paste grammar from HTML document Built a tool to process the BNF into a useful form Found syntax errors in the BNF and corrected. Misspellings Fixed by inferring correct names. Undefined and unused symbols using reachability analysis Symbols “GELLOType”, “ReferenceToClass” undefined Fixed by changing “GELLOTypes” to “GelloType”, and adding “ReferenceToClass” to point to “ReferenceToInstance” Symbols,, unused Fixed by including in “ConditionalExpression”, and omitting and Syntax errors in terminal regular expressions Fixed Fixed errors in some of the terminal regular expressions only generated numbers without digit “0” is ambiguous with was removed by simplifying grammar.

15. GELLO usability issues Clinicians were helping GELLO development Some relaxations proved helpful Added comments // A comment to end of line. /* A comment which is more than one line. */ Allow “ to be used synonymously with ‘ for strings Allow identifiers to be case insensitive With assistance clinicians (with IT interest!) started producing GELLO IDE features such as Code completion needed

16. GELLO is low level GELLO is not suitable for entire Guideline Excellent for data access/constraints however Initially planned to hard code visible guideline In practice content kept changing and another format was required Modified GLIF was used, based on V3.5 specification GLIF gave birth to GELLO but integration not published/completed GLIF data structures had to be persisted in EHR as HL7 CEN 13606 Archetypes used for GLIF and achieved this GLIF structure otherwise proved very suitable Use of GELLO and Archetypes simplified GLIF structure

17. GLIF describes high level logic

18. CEN Archetypes for data definition

19. GELLO constraints GELLO used to constrain archetype data OnInitializeOnCalculateOnValidateIsVisible Requires parameters Pass in Observation

20. GELLO in GLIF decisions

21. CEN Archetypes Used EN-13606 compliant archetypes Archetype describes Tree structure of data Could describe CDA component nesting Archetypes in V2 (tested in project) ‏ Used Observation SubID in OBX segments Terminology used and SNOMED-CT binding Extended with GELLO constraints ie: “Template” Allows HL7 V2 data to be represented as vEMR observations with nested components Used for modified GLIF data structure definitions Model can find Archetypes in Patient Data

22. Current v-EMR Definition

23. Virtual Medical Record definition Currently UML image in standard combined with “Simplified V3 Model” Ideally has agreed definition! Needs a definition language Candidates GELLO class definition (tba) ‏ CEN-13606 (no methods) ‏ UML GELLO class definition best from compiler’s point of view As is snapshot of current patient state can be simple Ideally abstract away differences in specific implementations of eg Past History encoding

24. Message – vEMR interface CEN 13606 Archetypes are possible solution Should be mappable to / from CDA Archetypes in V2 working in this project Would simplify mapping of eg Past History Allow complex GLIF data structures to be persisted Already a CEN standard Extends ability of HL7 V2 to carry structured data Not tied to specific (CEN, openEHR) encoding of data In this case wrapped in template with GELLO constraints (template in xml with embedded GELLO) ‏

25. Example CEN v-EMR Archetype Supports SNOMED-CT model/grammar Can Persist to HL7 V2 or CDA

26. GELLO Terminology Abstraction Provided excellent high level access to SNOMED- CT server that clinicians could use Model class of “SnomedUtterance” (SD) that supports standard Codedvalue interface Allows use of SNOMED-CT grammar and post- coordination of terms Hides interface to SNOMED-CT server from implementation of decision support Could be used with “ConceptDescriptor” (CD) V3 datatype

27. Use of SNOMED-CT CodedValue “implies” very powerful abstraction Allows post-coordination to be used

28. GELLO and SNOMED-CT Functional programming style works well

29. Rector's Model GELLO is the Yellow arrows! v-EMR/Gello classes are the interfaces Archetypes are Metadata GLIF is Inference Model HL7 V2/V3 is ehr Model SNOMED-CT is Concept Model

30. Summary GELLO was able to deliver data access BNF needs to be refined BNF needs to be extended Module definition will cover use cases Interface to GLIF works – needs standardization v-EMR needs to be defined CEN 13606 proven usable for Data structure definition Persistence to HL7 V2 – should work with CDA Terminology abstraction was powerful “Template” constraints can use GELLO

31. GELLO-GLIF-ARCHETYPES Appear to work together well Prototype GELLO Demo available Intersection point for many standards http://www.medical-objects.com.au/

32. Suggested GELLO Class Extensions