HL7 RIM Browser

The HL7 Reference Information Model (RIM) is a reference model that defines a common set of classes and relationships used for representing the content of health care messages. It forms the basis of the HL7v3 standard.

This tool is an interactive browser for exploring the HL7 RIM classes. You can browse the attributes of each class and view their descriptions (purple links). The relationships between classes are displayed as light purple elements. The structure of classes is rendered as a TypeScript-like type definition.

Class hierarchy

Class attributes

Access

Definition
A role played by a device when the device is used to administer therapeutic agents (medication and vital elements) into the body, or to drain material (e.g., exudates, pus, urine, air, blood) out of the body.
Usage notes
In general, Access is a Role of a ManufacturedMaterial or Device, something specifically manufactured or created to serve that purpose, such as a catheter or cannula inserted into a compartment of the body. Devices in the role of an Access are typically used in intake/outflow observations and in medication routing instructions. Microbiologic observations on the material itself or on fluids coming out of a drain are also common.
The Access role primarily exists in order to describe material actually deployed as an access, and not so much the fresh material as it comes from the manufacturer. For example, in supply ordering a box of catheters from a distributor, it is not necessary to use the Access role class, since the material attributes will usually suffice to describe and identify the product for the order. The Access role is used to communicate about the maintenance, intake/outflow, and due replacement of tubes and drains.
type = & {
?: CD,
?: CD,
?: PQ
}

Account

Definition
A set of financial transactions that are tracked and reported together with a single balance.
Usage notes
Account can be used to represent the accumulated total of billable amounts for goods or services received, payments made for goods or services, and debit and credit accounts between which financial transactions flow.
type = & {
?: MO,
?: CD,
?: RTO,
?: IVL
}

Acknowledgement

Definition
Metadata necessary when acknowledging a message.
type = & {
: CS,
?: INT.POS,
?: INT.NONNEG,
?: CD,
?: [],
: ,
:
}

AcknowledgementDetail

Definition
A message that provides information about the communication, parsing or formal (non-business-rule) validation of the message being acknowledged.
type = & {
: CS,
?: CD,
?: ED,
?: DSET[],
:
}

Act

Definition
A record of something that is being done, has been done, can be done, or is intended or requested to be done.
Usage notes
Acts connect to Entities in their Roles through Participations, and they connect to other Acts through ActRelationships. Participations indicate the performers, authors, and other responsible parties as well as subjects and beneficiaries (including tools and material used in the performance of the act, which are also subjects). The moodCode distinguishes among Acts that are meant as factual records, records of intended or ordered services, and other modalities in which acts can be recorded.
Rationale
Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.
An Act-instance represents a "statement," according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.]
An activity in the real world may progress from definition, through planning and ordering to execution: these stages are represented as the moods of the Act. Even though one might think of a single activity as progressing through these stages, the "attributable statement" model of Act entails that this progression be reflected by multiple Act-instances, each having one and only one mood, and that this mood not change during the Act-instance's life cycle. This is because the attribution and content of speech acts along this progression of an activity may be different, and it is critical that a permanent and faithful record be maintained of this progression. The specification of orders or promises or plans must not be overwritten by the specification of what was actually done, so as to allow recipients of the information to compare actions with their earlier specifications. Act-instances that describe this progression of the same real world activity are linked through the ActRelationships (of the relationship category "sequel").
Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the combination (and arbitration) of such attributed statements only, and there is no class in the RIM whose objects represent "objective state of affairs" or "real processes" independent from attributed statements. A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.
type = & {
: CS,
: CS,
?: DSET[],
?: CD,
?: BL,
?: BL,
?: ST.SIMPLE,
?: ED,
?: ED,
?: CS,
?: QSET,
?: QSET,
?: TS,
?: DSET[],
?: CD,
?: IVL,
?: BL,
?: CD,
?: BL,
?: CD,
?: DSET[],
?: CD,
?: BL,
?: [],
?: [],
?: []
}

ActHeir

Definition
A subtype of Act defined solely as a work-around for the lack of support of the reflexive closure of generalization relationships (i.e. "Act is-a Act") by the current set of tools.
Usage notes
Although it is used to represent Acts that are not otherwise sub-classed in the RIM, the use of the ActHeir class is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and it has no conceptual meaning or semantic modeling implications. Note that EntityHeir and RoleHeir have the same use for Entity and Role respectively.
Rationale
It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
type =

ActRelationship

Definition
A directed association between a source Act and a target Act.
Usage notes
The ActRelationship class is used to construct systems of acts to represent complex observations, action plans, and to represent clinical reasoning or judgments about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be linked with current clinical hypotheses. Problem lists and other networks of related judgments about clinical events are represented by the ActRelationship link.
Every ActRelationship instance is like an arrow with a point (headed to the target) and a butt (coming from the source). The functions that source and target Acts play in that association are defined for each ActRelationship type differently. For instance, in a composition relationship, the source is the composite and the targets are the components. In a reason-relationship the source is any Act and the target is the reason or indication for the source-Act.
The relationships associated with an Act are considered properties of the source act object. This means that the author of an Act-instance is also considered the author of all of the act relationships that have this Act as their source, (though not necessarily of the target Acts of those relationships). There are no exceptions to this rule.
The meaning and purpose of an ActRelationship is specified in the ActRelationship.typeCode attribute.
type = & {
: CS,
?: BL,
?: DSET[],
?: DSET[],
?: BN,
?: CS,
?: BL,
?: INT.NONNEG,
?: REAL,
?: PQ.TIME,
?: CS,
?: CS,
?: CS,
?: BL,
?: CS,
?: ST.SIMPLE,
?: BL,
?: CS,
?: CD,
: ,
:
}

Attachment

Definition
An addressable data block which can be referred to from the interior of the message.
Usage notes
Attachments are referred to from the message body using the reference functionality of the ED data type.
Design comments
Open issue requires more detail.
type = & {
?: II,
?: ED,
?:
}

AttentionLine

Definition
A collection of parameters related to a transmission that may need to be accessible from the transmission wrapper.
Usage notes
AttentionLine is a name-value pair, with keyWordText providing the topic from an enumerated set and value providing the parameter.
Design comments
Confirm edits. Clarify in definition, add to examples.
type = & {
?: SC.NT,
?: ANY[],
:
}

Batch

Definition
A message which is a collection of HL7 V3 messages.
Design comments
Does the batch have any effect on the member message, or is it a composition class that contains the member messages?
type = & {
?: II,
?: SC.NT,
?: DSET[],
?: INT.NONNEG,
?: DSET[],
?: CD,
?: []
}

CommunicationFunction

Definition
A relationship class that binds the various entities participating in the transmission (sender, receiver, respond-to) to be linked to the transmission.
type = & {
: CS,
?: TEL,
: [],
: []
}

Container

Definition
An Entity that holds other Entities.
Usage notes
Content material is related to a Container through Role.classCode = CONT (content).
Rationale
The specifications for this class arose from the collaboration between HL7 and the NCCLS. Many of the attribute definitions are drawn from or make reference to the NCCLS standard. With amorphic substances (e.g., liquids and gases), a container is required. However, the content of a container is always distinguishable and relatively easily separable from the container, unlike the content (ingredient) of a mixture.
type = & {
?: PQ,
?: PQ,
?: PQ,
?: CD,
?: CD,
?: PQ,
?: PQ
}

ContextStructure

Definition
A a container within a document.
Usage notes
Structures have captions which can be coded. Structures can nest, and structures can contain entries.
An original document is the first version of a document. It gets a new unique value for , and has the value of set to equal "1."
An addendum is an appendage to an existing document that contains supplemental information. The appendage is itself an original document. The parent document being appended is referenced via an , with set to equal "APND" (for "appends"). The parent report being appended remains in place and its content and status are unaltered.
A replacement document replaces an existing document. The replacement document uses the same value for as the parent document being replaced, and increments the value of by 1. The parent document being replaced is referenced via an ActRelationship, with ActRelationship.typeCode set to equal "RPLC" (for "replace"). The state of the parent document being replaced should become "obsolete" but is still retained in the system for historical reference.
It is also permissible for an implementation to maintain a set of documents, with a common setId value and version numbers, without the requirement that only the latest be in an "active" state if the Implementation Guide so specifies.
type = & {
?: II,
?: ST
}

ControlAct

Definition
An act representing a change to the state of another class, a user event (e.g. query), or a system event (e.g. time-based occurrences).
Usage notes
This class corresponds to the concept of 'Trigger Event', and as such, must be present as the focus of every messaging interaction (because of the 1..1 association between a trigger event and an interaction.) However, control acts can also appear within a message payload. For example, a set of control acts associated with a Lab Order identifying the events that have occurred against that order (first created, then revised, then suspended, then resumed, then completed.)
type = & {
?: ,
?:
}

Device

Definition
A ManufacturedMaterial used in an activity without being substantially changed through that activity.
Usage notes
This includes durable (reusable) medical equipment as well as disposable equipment. The kind of device is identified by the code attribute inherited from Entity.
type = & {
?: SC,
?: SC,
?: CD,
?: CD,
?: TS
}

DeviceTask

Definition
An activity of an automated system.
Usage notes
Device tasks are either invoked by an outside command or scheduled and executed spontaneously by the device (e.g., regular calibration or flushing). The command to execute the task has moodCode <= RQO; an executed task (including a task in progress) has moodCode <= EVN; and an automatic task on the schedule has moodCode <= APT.
type = & {
?: LIST[]
}

DiagnosticImage

Definition
An observation in the form of a spatial representational of a physical subject suitable for visual presentation.
Design comments
Definition rewritten to exclude apparently extraneous concepts.
type = & {
?: CD
}

Diet

Definition
A supply Act dealing specifically with the feeding or nourishment of a subject.
Usage notes
The detail of the diet is given as a description of the Material associated via Participation.typeCode="product". Medically relevant diet types may be communicated in Diet.code, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances.
Design comments
The introduction should stipulate how to document usage of or constraints on attributes from the generalization-e.g. Diet.code.
type = & {
?: PQ,
?: PQ
}

Document

Definition
A specialization of Act that supports the characteristics unique to document management services.
type = & {
?: CD,
?: CD,
?: TS,
?: DSET[]
}

Employee

Definition
A role played by a person who is associated with an organization to receive wages or salary.
Usage notes
The employing organization is the scoper. The purpose of the role is to identify the type of relationship the employee has to the employer rather than the nature of the work actually performed (contrast with AssignedEntity).
type = & {
?: CD,
?: SC,
?: CD,
?: CD,
?: CD,
?: MO,
?: ED,
?: ED
}

Entity

Definition
A physical thing, group of physical things or an organization capable of participating in Acts while in a role.
Usage notes
An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. Entity stipulates the thing itself, not the Roles it may play: the Role of Patient, e.g., is played by the Person Entity.
type = & {
: CS,
: CS,
?: DSET[],
?: CD,
?: PQ,
?: COLL[],
?: ED,
?: CS,
?: IVL,
?: COLL[],
?: DSET[],
?: DSET[],
?: [],
?: [],
?: [],
?: []
}

EntityHeir

Definition
A subtype of Entity defined solely as a work-around for the lack of support of the reflexive closure of generalization relationships (i.e. "Entity is-an Entity") by the current set of tools.
Usage notes
Although it is used to represent Entities that are not otherwise sub-classed in the RIM, the use of the EntityHeir class is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and it has no conceptual meaning or semantic modeling implications. Note that ActHeir and RoleHeir have the same use for Act and Role respectively.
Rationale
It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
type =

Exposure

Definition
An interaction between entities that provides opportunity for transmission of a physical, chemical, or biological agent from an exposure source entity to an exposure target entity.
Usage notes
This class deals only with opportunity and not the outcome of the exposure; i.e. not all exposed parties will necessarily experience actual harm or benefit.
Exposure differs from Substance Administration by the absence of the participation of a performer in the act.
The following participations SHOULD be used with the following participations to distinguish the specific entities:
The Exposure.statusCode attribute should be interpreted as the state of the Exposure business object (e.g., active, aborted, completed) and not the clinical status of the exposure (e.g., probable, confirmed). The clinical status of the exposure should be associated with the exposure via a subject observation.
Design comments
The usage notes require a clear criterion for determining whether an act is an exposure or substance administration-deleterious potential, uncertainty of actual transmission, or otherwise. SBADM states that the criterion is the presence of a performer-but there are examples above that call this criterion into question (e.g., the first one, concerning a dosing error).
type = & {
?: CD,
?: CD,
?: CD
}

FinancialContract

Definition
A contract whose value is measured in monetary terms.
type = & {
?: CD
}

FinancialTransaction

Definition
An Act representing the movement of a monetary amount between two accounts.
Usage notes
Financial transactions always occur between two accounts (debit and credit), but there may be circumstances where one or both accounts are implied or inherited from the containing model. In the "order" mood, this represents a request for a transaction to be initiated. In the "event" mood, this represents the posting of a transaction to an account.
type = & {
?: MO,
?: REAL,
?: REAL
}

InfrastructureRoot

Definition
An abstract super-type for all RIM classes, either directly or through inheritance.
Usage notes
Infrastructure Root provides a set of communication infrastructure attributes that may be used in instances of HL7-specified, RIM-based communications. When valued in a communication instance, these attributes indicate whether the information structure is being constrained by specifically defined templates, realms or common communication element types.
type = {
?: CS,
?: DSET[],
?: II,
?: LIST[]
}

InvoiceElement

Definition
A statement and explanation of an amount owed.
Usage notes
This represents the 'justification' portion of an invoice. It is frequently combined with a financial transaction representing the amount requested to be paid, agreed to be paid, or actually paid. A recursive relationship can be used to break a single InvoiceElement into its constituent elements. In definition mood, it represents possible justification for future billing. In request mood, it is a request to determine the amount owed. In event mood, this class represents the determination of a specific amount owed by a particular Entity.
type = & {
?: DSET[],
?: RTO,
?: RTO,
?: MO,
?: REAL,
?: REAL
}

LanguageCommunication

Definition
The language communication capabilities of an Entity.
Usage notes
While it may seem on the surface that this class would be restricted in usage to only the LivingSubject subtypes, Devices also have the ability to communicate, such as automated telephony devices that transmit patient information to live operators on a triage line or provide automated laboratory results to clinicians.
type = & {
?: CD,
?: CD,
?: CD,
?: BL,
:
}

LicensedEntity

Definition
An Entity that is accredited with a license or qualification certifying the capability to perform specific functions.
Usage notes
Usage Notes: The player is the qualified entity; the scoper is the Organization that issues the credential. LicensedEntity is a subset of QualifiedEntity.
type = & {
?: TS
}

LivingSubject

Definition
An organism, alive or not.
Rationale
This class contains administrative attributes of interest to medicine that differentiate living organisms from other Entities.
type = & {
?: CD,
?: TS,
?: BL,
?: TS,
?: BL,
?: INT.POS,
?: BL
}

ManagedParticipation

Definition
A participation that will be operated on over time and thus whose state and identity must be managed.
Rationale
ManagedParticipations are defined as a subclass of Participations because not all Participations are stateful. In general, when the sub-activity realized by a Participation is of closer interest and needs to be managed, one SHOULD instead model that sub-activity as an Act component of the main Act.
However, in certain environments, the activities that the participants perform is not very well understood, and hence modeling those as sub-acts is deemed burdensome, and it may imply an unmerited depth of knowledge or certainty.
Therefore, the ManagedParticipation extends Participation with an identity-attribute and a state-attribute to support these exceptional use cases. ManagedParticipations should be used with utmost caution so as to avoid confusion with Acts and to avoid having to duplicate the act-management infrastructure around participations.
type = & {
?: DSET[],
?: CS
}

ManufacturedMaterial

Definition
An Entity or combination of Entities transformed for a particular purpose by a manufacturing process.
Usage notes
This class encompasses containers, devices, software modules and facilities. It is used to further define the characteristics of Entities that are created out of other Entities. These entities are identified and tracked through associations and mechanisms unique to the class, such as lotName, stabilityTime and expirationTime.
type = & {
?: ST.SIMPLE,
?: IVL,
?: IVL
}

Material

Definition
A subtype of Entity that is inanimate and locationally independent.
Usage notes
Materials are entities that are neither Living Subjects nor places. Manufactured or processed products are considered material, even if they originate as living matter. Materials come in a wide variety of physical forms and can pass through different states (ie. Gas, liquid, solid) while still retaining their physical composition and material characteristics.
Design comments
Clarify the meaning of "locationally independent"; suggest removing it and supplanting with first Usage Note sentence.
type = & {
?: CD
}

Message

Definition
The parent class of all HL7 Version 3 messages.
Design comments
This may be the parent class, but that's not what makes it a message. What are the criteria for deciding whether something should be modeled as a message?
type = & {
?: CS,
?: CS,
?: CS,
?: CS,
?: INT.NONNEG,
?: DSET[],
?: []
}

NonPersonLivingSubject

Definition
A subtype of LivingSubject that includes all living things except the species homo sapiens.
Rationale
Living organisms may require additional characterizing information, such as genetic strain identification, that cannot be conveyed in the Entity.code.
type = & {
?: ED,
?: CD
}

Observation

Definition
An act that is intended to result in new information about a subject.
Usage notes
The main difference between Observations and other Acts is that Observations have a value attribute. The attribute of Observation and the attribute of Observation must be considered in combination to determine the semantics of the observation.
Structurally, many observations are name-value-pairs, where the Observation.code (inherited from Act) is the name and the Observation.value is the value of the property. Such a construct is also known as a "variable" (a named feature that can assume a value); hence, the Observation class is always used to hold generic name-value-pairs or variables, even though the variable valuation may not be the result of an elaborate observation method. It may be a simple answer to a question or it may be an assertion or setting of a parameter.
As with all Act statements, Observation statements describe what was done, and in the case of Observations, this includes a description of what was actually observed ("results" or "answers"); and those "results" or "answers" are part of the observation and not split off into other objects.
The method of action is asserted by the Observation classCode or its subclasses at the least granular level, by the Observation.code attribute value at the medium level of granularity, and by the attribute value of observation.methodCode when a finer level of granularity is required. The method in whole or in part may also appear in the attribute value of Observation.value when using coded data types to express the value of the attribute. Relevant aspects of methodology may also be restated in value when the results themselves entail a methodology.
An observation may consist of component observations each having their own Observation.code and Observation.value. In this case, the composite observation may not have an Observation.value for itself. For instance, a white blood cell count consists of the sub-observations for the counts of the various granulocytes, lymphocytes and other normal or abnormal blood cells (e.g., blasts). The overall white blood cell count Observation itself may therefore not have a value by itself (even though it could have one, e.g., the sum total of white blood cells). Thus, as long as an Act is essentially an Act of recognizing and noting information about a subject, it is an Observation, regardless of whether it has a simple value by itself or whether it has sub-observations.
Even though observations are professional acts (see Act) and as such are intentional actions, this does not require that every possible outcome of an observation be pondered in advance of it being actually made. For instance, differential white blood cell counts (WBC) rarely show blasts, but if they do, this is part of the WBC observation even though blasts might not be predefined in the structure of a normal WBC.
Clinical documents commonly have 'Subjective' and 'Objective' findings, both of which are kinds of Observations. In addition, clinical documents commonly contain 'Assessments,' which are also kinds of Observations. Thus, the establishment of a diagnosis is an Observation.
Design comments
The usage notes need to address observations that do not follow the name-value semantic paradigm, e.g., those identifying pathologies.
type = & {
?: ANY[],
?: BL,
?: DSET[],
?: DSET[],
?: DSET[]
}

Organization

Definition
An Entity representing a formalized group of persons or other organizations with a common purpose and the infrastructure to carry out that purpose.
type = & {
?: COLL[],
?: CD
}

Parameter

Definition
A uniquely identifiable value or set of values to be used as a query criterion.
Design comments
Confirm value as synonym for parameter.
type = & {
?: II,
?: ,
?:
}

ParameterItem

Definition
A valued element structure (name-value pair) for an element specified in a query.
Usage notes
The use of multiple parameterItem classes should be defined as an AND, OR, or XOR in the descriptive model documentation, based on what the modeler intends. The use of a SET<XX> data type in a parameter indicates an OR-type construct: the query results have to match at least one of the XX's.
type = & {
?: ANY[],
: SC.NT
}

ParameterList

Definition
A named list of parameters.
type = & {
?: []
}

Participation

Definition
An association between an Act and a Role. The Entity playing the Role is the actor.
Usage notes
Each Entity involved in an Act is linked to the Act by one Participation-instance. The kind of involvement in the Act is specified by the Participation.typeCode.
The Entity's Role interposes between the Entity and the Participation. While Roles represent the competence of an Entity, Participations represent performance, so a Participation is scoped by its specific Act, and only incidentally by its Entity. Conversely, Roles describe an innate quality of an Entity (i.e., how it may principally participate in acts), irrespective of any individual Act.
The professional credentials of a person (Role) may be quite different from what a person actually does (Participation). A common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists: the role of intern does not specify the nature of the participation.
An Act can have multiple participations of the same type: this indicates collaborative activities or group involvement. The notion of multiple performing Participations MAY also be represented as sub-activities (Act components): the presence of multiple actors MAY be represented as an act composed of sub-acts where each act has only one performing actor, or as a single act with many participations.
For example, a record of a surgical service may include the actors of type (a) consenter, (b) primary surgeon, and (c) anesthetist, and these three Roles might have separate Participation relationships to the surgery. Alternatively, these three actors really perform different tasks, which can be represented as three related acts: (a) the consent, (b) the surgery proper, and (c) the anesthesia act in parallel to the surgery. If we used the sub-acts, the consenter, surgeon and anesthetist could simply be of actor type "performer." Thus the more sub-acts we use, the fewer different actor types we need to distinguish; conversely, the fewer sub-acts we use, the more distinct actor types (and Participation instances) we need.
As a rule of thumb, sub-tasks should be preferred to multiple actors when the sub-tasks require special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In many cases, however, this detail is not urgent enough to support its collection: human resources are scheduled in teams (rather than as individuals), billing tends to lump sub-tasks together, and overall responsibility often rests with an attending physician, chief nurse, or head of department. While the ActRelationship class supports detailed decomposition, the Participation class supports multi-actor "lumping" of sub-activities into a primary act.
type = & {
: CS,
?: CD,
?: CS,
?: INT.NONNEG,
?: INT.POS,
?: BL,
?: ED,
?: IVL,
?: CD,
?: CD,
?: CD,
?: ED,
?: BL,
?: CD,
?: CS,
?: PQ,
: ,
:
}

Patient

Definition
A LivingSubject as a recipient of health care services from a healthcare provider.
Usage notes
The patient is the player; the provider is the scoper.
type = & {
?: CD
}

PatientEncounter

Definition
An interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s).
Usage notes
Healthcare services include health assessment.
type = & {
?: CD,
?: PQ.TIME,
?: CD,
?: BL,
?: DSET[],
?: DSET[]
}

Person

Definition
A human being.
Usage notes
This class can be used to represent either a single individual, a group of individuals or a kind of individual based on the values of Entity.determinerCode and Entity.quantity.
type = & {
?: COLL[],
?: CD,
?: CD,
?: DSET[],
?: CD,
?: CD,
?: DSET[],
?: DSET[]
}

Place

Definition
A bounded physical place or site, including any contained structures.
Usage notes
Place may be natural or man-made. The geographic position of a place may or may not be constant. Places may be work facilities (where relevant acts occur), homes (where people live) or offices (where people work). Places may contain sub-places (floor, room, booth, bed). Places may also be sites that are investigated in the context of health care, social work, public health administration (e.g., buildings, picnic grounds, day care centers, prisons, counties, states, and other focuses of epidemiological events).
type = & {
?: BL,
?: AD,
?: ED,
?: ED,
?: ST.SIMPLE
}

Procedure

Definition
An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject.
Usage notes
Applied to clinical medicine, procedure is but one among several types of clinical activities such as observation, substance-administrations, and communicative interactions (e.g. teaching, advice, psychotherapy, represented simply as Acts without special attributes). Procedure does not subsume those other activities nor is Procedure subsumed by them. Notably Procedure does not comprise all Acts of whose intent is intervention or treatment. Whether the bodily alteration is appreciated or intended as beneficial to the subject is likewise irrelevant: what counts is that the Act is essentially an alteration of the physical condition of the subject.
The choice between Procedure and other representations of real activities is based on whether the activity or activity step's necessary post-condition is the physical alteration. For example, taking an x-ray image may sometimes be called "procedure," but it is not a Procedure in the RIM sense, for an x-ray image is not done to alter the physical condition of the body.
Many clinical activities combine Acts of Observation and Procedure nature into one composite. For instance, interventional radiology (e.g., catheter directed thrombolysis) does both observing and treating, and most surgical procedures include conscious and documented Observation steps. These clinical activities therefore are best represented by multiple component Acts, each of the appropriate type.
type = & {
?: DSET[],
?: DSET[],
?: DSET[]
}

PublicHealthCase

Definition
An Observation representing a condition or event, or a set of conditions or events, that has a specific significance for a population or community of persons.
Usage notes
The public health case typically involves an instance or instances of a reportable infectious disease or other condition. It can include a health-related event concerning a single individual, or it may refer to multiple health-related events that are occurrences of the same disease or condition of interest to public health. A public health case definition (Act.moodCode = "definition") includes the description of the clinical, laboratory, and epidemiologic indicators associated with a disease or condition of interest to public health. There are case definitions for conditions that are reportable, as well as for those that are not. There are also case definitions for outbreaks. A public health case definition is a construct used by public health for the purpose of counting cases, and should not be used as clinical indications for treatment.
type = & {
?: CD,
?: CD,
?: CD
}

QualifiedEntity

Definition
An entity that has been recognized as having certain training, experience or other characteristics that would make the entity an appropriate performer for a certain activity.
Usage notes
The qualified entity is the player; the scoper is an organization that educates or qualifies entities. QualifiedEntity is a superset of LicensedEntity.
type = & {
?: BL
}

QueryAck

Definition
A response to a query.
type = & {
?: CS,
?: INT.NONNEG,
?: INT.NONNEG,
?: INT.NONNEG,
?: ST.SIMPLE
}

QueryByParameter

Definition
An HL7 query format proposed to replace the QRD/QRF query format.
Usage notes
The query format is considered a closed query because a data server specifies a fixed list of parameters published in a query conformance statement.
Design comments
The query definitions do not clearly distinguish the Query by Parameter from Query by Selection, and the Query Infrastructure document does not address QueryBySelection. These require clarification or deprecation. This class is abstract, and has no proper attributes (apart from those of its generalizations and specializations).
type = & {
?: []
}

QueryContinuation

Definition
A request for further data.
Usage notes
This class maintains the requestor's state information required at the application level to control the logical continuation of a query response.
type = & {
?: INT.POS,
?: INT.NONNEG,
?: ST.SIMPLE
}

QueryEvent

Definition
An abstract class that generalizes all query message interactions.
Usage notes
See Query Infrastructure under the Specification Infrastructure, Messaging chapter for a description of how RIM query capabilities are designed to operate.
Design comments
Purpose of rationale not clear; removed.
Definitions are shared with document; synchronize changes.
type = & {
?: II,
?: CS,
:
}

QuerySpec

Definition
The criteria and response expectations to be applied in the query.
type = & {
?: CS,
?: DSET[],
?: CS,
?: CS,
?: INT.POS,
?: CD,
?: TS,
?: []
}

Role

Definition
A competency of the Entity that plays the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role.
Usage notes
An Entity participates in an Act in the guise of a particular Role. Note that a particular entity in a particular role can participate in an act in different ways. Thus, a Person in the role of a practitioner can participate in a patient encounter as a rounding physician or as an attending physician. The Role defines the competency of the Entity irrespective of any Act, unlike Participations, which are limited to the scope of an Act.
Each role is "played" by one Entity, called the "player" and is "scoped" by another Entity, called the "scoper". Thus the Role of "patient" may be played by a person and scoped by the provider organization from which the patient will receive services. Similarly, the employer scopes the "employee" role.
The identifier of the Role identifies the Entity playing the role in that role. This identifier is assigned by the scoper to the player. The scoper NEED NOT have issued the identifier, but MAY have re-used an existing identifier.
Most attributes of Role are attributes of the playing entity while in the particular role.
type = & {
: CS,
?: DSET[],
?: CD,
?: BL,
?: COLL[],
?: COLL[],
?: COLL[],
?: CS,
?: QSET,
?: ED[],
?: CD,
?: RTO,
?: INT.POS,
?: LIST[],
?: ,
?: ,
?: [],
?: [],
?: []
}

RoleHeir

Definition
A subtype of Role defined solely as a work-around for the lack of support of the reflexive closure of generalization relationships (i.e. "Role is-a Role") by the current set of tools.
Usage notes
Although it is used to represent Roles that are not otherwise sub-classed in the RIM, the use of the RoleHeir class is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and it has no conceptual meaning or semantic modeling implications. Note that EntityHeir and ActHeir have the same use for Entity and Act respectively.
Rationale
It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
type =

RoleLink

Definition
A connection between two roles expressing a dependency between those roles and permitting the authorization or nullification of a dependent role based on status changes in its causal or directing role. The RoleLink may be operated over time and thus whose state and identity must be managed.
Usage notes
RoleLink specifies the relationships between roles, not between people (or other entities). People (or other Entities) are primarily related by the player/scoper relationships for player's Role and more generally through their interactions (i.e. their participations in acts).
The use of the ID and statusCode attributes should be used only in those circumstances where it is of importance to manage the RoleLink over time, i.e. in Role based registries. These attributes should not be used in general.
type = & {
: CS,
?: DSET[],
?: CS,
?: INT.NONNEG,
?: IVL,
: ,
:
}

SortControl

Definition
The sort order for instance matches to a query.
OpenIssue: Harmonization review of the Sequencing concept domain revealed that there seem to be elements missing from this class for it to be specify a complete sort control. One such element is whether the sort should be case sensitive or not.
type = & {
?: INT.NONNEG,
?: SC.NT,
?: CS,
:
}

SubstanceAdministration

Definition
A type of procedure that involves a performer introducing or otherwise applying a material into or to the subject.
Usage notes
Substance administration is distinguished from an exposure by the participation of a performer in the act.
The substance administered by a performer physically interacts with the subject or is otherwise "taken in" by the subject during the act of administration.
Detailed information about the supplied substance is represented using the entity class or one of its subtypes.
The performer of a substance administration may be another entity such as a person, device, plant, e.g. poison ivy, animal, e.g. mosquito bite, or it may be the same entity as the subject, as in self-administration.
For purposes of this definition, photons and other models of radiation or light energy are considered substances.
Substances may also include living entities such as live virus vaccines and other materials containing infectious agents, e.g. saliva, blood products, etc. (Note: if the infectious agent is the subject of the substance administration, then the infectious agent is modeled as a "Living Subject.")
In the intent moods, substance administration represents the plan to apply a given material. This includes (but is not limited to) prescriptions in which it might also be associated with a request for supply.
In event mood, substance administration represents a record of the actual application of a substance.
type = & {
?: CD,
?: PQ,
?: PQ,
?: DSET[],
?: DSET[],
?: CD
}

Supply

Definition
Provision of a material by one entity to another.
Usage notes
The product is associated with the Supply Act via Participation.typeCode="product". Generally, with Supply Acts, the precise identification of the Material (manufacturer, serial numbers, etc.) is important. Most of the detailed information about the Supply should be represented using the Material class. If delivery needs to be scheduled, tracked, and billed separately, one can associate a Transportation Act with the Supply Act. Pharmacy dispense services are represented as Supply Acts, associated with a SubstanceAdministration Act. The SubstanceAdministration class represents the administration of medication, while dispensing is Supply.
type = & {
?: PQ,
?: IVL
}

Transmission

Definition
Information about a specific transmission of information from one application to another.
type = & {
?: II,
?: TS,
?: ST.SIMPLE,
?: CS,
?: CS,
?: II,
?: LIST[],
?: [],
?: [],
?: [],
?: ,
?: [],
?: [],
?: [],
?: []
}

TransmissionRelationship

Definition
A directed association between a source Transmission and a target Transmission.
Usage notes
TransmissionRelationships on the same source Transmission are called the "outbound" transmission relationships of that Transmission. TransmissionRelationships on the same target Transmission are called the "inbound" relationships of that Transmission. The meaning and purpose of a TransmissionRelationship is specified in the TransmissionRelationship.typeCode attribute.
The initial implementation envisages a single type.
type = & {
: CS,
: ,
:
}

See also

Made by Anton Vasetenkov.