Version: V 01-08 (7/6/2001)
ModelID: RIM_0108
| Committee Co-chair: | George Beeler (woody@beelers.com) Beeler Consulting LLC |
| Committee Co-chair: | Jane Curry Alberta Health and Wellness |
| Committee Co-chair: | Abdul-Malik Shakir IDX Corporation |
Copyright 2001 by Health Level Seven. All rights reserved.
Link from here to model content: Subject areas, Classes, and Associations.
Comments or questions about this document may be may be addressed to:HL7 Headquarters Staff (HQ@HL7.org)
This model reflects changes determined to be "mandatory" for message designs during and immediately after the HL7 Spring 2001 Working Group Meetings May 7-11, 2001. Many of these changes were agreed to during a special M&M meeting on May 11, and will be harmonized during the July, 2001 Harmonization Meeting.
This release of the RIM is being made available to HL7 Committees developing messages to be submitted for ballot during the summer of 2001.
Comments on this model should be addressed to the co-chairs of the Methodology and Modeling Committee and/or sent to the M&M e-mail list at mnm@lists.hl7.org
The purpose of a Reference Information Model is to share consistent meaning beyond a local context. In general, the broader the scope of interest, the more important it is to make all assumptions about a topic of interest explicit. The HL7 Version 3 Reference Information Model (RIM) is a comprehensive source of all information subjects used in any HL7 specification.
Since HL7 specifications permit loosely coupled information systems to interoperate, the scope of the HL7 RIM is the information required to be understood between information systems, but not necessarily all information recorded within any particular system. As HL7 specifications are used to connect information systems operated in different circumstances, across many types of healthcare delivery organizations and potentially across political jurisdictions, the HL7 RIM needs to be flexible enough to express a diverse range of information content while maintaining a unified framework.
The Version 3 RIM articulates explicit definitions of the things of interest referenced in HL7 messages, structured documents or any future HL7 "information packages" specification. The RIM also contains definitions of the characteristics of these things of interest and the relationships among them.
The Reference Information Model is expressed using a modified object notation similar to that used in UML. The RIM is graphically presented as a network of classes containing their attributes and connected by their associations. Behind the graph are the details of all the definitions, connections and constraints. All information about the RIM is held in a repository that contains the details, the connections among the details and the changes over time.
The HL7 RIM is not a model of a database, or any particular vendor's information system, or any particular healthcare organization enterprise, or even any particular set of messages. Any of these specific contexts may have an information model of their own and can use a similar form of notation.
On the surface, the models may look alike, but their scopes and purposes are different. The definitions behind the pictures will reflect the constraints and emphasis appropriate to the context.
The RIM has been "under construction" since 1997. The initial "starter model" was created through amalgamating models from a number of healthcare organizations and the contents of the current message specifications. No one, however, considered the starter RIM to be satisfactory. Facilitators from each technical committee have, therefore, provided change proposals to the harmonization process, which is managed by the Modeling and Methodology Technical Committee. Harmonization meetings are held between working group meetings to facilitate this process and all changes are voted on by representatives from the TCs.
Over time, a close inspection of message contents, intensive interaction between technical committees and input from other standards development organizations and international affiliates have resulted in a much more generalized structure.
The initial version of the RIM can be said to have been "label" oriented and the current version is "structure and definition" oriented. In other words, the names of classes, attributes and associations have become more general, but the structure is capable of supporting information requirements for a greater variety of circumstances.
There is always a trade-off between having a model of manageable size but flexible structure and a model containing familiar names but more limited use. The initial version of the RIM was an explicit expression of a small scope (generally within a hospital). The current version is a more general expression of a large and still growing scope (networks of organizations interoperating to provide care in concert).
Entities represent all the things HL7 is interested in: people, other living organisms, organizations, places and manmade things. These things have identities in and of themselves. The entities can take on roles that are valid for periods of time. The roles themselves may be related. For example, a particular person may be a patient of a particular healthcare provider. The identifier of the person as patient is contained in the Role-relationship class and is specific to the particular provider and is effective only for the time period he/she is under their care. Entities in roles participate in all kinds of actions, either as actors, as targets of acts, or as resources required to be able to perform the acts. The acts themselves may be related in complex ways, some requiring subsequent acts to be performed, or others constraining which acts may be performed. Because the realm of healthcare is concerned with recording intentional actions, all information recorded during the act is considered part of the act itself.
Additional class subtypes are defined to contain attributes that are specific to certain subsets of the main classes. Both Entity and Act may be expressed as a definition as well as representing the actual instances. The RIM is organized to allow meaningful "sentences and paragraphs" to be constructed-rather than modeling the clusters of information resulting from a particular context.
The RIM class, attribute and association definitions provide detail about logical meaning, but full specification requires datatypes and domains. Datatypes are the details of structure that allow computers to chunk up a stream of bits into meaningful elements. Domains are the values any particular chunk may contain. Datatypes are represented in the repository and can be displayed using the same graphical representation. Vocabulary domains are also explicitly defined in the repository and permit a cross-reference among code schemes and alternative representations while keeping track of the logical concepts being expressed. Each attribute of each class may only be expressed using specific datatypes and domains.
When the RIM is put to use, a particular context is defined in a use case model, and the particular subset of classes, attributes and associations required are defined explicitly in a Refined Message Information Model. Additional constraints on vocabulary domains or interdependencies between attributes can be added during the definition of an abstract message or other structures "information package."
Taken together, the Version 3 Message Development Framework and the RIM provides the ability to express diverse information content for a wide variety of contexts while maintaining meaning as a unifying whole.
|
|
|
A collection of subject areas related to the Act class and its specializations. These relate to the actions and events that constitute health care services.
|
|
A collection of classes that are the specializations of the Act class and that focus upon the administrative and financial activities in health care.
|
|
|
A collection of subject areas that define the technical infrastructure of HL7, including messaging, structured documents and components.
|
|
A collection of classes related to the technical definition and control of message-based communication in HL7.
|
|
|
A collection of classes related to the definition of document-based communication in HL7, as represented by the Clinical Document Architecture standards.
|
|
|
A collection of classes that include the Entity class, all of its specializations and related qualifying classes. The classes represent helath care stakeholders and other trhings of interest to health care.
|
|
|
A collection of classes centered on the Role class, all of its specializations, and the Relationship-link class that binds role relations together.
|
|
|
|
|
|
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., exudate, pus, urine, air, blood) out of the body. Typically an Access_device is a catheter or cannulainserted into a compartment of the body.
Therefore, target_body_site_cd and entry_site_cd are attributes of the Access_device. Note that the Access_device 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_device role class, since the material attributes will usually suffice to describe and identify the product for the order. But the Access_device role is used to communicate about the maintenance, intake/outflow, and due replacement of tubes and drains.
Devices in the role of an Access_device 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.
OpenIssue: Can Entities other than Devices assume the role of Access_device? If so, perhaps the class is better named Access_material.
Vocabulary domain: AccessApproachSite (CWE)
Attribute description:Specifies the anatomic site where the line or drain first enters the body. For example in a arteria pulmonalis catheter targets a pulmonary artery but the access approach site is typically the vena carotis interna at the neck, or the vena subclavia at the fossa subclavia.
The coding system is the same as for Procedure.access_site_cd., indeed the Access.approach_site_cd has been copied from the Procedure class into the Access role class. The value of the Access.approach_site_cd should be identical to the value of the Procedure.approach_site_cd of an associated access placement procedure. This attribute is used if such an associated access placement procedure is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a resource of many services, the access approach site becomes an important identifying attribute of the access itself.
The gauge of an access is a measure for the inner diameter of the tube (the lumen.) Typically catheter gauge is measured in terms of units not seen elsewhere. Those units are defined in the Unified Code for Units of Measure.
Vocabulary domain: AccessTargetSite (CWE)
Attribute description:This is the anatomical target site of the access, i.e., the body compartment into which material is administered or from which it is drained. For example, a pulmonary artery catheter will have the target site arteria pulmonalis with or without a known laterality.
The coding system is the same as for Procedure.target_site_cd, indeed the Access.target_site_cd has been copied from the Procedure class into the Access role class. The value of the Access.target_site_cd should be identical to the value of the Procedure.target_site_cd of an associated access placement procedure. This attribute is used if such an associated access placement procedure is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a resource of many services, the target site becomes an important identifying attribute of the access itself. The target site is an important information that determine what kinds of substances may or may not administered (e.g., special care to avoid medication injections into an arterial access.)
|
|
A sub-class of Act representing a financial account established to track the net result of financial acts. 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.
An interval describing the minimum and maximum allowed balances for an account.
Vocabulary domain: Currency (CWE)
Attribute description:Indicates the currency that the account is managed in.
ExtRef: ISO:4217
A ratio that indicates the rate of interest that the account balance is subject to, and the term over which the interest rate compounds.
The numerator is the interest rate and the denominator is the compounding term.
The numerator is REAL, and the denominator is IVL(TS)
The descriptive name of the account as carried in the ledger of which the account is a part.
|
|
|
|
|
|
An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An Act instance is a record of such an intentional action. The terms "act", "action", and "activity" are all used interchangeably, but Act has been selected as the name of this class.
Any intentional action can exist in different "moods" (See Unified Service Action Model (USAM 2.7) for a complete description of "mood"). For example, the mood of an action can tell whether the action actually occurred (Act.mood="event"), was ordered (Act.mood="order"), serves as a criteria to trigger further actions (Act.mood="event criterion"), defines the action, and more. (See the ActMood domain table in HL7 Vocabulary Domain Listings for the complete set of defined Act moods.) An Act instance represents an action in one and only one such mood. Thus, act events, orders, criteria, and definitions are all represented by an instance of Act.
Any instance of an Act assumes one and only one mood and will not change its mood along its life cycle. The moods definition, intent, order, event, etc. seem to specify a life cycle of an activity and thus seem like state changes. However, the actors of these different moods are different, and so is the data different. It is important to keep track of those differences (variances) in business processes. Therefore, the mood of an Act instance is static and not part of the state, not part of the life cycle. The progression of the idea of an act towards actualization (i.e., the progression from defined, through planned and ordered, to being performed) is called "business cycle" to distinguish it from the "life cycle" of a single act instance. Related Act instances that form such a "business cycle" are linked through the Act_relationship class (See also USAM 2.7).
Examples for acts in health care are: a clinical test, an assessment of health condition (such as problems and diagnoses), the setting of healthcare goals, the performance of treatment services (such as medication, surgery, physical and psychological therapy), assisting, monitoring or attending, training and education services to patients and their next of kin, and notary services (such as advanced directives or living will).
Acts have participants, which can be actors or targets (See USAM 2.7 for a complete description of "actor" and "target"). Examples of actors are nurses, doctors, family members, notary publics, and service organizations -- every person or organization that is capable of independent decisions and can thus be responsible (and liable) for the actions performed.
Target participants in an act may include the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or reflexive services.)
An act can have multiple active participants and multiple target participants, their specific role being distinguished in the "type_cd" of the respective instance of the Participation class. In particular, an act involving coordination of care may involve two or more active participants -- playing different roles -- who interact on behalf of a patient, family, or aggregate in the role of target participant. For example, a nurse (active participant) calls Meals on Wheels (active participant) on behalf of the patient (target participant).
An act includes the "results", "answers" or informational "procedure products" gained during the act. In this model, "results" do not exist without an act, and every clinical result, including those results gained accidentally, is gleaned via an act. In other moods, such as "definition", "goal", and "criterion", the results are the possible results, the expected or aimed-for results, or the tested-for results.
This is the time when the action happened, is ordered or scheduled to happen, or when it can possibly happen (depending on the mood of the Service object.)
When used with procedures and other events, this is the total time of activity including preparation and clean-up actions. Thus it may be longer than the effective time of the same act, which is the period during which the procedure actaully takes place.
The timing of actions is a very important concept that is explained in greater detail in USAMP-II part A, Section 2.5.3.
Version 2.x reference:| FT1^4^00358^Transaction Date |
| IN1^29^00454^Verification Date/Time |
| IN3^7^00508^Certification Modify Date/Time |
| DRG^2^00769^DRG Assigned Date/Time |
For HL7 messaging, the Service.availability_dttm will be set according to the sender system. If the receiver system records the received information as new, it may set it's own recording time to the time it received this information, rather than to the time specified by the information sender.
The Service.availability_dttm is an inert attribute with respect to the mood code. This means, it is the recording time of the service object regardless of its mood.
Rationale: A database that records a separate time stamp for both valid time and transaction time is called a bi-temporal database. Bi-temporal databases allow reconstructing at any time what users of the database actually could have known, versus what the state of the world was at that time. For example, one might record that a patient had a right-ventricular myocardial infarction effective three hours ago, but we may only know about this unusual condition a few minutes ago. Thus, any interventions from three hours ago until a few minutes ago may have assumed a usual left-ventricular infarction, which can explain why these interventions may not have been appropriate in light of the more recent knowledge about the prior state. However, the transaction time (or recording time) may vary from system to system.
Vocabulary domain: ActCode (CWE)
Attribute description:A code specifying the kind of action (e.g. physical examination, serum potassium, patient encounter, financial transaction, etc.). The Act.cd specifies the act conceptually using a code from one of several, typically external, coding systems depending on the class of act, such as observations (LOINC), procedures (e.g., SNOMED), medication treatments (e.g., UMLS), etc.
Open Issue: for administrative acts, this code should actually be used, even though many administrative acts might be specified by Act.class_cd (e.g., encounter). However, sometimes we find further classifying codes (e.g., encounter class code) that can be appropriately mapped to the act code.
Version 2.x reference:| FT1^18^00148^Patient Type |
| PV1^18^00148^Patient Type |
| IN1^15^00440^Plan Type |
| IN1^31^00456^Type of Agreement Code |
| IN2^21^00492^Blood Deductible |
| IN2^28^00499^Room Coverage Type/Amount |
| IN2^29^00500^Policy Type/Amount |
| IN2^30^00501^Daily Deductible |
| IN3^12^00513^Non-Concur Code/Description |
| DRG^8^00770^DRG Payor |
| IN1^47^01227^Coverage Type |
| LRL^4^01227^Coverage Type |
Vocabulary domain: ActClass (CNE)
Attribute description:A code specifying on a high, technical, and tightly controlled level the kind of act. This code is similar in nature as the names of the classes derived from act in a refined message information model (R-MIM.)
Version 2.x reference:| PV1^2^00132^Patient Class |
| FT1^6^00360^Transaction Type |
| FT1^7^00361^Transaction Code |
| FT1^9^00363^Transaction Description - Alt |
Vocabulary domain: Confidentiality (CWE)
Attribute description:This is a code that limits the disclosure of information about this service.
Confidentiality policies may vary from institution to institution and not all systems are capable of abiding by all details of the confidentiality policies enumerated in the vocabulary domainsuggested in the above table. However, these are the items that are being used in some institutions and which implementers may want to consider supporting.
It is important to note that good confidentiality of the medical record cannot be achieved through confidentiality codes only to filter out individual record items to certain types of users. There are two important problems with per-item confidentiality: one is inference and the other is the danger of holding back information that may be critical in a certain care situation. Inference means that filtered sensitive information can still be assumed given the other information not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as zidovudine for treatment of HIV infections. The problem of hiding individual items becomes especially difficult with current medications, since the continuing administration of the medication must be assured.
Aggregations of data should assume the privacy level of the most private action in the aggregation.
Version 2.x reference:| IN1^27^00452^Release Information Code |
| PV2^21^00722^Visit Publicity Code |
The time at which the action focuses. This attribute is also known as the "primary" time (Arden Syntax) or the "biologically relevant time" (HL7 v2.x). While this attribute is of type GTS very often it will be a simple time range (IVL<TS>) or even a simple time stamp (which is all compatible with GTS.)
This attribute is distinguished from activity time.
For observations, the time of the observation action may be much later than the time of the observed feature. For instance, in a Blood Gas Analysis (BGA), a result will always come up several minutes after the specimen was taken, meanwhile the patient's physiological state may have changed significantly. Even more so in history taking, when the doctor records an episode of Hepatitis A under which the patient suffered last year for several weeks. So, the effective time is the time at which the observation is applicable.
For surgical procedures the time between first cut and last suture is taken as the effective time of the procedure. For transport and supply services the critical time is the time en route or time of delivery respectively (discounting the travel time to the pick-up location and from the drop-off location.) So the effective time does not count in the overhead that is not relevant for the objective of the act. This overhead, however, is relevant for scheduling and potentially billing.
For administrative acts, such as patient encounters, this is the "administrative" time, i.e., the encounter start and end date required to be chosen by business rules, as opposed to the actual time the healthcare encounter related work is performed (which would be the activity_time.)
ExRef: UB92 FL 17, UB91 FL 18
Version 2.x reference:| PV1^25^00155^Contract Effective Date |
| PV1^41^00171^Account Status |
| PV1^44^00174^Admit Date/Time |
| PV1^45^00175^Discharge Date/Time |
| FT1^5^00359^Transaction Posting Date |
| GT1^13^00417^Guarantor Date - Begin |
| IN3^6^00507^Certification Date/Time |
| IN3^9^00510^Certification Begin Date |
| IN3^13^00514^Non-Concur Effective Date/Time |
| IN3^22^00523^Second Opinion Date |
This is an instance identifier of a particular Act object. For example, whenever an act is carried out, there is a new Act object instantiated with an identifier that uniquely distinguishes this Act object from every other Act object.
Version 2.x reference:| PID^18^00121^Patient Account Number |
| MRG^3^00213^Prior Patient Account Number |
| BLG^3^00236^Account ID |
| FT1^2^00356^Transaction ID |
| FT1^14^00368^Insurance Plan ID |
| IN1^2^00368^Insurance Plan ID |
| DG1^8^00382^Diagnostic Related Group |
| DRG^1^00382^Diagnostic Related Group |
| IN1^14^00439^Authorization Information |
| IN1^35^00460^Company Plan Code |
| IN1^46^00471^Prior Insurance Plan ID |
| IN3^2^00503^Certification Number |
| UB2^12^00564^Document Control Number |
This attribute indicates whether this act can be transacted upon independently from other acts. Some acts can only be manipulated as subordinate to a composite act others are abstractions of acts or inseparable act groups that should only be manipulated together. Since in principle everything that can be done can potentially be acted upon, this attribute is true by default.
Example for use: In the master file, this indicates whether an act is individually orderable. In an order, whether a component of the order can be individually removed or cancelled.
OpenIssue: Find a new name for this attribute
Indicates whether an ct is interruptible by asynchronous events (such as "through" conditions to turn false, or time running out??.) See discussion on activity plans in the USAM 2.7 document, part A.
Vocabulary domain: ActMood (CNE)
Attribute description:Webster's dictionary defines mood as a "distinction of form [..] of a verb to express whether the action or state it denotes is conceived as fact or in some other manner (as command, possibility, or wish)". This definition of mood can be directly applied to the USAM model, where the action (in natural language) may be conceived as an event that happened (fact), an ordered service (command), a possible service (master), and a goal (wish) of health care. One of the "infinitive" moods is used for describing potential acts that can have actual services associated with them. Common use of the infinitive mood is for dictionary entries (so called "master service") and all "knowledge" links (e.g., possible reason, cause, manifestation, etc.) Other special infinitives are "goal" and "trigger" mood. A goal describes a wish for a certain outcome (typically an observation) to be achieved in the future. An observation in goal mood is not actually made, thus is an infinitive. Goals are evaluated later. Triggers are service descriptions that can match actual services (like a query.) When a trigger matches, it enables, suggests, or demands the associated action to be performed. Triggers are most often used to fully describe PRN medication orders, but can serve to build reminder systems too.
Vocabulary domain: ActPriority (CWE)
Attribute description:This attribute encodes the urgency under which the act is to be scheduled and performed, or was performed. This attribute is used in orders to indicate the ordered priority. It is also used in the service event documentation to indicate the actual priority used to perform the act, which is used to determine the charge. In master service definitions it indicates the available priorities.
Version 2.x reference:| PV1^4^00134^Admission Type |
| PV2^25^00726^Visit Priority Code |
Vocabulary domain: ActReason (CWE)
Attribute description:A code depicting the reason for and administrative or financial act. For Patient Encounter, it is the reason for a patient transfer associated with the encounter. Examples include roommate conflict, equipment malfunction, acuity change, etc.
OpenIssue: Clarify definition to make it clear which of the two locations that the reason is pertinent to: the source or the destination. The concept is OK though.
Version 2.x reference:| PV1^29^00159^Transfer to Bad Debt Code |
| PV1^34^00164^Delete Account Indicator |
| PV2^4^00184^Transfer Reason |
| IN3^17^00518^Appeal Reason |
This is the range of values for the number of repetitions of an act.
Vocabulary domain: ActStatus (CNE)
Attribute description:The state of the action. For example, suspended, active, completed, cancelled, aborted.
OpenIssue: Shouldn't the allowable states be added as an ActStatus vocab domain?
Version 2.x reference:| IN1^32^00457^Billing Status |
| IN2^16^00487^Champus Status |
| IN3^23^00524^Second Opinion Status |
| IN3^24^00525^Second Opinion Documentation Received |
| PV2^16^00717^Purge Status Code |
| PV2^24^00725^Patient Status Code |
The effective date of the status.
OpenIssue: This likely to represent a whole set of attribution for change of state.
Version 2.x reference:| PV1^30^00160^Transfer to Bad Debt Date |
| PV1^35^00165^Delete Account Date |
| PV2^17^00718^Purge Status Date |
The description of an act is a piece of free text or multimedia data that describes the act in all necessary detail. There is no restriction on length or content imposed on the Act.txt attribute. However, the content of the description is not considered part of the functional information communicated between systems. Descriptions are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects. As with any attribute of the Act class , the meaning of the Act.txt attribute is subject to the Act.mood_cd. For act definitions, the description can contain textbook-like information about that act. For act orders, the description will contain particular instructions pertaining only to that order. Filler order systems must show the description field to a performing provider.
OpenIssue: The descriptive text for this attribute needs to be revised for clarity and consistency.
Version 2.x reference:| FT1^8^00362^Transaction Description |
|
|
|
|
The Act_context is a specialization of an Act which explicitly contains a set of other Acts that share the same context. The "context" of an act is defined as the attribution ascribed to its containing Act_context.
OpenIssue: It is recognized as a useful construct but the implication of implied inheritance needs to be resolved. HL7 needs to be cautious about extending the class beyond its original use case. Cardinality on the Act/mulitiplicity needs to be reviewed (the suggestion is that needs to be 0 *).
Vocabulary domain: HumanLanguage (CWE)
Attribute description:The human language of character data can be specified using this attribute.
Vocabulary domain: ActContextLevel (CWE)
Attribute description:The nature or level of the contextual containment that this Act_context provides for the Acts it contains.
OpenIssue: The values of this attribute need to be carefully considered to address the open issues relating to inheritance.
|
|
|
The Act_relationship class is a recursive associative class with two associations to the Act class, one named "source" the other named "target". Consider every Act_relationship instance an arrow with a point (headed to the target) and a butt (coming from the source.) For each relationship type, the functions (or roles) of source and target Act are different. In principle the assignment of functions (roles) to each side of the relationship "arrow" is completely arbitrary. However since . The relationships associated with an Act are considered properties of the source act object. That means that the originator of the information reported in an act object is not only responsible for the attribute values of that object, but also for all its outgoing relationships.
The rule of attribution is that all act relationships are attributed to the responsible actor of the Act at the source of the Act_relationship (the "source act".)
With this recursive act relationship one 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.
Acts may also be grouped longitudinally, in a sequence of sub-actions to form temporal and conditional (non-temporal) action paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).
Acts may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections of acts allow expressing logical branches as well as parallel tasks (tasks carried out at the same time.) These constructs can be organized in multiple layers of nesting, to fully support workflow management.
The Act_relationship class is not only used to construct action plans but also 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 Act_relationship link too.
The Act_relationship.type_cd identifies the meaning and purpose of every Act_relationship instance. For a more detailed description of Act_relationship, see USAM 2.7.
Vocabulary domain: ActRelationshipCheckpoint (CNE)
Attribute description:Indicates when associated pre-conditions are to be tested.
Vocabulary domain: RelationshipConjunction (CNE)
Attribute description:In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.
The inversion indicator is used when the meaning of Act_relationship_type_cd must be reversed. For example, we define a relationship type reason to express the reason for an action as in:
a) "A cholecystectomy was performed because of symptomatic cholelithiasis without signs for cholecystitis." (cholecystectomy has-reason cholelithiasis)
This statement of rationale is attributed to the responsible performer of the cholecystectomy. Now consider the following statement:
b) "The finding of symptomatic gall stones (cholelithiasis) with no signs of acute cholecystitis suggests a cholecystectomy."
While sentence a) declares a reason for an action, sentence b) suggests an action. Reason and suggestion links are reciprocal, i.e., if X has-reason Y, then Y suggests X. The second statement would have been made by the originator of the cholelithiasis finding.
In the "network" of interrelated acts, we need to make sure that we do not lose proper attribution of statements to originators ("who said what?") Since attribution is so important, we adopt a very simple rule for it: an act relationship is always attributed to the originator of the source service. No exceptions to this rule are permitted whatsoever. If attribution needs to be different one can invert the relationship type by setting the inversion_ind attribute to "true".
If the inversion indicator is "true", source and target act swap their roles; that is, the reason and the suggested action swap their roles, so that cholecystectomy can be the source and cholelithiasis can be the target. Note that the attribution rule is always unchanged; i.e., the act relationship is always attributed to the responsible author of the source service, no matter what the inversion_ind value is.
Vocabulary domain: ActRelationshipJoin (CNE)
Attribute description:In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.
A kill branch will only be executed if there is at least one active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather than being discontinued shortly after it is started.) A detached branch will be unrelated to all other branches, thus a kill branch will be discontinued no matter whether there are detached branches still running.
For conditions and criteria links, indicates whether the meaning is negative (condition must not be true.) Normally all conditions are interpreted as affirmative, i.e., the condition must be true. The negation_ind is part of the condition so that the Boolean outcome of the condition XOR-ed with the negation_ind of the condition link must be true. Thus, if the negation_ind is "true", we say the "condition is true", even if the test was negative.
The time that should elapse between clearance for execution of this activity and the actual beginning of execution. Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the act is executed after its pre-conditions become true.
This integer number allows specification of another kind of ordering amongst the outgoing relationships of an act. This is used to represent the priority ordering of conditional branches in act execution plans, or priority ranking in pre-condition, outcome or support links, and preferences among options.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same act instance and usually having the same relationship type) has a distinct priority number. If, however, some relationships in the bundle share the same priority number, we have a partial ordering. Those links with the same priority will have undefined ordering of consideration.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same service instance and usually having the same relationship type) has a distinct priority number. If, however, some relationships in the bundle share the same priority number, we have a partial ordering. Those links with the same priority will have undefined ordering of consideration.
This integer number allows one to specify an ordering amongst the outgoing relationships of an act. This is used to represent sequences of actions in execution plans.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle has a distinct sequence number. (A relationship "bundle" is a sub-set of the relationships originating in the same act instance and usually having the same relationship type). If, however, some relationships in the bundle share the same sequence number, we have a partial ordering. In such a case the acts with the same sequence number are concurrent.
Vocabulary domain: ActRelationshipSplit (CNE)
Attribute description:When an activity plan has a branch (indicated through multiple steps with the same item number) the split code specifies how branches are selected for execution.
Vocabulary domain: ActRelationship (CNE)
Attribute description:Determines the meaning of a relationship between two Acts. Each of its values implies specific constraints to what kinds of Act objects can be related and in which way. Refer to the USAM specification document for defined act relationship types and examples of their use.
Version 2.x reference:| FT1^3^00357^Transaction Batch ID |
| FT1^15^00369^Insurance Amount |
| FT1^17^00370^Fee Schedule |
| IN1^25^00450^Rpt of Eligibility Flag |
| IN1^33^00458^Lifetime Reserve Days |
| IN1^34^00459^Delay Before L. R. Day |
| IN1^37^00462^Policy Deductible |
| IN1^39^00464^Policy Limit - Days |
| IN2^19^00490^Baby Coverage |
| IN2^20^00491^Combine Baby Bill |
| IN2^21^00492^Blood Deductible |
| IN2^24^00495^Non-Covered Insurance Code |
| IN2^28^00499^Room Coverage Type/Amount |
| IN2^29^00500^Policy Type/Amount |
| IN2^30^00501^Daily Deductible |
| IN3^5^00506^Penalty |
| IN3^20^00521^Pre-Certification Req/Window |
| IN2^67^00807^Copay Limit Flag |
|
|
Vocabulary domain: PractitionerPosition (CWE)
An indication that the healthcare practitioner is a primary care provider.
|
|
A relationship between a certifier and an Individual_healthcare_practitioner to indicate where the certifier (who is the source of the Role_relationship) has granted a license or certificate to the practitioner (who is the target of the Role_relationship)
Vocabulary domain: BoardCertificationType (CWE)
Attribute description:The type of board certification issued to the practitioner by the certifier.
OpenIssue: What is the relationship between this attribute and Healthcare_provider.specialty_cd?
The date recertification is required.
The Consent class represents informed consents and all similar medico-legal transactions between the patient (or his legal guardian) and the provider. Examples are informed consent for surgical procedures, informed consent for clinical trials, advanced beneficiary notice, against medical advice decline from service, release of information agreement, etc.
The details of consents vary. Often an institution has a number of different consent forms for various purposes, including reminding the physician about the topics to mention. Such forms also include patient education material. In electronic medical record communication, consents thus are information entities [use a different word to avoid confusion with the Entity class?] on their own and need to be managed similar to medical activities. Thus, Consent is modeled as a special class of Act.
The "signatures" to the consent document are represented electronically through Participation instances to the consent object. Typically an informed consent has Participation.type_cd of "performer" (the healthcare provider informing the patient, and "consenter", the patient or legal guardian. Some consents may associate a witness or a notary public (e.g., living wills, advanced directives). In consents where a healthcare provider is not required (e.g. living will), the performer may be the patient himself or a notary public.
Some consents have a minimum required delay between the consent and the service, so as to allow the patient to rethink his decisions. This minimum delay can be expressed in the act definition by the Act_relationship.pause_qty attribute that delays the service until the pause time has elapsed after the consent has been completed.
|
|
|
A container is a manufactured material used to hold other things for purposes such as transportation or protection of contents from loss or damage. 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.
A container is related to a content material through Role_relationship.type_cd = "has content".
OpenIssue: What is NCCLS?
OpenIssue: Need to differentiate between geometric properties -- barrier, bottom, capacity, diameter, height -- in these definitions. What is a barrier_delta, a bottom_delta, etc?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
Vocabulary domain: ContainerCap (CWE)
Attribute description:From NCCLS, the kind of cover cap.
OpenIssue: Code appears to be undefined. This attribute will be dropped if we do not get in a half-way complete concept repertoire by September 2000.
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the contained.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
Vocabulary domain: ContainerSeparator (CWE)
Attribute description:From NCCLS, the kind of separator material.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
OpenIssue: Needs a vocabulary domain.
|
|
This role represents the status of an individual (player) as a covered party, covered by a particular insurer (scoper). A covered party participates as 'coverage' in a variety of forms of the healthcarfe coverage act class.
Status as a covered party is also dependent upon being the target of an 'indirect authority' relationship link to a policy holder (subscriber) role. The "id" for the covered party is the identifier of the insurance policy sub-set that specifically identifies this invidual as having coverage.
The "cd" for this role indicates the reason for which coverage is provided, such as "child", "pet", "spouse", "ward", "dependent", etc.
Vocabulary domain: CoveredPartyHandicap (CWE)
Attribute description:A code depicting the handicap of a particular covered party. This code is used in conjuntion with other information to coordinate benefits for a covered party.
OpenIssue: See Canadian e-claims project for proposed code values for this item.
An indicator that the covered party is a student.
|
|
|
|
A device is anything used in an activity without being substantially changed through that activity. This includes durable (reuseable) medical equipment as well as disposable equipment.
There are a few device concepts defined by HL7 version 2.3 which are suggested for use in HL7 v2.3 as Material.type_cd values if the material is a device of one of the defined kinds and if it is not otherwise specified. See USAMP documentation, Table 38.
Table 38: Devices commonly used to administer medication (from HL7 v2.3 table 0164) Value Description Value Description AP Applicator IVS IV Soluset BT Buretrol MI Metered Inhaler HL Heparin Lock NEB Nebulizer IPPB IPPB PCA PCA Pump IVP IV Pump
OpenIssue: Currently there are no attributes of device that would not also be applicable to any kind of material. This role class is shown anyway, in order to make the use of material for devices obvious. If there are no properties defined for this class by September 2000 it will be deleted from the model.
Vocabulary domain: DeviceAlertLevel (CWE)
Attribute description:This field identifies the current functional activity of the automated device. The value of alert_level_cd is determined by the machine itself.
Date of last calibration and/or inspection of the device.
OpenIssue: Is this linked somehow with the 'maintainer'?
OpenIssue: Given the definition of the class, this attribute would be moved up to Manufactured_material.
Vocabulary domain: LocalRemoteControlState (CWE)
Attribute description:The current state of control associated with the equipment. An equipment can either work autonomously (local_remote_control_state_cd="Local") or it can be controlled by another system (local_remote_control_state_cd="Remote").
Name of the version of this device as designated by the manufacturer.
Name, version and release of the software that operates the device.
|
Class for holding attributes unique to diagnostic images.
Vocabulary domain: ImagingSubjectOrientation (CWE)
Attribute description:Patient direction of the rows and columns of the image.
|
|
|
A broad categorization, based upon included procedures and diagnoses, that applies to a Healthcare event as a whole. Used for grouping and evaluating Healthcare encounters with respect to duration of care and cost.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File; Standard_Day_Stay>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
|
|
Diet services are supply services, with some aspects resembling Medication services: the detail of the diet is given as a description of the Material associated via Participation.type_cd="product". Medically relevant diet types may be communicated in the Diet.type_cd, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances.
For diabetes diet one typically restricts the amount of metabolized carbohydrates to a certain amount per day (e.g., 240 g/d). This restriction can be communicated in the carbohydrate_qty.
OpenIssue: Unclear whether the same should not be expressed as associated observations in goal mood (observation.type_cd = carbohydrate intake.)
This value indicates the supplied biologic energy (Calories) per day. This physical quantity should be convertible to 1 kcal/d (or 1 kJ/d.) Note, that there is a lot of confusion about what is a "calorie." There is a "large Calorie" and a "small calorie." On "nutrition facts" labels, the large "Calories" is used. More appropriately, however, one should use the small calorie, which is 1/1000 of a large Calorie. In the Unified Code for Units of Measure, the proper unit symbol for the large calorie is "[Cal]" and for the small calorie it is "cal", or, more commonly used as a kilo-calorie "kcal".
OpenIssue: Need a complete reference for Unified Code for Units of Measure.
|
|
|
Specialization of Act to add the characteristics unique to document management services.
Vocabulary domain: DocumentChangeReason (CWE)
Vocabulary domain: DocumentCompletion (CWE)
Attribute description:A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).
OpenIssue: Many of the domain values overlap with values of service.status_cd. Other values are derivable from service.text and associated actors and their roles. Therefore we may ultimately not need this attribute.
Time a document is released (i.e., copied or sent to a display device) from a document management system that maintains revision control over the document. Once valued, cannot be changed. Intent of this attribute is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.
A report identifier that remains constant across all document revisions that derive from a common original document. An original report is the first version of a report. It gets a new unique value for Document_service.id, a new value for document_service.set_id, and has the value of document_service.version_nbr set to equal "1". An addendum is an appendage to an existing report that contains supplemental information. The appendage is itself an original report. The parent report being appended is referenced via an act_relationship, with ct_relationship.type_cd set to equal "APND" (for "appends"). The parent report being appended remains in place and its content and status are unaltered. A replacement report replaces an existing report. The replacement report gets a new unique value for Document_service.id, uses the same value for document_service.set_id as the parent report being replaced, and increments the value of document_service.version_nbr by 1. The state of the parent report being replaced should become "superceded" explicitly by another message, but is still retained in the system for historical reference.
Vocabulary domain: DocumentStorage (CWE)
Attribute description:A code depicting the storage status (e.g., active, archived, purged) of a report.
Version number is an integer starting at '1' and incrementing by 1. The first instance or original report should always be valued as '1'. The version number value must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.
|
|
|
A relationship between a person or organization and a person or organization formed for the purpose of exchanging work for compensation.
The type of hazards associated with the work performed by the employee for the employer. For example, asbestos, infectious agents.
Vocabulary domain: EmployeeJob (CWE)
Attribute description:A code describing the job performed by the employee for the employer. For example, accountant, programmer, banker.
Rationale: Represents the first component of the JCC data type (job Code)
Version 2.x reference:| NK1^11^00200^Next of Kin/Associated Parties Job Code/Class |
| GT1^50^00786^Job Code/Class |
| IN2^47^00786^Job Code/Class |
| STF^19^00786^Job Code/Class |
Vocabulary domain: EmployeeJobClass (CWE)
Attribute description:A code depicting the time-relative nature of the work performed by the employee for the employer. For example, full-time, part time.
Rationale: The job class in v2.3 (second component of JCC data type) references Employee Classification table. The first component of the JCC data type (job code) is represented in Person_employment.job_cd.
Version 2.x reference:| NK1^11^00200^Next of Kin/Associated Parties Job Code/Class |
| GT1^50^00786^Job Code/Class |
| IN2^47^00786^Job Code/Class |
| STF^19^00786^Job Code/Class |
The title of the job held, for example, Vice President, Senior Technical Analyst.
Version 2.x reference:| NK1^10^00199^Next of Kin/Associated Parties Job Title |
| IN2^23^00494^Special Coverage Approval Title |
| GT1^49^00785^Job Title |
| IN2^46^00785^Job Title |
| STF^18^00785^Job Title |
Protective equipment needed for the job performed by the employee for the employer. For example, safety glasses, hard hat.
The salary amount paid by the employer to the employee.
OpenIssue: Is this the amount paid per the value specified in salary_type_cd?
Vocabulary domain: EmployeeSalaryType (CWE)
Attribute description:A code categorizing the calculation method used by the employer to compute the employee's salary. For example, hourly, annual, commission.
|
|
|
A detailed categorization, based upon included procedures and diagonses, that applies to the encounter.
OpenIssue: 1) This description does not appropriately appear to fit with the actual meaning of the class itself and is internally inconstent.. 2) The meaning of this class is ambiguous based upon its instance connections and attributes.
An indication that the DRG assignment has been or has not been approved by a reviewing entity.
Version 2.x reference:| DG1^9^00383^DRG Approval Indicator |
| DRG^3^00383^DRG Approval Indicator |
An indication as to whether the DRG assigned to this encounter contains a confidential diagnosis.
Version 2.x reference:| DG1^18^00767^Confidential Indicator |
| DRG^10^00767^Confidential Indicator |
The amount of the encounter cost that is beyond the standard cost amount for the assigned DRG.
Version 2.x reference:| DG1^13^00387^Outlier Cost |
| DRG^7^00387^Outlier Cost |
A description providing additional information about the assignment of the DRG to the encounter.
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code indicating that the grouper results have been reviewed and approved.
Version 2.x reference:| DG1^10^00384^DRG Grouper Review Code |
| DRG^4^00384^DRG Grouper Review Code |
The version and type of the grouper used to derive the DRG.
OpenIssue: Either the description or the attribute type of this attribute is wrong. If it is type ID, then it is simply 'The identifier of the grouper . . .' If it is both version and type, then there should be two attributes to hold this data.
Version 2.x reference:| URS^4^00055^R/U What User Qualifier |
The number of days beyond the standard day count for the assigned DRG.
Rationale: This attrubute is required to meet reporting requirements on DRGs as imposed by HCFA.
Version 2.x reference:| DG1^12^00386^Outlier Days |
| DRG^6^00386^Outlier Days |
The portion of the total reimbursement amount designated for reimbursement of outlier days or costs.
Version 2.x reference:| DRG^9^00771^Outlier Reimbursement |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting the type of outlier (day, cost) associated with the encounter DRG.
Rationale: This is the v2.3 reference
OpenIssue: This attribute and the attribute outlier_reimbursement_amt do not work together. Either this is the outlier_reimbursement_type_cd or the definition of outlier_reimbursement should be changed to correspond to the definition of outlier_days_amt.
Version 2.x reference:| DG1^11^00385^Outlier Type |
| DRG^5^00385^Outlier Type |
|
|
|
|
|
|
Entities are physical things or organizations and groupings of physical things. A physical thing is anything that has extent in space, and has mass. This hierarchy encompasses human beings, organizations, living organisms, devices, pharmaceutical substances, etc. This does not include events/acts/actions, the definition of things, the roles which things can play (e.g. patient, provider), nor the relationships among things.
Rationale: Participants in acts MUST be roles of entities. Subjects of physical acts MAY be roles of entities, however not everything that an act is focused on must be an entity (e.g., when treating a human patient, the human patient is an entity, but solving a problem or thinking about an issue does NOT make the problem or the issue an entity.)
OpenIssue: Rational may belong in a different part of the model.
Vocabulary domain: EntityCode (CWE)
Attribute description:This is the main classifying attribute of the Entity class and all of its subclasses. This code indicates what kind of Entity is meant using a code from one of several coding systems depending on the class of entities, such as living subjects (typed by animal and plant taxonomies), chemical substance (e.g., IUPAC code), organizations, insurance company, government agency, hospital, park, lake, syringe, etc. Note that the entity type code may be so fine grained that some types may only have one known instance. Types with an extension of one instance are very similar to names. An example is the CDC vaccine manufacturer code, which is modeled as a concept vocabulary, when in fact each concept refers to only one instance. However, type codes SHOULD NOT normally be so fine grained as of overlap with instance identification.
Version 2.x reference:| IN2^14^00485^Champus Service |
Vocabulary domain: EntityClass (CNE)
Attribute description:A code specifying on a high, technical, and tightly controlled level the kind of entity. This code is similar in nature as the names of the classes derived from entity in a refined message information model (R-MIM.)
Version 2.x reference:| GT1^10^00414^Guarantor Type |
| LOC^3^00945^Location Type-LOC |
The description of an Entity is a piece of free text or multimedia data that describes the Entity in all necessary detail. There is no restriction on length or content imposed on the Entity.desc attribute. However, the content of the description is not considered part of the functional information communicated between systems. Descriptions are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects.
Vocabulary domain: Determiner (CNE)
Attribute description:The Entity.determiner_cd makes specific the denotation of an Entity object, i.e., whether the information in the Entity object refers to a class of things (Entity.determiner_cd = "kind"); a specific real world thing instance (Entity.determiner_cd = "instance"); or a quantified grouping within a 'kind' (Entity.determiner_cd = "quantified kind"), which might be used for instance to define the quantity and makeup of subjects needed for a clinical trial.
Vocabulary domain: EntityHandling (CWE)
Attribute description:A code to describe how the Entity needs to be handled to avoid damage to it or other entities. Examples include: Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.
A unique identifier for an entity. Ideally each entity will have only one identifier assigned to it, however, since different systems will maintain different data bases, there may be different instance identifiers assigned by different systems. Note that an instance identifier is a pure identifier and not a classifier. That means, this identifier is not used to store information about what kind or type of entity this is. Note that for Material, serial numbers assigned by specific manufacturers, catalog numbers of specific distributors, or for inventory numbers issued by owners, the Role_relationship.id can also be used. This allows to more clearly express the fact that such a code is assigned by a specific party associated with that material. In any case, all values of Role_relationship.id may occur in Material.id just as well.
EXREF:C04.R097.20
A text string indicating the living subject's economic or psychological importance to the owner.
OpenIssue: There is a problem with this attribute. Shouldn't it be coded? Does it belong here at all?
A name of the entity in the context of the Entity.type_cd attribute.
Specifies the quantity of the given entity in coordination with the determiner_cd. For individual instances of Entities, the qty is 1. For a group of individual members, the qty is the number of individual members in the group. For an instance portion of a substance, the qty specifies the amount of that substance comprised by that portion. For an undetermined substance (kind) the qty servers two purposes at the same time: (a) it provides a means of relations between quantities specific for that substance, and (b) it is a reference quantity for the specification of ingredients or components.
In all cases, the qty is an extensive "amount" kind of quantity (e.g., number, length, volume, mass, surface are, energy, etc.) Note that most relative or fractional quantities are not amounts, in particular, mass fraction, substance concentration, mass ratios, percentages, etc. are not extensive quantities and are prohibited values for this attribute. The following table lists those extensive quantities that should typically be used for this attribute.
Table: Kinds of extensive quantities for amounts of material Kind of quantity|Typical Unit|Forms|Examples| Number|1|solid|Material that is large enough that is can be counted ("eaches")| Mass|1 g|liquid, solid|Tissue chemical substances, food.| Amount of substance|1 mol|all|chemical substances, small particles.| Volume|1 L|liquid, gas|chemical substances in liquid and gas state, amorphic tissue.| Length|1 m|solid|long material measured in length, e.g., tape, pipes, hose, etc.| Area|1 m2|solid|flat material measured in area, e.g., covers, foils, etc.| Energy|1 J, 1 kcal|solid, liquid|chemical substances, especially food.| Catalytic amount|1 kat, 1 U, 1 i.U.|all|enzymes and other chemical substances having catalytic activity.| Radioactivity|1 Bq, 1 Cu|all|radioactive substances.| Reaction equivalent|1 Eq|all|ionized chemical substances measured through titration; deprecated, use proper amount of substance instead.|
Absolute quantities are specified directly as values of this attribute. For example, as a determined instance, 1 person is Person.qty = 1; a group of 5 people is Person.qty = 5; 1 tablet is Material.qty = 1; 30 tablets is Material.qty = 30; 1 mg of Glucose is Material.qty = 1 mg; and 50 mg of Glucose is Material.qty = 50 mg.
With undetermined kinds, the qty is but a reference quantity for the specification of the proportion of ingredients or components (e.g. through a has-part, has-ingredient, or has-content relationship.) For example, a kind of group with 60% females is Person(qty = 100) has-part Person(qty = 60; sex = female). Amoxicillin 500 mg per tablet is Material(Tablet, qty = 1) has-ingredient Material(Amoxicillin, qty = 500 mg). Glucose 50% (D5W) is Material(D5W, qty = 1 kg) has-ingredient Material(Glucose, qty = 50 g).
Material-specific quantity relations are expressed using the fact that the data type of this attribute is a set of physical quantity (SET<PQ>). If more than one qty value are specified in this set, each element in this set is considered to specify the same amount of the material. For example, for one liter of water one could use the set {1 L, 1 kg, 55.56 mol} to specify the volume, mass, and amount of substance for the same amount of water, this is equivalent with specifying the mass density (volumic mass 1 kg/L) and the molar mass (18 g/mol). For Glucose one could specify {180 g, 1 mol} according to the molar mass (180 g/mol).
OpenIssue: Needs data type: suggest set<PQ>
Vocabulary domain: EntityRisk (CWE)
Attribute description:A code indicating the existence of a risk or hazard associated with the Entity.
Vocabulary domain: EntityStatus (CNE)
Attribute description:The status_cd tracks the state of the Entity's state-transition model. This is typically a rather trivial state-transition model.
OpenIssue: The state transition model needs to be defined.
The telecom addresses for the organization.
Version 2.x reference:| PID^13^00116^Phone Number - Home |
| NK1^6^00195^Business Phone Number |
| GT1^6^00410^Guarantor Ph Num- Home |
| GT1^7^00411^Guarantor Ph Num-Business |
| GT1^18^00422^Guarantor Employer Phone Number |
| IN1^7^00432^Insurance Co Phone Number |
| IN3^16^00517^Certification Contact Phone Number |
| IN3^19^00520^Certification Agency Phone Number |
| OM1^17^00602^Telephone Number of Section |
| OM1^29^00614^Phone Number of Outside Site |
| GT1^46^00749^Contact Person's Telephone Number |
| NK1^31^00749^Contact Person's Telephone Number |
| IN2^50^00790^Employer Contact Person Phone Number |
| IN2^53^00793^Insured's Contact Person Telephone Number |
| IN2^58^00798^Insurance Co Contact Phone Number |
| IN2^63^00803^Insured's Telephone Number - Home |
| IN2^64^00804^Insured's Employer Telephone Number |
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 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 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. Subseqent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
|
|
|
|
An act utilized primarily for administrative (versus clinical) purposes.
The monetary value of a financial act after any applicable discounts and adjustments have been applied.
This attribute can be used to represent concepts that include the balance of a financial account, the value of a financial transaction, and the value of an invoice line item or adjustment.
|
Vocabulary domain: PaymentTerms (CWE)
Attribute description:Establishes the payment terms for a contractual agreement or obligation. Examples are "net 30", "on receipt of invoice", "upon completion of service", etc.
|
|
A sub-class of Act representing any transaction between two accounts whose value is measured in monetary terms.
In the "intent" mood, communicates a request for a transaction to be initiated, or communicates a transfer of value between two accounts.
In the "event" mood, communicates the posting of a transaction to an account.
A ratio indicating the rate of exchange in effect between the currency of the account being credited, and the currency of the transaction value.
The numerator should be expressed as a quantity in the currency of the credit account, and the denominator should be expressed as a quantity in the currency that the transaction is being reported in. For example, for the purchase of services valued in Mexican pesos using U.S. dollars paid from a Canadian dollar account, the credit exchange ratio would be communicated as the ratio: n CAD / n USD.
Rationale: this approach ensures that a common reporting mechanism is used, from the perspective of the value of the transaction, which is used to communicate the value of the act.
A ratio indicating the rate of exchange in effect between the currency of the account being debited, and the currency of the transaction value.
The numerator should be expressed as a quantity in the currency of the debit account, and the denominator should be expressed as a quantity in the currency that the transaction is being reported in. For example, for the purchase of services valued in Mexican pesos using U.S. dollars paid from a Canadian dollar account, the debit exchange ratio would be communicated as the ratio: n MXP / n USD.
Rationale: this approach ensures that a common reporting mechanism is used, from the perspective of the value of the transaction, which is used to communicate the value of the act.
A ratio that indicates the rate of interest that the transaction value is subject to and the term over which the interest rate compounds.
The numerator is the interest rate and the denominator is the compounding term.
Vocabulary domain: PaymentTerms (CWE)
Attribute description:Establishes the payment terms for a particular financial transaction. Examples are "net 30", "on receipt of invoice", "upon completion of service", etc.
|
The double role-based assocation between a party in the role of guarantor and an organization in the role of healthcare provider .
Vocabulary domain: CreditRating (CWE)
Attribute description:A code depicting the credit rating (e.g., excellent, good, fair, questionable, poor).
Version 2.x reference:| PV1^23^00153^Credit Rating |
| GT1^23^00774^Guarantor Credit Rating Code |
|
|
|
A contract held by a stakeholder which specifies the financial responsibility of the stakeholder for a patient billing account.
A indicator used to determine whether or not a system should suppress printing of the guarantor's bills.
Version 2.x reference:| GT1^22^00773^Guarantor Billing Hold Flag |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting the allowable mediums for billing under this guarantor contract.
Version 2.x reference:| PV2^32^00733^Billing Media Code |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting which adjustments should be made to this guarantor's charges.
Version 2.x reference:| GT1^26^00777^Guarantor Charge Adjustment Code |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code specifying the duration of the contract.
OpenIssue: This does not appear to be a coded type. In V2.3 it is a NM, with the definition "Specifies the duration of the contract for user-defined periods." If 2.3 is right, it looks like a candidate for _amt with units of time.
Version 2.x reference:| PV1^27^00157^Contract Period |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:Code identifying the type of contract entered into by the guarantor for the purpose of settling outstanding account balances.
Version 2.x reference:| PV1^24^00154^Contract Code |
The rate of interest for this guarantor contract.
Version 2.x reference:| PV1^28^00158^Interest Code |
Amount to be paid by the guarantor each period.
Version 2.x reference:| PV1^26^00156^Contract Amount |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code indicating the relative priority of this guarantor contract for a given patient billing account.
OpenIssue: If this is really a code, then give examples. It actually sounds like a priority number, in which case it should be priority_ranking_nbr.
Version 2.x reference:| GT1^15^00419^Guarantor Priority |
|
|
|
Class to contain unique attributes of diagnostic imaging equipment.
Vocabulary domain: PixelIntensityRelationship (CWE)
Attribute description:The relationship between the Pixel sample values and the X-Ray beam intensity.
Value of pixels added to non-rectangular image to pad to rectangular format.
The inherent limiting resolution in mm of the equipment for high contrast objects for the data gathering and reconstruction technique chosen. If variable across the images of the series, the value at the image center.
|
A patient encounter involving a stay in an inpatient Healthcare_facility.
Length of stay when evaluated on discharge from hospital. The actual days quantity can not be simply calculated from the admission and discharge dates because of possible leaves of absence.
OpenIssue: Should there be a boolean indicator to specify "estimated" vs. "actual" rather than having this attribute mean two things?
Version 2.x reference:| PV2^11^00712^Actual Length of Inpatient Stay |
|
|
|
A sub-type of Act that provides support for the full range of information requirements for invoice processing in healthcare. The class will be used in at least three moods - definition, order and event - and with a variety of both class_cd and cd values to distinguish them.
In the "definition" mood, this class provides for the specification of component items covered by health insurance plans and policies. These items may in turn be linked to one or more billable acts in definition mood to specify the coverages.
In the "order" mood, this class becomes an "invoice" (or claim) containing a set of items (also instances of this class), associated to the billable acts covered by the items and the policies under which the invoice is asserted, etc. When instances of this class exist in relationship with instances of authorization or eligibility, are used to communicate the details of requests for authorization or eligibility inquiries.
In the "event" mood, this class represents the action (result) undertaken in response to the claim. This includes a set of processing results and adjustments instantiated from this class that reflect the specific coverage decisions related to each of the items in the ordered invoice.
The context for this class is established, as usual, by a combination of act relationships, participations and roles which undertake the participations.
Act relationships provide for: compositional relations between plans, policies and sub-policies; compositional relations between invoices, invoice item groups and invoice items; compositional relations between processing results and adjustments within a single result; and reference relationships between one invoice item and another or from a processing result (event) to the invoice item (order) to which it responds.
Participation types used by this class include: "beneficiary," which reflects a "covered party" (role) as the target of a coverage policy or item, and which provides for coordination-of-benefits sequencing among a set of covered parties; and "policy holder" which is in the domain ServiceTargetType.
Vocabulary domain: CoverageSource (CWE)
Attribute description:A code depicting the source of information about the coverage (e.g., insurance company, employer, insured presented policy, insured presented card, signed statement on file, verbal information, none, . . .).
Version 2.x reference:| IN2^27^00498^Eligibility Source |
Used in financial calculations to derive gross amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving gross amounts is: Units (Quantity) * Cost/Unit = Gross Amount
The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: Units (Quantity) * Cost/Point * Factor = Gross Amount
For example, this could be 10 (Number of Treatments as Units) * $3.00 (Cost per Unit) * 1.5 (Factor) = $45.00 (Gross Amount).
See related note on Points. Formula, with Points and Factors becomes: Units * Cost/Unit * Points * Factor = Gross Amount
The monetary value of an invoice element before any applicable discounts and adjustments have been applied.
Computed as the item_nbr times the unit_nbr.
Version 2.x reference:| FT1^11^00365^Transaction Amount - Extended |
The number of instances of a good or service that are being reported in the invoice element.
For example, when specifying psychiatric coverage limitation - 50 outpatient visits per year, it would have the value 50; when specifying physician office visit-$15 co-pay out-of-network, it would have the value 15. The unit of measure is specified by the quantity_qualifier_cd.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
Version 2.x reference:| FT1^12^00366^Transaction Amount - Unit |
| IN1^33^00458^Lifetime Reserve Days |
| IN1^34^00459^Delay Before L. R. Day |
| IN1^37^00462^Policy Deductible |
| IN1^39^00464^Policy Limit - Days |
| IN2^21^00492^Blood Deductible |
| IN2^28^00499^Room Coverage Type/Amount |
| IN2^29^00500^Policy Type/Amount |
| IN2^30^00501^Daily Deductible |
| IN3^11^00512^Days |
Vocabulary domain: InvoiceItemQualifier (CWE)
Attribute description:Indicates the type of good or service that is being reported in the invoice element.
For example, when specifying psychiatric coverage limitation - 50 outpatient visits per year, the quantity would be 50 and the quantity qualifier code would be outpatient visits; when specifying inpatient stop-loss of $2000 USD per inpatient stay, the quantity would be 2000 and the quantity qualifier code would be USD.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction
Version 2.x reference:| IN1^33^00458^Lifetime Reserve Days |
| IN1^34^00459^Delay Before L. R. Day |
| IN1^37^00462^Policy Deductible |
| IN1^39^00464^Policy Limit - Days |
| IN2^21^00492^Blood Deductible |
| IN2^28^00499^Room Coverage Type/Amount |
| IN2^29^00500^Policy Type/Amount |
| IN2^30^00501^Daily Deductible |
Vocabulary domain: InvoiceElementModifier (CWE)
Attribute description:Designates a modifier to the cd attribute to provide additional information about the invoice element.
In the "intent" mood, communicates processing consideration information.
In the "event" mood, communicates information about sub-trees of the coding system utilized in the cd attribute for additional information, clarification, etc.
A flag indicating whether the details of the invoice processing results (usually an authorization or an adjustment) should be communicated directly to the covered party involved.
Used in financial calculations to derive gross amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving gross amounts is: Units (Quantity) * Cost/Unit = Gross Amount
The concept of Points allows for assignment of point values for services and/or goods, such that a dollar amount can be assigned to each point. For example, the formula, with points would be: Units (Quantity) * Points * Cost/Point = Gross Amount
For example, this could be 5 (Number of Treatments as Units) * 3 (Number of Points per treatment as Points)* $20.00 (Cost per Point) = $300.00 (Gross Amount).
See related note on Factor. Formula, with Points and Factors becomes: Units * Cost/Unit * Points * Factor = Gross Amount
The monetary cost per unit being accounted. In constructing the ratio, the numerator must of data type MO, and the denominator should either be a PQ, or else it should be a dimensoinless number (INT or REAL) with the units determined by the item_qualifier_cd.
Version 2.x reference:| FT1^10^00364^Transaction Quantity |
| FT1^22^00374^Unit Cost |
|
|
Class reflects the language communication capabilities for an Entity, showing 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.
Vocabulary domain: HumanLanguage (CWE)
Attribute description:A code indicating the language being communicated by the Entity (e.g. Spanish, Italian, German).
Version 2.x reference:| GT1^36^00118^Primary Language |
| IN2^34^00118^Primary Language |
| NK1^20^00118^Primary Language |
| PID^15^00118^Primary Language |
Vocabulary domain: LanguageAbilityMode (CWE)
Attribute description:A code depicting the method of expression of the language (e.g. expressed spoken, expressed written, expressed signed, received spoken, received written, received sign)
An indication of whether or not the language is the one preferred by the entity for the indicated mode.
Vocabulary domain: LanguageAbilityProficiency (CWE)
Attribute description:A code classifying the level of proficiency in the language (e.g. excellent, good, fair, poor)
|
|
|
|
|
An organism or complex animal, alive or not. Instances of this class encompass mammals, birds, fishes, bacteria, parasites, fungi and viruses. Person is a specialization of this class.
Vocabulary domain: AdministrativeGender (CWE)
Attribute description:A code depicting the gender (sex) of a person (e.g., female, male). This code is used for administrative purposes.
ExtRef: This information is reported on UB FL 15.
Version 2.x reference:| NK1^15^00111^Sex |
| PID^8^00111^Sex |
| STF^5^00111^Sex |
| GT1^9^00413^Guarantor Sex |
| IN1^43^00468^Insured's Sex |
For newborn living subjects in a multiple birth, the order in which this living subject was born.
Version 2.x reference:| PID^25^00128^Birth Order |
The date and time of a living subject's birth or hatching.
An indication that the subject is dead.
The date and time that a living subject's death occurred.
A indication as to whether the living subject is part of a multiple birth.
Version 2.x reference:| PID^24^00127^Multiple Birth Indicator |
An indication that the living subject is (as in "has donated" or "is willing to donate") an organ donor.
Version 2.x reference:| PD1^8^00760^Organ Donor |
|
|
|
|
Things or combination of things transformed for a particular purpose by a non-natural or manufacturing process. This class encompasses containers, devices, software modules and facilities.
The date and time the manufacturer stops ensuring the safety, quality, and/or proper functioning of the material.
OpenIssue: Given the definition of Material.effective_tmr, it doesn't appear that this attribute is necessary. If it is necessary, it belongs in the Material class, since non-Manufactured_materials can also expire.(e.g. eggs as food).
The lot number is a number used to identify a particular batch of manufactured material. It is usually printed on the label attached to the container holding the substance and on the packaging which houses the containerNote that a lot number is not meant to be a unique identifier, but is meaningful only when the product kind and manufacturer are also identified.
|
|
|
A Material is an Entity that excludes Living_subjects and places. Manufactured or processed products are considered material, even if they originate in living matter. Parts (e.g. organs) derived from living subjects are Material that may need to be tracked through associations with the individual Living_subject from which they were obtained. Examples of Material are 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.
The time interval a certain Material is in existence. The high boundary of this interval is the expiration date if it is defined for the Material. An expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.
Vocabulary domain: MaterialForm (CWE)
Attribute description:This is a classifier describing the form of the material. This includes the typical state of matter (solid, liquid, gas) and, for therapeutic substances, the dose form.
OpenIssue: Vocabulary domain should include, but is broader than, the DoseForm domain.
|
|
|
A non-human living subject..
Vocabulary domain: NonPersonLivingSubjectBreed (CWE)
Attribute description:A code representing the breed of the living subject.
An indication that the living subject was euthanized.
Vocabulary domain: GenderStatus (CWE)
Attribute description:A code indicating the whether the reproductive organs of Non_person_living_subject have been surgically removed.
Vocabulary domain: LivingSubjectProductionClass (CWE)
Attribute description:A code indicating the primary use for which the living subject was bred or grown.
A text string representing the genotypic or phenotypic strain of the living subject.
Vocabulary domain: NonPersonLivingSubjectTaxonomicClassification (CWE)
Attribute description:A code representing the taxonomy of the living subject.
|
|
|
|
|
Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value) include specific information about the observed object. The type and constraints of result values depend on the kind of action performed.
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.
The observation action (Observation.type_cd) and observation result (Observation.value) are modeled as two aspects of the same concept, just like the two faces of a coin are not separable from each other. Most other published healthcare models, including earlier HL7 RIM versions, separate the activity of observing and the observation result into different classes. These models label the kind of action in one class and the kind of observation result in the other. In most cases, however, the test name is a label for both activity (Observation.type_cd) and the observation result (Observation.value).
Derived observations can be defined through association with other observations using relationships of derivation type (Act_relationship.type_cd = derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with a Hemoglobin (HGB) observation (Act_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (Act_relationship.sequence_nmb = 2) Since MCH = HGB / RBC, the value of the derivation expression would be "$1 / $2".
The derivation expression is a character string with a simple syntax similar to that of the UNIX "expr" utility, or the expression subset of the PERL or TCL language. All observations that are cited in the formula must be associated with the derived observation through links of type derivation with a unique Act_relationship.sequence_nmb. Such observation values are referred to by that sequence number preceded by a dollar sign ($).
Defined operators are addition (+), subtraction (?), multiplication (*) and division (/). Parentheses can be used to overcome the usual precedence (left to right, multiplication before addition.) In addition to the basic arithmetic operations the usual mathematical functions are defined.
Vocabulary domain: ObservationInterpretation (CWE)
Attribute description:This attribute allows for a very rough interpretation of the course or outcome of a service action. This is sometimes called "abnormal flags", however, the judgement of normalcy is just one of the common rough interpretations, and is often not relevant. For example, for the observation of a pathologic condition, it doesn't make sense to state the normalcy, since pathologic conditions are never considered "normal."
Vocabulary domain: ObservationMethod (CWE)
Attribute description:For any Observation there may be several different methods to achieve by and large the same result, but may be important to know when interpreting a report more thoroughly (e.g., blood pressure method: arterial puncture vs. Riva-Rocci, sitting vs. supine position, etc.) Method concepts can be "pre-coordinated" in the Observation.type_cd, so that there is never an option to select different methods. There are so many possible methods which all depend heavily on certain kinds of services, so that defining a vocabulary domain of all methods is difficult
However, a code system might be designed such that it specifies a set of available methods for each defined service concept. Thus, a user ordering a service could select one of several variances of the service by means of the method code. Available method variances may also be defined in a master service catalog for each defined service. In service definition records (Observation.mood_cd = DEF) the method_cd attribute is a set of all available method codes that a user may select while ordering, or expect while receiving results.
Vocabulary domain: ObservationTargetSite (CWE)
Attribute description:The anatomical site or system that is the focus of the observation, if applicable. Most observation target sites are implied by the observation code and definition. For example, "heart murmur" always has the heart as target. This attribute is used when the observation target site needs to be refined, to distinguish right and left etc.
If the subject of the Observation is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses. For example, if the subject is a lake, the site could be inflow and outflow, etc. If the subject is a lymphatic node, "hilus," "periphery," etc. would still be valid target sites.
The result value of an observation action. As was true with HL7 v2, this value can be of any data type. However, there are clearly more or less reasonable choices of data types as indicated below.
Kind of observation :: Data type ::Notes
(1) Quantitative measurements :: PQ ::Physical quantity (real number with unit.) This is the most usual choice. Note that numeric values must not be communicated as a simple character string (ST.)
(2) Titer (e.g., 1:64) and other ratios (e.g. 1 out of 1000) :: RTO :: A ratio of two integer numbers (e.g., 1:128.) Sometimes by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32) Such conventions are confusing and should not be followed in HL7 messages.
(3) Index (number without unit) :: REAL :: When a quantity does not have a proper unit, one can just send the number as a real number. Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %). An integer number should only be sent when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see below.)
(4) Ranges (e.g., < 3; 12-20) :: IVL<PQ> :: Interval of physical quantity. Note that sometimes such intervals are used to report the uncertainty of measurement value. For uncertainty there are dedicated data type extensions available.
(5) Ordinals (e.g., stage "IIa") :: CV, INT :: At this point, ordinals should be reported either as code values, (e.g., +, ++, +++; or I, IIa, IIb, III, IV) or as integers. In the future ordinals may be addressed by a separate data type.
(6) Nominal results, "taxons" (e.g. organism type.) :: CD :: The Concept Descriptor (CD) is the most common data type to use for categorical results (e.g., diagnosis, complaint, color.) Such qualitative results are rarely simple Code Values (CV) if there is a tightly defined code system which everyone uses.
(7) Image (still, movie) :: ED :: The encapsulated data type allows one to send an image (e.g., chest X-ray) or a movie (e.g., coronary angiography, cardiac echo.)
(8) Waveform :: Waveforms can be sent using the waveform template developed by the Automated Data SIG for version 2.3. A mapping onto version 3 is shown farther below. In addition one can use the Encapsulated Data (ED) data type to send waveforms in other formats.
(9) Formalized expressions :: ST :: The character string data type may exceptionally be used to convey formalized expressions that do not fit in any of the existing data types. However, use of the string data type is not allowed if the meaning can be represented by one of the existing data types. Note that many of the data types do have character string literal expressions too, so the field in the message can be formatted using character string literals and still have a distinct data type.
OpenIssue: We should revisit the proper attribute to be used to transmit clinical documents.
|
|
A formalized group of people with a common purpose (e.g. administrative, legal, political) and the infrastructure to carry out that purpose. Examples include companies and institutions, a government department, an incorporated body that is responsible for administering a facility, an insurance company.
The postal and residential addresses of an organization.
Version 2.x reference:| PID^11^00114^Patient Address |
| PID^12^00115^County Code |
| NK1^4^00193^Address |
| GT1^5^00409^Guarantor Address |
| GT1^17^00421^Guarantor Employer Address |
| IN1^5^00430^Insurance Company Address |
| IN1^19^00444^Insured's Address |
| IN1^44^00469^Insured's Employer Address |
| OM1^28^00613^Address of Outside Site(s) |
Vocabulary domain: OrganizationIndustryClass (CWE)
Attribute description:The standard industry class code of the organization.
|
An Outbreak is a Public_health_case where the occurrence in a community or region of cases of an illness in excess of those normally expected. The designation of an outbreak implies that a public health assessment of causality or at least of relatedness among cases has taken place. An outbreak is considered to be a special type of public health case (where a case, in this instance, may include many affected individuals), and may not simply be an aggregate of multiple cases although an outbreak may also be designated as an aggregate of multiple individual public health cases.
The period of time during which the outbreak takes place. The date on which an outbreak starts is the earliest date of onset among the cases assigned to the outbreak, and its ending date is the last date of onset among the cases assigned to the outbreak.
OpenIssue: Needs additional thought. Consider that this is already available.
|
|
|
Participation defines how an Entity, in a particular Role, functions during the scope of an Act. Participation is limited to the scope of the Act, as opposed to Role, which defines the competency of an Entity irrespective of any Act. Note that a particular Entity in a particular Role can participate in an Act in many ways. Thus, a Person in the Role of Individual_healthcare_practitioner, can participate in a Patient_encounter as an a rounding physician or as an attending physician.
All people, things and locations involved in an Act (or for scheduling purposes "all resources of an activity") are associated with the Act as either actors or targets. Actors are mostly professional provider personnel, but also the patient (for self-administered services,) or a proxy (e.g. next of kin.) Actors can participate in an action in different ways. For example, primary surgeon, assistant surgeon, sterile nurse, and nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action. However, payers, supervisors, provider organizations (e.g., "MicroLab") and their delegates may be actors too, even though they might not be individual persons who have their "hands on" the action. The patient himself is a performing actor in self-care procedures (e.g. fingerstick blood glucose, insulin injection, etc.) The people and organizations that can be actors of a service action are capable of and accountable for their independent decisions. Capability of independent decision and accountable usually applies only to persons under the law, including both organizations and natural (human) persons. The notion of multiple actors, each with a specific Participation.type_cd (and possibly a Participation.function_cd), touches and partially overlaps the Role.type_cd of the involved Entity, and understanding the distinctions is important to use the RIM constructs correctly. On the one "side" actor functions look similar to Entity roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g., certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.) The professional credentials of a person may be quite different from what a person actually does. The professional credentials define an Entity's Role while what a person actually does during the course of an Act is defined by the Participation class. The most common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists. The opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse. Thus, roles and certification refer to the static capabilities of a person (person-related) while actors and Participation.type_cd refer to the particular function an actor played in the Act (activity-related.) The actor concept interferes with sub-activities. 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 modeled as an Act consisting of sub-services (through the Act_relationship class,) where each service 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) anesthesist. These three actors really perform different tasks, which can be represented as three related services: (a) the consent, (b) the surgery proper, and (c) the anesthesia service in parallel to the surgery. If we used the sub-services, the consenter, surgeon and anesthesist could simply be of actor type "performer." Thus the more sub-services we use, the fewer different actor types need to be distinguished, and the fewer sub-services we use, the more distinct actor types we need. Note that the perception of a task as "atomic" or "composite" (of sub-tasks) depends on local business rules and may differ from department to department. In principle, every task can be thought of as being a composite of sub-tasks. We thus say that actions are "fractal." The paradigmatic example of the fractal nature of activities is a "robotic arm" doing some simple action as reaching for a tool in front of it. The seemingly simple activity of the robotic arm decomposes into complex control and coordination procedures and movements, action of separate motors and switches, etc. (We sometimes use the key-phrase "robotic arm discussion" to recall the fractal nature of actions, since this example has been brought up over and over again, independently by different people.) 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 muli-service approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall service. Actors can participate in an action in different ways. For example, primary surgeon, assistant surgeon, sterile nurse, and nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action. However, payers, supervisors, provider organizations (e.g., "MicroLab") and their delegates may be actors too, even though they might not be individual persons who have their "hands on" the action. The patient himself is a performing actor in self-care procedures (e.g. fingerstick blood glucose, insulin injection, etc.)
The Stakeholders, people and organizations that can be actors and targets of a service action are capable of and accountable for their independent decisions. Capability of independent decision and accountable usually applies only to persons under the law, including both organizations and natural (human) persons. This "legal person" as a subject of legal rights and obligations is a very obvious interpretation of the RIM Stakeholder construct (it is a well-known legal notion.)
The notion of multiple actors with specific functions touches and partially overlaps on two "sides" with related concepts of the RIM, and understanding the distinctions is important to use the RIM constructs correctly. On the one "side" actor functions look similar to Stakeholder roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g., certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.) The professional credentials of a person may be quite different from what a person actually does. The most common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists. The opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse. Thus, roles and certification refer to the static capabilities of a person (person-related) while actors and Actor.type_cd refer to the particular function an actor played in the service (activity-related.)
On the other "side" the actor concept interferes with sub-activities. Whenever multiple actors are involved in a service, 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 modeled as a service consisting of sub-services (through the Service_relationship class,) where each service 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) anesthesist. These three actors really perform different tasks, which can be represented as three related services: (a) the consent, (b) the surgery proper, and (c) the anesthesia service in parallel to the surgery. If we used the sub-services, the consenter, surgeon and anesthesist could simply be of actor type "performer." Thus the more sub-services we use, the fewer different actor types need to be distinguished, and the fewer sub-services we use, the more distinct actor types we need.
Note that the perception of a task as "atomic" or "composite" (of sub-tasks) depends on local business rules and may differ from department to department. In principle, every task can be thought of as being a composite of sub-tasks. We thus say that actions are "fractal." The paradigmatic example of the fractal nature of activities is a "robotic arm" doing some simple action as reaching for a tool in front of it. The seemingly simple activity of the robotic arm decomposes into complex control and coordination procedures and movements, action of separate motors and switches, etc. (We sometimes use the key-phrase "robotic arm discussion" to recall the fractal nature of actions, since this example has been brought up over and over again, independently by different people.)
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 muli-service approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall service.
Vocabulary domain: TargetAwareness (CWE)
Attribute description:Indicates whether the associated patient or family member is aware of the service, and especially of the observation made. For example, a patient (or his next family members) may not be aware of a malignancy diagnosis, the patient and family may be aware at different times, and some patients may go through a phase of denial.
Vocabulary domain: EncounterAccomodation (CWE)
Attribute description:A code depicting the type of accommodation associated with this patient encounter (e.g., private, semi-private) during the period of time the encounter was associated with the specific Place.
Version 2.x reference:| PV2^2^00182^Accommodation Code |
Vocabulary domain: ParticipationFunction (CWE)
Attribute description:This attribute describes the business function of a Participant in more detail. It can accommodate the huge variety and nuances of functions that Participants may perform in the service. The number and kinds of functions applicable depends on the special kind of service. E.g., each operation and method may require a different number of assistant surgeons or nurses.
Vocabulary domain: ParticipationMode (CWE)
Attribute description:A code specifying how the participant is involved in the act, e.g., as physically present, over the telephone, or in written communication. Particularly for author (originator) participants this is used to specify whether the information represented by the act was initially provided verbally, (hand)written, or electronically.
A Participant can make a comment about this service item in the note_text attribute.
Attribute permits sequencing between multiple participations for an act. The sequencing might be undertaken for functional reasons or to establish a priority between participations. One example is the sequencing of covered party participations to establish a coordination of benefits sequence in insurance claims.
Vocabulary domain: ParticipationSignature (CWE)
Attribute description:Specifies whether the participant has performed some sort of signature for his participation in the act or whether such a signature is required. For example, a surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants. See also: Participation.signature_txt.
The signature by which the associated Entity endorses that its participation in the Act is as stated in the Participation.type_cd and that it assumes accountability for the Act accordingly. For example, an AUTHOR assumes accountability for the truth of the Act statement to the best of his knowledge, whereas an information RECIPIENT would only sign the fact that he has received the information.
The signature can be represented in many different ways either inline or by reference according to the ED data type. Typical cases are:
1) Paper-based signatures: the ED data type may refer to some document or file that can be retreived through an electronic interface to a hardcopy archive.
2) Electronic signature: this attribute can represent virtually any electronic signature scheme.
3) Digital signature: in particular, this attribute can represent digital signatures, for example, by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
Vocabulary domain: ParticipationStatus (CNE)
Attribute description:A code depicting the state of the participation (e.g., pending, active, complete, cancelled).
The effective time range of the participation. Note that this is particularly important when the time range of the participation is less than the time range of the act.
Vocabulary domain: ParticipationType (CNE)
Attribute description:Identifies the particular kind of Participation that an Entity performs in the Act. In practice, there are very many different participation types whose names and responsibilities vary. The number and kinds of involved participants also depend on the special kind of service. The "ParticipationType" vocabulary domain defines a few orthogonal axes along which Participation types can be defined more regularly. For example, one axis represents the physical performance of the action, another axis represents the responsibility for the action, yet another represents authoring the information in the Act object. A Participant can have one or more of these types to a certain degree. However, the business semantics of these types is too variant to be mathematically analyzed. For this reason, we split the coding of the kind of Participant's involvement into two attributes. The Participant.type_cd contains only categories that have crisp semantic relevance in the scope of HL7. It is a coded attribute without exceptions and no alternative coding systems allowed. Conversely, the Participation.function_cd is a mostly locally defined descriptor for the kind of professional activity carried out by the participant.
Version 2.x reference:| IN1^20^00445^Assignment of Benefits |
| IN1^21^00446^Coordination of Benefits |
| IN1^22^00447^Coord of Ben. Priority |
| IN2^5^00476^Mail Claim Party |
| IN2^19^00490^Baby Coverage |
| IN2^59^00799^Policy Scope |
|
|
A relationship between a Living_subject in the Role of patient and a Healthcare_provider, typically established for the provision of healthcare services to the patient by the provider.
OpenIssue: * Refer to PAFM for business rules and appropriate code sets.
Vocabulary domain: Confidentiality (CWE)
Attribute description:A code depicting the nature of publicity protections in place for this patient.
Version 2.x reference:| GT1^38^00743^Publicity Indicator |
| IN2^36^00743^Publicity Indicator |
| NK1^22^00743^Publicity Indicator |
| PD1^11^00743^Publicity Indicator |
| GT1^39^00744^Protection Indicator |
| IN2^37^00744^Protection Indicator |
| NK1^23^00744^Protection Indicator |
| PD1^12^00744^Protection Indicator |
Vocabulary domain: PatientImportance (CWE)
Attribute description:An indication of the person's VIP type, for example, board member, diplomat, etc..
Version 2.x reference:| PV1^16^00146^VIP Indicator |
|
|
|
|
n interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, 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.
OpenIssue: States of patient encounter (#234).
Vocabulary domain: EncounterAccident (CWE)
Vocabulary domain: EncounterAcuity (CWE)
Attribute description:A code depiciting the acuity (complexity of patient care, resource intensiveness of the patient care) of a patient's medical condition upon arrival. Values may be derived from formal acuity coding schemes such as RBS.
OpenIssue: PAFM and PC must work together on defining the concept of severity in the model.
Vocabulary domain: EncounterAdmissionSource (CWE)
Attribute description:The source of the referral for a patient encounter.
A indication that the Living_subject was born during this Patient_encounter.
Version 2.x reference:| PV2^36^00737^Newborn Baby Indicator |
Vocabulary domain: EncounterDischargeDisposition (CWE)
Attribute description:A code depicting the actual disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical advice, etc.).
Rationale: Clarification of definition
Version 2.x reference:| PV1^36^00166^Discharge Disposition |
Vocabulary domain: PracticeSetting (CWE)
Attribute description:A categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) in which care is delivered. (Note that there is a many-to-many relationship between practice setting and the physical location where care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.)
An indication that pre-admission tests are required for this patient encounter.
Version 2.x reference:| PV1^12^00142^Preadmit Test Indicator |
Vocabulary domain: EncounterReferralSource (CWE)
Attribute description:A code categorizing the source of this patient encounter for reimbursement purposes (e.g., physician referral, transfer from another health care facility, court/law enforcement agency).
Version 2.x reference:| PV1^14^00144^Admit Source |
Vocabulary domain: EncounterSpecialCourtesy (CWE)
Attribute description:A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional courtesy, VIP courtesies.
Version 2.x reference:| PV1^22^00152^Courtesy Code |
Vocabulary domain: EncounterStatusReason (CWE)
Attribute description:A code depicting the reason for the status change (e.g., patient cancelled the scheduled encounter, patient didn't arrive for the encounter).
OpenIssue: Need example values. Consider a more general strategy for dealing with update semantics and corresponding reasons.
Vocabulary domain: EncounterAdmissionUrgency (CWE)
Text describing the patient valuables left for safe keeping.
Version 2.x reference:| PV2^5^00185^Patient Valuables |
Descriptive text identifying where valuables of patient is located.
Version 2.x reference:| PV2^6^00186^Patient Valuables Location |
|
|
|
An individual human being.
The address(es) of a Person.
Version 2.x reference:| PID^11^00114^Patient Address |
| PID^12^00115^County Code |
| NK1^4^00193^Address |
| GT1^5^00409^Guarantor Address |
| GT1^17^00421^Guarantor Employer Address |
| IN1^5^00430^Insurance Company Address |
| IN1^19^00444^Insured's Address |
| IN1^44^00469^Insured's Employer Address |
| OM1^28^00613^Address of Outside Site(s) |
Vocabulary domain: AmbulatoryStatus (CWE)
Attribute description:Identifies the person's transient state of mobility or factors which impact their state of mobility, e.g., ambulates with assistive devices, wheelchair-bound, bed-bound, etc.
OpenIssue: Verify that permanent vs. transient conditions are handled as separate attributes. Note that the presence of this attribute brings up to question the entire issue of observations and metaobservations made by non0clinicians for non-clinical purposes.
Version 2.x reference:| GT1^34^00145^Ambulatory Status |
| IN2^32^00145^Ambulatory Status |
| NK1^18^00145^Ambulatory Status |
| PV1^15^00145^Ambulatory Status |
Vocabulary domain: PersonDisabilityType (CWE)
Attribute description:A code identifying a person's disability, e.g., vision impaired, hearing impaired.
OpenIssue: Need example values.
Version 2.x reference:| GT1^52^00753^Handicap |
| IN1^48^00753^Handicap |
| NK1^36^00753^Handicap |
| PD1^6^00753^Handicap |
Vocabulary domain: EducationLevel (CWE)
Attribute description:The amount of education a person achieved.
OpenIssue: Need example values.
Vocabulary domain: Ethnicity (CWE)
Attribute description:The ethnic group of the person.
OpenIssue: Knowing that this repeats, it may be required that a 'primary' in the list is required as well. There is currently no mechanism to identify the primary in the set in the HMD.
OpenIssue: Need example values.
Version 2.x reference:| GT1^44^00125^Ethnic Group |
| IN2^42^00125^Ethnic Group |
| NK1^28^00125^Ethnic Group |
| PID^22^00125^Ethnic Group |
Vocabulary domain: LivingArrangement (CWE)
Attribute description:A code depicting the living arrangements of a person (e.g., independent household, institution, nursing home, extended care facility, retirement community, etc.). Used for discharge planning, social service assessment, psychosocial evaluation.
Version 2.x reference:| GT1^37^00742^Living Arrangement |
| IN2^35^00742^Living Arrangement |
| NK1^21^00742^Living Arrangement |
| PD1^2^00742^Living Arrangement |
Vocabulary domain: MaritalStatus (CWE)
Attribute description:A code indicating the married or similar partnership status of a person, e.g., married, separated, divorced, widowed, common-law marriage.
This information is reported on UB FL 16
OpenIssue: It is not clear what the temporal values are and whether or not items such as divorced/married are mutually exclusive.
OpenIssue: Probably competing existing code schemes.
Version 2.x reference:| IN2^43^00119^Marital Status |
| NK1^14^00119^Marital Status |
| PID^16^00119^Marital Status |
| STF^17^00119^Marital Status |
| GT1^30^00781^Guarantor Marital Status Code |
A value representing a person's mother's maiden name (e.g. McKinnon, Reeves, Hughes)
Rationale: This is one of a set of attributes (e.g. a person's name, gender and date of birth) that is typically used as a distinguishing characteristic when determining which (of several) person records several represents the person in question.
Vocabulary domain: Race (CWE)
Attribute description:A code depicting the race of a person.
OpenIssue: Need example values.
Version 2.x reference:| IN2^71^00113^Race |
| NK1^35^00113^Race |
| PID^10^00113^Race |
Vocabulary domain: ReligiousAffiliation (CWE)
Attribute description:A person's religious preference.
OpenIssue: Need example values.
Version 2.x reference:| GT1^41^00120^Religion |
| IN2^39^00120^Religion |
| NK1^25^00120^Religion |
| PID^17^00120^Religion |
Vocabulary domain: SpecialAccomodation (CWE)
Attribute description:A code indicating the type of special accommodations for a person (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog). This attribute can be used when planning for a patient encounter and also when the source of the information is irrelevant, not known, etc.
OpenIssue: LHSR did not include this attribute in the mapping table. Modeler, therefore, left it in.
|
|
|
A physical place or site with its contained structures, if any. Place may be natural or man-made. The geographic position of a place may or may not be constant. Examples include a field, lake, city, county, state, country, lot (land), building, pipeline, power line, playground, ship, truck. 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.)
The address of this place.
Version 2.x reference:| RXD^13^00299^Deliver-to Location |
| RXE^8^00299^Deliver-to Location |
| RXG^11^00299^Deliver-to Location |
| RXO^8^00299^Deliver-to Location |
| RXA^11^00353^Administered-at Location |
| LOC^5^00948^Location Address |
| RXD^13^01303^Dispense-to Location |
| RXG^11^01303^Dispense-to Location |
A free text note that carries information related to a site that is useful for entities accessing that site. It could include directions for finding the site when address information is inadequate, GPS information is not available, and/or the entity accessing the site cannot make direct use of the GPS information. It could also include information useful to people visiting the location. E.g., "Last house on the right", "If owner not present, check whereabouts with neighbour down the road".
EXTREF: PHCDM-02.01.04.01
GPS coordinates of the place.
OpenIssue: This is really the GPS coordinates, and needs a different data type to capture the integers. Also, it needs a description.
Indicates whether the facility is considered mobile.
A set of codes that locates the site within a mapping scheme. For example, map coordinates for US Geological Survey maps.
|
|
|
An authorization for patient services by a third party prior to the delivery of the patient service.
The number of authorized encounters.
The date the authorized period begins.
A unique identifier assigned to the pre authorization.
Rationale: IN1-28
OpenIssue:
Version 2.x reference:| IN1^28^00453^Pre-Admit Cert (PAC) |
The date and time the pre authorization is issued.
The date and time the preauthorization was created.
A description of restrictions associated with the preauthorization.
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting the status of a preauthorization.
OpenIssue: Need examples values.
The date and time of the last status change.
|
|
|
The term "procedure" is also commonly known as a "surgical procedure" or an "operative procedure". Typically, a surgical procedure involves planned alteration of the structure of the body, ordinarily requiring the disruption of some body surface, usually through an incision.
Vocabulary domain: ProcedureApproachSite (CWE)
Attribute description:The anatomical site or system through which the procedure reaches its target (see target_site_cd.) For example, a Nephrectomy can have a trans-abdominal or a primarily retroperitoneal approach; an arteria pulmonalis catheter targets a pulmonary artery but the approach site is typically the vena carotis interna or the vena subclavia, at the neck or the fossa subclavia respectively. For non-invasive procedures, e.g., accupuncture, the approach site is the punctured area of the skin.
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses.
Some approach sites can also be "pre-coordinated" in the Service definition, so that there is never an option to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
Vocabulary domain: ProcedureMethod (CWE)
Attribute description:For any Procedure there may be several different methods to achieve by and large the same result, but may be important to know when interpreting a report more thoroughly (e.g., cholecystectomy: open vs. laparoscopic) Method concepts can be "pre-coordinated" in the Act definition. There are many possible methods, which all depend heavily on the particular kind of Procedure, so that defining a vocabulary domain of all methods is difficult. However, a code system might be designed such that it specifies a set of available methods for each defined Procedure concept. Thus, a user ordering a Procedure could select one of several variances of the act by means of the method code. Available method variances may also be defined in a master service catalog for each defined Procedure. In service definition records (Act.mood_cd = DEF) the method_cd attribute is a set of all available method codes that a user may select while ordering, or expect while receiving results.
Vocabulary domain: ProcedureTargetSite (CWE)
Attribute description:The anatomical site or system that is the focus of the procedure. For example, a Nephrectomy's target site is the right or left kidney; an arteria pulmonalis catheter targets a pulmonary artery. For non-invasive procedures, e.g., accupuncture, the target site is the organ/system that is sought to be influenced (e.g., "the liver".)
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses.
Some target sites can also be "pre-coordinated" in the Service definition, so that there is never an option to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
|
|
|
|
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.mood_cd = "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.
OpenIssue: Need to work wito broaden the concept, the name and the description.
Vocabulary domain: CaseDetectionMethod (CWE)
Attribute description:Code for the method by which the public health department was made aware of the case. Includes provider report, patient self-referral, laboratory report, case or outbreak investigation, contact investigation, active surveillance, routine physical, prenatal testing, perinatal testing, prison entry screening, occupational disease surveillance, medical record review, etc.
Vocabulary domain: CaseDiseaseImported (CWE)
Attribute description:Code that indicates whether the disease was likely acquired outside the jurisdiction of observation, and if so, the nature of the inter-jurisdictional relationship. Possible values include not imported, imported from another country, imported from another state, imported from another jurisdiction, and insufficient information to determine.
Vocabulary domain: CaseTransmissionMode (CWE)
Attribute description:Code for the mechanism by which disease was acquired by the living subject involved in the public health case. Includes sexually transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental exposure, indeterminate.
OpenIssue: Consider moving this attribute to Observation.
|
|
A role of a Healthcare_provider. Examples include physician, midwife, nurse practitioner.
OpenIssue: Compare these values with the vocab domain when it exists.
Vocabulary domain: FellowshipField (CWE)
Attribute description:The fellowship field of a physician.
OpenIssue: Need example codes. Need to reconcile with specialty_cd of Healthcare_provicer.
Vocabulary domain: ResidencyField (CWE)
Attribute description:The physician residency code.
OpenIssue: Need example codes for this attribute.
|
|
|
An introduction of a patient from a source caregiver to a target caregiver or provider institution, typically for the purpose of obtaining the target caregiver's assessment and treatment recommendations. A referral may authorize a specified quantity of a particular kind or level of service. A referral may also simply be a recommendation or introduction. OpenIssue: What is the distinction between the reason_txt and the desc atriibutes? Their descriptions do not reveal the difference, nor does the class description.
The number of authorized referral visits.
OpenIssue: Unclear what this attribute does, how it is used, and whether it belongs here. Authorized_visits_qty sounds more like a property of a health coverage.
Free form text describing the referral.
OpenIssue: These attributes seem to overlap with features and functionality inherited from the Service class. Notably Referral.desc is identical to Service.txt and Referral.reason_txt is either also in Service.txt or represented through -- possibly coded -- associated Services (e.g., observations).
Free form text providing the reason for the referral.
OpenIssue: These attributes seem to overlap with features and functionality inherited from the Service class. Notably Referral.desc is identical to Service.txt and Referral.reason_txt is either also in Service.txt or represented through -- possibly coded -- associated Services (e.g., observations).
|
|
Establishes a relationship link between two scoped Roles.
Vocabulary domain: RelationshipLinkType (CNE)
A specific time interval of a Schedule, that can be tentative, scheduled, or blocked to prevent use.
OpenIssue: A booked resource_slot is a relationship between a patient and a provider, and a resource_slot is part of a schedule, which is a relationship between a provider and the entity that has the authority to fill the providers schedule. Therefore, resource_slot should be both a type of Role_relationship, and should use the existing "has_parts :: (0..n) Role_relationship :: is_part_of :: (0..1)" to associate with the relevant Schedule.
Defines the start, duration, and repeat cycle for a Resource_slot.
|
|
|
|
|
|
A Role defines the competency of an Entity. An Entity, in a particular Role, can participate in an Act or can be related to another Entity 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 Individual_healthcare_practitioner, can participate in a Patient_encounter as an a rounding physician or as an attending physician. A Role defines the competency of an Entity irrespective of any Act, as opposed to Participation which is limited to the scope of an Act.
Attributes of Role are those that are particular to the entity while in the particular role.
The address for the Entity in this Role.
Version 2.x reference:| PID^11^00114^Patient Address |
| PID^12^00115^County Code |
| NK1^4^00193^Address |
| GT1^5^00409^Guarantor Address |
| GT1^17^00421^Guarantor Employer Address |
| IN1^5^00430^Insurance Company Address |
| IN1^19^00444^Insured's Address |
| IN1^44^00469^Insured's Employer Address |
| OM1^28^00613^Address of Outside Site(s) |
Vocabulary domain: RoleCode (CWE)
Attribute description:The "rich" code for Roles
A certificate for the relationship between the two entities. The certificate subject is the Entity at the target end of the Relationship, the certificate issuer is the Entity at the source end of the Relationship. The issuer certifies for his relationship to the target. For example, an employer can certify for his employee, an insurance can certify for his enrollee, a health authority for its licensee, a school for its graduate, etc.
The certificate can be represented in many different ways, either inline or by reference, according to the ED data type. Typical cases are:
1) Paper-based certificate: the ED data type may refer to some document or file that can be retreived through an electronic interface to a hardcopy archive.
2) Electronic certificate: this attribute can represent virtually any electronic certification scheme, such as, an electronically (incl. digitally) signed electronic text document.
3) Digital certificate (public key certificate): in particular, this attribute can represent digital certificates, as an inline data block or by reference to such data. The certificate data block would be constructed in accordance to a digital certificate standard, such as X509, SPKI, PGP, etc.
Note: for self-signed digital certificates both source and target of the relationship instance would be the same object instance (the relationship would be cyclic.)
Vocabulary domain: RoleClass (CNE)
Attribute description:A code specifying on a high, technical, and tightly controlled level the kind of role. This code is similar in nature as the names of the classes derived from Role in a refined message information model (R-MIM.)
Used with composition-relationships (e.g., has-parts, has-ingredient, has-content) and specifies how much of the target entity is comprised by the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10. The relationship numerator_qty specifies a relative amount (proportion) because Role-relationship.numerator_qty is the numerator of a fraction whose denominator is the relationship.denominatory. Therefore the relationship quantity must also be an amount quantity (refer to the Entity.qty definition), compound quantities such as percentages or concentrations are prohibited in this attribute and are not needed.
The time span during which the Entity assumes this Role.
The same piece of material may be given different identifiers by different responsible parties. For example, a manufacturer may assign a manufacturer id, a distributor may assign a catalog number, etc. All those identifiers can in principle occur under the Material.id attribute, i.e., as a property of the material itself. However, this attribute allows to make the scope of the id more clear, i.e. it helps to easily distinguish a specific manufacturer's id from a distributor's id much more directly and obvious as can be done using the assigning authority component of the instance identifier data type.
This attribute is for associations between entities where position is a relevant concept. For example, some containers have discrete positions in which content may be located. Depending on the geometry of the container, the position may be referenced as a scalar ordinal number, or as a vector of ordinal numbers (coordinates.) Coordinates always begin counting at 1.
Some containers may have customary ways of referring to the positions or no way at all. In absence of any specific regulation for a specific container type, the rule of thumb is that the coordinate that is changed earlier is positioned first. For an automated blood chemistry analyzer with a square shaped tray, this means that the first coordinate is the one in which direction the tray moves at each step and the second coordinate is the one in which the tray moves only every 10 (or so) steps.
OpenIssue: Other than for the container-content relationship, no use of the position_nbr attribute has been defined. There is also some conceptual overlap with other ways to describe position elsewhere in the model. For example, for a Role_relationship between a Material and a Facility entity, describing the current location of a mobile equipment, the position_nbr overlays with the notion of position in terms of GPS coordinate. Also, anatomical location of one entity in an biological entity is a position of sorts.
Used with composition-relationships (e.g., has-parts, has-ingredient, has-content) and specifies how much of the target entity is comprised by the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10. The relationship numerator_qty specifies a relative amount (proportion) because Role-relationship.numerator_qty is the numerator of a fraction whose denominator is the relationship.denominatory. Therefore the relationship quantity must also be an amount quantity (refer to the Entity.qty definition), compound quantities such as percentages or concentrations are prohibited in this attribute and are not needed.
In circumstances where a ratio is intended, this attribute values the numerator.
Vocabulary domain: RoleStatus (CNE)
Attribute description:OpenIssue: If the only values are active/inactive, then this attribute may be derivable from effective_tmr.
Version 2.x reference:| PID^27^00130^Veterans Military Status |
The electronic communication addresses for the Entity in this Role.
Version 2.x reference:| PID^13^00116^Phone Number - Home |
| NK1^6^00195^Business Phone Number |
| GT1^6^00410^Guarantor Ph Num- Home |
| GT1^7^00411^Guarantor Ph Num-Business |
| GT1^18^00422^Guarantor Employer Phone Number |
| IN1^7^00432^Insurance Co Phone Number |
| IN3^16^00517^Certification Contact Phone Number |
| IN3^19^00520^Certification Agency Phone Number |
| OM1^17^00602^Telephone Number of Section |
| OM1^29^00614^Phone Number of Outside Site |
| GT1^46^00749^Contact Person's Telephone Number |
| NK1^31^00749^Contact Person's Telephone Number |
| IN2^50^00790^Employer Contact Person Phone Number |
| IN2^53^00793^Insured's Contact Person Telephone Number |
| IN2^58^00798^Insurance Co Contact Phone Number |
| IN2^63^00803^Insured's Telephone Number - Home |
| IN2^64^00804^Insured's Employer Telephone Number |
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 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 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. Subseqent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
|
A Role of an Entity that can be scheduled.
Duration for a single schedulable unit in a schedule for a resource.
OpenIssue: Not sure what this means.
|
|
|
Substance_administration is an Act using a Material as a therapeutic agent. The effect of the therapeutic substance is typically established on a biochemical basis, however, that is not a requirement. For example, radiotherapy can largely be described in the same way, especially if it is a systemic therapy such as radio-iodine.
Because Substance_administration deploys material substances, a number of attributes arguably pertain to the Material rather than the Substance_administration action. Therefore, some information may be representable in two ways: as attributes of the Substance_administration act or as attributes of the Material. For example, an amoxicillin treatment is usually described as "Substance_administration.cd = Amoxicillin"; however, it could also be described as "Substance_administration.cd = Administration" with an associated "Material.cd = Amoxicillin". At this point naming the Substance_administration action after the administered substance is the preferred strategy, so long as it is noted that "Substance_administration.cd = Amoxicillin" really represents "Substance_administration.cd = Administration-of-Amoxicillin". This design allows simple medications to be described without having to use the Material class. Only if such actions as dispensing are involved, or if a recipe prescription is written, should one have to deploy the Material class.
Vocabulary domain: SubstanceAdminApproachSite (CWE)
Attribute description:The detailled anatomical site where the medication is routed. Note, this attribute is only needed if the route_cd requires further specification. For example, if the route_cd is "by mouth", no further specification of approach site is needed. If, however, route_cd is intravenous or intra-muscular, the precise site may be specified in this attribute (e.g., right forearm or left deltoid muscle respectively.)
OpenIssue: There is some overlap with route_cd. Will have to determine if body site is better to be included with route or if it is better to try to split route and body site (so that for instance "SQ" is a route, while "left forearm" is the body site.
This attribute should not generally be used; it is only provided for a special purpose. In some countries, especially Japan, there is a regulatory requirement to note the total daily dose on the prescription and associated documentation. The purpose of this requirement obviously is to encourage and facilitate reviewing the total dose prescribed to avoid over- (or under-) dosage. Rather than to define a "total daily dose" attribute as HL7 v2.3 did, we define this general purpose dose_check_qty attribute that can be used in various ways as required by local business rules or regulations. For example, in Japan one would use this field as a total daily dose by calculating the "real" dose as noted above and then adjusting the denominator to 1 d (one day). For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the total daily dose as dose_check_qty = dose_qty (1) * strength_qty (250 mg) * activity_dttm (3 /d) = 750 mg/d. For an intravenous example, this term would be dose_check_qty = dose_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100 mL/h which can be calculated on a daily basis as dose_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d.
So, in Japan, the denominator of the dose_check_qty unit must always be 1 /d. In other countries the constraints on the dose_check_qty may be different or, most likely, the attribute would not be used at all. In any case this dose_check_qty attribute must not be used to carry any functional information.
The dose_qty is the amount of the therapeutic agent or other substance given at one administration event. If specified as an interval, the dose is a value in the specified range. This attribute can be used alone or in combination with a strength. In theory, for medications provided to patients, a physician's prescription could suffice with just the dose specification. For example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength. The pharmacist can figure out the right preparation given what is available in stock or on the marketplace. When the pharmacist dispenses a particular preparation with a particular strength and packet size from a particular manufacturer, etc., this detail should be communicated using the Material class.
Vocabulary domain: DoseForm (CWE)
Attribute description:The physical form in which the substance is delivered. For therapeutic medications, examples include tablet, capsule, suppository, and solution. For environmental interventions, such as chlorination of the water supply, examples might include liquid or tablets.
OpenIssue: This field must have a mandatory HL7 table for interoperability purpose. Such a table could cover at least 90% of all cases.
Identifies the period of time over which the maximum total quantity of a therapeutic substance may be administered to a subject. e.g. 500 mg/day; 1200mg/week. In the situation of multiple reptitions, each max_dose_qty corresponds to the equivalent repetition of the max_dose_period_qty.
Identifies the maximum total quantity of a therapeutic substance that may be administered to a subject over the period of time identified by max_dose_period_qty. e.g. 500 mg/day; 1200mg/week. In the situation of multiple reptitions, each max_dose_qty corresponds to the equivalent repetition of the max_dose_period_qty.
With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified. If specified as an interval, the dose is a value in the specified range. The Pharmacotherapy.rate_qty is specified as a physical quantity in time (a duration.) Hence, the rate_qty is really the denominator of the dose rate (the dose_qty is the numerator). For example, if a Ringer's solution is to be given at 100 mL/hour i.v., the dose_qty would be 100 mL and the rate_qty would be 1 h. Note that there is no difference in the actual values of dose_qty and rate_qty as long as the quotient of both has the same value. In this example, we could just as well specify dose_qty as 50 mL and rate_qty as 30 min, or 200 mL and 2 h or any other combination where the quotient equals 100 mL/h.
Note that in principle one could again suffice with just the dose_qty attribute specifying the rate right in that one attribute (e.g., dose_qty = 100 mL/h.) However this practice is not allowed. Systems that implement the semantics of units according to the Unified Code for Units of Measure would have no problem noting the fact that a dose_qty is really a rate. Other system however will have difficulties to tell an at-once dose from a dose rate from just looking at the units. If a system wishes to deal only with a single quantity describing the dosage, it can always calculate such a quantity as real_dose_qty = dose_qty x strength_qty / rate_qty.
Vocabulary domain: MedAdministrationRoute (CWE)
Attribute description:The route by which the medication is administered. Medication route - when the medication is delivered to a living patient - is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise applied to the body (body_site_cd). It is an open issue whether a specialized route_cd could be replaced by a general anatomic site code. The typical routes are per os (PO), sublingual (SL), rectal (PR), per inhalationem (IH), ophtalmic (OP), nasal (NS), otic (OT), vaginal (VG) , intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and intra-cardial (IC). However, there are other routes and there are many variations as to how to access a specific route. For instance, an oral administration with the patient swallowing will usually have the same effect as if the same substance is given through a gastric tube. A more systematic approach to break down the route into components such as site of primary entry (e.g. oral, nasal), site/system of substance uptake (e.g. gastrointestinal, bronchial, nasal mucosa), method (e.g., swallow, inhale), and device (e.g., gastric tube, tracheal tube) should be considered. When the medication is delivered to an environmental site, or a location, the route code indicates a site on its "body".
Vocabulary domain: SubstanceAdminSubstitution (CWE)
Attribute description:Indicates whether an ordered or intended Substance_administration may be or has been substituted for a different Substance_administration. The fact that the actual service differs from the planned or ordered service, and the details of the variance can be seen by comparing the service as planned or ordered from the service as performed. Both service records should be sent in a message where this difference is important. The Pharmacotherapy.substitution_cd attribute is mainly used in an order, to specify whether an ordered service may be substituted and in what way it may be substituted.
Supply orders and deliveries are very simple services that mainly focus on the delivered product. The product is associated with the supply service via Participation.type_cd="product". Just as with Medication services there are in principle two ways to represent the type and identity of supplied material, i.e. as the Supply.type_cd or as the Material.type_cd of the target material. With general supply orders the precise identification of the Material, its manufacturer, serial numbers, etc. is important, and supply services are only very marginal parts of the electronic patient record. Therefore, most of the detail information about the supply should be represented using the Material class.
Note that if delivery needs to be scheduled, tracked, and billed separately, one can associate Transportation services with the supply.
Pharmacy dispense services are represented as supply services, associated with a medication service. The medication class represents the administration of medication, while dispensing is supply.
Specifies the quantity ordered or supplied (depending on the mood_cd.)
Transportation is the moving of a payload (people or material) from a location of origin to a destination location. Thus, any transport service has the three target instances of type payload, origin, and destination, besides the targets that are generally used for any service (i.e., performer, device, etc.)
|
|
|
Billing account information particular to the national uniform billing form. In the United States, this information is used for claim production to receive payment for healthcare services provided.
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting a condition.
EXTREF: This information is reported on UB92 FL 24-30.
Version 2.x reference:| UB1^7^00536^Condition Code (35-39) |
| UB1^12^00541^Spec Program Indicator (44) |
| UB2^3^00555^Condition Code (24-30) |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting a event.
EXTREF: This information is reported on UB92 FL 32-35.
Version 2.x reference:| UB1^16^00545^Occurrence (28-32) |
| UB2^7^00559^Occurrence Code & Date (32-35) |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code depicting an event which occurs over a span of time.
EXTREF: This information is reported on UB92 FL 36.
Version 2.x reference:| UB1^13^00542^PSRO/UR Approval Indicator (87) |
| UB1^17^00546^Occurrence Span (33) |
| UB2^8^00560^Occurrence Span Code/Dates (36) |
The from date of the event depicted in occurrence span code.
ExtRef: This inormation is reported on UB92 FL 36.
Version 2.x reference:| UB1^14^00543^PSRO/UR Approved Stay-Fm (88) |
| UB1^18^00547^Occur Span Start Date(33) |
| UB2^8^00560^Occurrence Span Code/Dates (36) |
The end date of the event depicted in occurrence span code.
ExtRef: This information is reported on UB92 FL 36.
Version 2.x reference:| UB1^15^00544^PSRO/UR Approved Stay-To (89) |
| UB1^19^00548^Occur Span End Date (33) |
| UB2^8^00560^Occurrence Span Code/Dates (36) |
The date of the event depicted in occurrence code.
ExtRef: This information is reported on UB92-35.
Version 2.x reference:| UB2^7^00559^Occurrence Code & Date (32-35) |
A quantitative value on a bill. The value is qualified by quantity type code.
ExtRef: The quantity of covered days, non-covered days, and co-insurance days are reported on UB92 FL 7, 8, and 9.
Version 2.x reference:| UB1^3^00532^Blood Furnished-Pints Of (40) |
| UB1^4^00533^Blood Replaced-Pints (41) |
| UB1^5^00534^Blood Not Replaced-Pints(42) |
| UB1^6^00535^Co-Insurance Days (25) |
| UB1^8^00537^Covered Days (23) |
| UB1^9^00538^Non Covered Days (24) |
| UB1^11^00540^Number Of Grace Days (90) |
| UB2^2^00554^Co-Insurance Days (9) |
| UB2^4^00556^Covered Days (7) |
| UB2^5^00557^Non-Covered Days (8) |
| UB2^17^00815^Special Visit Count |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code qualifying the quantity amount information on a bill (e.g., Blood furnished, blood not replaced, blood replaced, coinsurance day, covered day, non-covered day, grace day, special visit, . . .).
A value amount qualified by value code.
EXTREF: This information is reported on UB92 FL 39-41.
Version 2.x reference:| UB1^10^00539^Value Amount & Code (46-49) |
| UB2^6^00558^Value Amount & Code |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:A code qualifying the billing information value amount.
EXTREF: This information is reported on UB92 FL 39-41.
Version 2.x reference:| UB1^10^00539^Value Amount & Code (46-49) |
| UB2^6^00558^Value Amount & Code |
|
|
|
OpenIssue: The specializations of this class need to be harmonized in January 2001.
|
Working_list collects a dynamic list of individual instances of Act via Act_relationship which reflects the need of an individual worker, team of workers, or an organization to manage lists of acts for many different clinical and administrative reasons. Examples of working lists include problem lists, goal lists, allergy lists, and to-do lists.
OpenIssue: The name is too generic. This needs to be harmonized with Scheduling.
Vocabulary domain: ListOwnershipLevel (CWE)
Attribute description:Ownership_level_cd indicates the category of representation for the personnel managing the list, whether personal, team or organizaion. Other values may be added as needed by an organization.
Represents a valued element structure for the element specified in the query response.
Represents a valued element structure for the element specified in the query response.
|
|
The Acknowledgement class contains information sent when acknowledging another message.
Vocabulary domain: MessageCondition (CWE)
Attribute description:This attribute allows for a coded error type.
Version 2.x reference:| MSA^6^00023^Error Condition |
This attribute is used in the sequence number protocol.
Version 2.x reference:| MSA^4^00021^Expected Sequence Number |
This attribute further describes an error condition. This text may be printed in error logs or presented to an end user.
Version 2.x reference:| MSA^3^00020^Text Message |
Vocabulary domain: AcknowledgementType (CWE)
Attribute description:This attribute contains an acknowledgement code as described in the HL7 message processing rules. Refer to HL7 table 0008 - Acknowledgement code for valid values.
Version 2.x reference:| MSA^1^00018^Acknowledgement Code |
|
|
This class allows parameters for a technology specific transport to be represented in the V3 message outer wrapper.
A parameter defining word.
A parameter value.
|
|
|
The Batch class is to specify a message which is a collection of HL7 V3 messages. This class is a placeholder for future specification work by the Control/Query TC.
OpenIssue
This attribute is available to capture comments related to the batch.
Version 2.x reference:| BHS^10^00090^Batch Comment |
| BTS^2^00090^Batch Comment |
The batch total. It is possible that more than a single batch total exists.
Version 2.x reference:| BTS^3^00095^Batch Totals |
This attribute uniquely identifies a particular batch.
Version 2.x reference:| BHS^11^00091^Batch Control ID |
This attribute contains the date/time that the sending application created the batch.
Version 2.x reference:| BHS^7^00087^Batch Creation Date/Time |
This attribute contains the count of individual messages contained within the batch.
Version 2.x reference:| BTS^1^00093^Batch Message Count |
This attribute is used by the application processing the batch.
Version 2.x reference:| BHS^9^00089^Batch Name/ID/Type |
This attribute uniquely identifes the receiving application of the batch
Version 2.x reference:| BHS^5^00085^Batch Receiving Application |
This attribute indicates the control identifier of the batch when it was originally transmitted.
Version 2.x reference:| BHS^12^00092^Reference Batch Control ID |
This attribute is specified for applications to implement security features for an HL7 batch of messages. Its uses is not further specified at this time.
Version 2.x reference:| BHS^8^00088^Batch Security |
This attribute uniquely identifies the sending application of the batch.
Version 2.x reference:| BHS^3^00083^Batch Sending Application |
Plain character data.
Plain character data.
|
A clinical document contains Observations and Acts and has the following characteristics: (1) Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements; (2) Stewardship - A clinical document is maintained by a person or organization entrusted with its care; (3) Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated; (4) Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document; (5) Human readability - A clinical document is human readable.
An optional identifier which must be unique within the document.
The clinical document body occurs in a clinical document and contains structured or unstructured components.
The coded_entry enables the insertion of codes from HL7-recognized coding schemes into clinical documents.
A globally unique identifier of this coded entry.
The code for this coded entry.
Content is a Structure which can nest recursively, which enables wrapping a string of plain text down to as small a chunk as desired. These content structure elements can serve as anchors, to be referenced as the original text that supports the use of a code.
|
|
|
|
Entries are contained within structures. Some entries (e.g. Local_markup) can contain nested entries (e.g. Local_attr). Entries also occur in table cells and captions.
An optional identifier which must be unique within the document.
|
|
|
This class is defined to contain a file (group of batches) being processed following the HL7 batch protocol.
OpenIssue: This name does not appear to conform to the standard Class naming conventions, and should be corrected as a technical correction.
This attribute uniquely identifies a particular file.
Version 2.x reference:| FHS^12^00078^Reference File Control ID |
This attribute contains the date/time that the sending application created the file.
Version 2.x reference:| FHS^7^00073^File Creation Date/Time |
This attribute contains the number of batches contained in this fie
Version 2.x reference:| FTS^1^00079^File Batch Count |
This attribute is a text field for comment that is not further specified
Version 2.x reference:| FTS^2^00080^File Trailer Comment |
This attribute is used by the application processing the file.
Version 2.x reference:| FHS^9^00075^File Name/ID |
This attribute uniquely identifies the receiving application of the file
Version 2.x reference:| FHS^5^00071^File Receiving Application |
This attribute indicates the control identifier of the file when it was originally transmitted.
Version 2.x reference:| FHS^12^00078^Reference File Control ID |
This attribute is specified for applications to implement security features for a file of a group of HL7 batches. Its use is not further specified at this time.
Version 2.x reference:| FHS^8^00074^File Security |
This attribute uniquely identifies the sending application of the file
Version 2.x reference:| FHS^4^00070^File Sending Facility |
|
|
|
This class maintains the state information required at the application level to control the logical continuation of a query response.
Specifies the number of instance matches to return in the next query response message.
This attribute is valued by the initiating application to identify a query. Here it is intended to be used to match a request for more results from a query that has been previously initiated.
Specifies the which instances number in original query result set to start return in next query response message.
A link is a generic referencing mechanism.
|
|
|
Link_html is based on the HTML anchor tag, and enables HTML-style hyperlinking semantics.
This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
Vocabulary domain: HtmlLinkType ()
Attribute description:This attribute is part of the HTML anchor tag.
Vocabulary domain: HtmlLinkType ()
Attribute description:This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
The unstructured blob is used to represent an unstructured document body (meaning, a document body that does not have a standardized internal structure).
Vocabulary domain: ListType (CWE)
Attribute description:The list_type attribute specifies whether the list is ordered or unordered. Use an ordered list when the ordering of list items is meaningful.
A list item occurs within a list, and can contain nested structures and entries as well as an optional caption.
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
The name of the local attribute.
The value of the local attribute.
|
|
|
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.
Vocabulary domain: LocalMarkupIgnore (CWE)
Attribute description:The ignore attribute tells the receiver to ignore just the <local_markup> tag (ignore="markup"), or to ignore the <local_markup> tag and all contained content (ignore="all").
The render attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.
|
Vocabulary domain: ServiceRelationshipConjunction (CWE)
Attribute description:When more than one criteria is to be applied in the evaluation of candidate instances, a conjunction is supplied to identify how to relate an additional criteria. Reference HL7 Table 0210 - Relational conjunction for valid values.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
|
|
|
The Message class is the parent class of all HL7 Version 3 messages.
OpenIssue: May need a type code to serve a purpose above and beyond the interaction_id, since the subtypes may not be fully enumerated.
Contains arbitrary attachments of data blocks to which can be referred to from the interior of the message. Any ITS is advised to represent the attachments behind the main message body. Attachments are referred to from the message body using the reference functionality of the ED data type.
OpenIssue: Constrain the use of the ED data type in the attachment message type.
For large data blocks, it may be easier to represent them as attachments rather than as inline data in the main message payload body. Digital signature blocks are best appended in attachments, since otherwise the signature itself would be part of the signed data.
Examples for ITS mappings of attachments are XML fragment and MIME multipart. The ED data type can contain a reference URL to an XML fragment (IDREF) where the fragment id (ID) is defined as an XML attribute of the attachment element. MIME multipart can be referred to by a URL of scheme "CID:" that refers to a MIME part with the corresponding "Content-ID" header.
The date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.
Version 2.x reference:| MSH^7^00007^Date/Time of Message |
Unique identifier of message.
Version 2.x reference:| MSA^2^00010^Message Control ID |
| MSH^10^00010^Message Control ID |
The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for speciying a message.
OpenIssue: This may be better modeled as an association to the class Interaction (in the meta-model). It is possible that this may supply the type code for the message, or we may need an additional attribute to carry the type code.
Version 2.x reference:| MSH^9^00009^Message Type |
Vocabulary domain: ProcessingID (CWE)
Attribute description:This attribute defines whether the message is part of a production, training, or debugging system. In HL7 Version 2.x, the values for this id were drawn from HL7 table 0103.
Version 2.x reference:| MSH^11^00011^Processing ID |
Vocabulary domain: ProcessingMode (CWE)
Attribute description:This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.. In HL7 version 2.x the values for this code were drawn from HL7 table 0207. Recommended V3 datatype is CV.
The message profile identifier allows a given implementation to explicitly state how it varries from the standard message definition
Unique identifier of receiving application of message.
OpenIssue: The elements of this attribute are semantically "paired" with the has_recipient (1,n)::Stakeholder association, which isn't properly express in this model.
This attribute allows a URL to define the address to which the message reply should be directed.
Unique identifier of the sending application of the message.
OpenIssue: Make the names consistent with the modeling sytle guide (as a technical correction).
Version 2.x reference:| MSH^3^00003^Sending Application |
This attribute is provided for implementing the sequence number protocol. This field is incremented by one for each subsequent value assignment.
Version 2.x reference:| MSH^13^00013^Sequence Number |
This attribute is matched by the receiving system to its own versioin to be sure the message will be interpreted correctly.
Version 2.x reference:| MSH^12^00012^Version ID |
|
|
An messaging interaction is the bundle of information that is communicated for a particular purpose. For example, a "register new patient" interaction is the bundle of patient information along with the command (purpose) to enter that information into a registry. The message interaction also contains attribution about when it was issued, who issued it, etc.
A messaging interaction is a unique object no matter whether it is broadcasted, archived or replayed. A messaging interaction is usually the payload of a message. Multiple messages sent to multiple recipients may contain one identical messaging interaction. This can be demonstrated with the instance identifiers: the Message_interaction.id will be a constant unique identifier even if this interaction is copied, broadcasted, resent, stored, or replayed in multiple messages. Each message would have a different Message.id, but the Message_interaction.id would always be the same.
OpenIssue: Look at the symmetry between how messages and documents are structured. does message interaction support the idea of queries.
Attribute identifying the structure of the payload portion of the message specified for this interaction.
A paragraph is a structure. It can contain a caption and it can contain entries.
|
|
|
This is an abstract class that represents the possible forms f parameters that may be specified in a Query_by_parameter conformance statement.
In a Paremeter_list, specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.
In A_parameter, identifies the name of the element field in an HMD specified for query response.
Specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.
|
|
|
|
|
This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification.
Specifies the time the response is to be returned.
This attribute may be valued by the initiating application to identify the query. It is intended to be used to match response messages to the originating query.
Version 2.x reference:| EQL^1^00696^Query Tag |
| ERQ^1^00696^Query Tag |
| QAK^1^00696^Query Tag |
| SPR^1^00696^Query Tag |
| VTQ^1^00696^Query Tag |
Defines the maximum size of the response that can be accepted by the requesting application. The accepted units are drawn from HL7 Table 0126 - Quantity limited request.
Version 2.x reference:| QRD^7^00031^Quantity Limited Request |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:This attribute is the name of the query as defined by a function-specific chapters of this specification or by an implementation specific agreement. There is a one to one correspondence with a conformance statement for this query name. The query name is an identifier for this conformance statement. The HL7 standard will maintain a table of the standard queries as specified by an HL7 technical committee. Implementation specific queries will extend this table.
Vocabulary domain: ModifyIndicator ()
Attribute description:Indicates whether the subscription to a query is new or is being modified. Reference HL7 Table 0395 - Modify indicator for valid values.
Vocabulary domain: QueryPriority ()
Attribute description:Identifies the time fram in which the response is expected. Reference HL7 Table 0091 - Query priority.
Vocabulary domain: ResponseModality (CWE)
Attribute description:Defines the timing and grouping of the response instances. References HL7 Table - 0394 - Response Modality for valid values.
|
|
|
This class carries information sent with responses to a query.
This attribute is valued by the initiating application to dientify a query. Here it is intended to be used to match response messages to the originating query.
Version 2.x reference:| URS^9^00695^R/U Quantity/Timing Qualifier |
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:This attribute has same semantic meaning as specified in Query.message_query_name.
Vocabulary domain: <<unassigned>> (CWE)
Attribute description:This attribute allows the responding system to return a precise response status. Reference HL7 Table 0208 - Query response status for values for this coded attribute.
Version 2.x reference:| QAK^2^00708^Query Response Status |
Specifies number of matches for processed query specification that occur in current bundle of matches.
Specifies number of matches for processed query specification that have yet to be sent to receiver.
Specifies total number of instance matches for query specification associated with this query response instance.
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 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.
|
|
|
Identifies RIM element as subject of selection criteria evaluation.
Vocabulary domain: RelationalOperator (CWE)
Attribute description:Identifes common relational operators used in selection criteria. Reference HL7 Table 0209 - Relational operator for suggested values.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
Value supplied for comparison using criteria.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
A document structure that can contain a caption, and can contain nested structures.
|
|
|
|
|
Holds specification of sort order for instance matches to a query.
Vocabulary domain: Sequencing (CWE)
Attribute description:Specifies sequence of sort order. Refer to HL7 Table 0390 - Sequencing for valid values.
Identifies a RIM element in a query response.
|
|
|
|
A structure is a container within a document. Structures have captions which can be coded. Structures can nest, and structures can contain entries.
An optional identifier which must be unique within the document.
|
|
|
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
Vocabulary domain: TableFrame ()
Attribute description:This attribute is part of the XHTML table model.
Vocabulary domain: TableRules ()
Attribute description:This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
|
|
|
|
|
A cell in a table.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML model.
Vocabulary domain: TableCellScope ()
Attribute description:This attribute is part of the XHTML table model.
A column in a table.
A group of table columns.
|
|
|
|
A table column or column group.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
A table data cell.
A table header cell.
A row in a table.
|
A group of table rows.
Vocabulary domain: TableRowGroupType (CWE)
Attribute description:Specificies whether this is a header, footer, or body row group.
|
|
A table row or row group.
|
|
|
|
|
|
A table structure is either a column structure, a row structure, or a table cell.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
Vocabulary domain: TableCellHorizontalAlign ()
Attribute description:This attribute is part of the XHTML table model.
An optional identifier which must be unique within the document.
Vocabulary domain: TableCellVerticalAlign ()
Attribute description:This attribute is part of the XHTML table model.
The unstructured blob is used to represent an unstructured document body (meaning, a document body that does not have a standardized internal structure).
The unstructured blob is stored in this field.
This connection shows the relationship of the acknowledgement to a specific HL7 V3 message
This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.
This relationship allows parameters for a technology specific transport to be represented in the V3 message. outer wrapper.
This relationship allows the originating organization for an HL7 V3 message to be identified
Message_interactions are the payloads of Messages. This is navigable in one direction only from Message to Message_interaction.
OpenIssue: Examine the symetry between the way messages and documents relate to the RIM including the way messages.
Specifies the relationship between a parameter list and the parameters which are its content.
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }