- Access
is a specialization of:
Role
Description of Access:
A role played by a device when the device is used to administer therapeutic agents (medication and vital elements) into the body, or to drain material (e.g., exudates, pus, urine, air, blood) out of the body. For the most part, anything that would be used for access would be a device (something specifically manufactured or created to serve that purpose). Typically the device is a catheter or cannula inserted into a compartment of the body.
A device enters the body from an anatomic site designated by the approach_site_cd. The body compartment into which material is administered or from which it is drained is designated by the target_site_cd.
Note that the Access role primarily exists in order to describe material actually deployed as an access, and not so much the fresh material as it comes from the manufacturer. For example, in supply ordering a box of catheters from a distributor, it is not necessary to use the Access role class, since the material attributes will usually suffice to describe and identify the product for the order. But the Access role is used to communicate about the maintenance, intake/outflow, and due replacement of tubes and drains.
Devices in the role of an Access are typically used in intake/outflow observations, and in medication routing instructions. Microbiologic observations on the material itself or on fluids coming out of a drain, are also common.
OpenIssue: Issue relates to the restriction of access device to persons or animals as patients. In the case where the material desired does not originate from a "living subject" such as in environmental monitoring, then the access device definition needs to reflect that change. For example, an order for a sample to be taken from the clean-out port of a food processing device for a public health investigation.
Attributes of Access:
Vocabulary domain:
ActSite
(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.
Vocabulary domain:
ActSite
(CWE)
Attribute description: This is the target site of the access, i.e., the compartment into which material is administered or from which it is collected. For example, a pulmonary artery catheter will have the target site arteria pulmonalis with or without a known laterality. For environmental testing this could be the incubation chamber or the cooling tower or the overflow reservoir, etc.
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.)
OpenIssue: This is another area where the definition could be generalized to Entities other than Living_subjects. The target site for environmental sampling may be a particular part of a machine, sewage system, distribution system, etc.
Attribute description: 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.
Description of Account:
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.
Attributes of Account:
Attribute description: The descriptive name of the account as carried in the ledger of which the account is a part.
Vocabulary domain:
Currency
(CWE)
Attribute description: Indicates the currency that the account is managed in.
ExtRef: ISO:4217
Attribute description: 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)
Attribute description: An interval describing the minimum and maximum allowed balances for an account.
Description of Act:
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"). Moods describe activities as they progress in the business cycle, from defined, through planned and ordered to complete.
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 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 and 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 is 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 " or "intent", the results are the possible results, the expected or aimed-for results, or the tested-for results.
Attributes of Act:
3.3.1 Act.class_cd
::
CS
(1..1)
Mandatory
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 |
3.3.2 Act.mood_cd
::
CS
(1..1)
Mandatory
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.) Another special infinitive is "goal". 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.
Attribute description: 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 |
3.3.4 Act.cd
::
CD
(0..1)
Vocabulary domain:
ActCode
(CWE)
Attribute description: A code specifying a 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. The precision and specificity of the action is dependent of the coding system used.
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 |
Attribute description: If true, negates the assertion of the Act. For example in an observation it allows one to say "patient has no chest pain". In criterion mood it negates the criterion analogously, e.g., "if systolic blood pressure is not within 90-100 mmHg then alert me."
This attribute is explicitly a boolean and does not need to have grades or other nuances for expressing uncertainty. It simply negates. If the observation (or other act) is asserted with some low degree of probability, the negation indicator should be left false. The fact that an observation was not ascertained is also distinct from the negation. Not ascertaining an observation causes there to be no such observation, it does not negate the assertion.
3.3.6 Act.txt
::
ED
(0..1)
Attribute description: 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. The content of the description is not considered part of the functional information communicated between systems. Free text descriptions are used to help an individual interpret the content and context of the act. 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.
Version 2.x reference:| FT1^8^00362^Transaction Description |
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 |
Attribute description: 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^30^00160^Transfer to Bad Debt Date |
| PV1^35^00165^Delete Account 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 |
| PV2^17^00718^Purge Status Date |
Attribute description: 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 actually takes place.
The timing of actions is a very important concept that is explained in greater detail in the USAM discussion.
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 |
Attribute description: For HL7 messaging, the Service.availability_time 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_time 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:
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:
Confidentiality
(CWE)
Attribute description: This is a code that limits the disclosure of information about this act.
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 suggested vocabulary domain. 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 |
Attribute description: An interval of integer numbers stating the minimal and maximal number of repetitions of an act. The number an act repeats is additionally constrained by time. The act will repeat at least repeat_nbr.low times and at most repeat_nbr.high times. Repetitions will also terminate when the time exceeds effective_time.high, whichever comes first.
Attribute description: Indicates whether an act is interruptible by asynchronous events (such a "through" conditions to turn false, or time running out??.) See discussion on activity plans in the USAM documentation.
Attribute description: Indicates that all acts connected through context-conductive links should not be independently removed from the context of this act.
Attribute description: 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
Vocabulary domain:
ActReason
(CWE)
Attribute description: A code depicting the reason for a clinical, administrative or financial act. For Patient Encounter, it is the reason for a patient transfer associated with the encounter. Example include roommate conflict, equipment malfunction, acuity change, etc. For clinical documents, it is the reason for document status change.
exRef: TXA^21^00933^Doocument Change Reason
Ratiionale: This is a point of last resort if there isn't an observation that fits the case.
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 |
Vocabulary domain:
HumanLanguage
(CWE)
Attribute description: The human language of character data can be specified using this attribute.
-
Attributes of Act_context:
- Act_context
is a specialization of:
Act
Description of Act_context:
The Act_context is a specialization of an Act that 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/multiplicity needs to be reviewed (the suggestion is that it needs to be 0 *).
Attributes of Act_context:
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.
- Act_heir
is a specialization of:
Act
Description of Act_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
-
Attributes of Act_relationship:
Description of Act_relationship:
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. 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.
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 documentation.
Attributes of Act_relationship:
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 |
Attribute description: 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:
ActRelationshipContextControl
(CNE)
Attribute description: Specifies if this act relationship is conductive to inherited participations and relationships or if it can itself be inherited. Act relationships and participations that are marked inheritable can be inherited along act-relationships that are marked conductive. Conductance of inheritable objects is transitive and unidirectional from source to target. The total of all inheritable objects along an uninterrupted chain of conductive links leading back from a target act towards the source of act relationships is called the inherited context of that act. All inherited context is lost at an act relationship marked non-conductive. Context inheritance can be additive (I) or overriding (IOS). Additive inheritance adds new objects into the inherited context while overriding inheritance replaces inherited objects of the same or more specific type/class with this inherited object.
Example 1: An observation event has a patient participation marked inheritable and has component observation events linked through act relationships that are marked conductive. This means that the patient participation is a patient participation of those component observation events.
Example 2: A composite order has a patient participation, an author participation, and a reason relationship to a diagnosis, all marked as inheritable. The order further has several detail orders as components, with the components marked as conductive. The patient, author, and reason of the component orders are the same as for the composite order.
Attribute description: This integer number specifies an order 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.
Attribute description: This integer specifies another 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.
Attribute description: 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.
Vocabulary domain:
ActRelationshipCheckpoint
(CNE)
Attribute description: Indicates when associated pre-conditions are to be tested.
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:
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.
Attribute description: Indicates that the playing entity does NOT play the specified role. Allows for explicit exclusions in containment relationships, permission relationships, etc. Normally all roles are considered to be affirmitive. (This attribute defaults to FALSE.)
Vocabulary domain:
RelationshipConjunction
(CNE)
Attribute description: In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.
-
Attributes of Assigned_entity:
- Assigned_entity
is a specialization of:
Role
Description of Assigned_entity:
An agent role in which the agent is an Entity acting in the employ of an organization. The focus is on functional role on behalf of the organization, unlike the Employee role where the focus is on the 'Human Resources' relationship between the employee and the organization.
Attributes of Assigned_entity:
Vocabulary domain:
PractitionerPosition
(CWE)
Attribute description: An indication that the healthcare practitioner is a primary care provider.
-
Attributes of Certified_entity:
- Certified_entity
is a specialization of:
Role
Description of Certified_entity:
A relationship in which the scoper certifies the players ability to perform a specific task. The certification may imply legal capacity, or an evaluated capability for the performance of that task. Examples include the certification of equipment, as well as the granting of license or certificates to organizations or professionals.
Attributes of Certified_entity:
Attribute description: The date recertification is required.
-
Attributes of Clinical_document:
Description of Clinical_document:
Specialization of Act to add the characteristics unique to document management services.
Attributes of Clinical_document:
Attribute description: 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.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_relationsip, with act_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 replacemnt report replaces an existing report. The replacement report uses the same value for document_service.set_id as the parent report being replaced, and increments the value of document_serivce.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.
Attribute description: 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.
Vocabulary domain:
DocumentCompletion
(CWE)
Attribute description: A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).
Vocabulary domain:
DocumentStorage
(CWE)
Attribute description: A code depicting the storage status (e.g., active, archived, purged) of a report.
Attribute description: 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.
Description of Container:
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".
Rationale: The specifications for this class arose from the collaboration between HL7 and the NCCLS. Many of the attribute definitions are drawn from or reference the NCCLS standard.
Attributes of Container:
Attribute description: The capacity of the container in the units specified.
Attribute description: The height of the container in units specified.
Attribute description: The outside diameter of the container in units specified.
Vocabulary domain:
ContainerCap
(CWE)
Attribute description: The type of cap that is to be used with the container for decapping, piercing or other mechanisms.
Vocabulary domain:
ContainerSeparator
(CWE)
Attribute description: A material such as a gel that is contained in blood collection tubes to facilitate separation of blood cells from blood serum by creating a physical "barrier" between them.
Attribute description: The distance from the Point of Reference to the separator material (barrier) within the container. This distance may be provided by the LAS to the instrument and/or specimen processing/handling device to facilitate the insertion of a sampling probe into the specimen without touching the separator. See the Point of Reference definition or in NCCLS standard AUTO5 Laboratory Automation: Electromechanical Interfaces.
Attribute description: The distance from the Point of Reference to the outside bottom of the container in units specified below. Refer to Point of Reference definition in section Glossary or in NCCLS standard AUTO5 Laboratory Automation: Electromechanical Interfaces.
Description of Device:
A device is anything used in an activity without being substantially changed through that activity. This includes durable (reusable) medical equipment as well as disposable equipment.
There are a few device concepts defined by HL7 version 2.3 which are suggested for use if the material is a device of one of the defined kinds and if it is not otherwise specified. See USAM documentation.
Devices commonly used to administer medication (from HL7 v2.3 table 0164) include: Applicator (AP), IV Soluset (IVS), and Buretrol (BT). Metered Inhaler (MI), Heparin Lock (HL), Nebulizer (NEB), PCA Pump (PCA), and IV Pump (IVP).
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.
Attributes of Device:
Attribute description: Name of the version of this device as designated by the manufacturer.
Attribute description: Name, version and release of the software that operates the device.
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").
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.
Attribute description: 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.
-
Attributes of Device_task:
- Device_task
is a specialization of:
Act
Description of Device_task:
An activity of an automated system. Such activities are invoked either by an outside command or are scheduled and executed spontaneously by the device (e.g., regular calibration or flushing.) The command to execute the task has mood_cd <= ORD; an executed task (including a task in progress) has mood_cd <= EVN, an automatic task on the schedule has mood_cd <= INT.
Attributes of Device_task:
Attribute description: The parameters of the task submitted to the device upon issuing of a command (or configuring the schedule of spontaneously executed tasks.) Parameters are only specified here if they are not included in separate HL7 defined structure. The parameters are a list of any data values interpreted by the device. The parameters should be typed with an appropriate HL7 data type (e.g., codes for nominal settings, such as flags, REAL and INT for numbers, TS for points in time, PQ for dimensioned quantities, etc.) However, besides this HL7 data typing, the functioning of the parameters is opaque to the HL7 standardization.
Rationale: Some parameters for tasks are uniquely defined by a specific model of equipment. Most critical arguments of a task (e.g., container to operate on, positioning, timing, etc.) are specified in an HL7 standardized structure, and the parameter list would not be used for those. The parameter list is used only for those parameters that cannot be standardized because they are uniquely defined for a specific model of equipment.
-
Attributes of Diagnostic_image:
Description of Diagnostic_image:
Class for holding attributes unique to diagnostic images.
Attributes of Diagnostic_image:
Vocabulary domain:
ImagingSubjectOrientation
(CWE)
Attribute description: Patient direction of the rows and columns of the image.
- Diet
is a specialization of:
Supply
Description of Diet:
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.
Attributes of Diet:
Attribute description: 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".
Attribute description: 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.)
- Employee
is a specialization of:
Role
Description of Employee:
A relationship between a person or organization and a person or organization formed for the purpose of exchanging work for compensation. The purpose of the role is to identify the type of relationship the employee has to the employer, rather than the nature of the work actually performed. (Contrast with Assigned_entity)
Attributes of Employee:
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 |
Attribute description: 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 |
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 |
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.
Attribute description: The salary amount paid by the employer to the employee.
OpenIssue: Is this the amount paid per the value specified in salary_type_cd?
Attribute description: The type of hazards associated with the work performed by the employee for the employer. For example, asbestos, infectious agents.
Attribute description: Protective equipment needed for the job performed by the employee for the employer. For example, safety glasses, hard hat.
Description of Entity:
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 that things can play (e.g. patient, provider), nor the relationships among things.
Attributes of Entity:
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 |
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.
Attribute description: 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
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 |
Attribute description: 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>
Attribute description: A name of the entity in the context of the Entity.type_cd attribute.
Attribute description: 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:
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.
Attribute description: The interval of time over which the entity has physical existence.
Attribute description: 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 |
Vocabulary domain:
EntityRisk
(CWE)
Attribute description: A code indicating the existence of a risk or hazard associated with the Entity.
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.
Attribute description: 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?
- Entity_heir
is a specialization of:
Entity
Description of Entity_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
-
Attributes of Financial_act:
- Financial_act generalizes:
- Financial_act
is a specialization of:
Act
Description of Financial_act:
An act utilized primarily for administrative (versus clinical) purposes.
Attributes of Financial_act:
Attribute description: 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.
-
Attributes of Financial_contract:
- Financial_contract
is a specialization of:
Act
Description of Financial_contract:
A contract whose value is measured in monetary terms.
Attributes of Financial_contract:
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.
-
Attributes of Financial_transaction:
Description of Financial_transaction:
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.
Attributes of Financial_transaction:
Attribute description: 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.
Attribute description: 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.
Attribute description: 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.
- Guarantor
is a specialization of:
Role
Description of Guarantor:
The double role-based association between a party in the role of guarantor and an organization in the role of healthcare provider .
Attributes of Guarantor:
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 |
-
Attributes of Imaging_modality:
- Imaging_modality
is a specialization of:
Device
Description of Imaging_modality:
Class to contain unique attributes of diagnostic imaging equipment.
Attributes of Imaging_modality:
Vocabulary domain:
PixelIntensityRelationship
(CWE)
Attribute description: The relationship between the Pixel sample values and the X-Ray beam intensity.
Attribute description: 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.
Attribute description: Value of pixels added to non-rectangular image to pad to rectangular format.
-
Attributes of Invoice_element:
Description of Invoice_element:
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.
Attributes of Invoice_element:
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.
Attribute description: A description of the number of instances of a product or service that is being billed or charged for.This attribute represents such concepts as 4 hours, 4 mg, 4 boxes, etc.
The unit of measure is restricted to a measurable unit such as liters, milligrams and hours. Non-measurable, but countable units such as boxes, packages, visits must not be specified using the unit component of the PQ data type, except as an annotation, marked by {xxx}.Refer to Data Types Part II Unabridged Specification, Appendix A :Unified Code for Units of Measure.
Specification of countable units can be handled with the following techniques:
(1) specify the countable unit in the invoice_element.cd.That is, a specific Invoice_element.cd would indicate that the item referenced by the act represents a box of 20 items.There would be a different Invoice_element.cd for a box of 40 items, and so on.
For example, if the Invoice_element.cd represents a box of 20 items, and the Invoice_element.unit_qty = 2 (no units), then this represents 2 boxes of 20 items for a total of 40 items.
(2) if more detail is required (e.g. to describe the composition, packaging, manufacturer of a product), then use a participation (type_cd = "PRD"), and a combination of role and entity classes to describe the details.
Attribute description: The monetary cost per unit being accounted. In constructing the ratio, the numerator must of data type MO, and the denominator must be a PQ, specified in the same manner as the unit_qty attribute.
Version 2.x reference:| FT1^10^00364^Transaction Quantity |
| FT1^22^00374^Unit Cost |
Attribute description: Used in financial calculations to derive amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving gross amounts is:
Units (Quantity) * Cost/Unit = 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 = Amount
For example, this could be 10 (Number of Treatments as Units) * $3.00 (Cost per Unit) * 1.5 (Factor) = $45.00 (Amount).
See related note on Points. Formula, with Points and Factors becomes:
Units * Cost/Unit * Points * Factor = Amount
Attribute description: Used in financial calculations to derive amounts from quantities of services delivered and/or goods received.
The simplest formula for deriving amounts is:
Units (Quantity) * Cost/Unit = 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 = 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 (Amount).
See related note on Factor. Formula, with Points and Factors becomes:
Units * Cost/Unit * Points * Factor = Amount
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 |
Attribute description: 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.
-
Attributes of Language_communication:
Description of Language_communication:
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.
Attributes of Language_communication:
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)
Vocabulary domain:
LanguageAbilityProficiency
(CWE)
Attribute description: A code classifying the level of proficiency in the language (e.g. excellent, good, fair, poor)
Attribute description: An indication of whether or not the language is the one preferred by the entity for the indicated mode.
-
Attributes of Living_subject:
- Living_subject generalizes:
- Living_subject
is a specialization of:
Entity
Description of Living_subject:
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.
Attributes of Living_subject:
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 |
Attribute description: The date and time of a living subject's birth or hatching.
Version 2.x reference:| NK1^16^00110^Date/Time of Birth |
| PID^7^00110^Date/Time of Birth |
| STF^6^00110^Date/Time of Birth |
| GT1^8^00412^Guarantor Date/Time of Birth |
| IN1^18^00443^Insured's Date of Birth |
Attribute description: An indication that the subject is dead.
Attribute description: The date and time that a living subject's death occurred.
Attribute description: A indication as to whether the living subject is part of a multiple birth.
Version 2.x reference:| PID^24^00127^Multiple Birth Indicator |
Attribute description: 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 |
Attribute description: 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 |
-
Attributes of Managed_participation:
Description of Managed_participation:
A "stateful" participation. The primary example would be attending practitioner for an inpatient encounter.
Rationale: The state attribute is being added to support attending physician participation on Encounters.
Attributes of Managed_participation:
Attribute description: A unique identifier for a participation.
Vocabulary domain:
ParticipationStatus
(CNE)
Attribute description: A code depicting the state of the participation (e.g., pending, active, complete, cancelled).
-
Attributes of Manufactured_material:
- Manufactured_material generalizes:
- Manufactured_material
is a specialization of:
Material
Description of Manufactured_material:
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.
Attributes of Manufactured_material:
Attribute description: 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.
Attribute description: The date and time the manufacturer stops ensuring the safety, quality, and/or proper functioning of the material.
Attribute description: Specifies the time at which the material is considered useable after it is activated (for instance through opening the bottle of a liquid.) If a kind of material is described (determiner_cd = KIND) only the width of that interval can be known, i.e., the duration after opening the reagent container at which the reagent substance is considered useable for its normal testing purpose. For an actual instance of the reagent (e.g., a specific bottle), the stability_time.low TS marks the time at which the reagent bottle has been opened (or the reagent was otherwise activated.) Together with the typical stability duration, this determines the stability_time.high TS beyond which the reagent is no longer considered useable for its normal testing purpose.
- Material
is a specialization of:
Entity
Description of Material:
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.
Attributes of Material:
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.
-
Attributes of Non_Person_living_subject:
Description of Non_Person_living_subject:
A non-human living subject..
Attributes of Non_Person_living_subject:
Vocabulary domain:
NonPersonLivingSubjectTaxonomicClassification
(CWE)
Attribute description: A code representing the taxonomy of the living subject.
Vocabulary domain:
NonPersonLivingSubjectBreed
(CWE)
Attribute description: A code representing the breed of the living subject.
Attribute description: A text string representing the genotypic or phenotypic strain of the living subject.
Vocabulary domain:
GenderStatus
(CWE)
Attribute description: A code indicating whether the reproductive organs of Non_person_living_subject have been surgically removed.
Attribute description: An indication that the living subject was euthanized.
-
Attributes of Observation:
- Observation
is a specialization of:
Act
Description of Observation:
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.
Attributes of Observation:
Attribute description: 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.
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 judgment 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:
ActSite
(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.
Attribute description: 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.
-
Attributes of Organization:
- Organization
is a specialization of:
Entity
Description of Organization:
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.
Attributes of Organization:
Attribute description: 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.
-
Attributes of Participation:
- Participation generalizes:
Description of Participation:
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 Certified_practitioner can participate in a Patient_encounter as a rounding physician or as an attending physician.
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 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 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) anesthetist. 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 anesthetist 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.
Attributes of Participation:
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 |
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:
ParticipationContextControl
(CNE)
Attribute description: Specifies if this participation can be inherited along conductive act-relationships.
Attribute description: 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.
Attribute description: A Participant can make a comment about this service item in the note_text attribute.
Attribute description: 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:
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.
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:
ParticipationSignature
(CNE)
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.
Attribute description: 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 retrieved 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.
- Patient
is a specialization of:
Role
Description of Patient:
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. The role is scoped by the provider.
Attributes of Patient:
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 |
-
Attributes of Patient_encounter:
- Patient_encounter
is a specialization of:
Act
Description of Patient_encounter:
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).
Attributes of Patient_encounter:
Vocabulary domain:
EncounterAdmissionSource
(CWE)
Attribute description: The source of the referral for a patient encounter.
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 |
Attribute description: 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 |
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:
EncounterAccident
(CWE)
Attribute description: A indication that the Living_subject was born during this Patient_encounter.
Version 2.x reference:| PV2^36^00737^Newborn Baby Indicator |
Vocabulary domain:
EncounterAcuity
(CWE)
Attribute description: A code depicting 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.
Vocabulary domain:
EncounterAdmissionUrgency
(CWE)
Attribute description: An indication that pre-admission tests are required for this patient encounter.
Version 2.x reference:| PV1^12^00142^Preadmit Test Indicator |
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 |
Attribute description: Descriptive text identifying where the patient's valuables are located.
Version 2.x reference:| PV2^5^00185^Patient Valuables |
Attribute description: Descriptive text identifying where valuables of patient is located.
Version 2.x reference:| PV2^6^00186^Patient Valuables Location |
Description of Person:
An individual human being.
Attributes of Person:
Attribute description: 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:
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 |
Vocabulary domain:
EducationLevel
(CWE)
Attribute description: The amount of education a person achieved.
OpenIssue: Need example values.
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 non-clinicians 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:
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:
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.
Vocabulary domain:
Race
(CWE)
Attribute description: A code depicting the race of a person.
Version 2.x reference:| IN2^71^00113^Race |
| NK1^35^00113^Race |
| PID^10^00113^Race |
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 |
- Place
is a specialization of:
Entity
Description of Place:
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.)
Attributes of Place:
Attribute description: Indicates whether the facility is considered mobile.
Attribute description: The physical address of this place. (ADDR.use must be PHYS)
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 |
Attribute description: 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 neighbor down the road".
EXTREF: PHCDM-02.01.04.01
Attribute description: A set of codes that locates the site within a mapping scheme. For example, map coordinates for US Geological Survey maps.
Attribute description: 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.
- Procedure
is a specialization of:
Act
Description of Procedure:
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.
Attributes of Procedure:
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:
ActSite
(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., acupuncture, 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:
ActSite
(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., acupuncture, 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.
-
Attributes of Public_health_case:
Description of Public_health_case:
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 to broaden the concept, the name and the description.
Attributes of Public_health_case:
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:
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.
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.
- Referral
is a specialization of:
Act
Description of Referral:
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 attributes? Their descriptions do not reveal the difference, nor does the class description.
Attributes of Referral:
Attribute 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.
-
Attributes of Relationship_link:
Description of Relationship_link:
Establishes a relationship link between two scoped Roles.
Attributes of Relationship_link:
Vocabulary domain:
RelationshipLinkType
(CNE)
Attribute description: Identifies the meaning and purpose of every Relationship_link instance.
Attribute description: The time span during which the link exists.
Description of Role:
Role defines the competency of an Entity. An Entity, in a particular Role, can participate in an 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 a practitioner can participate in a patient encounter as a rounding physician or as an attending physician. The Role defines the competency of the Entity irrespective of any Act, as opposed to Participation, which is limited to the scope of an Act.
Each role is 'played' by one Entity (the Entity that is in the role) and is usually 'scoped' by another. Thus the Role of 'patient' is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, the employer scopes an Employee role.
Two general rules distinguish between Entities that play a role versus those that scope a role. First, the relationship is one-to-many in the sense that each 'scoping' Entity instance, will scope MANY 'playing' Entity instances. (An Employer organization scopes many employees, but most employees have one or a few employers.)
Secondly, the identifier of the Role also identifies the Entity playing the role. This identifier is formally either issued by the scooping Entity or, at least, formally recognized by the scoping Entity. (This allows a Patient role identifier to be either a number issued by the scoping provider, or another identifier, like a social security number, that is used by the provider to identify its patients.)
Attributes of Role are those that are particular to the entity while in the particular role.
Rationale: Requires further constraint: invariant (Role x) where x.nonNull { x.played_by.nonNull.or(x.scoped_by.nonNull);}
Attributes of Role:
3.41.1 Role.class_cd
::
CS
(1..1)
Mandatory
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.)
Attribute description: 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.
3.41.3 Role.cd
::
CE
(0..1)
Vocabulary domain:
RoleCode
(CWE)
Attribute description: The "rich" code for Roles. Provides an extensive taxonomy of the possible instances of the class_cd. Domains will be drawn from a variety of sources, frequently external to HL7.
Attribute description: Indicates that the playing entity does NOT play the specified role. Allows for explicit exclusions in containment relationships, permission relationships, etc. Normally all roles are considered to be affirmitive. (This attribute defaults to FALSE.)
Attribute description: 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) |
Attribute description: 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 |
Vocabulary domain:
RoleStatus
(CNE)
Version 2.x reference:| PID^27^00130^Veterans Military Status |
Attribute description: The time span during which the Entity assumes this Role.
Attribute description: A certificate for the relationship between two entities. The certificate subject is the Entity at the target end of the Role; 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 retrieved 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.)
Attribute description: Used with composition-relationships (e.g., has-parts, has-ingredient, has-content) and specifies that a numerator amount of the target entity is comprised by a denominator amount of the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10:1; if 0.6 mL contain 75 mg of FeSO4 the ingredient relationship qty is 75 mg : 0.6 mL. Both numerator and denominator must be amount quantities (refer to the Entity.qty definition).
Attribute description: 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.
- Role_heir
is a specialization of:
Role
Description of Role_heir:
Rationale: It has been discovered that one cannot create an HMD choice structure for a set of classes, all of which are sub-types of Act, Role or Entity, but for which there is not a defined physical class. These are the classes that would have been in the RIM as direct descendants (heirs) of Act, Role and Entity, except for the fact that they carried no unique attributes or associations.
The addition of this single empty class in each hierarchy will permit messages with the appropriate and necessary choice structures to be built. Subsequent evolution of the methodology and tooling may permit the elimination of these classes in favor of an equivalent abstraction in the methodology.
-
Attributes of Schedulable_resource:
- Schedulable_resource
is a specialization of:
Role
Description of Schedulable_resource:
A Role of an Entity that can be scheduled.
Attributes of Schedulable_resource:
Attribute description: Duration for a single schedulable unit in a schedule for a resource.
OpenIssue: Not sure what this means.
-
Attributes of Substance_administration:
- Substance_administration
is a specialization of:
Act
Description of Substance_administration:
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.
Attributes of Substance_administration:
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). 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".
OpenIssue: should a specialized route_cd be replaced by a general anatomic site code.
Vocabulary domain:
ActSite
(CWE)
Attribute description: The detailed 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.
Attribute description: 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.
Open Issue: with the deletion of the strength_qty attribute, the use of attributes such as dose_qty and dose_check_qty has changed slightly. It is now no longer clear how doses such as 250 mg Amoxicillin 3/d are represented. With strength being in the Material class, dose_qty would have to be only 1. However, the administered object (e.g., capsule) is different from the amount of the leading ingredient that one would expect in a "dose quantity" attribute.
Attribute description: With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified. If specified as an interval, the rate should be anywhere 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.
Attribute description: 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 of the Ratio (RTO) data type. The numerator must be comparable to the dose_qty and the denominator must be an quantity of elapsed time. 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."
Rationale: This attribute incurs a constraint: invariant(Substance_administration med, RTO max) where med.max_dose_qty.contains(max) { max.numerator.compares(med.dose_qty); max.denominator.compares(1 s);}
Attribute description: Identifies the maximum total quantity of a therapeutic substance that may be administered to a subject over the period of time. The data type is a ratio (RTO) with the a value comparable to dose qty as numerator and a time duration as denominator, e.g. 500 mg/day; 1200mg/week.
Rationale: This attribute requires a constraint: invariant(Substance_administration med, RTO max) where med.max_dose_qty.contains(max) { max.numerator.compares(med.dose_qty); max.denominator.compares(1 s);}
Attribute description: Identifies the relative 'effectiveness' of the substance being administered. Intended to express concepts for homeopathic 'strength', and similar concepts.
Rationale: Note: This should NOT be used to represent standard ingredient strengths (measured in milligrams). This should be represented using the Composition relationship between a product and its active ingredient(s).
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 Substance_administration.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
is a specialization of:
Act
Description of Supply:
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". 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 Substance_administration class represents the administration of medication, while dispensing is supply.
Attributes of Supply:
Attribute description: Specifies the quantity ordered or supplied (depending on the mood_cd.)
Attribute description: Identifies the period time over which the supplied product is expected to be used, or the length of time the supply is expected to last. In some situations, this attribute may be used instead of Supply.qty to identify the amount supplied by how long it is expected to last, rather than the physical quantity issued. E.g. 90 days supply of medication (based on an ordered dosage), 10 hours of jet fuel, etc. NOTE: When possible, it is always better to specify Supply.qty, as this tends to be more precise. Supply.expected_use_time will always be an estimate that can be influenced by external factors.
-
Attributes of Working_list:
- Working_list
is a specialization of:
Act
Description of Working_list:
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.
Attributes of Working_list:
Vocabulary domain:
ListOwnershipLevel
(CWE)
Attribute description: Ownership_level_cd indicates the category of representation for the personnel managing the list, whether person, team or organization. Other values may be added as needed by an organization.
-
Attributes of Acknowledgement:
Description of Acknowledgement:
The Acknowledgement class contains information sent when acknowledging another message.
Attributes of Acknowledgement:
Vocabulary domain:
AcknowledgementType
(CNE)
Attribute description: This attribute contains an acknowledgement code as described in the HL7 message processing rules.
Version 2.x reference:| MSA^1^00018^Acknowledgement Code |
Vocabulary domain:
MessageCondition
(CWE)
Attribute description: This attribute allows for a coded error type.
Version 2.x reference:| MSA^6^00023^Error Condition |
Attribute description: 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 |
Attribute description: This attribute is used in the sequence number protocol.
Version 2.x reference:| MSA^4^00021^Expected Sequence Number |
-
Attributes of Attention_line:
Description of Attention_line:
This class allows parameters for a technology specific transport to be represented in the V3 message outer wrapper.
Attributes of Attention_line:
Attribute description: A parameter defining word.
Attribute description: A parameter value.
Description of Batch:
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: To be resolved when future work completed.
Attributes of Batch:
Attribute description: 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 |
Attribute description: This attribute is used by the application processing the batch.
Version 2.x reference:| BHS^9^00089^Batch Name/ID/Type |
Attribute description: 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 |
Attribute description: This attribute contains the count of individual transmissions contained within the batch.
Attribute description: The batch total. It is possible that more than a single batch total exists.
Version 2.x reference:| BTS^3^00095^Batch Totals |
-
Attributes of Character_data:
- Character_data
is a specialization of:
Entry
Description of Character_data:
Plain character data.
Attributes of Character_data:
Attribute description: Plain character data.
-
Attributes of Communication_function:
Description of Communication_function:
Relationship class binds the various entities which function in the transmission (sender, receiver, respond-to) to be linked to the transmission.
Attributes of Communication_function:
Vocabulary domain:
CommunicationFunctionType
(CNE)
Attribute description: The type of communication function being served by the entity with respect to the transmission, such as sender, receiver, respond-to party, etc.
Attribute description: The telecomm address that can be used to reach the entity that is serving this function.
-
Attributes of Context_structure:
- Context_structure generalizes:
- Context_structure
is a specialization of:
Act
Description of Context_structure:
A structure is a container within a document. Structures have captions which can be coded. Structures can nest, and structures can contain entries.
Attributes of Context_structure:
Attribute description: An optional identifier which must be unique within the document.
-
Attributes of Control_event:
- Control_event
is a specialization of:
Act
Description of Control_event:
The Event is the focal point of information assembled in response to the occurrence of a "controlled event." "Participations" and "Acts" related to a "controlled event" ard assembled in a package with the RIM content that a domain technical committee specifies as the main payload of information to be communicated to document the event. This package can be placed in a message envelope, directed to an application managing documents or any application with component interfaces to this package of structured information content.
OpenIssue: Look at the symmetry between how messages and documents are structured. This is work that is yet to be completed.
Attributes of Control_event:
Attribute description: Attribute identifying the structure of the payload portion of the message specified for this interaction.
Vocabulary domain:
ResponseLevel
(CNE)
Attribute description: Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should include.
Description of Entry:
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.
Attributes of Entry:
Attribute description: An optional identifier which must be unique within the document.
- Link
is a specialization of:
Entry
Description of Link:
A link is a generic referencing mechanism.
- Link_html
is a specialization of:
Entry
Description of Link_html:
Link_html is based on the HTML anchor tag, and enables HTML-style hyperlinking semantics.
Attributes of Link_html:
Attribute description: This attribute is part of the HTML anchor tag.
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.
Vocabulary domain:
HtmlLinkType
()
Attribute description: This attribute is part of the HTML anchor tag.
Attribute description: This attribute is part of the HTML anchor tag.
-
Attributes of Local_attr:
- Local_attr
is a specialization of:
Entry
Description of Local_attr:
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
Attributes of Local_attr:
Attribute description: The name of the local attribute.
Attribute description: The value of the local attribute.
-
Attributes of Local_markup:
- Local_markup
is a specialization of:
Entry
Description of Local_markup:
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
Attributes of Local_markup:
Attribute description: The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.
Attribute description: The render attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.
Vocabulary domain:
LocalMarkupIgnore
(CNE)
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").
-
Attributes of Logical_expression:
Attributes of Logical_expression:
Vocabulary domain:
SQLConjunction
(CNE)
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.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
Description of Message:
The Message class is the parent class of all HL7 Version 3 messages.
Attributes of Message:
Attribute description: This attribute is matched by the receiving system to its own version to be sure the message will be interpreted correctly.
Version 2.x reference:| MSH^12^00012^Version ID |
Attribute description: The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for specifying a message.
Version 2.x reference:| MSH^9^00009^Message Type |
Attribute description: The message profile identifier allows a given implementation to explicitly state how it varies from the standard message definition.
Vocabulary domain:
ProcessingID
(CNE)
Attribute description: This attribute defines whether the message is part of a production, training, or debugging system.
Version 2.x reference:| MSH^11^00011^Processing ID |
Vocabulary domain:
ProcessingMode
(CNE)
Attribute description: This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.
Version 2.x reference:| MSH^11^00011^Processing ID |
Vocabulary domain:
AcknowledgmentCondition
(CNE)
Attribute description: The attribute identifies the conditions under which accept acknowledgements are required to be returned in response to this message.
Version 2.x reference:| MSH^15^00015^Accept Acknowledgement Type |
Vocabulary domain:
AcknowledgmentCondition
(CNE)
Attribute description: This attribute contains conditions under which application level acknowledgements are to be returned in response to this message.
Version 2.x reference:| MSH^16^00016^Application Acknowledgement Type |
Attribute description: 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 |
Attribute description: 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. Additionally, the appropriateness of this attribute in the Message class is being questioned. An alternative to consider would be the placement of this attribute in a new class maintaining a 0 to many relationship with the Message class.
Description of Parameter:
The Parmeter class is an implementation class that represents the structure of parameters that may be specified with the Query-by-parameter mechanisms of the V3 query framework. Parameters may be set of name/value pairs, a named parameter list with a set of name/value pairs or any combination the previous two options.
Attributes of Parameter:
Attribute description: The Parameter.id can assist in tracing problems with implementing the query-by-parameter mechanism.
Attribute description: In a Parameter_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.
-
Attributes of Parameter_item:
- Parameter_item
is a specialization of:
Parameter
Description of Parameter_item:
Represents a valued element structure for the element specified in the query response.
Attributes of Parameter_item:
Attribute description: Represents a valued element structure for the element specified in the query response.
Vocabulary domain:
String
(CWE)
Attribute description: The Parameter_item.type_cd attribute provides a unique identification to an element within a specified query response structure.
- Parameter_list
is a specialization of:
Parameter
Description of Parameter_list:
Specifies a named list of parameters (name/value pairs) that is referenced in a query conformance statement.
Description of Query_ack:
This class carries information sent with responses to a query.
Attributes of Query_ack:
Vocabulary domain:
<<unassigned>>
(CWE)
Attribute description: This attribute is the name of the query as defined by the 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 conformancd 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.
OpenIssue: Should this attribute be represented by an Instance Identifier (OID+ extension) or a code value within an HL7 vocabulary domain that can be extended by implementers of the standard?
Vocabulary domain:
QueryStatus
(CNE)
Attribute description: This attribute allows the responding system to return a precise response status.
Version 2.x reference:| QAK^2^00708^Query Response Status |
Attribute description: Specifies total number of instance matches for query specification associated with this query response instance.
Attribute description: Specifies number of matches for processed query specification that occur in current bundle of matches.
Attribute description: Specifies number of matches for processed query specification that have yet to be sent to receiver.
- Query_by_parameter
is a specialization of:
Query_spec
Description of Query_by_parameter:
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.
- Query_by_selection
is a specialization of:
Query_spec
Description of Query_by_selection:
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.
-
Attributes of Query_continuation:
Description of Query_continuation:
This class maintains the state information required at the application level to control the logical continuation of a query response.
Attributes of Query_continuation:
Attribute description: Specifies the instance number in the original query result set to start return in next query response message.
Attribute description: Specifies the number of instance matches to return in the next query response message.
-
Attributes of Query_event:
Description of Query_event:
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.
Attributes of Query_event:
Attribute description: 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. Query_event.query_id may remain the same across multiple interactions when performing continuations of a previous query.
-
Attributes of Query_spec:
Description of Query_spec:
This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification.
Attributes of Query_spec:
Vocabulary domain:
<<unassigned>>
(CWE)
Attribute description: This attribute is the name of the query as defined by the 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.
OpenIssue: Should this attribute be represented by an Instance Identifier (OID + extension) or a code value within an HL7 vocabulary domain that can be extended by implementers of the standard?
OpenIssue: Can the "Message.profile_id" attribute provide a means of supporting the need to have a mechanism for local implementations to specify query response pairs as local business requirements dictate.
OpenIssue: In Version 3, must we have an explicity interaction set defined for any ad hoc query request/query response pair that may want to be implemented? If it is reasonable to support local implementations of query request/query response interaction pairs with
(1) a generic query mechanism that allows specific query interaction pairs to be exchanged using a set of standard query interactions and
(2) a protocol for passing parameters which can allow applications to customize for local business requirements?
Vocabulary domain:
ModifyIndicator
(CNE)
Attribute description: Indicates whether the subscription to a query is new or is being modified.
Attribute description: The response_element_group_id identifies the specific message_type to be returned in the query response. This message_type must be chosed from the set of message types supported by the receiver responsibilities associated with the query interaction.
Vocabulary domain:
ResponseModality
(CNE)
Attribute description: Defines the timing and grouping of the response instances.
Vocabulary domain:
QueryPriority
(CNE)
Attribute description: Identifies the time frame in which the response is expected.
Version 2.x reference:| QRD^3^00027^Query Priority |
Attribute description: Defines the maximum size of the response that can be accepted by the requesting application.
Version 2.x reference:| QRD^7^00031^Quantity Limited Request |
Vocabulary domain:
QueryRequestLimit
(CWE)
Attribute description: Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application
Attribute description: Specifies the time the response is to be returned.
-
Attributes of Relational_expression:
Attributes of Relational_expression:
Attribute description: Identifies RIM element as subject of selection criteria evaluation.
Vocabulary domain:
RelationalOperator
(CNE)
Attribute description: Identifies common relational operators used in selection criteria.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
Attribute description: Value supplied for comparison using criteria.
Version 2.x reference:| VTQ^5^00700^Selection Criteria |
- Selection_expression generalizes:
-
Attributes of Sort_control:
Description of Sort_control:
Holds specification of sort order for instance matches to a query.
Attributes of Sort_control:
Attribute description: Identifies a RIM element in a query response.
Vocabulary domain:
Sequencing
(CNE)
Attribute description: Specifies sequence of sort order.
Attributes of Table:
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Vocabulary domain:
TableRules
(CNE)
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Vocabulary domain:
TableFrame
(CNE)
Attribute description: This attribute is part of the XHTML table model.
-
Attributes of Table_cell:
Description of Table_cell:
A cell in a table.
Attributes of Table_cell:
Vocabulary domain:
TableCellScope
(CNE)
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML model.
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML model.
-
Attributes of Table_column_structure:
Description of Table_column_structure:
A table column or column group.
Attributes of Table_column_structure:
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
-
Attributes of Table_structure:
- Table_structure generalizes:
Description of Table_structure:
A table structure is either a column structure, a row structure, or a table cell.
Attributes of Table_structure:
Attribute description: This attribute is part of the XHTML table model.
Attribute description: This attribute is part of the XHTML table model.
Vocabulary domain:
TableCellHorizontalAlign
(CNE)
Attribute description: This attribute is part of the XHTML table model.
Attribute description: An optional identifier which must be unique within the document.
Vocabulary domain:
TableCellVerticalAlign
(CNE)
Attribute description: This attribute is part of the XHTML table model.
-
Attributes of Transmission:
- Transmission generalizes:
Description of Transmission:
Represents information about a specific transmission of information from one application to another.
Attributes of Transmission:
Attribute description: Unique identifier of the transmission
Version 2.x reference:| MSA^2^00010^Message Control ID |
| MSH^10^00010^Message Control ID |
| FHS^11^00077^File Control ID |
| BHS^11^00091^Batch Control ID |
Attribute description: The date/time that the sending system created the transmission. If the time zone is specified, it will be used throughout the transmission as the default time zone.
Version 2.x reference:| MSH^7^00007^Date/Time of Message |
| FHS^7^00073^File Creation Date/Time |
| BHS^7^00087^Batch Creation Date/Time |
Attribute description: This attribute is specified for applications to implement security features for a transmission. Its uses is not further specified at this time.
Version 2.x reference:| FHS^8^00074^File Security |
| BHS^8^00088^Batch Security |
