Syntax
Defining OwS Objects
The define statement is used for introducing a new named object to OwS. Upon introduction a new object is given a name and assigned a type. These properties are fixed through the define statement and cannot be changed afterwards. The immediate binding of a new object to a type is important because not only the object's behavior but even the way you may use that object within OwS is determined by its type. The table below lists, how you may further define objects of the defined OwS types.
| type
|
definiton
|
specific behavior
|
| codesystem
|
full definition
|
exported as a FHIR ValueSet resource (or FHIR STU-3 Codesystem resource)
|
| system
|
full definition, internal reference
|
ID and version information goes into references to external code systems
|
| concept
|
full definition, internal reference, qualified concept
|
exported as part of a code system unless given a silent name
|
| predicate
|
full definition
|
exported as concept reference unless given a silent name
|
| property
|
full definition
|
exported as string reference unless given a silent name
|
Full Definition
The OwS full definition syntax is applicable to all types of objects. A full definition consists of a sequence of OnotDL statements within a definition scope that is confided by curly brackets. A full definition may be empty; in that case it only consists of a pair of curly brackets.
The example below shows a full definion of a code system "animals" that consists of different kinds of OwS statements to define the semantics and content of the code system. The included concept "mouse" is not further defined as its definition scope is empty.
define codesystem animals {
default Language = en
set me.URI = (http://test.com/animals)
define concept mouse { }
define concept elephant {
--(bigger than)--> mouse
}
}
A special way for setting property values to an object is to place a MS Word table with two columns into the definition scope. This table holds the name of the property in the first column and the property value in the second column. You may advise the OwS interpreter to consider a property value as a string by prefixing it with "($".
| Style Sheet |
|
Text |
|
Comment
|
| OwS |
|
|
|
opening the definition scope for the concept "mouse"
|
| OwS |
|
|
|
|
|
|
|
|
|
|
|
|
|
($ a small rodent characteristically having a pointed snout, small rounded ears, a body-length scaly tail and a high breeding rate
|
|
|
|
|
using a table for setting property values of the concept "mouse":
- in the first row the property "Code" is set to the string value "Mus".
- in the 2nd row the value of the property "Display" is set to the concept's name ("mouse")
- the 3rd row holds a long text with special characters (comma) as the concept's definition. We do not want the OwS interpeter to parse through that text, so we prefic it with "($" (we could have put it into parentheses as well to gain the same effect).
|
| OwS |
|
|
|
the concept's definition scope is closed
|
Defining Objects from Internal References
Objects of type "concept" and "system" may be defined through properties of other objects that resolve to these respective types. The most common scenario is to introduce an external code system to OwS through the Systems property of the CTS2LE global object:
define system LOINC = CTS2LE.Systems[OID=(2.16.840.1.113883.6.1)]
The same mechanism can be applied for intorducing a concept from an external system:
define concept (hospital letter) = LOINC.Concepts[Code=(68609-7)]
It is important to notice that objects defined through internal references do not have a definiton scope. This is because they adopt all properties except the name from the assigned object. The assignment is "by reference" whoch means that the defined object is just a reference to the source object and therefore all changes applied to the source object will be visible to the newly defined object, too.
In the example below, both concepts "demo" and "demo2" will have a display value of "demonstration" at the end of the definition scope of concept "demo" (Note: This was just to demonstrate the principle. In fact this code would rise an error because there must not be two concepts within the same code system that have the same code).
define concept demo {
define concept demo2 = me
set me.Display = (demonstration)
}
Qualified Concepts
Concepts from external code systems can be introduced by just providing their code together with a reference to the code system:
define concept (hospital letter) = (68609-7)@LOINC
This compact notation is especially useful when defining a value set of codes from external code systems:
define codesystem documenttypes {
set .URI = (http://sample.com/doctypes)
define concept (hospital letter) = (68609-7)@LOINC
define concept (referral note) = (57133-1)@LOINC
define concept (hospital consult note) = (34104-0)@LOINC
}
Nesting of definition Statements
definition statements may be nested, e.g. a code system definition usualy contains further definition statements for the concepts within the code system. The table below lists which object definitions may be included within the definition scope of other objects.
left=outside
top=inside
|
codesystem
|
system
|
concept
|
property
|
predicate
|
| codesystem
|
not allowed
|
not allowed
|
top-level concept within the codesystem
|
property applicable to the code system and all contained objects
|
predicate applicable to all concepts within the code system
|
| system
|
not allowed
|
not allowed
|
concept within the system.
shall be identified by its code
|
property applicable to the code system and all contained objects.
properties values will not be exported
|
predicate applicable to all concepts within the code system.
concepts within the codesystem are only allowed as targets to concept relationships
|
| concept
|
not allowed
|
not allowed
|
sub-concept
|
property applicable to the concept and all of its sub-concepts
|
predicate applicable to the concept and all of its sub-concepts
|
| property
|
not allowed
|
not allowed
|
not allowed
|
not allowed
|
not allowed
|
| predicate
|
not allowed
|
not allowed
|
not allowed
|
not allowed
|
not allowed
|
Examples
Tutorial
The folling lessons of the OwS tutorial provide examples on uning the define statement for defing objects of various types:
OwS Object Language
For examples see the section "Description" above.
OwS Macro Language
Example 1: Terminology including References to an External Code System
In the example below an external code system "OPS" of type system is defined. For referencing to concepts within that system, a relationship "bei OPS" of type predicate is defined. The definiton of the custom terminology "Zusatzentgelte nach § 6 Abs. 1 KHEntgG" and its contained concepts is done using the #heading directive of the OwS Macro Language.
| Style Sheet |
|
Text |
|
Comment
|
| OwS |
|
|
|
define system OPS = CTS2LE.Systems[OID=(1.2.276.0.76.5.425)]
|
|
|
Introducing the system OPS as an external code system using the internal reference notation
|
| OwS |
|
|
|
Defining a custom predicate using the full definition notation
|
| OwS |
|
|
|
#heading 2 codesystem .Name
|
|
|
advising the OwS Makro Language interpreter to map all level-2 headings onto code system definitions. Internally the interpreter will replace any heading 2 text by "define codesystem (Text) {" and insert a "}" character at the end of the level-2 section of the document.
|
| OwS |
|
|
|
#heading 5 concept .Name : .Definition
|
|
|
advising the OwS Makro Language interpreter to map all level-5 headings onto concept definitions. Internally the interpreter will split any heading 5 text into a name part and an definition part and then replace the heading by the OwS commands "define concept (name) { set me.Definition=(definition)". Again the interpreter inserts a "}" character at the end of the level-5 section (e.g. when a new level-5 heading is discovered).
|
| OwS |
|
|
|
#pattern OPS => OPS %c => --(bei OPS)-->(%c)
|
|
|
this pattern allows us to just write the OPS-code we want to refer to instead of writing the full OwS syntax for concept relationships.
|
| OwS |
|
|
|
|
| Überschrift 2 |
|
|
|
Zusatzentgelte nach § 6 Abs. 1 KHEntgG
|
|
|
Defining a code system named "Zusatzentgelte nach § 6 Abs. 1 KHEntgG"
|
| OwS |
|
|
|
As explained above, the heading directive maps a heading onto a full definition. This opens up a definion scope and allows us to further refine the definition of the code system.
|
| Überschrift 5 |
|
|
|
76097392: ZE2016-110 Gabe von Tocilizumab, subkutan, je Fertigspritze 162 mg
|
|
|
a cocnept named "76097392" is defined.
|
| OPS |
|
|
|
the concept refers to the OPS-code "6-005.n"
|
| Überschrift 5 |
|
|
|
76097394: ZE2016-03 ECMO und PECLA, 576 bis unter 800 Stunden
|
|
|
|
| OPS |
|
|
|
|
| Überschrift 5 |
|
|
|
76097395: ZE2016-03 ECMO und PECLA, 800 bis unter 1000 Stunden
|
|
|
|
| OPS |
|
|
|
|
