]> 0.1 (30.05.2010 21:51:33) A record of something that is being done, has been done, can be done, or is intended or requested to be done. Examples: The kinds of acts that are common in health care are (1) a clinical observation, (2) an assessment of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) and notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others. Discussion and Rationale: Acts are the pivot of the RIM; all domain information and processes 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.Acts connect to Entities in their Roles through Participations and connect to other Acts through ActRelationships. Participations are the authors, performers and other responsible parties as well as subjects and beneficiaries (which includes tools and material used in the performance of the act, which are also subjects). The moodCode distinguishes between Acts that are meant as factual records, vs. records of intended or ordered services, and the other modalities in which act can appear.One of the Participations that all acts have (at least implicitly) is a primary author, who is responsible of the Act and who "owns" the act. Responsibility for the act means responsibility for what is being stated in the Act and as what it is stated. Ownership of the act is assumed in the sense of who may operationally modify the same act. Ownership and responsibility of the Act is not the same as ownership or responsibility of what the Act-object refers to in the real world. The same real world activity can be described by two people, each being the author of their Act, describing the same real world activity. Yet one can be a witness while the other can be a principal performer. The performer has responsibilities for the physical actions; the witness only has responsibility for making a true statement to the best of his or her ability. The two Act-instances may even disagree, but because each is properly attributed to its author, such disagreements can exist side by side and left to arbitration by a recipient of these Act-instances.In this sense, an Act-instance represents a "statement" according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.] Rector and Nowlan have emphasized the importance of understanding the medical record not as a collection of facts, but "a faithful record of what clinicians have heard, seen, thought, and done." Rector and Nowlan go on saying that "the other requirements for a medical record, e.g., that it be attributable and permanent, follow naturally from this view." Indeed the Act class is this attributable statement, and the rules of updating acts (discussed in the state-transition model, see Act.statusCode) versus generating new Act-instances are designed according to this principle of permanent attributable statements.Rector and Nolan focus on the electronic medical record as a collection of statements, while attributed statements, these are still mostly factual statements. However, the Act class goes beyond this limitation to attributed factual statements, representing what is known as "speech-acts" in linguistics and philosophy. The notion of speech-act includes that there is pragmatic meaning in language utterances, aside from just factual statements; and that these utterances interact with the real world to change the state of affairs, even directly cause physical activities to happen. For example, an order is a speech act that (provided it is issued adequately) will cause the ordered action to be physically performed. The speech act theory has culminated in the seminal work by Austin (1962) [How to do things with words. Oxford University Press].An activity in the real world may progress from defined, through planned and ordered to executed, which is represented as the mood of the Act. Even though one might think of a single activity as progressing from planned to executed, this progression is reflected by multiple Act-instances, each having one and only one mood that will not change along 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 often 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 comparing 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").Act as statements or speech-acts are the only representation of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through a 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. As such, there is no distinction between an activity and its documentation. Every Act includes both to varying degrees. For example, a factual statement made about recent (but past) activities, authored (and signed) by the performer of such activities, is commonly known as a procedure report or original documentation (e.g., surgical procedure report, clinic note etc.). Conversely, a status update on an activity that is presently in progress, authored by the performer (or a close observer) is considered to capture that activity (and is later superceded by a full procedure report). However, both status update and procedure report are acts of the same kind, only distinguished by mood and state (see statusCode) and completeness of the information. 1 1 1 1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0 1 0 1 0 1 0 1 0 1 0 0 1 SET<II> SET<CE> SET<CE> IVL<INT> SET<CE> A directed association between a source Act and a target Act. ActRelationship on the same source Act are called the "outbound" act relationships of that Act. ActRelationships on the same target Act are called the "inbound" relationships of that Act. The meaning and purpose of an ActRelationship is specified in the ActRelationship.typeCode attribute. Examples: 1) An electrolyte observation panel may have sodium, potassium, pH, and bicarbonate observations as components. The composite electrolyte panel would then have 4 outbound ActRelationships of type "has component".2) The electrolyte panel event has been performed in fulfillment of an observation order. The electrolyte panel event has an outbound ActRelationship of type "fulfills" with the order as target.3) A Procedure "cholecystectomy" may be performed for the reason of an Observation of "cholelithiasis". The procedure has an outbound ActRelationship of type "has reason" to the cholelithiasis observation. Discussion: Consider every ActRelationship instance an arrow with a point (headed to the target) and a butt (coming from the source). The functions (sometimes called "roles") 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 target is the component. 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. There are no exceptions to this rule.See ActRelationship.typeCode for more overview of the different kinds of ActRelationships.The ActRelationship class is used to construct 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.One of the most commonly used ActRelationship types is "has component" to describe the composition and de-composition of Acts. The relationship type allows specifying detail of Acts to varying degrees.The composition relationship can group actions into "batteries," e.g., LYTES, CHEM12, or CBC, where multiple routine laboratory tests are ordered as a group. Some groupings, such as CHEM12, appear more arbitrary; others, such as blood pressure, seem to naturally consist of systolic and diastolic pressure.The composition relationships can be arranged in a sequence to form temporal and conditional (non-temporal) action plans (e.g., care plan, critical path, clinical trials protocol, drug treatment protocols). There is a group of attributes in both Act and ActRelationship that we refer to as the "workflow Control suite of attributes", and which allow the detailed specification of executable action plans. These attributes are:ActRelationship.sequenceNumber arranges the components of an Act as a sequence or as concurrent collections of components, expressing logical branches as well as parallel tasks (tasks carried out at the same time). The ActRelationship attributes splitCode and joinCode control how branches are selected or executable in parallel.Act.activityTime and ActRelationship.pauseQty allow one to explicitly time an action plan. Act.repeatNumber allows specifying act to repeat (loop).The ActRelationship type has-precondition allows plan steps to be conditional on the status or outcome of previous actions. The ActRelationhsip.checkpointCode specifies when pre-conditions of acts are tested during the flow of control.The composition ActRelationship allows these constructs to be organized in multiple layers of nesting to fully support workflow management. This nesting and the workflow control attributes are designed in analogy to a block-structured programming language with support for concurrency (fork, join, interrupts), and without "goto" statements. It is important to note that ALL plans are established through sequencing components (steps) in a composite act (block) as can be depicted in "Nassi-Schneiderman" diagrams (also known as "Chap Charts" or "Structograms"), not by chain-linking acts as in a flowchart diagram. With the composition relationship, the detail of Acts can be revealed to different levels for different purposes, without the structure of the Act hierarchy needing to be rearranged. This allows supporting multiple viewpoints on the same business processes. For instance, a billing-viewpoint of a laboratory test battery may be as a single billable act. A clinician's view of the same laboratory test battery is as a set of individual observations, where the ordering among the observations is irrelevant. The laboratory's view of this act will be more detailed, including action plan steps that are never reported to the clinician (e.g., centrifugation, decantation, aliquoting, running certain machines etc.). The laboratory's viewpoint warrants a thorough specification of action plans (that can be automated). During this specification, more and more nested sub-activities will be defined. Still the Act is the same, with varying degrees of detail uncovered in the de-composition relationship. We described the nature of varying detail saying that Acts are "fractal", ever more decomposable, just as the movements of a robotic arm can be decomposed in many fine control steps. 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 An association between an Act and a Role with an Entity playing that Role. Each Entity (in a Role) involved in an Act in a certain way is linked to the act by one Participation-instance. The kind of involvement in the Act is specified by the Participation.typeCode. Examples: 1) Performers of acts (surgeons, observers, practitioners).2) Subjects of acts, patient, devices3) Locations4) Author, co-signer, witness, informant5) Addressee, information recipient Rationale: Participations represent performance while Roles represent competence. Participations specify the actual performance of an Entity in a certain Act, and thus a Participation is scoped by its specific Act. Conversely, Roles specify the competence of an Entity (i.e., how it may principally participate in what kinds of acts) irrespective of any individual Act.For example, 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. An Act can have multiple participations of the same type, which indicates collaborative activities or group involvement. The notion of multiple performing Participations partially overlaps with sub-activities (Act components). Whenever multiple actors are involved in an act, each actor performs a different task (with the extremely rare exception of such symmetrical activities as two people pulling a rope from either end). Thus, the presence of multiple actors could be equally well represented as an act consisting of sub-acts where each act would have only one performing actor For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthetist. 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 we need.As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In most cases, however, human resources are scheduled by teams (instead of individuals), billing tends to lump many sub-tasks together into one position, and overall responsibility often rests with one attending physician, chief nurse, or head of department. This model allows both the multi-actor and the multi-act approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall act. 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 IVL<TS> An Act representing a category of financial transactions that are tracked and reported together with a single balance. Discussion: This 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. Examples: Patient accounts; Encounter accounts; Cost centers; Accounts receivable 0 1 0 1 0 1 0 1 RTO<MO> IVL<MO> 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). Examples: Discharging a patient (Encounter from Active to Completed); Stopping a medication (SubstanceAdministration from Active to Aborted); Sending an end-of-day summary (time-based event). Discussion: 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.) An activity of an automated system. Discussion:Such activities are invoked either by an outside command or are 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, an automatic task on the schedule has moodCode <= APT. 0 LIST<ANY> An observation whose immediate and primary outcome (post-condition) is new data about a subject, in the form of visualized images. 0 1 A supply act dealing specifically with the feeding or nourishment of a subject. Discussion: 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 the Diet.code, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances. Examples: Gluten free; Low sodium 0 1 0 1 Definition: Exposure is an interaction that provides opportunity for transmission of an agent from an exposure source entity to an exposure target entity. The agent is a physical (including energy), chemical or biological substance. (Note: This class deals only with opportunity and not the outcome of the exposure, i.e. not all exposed parties will necessarily acquire the agent nor will all who acquire the agent necessarily experience actual harm or benefit.) Relationship to Substance Administration: There is a relationship between Exposure and Substance Administration. Normally when an entity has been exposed to an agent, and it is known the agent has affected the entity (e.g., caused a disease), then it is logically understood that the agent was introduced into the entity in some fashion. Commonly, an agent is introduced via a Substance Administration of some sort. In those instances, there is an act relationship (COMP where Exposure is the source act) between the Exposure and the Substance Administration. Alternately, when a physician writes a prescription for a drug for a patient, the physician is effectively ordering the patient be exposed to a particular substance in the prescribed fashion (i.e., a specific type of substance administration). However, this type of administration of the prescribed substance, while normally documented as a Substance Administration, is not typically documented with a related ?Exposure? due to the detailed knowledge of cause and effect. Examples: The following examples are provided to indicate what interactions are considered exposures vs. other types of Acts: Interpretation of Exposure.statusCode: 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 would be associated with the exposure via a subject observation. Constraints: The following participations should be used with the following participations to distinguish the specific entities: 0 1 0 1 0 1 A contract whose value is measured in monetary terms. Examples: Insurance; Purchase agreement 0 1 An Act representing the movement of a monetary amount between two accounts. Discussion: 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. Examples: Cost of a service; Charge for a service; Payment of an invoice 0 1 0 1 0 1 An Act representing a statement and justification of an "amount owed". Discussion: 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 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. 0 0 1 0 1 0 1 0 1 0 1 SET<CE> RTO<PQ> RTO<MO> A participation that will be operated on over time and thus whose state and identity must be managed. Examples: An attending practitioner for an inpatient encounter may change due to leave of absence and it is important to note when this participation will be available. Rationale: ManagedParticipations are defined as a subclass of Participations to make explicit that 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 underneath the main Act.However, in certain environments the view of what these activities really are that the participants perform is not very well recognized and hence modeling those as sub-acts is deemed confusing or burdensome.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. 0 0 1 SET<II> An act that is intended to result in new information about a subject. The main difference between Observations and other Acts is that Observations have a value attribute. The code attribute of Observation and the value attribute of Observation must be considered in combination to determine the semantics of the observation. Discussion: 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 imply or state 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. Examples of Observation: 0 0 0 0 SET<CE> SET<CE> SET<CD> An interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s). Healthcare services include health assessment. Examples: outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call. 0 1 0 1 0 1 0 1 0 1 0 0 SET<CE> SET<CE> An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. Examples: Procedures may involve the disruption of some body surface (e.g. an incision in a surgical procedure) conservative procedures such as reduction of a luxated join, including physiotherapy such as chiropractic treatment, massage, balneotherapy, acupuncture, shiatsu, etc. Outside of clinical medicine, procedures may be such things as alteration of environments (e.g. straightening rivers, draining swamps, building dams) or the repair or change of machinery etc. Discussion: 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 representations for real activities is based on whether the specific properties of procedure are applicable and 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. 0 0 0 SET<CE> SET<CD> SET<CD> A public health case is an Observation representing a condition or event that has a specific significance for public health. Typically it involves an instance or instances of a reportable infectious disease or other condition. The public health case 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. An outbreak involving multiple individuals may be considered as a type of public health case. 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. Examples include AIDS, toxic-shock syndrome, and salmonellosis and their associated indicators that are used to define a case. 0 1 0 1 0 1 A substance administration is a type of act that involves introducing or otherwise applying a material into or to the subject. The substance administration is distinguished from an exposure by the participation of a performer in the act. Discussion: The substance administered by a performer physically interacts with the subject or is otherwise "taken in" by the subject during the act of administration indicated by the participation consumable.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 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 infectious 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. Examples: Substance administration may be used to represent: 0 1 0 0 1 0 1 0 0 0 1 0 SET<CD> IVL<PQ> IVL<PQ> SET<RTO> SET<RTO> SET<CD> An act that involves provision of a material by one entity to another. Discussion: The product is associated with the Supply Act via Participation.typeCode="product". With general 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. Examples: Ordering bed sheets; Dispensing of a drug; Issuing medical supplies from storage 0 1 0 1 IVL<TS> A dynamic list of individual instances of Act which reflect the needs of an individual worker, team of workers, or an organization to view groups of Acts for clinical or administrative reasons. Discussion: The grouped Acts are related to the WorkingList via an ActRelationship of type 'COMP' (component). Examples: Problem lists, goal lists, allergy lists, to-do lists, etc. Design note: This physical class contains but a single attribute, other than those that it inherits from Act. Use of that attribute in the design of RIM-based static models has been DEPRECATED in HL7 RIM Harmonization, effective November 2005. This action was based on recommendations from the Patient Care Technical Committee.As a consequence, this class will cease to be shown as a physical class in the RIM, once the attribute is retired. Nevertheless, use of this class via an Act.classCode value of "LIST" is entirely appropriate so long as only the attibutes inherited from Act are used. 0 1 A physical thing, group of physical things or an organization capable of participating in Acts, while in a role. Discussion: 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. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider). 1 1 1 1 0 0 1 0 0 0 1 0 1 0 1 0 0 0 SET<II> SET<PQ> BAG<EN> IVL<TS> BAG<TEL> SET<CE> SET<CE> The language communication capabilities for an Entity. Examples: A patient who originally came from Mexico may have fluent language capabilities to speak, read and write in Spanish, but only rudimentary capabilities in English. A person from Russia may have the capability to communicate equally well in spoken language in Russian, Armenian or Ukrainian, but prefers to speak in Armenian. Discussion: 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. Rationale: Each Entity with the ability to communicate verbally has differing language and proficiency level. This class specifies the languages with which the entity can communicate, the mode of communication (speak, read, write), the proficiency of that communication, and the Entity's preference. 0 1 0 1 0 1 0 1 A subtype of ManufacturedMaterial used to hold other Entities for purposes such as transportation or protection of contents from loss or damage. Rationale: The specifications for this class arose from the collaboration between HL7 and the NCCLS. Many of the attribute definitions are drawn from or reference the NCCLS standard. With amorphic substances (liquids, 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. Usage: A container is related to a content material through Role.classCode = CONT (content). 0 1 0 1 0 1 0 1 0 1 0 1 0 1 A subtype of ManufacturedMaterial used in an activity, without being substantially changed through that activity. The kind of device is identified by the code attribute inherited from Entity. Usage: This includes durable (reusable) medical equipment as well as disposable equipment. 0 1 0 1 0 1 0 1 0 1 A subtype of Entity representing an organism or complex animal, alive or not. Examples: A person, dog, microorganism or a plant of any taxonomic group. Constraints: Instances of this class encompass mammals, birds, fishes, bacteria, parasites, fungi and viruses. Person is a specialization of this class. Rationale: This class contains "static" or "administrative" attributes of interest to medicine that differentiate living organisms from other Entities. 0 1 0 1 0 1 0 1 0 1 0 1 0 1 A subtype of Material representing an Entity or combination of Entities transformed for a particular purpose by a non-natural or manufacturing process. Examples: Processed food products, disposable syringes, chemistry analyzer, saline for infusion, etc. Discussion: This class encompasses containers, devices, software modules and facilities. Rationale: This class 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. 0 1 0 1 0 1 IVL<TS> IVL<TS> A subtype of Entity that is inanimate and locationally independent. Examples: Pharmaceutical substances (including active vaccines containing retarded virus), disposable supplies, durable equipment, implantable devices, food items (including meat or plant products), waste, traded goods, etc. Discussion: 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. Rationale: There are entities that have attributes in addition to the Entity class, yet cannot be classified as either LivingSubject or Place. 0 1 A subtype of LivingSubject that includes all living things except the species homo sapiens. Examples: Cattle, birds, bacteria , plants molds and fungi, etc. Rationale: Living organisms other than human beings may require additional characterizing information such as genetic strain identification that cannot be conveyed in the Entity.code. 0 1 0 1 An Entity representing a formalized group of entities with a common purpose (e.g. administrative, legal, political) and the infrastructure to carry out that purpose. Examples: Companies and institutions, a government department, an incorporated body that is responsible for administering a facility, an insurance company. 0 0 1 BAG<AD> A subtype of LivingSubject representing a human being. Constraints: 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. 0 0 1 0 1 0 0 1 0 1 0 0 BAG<AD> SET<CE> SET<CE> SET<CE> A subtype of Entity representing a bounded physical place or site with its contained structures, if any. Examples: A field, lake, city, county, state, country, lot (land), building, pipeline, power line, playground, ship, truck. Constraints: Place may be natural or man-made. The geographic position of a place may or may not be constant. Discussion: 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). 0 1 0 1 0 1 0 1 0 1 A competency of the Entity playing the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role. Discussion: An Entity participates in an Act as in a particular Role. Note that a particular entity in a particular role can participate in an act in many 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, as opposed to Participation, 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 an "employee" role.The identifier of the Role identifies the Entity playing the role in that role. This identifier is assigned by the scoping Entity to the player. The scoping Entity need not have issued the identifier, but it may have re-used an existing identifier for the Entity to also identify the Entity in the Role with the scoper.Most attributes of Role are attributes of the playing entity while in the particular role. 1 1 0 0 1 0 1 0 0 0 0 1 0 1 0 0 0 1 0 SET<II> BAG<EN> BAG<AD> BAG<TEL> IVL<TS> SET<CE> LIST<INT> A connection between two roles expressing a dependency between those roles. Examples: 1.) A role of assignment or agency depends on another role of employment, such that when the employment role is terminated, the assignments would be terminated as well. This is the dependency of the assignment role with the employment role, or in other words, the assignment is "part of" the employment.2.) One role has authority over another (in organizational relationships). For example, an employee of type "manager" may have authority over employees of type "analyst" which would be indicated by a role link for "direct authority". Discussion: RoleLink specifies the relationships between roles, not between people (or other entities). People (or other Entities) are primarily related by their direct player/scoper relationships around the player's Role and more generally through their interactions (i.e. their participations in acts). 1 1 0 1 0 1 IVL<TS> 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. Discussion: 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. Rationale: 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. But the Access role is used to communicate about the maintenance, intake/outflow, and due replacement of tubes and drains. 0 1 0 1 0 1 A role played by a person who is associated with an organization (the employer, scoper) to receive wages or salary. Discussion: 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). 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 A Role of an Entity (player) that is accredited with licenses or qualifications (diplomas) certifying that this Entity may properly perform specific functions. Examples: 1.) A paramedical training diploma2.) The certification of equipment3.) A license to a Person or Organization to provide health services. Constraints: The scoper is the Organization that issues the credential. 0 1 A Role of a LivingSubject (player) as a recipient of health care services from a healthcare provider (scoper). 0 1 An entity (player) that has been recognized as having certain training/experience or other characteristics that would make said entity an appropriate performer for a certain activity. The scoper is an organization that educates or qualifies entities. 0 1 This abstract class is a super-type for all RIM classes, either directly or through inheritance. It 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.In general, constraint declarations, such as those communicated in this class's attributes, may occur wherever a RIM class or one of its derived clones is instantiated in an HL7 communication. Thus the attributes must be available in all RIM classes and clones. 0 1 0 0 1 0 SET<CS> LIST<II> A class 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. Examples: Consider a refined message information model (RMIM) contains Act with the specializations of Observation and PatientEducationAct, where PatientEducationAct is conceptually a direct specialization ("clone") of Act. In this case, the ActHeir class is used as the basis of the PatientEducationAct clone rather than the Act RIM class itself. The Act RIM class is used here only to represent the common generalization of Observation and PatientEducationAct. This use is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and have no conceptual meaning. Discussion: Notably, although it is used to represent Acts that are not otherwise sub-classed in the RIM, the ActHeir class does not reflect any conceptual modeling principle according to which generalizations must all be abstract and only leaf-specializations (like ActHeir) could be instantiated. This is not what ActHeir conveys; it is simply and only a work-around practical tooling problems and subsequent evolution of the tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.Note that EntityHeir and RoleHeir have the same use for Entity and Role respectively. 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. Examples: A refined message information model (RMIM) contains Entity with the specializations of EnvironmentalEntity, and LivingSubject, where EnvironmentalEntity is conceptually a direct specialization ("clone") of Entity. In this case, the EntityHeir class is used as the basis of the EnvironmentalEntity clone rather than the Entity RIM class itself. The Entity RIM class is used only to represent the common generalization of Observation and EnvironmentalEntity. Discussion: Notably, although it is used to represent Entities that are not otherwise sub-classed in the RIM, the EntityHeir class does not reflect any conceptual modeling principle according to which generalizations must all be abstract and only leaf-specializations (like EntityHeir) could be instantiated. This is not what EntityHeir conveys; it is only a work-around for practical tooling problems. Subsequent evolution of the tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology. Rationale: This use is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and have no conceptual meaning. 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. A class 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. Examples: Consider a refined message information model (RMIM) contains Role with the specializations of Employee and Member, where Member is conceptually a direct specialization ("clone") of Role. In this case, the RoleHeir class is used as the basis of the Member clone rather than the Role RIM class itself. The Role RIM class is used here only to represent the common generalization of Employee and Member. This use is entirely dictated by the (excusable) shortcomings of certain tools and data-structures used in the HL7 methodology, and have no conceptual meaning. Discussion: Notably, although it is used to represent Roles that are not otherwise sub-classed in the RIM, the RoleHeir class does not reflect any conceptual modeling principle according to which generalizations must all be abstract and only leaf-specializations (like RoleHeir) could be instantiated. This is not what RoleHeir conveys; it is simply and only a work-around practical tooling problems and subsequent evolution of the tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology. Note that EntityHeir and ActHeir have the same use for Entity and Act respectively. The Acknowledgement class contains information sent when acknowledging another message. 0 1 0 1 0 1 0 1 A message that provides information about the communication, parsing or non-business-rule validation of the message being acknowledged. 0 1 0 1 0 1 0 SET<ST> Contains arbitrary attachments of data blocks to which can be referred to from the interior of the message. Attachments are referred to from the message body using the reference functionality of the ED data type.OpenIssue: Proper use of this class (Attachment) requires an extension of the referencing mechanism of the ED data type. 1 1 1 1 This class allows parameters related to the transmission to be represented in the V3 message wrapper. The contents of the class shall be related to the transmission as a whole and shall be solely used for transmission related purposes and not have any impact on the semantic interpretation of the contents of the transmission. For example, if encrypted or compressed payloads are used, and the receiver needs to have access to the Patient.id for internal routing purposes within the receving application, then the sender can make this information available in AttentionLine. 0 1 0 The Batch class is used to specify a message which is a collection of HL7 V3 messages. 0 1 0 1 0 0 1 0 0 1 SET<ST> SET<INT> Relationship class binds the various entities which function in the transmission (sender, receiver, respond-to) to be linked to the transmission. 0 1 0 1 The Message class is the parent class of all HL7 Version 3 messages. 0 1 0 1 0 1 0 1 0 1 0 SET<ED> Represents information about a specific transmission of information from one application to another. 0 1 0 1 0 1 0 1 0 1 0 1 0 LIST<II> A directed association between a source Transmission and a target Transmission. 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. Examples: The initial implementation envisages a single type - SEQL - "A transmission relationship indicating that the source transmission follows the target transmission." 1 1 0 1 The Parameter class is an implementation class that represents the structure of parameters that may be specified with the Query-by-parameter mechanisms of the V3 query framework. Parameters may be set of name/value pairs, a named parameter list with a set of name/value pairs or any combination the previous two options. 0 1 Represents a valued element structure (name-value pair) for the element specified in the query response.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. Discussion: 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. 0 0 1 Specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement. This class carries information sent with responses to a query. 0 1 0 1 0 1 0 1 0 1 This class contains the definition of a Query by Parameter, an HL7 query format proposed to replace the QRD/QRF query format. The query format is considered a closed query because a data server specifies a fixed list of parameters published in a query conformance statement. This class contains the definition of a Query by Selection. This is an HL7 query in which a request can specify any or all of the variables offered by a data server and may additionally specify any permissible operators and values for each variable as published in a query conformance statement. This query format is considered an open query because it allows a selection specification against a published data base schema. This class maintains the state information required at the application level to control the logical continuation of a query response. 0 1 0 1 0 1 This abstract class is used to gather the parts of a message interaction that are specific to a query message interaction.Rationale: A message element type is defined by a TC to meet a messaging requirement for a query response (like the response message element type for a demographics query). An instance of such a message element type would be represented as a query message interaction in this revised view of the V3 query/response model. The "return_element_group" would identify the RIM view that would be similar in form to the RIM view specified in a declarative or imperative application message interaction.OpenIssue: State names need to be re-visited. 0 1 0 1 This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification. 0 1 0 0 1 0 1 0 1 0 1 0 1 SET<II> 0 1 0 1 0 1 Holds specification of sort order for instance matches to a query. 0 1 0 1 0 1 Specialization of Act to add the characteristics unique to document management services. 0 1 0 1 0 1 0 SET<ED> A structure is a container within a document. Structures have captions which can be coded. Structures can nest, and structures can contain entries.OpenIssue: The name of this class, and the allowable ActClass values, will be revised so as to be consistent with the ActContainer hierarchy, which is currently undergoing review. (November 2004) 0 1 0 1 Identifies the relationship between an acknowledgment and the error, warning and informational detail accompanying that acknowledgment. 1 1 0 * Identifies the relationship between a transmission and the acknowledgements that acknowledge that transmission. 0 * 1 1 Identifies the relationship between an acknowledgment and the transmission conveying that acknowledgement. 0 * 1 1 0 * 1 1 0 * 1 1 0 * 0 1 This relationship allows parameters for a technology-specific transport to be represented in the V3 transmission outer wrapper. 0 * 1 1 Comment: Contained transmissions inherit all elements of the containing transmission unless explicitly overridden, such as sender, receiver, attachments, transmission time, etc. This is applicable, but not limited to Messages (interactions with a Message-class entry-point) contained in a Batch (interactions with a Batch-class entry-point). 0 1 0 * 0 * 0 1 This relationship allows the entities playing the various communication functions to be identified. 1 * 0 * 1 1 0 * 0 * 0 1 Specifies the relationship between a parameter list and the parameters which are its content. 0 1 0 * 0 * 1 1 0 * 1 1 0 1 1 1 0 * 0 1 0 * 0 1 0 * 1 1 0 * 1 1 0 * 0 1 0 * 0 1 0 * 0 1 0 * 1 1 This relation links a transmission to its sender, receiver, call-back party, etc. 1 * 0 * 0 * 1 1 0 * 1 1