WIXLIB

Data types.basic PackageRev 1.0.0openEHR Archetype ProfileCLASSInheritC DV STATEC DOMAIN TYPEAttributesMeaningvalue: STATE MACHINE1.1Invariants3.1.2Signaturevalue exists: value / VoidSTATE MACHINE ClassCLASSSTATE MACHINEPurposeDefinition of a state machine in terms of states, transition events and outputs, andnext states.AttributesMeaningstates: Set STATE 1.1Invariants3.1.3SignatureStates valid: states / Void and then not states.is emptySTATE ClassCLASSPurposeSTATE (abstract)Abstract definition of one state in a state machine.AttributesMeaningname: String1.1Invariants3.1.4Signaturename of this stateName valid: name / Void and then not name.is emptyNON TERMINAL STATE ClassCLASSNON TERMINAL STATEPurposeDefinition of a non-terminal state in a state machine, i.e. one that has natureMeaningtransitions: Set TRANSITION Transitions valid: transitions / Void and then not transitions.is emptyDate of Issue: 08 Apr 2007Page 12 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgEditors:T Beale

openEHR Archetype Profile3.1.5Data types.basic PackageRev 1.0.0TERMINAL STATE ClassCLASSTERMINAL STATEPurposeDefinition of a terminal state in a state machine, i.e. a state with no exit Invariants3.1.6TRANSITION ditors:T BealeTRANSITIONDefinition of a state machine transition.SignatureMeaningevent: StringEvent which fires this transitionguard: StringGuard condition which must be true for thistransition to fireaction: StringSide-effect action to execute during the firing of this transitionnext state: STATETarget state of transitionEvent valid: event / Void and then not event.is emptyAction valid: action / Void implies not action.is emptyGuard valid: guard / Void implies not guard.is emptyNext state valid: next state / VoidPage 13 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgDate of Issue: 08 Apr 2007

Data types.text PackageRev 1.0.0openEHR Archetype Profile4Data types.text Package4.1OverviewThe am.openehr profile.data types.text package contains custom classes for expressingconstraints on instances of the types defined in the rm.data types.text package. Only one type is currently defined, enabling the constraining of CODE PHRASE instances. It is illustrated in FIGURE 4.C DOMAIN TYPE(am.archetype.constraint model)textterminology idC CODE PHRASEcode list[0.1]: List String TERMINOLOGY ID(rm.support.identification)0.1FIGURE 4 am.openehr profile.data types.text Package4.2Design4.2.1Standard ADL ApproachThe generic kind of constraint that can be expressed for the DV CODED TEXT type can, like all standard archetype constraints, only include constraints on the attributes defined in the reference modeltype. This is illustrated by the following fragment of ADL:DV CODED TEXT matches {defining code matches {CODE PHRASE matches {terminology id matches {“xxxx”}code string matches {“cccc”}}}}The standard approach allows the attributes terminology id and code string to be constrained independently, and would for example, allow terminology id to be constrained to ICD10 Snomedct LOINC, while code string could be constrained to some particular fixed values. However, thismakes no sense; codes only make sense within a given terminology, not across them. It also makes nosense to allow codes from more than one terminology, as terminologies generally have quite differentdesigns - LOINC and Snomed-CT are completely different in their conception and realisation.A more appropriate kind of constraint for CODE PHRASE instances is for terminology id to be fixedto one particular terminology, and for code string to be constrained to a set of allowed codes; anempty list indicates that any code is allowed. These semantics are formalised in the class definition,shown below.4.2.2Inline dADL formIn an archetype, an instance of C CODE PHRASE can be included as inline dADL, as in the following example:defining code matches {Date of Issue: 08 Apr 2007Page 14 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgEditors:T Beale

openEHR Archetype ProfileData types.text PackageRev 1.0.0C CODE PHRASE terminology id value "icd10" code list ["1"] "CF43.00" -- acute stress reaction, mild["2"] "F43.01" -- acute stress reaction, moderate["3"] "F32.02" -- acute stress reaction, severe }4.2.3Custom Syntax FormThe same constraint as above can be expressed used a custom syntax extension to ADL. This form ismost usually used for expressing value-set constraints within an archetype.defining code matches {[icd10::F43.00, -- acute stress reaction, mildF43.01, -- acute stress reaction, moderateF32.02] -- acute stress reaction, severe}4.2.4Archetype-local CodesIn either of the constraint forms above, the special terminology name “local” is recognised. This isused to indicate that the listed terms come from the ontology section of the archetype itself, ratherthan an external terminology, as in the following example:defining code matches {[local::at1311, -- Colo-colonic anastomosisat1312, -- Ileo-colonic anastomosisat1313, -- Colo-anal anastomosisat1314, -- Ileo-anal anastomosisat1315] -- Colostomy}4.2.5Assumed valueThe custom code syntax provides an equivalent of the assumed value notion from standard ADL byrepeating the assumed value separated by the semi-colon (;) character, as in the following example:defining code matches {[local::at1311, -- Colo-colonic anastomosisat1312, -- Ileo-colonic anastomosisat1313, -- Colo-anal anastomosisat1314, -- Ileo-anal anastomosisat1315; -- Colostomyat1312] -- (assumed value)}Editors:T BealePage 15 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgDate of Issue: 08 Apr 2007

Data types.text PackageRev 1.0.0openEHR Archetype Profile4.3Class Descriptions4.3.1C CODE PHRASE ClassCLASSC CODE PHRASEPurposeExpress constraints on instances of CODE PHRASE. The terminology id attributemay be specified on its own to indicate any term from a specified terminology;the code list attribute may be used to limit the codes to a specific list.InheritC DOMAIN rminology id:Syntax string expressing constraint onallowed primary termsTERMINOLOGY IDcode list: List String FunctionsList of allowed codes; may be empty, meaning any code in the terminology may beused.SignatureMeaning(effected)any allowed: BooleanensureResult terminology id Voidand code list VoidInvariantsList validity: code list / Void implies (not code list.is empty andterminology id / Void)Any allowed validity: any allowed xor terminology id / VoidDate of Issue: 08 Apr 2007True if any CODE PHRASE instanceallowed.Page 16 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgEditors:T Beale

openEHR Archetype ProfileData types.quantity PackageRev 1.0.05Data types.quantity Package5.1OverviewThe am.openehr profile.data types.quantity package is illustrated in FIGURE 5. Twocustom types are defined: C DV QUANTITY and C DV ORDINAL.C DOMAIN TYPE(am.archetype.constraint model)quantitycoded by openEHRterminology group““property”C DV QUANTITYC DV ORDINALproperty[0.1]: CODE PHRASElistlist*DV ORDINAL(rm.data types.quantity)0.*C QUANTITY ITEMmagnitude[0.1]: Interval Real precision[0.1]: Interval Integer units[1]: StringFIGURE 5 am.openehr profile.data types.quantity Package5.2Design - Ordinals5.2.1Standard ADLAn ordinal value is defined as one which is ordered without being quantified, and is represented by asymbol and an integer number. The DV ORDINAL class can be constrained in a generic way in ADLas follows:item matches {DV ORDINAL matches {value matches {0}symbol matches {DV CODED TEXT matches {defining code matches {[local::at0014]} -- no heartbeat}}}DV ORDINAL matches {value matches {1}symbol matches {DV CODED TEXT matches {defining code matches {[local::at0015]} -- less than 100 bpm}}}DV ORDINAL matches {value matches {2}symbol matches {DV CODED TEXT matches {Editors:T BealePage 17 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgDate of Issue: 08 Apr 2007

Data types.quantity PackageRev 1.0.0openEHR Archetype Profiledefining code matches {[local::at0016]} -- greater than 100bpm}}}}The above says that the allowed values of the attribute value is the set of ORDINALs represented bythree alternative constraints, each indicating what the numeric value of the ordinal in the series, aswell as its symbol, which is a CODED TEXT.5.2.2Inline dADL SectionThe above constraint can be represented as an inline instance of the openEHR type C ORDINAL, asfollows:defining code matches {C DV ORDINAL list ["1"] value 0 symbol defining code [local::at0014] -- no heartbeat ["2"] value 1 symbol defining code [local::at0014] -- less than 100 bpm ["3"] value 2 symbol defining code [local::at0014] -- greater than 100 bpm }5.2.3Custom SyntaxA more efficient way of representing the same constraint is using the following ADL syntax:item matches {0 [local::at0014], -- no heartbeat1 [local::at0015], -- less than 100 bpm2 [local::at0016] -- greater than 100 bpm}5.2.4Assumed ValueAssumed value is represented in the same way as in the custom code syntax, i.e. by adding a semicolon demarcated value at the end of the list, as follows:item matches {0 [local::at0014],1 [local::at0015],2 [local::at0016];0 [local::at0014]Date of Issue: 08 Apr 2007-----no heartbeatless than 100 bpmgreater than 100 bpm(assumed value)Page 18 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgEditors:T Beale

openEHR Archetype ProfileData types.quantity PackageRev 1.0.0}5.3Design - Quantities5.3.1Standard ADLA typical need in clinical and demographic data containing an age attribute is to be able to constrain itto different ranges depending on whether it is expressed in months (as is normally the case withinfants) or years (for adults). If the age value is expressed using the openEHR DV QUANTITY, thisconstraint can be expressed as follows:age matches {DV QUANTITY matches {property matches {“time”}units matches {“yr”}magnitude matches { 0.0.200.0 }}DV QUANTITY matches {property matches {“time”}units matches {“mth”}magnitude matches { 3.0.12.0 }}The above says that if units matches “years”, the constraint on DV QUANTITY.magnitude is 0 - 200,while if units is “months” then the magnitude constraint is 3 - 12. This approach is not particularlyefficient or clear, since it allows multiple instances of the constraint on the property attribute, when infact property can only sensibly be the same for all branches of the constraint.5.3.2Inline dADL SectionThe above constraint can be represented as an inline instance of the type C QUANTITY, as below.Note that an assumed value has been included as well, just using normal dADL.age matches {C DV QUANTITY property [openehr::128] -- timelist ["1"] units "yr" magnitude 0.0.200.0 precision 2 ["2"] units "mth" magnitude 1.0.36.0 precision 2 assumed value magnitude 1.0 units "yr" }5.4Class DefinitionsEditors:T BealePage 19 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgDate of Issue: 08 Apr 2007

Data types.quantity PackageRev 1.0.05.4.1openEHR Archetype ProfileC DV ORDINAL Class DefinitionCLASSC DV ORDINALPurposeClass specifying constraints on instances of DV ORDINAL. Custom constrainertype for instances of DV ORDINAL.InheritC DOMAIN TYPEAttributesSignatureMeaninglist: Set DV ORDINAL 1.1FunctionsSet of allowed DV ORDINAL values.SignatureMeaning(effected)any allowed: BooleanensureResult items VoidInvariantsOrdinals valid: items / Void xor any allowedItems valid: items / Void implies not items.is empty5.4.2True if any DV ORDINAL instance allowed.C DV QUANTITY Class DefinitionCLASSPurposeInheritC DV QUANTITYConstrain instances of DV QUANTITY.C DOMAIN TYPEAttributesSignatureMeaning0.1list: List C QUANTITY ITEM List of value/units pairs.0.1property: CODE PHRASEOptional constraint on units propertyFunctionsSignature(effected)any allowed: BooleanensureResult list Void and property VoidInvariantsList valid: list / Void implies not list.is emptyProperty valid: property / Void implies terminology(Terminology id openehr).has code for group id (Group id property,property)Overall validity: (list / Void or property / Void) xor any allowedDate of Issue: 08 Apr 2007MeaningTrue if any DV QUANTITY instanceallowed.Page 20 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgEditors:T Beale

openEHR Archetype Profile5.4.3Data types.quantity PackageRev 1.0.0C QUANTITY ITEM Class DefinitionCLASSPurposeC QUANTITY ITEMConstrain instances of DV ude: Interval Real Constraint on the magnitude of theDV QUANTITY.precision: Interval Integer Constraint on the precision of theDV QUANTITY. A value of -1 means thatprecision is unconstrained.units: STRINGConstraint on units of the DV QUANTITY.FunctionsSignatureMeaningprecision unconstrained:BooleanTrue if no constraint on precision; True ifprecision -1.ensureprecision -1 implies ResultInvariantsEditors:T Bealeunits valid: units / Void and not units.is emptyPage 21 of 25 2005-2008 The openEHR Foundation.email: info@openEHR.org web: http://www.openEHR.orgDate of Issue: 08 Apr 2007

Syntax SpecificationRev 1.0.06openEHR Archetype ProfileSyntax SpecificationThe syntax described in this specification require some additions to the standard cADL grammardescribed in the openEHR ADL specification.The additions to the grammar and lexical specificatoins for the standard cADL syntax are shownbelow. The actual grammar and lexical files used in the openEHR reference ADL parser (written inEiffel) are available at http://my.openehr.org/wsvn/ref impl eiffel/TRUNK/components/adl parser/src/syntax/cadl/parser/?rev 0&sc 0. The .l and .y files can be convertedfor use in other yacc/lex-based programming environments. The production rules of the .y file areavailable as an HTML document.6.1GrammarThe following shows additions to the standard cADL parser production rules (yacc specification) epository(http://svn.openehr.org/ref impl eiffel).c object:c complex object archetype internal ref archetype slot constraint ref c code phrase-- added c ordinal-- added c primitive object V C DOMAIN TYPE ERR C DOMAIN TYPE errorc ordinal:c ordinal spec c ordinal spec ; integer value c ordinal spec ; errorc ordinal spec:ordinal c ordinal spec , ordinalordinal:integer value SYM INTERVAL DELIM V QUALIFIED TERM CODE REFc code phrase:V TERM CODE CONSTRAINT V QUALIFIED TERM CODE REF6.2SymbolsThe following patterns are added to the lexical specification for the standard cADL grammar.---------/* V TERM CODE CONSTRAINT of form */ ---------

The openEHR Archetype Profile model is defined in the package am.openehr_profile, illustrated in FIGURE 1. It is shown in the context of the openEHR am and am.archetype packages. The internal structure of the package mimics the structure of the reference model it profiles, i.e. the openEHR reference model. This is done to make software .