10.1.1.41.7910
Upcoming SlideShare
Loading in...5
×
 

10.1.1.41.7910

on

  • 877 views

 

Statistics

Views

Total Views
877
Views on SlideShare
877
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

10.1.1.41.7910 10.1.1.41.7910 Document Transcript

  • Linking a Medical Vocabulary to a Clinical Data Model using Abstract Syntax Notation 1 Stanley M. Huff1,2, Roberto A. Rocha2,3, Harold R. Solbrig3, M. Wade Barnes4, Steve P. Schrank3, Matt Smith5 1 Intermountain Health Care, Salt Lake City, UT, USA 2 Department of Medical Informatics, University of Utah, Salt Lake City, UT, USA 3 3M Health Information Systems, Murray, UT, USA 4 Department of Computer Sciences, University of Texas, Austin, TX, USA 5 Microsoft, Redmond, WA, USAWe have created a clinical data model using Abstract Syntax Representation and Integration Language (GRAIL) [8, 9],Notation 1 (ASN.1). The clinical model is constructed from a templates, and frames [10-12].small number of simple data types that are built into data ASN.1 [13, 14] is an international standard for describingstructures of progressively greater complexity. Important abstract syntax. It was initially created as a languageintermediate types include Attributes, Observations, and independent mechanism for representing the structure of dataEvents. The highest level elements in the model are messages passed in computer-to-computer interfaces. It has subsequentlythat are used for inter-process communication within a clinical been used as a platform-independent means of distributinginformation system. Vocabulary is incorporated into the model databases [15] and as the storage structure for a nationalusing BaseCoded, a primitive data type that allows vocabulary genetics database [16]. ASN.1 consists of two parts: an abstractconcepts and semantic relationships to be referenced using syntax notation and a set of encoding rules. The abstract syntaxstandard ASN.1 notation. ASN.1 subtyping language was notation describes the logical form and structure of data whileuseful in preventing unbounded proliferation of object classes the encoding rules describe how to make a physical instance ofin the model, and in general, ASN.1 was found to be a flexible data suitable for passing in an interface or for storing in aand robust notation for representing a model of clinical database. There are several encoding rule variations in theinformation. standard targeted for different situations and uses. We currently use Basic Encoding Rules (BER) within ourIntroduction applications. The fact that any logical model expressed in ASN.1 can be readily converted into a storable form is one of The representation of medical concepts in computer systems the strengths of ASN.1. A second strength is that compilersis one of the continuing challenges of medical informatics. and other tools that support the use of ASN.1 are available asRector et al [1] have characterized the problem by identifying software in the public domain or as tool kits from commercialtwo components that contribute to the formal representation of sources.medical concepts: vocabulary elements and an informationmodel. The vocabulary (lexicon) is a set of words or terms used We have previously used ASN.1 (and its predecessor X.409-to denote medical concepts, like the names of drugs, signs, X.410 [17]) in computer-to-computer interfaces [18]. We weresymptoms, diagnoses, and devices. The information model impressed with the expressive power of ASN.1 and with therepresents a grammar, or a set of rules that state how ease of implementing and maintaining the interfaces. Wevocabulary elements can be combined to make a representation wanted to explore the use of ASN.1 to define and implement anof medical information. An information model that is based electronic medical record (also known as a lifetime patient datasemantic types is called a semantic data model (SDM). Several repository). We describe our approach and experiences below.notations have been proposed for representing SDMs inmedicine including, conceptual graphs [2-5], Model forrepresentation of Semantics in Medicine (MOSE) [6],Structured Meta Knowledge (SMK) [7], the GALEN
  • The ASN.1 Clinical Data Model Primitive data types A sample of primitive data types is defined in Figure 1. ToGeneral approach and ASN.1 basics create a “protective buffer” between ASN.1 types and our user defined clinical types, all Universal types used in the model are Our information model for clinical data was created by renamed as user types. For instance, the user defined typedefining simple data types that were then combined to create OctetString (a data type consisting of a sequence of 8-bit bytes)progressively more complex data types in a layered approach. is a simple renaming of the Universal type OCTET STRING.Each of the six layers in the model adds flexibility and Similarly, EmbeddedPDV is a renaming of the Universal typefunctionality. The six layers consist of: primitive data types, EMBEDDED PDV. The EMBEDDED PDV type allows for anattributes, attributes with error handling, observations, events, external type (one defined outside of ASN.1) to be encapsulatedand clinical events. Each of these layers will be described in inside an ASN.1 data structure. Thus, by defining Image,detail in the following sections. Sound, Video, and Document as EmbeddedPDV types, Since the model is expressed in ASN.1, we will describe a few externally defined types of these items can exist without conflictASN.1 basics before proceeding. With a few of the basics in an ASN.1 instance.understood, we will describe each part of the model, adding ULong2 has been defined as an INTEGER, but it has beendescriptions of more complex ASN.1 syntax as it is used in the constrained to have a value from 0 to 264-1. In ASN.1, this isexamples and Figures. called a subtype constraint. In other words, the new type is ASN.1 syntax is used to create descriptions of the structure of derived from the parent type, but the new type represents adata (metadata definitions). The definitions are then used in proper subset on the domain of the parent type. In our example,programs to guide the creation of actual instances of the data Ulong2 is an INTEGER, but its value has been constrained tousing the BER. Each item that is encoded in a BER string is those that can be represented in a 64 bit integer variable type.described by three parts: an identifier, the length of the value of Subtype constraints are always enclosed in parentheses. Athe item, and the actual value of the item. The identifier of an different type of subtype constraint is shown for Decimal. It isitem in an encoded string is derived algorithmically from its defined as IA5String (a particular character set), butASN.1 definition. Because a length specification is included constrained so that the only values that can be in the string arewith each field in the encoded string, ASN.1 has almost no numeric characters and a period (decimal point). Thus, theinherent size restrictions. Decimal type is a character string representation of a decimal number. ASN.1 has many of the features of an object oriented datadefinition language. It allows unlimited depth in hierarchical OctetString ::= OCTET STRINGdata structures, and also allows unlimited reuse of types, BERString ::= OctetStringincluding recursive type definitions. ASN.1 does not describethe behaviors (methods) of an object, but only describes the EmbeddedPDV ::= EMBEDDED PDVstructure of the object. Ulong2 64 ::= INTEGER (0..2 -1) All object definitions (data types) are built by reference to Decimal ::= IA5String (FROM(“0123456789” | “.”))other objects. There are currently over 25 predefined types Ncid ::= ULong2(called Universal Types) in the ASN.1 standard, including RelSFormNumId ::= ULong2INTEGER, BOOLEAN, REAL, NULL, etc. All user-definedtypes must ultimately be defined by reference to one or more of DateTime ::= Ulong2the Universal types. Most of the Universal type names consist Text ::= CHOICE {of all upper case letters. Names for user defined Types must english [0] BasicString, spanish [1] LatinOne,begin with a capital letter, but should use mixed case thereafter. portuguese [2] LatinOne,A new type is defined from an existing type using the french [3] LatinOne,assignment characters “::=”. For example, a new integer type german [4] LatinOne, italian [5] LatinOne }based on the Universal INTEGER type could be defined asfollows: Image ::= EmbeddedPDV NewInteger ::= INTEGER Sound ::= EmbeddedPDV Video ::= EmbeddedPDV With this background we will now proceed to the firstdefinitions used in the clinical data model and describe other Document ::= EmbeddedPDVASN.1 features as they occur in the model. Figure 1: Definition of some primitive Types by reference to universal ASN.1 Types.
  • Figure 1 also shows a somewhat more complex definition for subtract, and compare exact chronological times. DateTime hasText. Text is defined by reference to the Universal type two possible resolutions. If the resolution is to the millisecond,CHOICE. An ASN.1 CHOICE is similar to the union type in then dates between 1800 and 2517 are supported. If thethe C programming language. It means that when an actual resolution is seconds or greater, dates between 0001 andinstance of the type is created, the type may take one of several 183738 are supported. Having the two different resolutionsalternative forms. In the case of Text, the text could be means that we can store very precise times for current eventsEnglish, Spanish, Portuguese, French, German, or Italian. This like electrical activity on an EKG tracing, while being able tois an “exclusive OR” relationship; an instance of type Text must cover a very broad time range for less precisely known dates,be one and only one of the possible choices. You will notice like the birth dates and death dates of a patient’s ancestors.that the set of possible choices is enclosed in curly braces, and We would next like to describe the definition of BaseCoded,that there are three parts to each line item in the choice. The which is the elementary type that creates the link between thefirst token in the first line is “english.” In ASN.1, “english” is information model, as expressed using ASN.1, and the codedcalled an element name. It is similar to a variable name in the medical vocabulary. For the definition of BaseCoded to beC programming language. It must be unique within the understood, we need to briefly review the structure of ourCHOICE construct, and it is a unique textual identifier of the vocabulary, which we have described in detail in a previousfirst item in the choice. The second token in the first item is publication [19].“[0],” and is called an ASN.1 tag. ASN.1 tags are only used bythe algorithm that creates an item identifier while encoding an As shown in Figure 2, the vocabulary is organized aroundinstance of the type. In the context of a BER encoded type, the concepts, where a concept is “a unit of thought constitutedtag is the part of the definition which ensures that the identifier through abstraction on the basis of characteristics common to acreated is unique. Since the ASN.1 tag is meaningful only to set of objects” [20]. In our vocabulary, each conceptthe computer algorithm, it can be ignored when reading an (representing a unique object, identity, or meaning) is assignedASN.1 definition. a numeric concept identifier (Ncid). The Ncid is a globally unique identifier of a concept. As shown in Figure 1, an Ncid The final token of the first CHOICE line item is is defined as a Ulong2, meaning that there can be 264“BasicString.” BasicString is the ASN.1 type of the first (approximately 1.6 x 1019) concepts in the vocabulary.CHOICE item. As can be seen, the other items in the CHOICEhave the type of “LatinOne.” BasicString actually correspondsto an ASN.1 definition that specifies the set of characters that Related Surface Formscan legally be used in the English language. The primitivedefinition of the BasicString character set is not shown in theexample. The type “LatinOne” also refers to a specific set of Concept Pen-Vee Kcharacters that can be used for representation of words in the RelSFormNumId 456other languages indicated in the CHOICE. To summarize, anitem of type Text could be a set of characters in one of six penicillin V potassium V-Cillin Kpossible languages, where English text would be represented Ncid 123 RelSFormNumId 295using the character set defined by the type BasicString, and textin any of the other five languages would use the character set Veetidsdefined by the type LatinOne. This example is syntactically RelSFormNumId 746correct, but it is obviously incomplete in terms of the contentrepresented. Also shown in Figure 1 is the definition of DateTime, which Figure 2: The relationship between concepts and relatedrepresents an exact chronological time. As a Ulong2, surface formsDateTime is a 64 bit quantity, but this definition obscures thefact that DateTime actually has six subparts. The six parts are: Each concept can have one or more representations (alsoresolution, number of days from starting date, time since called surface forms). A representation is one or more wordsmidnight, time offset to GMT, daylight savings time flag, and that a person would use to refer to the concept. As shown intime zone indicator. Some of these quantities are slightly Figure 2, the concept “penicillin V potassium” (Ncid 123) hasredundant with one another, but this was an intentional overlap at least three representations: “Pen-Vee K,” “V-Cillin K,” andthat facilitates ease of use. DateTime is a user defined “Useful “Veetids.” In a manner similar to the concept identifiers, eachType,” meaning that the internal parts and behaviors of representation is also assigned a unique numeric identifier,DateTime are not directly manipulated by the user, but are called the related surface form numeric identifierimplemented in the software modules that set, get, add, (RelSFormNumId). In the example, the representation “Pen- Vee K” has been assigned the RelSFormNumId of 456. Thus,
  • concepts are the fundamental building blocks of the vocabulary, Besides BaseCoded, three other coded types are defined inand each concept is uniquely identified by an Ncid. Figure 3: CodedWRSform, CodedWOSform, and Coded. TheFurthermore, each concept can have one or more associated purpose in defining these types is to create subtypes ofrepresentations (surface forms), and each representation has a BaseCoded that have specialized uses. BaseCoded itself isunique RelSFormNumId. Both Ncids and RelSFormNumIds actually a virtual type, meaning that it is used to derive otherare of type Ulong2. With this background, we can now move to types, but it is not instantiated as part of the clinical database.the definition of BaseCoded, which is shown in Figure 3. Clinical records actually use one of the three derived types, depending on the situation. In some situations it may be BaseCoded is the data type used in the information model to mandatory that the database capture the concept representationrefer to items in the vocabulary. It is defined as a SET, that was seen by the user. For instance, in a drug orderingmeaning that it is a data type that is made up of a group of application that allows ordering by brand name, if the userother data types. The items in the SET are enclosed in curly ordered “Pen-Vee K,” it is important to capture not only thebraces, and elements can be marked as OPTIONAL as ncid of the drug being ordered, but also the RelSFormNumId.appropriate. Any item in a set not marked optional is required. By storing both the Ncid and the RelSFormNumId we know not The BaseCoded set consists of three elements: ncid, text, and only what drug was ordered but we also know exactly whatrelSFormNumId. The syntax of how the elements in the SET textual representation of the drug name the user saw in theare defined is the same as previously described for items in a order entry application. The CodedWRSform type (whichCHOICE construct. Thus, the ncid element is said to be of type means a coded data type with required surface form) wasNcid, the text element is said to be of type Text, and the created for just this situation. At other times, it would be goodrelSFormNumId element is said to be of type RelSFormNumId. to record the surface form that the user saw, but the surfaceEach of these three types was previously defined in Figure 1. form may not always be available. In this situation, the type CodedWOSform (meaning a coded data type with optionalBaseCoded ::= SET { surface form) would be used. Finally, there are situations where ncid [1] Ncid OPTIONAL, only capturing the concept is needed. In these cases, the Coded text [3] Text OPTIONAL, relSFormNumId [4] RelSFormNumId OPTIONAL } type (meaning a coded data type without a surface form) would be used.CodedWRSform ::= BaseCoded (WCS { ncid, The three new coded data types are derived from BaseCoded relSFormNumId, using ASN.1 subtype notation. As before, the subtype text OPTIONAL }) constraint is contained in parentheses. When constraining aCodedWOSform ::= BaseCoded (WCS { SET, the WITH COMPONENTS syntax is used to indicate ncid, relSFormNumId OPTIONAL, which elements of the parent type are included in the new child text OPTIONAL }) type. For the sake of brevity, we have substituted “WCS” forCoded ::= BaseCoded ( WCS{ WITH COMPONENTS in all Figures. Elements within the ncid }) subtype constraint are referenced by their element name, and the tag and type of the element are not repeated in the subtype Figure 3: Definition of the Coded data types by subtype because it would be redundant with the tag and type definition constraint of the BaseCoded type. in the parent type. A component within a subtype constraint is required unless it is followed by the keyword OPTIONAL. The three parts of the BaseCoded set refer to the Thus, in the definition of CodedWRSform, ncid andcorresponding parts of the vocabulary described in the relSFormNumId are required elements, while text is optional.preceding paragraph. A BaseCoded item contains the ncid, In the definition of CodedWOSform, ncid is required whiletext, and relSFormNumId of a single concept from the both relSFormNumId and text are optional. For the definitionvocabulary. Thus, to create an instance of BaseCoded that of Coded, ncid is required, and no other elements are allowed.referred to the concept “penicillin V potassium” as described inthe previous example, ncid would have a value of 123, textwould have a value of “Pen-Vee K,” and relSFormNumIdwould have a value of 456. Because the text of a concept has aone-to-one correspondence with the relSFormNumId, the textelement of a BaseCoded is redundant. “Text” is included as anoptional part of the definition of BaseCoded as a way todecrease the time needed to decode and display coded datatypes.
  • Value ::= CHOICE { relationship between the Attribute and its value. For instance, decimal [0] Decimal, if you had an Attribute called "systolic blood pressure" and the long1 [1] Long1, patients systolic blood pressure measurement was "less than long2 [3] Long2, dateTime [6] DateTime, 60," the value of "systolic blood pressure" would be set to "60," coded [7] CODED, and numericOp would be set to “<” (less than). Likewise, the codedWOSform [8] CODEDWOSFORM, units and precision fields allow units of measure and precision codedWRSform [9] CODEDWRSFORM, to be specified for any measured continuous variable. The text [10] Text, document [11] Document, probability fields allow for each Attribute to have a user stated sound [12] Sound, probability (userStatedProb) as in the phrase "there is a 60% image [14] Image, chance of malignancy" or a calculated probability video [16] Video } (machineProb), generated from a computerized instantiationAttribute ::= SET { process. value [0] Value, negation [1] LCodedWOSformAtt(Negation) OPTIONAL, The definition of Attribute introduces a new shorthand ASN.1 numericOp [2] LCodedWOSformAtt(NumOperator) OPTIONAL, notation that we have not used previously. uncertainty [3] LCodedWOSformAtt(Uncertainty) OPTIONAL, machineProb [4] Probability OPTIONAL, “LCodedWOSformAtt(Units)” is shorthand which expands to a userStatedProb [5] Probability OPTIONAL, definition of a constrained subtype of LAttribute. The modifier [6] LCodedWOSformAtt(AttModifier) OPTIONAL, derivation of LAttribute is described later (Figure 7) The units [7] LCodedWOSformAtt(Units) OPTIONAL, precision [10] Precision OPTIONAL } shorthand expression means that “units” is a loosely coded attribute whose value must come from the domain of Units. Figure 4: The definition of Attribute, by reference to Units is a set of vocabulary elements containing units-of- previously defined Types. measure like, “minute,” “second,” “kilogram,” and “liter.” Though the intermediate definitions are not shown, theAttributes LCodedWOSformAtt type is derived from Attribute. Thus, Attribute indirectly references itself as part of its definition. The primitive ASN.1 types, as defined in Figures 1 and 3, are This is the first example of the recursive use of ASN.1used to define a more complex data type called Attribute, as definitions. For the sake of brevity, the definitions ofshown in Figure 4. Attributes are the building blocks of the Probability, and Precision are also not shown.information model, and they are used to store the variouscharacteristics of the clinical events found in the medical One of the most important implicit attributes is “negation.”record. The ASN.1 CHOICE construct is used in the definition Negation is used in conjunction with coded Attributes toof “Value” to represent the fact that the “value” of an Attribute express that a given finding is NOT present. For example, itcan be any one of the primitive types. For instance, patient might be important clinically to state that the appearance of aidentifiers may be alphanumeric character strings, blood trauma victim’s urine was “not bloody.” In this case, thepressures might be integers, a hepatitis surface antigen test attribute being evaluated would be urine color, value would becould be a titer, a microscopic urine cell count could be a range set to “bloody” and negation would be set to “not.” Use ofof cells per high power field, and the date and time of birth negation allows pertinent negative findings to be representedwould be a date/time element. without explicit creation of finding codes that include the words “not” or “no,” or “none.” Many attributes within the medical domain have values thatare expressed using words or text rather than numbers. The implicit attributes could have been handled explicitly asAttributes like patient names, symptom names, drug names, “ordinary” attributes, but their frequent use and generaldisease names, and anatomic locations are examples of textual applicability favored making them an integral (implicit) part ofdata. It is worth noting, however, that the possible values for Attribute.an attribute like "drug name" come from a finite set of possible One problem with the definition of Attribute, as shown inchoices which means that it is possible to represent these terms Figure 4, is that not all of the implicit attributes are appropriateby one of the Coded types shown in Figure 3, rather than by for all value types that could be chosen from the CHOICE listtheir full text representation. This ability to encode the value of for Value. For example, it would be inappropriate to usetextual attributes has important implications in the physical precision to describe a coded term, and it is unclear whatdatabase. negation would mean if attached to an image. To clarify In addition to “value,” a set of optional characteristics (called exactly which implicit attributes can be used with which valueimplicit attributes in a previous publication [11]) are also types, specialized subtypes of Attribute have been created. Bydefined for the Attribute type. The implicit attributes (Figure 4: design, Attribute is another virtual type, i.e. one that is used totags 1 to 10) are used to store complementary details about the derive other types, but not used directly to create instances of
  • data in the patient database. Only the specialized subtypes of DateTimeIntervalSet ::= SET {Attribute are used to create data instances. startTime [0] BaseDateTimeAttribute, endTime [1] BaseDateTimeAttribute } Three examples of specialized Attribute subtypes are shown in TiterSet ::= SET {Figure 5. BaseCodedAttribute has been defined as a subtype of lower [0] BaseDecimalAttribute,Attribute, where value has been restricted to be of type coded. upper [1] BaseDecimalAttribute }The implicit attributes of negation, uncertainty, machine IntegerRangeSet ::= SET {probability, user stated probability, and modifier can be lower [0] BaseLong2Attribute,optionally present. Numeric operator, units, and precision have upper [1] BaseLong2Attribute }been deleted as implicit attributes in the definition of Figure 6: The definition of an interval of chronological timeBaseCodedAttribute. For BaseDateTimeAttribute, numeric using the specialized BaseDateTimeAttribute.operator, negation, uncertainty and precision are included asoptional elements, while machine probability, user stated Figure 6 also shows the definition of TiterSet andprobability, modifier, and units have been deleted. The IntegerRangeSet. TiterSet defines a complex type which allowsdefinition of BaseDecimalAttribute was created in a similar the recording of clinical laboratory observations that aremanner. Specialized subtypes of Attribute were made for all of measured by serial dilution methods. It uses two componentthe primitive types, but only these three examples are shown. elements, “lower” and “upper,” to represent the separate parts of a titer expression. Each of the components in TiterSet is ofBaseCodedAttribute ::= Attribute ( WCS { type BaseDecimalAttribute. Similarly, IntegerRangeSet is a value (WCS {coded}), negation OPTIONAL, complex type which would typically be used to record uncertainty OPTIONAL, microscopic slide observations where the number of items per machineProb OPTIONAL, high power field varies within a bounded range. The userStatedProb OPTIONAL, modifier OPTIONAL }) components of IntegerRangeSet are of type BaseLong2Attribute.BaseDateTimeAttribute ::= Attribute ( WCS { value ( WCS {dateTime}), Attributes with error handling numericOp OPTIONAL, negation OPTIONAL, uncertainty OPTIONAL, Attribute represents a very flexible data type that is the precision OPTIONAL }) foundation for many clinically useful types. However, at theBaseDecimalAttribute ::= Attribute ( WCS { level of abstraction provided by Attribute, some practical value ( WCS {decimal}), considerations about how processes will instantiate these types numericOp OPTIONAL, becomes important. One of these considerations is error precision OPTIONAL }) handling. For example, if we have defined a clinical Figure 5: The creation of specialized attributes by subtype measurement like hematocrit as a numeric quantity (say as a constraint of Attribute. BaseDecimalAttribute type), and an interface from a clinical application sends a value for a hematocrit of “not done” in a The specialized subtypes of Attribute can be used to create laboratory interface message, an exception condition exists.more complex data types that have more than one component, The information model has defined the clinical variable as aas shown in Figure 6. DateTimeIntervalSet is a new type that is numeric type, but the source system has sent a value that is ofused to represent an interval of chronological time. It contains type text. In order to handle these kinds of exceptiontwo components, a start time and end time. Each of the conditions, a new type called LAttribute was defined, as showncomponents is typed as a BaseDateTimeAttribute, meaning that in Figure 7.each end of the interval can include uncertainty and LAttribute (which stands for Loosely-typed Attribute) isimprecision as part of the specification. This new type defined as a choice between BaseAttribute or ErrorType.represents a very flexible representation of chronological time Furthermore, BaseAttribute is a choice containing all of thethat is often needed in recording a patient’s signs, symptoms, specialized versions of Attribute, and ErrorType is a choiceand diseases. between four possible types that could be used to represent errors. The intended use of this structure is as follows. Data coming into the system is expected to be represented as one of the types available in the BaseAttribute choice. If the incoming data is of the type expected, then the data is instantiated as that type. However, if the incoming data is not of the expected type, the data is instantiated as one of the error types. Referring back to the hematocrit example, if hematocrit was typed as
  • BaseDecimalAttribute, and a value of “42.8” was sent by a BaseObservation ::= SET {clinical laboratory system, the value would be instantiated obsValue [0] LAttribute,inside of the decimalAtt element of BaseAttribute. If the value commonMods [1] ObservationSequence OPTIONAL, obsMods [2] ObservationSequence OPTIONAL,of the incoming hematocrit was “not done,” then the value comments [3] Comments(ObsComment) OPTIONAL,would be instantiated as errorText inside of ErrorType. Using actionsInfo [8] EventActionSequence OPTIONAL,LAttribute in this way provides for exception handling when semanticLinks [9] SemanticLinks OPTIONAL }incoming data is not of the expected type. This ultimately ObservationSequence ::= SEQUENCE OF ObservationObjectmeans that clinical data in the system is strongly typed to the ObservationObject ::= INSTANCE-OF-SUBTYPE(greatest extent possible, given the limitations of a sending SUBTYPES OF (BaseObservation))application. Figure 8: The definition of BaseObservation by reference toLAttribute ::= CHOICE { LAttribute. type [0] BaseAttribute, error [1] ErrorType } The next element, commonMods, is a sequence of commonBaseAttribute ::= CHOICE { modifiers of a class of observations. For laboratory decimalAtt [0] BaseDecimalAttribute, measurements, typical kinds of common modifiers include long1Att [1] BaseLong1Attribute, abnormal flags, delta check flags, and reference ranges. The long2Att [3] BaseLong2Attribute, dateTimeAtt [6] BaseDateTimeAttribute, exact set of possible common modifiers for a given observation codedAtt [7] BaseCodedAttribute, are not specified in the definition of BaseObservation, but are codedWOSformAtt [8] BaseCodedWOSformAttribute, specified when subtypes of BaseObservation are created. codedWRSformAtt [9] BaseCodedWRSformAttribute, ObsMods is also a sequence of modifiers of the observation, but textAtt [10] BaseTextAttribute, documentAtt [11] BaseDocumentAttribute, it contains modifiers that are appropriate for a specific soundAtt [12] BaseSoundAttribute, observation, rather than common to a general class of imageAtt [14] BaseImageAttribute, observations. For example, in evaluating a patient for rales, videoAtt [16] BaseVideoAttribute, timeIntAtt [1004] DateTimeIntervalSet } typical observation modifiers would be quality and severity. Examples that further illustrate the use of commonMods andErrorType ::= CHOICE { obsMods are shown later (Figures 19, 21, and 23). errorCoded [0] CodedWOSform(LooseTypeErrorCode), errorText [1] Text, As shown in Figure 8, both commonMods and obsMods are of errorByte [2] OctetString, errorBit [3] BitString } type ObservationSequence. ObservationSequence is then defined as a SEQUENCE OF an ObservationObject. Figure 7: The definition of LAttribute (a loosely typed SEQUENCE OF is a standard ASN.1 type, and signifies an attribute) by reference to the specialized attribute definitions. ordered set, where all of the elements in the set are of the same ASN.1 type. ObservationObject is defined as an INSTANCE-Observations OF-SUBTYPE. LAttribute becomes the building block for the next level of INSTANCE-OF-SUBTYPE is a new type that plays a specialabstract data type in the clinical information model. Clinical role in the information model. There were at least threedata is usually accompanied by other information that motives for the creation of INSTANCE-OF-SUBTYPE. First,establishes the context and circumstances surrounding the we saw a need to manage the structural evolution of ASN.1collection of the data, as well as possible modifiers of the data. subtypes over time. Second, we saw the need to handleIt is useful to keep this set of information together as an information at different levels of abstraction, i.e. to create ainformation object. To accommodate this need, degree of polymorphism in the ASN.1 types. Third, we wantedBaseObservation was created, as shown in Figure 8. an ASN.1 type that would allow us to create subtype definitionsBaseObservation was patterned after the OBX Segment from a known type after ASN.1 compile time.(Observation Results Segment) as defined in the HL7 The definition of INSTANCE-OF-SUBTYPE is shown inspecification [21]. The principle component of Figure 9. The “type” component contains the actual data of anBaseObservation is obsValue, which is of type LAttribute, and instance of the subtype. The structure of the data inside ofrepresents the value of whatever was observed or evaluated. “type” must conform to the ASN.1 supertype (symbolicallyObsValue is modified by three associated data elements, named TypeReference) from which the specific subtype wascommonMods, obsMods, and comments. For the sake of derived. It is required that the definition of TypeReference bebrevity, the Comments type is not further defined here, but it present in the same ASN.1 module where a subtype ofrepresents a sequence of either coded or text comments INSTANCE-OF-SUBTYPE is defined. This ensures that theassociated with the observation.
  • information to code and decode the ASN.1 type is present in value contained in “type” must be a subtype of BaseType. Noteexecutable applications. that it is possible to decode the value of the subtype knowing only the definition of BaseType. The Ncid and Version of theINSTANCE-OF-SUBTYPE ::= SEQUENCE { type are only needed when an instance is to be validated against id [0] Ncid, its subtype definition. version [1] Version, type [2] TypeReference } NewSpecificSubtype ::= INSTANCE-OF-SUBTYPE ( Figure 9: The definition of Instance of Concept. SUBTYPES OF (BaseType)) BaseType ::= TypeReference The “id” element of INSTANCE-OF-SUBTYPE contains thename (identifer) of the specific subtype that is instantiated in Figure 10: The syntax for defining a constrained subtype ofthe “type” element. The id element is of type Ncid. We require Instance of Concept.that all ASN.1 types and subtypes be defined as concepts in thedata dictionary. Furthermore, each concept which represents an One further conceptual problem remains. We have defined anASN.1 type includes validation information as part of its abstract observation (BaseObservation) as a set of elementsdefinition. Since each concept is assigned an Ncid, the Ncid (obsValue, commonMods, obsMods, etc.), and we have definedserves as a unique identifier of the subtype contained in an ObservationSequence as a SEQUENCE OF ObservationObject,INSTANCE-OF-SUBTYPE. where ObservationObject is an INSTANCE-OF-SUBTYPE, which must be a subtype of BaseObservation. (Note that The “version” element is include because the validation BaseObservation is another case where we have recursivelyinformation associated with a subtype may change over time. used a type definition within itself.) Given these definitions,The “version” element represents the version number of the ASN.1 provides the ability, using WITH COMPONENTsubtype validation information that was current at the time a (abbreviated here as WC), to constrain ObservationSequence tosubtype was instantiated. Thus, the combination of the “id” and be of specific types as shown in Figure 11.“version” elements provide a unique key to access validationinformation associated with a subtype, while the “type” field LaboratoryModifiers1 ::= ObservationSequence (WC {contains the actual data as defined by TypeReference. Data WCS ( AbnormalFlag | ReferenceRange ) })dictionary services are supplied so that subtype validation AbnormalFlag ::= BaseObservation ( WCS { ... })information can be used by an application at runtime. ReferenceRange ::= BaseObservation ( WCS { ... }) The kind of polymorphism that we were trying to achieve Figure 11: The syntax for defining a constrained subtype ofusing INSTANCE-OF-SUBTYPE can be illustrated by an Instance of Concept.example. An electrolyte panel that consists of fourmeasurements (sodium, potassium, chloride, and bicarbonate) Unfortunately, this use of ASN.1 notation constrainscan be thought of as a sequence of laboratory observations ObservationSequence to be a sequence consisting of zero orbecause they can all be represented using a common data more AbnormalFlags and/or zero or more ReferenceRanges.structure. That is, they can be represented as subtypes of The desired result is a sequence of elements that are subtypes ofBaseObservation. However, each measurement can also be BaseObservation, but consisting of exactly one AbnormalFlagthought of as a distinct object class. As a class, serum sodium and exactly one ReferenceRange. We have not been able tomeasurements have a different reference range and different achieve this result within existing ASN.1 notation and have hadclinical meaning than serum potassium measurements. It may to resort to an extension, WITH TYPES.be desirable for a data entry program to validate that a serumsodium value came from the range that was appropriate for The WITH TYPES notation provides the ability toserum sodiums, and that serum potassium values came from the positionally constrain each individual element within therange that was appropriate for serum potassiums. So in SEQUENCE OF type. Using the same example as in Figuredifferent situations, there is a need to treat an electrolyte panel 11, the WITH TYPES notation can be used to correctlyas a sequence of the same structural type (BaseObservation), or constrain ObservationSequence as shown in Figure 12. Thisalternatively, as a sequence of four specific ASN.1 types. notation indicates that ObservationSequence is a sequence of BaseObservations and must consist of exactly two The syntax for creating a constrained subtype of INSTANCE- BaseObservations; one occurrence must be of typeOF-SUBTYPE is shown in Figure 10. This syntax constrains AbnormalFlag and one occurrence must be of typethe contents of the id and type fields of the INSTANCE-OF- ReferenceRange.SUBTYPE to be subtypes of any other specified and knownASN.1 type. This definition means that NewSpecificSubtype is The WITH TYPES and SUBTYPES OF notation are the onlyderived from INSTANCE-OF-SUBTYPE where the encoded “extensions” to the semantics of the 1994 ASN.1 specification
  • that we have made. All of the notation described in this The SemanticLinks component of BaseObservation enablesdocument with the exception of WITH TYPES and SUBTYPES separate instances of objects and events to be linked via aOF is either taken directly from the ASN.1 specification or is named relationship. For example, SemanticLinks could be used“shorthand” which can be readily mapped into the to connect a positive throat culture result with a prescription forcorresponding ASN.1 notation if needed. The SUBTYPES OF penicillin, using the named relationship “treated-by” to make itnotation is an extension using ideas from the specification of clear that the prescription was written as the treatment for thethe standard ASN.1 type INSTANCE-OF. WITH TYPES has positive throat culture. The purpose and use of semantic linksno precedent in standard ASN.1. was also described in a previous publication [11]. The structure of SemanticLinks is shown in Figure 13.LaboratoryModifiers2 ::= ObservationSequence ( WITH TYPES { SemanticLinks is a sequence of SemanticLink, meaning there AbnormalFlag, can be zero to many semantic links for each observation. ReferenceRange }) SemanticLink contains three components. The “relationship”AbnormalFlag ::= BaseObservation (WCS { ... }) element is the coded name of the relationship that links the twoReferenceRange ::= BaseObservation (WCS { ... }) instances. Possible relationships include: caused-by, associated- with, treated-by, contains, etc. The second element, Figure 12: The syntax for defining a constrained subtype of objectPointer, contains the unique key (equivalent to a unique Instance of Concept using the WITH TYPES syntax. object identifier) to the linked observation or event. The final element, linkInfo, is of type EventActionSequence, and Neither of these exceptions is viewed as an impediment to the provides attribution information about who, what, when, anduse of standard ASN.1 compilers. For example, the simple where the link was created. EventActionSequence is also theremoval of the WITH TYPES portion of the specification underlying type of actionsInfo in BaseObservation, and is theprovides valid ASN.1 which accurately describes the content of common data type used for recording attribution informationthe data. With the removal of the WITH TYPES syntax, for observations, semantic links, and events.LaboratoryModifiers2 would simply be a sequence ofBaseObservations. By removing WITH TYPES, what is SemanticLinks ::= SEQUENCE OF SemanticLinkomitted is validation information that specifies that the SemanticLink ::= SET {sequence should contain two, and only two, specific subtypes of relationship [0] CodedWOSformAtt(LinkRelationship),BaseObservation (AbnormalFlag and ReferenceRange). objectPointer [1] ObjectPointer,Without this information, the user of a generic ASN.1 compiler linkInfo [2] EventActionSequence OPTIONAL }would be able to encode a LaboratoryModifiers2 instance which Figure 13: The definition of SemanticLinks.was not actually valid. However, since we require that any dataentered into the system must pass a service level validation step The definition of EventActionSequence is shown in Figureregardless of the source, invalid encodings would still be 14. EventActionSequence is a sequence of EventActionObject.detected. Meanwhile, any valid instance of EventActionObject is an INSTANCE-OF-SUBTYPE where theLaboratoryModifiers2 could be decoded using its more general concept instances must be subtypes of EventActionInfo. Thedefinition as a sequence of BaseObservations. Ncid inside of the INSTANCE-OF-SUBTYPE (see Figure 9), A similar situation exists for the SUBTYPES OF syntax. It is indicates an action taken by a user or application. Typicalessentially a way of specifying an ASN.1 template where actions would include add, modify, delete, sign, review, andTypeReference can be replaced by a known ASN.1 type at the place on hold. The EventActionInfo set contains the time of thetime a subtype definition is created. This is a convenient action, the reason for the action, and any free text or codednotation for the derivation of subtypes. However, this syntax comments about the action. AssociatedActions referscould be replace by a policy that required each subtype derived recursively back to the definition of EventActionSequence, andfrom INSTANCE-OF-SUBTYPE to become its own type. allows actions to be taken on other actions. One common useMacro substitution in a precompile step would accomplish the would be to allow counter signatures on signatures.same thing. Either of these approaches would allow a standard The final element in EventActionInfo is sourceInfo, whichASN.1 compiler to decode a BER encoded string created by our ultimately becomes a sequence of possible SourceInfo types.system. The source of the information could be a person, a system, a Having explained the substructure of ObservationSequence device, etc. Further details of the components ofand its component type INSTANCE-OF-SUBTYPE, we will PersonSourceInfo, SystemSourceInfo, etc., are not shown butnow describe the remaining elements within the definition of include person names, identifiers, model numbers, andBaseObservation. application names. The list of possible information sources will likely increase as new applications and interfaces are added to the system.
  • We have now described all of the elements that are included BaseEvent ::= SET {in BaseObservation. It is the ASN.1 type that contains a single sharedContext [0] ObservationSequence,observation about a patient, with its attendant modifiers and eventContent [1] EventContent, comments [2] Comments(BaseEventComment) OPTIONAL,attribution information. BaseObservation, in turn, becomes the actionsInfo [7] EventActionSequence OPTIONAL,building block for Events, which are the next level of patient semanticLinks [8] SemanticLinks OPTIONAL }data organization in our system. EventContent ::= CHOICE { observations [0] ObservationSequence,EventActionSequence ::= SEQUENCE OF EventActionObject events [1] EventSequence }EventActionObject ::= INSTANCE-OF-SUBTYPE( EventSequence ::= SEQUENCE OF EventObject SUBTYPES OF (EventActionInfo) ) EventObject ::= INSTANCE-OF-SUBTYPE(EventActionInfo ::= SET { SUBTYPES OF (BaseEvent)) time [1] LDateTimeAtt OPTIONAL, associatedActions [2] EventActionSequence OPTIONAL, Figure 15: The definition of BaseEvent by reference to reasons [3] Reasons OPTIONAL, BaseObservation. comments [4] Comments(EvntActComment) OPTIONAL, sourceInfo [5] SourceInfoSequence } The first element in BaseEvent is sharedContext, whichSourceInfoSequence ::= SEQUENCE OF SourceObject ultimately resolves to a sequence of BaseObservations. TheSourceObject ::= INSTANCE-OF-SUBTYPE( purpose of sharedContext is to record context and attribution SUBTYPES OF (SourceInfo)) information that is common to all of the observations that willSourceInfo ::= CHOICE { be recorded in eventContent. For the cardiovascular exam, person [0] PersonSourceInfo, sharedContext would contain who the examiner was, the date system [1] SystemSourceInfo, and time of the examination, and where the examination was decision [2] LogicProcessSourceInfo, institution [3] ExternalInstitution, performed. For the clinical chemistry example, sharedContext device [4] DeviceInfo, would contain descriptions of the sample, who collected the physicalLocation [5] PhysicalLocation } sample, and when it was collected. Figure 14: The definition of EventActionSequence. EventContent is the real information container in BaseEvent. It ultimately resolves to either a sequence of BaseObservations,Events or to a sequence of BaseEvents. This is a recursive definition, allowing events inside of events to whatever depth is necessary In many situations in clinical medicine, observations are not to capture a complex clinical situation. The other elements inmade in isolation but are collected in a common context. For BaseEvent (comments, actionsInfo, and semanticLinks) haveexample, observations on heart sounds, heart murmurs, heart the same use and structure as they did in BaseObservation,rate, systolic and diastolic blood pressures might all be collected except that they are now modifiers of the event, rather than aas part of a cardiovascular examination. In the laboratory, a single observation.serum sodium, potassium, carbonate, and chloride are oftendone on the same blood specimen as a collection of clinical Patient Eventschemistry observations. Previous publications have describedthe use of events in building patient information systems [11, With the definition of BaseEvent, the next step in the clinical22, 23]. The BaseEvent type, as shown in Figure 15, was type hierarchy is the association of one or more events with adesigned to allow efficient recording of observations that share patient, and then the association of patient events witha common clinical context. Many of the parts of BaseEvent are transactions and messages. Figure 16 presents the definition ofreused from BaseObservation. “PatientEvent,” where one or more events (derived from BaseEvent) are associated with a patient. The substructure of Patient is not shown, but contains a unique numeric identifier of the patient. PatientEvent then becomes the building block for PatEventSequence, which is then included in Action. Action represents a logical set of actions that will be taken against the patient database. Besides the sequence of patient events, Action contains an operation (delete, update, insert) which indicates what action is to be taken relative to the patient database, a set of reasons for the action, and errors associated with the action. Action is the primary component of PatDataTrans, a patient data transaction which consists of a sequence of actions.
  • PatDataTrans ::= SEQUENCE OF Action in the information model. It became apparent that it would be useful to be able to enclose or encapsulate one ASN.1 typeAction ::= SET { patEvents [0] PatEventSequence, inside of another ASN.1 type. The difference between operation [1] Operation, INSTANCE-OF-SUBTYPE and INSTANCE-OF-CONCEPT is reason [2] ActionReasons OPTIONAL, that INSTANCE-OF-CONCEPT offers an anonymous choice errors [3] Errors OPTIONAL } between one or more types that are listed inside of the “id”Operation ::= CHOICE { element. An anonymous choice means that the concepts that deleteOp [0] Null, are part of the choice do not have to be defined in the ASN.1 updateOp [1] Null, insertOp [2] Null } module where the INSTANCE-OF-CONCEPT type is used. This is the opposite of INSTANCE-OF-SUBTYPE, where thePatEventSequence ::= SEQUENCE OF PatientEvent contained type must be defined in the same ASN.1 modulePatientEvent ::= SET { where it is used. patient [0] Patient, events [1] EventSequence } The value of the anonymous choice is that applications only Figure 16: The definition of PatientEvent by reference to have to be aware of the definition of the contained types which EventObject. they will manipulate or decode. Assume, for example, that a message routing application is able to route a message based on The final step in the clinical information model is to include the information contained in MessageInfo. By using thethe patient data transactions in a message. Within the system, INSTANCE-OF-CONCEPT construct as shown in Figure 17,all process-to-process communication or computer-to-computer the definitions of PatDataTrans and HDDTrans (and all of theinterfaces are based on a single message definition, as shown in types that they reference) do not need to be included in theFigure 17. HemsMessage (health enterprise management routing application. However, an application that was storingsystem message) contains three components. Version patient data in the patient database would need the definition ofrepresents the version number of the HemsMessage definition PatDataTrans (and the types which it references) in order tothat was current at the time a message was created. decode and validate that the patient events it contains conformMessageInfo contains global information about security and to their ASN.1 definitions.access information, message flags, errors associated with the Essentially, the INSTANCE-OF-CONCEPT type providesmessage, and the context (attribution information) of the “cut points” in the ASN.1 definitions that allow applications tomessage. TransactionObject ultimately contains PatDataTrans include only those types that they directly manipulate or decode.(the patient transaction) or HDDTrans (a transaction to query At runtime, applications are also able to decode only thosefor information in the health care data dictionary), but portions of a BER-encoded ASN.1 string in which they haveTransactionObject utilizes a new construct called INSTANCE- interest.OF-CONCEPT. The definition of INSTANCE-OF-CONCEPT is shown inHemsMessage ::= SET { Figure 18. The “id” element contains the Ncid of the ASN.1 version [0] Version, type that is contained as a BER encoded string in “value.” messageInfo [1] MessageInfo, trans [3] TransactionObject } Version is the version number of the type definition that was current at the time an instance of the INSTANCE-OF-MessageInfo ::= SET { CONCEPT type was created. The “&Value” notation expresses accessSecurityInfo [3] AccessSecurityInfo, messageFlags [5] MessageFlags OPTIONAL, the anonymous choice. It means that the definition of the type errors [8] Errors OPTIONAL, referred to by Ncid (and encoded in the “value” element) does context [9] UserContext OPTIONAL } not have to reside in the same module where INSTANCE-OF-TransactionObject ::= INSTANCE-OF-CONCEPT ( WCS { CONCEPT is used. ..., id ({PatDataTrans} | {HDDTrans} ) }) INSTANCE-OF-CONCEPT ::= SEQUENCE { id [0] Ncid, Figure 17: The definition of a HemsMessage (health version [1] Version, enterprise management system message), which ultimately value [2] &Value } contains a patient data transaction (PatDataTrans). Figure 18: The definition of INSTANCE-OF-CONCEPT. INSTANCE-OF-CONCEPT has some similarity in purposeand structure to INSTANCE-OF-SUBTYPE. As we We have now completed the description of all of theimplemented the early releases of our clinical database, it underlying data types used in our clinical information model.became obvious that information hiding and encapsulation were We would now like to show by example how these structuresnecessary in order to effectively manage modularity and change are used.
  • As illustrated above, BaseObservation is the building block of another body site by a “BodySiteConnector”. BodySite andBaseEvent. However, the complex information structures BodySiteConnector are both derived from BaseObservation.necessary to describe clinical events are often shared across BodySiteConnector is a simple observation consisting of amultiple types of events. For instance, most clinical findings coded attribute whose values are limited to the domain of “bodyreported by the patient or detected by the provider require a site connectors.” BodySite is a complex observation in whichprecise description of their anatomic locations. The an anatomical site (“BodyAnatomy”) is modified orrepresentation of these common pieces of information is complemented by a series of optional characteristics, includingpossible with the creation of subtypes of BaseObservation, “side” (right, left, etc.), “laterality” (lateral, medial, etc.),making these subtypes the building blocks of more complex “depth” (anterior, posterior, etc.), among others. These variousobservations and events. characteristics are themselves subtypes of BaseObservation, taking advantage of the recursive characteristic of the Figure 19 illustrates the definition of “LocationDescription” information model.as a constrained subtype of BaseObservation. The first elementin the definition is “codedObsVal(Presence).” Note that Figure 20 presents the definition of a patient exam eventcodedObsVal is a shorthand syntax for describing a coded derived from BaseEvent, and it includes theobservation restricted to codes in a specific domain. It is LocationDescription observation as an optional context. Figureactually a macro that is used to hide some of the complexity of 20 introduces a new element of ASN.1 subtype notation. Thethe ASN.1 subtype syntax from people creating or reviewing the use of ellipsis (“...”) in a subtype definition means that all themodel. The expansion of the macro is not shown. The elements defined in the parent type are included in the subtype“codedObsVal(Presence)” element has a purpose similar to the definition unchanged, unless otherwise specified. Forpurpose previously described for Negation in the definition of PatientExamEvent, it means that all of the elements defined inAttribute (Figure 4). The value of Presence can be either BaseEvent are applicable to PatientExamEvent, except for“Present” or “Absent (Not Present),” which allows negation of a “sharedContext” which is explicitly included, but as aLocationDescription as expressed in the phrase “The rash was constrained subtype that is defined further. PatientExamEventnot present on the palms of the hands.” is used to represent the information from the physical examination where more than one observation is associatedLocationDescription ::= BaseObservation ( WCS { with the same body location, such as systolic and diastolic blood codedObsVal(Presence), pressures measured in the right brachial artery. obsMods ( WITH TYPES { BodySite, BodySiteConnector OPTIONAL }) }) PatientExamEvent ::= BaseEvent ( WCS { ...,BodySiteConnector ::= BaseObservation ( WCS { sharedContext ( WITH TYPES { codedObsVal(BodySiteConnectors) }) EventDateTime, ObjectStatus OPTIONAL,BodySite ::= BaseObservation ( WCS { LocationDescription OPTIONAL }) }) codedObsVal(Presence), obsMods ( WITH TYPES { BodyAnatomy, Figure 20: The definition of PatientExamEvent by subtype BodySide OPTIONAL, constraint of BaseEvent Laterality OPTIONAL, BodyDepth OPTIONAL, Clinical observations are frequently associated with a series of BodyRelativeDepth OPTIONAL, commonly used modifiers. Some of these modifiers are BodyLevel OPTIONAL, BodyRelativeLevel OPTIONAL, particularly important when numeric values are reported, such RelativeSideOrLaterality OPTIONAL }) }) as clinical laboratory measurements. Figure 21 shows theBodyAnatomy ::= BaseObservation ( WCS { derivation of “PatientObservation” from BaseObservation, codedObsVal(BodyAnatomySite) }) where common modifiers for numeric result values areBodySide ::= BaseObservation ( WCS { explicitly included (reference range, abnormal flag, status, delta codedObsVal(BodySides) }) flag, reporting flag, and location).Laterality ::= BaseObservation ( WCS { codedObsVal(Lateralities) }) Figure 19: The definition of a complex observation (body location description) by recursive subtype constraint of BaseObservation. The rest of the definition of LocationDescription basicallyconsists of a recursive sequence of a “BodySite” linked to
  • PatientObservation ::= BaseObservation ( WCS { PulmonaryExam ::= PatientExamEvent ( WCS { ..., ..., commonMods ( WITH TYPES { sharedContext ( WITH TYPES { ReferenceRange OPTIONAL, ..., AbnormalFlag OPTIONAL, LocationDescription ABSENT }), ObjectStatus OPTIONAL, eventContent (WCS { DeltaFlag OPTIONAL, observations ( WITH TYPES { ReportFlag OPTIONAL, Rhonchi, LocationDescription OPTIONAL }) }) Rales }) }) }) Figure 21: The definition of PatientObservation by subtype Rhonchi ::= PatientObservation ( WCS { ..., constraint of BaseObservation. codedObsVal(Presence), commonMods ( WITH TYPES { Figure 22 illustrates how PatientExamEvent and ...,PatientObservation can be combined to define a more specific ReferenceRange ABSENT, LocationDescription }),type of patient exam, in this case a blood pressure battery obsMods ( WITH TYPES {(“BPBattery”). In BPBattery the observation component is Pitch OPTIONAL,made explicit by restricting it to systolic (SysBP) and diastolic Severity OPTIONAL }) })blood pressure (DiaBP) observations. In addition, both SysBP Rales ::= PatientObservation ( WCS {and DiaBP are to be resulted using units of “mmHg.” Again, ...,decUObsVal is shorthand for an observation that has been codedObsVal(Presence), commonMods ( WITH TYPES {constrained to be a decimal value measured in the specific units ...,of “mmHg.” ReferenceRange ABSENT, LocationDescription }), Finally, Figure 23 illustrates a more complex type of obsMods ( WITH TYPES {PatientExamEvent, named “PulmonaryExam.” In this Quality OPTIONAL,example, LocationDescription is excluded for use at the event Severity OPTIONAL }) })level (by use of the keyword ABSENT), but it is required to be Figure 23: The definition of PulmonaryExam (a set ofpresent with each observation. This allows the location of each pulmonary examination findings) by subtype constraint ofobservation to be described individually. PatientExamEvent, and by subtype constraint of Figure 23 suggests that PulmonaryExam corresponds to PatientObservation.possible findings encountered during an examination of the In the same way, if “rales” are detected, the “quality” andlungs, such as “Rhonchi” and “Rales.” The PulmonaryExam “severity” of the rales can be stored. Notice that the locationevent is instantiated by acknowledging the presence or not of description is a required modifier for both Rhonchi and Rales,each observation. If a given observation is present, the i.e., if either rhonchi or rales are present, their anatomicalcharacteristics of this observation can also be recorded. For locations must be determined. Likewise, the common modifierinstance, if “rhonchi” is present, the “pitch” and “severity” can ReferenceRange does not apply in either case and is marked asbe optionally represented. absent. These two examples are fairly simple, but show theBPBattery ::= PatientExamEvent ( WCS { process whereby very complex clinical data models can be built ..., from BaseObservation and BaseEvent. eventContent (WCS { observations ( WITH TYPES { SysBP, Practical Experience DiaBP }) }) })SysBP ::= PatientObservation ( WCS { We have implemented an electronic medical record system decUObsVal(MillimetersOfMercury) }) using ASN.1. The exact model used was an earlier version ofDiaBP ::= PatientObservation ( WCS { the clinical model presented in this paper. The patient decUObsVal(MillimetersOfMercury) }) repository was implemented using a client-server architecture Figure 22: The definition of BPBattery (a blood pressure and using a relational database as the primary data store. We battery) by subtype constraint of PatientExamEvent, and by previously published a description of the system architecture subtype constraint of PatientObservation. [24]. In the first design of the data repository, patient events were to be stored as packed PTXT strings. (PTXT is the hierarchical encoding system used in the HELP system [25]. In the actual implementation of the system, the packed PTXT strings were replaced by BER encoded ASN.1 strings. The
  • BER strings are stored in a variable length character field in the return a list of all classes to which the concept belongs.relational database. In addition to the patient event table, there Because the RelSFormNumId is present, the application canare a number of associated relational tables that expose partially also display the exact representation that was seen by the user atnormalized views of the patient data to standard SQL query data entry time. This rich set of behaviors evolves from thetools. The associated tables also act as indexes to the ASN.1 combination of a simple ASN.1 structure, a set of vocabularyobjects contained in the patient event table. The ASN.1 strings tables, and a set of library routines that implement behaviorsare created and modified using a standard library of routines based on the structure.written in C and C++. Application developers can interact with A second issue is the alternative approach that ASN.1the ASN.1 objects using C, C++, or Microsoft OLE interfaces. subtyping offers in the creation of new object types. In standardThree clinical systems have recently begun live operations object-oriented modeling, specialized types are created byusing this architecture. inheriting the attributes and behaviors of the parent type and then adding additional attributes. This approach could beDiscussion implemented using CHOICE constructs in ASN.1. Our approach has been to create a parent type that includes all of the We have found ASN.1 to be a very flexible and robust attributes that can exist in any of the children, and then createlanguage for representing and implementing a clinical the children using the extensive subtype constraint language ofinformation model. Our approach has been to develop a small ASN.1. The different approaches offer tradeoffs innumber of primitive types that are then used to construct implementation. Because of the large number of object typescomposite data types of progressively greater complexity. This that exist in clinical medicine, the standard approach can leadstrategy has uncovered some interesting issues related to ASN.1 to an unwieldy number of object classes. For example, it is easyand also object oriented modeling in general. to think of a hematocrit measurement as an object class, since there could be many hematocrits associated with a given One issue is that ASN.1 is not a true object oriented language. patient, there are expectations about the range of values that itThat is, ASN.1 only defines the data structures related to an can take, it has a specific unit of measure, etc. However, ifobject, not its methods or behaviors. However, the ASN.1 data everything that is at the same level of abstraction in clinicalstructure is very flexible and can be used as the storage medicine as hematocrit becomes an object class, there would bestructure for persistent data related to the object. thousands of object classes. In our case, the true clinical objects were implemented using By contrast, a single ASN.1 type could be implemented, i.e.Microsoft OLE Automation technology, but the internal storage BaseObservation, and then thousands of subtypes would bestructure used ASN.1. Methods and behaviors related to the created for objects at the level of hematocrit. The subtypeASN.1 objects were implemented in programs written in C and information is only used in the general implementation when aC++. The goal was to encapsulate behaviors at the appropriate new instance of hematocrit or one of the other subtypes islevel, and then add more complex behaviors as the objects created. Validation is simple because it follows directly frombecome more sophisticated. For instance, there are low-level ASN.1 subtype notation. After validation, the subtype can beroutines that subtract and compare two DateTime items. At the manipulated simply as its supertype, which in this case islevel of Attribute, these routines are still utilized to compare BaseObservation. The ASN.1 subtyping approach has providedtwo DateTimeAttributes, but the higher level functions must an important simplification in the implementation of ouralso handle the open-ended uncertainty allowed at the level of patient data repository.Attribute. The lower-level functions are the building blocks forhigher-level behaviors. Another particular advantage of ASN.1 is that it integrates coded data types (and hence vocabulary) with other primitive Coded data, in particular, benefits from behaviors types in a consistent modeling framework. Coded dataimplemented around a simple data structure. At most, a coded elements are just one more primitive type in the system. Codeddata element in our system can consist of 3 elements: an Ncid, a data has its own set of behaviors, but it lives side by side withRelSFormNumId, and Text. However, a set of programs, using numbers, dates, times, and images. Rather than using one kindinformation stored in the vocabulary tables of the system, can of infrastructure to manage coded data and another to manageimplement very useful behaviors on the coded data types. the other types of patient data, there is a single consistent toolThese routines allow an application to display coded data in used for all patient data. At the level of Attribute, the modeldifferent languages, to translate between languages, and to explicitly shows how uncertainty and negation are handled. Atdisplay a representation that is determined by other parameters the level of BaseObservation, the explicit relationship ofof the runtime environment. By reference to the semantic modifiers to the observation is shown. Eventually the clinicalnetwork in the vocabulary tables, the routines can determine information model builds to the level of patient events, patientwhether a given concept is a member of a particular class, or transactions, and inter-process messages, all of which are
  • expressed using a common language. Because of the tight One of our objectives in having a formally defined model wasconnection between ASN.1 syntax and ASN.1 encoding, the to support application development. In our setting, applicationsstorage structure of any element is known as soon as its abstract include data entry programs, data review programs, clinicalsyntax is defined. alert modules, decision logic, and database queries to support clinical research and quality assurance. The clinical model is A final advantage of ASN.1 is that it is platform independent. structured so that the model can be browsed by applicationData encoded using ASN.1 is easy to pass from client to server developers. By entering a keyword it is possible to traverse theor across computer-to-computer interfaces, because of the byte- model from a term, to a coded attribute, to an observation, andoriented nature of a BER-encoded string. then to events that contain that observation. For example, by There are limitations to the use of ASN.1. As previously entering the term penicillin, one could find that the conceptmentioned, it is not a true object modeling language. It does penicillin can be taken as the value of the coded attribute drug,not include the definition of methods and behaviors as part of and that the drug attribute participates in pharmacy ordertype definitions. events, medication administration events, drug allergy events, and antibiotic susceptibility results. The definitions for these A second limitation, at least in our implementation, is that events can then be shown to the developer who can choose theour type definitions cannot support a generative grammar. [9, events of interest for her application. The information model is26]. The subtype definitions, at the granularity that we have in place to support this kind of browsing, but we are just nowcreated them, could be instantiated in nonsensical ways. This creating the tools that will support this kind of user interface towas intentional. The work of making all of the definitions the model.explicit before the system could be used was a practicalimpediment to implementation. By leaving some vagueness in It would be interesting to do a comparison of not only thethe definitions, we risk storing data that is ill structured or expressive power of various modeling notations, but also thenonsensical. On the other hand, we have been able to degree to which they simplify implementation of a system.implement systems quickly, and we can continue to refine the Potential candidates for a comparison would include ASN.1,subtype definitions as time permits. IDL (Interface Definition Language), Conceptual Graphs, UML (Unified Modeling Language), and GRAIL. An impediment to such a comparison would be defining a set of measurableConclusion characteristics on which to base the comparison. One discovery that we made in the development of our Finally, we would like to investigate other formally definedclinical information model was only tangentially related to the clinical information models to see how we might incorporateuse of ASN.1. We found that there were a number of issues their information into our model. We recognize that we haveabout medical information representation that could not be only just begun the process of defining all of the necessarydiscussed intelligently without reference to a formal notation. ASN.1 types and subtypes that will be needed to support aAt some level the words normally used to communicate abstract comprehensive clinical information system. We wouldideas are not useful unless they can be rigorously defined by welcome the opportunity to collaborate with others who arereference to objects represented in a formal syntax. This is developing compatible models in a formal notation.certainly the case when discussing how medical vocabulariesinteract with a clinical information model and a semantic Referencesnetwork. Until an information model is formally defined, it isdifficult to draw consistent boundaries about what role each 1. Rector AL, Nowlan WA, Kay S, Goble CA, Howkins TJ. Aelement plays in the total picture of medical information Framework for Modelling the Electronic Medical Record.representation. Methods of Information in Medicine 1993;32(2):109-19. There are a number of issues in which we are interested, but 2. Sowa JF. Toward the Expressive Power of Naturalhave not had time to develop or pursue. We can see relevance Language. In: Sowa JF, ed. Principles of Semanticof ASN.1 subtyping as a mechanism to represent the Networks. San Mateo, CA: Morgan Kaufmann Publishers,decomposition of multi-word medical expressions into more Inc., 1991:157-89.atomic elements, but have not finalized the model that wouldimplement a solution. The approach that we envision is to 3. Campbell KE, Das AK, Musen MA. A Logical Foundationprogressively define more specific subtypes of our existing data for Representation of Clinical Data. Journal of thetypes. For example, LocationDescription (Figure 19), could be American Medical Informatics Association 1994;1(3):218-used to show the association between the expression “right 32.upper arm” and its decomposition as BodyAnatomySite =“arm,” BodyLevel = “upper,” and BodySide = “right.”
  • 4. Friedman C, Cimino JJ, Johnson SB. A Schema for (DER). New York City, NY: American National Standards Representing Medical Language Applied to Clinical Institute, 1994. Radiology. Journal of the American Medical Informatics 15. Ohkawa H, Ostell J, Bryant S. MMDB: an ASN.1 Association 1994;1(3):233-48. specification for macromolecular structure. Ismb5. Bell DS, Pattison-Gordon E, Greenes RA. Experiments in 1995;3:259-67. Concept Modeling for Radiographic Image Reports. Journal 16. Hart KW, Searls DB, Overton GC. SORTEZ: a relational of the American Medical Informatics Association translator for NCBIs ASN.1 database. Computer 1994;1(3):249-62. Applications in Biosciences 1994;10:369-78.6. Rossi Mori A, Bernauer J, Pakarinen V, et al. Model for 17. CCITT. Recommendation X.409, Message Handling Representation of Terminologies and Coding Systems in Systems: Presentation Transfer Syntax and Notation. Medicine. Seminar Opportunities for European and U.S. CCITT, 1984. Cooperation in Standardization in Health Care Informatics. Geneva, 1992. 18. Huff SM, Evans RS, Gandhi S. An LIS to HIS Interface Using CCITT Standard Protocols. In: Kingsland III LC, ed.7. Rector AL, Nowlan WA, Kay S. Unifying Medical Thirteenth Symposium on Computer Applications in Informatics Using an Architecture Based on Descriptions. Medical Care. Washington, DC: IEEE Computer Society In: Miller RA, ed. Fourteenth Symposium on Computer Press, Los Angeles, 1989:692-5. Applications in Medical Care. Washington, D.C.: IEEE Computer Society Press, Los Angeles, 1990:190-194. 19. Rocha RA, Huff SM, Haug PJ, Warner HR. Designing a Controlled Medical Vocabulary Server: The VOSER8. Rector AL, Nowlan WA. The GALEN Representation and Project. Computers and Biomedical Research Integration Language (GRAIL) Kernel, version 1. 1994;27(6):472-507. Manchester, UK: Medical Informatics Group, University of Manchester, 1993. 20. International Organization for Standardization. ISO/IEC Standard 11179 Specification and Standardization of Data9. Rector AL, Glowinski WA, Nowlan WA, Rossi-Mori A. Elements, Part 1 Framework for the Specification and Medical-concept Models and Medical Records: An Standardization of Data Elements. New York City, NY: Approach Based on GALEN and PEN&PAD. Journal of the American National Standards Institute, 1996. American Medical Informatics Association 1995;2(1):19- 35. 21. Health Level Seven. Health Level Seven Standard Version 2.2: An Application Protocol for Electronic Data Exchange10. Sager N, Lyman M, Bucknall C, Nhan N, Tick LJ. Natural in Healthcare Environments. Ann Arbor, MI: Health Level Language Processing and the Representation of Clinical Seven, Inc., 1994. Data. Journal of the American Medical Informatics Association 1994;1(2):142-60. 22. Friedman C, Hripcsak G, Johnson SB, Cimino JJ, Clayton PD. A Generalized Relational Schema for an Integrated11. Huff SM, Rocha RA, Bray BE, Warner HR, Haug PJ. An Clinical Patient Database. In: Miller RA, ed. Fourteenth Event Model of Medical Information Representation. Symposium on Computer Applications in Medical Care. Journal of American Medical Informatics Association Washington, D.C.: IEEE Computer Society Press, Los 1995;2(2):116-34. Angeles, 1990:335-339.12. Masarie FE, Miller RA, Bouhaddou O, Giuse NB, Warner 23. Huff SM, Craig RB, Gould BL, Castagno DL, Smilan RE. HR. An Interlingua for Electronic Interchange of Medical Medical Data Dictionary for Decision Support Applications. Information: Using Frames to Map between Clinical Eleventh Symposium on Computer Applications in Medical Vocabularies. Computers and Biomedical Research Care. Washington, D.C.: IEEE Computer Society Press, Los 1991;24:379-400. Angeles, 1987:310-317.13. International Organization for Standardization. ISO/IEC 24. Huff SM, Haug PJ, Stevens LE, Dupont RC, Pryor TA. 8824-1: Information Technology - Abstract Syntax Notation HELP the next generation: A new client-server architecture. One (ASN.1) - Specification of Basic Notation. New York Journal of the American Medical Informatics Association City, NY: American National Standards Institute, 1994. 1994;1(symposium supplement):271-5.14. International Organization for Standardization. ISO/IEC 25. Kuperman GJ, Gardner RM, Pryor TA. HELP: A Dynamic 8825-1: Information Technology - ASN.1 Encoding Rules - Hospital Information System. New York, NY: Springer- Specification of Basic Encoding Rules (BER), Canonical Verlag, 1991. Encoding Rules (CER) and Distinguished Encoding Rules
  • 26. Chomsky N. Aspects of the theory of syntax. Cambridge, MA: The MIT Press, 1965.