Overview

HGML tags define conditional contexts that indicate the relevancy of corresponding recommendation text.

The Hypertext Guideline Markup Language (HGML) was designed to facilitate the encoding of text/html-based guideline documents through a streamlined markup process. This process primarily involves identification of the natural language expressions which can be offered as recommendations, and the conditions under which they apply. It can be used by itself or as a component of a guideline representation, or as a first-step toward encoding in richer representations. It is intended to be human-friendly, with a minimum of elements to learn about and use, but sufficient to allow a guideline to be integrated within a clinical system.

HGML tags are intended to coexist with HTML tags in an XHTML document. However, XML standards dictate that elements be strictly nested. In cases where the HGML and HTML element borders overlap, the HGML elements are broken into several components that have identical identifier attributes. This inline representation can be converted to or from a "standoff" representation, where HGML elements are listed in a separate annotation file with arbitrary begin and end offsets relative to the original document (or a text-only version).

Syntax

Any combination of HGML tags may be nested (with no overlap, in compliance with XML) resulting in a tree-like substructure^**. Thus any text in the document is associated with a node in the corresponding tree. Con-versely, any node has a corresponding portion of text (context, or conditional text). Children of a node in the tree define "subcontexts", which may be more specific than the "supercontext" of their parent".

^* The root of the tree is an implicit "Segment" whose scope is the entire document.
^**The "Reference" element is essentially a pointer to another node's context, effectively resulting in a directed graph substructure.

Elements

(S) Segment: (formerly "Statement") The basic class of element delimiting a span of text from which most of the other elements are derived. Segments may also have ID and Operator attributes - the former allowing them to be "referenced" and the latter indicating how to logically combine sub-elements.

"Condition" and "Recommendation" elements are subclasses of "Segment", and all of these are allowed to be nested in each other.

Segments containing condition and recommendation elements serve to "bind" conditions to the recommendations (this can also be achieved by placing a condition within a recommendation, or visa versa). A statement may contain a condition which applies, and by default logically AND-ed, to all substatement conditions when evaluating the relevance of the recommendations in those conditional contexts.

One approach to HGML markup is to first identify statements, and then identify the conditions and recommendations within them. In many cases, the identification of statements can be avoided by identifying conditional blocks which include recommendations, or recommendation blocks including conditions followed by the sub-condition and any sub-recommendation elements.

Attributes: Operator, ID

(C) Condition: determine the relevancy of recommendations, either within their scope or at the same level (shared within another statement of any type, recommendation, condition...)

Various conditional contexts can be achieved by nesting [conditional-] statements, with various operators and constraints. An identifier (ID) attribute allows reference [see Link/Reference below]

Those containing other conditions are "compound" conditions, otherwise "terminal" conditions ("TermConds" or "Terms") and may have attributes associating them with concepts, allowing integration with other systems.

It is also sometimes useful to differentiate Top-Level conditions ("TopConds"). [see below]

Attributes: Concept, ID, Operator (Oper)

(Q) Constraint (formerly "Relation"): Relation to Quantity, ("Limit", "Criteria", "X", Association, ...) "Q": Qualifier, Quantity, Qualitative, Quantitiative)

Attributes: Q.variable - inferred through context, Q.value, Q.relation, Q.units

(R) Recommendation: may also be nested with operators.

“Terminal” recommendations (“TermRecs”; with no sub-recommendations) may (or may not) be specific Actions and have an attribute with association to specific concept(s). The first application is to identify something to return as text that will link back to the original guideline document (something to keep in mind when choosing text to include in the markup). However, the specification of specific actions will facilitate closer integration with point of care systems. These might be identified more explicitly with an additional “Action” tag which is functionally equivalent to a terminal recommendation tag with a concept attribute.

Attributes: Concept, ID, Operator

(A) Assertion(Binding): like a recommendation for evaluation side-effects triggers re-evaluation of some conditions perhaps just unknown ones?

Attributes:A.Var[iable], A.Value[Expression]

eg. Risk_Factors := SET()

eg. LDL_Goal := <value>

-Variable is bound to a potentially arbitrary expression but for convenience, begin with values that can be identified through point and click: eg when assertion is expressed, additional selections for variable and value(s) are solicited.

Multiple values then result in a set (eg risk factors) i.e (A a.var a.val*)

?how general and convenient is this mechanism?

(L) Link/Reference: to the element with the specified identifier

Currently, a reference to an element assumes its complete conditional context including its supercontext and subcontexts.

An alternate semantics would be to isolate the subcontext from the supercontext unless the reference was to a "null condition" (or a keyword) that would indicate a conditional context.
- using a statement would be somewhat confusing because it has a truth value dependant on the conditions within it, and here we'd want to reference the truth value of the context in which it exists, those conditions outside.

Attributes: Identifier (ID)

(K) Keyword: something like an anchor

Attributes: Concept, Identifier

(G) GLELT: allows association with elements from GEM (or some other namespace)

Attributes: CLASS/TYPE="GEM_ELEMENT"

Semantics

The primary purpose of HGML is to identify the conditions, the "conditional contexts", in which each recommendation is relevant. For any scenario, such as the application of a clinical practice guideline to a particular patient, each of the conditional expressions may be "True", "False", or "Unknown", and these determine the truth value of the conditional contexts for each of the recommendations. A recommendation appearing in a context that evaluates to "True" for particular scenario will be deemed relevant, while a recommendation is possibly relevant when it's conditional context evaluates to "Unknown".

The "truth value" of any context (associated with a "Condition", "Recommendation" or "Segment" element) is a logical combination of any direct sub-conditions, in conjunction with the truth value of any supercontext in which it appears. The default operator to combine sub-conditions is "OR", while supercontext is combined with "AND". An optional operator attribute of each of these elements can be used to specify an alternate operator to combine subconditions, while conjunction with the supercontext can be averted by specifying special operator "ESCAPE" (in which case the default "OR" is used for sub-conditions).

Note that that sub-statements and sub-recommendations do not contribute to the truth value of their parent, but the parent's value can contribute to their subcontext value.

Condition elements with no sub-conditions may be referred to as "terminal conditions", "termconds", "terms", or "variables". They are assumed to have boolean values unless they appear in conjunction with constraints that predicate their values. This allows incomplete markup of conditions to result in a full text query (posed as a question to a clinician, for example), while further specification may isolate individual constraints on concepts within that can be mapped to an EMR.

• Recommendations can include conditions which apply to them

  (R (C)) => R if C

• Conditions can include recommendations to which they apply

  (C (R)) => R if C 

• Recommendations inside conditions are subject to the more specific context

  (C0^or (C1 ) (C2 ) R1 (C3 R2)) 
  "patients with (C1 ) and (C2 ) should be given (R1 ) although
       those with C3 should receive (R2 )"
   => R1 if C1 OR C2 OR C3
   => R2 if (C1 OR C2) and C3
  

  * However, in this example, note that R1 would be relevant in the case of C3 because C3 is at the same level as C1 and C2.
  * Order of elements in C0 doesn't matter, only scope
  * The specification of the operator attribute "or" for C0 is optional in this case, but makes clear that an individual patient with C1 or C2 is included in the group of patients with C1 and C2. However, "patients with (C1 ) along with (C2 )" might require the use of "and".
  
  
• Sub-conditions may be hidden from the top level by embedding them in sub-statements or recommendations

  (C0 (C1 ) (C2 ) R1 (S (C3) (R2)))
  or (C0 (C1 ) (C2 ) R1 (R2 C3))
  "patients with (C1 ) and (C2 ) should be given (R1 ) although
       (for those who also have (C3), R2 is more appropriate)"
   => R1 if C1 OR C2
   => R2 if (C1 OR C2) and C3
  

  * Here, C3 is embedded and does not imply R1
  * In the sentance, the entire clause containing C3 and R2 could be identified either as a statement, in which case the specific description of the recommendation would be identified as the previous example. Alternatively, the entire clause could be identified as a recommendation containing a the sub-condition C3, and the specific sub-recommendation R2.
  * When multiple recommendations apply, the more specific is presumably more relevant, although ultimately the clinician should make that decision.

To account for unknown values, a three state logic with the values True, False and Unknown. Also note that all operators are symmetric, and likewise, the order of sub-elements in the markup does not matter.

Operators include AND, OR, NOT, X-or-more (depending on an additional "X" attribute), and the special operators EXCEPT and ESCAPE.

When unspecified, the default combining operator for conditions is OR.
(S (C) (C)) == (S^{OR} (C) (C)) == (C^{OR} (C) (C)) == (C (C) (C))
the latter might be called a top-level condition expression containing sub-condition elements

...and substatements are combined with AND
(S (C1) (R1) (S (C2) (R2))) == (C1 (R1) (R2 C2))
=> "if C1 then R1, and if (C1 AND C2) then R2"

...but EXCEPT allows substatements to offer an option to the current context
-this is perhaps the only case where a condition is effected by a subcondition: it's more like a macro
(S1 (C1) (R1) (C0^{EXCEPT} (C2) (R2))
=>"if C1 and NOT C2 then R1"
=>"if C1 and C2 then R2"
"in patients with (C1 ) (R1 ) is appropriate, except those with (C2 ) should be given (R 2)"

Conditions can contain, be contained by, or coexist (as siblings) with constraints that predicate their values.
These three cases can be schematically depicted as (...(C ) (Q )*...), (C (Q )*), (Q (C ))

• Multiple constraints allow different units to be expressed

  (C (C) (Q1) (Q2)) 
  "temperature (above value1 farenheit) (above value2 celsius)"
  => TRUE if (Q1 C) OR (Q2 C)
  

  * the embedded condition identifies the specific clinical term ("temperature"), although it may also be possible to associate the term with the outermost condition omitting the embedded constraints.
  
  
• Conditions can distribute into constraint subexpressions
  (by default OR-ing with the constraints, and AND-ing with subconditions)
  Any addititional subconditions should be embedded within the scope of the constraint. Otherwise it could be difficult to determine which constraints go with which conditions without knowing if one or the other were boolean.
  eg.

  (c C1 Q1 (Q2 (C2))(Q3 (C3)))
  "if measure is high [(range1 in men), (range2 in women)]"
   => TRUE if (C1 Q1) [siblings]
                  OR ((C1 Q2) AND C2) [C1 distributed into first subconstraint]
                  OR ((C1 Q3) AND C3) [C1 distributed into second subconstraint]
   => TRUE if (measure qualitatively high) 
                 OR ((measure in range1) AND man))
                 OR ((measure in range2) AND woman)
    ...the additional subcondition would be ambiguous otherwise in
  (c C1 Q1 (Q2 (c (C2) Q3)))
   => TRUE if (C1 Q1) 
                 OR ((C1 Q2) AND (C2 Q3))) 
  

• Constraints with no associated condition elements are effectively ignored by evaluating to true but should result in a warning that they are incompletely specified

Recommendation tags delineate text that can be returned as a relevent for a specific patient or group which satisfy the associated conditions. Recommendations with no sub-recommendations may be referred to as "terminal recommendations", "term recs" or "action" terms.

Recommendations may include sub-recommendations that indicate more specific clinical terms that indicate actions, or include additional, generally more specific, relevancy conditions. While the optional operator attribute (default OR) determines how any subconditions are combined, an additional optional "recommendation-operator" attribute (default "only one of") determines the relation between sub-recommendations: "only one of" ("XOR"), "one or more of" ("OR"), "all of" ("AND"), "not", ... although the specification of such prescriptions remains incomplete.

• Subrecommendations don't contribute subconditions/augment superconditions

    (C1 R5 (R1 (C2 R2) C3 Re) C4 R4)
    => R1, R3 <- C1 and (C2 or C3)
    => R2 <- C1 and C2 and C3
    => R4, R5 <- C1 or C4
  

• Supercontext applies logical operator to (sibling) subconditions

    (C0^op (C1) (C2 (R1 C3)) R2)
    => R2 <- C1 op C2
    => R1 <- (C3 and C3)
  
    (C^and C1 (C2 R1))
    (C^or C1 (C2 R1))
    (S1 C1 (S2 C2 (R1 C3))) => R1 <- C1 and C2 and C3 [note C1]
   
    R0      => R1 <-
    (R1 C1) => R1 <- C1
    (C1 R1) => R1 <- C1
    (R1 C1 C2) => R1 <- C1 and C2
    (C0^or R1 C1 C2)   => R1 <- C1 or C2
    (R1 (C0^or C1 C2)) => R1 <- C1 or C2
  

* Each element is associated with [zero or more] subelements:
constraints, statements (subconditions, recommendations)
Conditions & Constraints: Tricky to implement?

* It is also possible to differentiate between the various levels of elements (toplevel and terminal):

* "Top level conditions" ("TLCs", "TopConds") [entire conditional expressions] and "Terminal conditions" ("TermConds", "Terms") [variables]

* TopRecs and TermRecs (similarly)

* During the markup process the distinction between top level and terminal elements - for flexibility, markup can proceed top down or bottom up

* For some purposes it may be more useful to speak in terms of distinct conditional contexts

* Some "TermConds" will be "TopConds", we can actually additionally differentiate between types of TopConds: TermTopConds and InnerCompoundConds so that:
Count TopConds=TermTopConds+InnerCompoundConds
Count Conditions=TopConds-TermTopConds+InnerCompoundConds+TermConds

* It can be useful to generate a list of TermConds(Terms) for value acquisition during evaluation

* Each sub-condition, sans duplicates, defines potentially a different conditional context which has a bidirectional association with each recommendation. (If there are no embedded conditions, association with top-level recommendations should be sufficient)

* We can also label sub-conditions by repeatedly labeling outermost conditions as in GATE:
condition(AND,OR,NOT) -> TopCond(compound) [REMOVE condition]
condition -> TermTopCond(=)TopCond(atomic) [REMOVE condition]
???But this will misidentify conds serving a default OR function as TermTopConds???
THEN (for all, brill)
condition(AND) -> InnerCompoundCond [REMOVE condition]
condition(OR) -> InnerCompoundCond [REMOVE conCdition]
condition(NOT) -> InnerCompoundCond [REMOVE condition]
THEN
condition -> TermTermCond(=)TermCond [REMOVE condition]
TermTopCond->TermCond [additional]
action->TermRec
recommendation->TopRec
so that Count Conditions also=TopConds+InnerCompoundConds+TermTermConds

- Standoff will presumably assign begin=, end= attributes (to all tags)

- Treeview will presumably assign graphx=, graphy= attributes (to some tags)
TREEVIEW Algorithm
standoff
-> Offsets of blocks
-> reannotate w/new links,nesting,offsets (standon)