1 / 19

An Approach to “Dot Notation” in Arden Syntax Tom Hooks – McKesson October 1, 2002

An Approach to “Dot Notation” in Arden Syntax Tom Hooks – McKesson October 1, 2002. Dot Notation. A gentle “phased approach” to representing objects in Arden Syntax Preserves existing MLMs User-acceptable Helps standardize variable names. Dot Notation Phases. Phase 1 – Just Cosmetic

baakir
Download Presentation

An Approach to “Dot Notation” in Arden Syntax Tom Hooks – McKesson October 1, 2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An Approach to “Dot Notation”in Arden SyntaxTom Hooks – McKessonOctober 1, 2002

  2. Dot Notation A gentle “phased approach” to representing objects in Arden Syntax • Preserves existing MLMs • User-acceptable • Helps standardize variable names

  3. Dot Notation Phases Phase 1 – Just Cosmetic Phase 2 – Simple Arden Objects and Attributes Phase 3 – Lists of Objects Phase 4 – Futures

  4. Phase 1 -- Cosmetic Periods (dots) permitted in Arden variable names -- similar to the underscore Must explicitly reference the entire variable – no objects yet Patient_FirstName := "BILLY"; Patient.FirstName := "BILLY"; (Patient.FirstName, Patient.LastName) := READ last {PatientName};

  5. Phase 1 -- Cosmetic Slight formatting restriction when using dots in variable names Multiple 'dots' are okay Letter is required after each dot x1_2_3 := 15; // currently permitted x1.2.3 := 15; // a really bad variable name x1.y2.z3 := 15; // marginally better

  6. Phase 1 -- Cosmetic New variables look a little different, but offer no gain in functionality, so . . .

  7. Phase 2 – Simple Arden Objects and Attributes Variables expressed as 'object.attribute' Objects are containers Attributes are components of objects "simple" phase restricted to single objects Patient.FirstName := "BILLY"; Patient.LastName := "SMITH"; Patient.DOB := 1960-10-01T00:00;

  8. Simple Arden Objects Simple objects are like heterogeneous lists Attributes are like "labeled elements" Existing Arden list … Pt_info := "SMITH", "BILLY", 1960-03-07T00:00:00; New_pt := pt_info; new_pt[1] is "SMITH", new_pt[2] is "BILLY", new_pt[3] is 1960-03-07T00:00:00

  9. Simple Arden Objects Simple Arden object … pt_info := READ last {Patient_Info}; // this READ mapping returns 3 elements new_pt := pt_info; new_pt.LastName is "SMITH", new_pt.FirstName is "BILLY", new_pt.DOB is 1960-03-07T00:00:00

  10. Simple Arden Objects and Primary Time Maintain primary time at object or attribute level? Object level – compatibility with existing syntax WRITE time of patient Attribute level – maybe more flexibility WRITE time of patient.FirstName

  11. Simple Arden Objects and Primary Time If primary time is preserved at the object level, all attributes must be part of the same order or result set This would NOT be an acceptable object: Renal_function.BUN_level Renal_function.Creat_level

  12. Simple Arden Objects and Default Attributes Arden objects could contain two Default Attributes .value .primary_time If an attribute is not specified, .value is assumed: glucose := 98 is the same as glucose.value := 98

  13. Simple Arden Objects and Default Attributes Similarly, 'time of' operator actually refers to the .primary_time attribute time of glucose is the same as glucose.primary_time With default attributes, existing Arden variables could be "promoted" to simple objects

  14. Phase 3 – Lists of Objects Lists are needed for separate sets of results or orders Assume all attributes in an object are logically related (i.e. same primary time) Example -- Create a list of blood pressure objects with these attributes: bp.systolic bp.primary_time bp.diastolic bp.site

  15. Phase 3 – Lists of Objects Data obtained by READ mappings // this READ obtains four values for each obsv bp := READ last 3 {Blood_pressure_obs}; Data referenced by object list element number [in square brackets] Bp[1].systolic is 146 Bp[2].systolic is 141 Bp [3].diastolic is 82 Bp[2].site is "L Arm"

  16. Lists of Objects and Operators Attributes must be specified when using most operators. For example Avg(bp) will NOT average all attributes of an object Avg(bp.systolic) and Avg(bp.diastolic) WILL return appropriate results

  17. Filtering Lists of Objects WHERE clause supports lists of objects Attributes can be appended to "it" and "they" synonyms // List of objects returned Bp_recent := bp where it occurred within past 2 hours Bp_r_arm := bp where it.site = "R Arm" // Simple list returned Elevated_systolic := bp.systolic where it > 140

  18. Objects in CALL statements Objects and lists of objects permitted as parameters and return variables in MLM CALL statements // This utility MLM accepts a list of objects // and returns a single object Data: avg_bp := MLM 'mlm_average_bp'; Logic: Avg_bp := CALL avg_bp WITH bp; Msg := "Average bp is " || avg_bp.systolic || "/" || avg_bp.diastolic; -

  19. Phase 4 -- Futures Establish standard objects Support for customized objects Discovering object structure at runtime Utilities to output object content Other ideas . . .

More Related