Copyright 2001 by Health Level Seven
Link to Subjects and Classes
Link to Categories and Data types
Link to Stewardship and Class interests and DIMs
This data model was HTML encoded by software prepared for the HL7. Comments on presentation links or any bugs encountered may be addressed to:
HQ@HL7.org (HL7 Headquarters staff).
Organization: Health Level Seven
Version: V 0-103 20010516
Developed by: Modeling and Methodology
|
RIM_Acts RIM_Clinical_acts RIM_Communication_infrastructure RIM_Entities RIM_Financial_acts |
RIM_Message_control RIM_Roles RIM_Structured_documents RIM_unassigned All_Classes |
|
Container Device Entity Imaging_modality Language_ability |
Living_subject Manufactured_material Material Non_Person_living_subject Organization |
Person Person_Language Place Role |
|
Access Assigned_practitioner Certified_practitioner Employee Entity |
Guarantor Participation Patient Qualified_practitioner |
Relationship_link Resource_slot Role Schedulable_resource |
This model reflects changes determined to be "mandatory" for message designs during the HL7 Spring 2001 Working Group Meetings May 7-11, 2001. These changes were agreed to during a special M&M meeting on May 11, and will be harmonized during the July, 2001 Harmonization Meeting.
This release of the RIM is being made available to HL7 Committees developing messages to be submitted for ballot during the summer of 2001.
Comments on this model should be addressed to the co-chairs of the Methodology and Modeling Committee and/or sent to the M&M e-mail list at mnm@lists.hl7.org
|
|
|
Class steward is Patient Care
A role played by a Device when the Device is used to administer therapeutic agents (medication and vital elements) into the body, or to drain material (e.g., exudate, pus, urine, air, blood) out of the body. Typically an Access_device is a catheter or cannulainserted into a compartment of the body.
Therefore, target_body_site_cd and entry_site_cd are attributes of the Access_device. Note that the Access_device role primarily exists in order to describe material actually deployed as an access, and not so much the fresh material as it comes from the manufacturer. For example, in supply ordering a box of catheters from a distributor, it is not necessary to use the Access_device role class, since the material attributes will usually suffice to describe and identify the product for the order. But the Access_device role is used to communicate about the maintenance, intake/outflow, and due replacement of tubes and drains.
Devices in the role of an Access_device are typically used in intake/outflow observations, and in medication routing instructions. Microbiologic observations on the material itself or on fluids coming out of a drain, are also common.
OpenIssue: Can Entities other than Devices assume the role of Access_device? If so, perhaps the class is better named Access_material.
Specifies the anatomic site where the line or drain first enters the body. For example in a arteria pulmonalis catheter targets a pulmonary artery but the access approach site is typically the vena carotis interna at the neck, or the vena subclavia at the fossa subclavia.
The coding system is the same as for Procedure.access_site_cd., indeed the Access.approach_site_cd has been copied from the Procedure class into the Access role class. The value of the Access.approach_site_cd should be identical to the value of the Procedure.approach_site_cd of an associated access placement procedure. This attribute is used if such an associated access placement procedure is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a resource of many services, the access approach site becomes an important identifying attribute of the access itself.
The gauge of an access is a measure for the inner diameter of the tube (the lumen.) Typically catheter gauge is measured in terms of units not seen elsewhere. Those units are defined in the Unified Code for Units of Measure.
This is the anatomical target site of the access, i.e., the body compartment into which material is administered or from which it is drained. For example, a pulmonary artery catheter will have the target site arteria pulmonalis with or without a known laterality.
The coding system is the same as for Procedure.target_site_cd, indeed the Access.target_site_cd has been copied from the Procedure class into the Access role class. The value of the Access.target_site_cd should be identical to the value of the Procedure.target_site_cd of an associated access placement procedure. This attribute is used if such an associated access placement procedure is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a resource of many services, the target site becomes an important identifying attribute of the access itself. The target site is an important information that determine what kinds of substances may or may not administered (e.g., special care to avoid medication injections into an arterial access.)
|
|
|
Class steward is Control/Query/MasterFiles
The Acknowledgement class contains information sent when acknowledging another message.
This attribute allows for a coded error type.
|MSA^6^00023^Error Condition|
This attribute is used in the sequence number protocol.
|MSA^4^00021^Expected Sequence Number|
This attribute further describes an error condition. This text may be printed in error logs or presented to an end user.
|MSA^3^00020^Text Message|
This attribute contains an acknowledgement code as described in the HL7 message processing rules. Refer to HL7 table 0008 - Acknowledgement code for valid values.
|MSA^1^00018^Acknowledgement Code|
This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.
This connection shows the relationship of the acknowledgement to a specific HL7 V3 message
|
|
|
Class steward is Patient Care
An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An Act instance is a record of such an intentional action. The terms "act", "action", and "activity" are all used interchangeably, but Act has been selected as the name of this class.
Any intentional action can exist in different "moods" (See Unified Service Action Model (USAM 2.7) for a complete description of "mood"). For example, the mood of an action can tell whether the action actually occurred (Act.mood="event"), was ordered (Act.mood="order"), serves as a criteria to trigger further actions (Act.mood="event criterion"), defines the action, and more. (See the ActMood domain table in HL7 Vocabulary Domain Listings for the complete set of defined Act moods.) An Act instance represents an action in one and only one such mood. Thus, act events, orders, criteria, and definitions are all represented by an instance of Act.
Any instance of an Act assumes one and only one mood and will not change its mood along its life cycle. The moods definition, intent, order, event, etc. seem to specify a life cycle of an activity and thus seem like state changes. However, the actors of these different moods are different, and so is the data different. It is important to keep track of those differences (variances) in business processes. Therefore, the mood of an Act instance is static and not part of the state, not part of the life cycle. The progression of the idea of an act towards actualization (i.e., the progression from defined, through planned and ordered, to being performed) is called "business cycle" to distinguish it from the "life cycle" of a single act instance. Related Act instances that form such a "business cycle" are linked through the Act_relationship class (See also USAM 2.7).
Examples for acts in health care are: a clinical test, an assessment of health condition (such as problems and diagnoses), the setting of healthcare goals, the performance of treatment services (such as medication, surgery, physical and psychological therapy), assisting, monitoring or attending, training and education services to patients and their next of kin, and notary services (such as advanced directives or living will).
Acts have participants, which can be actors or targets (See USAM 2.7 for a complete description of "actor" and "target"). Examples of actors are nurses, doctors, family members, notary publics, and service organizations -- every person or organization that is capable of independent decisions and can thus be responsible (and liable) for the actions performed.
Target participants in an act may include the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or reflexive services.)
An act can have multiple active participants and multiple target participants, their specific role being distinguished in the "type_cd" of the respective instance of the Participation class. In particular, an act involving coordination of care may involve two or more active participants -- playing different roles -- who interact on behalf of a patient, family, or aggregate in the role of target participant. For example, a nurse (active participant) calls Meals on Wheels (active participant) on behalf of the patient (target participant).
An act includes the "results", "answers" or informational "procedure products" gained during the act. In this model, "results" do not exist without an act, and every clinical result, including those results gained accidentally, is gleaned via an act. In other moods, such as "definition", "goal", and "criterion", the results are the possible results, the expected or aimed-for results, or the tested-for results.
This is the time when the action happened, is ordered or scheduled to happen, or when it can possibly happen (depending on the mood of the Service object.)
When used with procedures and other events, this is the total time of activity including preparation and clean-up actions. Thus it may be longer than the effective time of the same act, which is the period during which the procedure actaully takes place.
The timing of actions is a very important concept that is explained in greater detail in USAMP-II part A, Section 2.5.3.
|DRG^2^00769^DRG Assigned Date/Time | |FT1^4^00358^Transaction Date|
For HL7 messaging, the Service.availability_dttm will be set according to the sender system. If the receiver system records the received information as new, it may set it’s own recording time to the time it received this information, rather than to the time specified by the information sender.
The Service.availability_dttm is an inert attribute with respect to the mood code. This means, it is the recording time of the service object regardless of its mood.
Rationale: A database that records a separate time stamp for both valid time and transaction time is called a bi-temporal database. Bi-temporal databases allow reconstructing at any time what users of the database actually could have known, versus what the state of the world was at that time. For example, one might record that a patient had a right-ventricular myocardial infarction effective three hours ago, but we may only know about this unusual condition a few minutes ago. Thus, any interventions from three hours ago until a few minutes ago may have assumed a usual left-ventricular infarction, which can explain why these interventions may not have been appropriate in light of the more recent knowledge about the prior state. However, the transaction time (or recording time) may vary from system to system.
A code specifying the kind of action (e.g. physical examination, serum potassium, patient encounter, financial transaction, etc.). The Act.cd specifies the act conceptually using a code from one of several, typically external, coding systems depending on the class of act, such as observations (LOINC), procedures (e.g., SNOMED), medication treatments (e.g., UMLS), etc.
Open Issue: for administrative acts, this code should actually be used, even though many administrative acts might be specified by Act.class_cd (e.g., encounter). However, sometimes we find further classifying codes (e.g., encounter class code) that can be appropriately mapped to the act code.
|FT1^18^00148^Patient Type| |PV1^18^00148^Patient Type|
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.)
|FT1^6^00360^Transaction Type| |FT1^7^00361^Transaction Code| |FT1^9^00363^Transaction Description - Alt| |PV1^2^00132^Patient Class|
This is a code that limits the disclosure of information about this service.
Confidentiality policies may vary from institution to institution and not all systems are capable of abiding by all details of the confidentiality policies enumerated in the vocabulary domainsuggested in the above table. However, these are the items that are being used in some institutions and which implementers may want to consider supporting.
It is important to note that good confidentiality of the medical record cannot be achieved through confidentiality codes only to filter out individual record items to certain types of users. There are two important problems with per-item confidentiality: one is inference and the other is the danger of holding back information that may be critical in a certain care situation. Inference means that filtered sensitive information can still be assumed given the other information not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as zidovudine for treatment of HIV infections. The problem of hiding individual items becomes especially difficult with current medications, since the continuing administration of the medication must be assured.
Aggregations of data should assume the privacy level of the most private action in the aggregation.
|PV2^21^00722^Visit Publicity Code|
The time at which the action focuses. This attribute is also known as the "primary" time (Arden Syntax) or the "biologically relevant time" (HL7 v2.x). While this attribute is of type GTS very often it will be a simple time range (IVL<TS>) or even a simple time stamp (which is all compatible with GTS.)
This attribute is distinguished from activity time.
For observations, the time of the observation action may be much later than the time of the observed feature. For instance, in a Blood Gas Analysis (BGA), a result will always come up several minutes after the specimen was taken, meanwhile the patient’s physiological state may have changed significantly. Even more so in history taking, when the doctor records an episode of Hepatitis A under which the patient suffered last year for several weeks. So, the effective time is the time at which the observation is applicable.
For surgical procedures the time between first cut and last suture is taken as the effective time of the procedure. For transport and supply services the critical time is the time en route or time of delivery respectively (discounting the travel time to the pick-up location and from the drop-off location.) So the effective time does not count in the overhead that is not relevant for the objective of the act. This overhead, however, is relevant for scheduling and potentially billing.
For administrative acts, such as patient encounters, this is the "administrative" time, i.e., the encounter start and end date required to be chosen by business rules, as opposed to the actual time the healthcare encounter related work is performed (which would be the activity_time.)
|PV1^44^00174^Admit Date/Time| |PV1^45^00175^Discharge Date/Time|
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.
|BLG^3^00236^Account ID| |DG1^8^00382^Diagnostic Related Group| |DRG^1^00382^Diagnostic Related Group| |FT1^2^00356^Transaction ID| |IN1^14^00439^Authorization Information| |IN1^35^00460^Company Plan Code| |IN1^46^00471^Prior Insurance Plan ID| |MRG^3^00213^Prior Patient Account Number| |PID^18^00121^Patient Account Number| |UB2^12^00564^Document Control Number|
This attribute indicates whether this act can be transacted upon independently from other acts. Some acts can only be manipulated as subordinate to a composite act others are abstractions of acts or inseparable act groups that should only be manipulated together. Since in principle everything that can be done can potentially be acted upon, this attribute is true by default.
Example for use: In the master file, this indicates whether an act is individually orderable. In an order, whether a component of the order can be individually removed or cancelled.
OpenIssue: Find a new name for this attribute
Indicates whether an ct is interruptible by asynchronous events (such as "through" conditions to turn false, or time running out??.) See discussion on activity plans in the USAM 2.7 document, part A.
This is the maximum number of repetitions of an act. If specified as an interval, the maximum number of repetitions is a value within the specified range. Typical values are 1, some other finite number, and the infinity (a specific null value for numbers.) See the discussion on service plans in the USAM 2.7 specification, part A, on how specifically this is used.
Webster's dictionary defines mood as a "distinction of form [..] of a verb to express whether the action or state it denotes is conceived as fact or in some other manner (as command, possibility, or wish)". This definition of mood can be directly applied to the USAM model, where the action (in natural language) may be conceived as an event that happened (fact), an ordered service (command), a possible service (master), and a goal (wish) of health care. One of the "infinitive" moods is used for describing potential acts that can have actual services associated with them. Common use of the infinitive mood is for dictionary entries (so called "master service") and all "knowledge" links (e.g., possible reason, cause, manifestation, etc.) Other special infinitives are “goal” and “trigger” mood. A goal describes a wish for a certain outcome (typically an observation) to be achieved in the future. An observation in goal mood is not actually made, thus is an infinitive. Goals are evaluated later. Triggers are service descriptions that can match actual services (like a query.) When a trigger matches, it enables, suggests, or demands the associated action to be performed. Triggers are most often used to fully describe PRN medication orders, but can serve to build reminder systems too.
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.
|PV1^4^00134^Admission Type| |PV2^25^00726^Visit Priority Code|
A code depicting the reason for and administrative or financial act. For Patient Encounter, it is the reason for a patient transfer associated with the encounter. Examples include roommate conflict, equipment malfunction, acuity change, etc.
OpenIssue: Clarify definition to make it clear which of the two locations that the reason is pertinent to: the source or the destination. The concept is OK though.
|PV2^4^00184^Transfer Reason|
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?
|IN1^32^00457^Billing Status| |IN3^23^00524^Second Opinion Status | |IN3^24^00525^Second Opinion Documentation Received| |PV2^16^00717^Purge Status Code| |PV2^24^00725^Patient Status Code|
The description of an act is a piece of free text or multimedia data that describes the act in all necessary detail. There is no restriction on length or content imposed on the Act.txt attribute. However, the content of the description is not considered part of the functional information communicated between systems. Descriptions are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects. As with any attribute of the Act class , the meaning of the Act.txt attribute is subject to the Act.mood_cd. For act definitions, the description can contain textbook-like information about that act. For act orders, the description will contain particular instructions pertaining only to that order. Filler order systems must show the description field to a performing provider.
OpenIssue: The descriptive text for this attribute needs to be revised for clarity and consistency.
|FT1^8^00362^Transaction Description|
|
|
|
Class steward is Orders/Observation
The Act_context is a specialization of an Act which explicitly contains a set of other Acts that share the same context. The "context" of an act is defined as the attribution ascribed to its containing Act_context.
OpenIssue: It is recognized as a useful construct but the implication of implied inheritance needs to be resolved. HL7 needs to be cautious about extending the class beyond its original use case. Cardinality on the Act/mulitiplicity needs to be reviewed (the suggestion is that needs to be 0 *).
The human language of character data can be specified using this attribute.
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.
|
|
|
Class steward is Patient Care
The Act_relationship class is a recursive associative class with two associations to the Act class, one named "source" the other named "target". Consider every Act_relationship instance an arrow with a point (headed to the target) and a butt (coming from the source.) For each relationship type, the functions (or roles) of source and target Act are different.
In principle the assignment of functions (roles) to each side of the relationship "arrow" is completely arbitrary. However since . The relationships associated with an Act are considered properties of the source act object. That means that the originator of the information reported in an act object is not only responsible for the attribute values of that object, but also for all its outgoing relationships.
The rule of attribution is that all act relationships are attributed to the responsible actor of the Act at the source of the Act_relationship (the "source act".)
With this recursive act relationship one can group actions into "batteries," e.g., LYTES, CHEM12, or CBC, where multiple routine laboratory tests are ordered as a group. Some groupings, such as CHEM12, appear more arbitrary; others, such as blood pressure, seem to naturally consist of systolic and diastolic pressure.
Acts may also be grouped longitudinally, in a sequence of sub-actions to form temporal and conditional (non-temporal) action paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).
Acts may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections of acts allow expressing logical branches as well as parallel tasks (tasks carried out at the same time.) These constructs can be organized in multiple layers of nesting, to fully support workflow management.
The Act_relationship class is not only used to construct action plans but also to represent clinical reasoning or judgments about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be linked with current clinical hypotheses. Problem lists and other networks of related judgments about clinical events are represented by the Act_relationship link too.
The Act_relationship.type_cd identifies the meaning and purpose of every Act_relationship instance. For a more detailed description of Act_relationship, see USAM 2.7.
Indicates when associated pre-conditions are to be tested.
In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.
The inversion indicator is used when the meaning of Act_relationship_type_cd must be reversed. For example, we define a relationship type reason to express the reason for an action as in:
a) "A cholecystectomy was performed because of symptomatic cholelithiasis without signs for cholecystitis." (cholecystectomy has-reason cholelithiasis)
This statement of rationale is attributed to the responsible performer of the cholecystectomy. Now consider the following statement:
b) "The finding of symptomatic gall stones (cholelithiasis) with no signs of acute cholecystitis suggests a cholecystectomy."
While sentence a) declares a reason for an action, sentence b) suggests an action. Reason and suggestion links are reciprocal, i.e., if X has-reason Y, then Y suggests X. The second statement would have been made by the originator of the cholelithiasis finding.
In the "network" of interrelated acts, we need to make sure that we do not lose proper attribution of statements to originators ("who said what?") Since attribution is so important, we adopt a very simple rule for it: an act relationship is always attributed to the originator of the source service. No exceptions to this rule are permitted whatsoever. If attribution needs to be different one can invert the relationship type by setting the inversion_ind attribute to "true".
If the inversion indicator is "true", source and target act swap their roles; that is, the reason and the suggested action swap their roles, so that cholecystectomy can be the source and cholelithiasis can be the target. Note that the attribution rule is always unchanged; i.e., the act relationship is always attributed to the responsible author of the source service, no matter what the inversion_ind value is.
In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.
A kill branch will only be executed if there is at least one active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather than being discontinued shortly after it is started.) A detached branch will be unrelated to all other branches, thus a kill branch will be discontinued no matter whether there are detached branches still running.
For conditions and criteria links, indicates whether the meaning is negative (condition must not be true.) Normally all conditions are interpreted as affirmative, i.e., the condition must be true. The negation_ind is part of the condition so that the Boolean outcome of the condition XOR-ed with the negation_ind of the condition link must be true. Thus, if the negation_ind is "true", we say the "condition is true", even if the test was negative.
The time that should elapse between clearance for execution of this activity and the actual beginning of execution. Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the act is executed after its pre-conditions become true.
This integer number allows specification of another kind of ordering amongst the outgoing relationships of an act. This is used to represent the priority ordering of conditional branches in act execution plans, or priority ranking in pre-condition, outcome or support links, and preferences among options.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same act instance and usually having the same relationship type) has a distinct priority number. If, however, some relationships in the bundle share the same priority number, we have a partial ordering. Those links with the same priority will have undefined ordering of consideration.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same service instance and usually having the same relationship type) has a distinct priority number. If, however, some relationships in the bundle share the same priority number, we have a partial ordering. Those links with the same priority will have undefined ordering of consideration.
This integer number allows one to specify an ordering amongst the outgoing relationships of an act. This is used to represent sequences of actions in execution plans.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle has a distinct sequence number. (A relationship "bundle" is a sub-set of the relationships originating in the same act instance and usually having the same relationship type). If, however, some relationships in the bundle share the same sequence number, we have a partial ordering. In such a case the acts with the same sequence number are concurrent.
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.
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.
|
|
|
Class steward is Patient Administration
An indication that the healthcare practitioner is a primary care provider.
|
|
|
Class steward is Control/Query/MasterFiles
This class allows parameters for a technology specific transport to be represented in the V3 message outer wrapper.
A parameter defining word.
A parameter value.
This relationship allows parameters for a technology specific transport to be represented in the V3 message. outer wrapper.
|
|
|
The Batch class is to specify a message which is a collection of HL7 V3 messages. This class is a placeholder for future specification work by the Control/Query TC.
OpenIssue
This attribute is available to capture comments related to the batch.
|BHS^10^00090^Batch Comment| |BTS^2^00090^Batch Comment|
The batch total. It is possible that more than a single batch total exists.
|BTS^3^00095^Batch Totals|
This attribute uniquely identifies a particular batch.
|BHS^11^00091^Batch Control ID|
This attribute contains the date/time that the sending application created the batch.
|BHS^7^00087^Batch Creation Date/Time|
This attribute contains the count of individual messages contained within the batch.
|BTS^1^00093^Batch Message Count|
This attribute is used by the application processing the batch.
|BHS^9^00089^Batch Name/ID/Type|
This attribute uniquely identifes the receiving application of the batch
|BHS^5^00085^Batch Receiving Application|
This attribute indicates the control identifier of the batch when it was originally transmitted.
|BHS^12^00092^Reference Batch Control ID|
This attribute is specified for applications to implement security features for an HL7 batch of messages. Its uses is not further specified at this time.
|BHS^8^00088^Batch Security|
This attribute uniquely identifies the sending application of the batch.
|BHS^3^00083^Batch Sending Application|
|
|
|
Class steward is Patient Administration
Billing account information particular to the national uniform billing form. In the United States, this information is used for claim production to receive payment for healthcare services provided.
A code depicting a condition.
EXTREF: This information is reported on UB92 FL 24-30.
|UB1^7^00536^Condition Code (35-39)| |UB1^12^00541^Spec Program Indicator (44) | |UB2^3^00555^Condition Code (24-30)|
A code depicting a event.
EXTREF: This information is reported on UB92 FL 32-35.
|UB1^16^00545^Occurrence (28-32)| |UB2^7^00559^Occurrence Code & Date (32-35)|
The date of the event depicted in occurrence code.
ExtRef: This information is reported on UB92-35.
|UB2^7^00559^Occurrence Code & Date (32-35)|
A code depicting an event which occurs over a span of time.
EXTREF: This information is reported on UB92 FL 36.
|UB1^13^00542^PSRO/UR Approval Indicator (87) | |UB1^17^00546^Occurrence Span (33) | |UB2^8^00560^Occurrence Span Code/Dates (36)|
The from date of the event depicted in occurrence span code.
ExtRef: This inormation is reported on UB92 FL 36.
|UB1^14^00543^PSRO/UR Approved Stay-Fm (88)| |UB1^18^00547^Occur Span Start Date(33) | |UB2^8^00560^Occurrence Span Code/Dates (36)|
The end date of the event depicted in occurrence span code.
ExtRef: This information is reported on UB92 FL 36.
|UB1^15^00544^PSRO/UR Approved Stay-To (89)| |UB1^19^00548^Occur Span End Date (33) | |UB2^8^00560^Occurrence Span Code/Dates (36)|
A quantitative value on a bill. The value is qualified by quantity type code.
ExtRef: The quantity of covered days, non-covered days, and co-insurance days are reported on UB92 FL 7, 8, and 9.
|UB1^3^00532^Blood Furnished-Pints Of (40)| |UB1^4^00533^Blood Replaced-Pints (41)| |UB1^5^00534^Blood Not Replaced-Pints(42)| |UB1^6^00535^Co-Insurance Days (25)| |UB1^8^00537^Covered Days (23) | |UB1^9^00538^Non Covered Days (24) | |UB1^11^00540^Number Of Grace Days (90) | |UB2^2^00554^Co-Insurance Days (9)| |UB2^4^00556^Covered Days (7)| |UB2^5^00557^Non-Covered Days (8)| |UB2^17^00815^Special Visit Count|
A code qualifying the quantity amount information on a bill (e.g., Blood furnished, blood not replaced, blood replaced, coinsurance day, covered day, non-covered day, grace day, special visit, . . .).
A value amount qualified by value code.
EXTREF: This information is reported on UB92 FL 39-41.
|UB1^10^00539^Value Amount & Code (46-49)| |UB2^6^00558^Value Amount & Code|
A code qualifying the billing information value amount.
EXTREF: This information is reported on UB92 FL 39-41.
|UB1^10^00539^Value Amount & Code (46-49)| |UB2^6^00558^Value Amount & Code|
|
|
|
Class steward is Patient Administration
A relationship between a certifier and an Individual_healthcare_practitioner to indicate where the certifier (who is the source of the Role_relationship) has granted a license or certificate to the practitioner (who is the target of the Role_relationship)
The type of board certification issued to the practitioner by the certifier.
OpenIssue: What is the relationship between this attribute and Healthcare_provider.specialty_cd?
The date recertification is required.
|
|
|
Class steward is Patient Administration
A type of insurance coverage provided to military veterans and federal workers.
OpenIssue: Expand definition. Explain national specificity.
A code depicting the handicapped program in which the patient is enrolled.
OpenIssue: Amplify definition. Please indicate how the program is typed, perhaps with example.
|IN2^65^00805^Military Handicapped Program |
A indication as to whether the champus non-avail certification is on file.
|IN2^18^00489^Champus Non-Avail Cert on File|
The date of retirement for the person covered by Champus.
|IN2^17^00488^Champus Retire Date|
The identifier of the Champus station.
|IN2^13^00484^Champus Station|
Interested committees Structured Document Committee
Plain character data.
Plain character data.
|
|
Class steward is Information Management (Medical Records)
A clinical document contains Observations and Acts and has the following characteristics: (1) Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements; (2) Stewardship - A clinical document is maintained by a person or organization entrusted with its care; (3) Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated; (4) Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document; (5) Human readability - A clinical document is human readable.
An optional identifier which must be unique within the document.
Interested committees Structured Document Committee
The clinical document body occurs in a clinical document and contains structured or unstructured components.
Interested committees Structured Document Committee
The coded_entry enables the insertion of codes from HL7-recognized coding schemes into clinical documents.
A globally unique identifier of this coded entry.
The code for this coded entry.
Class steward is Orders/Observation
Interested committees Patient Care
The Consent class represents informed consents and all similar medico-legal transactions between the patient (or his legal guardian) and the provider. Examples are informed consent for surgical procedures, informed consent for clinical trials, advanced beneficiary notice, against medical advice decline from service, release of information agreement, etc.
The details of consents vary. Often an institution has a number of different consent forms for various purposes, including reminding the physician about the topics to mention. Such forms also include patient education material. In electronic medical record communication, consents thus are information entities [use a different word to avoid confusion with the Entity class?] on their own and need to be managed similar to medical activities. Thus, Consent is modeled as a special class of Act.
The "signatures" to the consent document are represented electronically through Participation instances to the consent object. Typically an informed consent has Participation.type_cd of "performer" (the healthcare provider informing the patient, and "consenter", the patient or legal guardian. Some consents may associate a witness or a notary public (e.g., living wills, advanced directives). In consents where a healthcare provider is not required (e.g. living will), the performer may be the patient himself or a notary public.
Some consents have a minimum required delay between the consent and the service, so as to allow the patient to rethink his decisions. This minimum delay can be expressed in the act definition by the Act_relationship.pause_qty attribute that delays the service until the pause time has elapsed after the consent has been completed.
|
|
|
Class steward is Patient Care
A container is a manufactured material used to hold other things for purposes such as transportation or protection of contents from loss or damage. With amorphic substances (liquids, gases) a container is required. However, the content of a container is always distinguishable and relatively easily separable from the container, unlike the content (ingredient) of a mixture.
A container is related to a content material through Role_relationship.type_cd = "has content".
OpenIssue: What is NCCLS?
OpenIssue: Need to differentiate between geometric properties -- barrier, bottom, capacity, diameter, height -- in these definitions. What is a barrier_delta, a bottom_delta, etc?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, the kind of cover cap.
OpenIssue: Code appears to be undefined. This attribute will be dropped if we do not get in a half-way complete concept repertoire by September 2000.
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the container.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, a geometric property of the contained.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
From NCCLS, the kind of separator material.
OpenIssue: How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?
OpenIssue: Needs a vocabulary domain.
Interested committees Structured Document Committee
Content is a Structure which can nest recursively, which enables wrapping a string of plain text down to as small a chunk as desired. These content structure elements can serve as anchors, to be referenced as the original text that supports the use of a code.
|
|
|
Class steward is Scheduling
A device is anything used in an activity without being substantially changed through that activity. This includes durable (reuseable) medical equipment as well as disposable equipment.
There are a few device concepts defined by HL7 version 2.3 which are suggested for use in HL7 v2.3 as Material.type_cd values if the material is a device of one of the defined kinds and if it is not otherwise specified. See USAMP documentation, Table 38.
Table 38: Devices commonly used to administer medication (from HL7 v2.3 table 0164) Value Description Value Description AP Applicator IVS IV Soluset BT Buretrol MI Metered Inhaler HL Heparin Lock NEB Nebulizer IPPB IPPB PCA PCA Pump IVP IV Pump
OpenIssue: Currently there are no attributes of device that would not also be applicable to any kind of material. This role class is shown anyway, in order to make the use of material for devices obvious. If there are no properties defined for this class by September 2000 it will be deleted from the model.
This field identifies the current functional activity of the automated device. The value of alert_level_cd is determined by the machine itself.
Date of last calibration and/or inspection of the device.
OpenIssue: Is this linked somehow with the ‘maintainer’?
OpenIssue: Given the definition of the class, this attribute would be moved up to Manufactured_material.
The current state of control associated with the equipment. An equipment can either work autonomously (local_remote_control_state_cd="Local") or it can be controlled by another system (local_remote_control_state_cd="Remote").
Name of the version of this device as designated by the manufacturer.
Name, version and release of the software that operates the device.
|
|
Class steward is Orders/Observation
Class for holding attributes unique to diagnostic images.
Patient direction of the rows and columns of the image.
Class steward is Patient Administration
A broad categorization, based upon included procedures and diagnoses, that applies to a Healthcare event as a whole. Used for grouping and evaluating Healthcare encounters with respect to duration of care and cost.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File; Standard_Day_Stay>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
<see FIN2301:DRG_Master_File>
OpenIssue: Please provide a definition.
|
|
|
Class steward is Orders/Observation
Diet services are supply services, with some aspects resembling Medication services: the detail of the diet is given as a description of the Material associated via Participation.type_cd="product". Medically relevant diet types may be communicated in the Diet.type_cd, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances.
For diabetes diet one typically restricts the amount of metabolized carbohydrates to a certain amount per day (e.g., 240 g/d). This restriction can be communicated in the carbohydrate_qty.
OpenIssue: Unclear whether the same should not be expressed as associated observations in goal mood (observation.type_cd = carbohydrate intake.)
This value indicates the supplied biologic energy (Calories) per day. This physical quantity should be convertible to 1 kcal/d (or 1 kJ/d.) Note, that there is a lot of confusion about what is a "calorie." There is a "large Calorie" and a "small calorie." On "nutrition facts" labels, the large "Calories" is used. More appropriately, however, one should use the small calorie, which is 1/1000 of a large Calorie. In the Unified Code for Units of Measure, the proper unit symbol for the large calorie is "[Cal]" and for the small calorie it is "cal", or, more commonly used as a kilo-calorie "kcal".
OpenIssue: Need a complete reference for Unified Code for Units of Measure.
|
|
|
Class steward is Information Management (Medical Records)
Interested committees Structured Document Committee
Specialization of Act to add the characteristics unique to document management services.
A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).
OpenIssue: Many of the domain values overlap with values of service.status_cd. Other values are derivable from service.text and associated actors and their roles. Therefore we may ultimately not need this attribute.
Time a document is released (i.e., copied or sent to a display device) from a document management system that maintains revision control over the document. Once valued, cannot be changed. Intent of this attribute is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.
A report identifier that remains constant across all document revisions that derive from a common original document. An original report is the first version of a report. It gets a new unique value for Document_service.id, a new value for document_service.set_id, and has the value of document_service.version_nbr set to equal "1". An addendum is an appendage to an existing report that contains supplemental information. The appendage is itself an original report. The parent report being appended is referenced via an act_relationship, with ct_relationship.type_cd set to equal "APND" (for "appends"). The parent report being appended remains in place and its content and status are unaltered. A replacement report replaces an existing report. The replacement report gets a new unique value for Document_service.id, uses the same value for document_service.set_id as the parent report being replaced, and increments the value of document_service.version_nbr by 1. The state of the parent report being replaced should become "superceded" explicitly by another message, but is still retained in the system for historical reference.
A code depicting the storage status (e.g., active, archived, purged) of a report.
Version number is an integer starting at '1' and incrementing by 1. The first instance or original report should always be valued as '1'. The version number value must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.
|
|
|
Class steward is Patient Administration
A relationship between a person or organization and a person or organization formed for the purpose of exchanging work for compensation.
The type of hazards associated with the work performed by the employee for the employer. For example, asbestos, infectious agents.
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)
|GT1^50^00786^Job Code/Class| |IN2^47^00786^Job Code/Class| |NK1^11^00200^Next of Kin/Associated Parties Job Code/Class| |STF^19^00786^Job Code/Class|
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.
|GT1^50^00786^Job Code/Class| |IN2^47^00786^Job Code/Class| |NK1^11^00200^Next of Kin/Associated Parties Job Code/Class| |STF^19^00786^Job Code/Class|
The title of the job held, for example, Vice President, Senior Technical Analyst.
|GT1^49^00785^Job Title| |IN2^23^00494^Special Coverage Approval Title| |IN2^46^00785^Job Title| |NK1^10^00199^Next of Kin/Associated Parties Job Title| |STF^18^00785^Job Title|
Protective equipment needed for the job performed by the employee for the employer. For example, safety glasses, hard hat.
The salary amount paid by the employer to the employee.
OpenIssue: Is this the amount paid per the value specified in salary_type_cd?
A code categorizing the calculation method used by the employer to compute the employee’s salary. For example, hourly, annual, commission.
|
|
|
Class steward is Patient Administration
A detailed categorization, based upon included procedures and diagonses, that applies to the encounter.
OpenIssue: 1) This description does not appropriately appear to fit with the actual meaning of the class itself and is internally inconstent.. 2) The meaning of this class is ambiguous based upon its instance connections and attributes.
An indication that the DRG assignment has been or has not been approved by a reviewing entity.
|DG1^9^00383^DRG Approval Indicator| |DRG^3^00383^DRG Approval Indicator|
An indication as to whether the DRG assigned to this encounter contains a confidential diagnosis.
|DG1^18^00767^Confidential Indicator| |DRG^10^00767^Confidential Indicator|
The amount of the encounter cost that is beyond the standard cost amount for the assigned DRG.
|DG1^13^00387^Outlier Cost| |DRG^7^00387^Outlier Cost|
A description providing additional information about the assignment of the DRG to the encounter.
A code indicating that the grouper results have been reviewed and approved.
|DG1^10^00384^DRG Grouper Review Code| |DRG^4^00384^DRG Grouper Review Code|
The version and type of the grouper used to derive the DRG.
OpenIssue: Either the description or the attribute type of this attribute is wrong. If it is type ID, then it is simply 'The identifier of the grouper . . .' If it is both version and type, then there should be two attributes to hold this data.
|URS^4^00055^R/U What User Qualifier|
The number of days beyond the standard day count for the assigned DRG.
Rationale: This attrubute is required to meet reporting requirements on DRGs as imposed by HCFA.
|DG1^12^00386^Outlier Days| |DRG^6^00386^Outlier Days|
The portion of the total reimbursement amount designated for reimbursement of outlier days or costs.
|DRG^9^00771^Outlier Reimbursement|
A code depicting the type of outlier (day, cost) associated with the encounter DRG.
Rationale: This is the v2.3 reference
OpenIssue: This attribute and the attribute outlier_reimbursement_amt do not work together. Either this is the outlier_reimbursement_type_cd or the definition of outlier_reimbursement should be changed to correspond to the definition of outlier_days_amt.
|DG1^11^00385^Outlier Type| |DRG^5^00385^Outlier Type|
|
|
|
Entities are physical things or organizations and groupings of physical things. A physical thing is anything that has extent in space, and has mass. This hierarchy encompasses human beings, organizations, living organisms, devices, pharmaceutical substances, etc. This does not include events/acts/actions, the definition of things, the roles which things can play (e.g. patient, provider), nor the relationships among things.
Rationale: Participants in acts MUST be roles of entities. Subjects of physical acts MAY be roles of entities, however not everything that an act is focused on must be an entity (e.g., when treating a human patient, the human patient is an entity, but solving a problem or thinking about an issue does NOT make the problem or the issue an entity.)
OpenIssue: Rational may belong in a different part of the model.
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.
|IN2^14^00485^Champus Service|
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.)
|GT1^10^00414^Guarantor Type| |LOC^3^00945^Location Type-LOC|
The description of an Entity is a piece of free text or multimedia data that describes the Entity in all necessary detail. There is no restriction on length or content imposed on the Entity.desc attribute. However, the content of the description is not considered part of the functional information communicated between systems. Descriptions are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects.
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.
A unique identifier for an entity. Ideally each entity will have only one identifier assigned to it, however, since different systems will maintain different data bases, there may be different instance identifiers assigned by different systems. Note that an instance identifier is a pure identifier and not a classifier. That means, this identifier is not used to store information about what kind or type of entity this is. Note that for Material, serial numbers assigned by specific manufacturers, catalog numbers of specific distributors, or for inventory numbers issued by owners, the Role_relationship.id can also be used. This allows to more clearly express the fact that such a code is assigned by a specific party associated with that material. In any case, all values of Role_relationship.id may occur in Material.id just as well.
EXREF:C04.R097.20
A text string indicating the living subject's economic or psychological importance to the owner.
OpenIssue: There is a problem with this attribute. Shouldn't it be coded? Does it belong here at all?
A name of the entity in the context of the Entity.type_cd attribute.
Specifies the quantity of the given entity in coordination with the determiner_cd. For individual instances of Entities, the qty is 1. For a group of individual members, the qty is the number of individual members in the group. For an instance portion of a substance, the qty specifies the amount of that substance comprised by that portion. For an undetermined substance (kind) the qty servers two purposes at the same time: (a) it provides a means of relations between quantities specific for that substance, and (b) it is a reference quantity for the specification of ingredients or components.
In all cases, the qty is an extensive "amount" kind of quantity (e.g., number, length, volume, mass, surface are, energy, etc.) Note that most relative or fractional quantities are not amounts, in particular, mass fraction, substance concentration, mass ratios, percentages, etc. are not extensive quantities and are prohibited values for this attribute. The following table lists those extensive quantities that should typically be used for this attribute.
Table: Kinds of extensive quantities for amounts of material Kind of quantity|Typical Unit|Forms|Examples| Number|1|solid|Material that is large enough that is can be counted (“eaches”)| Mass|1 g|liquid, solid|Tissue chemical substances, food.| Amount of substance|1 mol|all|chemical substances, small particles.| Volume|1 L|liquid, gas|chemical substances in liquid and gas state, amorphic tissue.| Length|1 m|solid|long material measured in length, e.g., tape, pipes, hose, etc.| Area|1 m2|solid|flat material measured in area, e.g., covers, foils, etc.| Energy|1 J, 1 kcal|solid, liquid|chemical substances, especially food.| Catalytic amount|1 kat, 1 U, 1 i.U.|all|enzymes and other chemical substances having catalytic activity.| Radioactivity|1 Bq, 1 Cu|all|radioactive substances.| Reaction equivalent|1 Eq|all|ionized chemical substances measured through titration; deprecated, use proper amount of substance instead.|
Absolute quantities are specified directly as values of this attribute. For example, as a determined instance, 1 person is Person.qty = 1; a group of 5 people is Person.qty = 5; 1 tablet is Material.qty = 1; 30 tablets is Material.qty = 30; 1 mg of Glucose is Material.qty = 1 mg; and 50 mg of Glucose is Material.qty = 50 mg.
With undetermined kinds, the qty is but a reference quantity for the specification of the proportion of ingredients or components (e.g. through a has-part, has-ingredient, or has-content relationship.) For example, a kind of group with 60% females is Person(qty = 100) has-part Person(qty = 60; sex = female). Amoxicillin 500 mg per tablet is Material(Tablet, qty = 1) has-ingredient Material(Amoxicillin, qty = 500 mg). Glucose 50% (D5W) is Material(D5W, qty = 1 kg) has-ingredient Material(Glucose, qty = 50 g).
Material-specific quantity relations are expressed using the fact that the data type of this attribute is a set of physical quantity (SET<PQ>). If more than one qty value are specified in this set, each element in this set is considered to specify the same amount of the material. For example, for one liter of water one could use the set {1 L, 1 kg, 55.56 mol} to specify the volume, mass, and amount of substance for the same amount of water, this is equivalent with specifying the mass density (volumic mass 1 kg/L) and the molar mass (18 g/mol). For Glucose one could specify {180 g, 1 mol} according to the molar mass (180 g/mol).
OpenIssue: Needs data type: suggest set<PQ>
A code indicating the existence of a risk or hazard associated with the Entity.
The status_cd tracks the state of the Entity's state-transition model. This is typically a rather trivial state-transition model.
OpenIssue: The state transition model needs to be defined.
The telecom addresses for the organization.
|GT1^6^00410^Guarantor Ph Num- Home| |GT1^7^00411^Guarantor Ph Num-Business| |GT1^18^00422^Guarantor Employer Phone Number| |GT1^46^00749^Contact Person’s Telephone Number| |IN1^7^00432^Insurance Co Phone 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| |IN3^16^00517^Certification Contact Phone Number| |IN3^19^00520^Certification Agency Phone Number| |NK1^6^00195^Business Phone Number| |NK1^31^00749^Contact Person’s Telephone Number| |OM1^17^00602^Telephone Number of Section| |OM1^29^00614^Phone Number of Outside Site| |PID^13^00116^Phone Number - Home|
This relationship allows the originating organization for an HL7 V3 message to be identified
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
|
|
Interested committees Structured Document Committee
Entries are contained within structures. Some entries (e.g. Local_markup) can contain nested entries (e.g. Local_attr). Entries also occur in table cells and captions.
An optional identifier which must be unique within the document.
|
|
|
Class steward is Control/Query/MasterFiles
This class is defined to contain a file (group of batches) being processed following the HL7 batch protocol.
OpenIssue: This name does not appear to conform to the standard Class naming conventions, and should be corrected as a technical correction.
This attribute uniquely identifies a particular file.
|FHS^12^00078^Reference File Control ID|
This attribute contains the date/time that the sending application created the file.
|FHS^7^00073^File Creation Date/Time|
This attribute contains the number of batches contained in this fie
|FTS^1^00079^File Batch Count|
This attribute is a text field for comment that is not further specified
|FTS^2^00080^File Trailer Comment|
This attribute is used by the application processing the file.
|FHS^9^00075^File Name/ID|
This attribute uniquely identifies the receiving application of the file
|FHS^5^00071^File Receiving Application|
This attribute indicates the control identifier of the file when it was originally transmitted.
|FHS^12^00078^Reference File Control ID|
This attribute is specified for applications to implement security features for a file of a group of HL7 batches. Its use is not further specified at this time.
|FHS^8^00074^File Security|
This attribute uniquely identifies the sending application of the file
|FHS^4^00070^File Sending Facility|
|
|
|
Class steward is Patient Administration
An act utilized primarily for administrative (versus clinical) purposes.
The date and time range the class is valid.
ExRef: UB92 FL 17, UB91 FL 18
|IN3^22^00523^Second Opinion Date| |PV1^41^00171^Account Status| |PV1^44^00174^Admit Date/Time| |PV1^45^00175^Discharge Date/Time|
A code depicting the reason for the action.
OpenIssue: Need example codes.
|IN3^17^00518^Appeal Reason| |PV1^29^00159^Transfer to Bad Debt Code| |PV1^34^00164^Delete Account Indicator|
The effective date of the status.
OpenIssue: This likely to represent a whole set of attribution for change of state.
|PV1^30^00160^Transfer to Bad Debt Date| |PV1^35^00165^Delete Account Date| |PV2^17^00718^Purge Status Date|
|
|
|
Class steward is Patient Administration
A charge, credit, or adjustment to charges in a patient's billing account.
The transaction amount derived from multiplying the unit amount by the number of units.
OpenIssue: Note this is a derived attribute as described. Is MnM OK with this?
|FT1^11^00365^Transaction Amount - Extended|
A code depicting the fee schedule used for this financial transaction.
|FT1^17^00370^Fee Schedule|
The amount of the financial transaction that is applicable to the associated Healthcare benefit plan.
|FT1^15^00369^Insurance Amount|
The posting date of the financial transaction.
|FT1^5^00359^Transaction Posting Date|
transaction quantity.
OpenIssue: This attribute is not defined either here or in Version 2.3. It may be "number of units" but that is only a guess.
|FT1^10^00364^Transaction Quantity|
A unique identifier assigned to the batch in which this transaction belongs.
|FT1^3^00357^Transaction Batch ID|
The unit price of transaction. The cost of a single item.
OpenIssue: Note that the class carries no definitions to indicate what a unit is or what the kind (cd) for the unit should be.
|FT1^22^00374^Unit Cost|
The amount associated with one transaction unit.
OpenIssue: Note that the class carries no definitions or attributes to indicate what a unit is or what the kind (cd) for the unit should be.
|FT1^12^00366^Transaction Amount - Unit|
Class steward is Control/Query/MasterFiles
This class maintains the state information required at the application level to control the logical continuation of a query response.
Specifies the number of instance matches to return in the next query response message.
This attribute is valued by the initiating application to identify a query. Here it is intended to be used to match a request for more results from a query that has been previously initiated.
Specifies the which instances number in original query result set to start return in next query response message.
|
|
Class steward is Patient Administration
The double role-based assocation between a party in the role of guarantor and an organization in the role of healthcare provider .
A code depicting the credit rating (e.g., excellent, good, fair, questionable, poor).
|GT1^23^00774^Guarantor Credit Rating Code| |PV1^23^00153^Credit Rating|
|
|
|
Class steward is Patient Administration
A contract held by a stakeholder which specifies the financial responsibility of the stakeholder for a patient billing account.
A indicator used to determine whether or not a system should suppress printing of the guarantor's bills.
|GT1^22^00773^Guarantor Billing Hold Flag|
A code depicting the allowable mediums for billing under this guarantor contract.
|PV2^32^00733^Billing Media Code|
A code depicting which adjustments should be made to this guarantor's charges.
|GT1^26^00777^Guarantor Charge Adjustment Code|
A code specifying the duration of the contract.
OpenIssue: This does not appear to be a coded type. In V2.3 it is a NM, with the definition "Specifies the duration of the contract for user-defined periods." If 2.3 is right, it looks like a candidate for _amt with units of time.
|PV1^27^00157^Contract Period|
Code identifying the type of contract entered into by the guarantor for the purpose of settling outstanding account balances.
|PV1^24^00154^Contract Code|
The time period during which the guarantor contract is effective.
|GT1^13^00417^Guarantor Date - Begin| |PV1^25^00155^Contract Effective Date|
The rate of interest for this guarantor contract.
|PV1^28^00158^Interest Code|
Amount to be paid by the guarantor each period.
|PV1^26^00156^Contract Amount|
A code indicating the relative priority of this guarantor contract for a given patient billing account.
OpenIssue: If this is really a code, then give examples. It actually sounds like a priority number, in which case it should be priority_ranking_nbr.
|GT1^15^00419^Guarantor Priority|
|
|
|
Class steward is Patient Administration
The specification of the amount of financial coverage for a healthcare service or category of services. Example 1: physician office visit - 100% coverage, no co-pay in network, $15 co-pay out of network. Example 2: inpatient semi-private room rate @ 100%. Stop-loss of $2,000 per inpatient stay. Outpatient coverage: 80% with out-of-pocket limit of $2,000 per year. Note: each of the above examples would require more than one instance of this class to express.
Rationale: This class allows clinical and financial systems to communicate with payor systems regarding financial responsibility.
OpenIssue: Should this Class be 'masterized"? Is it *really* per patient, or per-plan, or associated in some other way?
A code depicting the nature of the coverage assertion (e.g. covered, excluded, coinsurance, co-pay, out-of-pocket/stop-loss, excluded, deductible, approval required, second opinion required). For example, when specifying physician office visit - 100% coverage, it indicates "coverage"; when specifying dental crowns excluded, it indicates "excluded"; when specifying psychiatric outpatient - subject to approval by Managed Care Gatekeeper, it indicates "approval required".
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|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^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|
A indicator used to determine whether or not authorization/certification is required. For example, this would be used in specifying that psychiatric outpatient visits are subject to approval by a Managed Care Coordinator.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|IN3^20^00521^Pre-Certification Req/Window|
An indication as to whether the patient has reached the copay limit.
Rationale: Attribute applies to coverage class.
|IN2^67^00807^Copay Limit Flag|
A code depicting the covered parties (e.g. individual, family).
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|IN2^19^00490^Baby Coverage| |IN2^59^00799^Policy Scope |
A code depicting the person's eligibility for coverage, e.g., for Medicaid (e.g aged, blind, disabled) or Medicare (e.g., age, disability.)
Rationale: Improves model by combining two previously distinct attributes in Medicare_coverage and Medicaid_coverage classes. There was no v2.3 x-ref for these attributes.
A code depicting the source of information about the insured's eligibility for benefits (e.g., insurance company, employer, insured presented policy, insured presented card, signed statement on file, verbal information, none, . . .).
Rationale: Attribute is related to coverage.
|IN2^27^00498^Eligibility Source|
An indicator as to whether or not the assertion applies to in-network or out-of-network. This would be used in specifying that physician office visits have a $15 co-pay for out-of-network or that physician office visits have no co-pay in-network.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
A code indicating how the policy information was obtained.
OpenIssue: This attribute may be deleted in the future; it is similar to Healthcare_benefit_product.eligibility source code. OpenIssue: Amplify definition. Need examples, explanation.
Rationale: Attribute is related to coverage.
The amount of the coverage assertion. For example, when specifying psychiatric coverage limitation - 50 outpatient visits per year, it would have the value 50; when specifying physician office visit-$15 co-pay out-of-network, it would have the value 15. The unit of measure is specified by the quantity_qualifier_cd.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|IN1^33^00458^Lifetime Reserve Days| |IN1^34^00459^Delay Before L. R. Day| |IN1^37^00462^Policy Deductible| |IN1^39^00464^Policy Limit - Days| |IN2^21^00492^Blood Deductible| |IN2^28^00499^Room Coverage Type/Amount| |IN2^29^00500^Policy Type/Amount| |IN2^30^00501^Daily Deductible|
A code specifying the type of units conveyed by the qty attribute. For example, when specifying psychiatric coverage limitation - 50 outpatient visits per year, the quantity would be 50 and the quantity qualifier code would be outpatient visits; when specifying inpatient stop-loss of $2000 per inpatient stay, the quantity would be 2000 and the quantity qualifier code would be dollars.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|IN1^33^00458^Lifetime Reserve Days| |IN1^34^00459^Delay Before L. R. Day| |IN1^37^00462^Policy Deductible| |IN1^39^00464^Policy Limit - Days| |IN2^21^00492^Blood Deductible| |IN2^28^00499^Room Coverage Type/Amount| |IN2^29^00500^Policy Type/Amount| |IN2^30^00501^Daily Deductible|
The maximum range amount. For example, when specifying dental coverage, orthodontics covered with 50% coinsurance for ages 8-15 years, this would have the value 15.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
The minimum range amount. For example, when specifying dental coverage, orthodontics covered with 50% coinsurance for ages 8-15 years, this would have the value 8.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
A code depicting the unit of measure for the range low and range high quantities. For example, when specifying dental coverage, orthodontics covered with 50% coinsurance for ages 8-15 years, this would have the value years.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
A code classifying healthcare services (e.g. physician office visit, inpatient semi-private room rate, outpatient coverage, dental, vision, orthodontics, psychiatric outpatient visit, surgical procedure).
ExtRef: HIPAA Implementation Guide for X12 271 Transaction
|IN2^21^00492^Blood Deductible| |IN2^28^00499^Room Coverage Type/Amount| |IN2^30^00501^Daily Deductible|
A code depicting a specific medical item, procedure or service (e.g. a pair of eyeglasses.)
OpenIssue: Is this attribute redundant with the connection to a masterfile class, possible Master_service? We need a better definition of the precise concept behind service_cd to know exactly to which class it belongs.
A modifier code depicting a qualifier for a particular service (e.g., bilateral procedure, repeat procedure by the same physician, distinct procedural service.)
A code depicting the time period for the benefit assertion (e.g. duration of an inpatient stay, calendar year). When specifying inpatient: stop-loss of $2,000 per inpatient stay, the value would be inpatient stay; when specifying outpatient coverage: 80% with out-of-pocket limit of $2,000 per year, the value would be year.
ExtRef: HIPAA Implementation Guide for X12 271 Transaction.
|IN2^28^00499^Room Coverage Type/Amount|
Class steward is Patient Administration
Either a healthcare product that can be purchased (as
a single package) from an insurer or an individual healthcare policy as it applies to an individual.
Description of the access protocol for designated services, for example, prior to elective surgery call (999) 999-9999.
A code serving as an additional refinement of an insurance plan. (e.g., standard, unified, maternity, . . .).
|IN1^31^00456^Type of Agreement Code|
An indication as to whether the insured agreed to assign the insurance benefits to the healthcare provider.
ExtRef: This information is reported on UB92 FL 53.
|IN1^20^00445^Assignment of Benefits|
A description of the healthcare benefit. For example, Healthpol-Plus is a health insurance offering of xyz company that offers additional vison and dental benefits over the standard Healthpol product.
Rationale: Clarify attribute name and definition.
OpenIssue: PAFM needs to continue to work on this definition since it is still to fuzzy. Need additional explicit examples. Committee will continue to work on definition and consult with Information Management.
The name of the benefit product.
|FT1^14^00368^Insurance Plan ID| |IN1^2^00368^Insurance Plan ID|
A code classifying the benefit product type (e.g., commercial, Medicare, Medicaid, . . .).
|DRG^8^00770^DRG Payor| |IN1^15^00440^Plan Type|
An indication as to whether this insurance product ever works in conjunction with other insurance plans or not. If it does not, it provides independent coverage and payment of benefits regardless of other insurance that might be available to the patient. For example, a cancer policy pays which pays a per diem rate regardless of other coverage is considered independent coverage. This attribute does not indicate the priorty order for coordination of benefits, or whether a patient is covered by multiple plans.
Rationale: This element is an IS datatype in 2.3 with suggested values of CO- Coodinated, IN - Independent.
|IN1^21^00446^Coordination of Benefits|
The priority sequence for an insurance plan that works in conjunction with other insurance.
|IN1^22^00447^Coord of Ben. Priority|
An indication as to whether charges for a baby should be combined with charges for the mother.
|IN2^20^00491^Combine Baby Bill|
A code indicating the type of coverage (e.g. hospital/institutional, physician/professional, both hospital and physician.)
|IN1^47^01227^Coverage Type| |LRL^4^01227^Coverage Type|
A indication as to whether the healthcare coverage is a group contract.
A code indicating the party to which the claim should be mailed (e.g., employer, guarantor, insurance company, patient, . . .).
|IN2^5^00476^Mail Claim Party|
The policy category code (e.g., ANC-ancillary, MMD-major medical)
|IN2^29^00500^Policy Type/Amount|
A code describing what information, if any, a provider can release about a patient.
OpenIssue: Need example codes or codes set.
ExtRef: This information is reported on UB92 FL 52.
|IN1^27^00452^Release Information Code|
A code depicting the status of the healthcare product.
OpenIssue: The x-ref 00487^Champus Status needs to be moved to a different class, currently under consideration. In 2.x, this referred to UB82 codes indicative active, deceased, or retired for claims.
|IN2^16^00487^Champus Status|
|
|
|
Class steward is Scheduling
Class to contain unique attributes of diagnostic imaging equipment.
The relationship between the Pixel sample values and the X-Ray beam intensity.
Value of pixels added to non-rectangular image to pad to rectangular format.
The inherent limiting resolution in mm of the equipment for high contrast objects for the data gathering and reconstruction technique chosen. If variable across the images of the series, the value at the image center.
|
|
Class steward is Patient Administration
A patient encounter involving a stay in an inpatient Healthcare_facility.
Length of stay when evaluated on discharge from hospital. The actual days quantity can not be simply calculated from the admission and discharge dates because of possible leaves of absence.
OpenIssue: Should there be a boolean indicator to specify "estimated" vs. "actual" rather than having this attribute mean two things?
|PV2^11^00712^Actual Length of Inpatient Stay|
|
|
|
Class steward is Patient Administration
An affirmation by an insurance company that it will pay for a specified service.
A count of the number of days for which this certification is valid.
|IN3^11^00512^Days|
The date range during which this certification is effective.
|IN3^6^00507^Certification Date/Time| |IN3^9^00510^Certification Begin Date|
A unique identifier for the certification assigned by the certification agency.
|IN3^2^00503^Certification Number|
The data and time the insurance coverage was verified.
|IN1^29^00454^Verification Date/Time|
The date/time that the certification was modified.
|IN3^7^00508^Certification Modify Date/Time|
A code depicting the reason or kind of denied request.
OpenIssue: Need code examples (#55).
|IN3^12^00513^Non-Concur Code/Description|
The date of the non-concurrence classification.
|IN3^13^00514^Non-Concur Effective Date/Time|
The dollar amount of the penalty that will be assessed if the precertification is not performed.
|IN3^5^00506^Penalty|
The date a report of eligibility (ROE) was received.
Rationale: IN1-26
OpenIssue: should it be placed in Preauthorization.authorized_period_begin_dt instead? If so then Healthcare_benefit_plan.report_of_eligibility_ind should be moved to that class as well.
|IN1^26^00451^Rpt of Eligibility Date|
An indication of whether the insurance carrier sent a report of eligibility identifying the benefits the patient is eligible for.
|IN1^25^00450^Rpt of Eligibility Flag|
|
|
|
Class steward is Patient Administration
A person’s ability to understand and/or express themselves in a given language.
A code depicting the method of expression of the language (e.g. expressed spoken, expressed written, expressed signed, received spoken, received written, received sign)
A code classifying the level of proficiency in the language (e.g. excellent, good, fair, poor)
Interested committees Structured Document Committee
A link is a generic referencing mechanism.
Interested committees Structured Document Committee
Link_html is based on the HTML anchor tag, and enables HTML-style hyperlinking semantics.
This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
This attribute is part of the HTML anchor tag.
Interested committees Structured Document Committee
The unstructured blob is used to represent an unstructured document body (meaning, a document body that does not have a standardized internal structure).
The list_type attribute specifies whether the list is ordered or unordered. Use an ordered list when the ordering of list items is meaningful.
Interested committees Structured Document Committee
A list item occurs within a list, and can contain nested structures and entries as well as an optional caption.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Administration
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.
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.
|GT1^9^00413^Guarantor Sex| |IN1^43^00468^Insured's Sex| |NK1^15^00111^Sex| |PID^8^00111^Sex| |STF^5^00111^Sex|
The date and time of a living subject's birth or hatching.
For newborn living subjects in a multiple birth, the order in which this living subject was born.
|PID^25^00128^Birth Order|
The date and time that a living subject's death occurred.
An indication that the subject is dead.
A indication as to whether the living subject is part of a multiple birth.
|PID^24^00127^Multiple Birth Indicator|
An indication that the living subject is (as in "has donated" or "is willing to donate") an organ donor.
|PD1^8^00760^Organ Donor|
Interested committees Structured Document Committee
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
The name of the local attribute.
The value of the local attribute.
Interested committees Structured Document Committee
A component used to map local semantics into the exchange standard when local semantics have not yet been standardized.
The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.
The ignore attribute tells the receiver to ignore just the <local_markup> tag (ignore="markup"), or to ignore the <local_markup> tag and all contained content (ignore="all").
The render attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain.
|
|
When more than one criteria is to be applied in the evaluation of candidate instances, a conjunction is supplied to identify how to relate an additional criteria. Reference HL7 Table 0210 - Relational conjunction for valid values.
|VTQ^5^00700^Selection Criteria|
|
|
|
Things or combination of things transformed for a particular purpose by a non-natural or manufacturing process. This class encompasses containers, devices, software modules and facilities.
The date and time the manufacturer stops ensuring the safety, quality, and/or proper functioning of the material.
OpenIssue: Given the definition of Material.effective_tmr, it doesn't appear that this attribute is necessary. If it is necessary, it belongs in the Material class, since non-Manufactured_materials can also expire.(e.g. eggs as food).
The lot number is a number used to identify a particular batch of manufactured material. It is usually printed on the label attached to the container holding the substance and on the packaging which houses the containerNote that a lot number is not meant to be a unique identifier, but is meaningful only when the product kind and manufacturer are also identified.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Care
A Material is an Entity that excludes Living_subjects and places. Manufactured or processed products are considered material, even if they originate in living matter. Parts (e.g. organs) derived from living subjects are Material that may need to be tracked through associations with the individual Living_subject from which they were obtained. Examples of Material are pharmaceutical substances (including active vaccines containing retarded virus), disposable supplies, durable equipment, implantable devices, food items (including meat or plant products), waste, traded goods, etc.
The time interval a certain Material is in existence. The high boundary of this interval is the expiration date if it is defined for the Material. An expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.
This is a classifier describing the form of the material. This includes the typical state of matter (solid, liquid, gas) and, for therapeutic substances, the dose form.
OpenIssue: Vocabulary domain should include, but is broader than, the DoseForm domain.
A code to describe how the Material needs to be handled to avoid damage. Examples include: Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.
|
|
|
Class steward is Control/Query/MasterFiles
The Message class is the parent class of all HL7 Version 3 messages.
OpenIssue: May need a type code to serve a purpose above and beyond the interaction_id, since the subtypes may not be fully enumerated.
Contains arbitrary attachments of data blocks to which can be referred to from the interior of the message. Any ITS is advised to represent the attachments behind the main message body. Attachments are referred to from the message body using the reference functionality of the ED data type.
OpenIssue: Constrain the use of the ED data type in the attachment message type.
For large data blocks, it may be easier to represent them as attachments rather than as inline data in the main message payload body. Digital signature blocks are best appended in attachments, since otherwise the signature itself would be part of the signed data.
Examples for ITS mappings of attachments are XML fragment and MIME multipart. The ED data type can contain a reference URL to an XML fragment (IDREF) where the fragment id (ID) is defined as an XML attribute of the attachment element. MIME multipart can be referred to by a URL of scheme "CID:" that refers to a MIME part with the corresponding "Content-ID" header.
The date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.
|MSH^7^00007^Date/Time of Message|
Unique identifier of message.
|MSA^2^00010^Message Control ID| |MSH^10^00010^Message Control ID|
The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for speciying a message.
OpenIssue: This may be better modeled as an association to the class Interaction (in the meta-model). It is possible that this may supply the type code for the message, or we may need an additional attribute to carry the type code.
|MSH^9^00009^Message Type|
This attribute defines whether the message is part of a production, training, or debugging system. In HL7 Version 2.x, the values for this id were drawn from HL7 table 0103.
|MSH^11^00011^Processing ID|
This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.. In HL7 version 2.x the values for this code were drawn from HL7 table 0207. Recommended V3 datatype is CV.
The message profile identifier allows a given implementation to explicitly state how it varries from the standard message definition
Unique identifier of receiving application of message.
OpenIssue: The elements of this attribute are semantically "paired" with the has_recipient (1,n)::Stakeholder association, which isn't properly express in this model.
This attribute allows a URL to define the address to which the message reply should be directed.
Unique identifier of the sending application of the message.
OpenIssue: Make the names consistent with the modeling sytle guide (as a technical correction).
|MSH^3^00003^Sending Application|
This attribute is provided for implementing the sequence number protocol. This field is incremented by one for each subsequent value assignment.
|MSH^13^00013^Sequence Number|
This attribute is matched by the receiving system to its own versioin to be sure the message will be interpreted correctly.
|MSH^12^00012^Version ID|
This connection shows the relationship of the acknowledgement to a specific HL7 V3 message
This relationship allows the originating organization for an HL7 V3 message to be identified
This relationship allows parameters for a technology specific transport to be represented in the V3 message. outer wrapper.
Message_interactions are the payloads of Messages. This is navigable in one direction only from Message to Message_interaction.
OpenIssue: Examine the symetry between the way messages and documents relate to the RIM including the way messages.
This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.
|
|
Class steward is Control/Query/MasterFiles
An messaging interaction is the bundle of information that is communicated for a particular purpose. For example, a "register new patient" interaction is the bundle of patient information along with the command (purpose) to enter that information into a registry. The message interaction also contains attribution about when it was issued, who issued it, etc.
A messaging interaction is a unique object no matter whether it is broadcasted, archived or replayed. A messaging interaction is usually the payload of a message. Multiple messages sent to multiple recipients may contain one identical messaging interaction. This can be demonstrated with the instance identifiers: the Message_interaction.id will be a constant unique identifier even if this interaction is copied, broadcasted, resent, stored, or replayed in multiple messages. Each message would have a different Message.id, but the Message_interaction.id would always be the same.
OpenIssue: Look at the symmetry between how messages and documents are structured. does message interaction support the idea of queries.
Attribute identifying the structure of the payload portion of the message specified for this interaction.
Message_interactions are the payloads of Messages. This is navigable in one direction only from Message to Message_interaction.
OpenIssue: Examine the symetry between the way messages and documents relate to the RIM including the way messages.
|
|
|
A non-human living subject..
A code representing the breed of the living subject.
An indication that the living subject was euthanized.
A code indicating the whether the reproductive organs of Non_person_living_subject have been surgically removed.
A code indicating the primary use for which the living subject was bred or grown.
A text string representing the genotypic or phenotypic strain of the living subject.
A code representing the taxonomy of the living subject.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Care
Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value) include specific information about the observed object. The type and constraints of result values depend on the kind of action performed.
Clinical documents commonly have ‘Subjective’ and ‘Objective’ findings, both of which are kinds of Observations. In addition, clinical documents commonly contain ‘Assessments’, which are also kinds of Observations. Thus, the establishment of a diagnosis is an Observation.
The observation action (Observation.type_cd) and observation result (Observation.value) are modeled as two aspects of the same concept, just like the two faces of a coin are not separable from each other. Most other published healthcare models, including earlier HL7 RIM versions, separate the activity of observing and the observation result into different classes. These models label the kind of action in one class and the kind of observation result in the other. In most cases, however, the test name is a label for both activity (Observation.type_cd) and the observation result (Observation.value).
Derived observations can be defined through association with other observations using relationships of derivation type (Act_relationship.type_cd = derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with a Hemoglobin (HGB) observation (Act_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (Act_relationship.sequence_nmb = 2) Since MCH = HGB / RBC, the value of the derivation expression would be "$1 / $2".
The derivation expression is a character string with a simple syntax similar to that of the UNIX "expr" utility, or the expression subset of the PERL or TCL language. All observations that are cited in the formula must be associated with the derived observation through links of type derivation with a unique Act_relationship.sequence_nmb. Such observation values are referred to by that sequence number preceded by a dollar sign ($).
Defined operators are addition (+), subtraction (?), multiplication (*) and division (/). Parentheses can be used to overcome the usual precedence (left to right, multiplication before addition.) In addition to the basic arithmetic operations the usual mathematical functions are defined.
This attribute allows for a very rough interpretation of the course or outcome of a service action. This is sometimes called "abnormal flags", however, the judgement of normalcy is just one of the common rough interpretations, and is often not relevant. For example, for the observation of a pathologic condition, it doesn’t make sense to state the normalcy, since pathologic conditions are never considered "normal."
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.
The anatomical site or system that is the focus of the observation, if applicable. Most observation target sites are implied by the observation code and definition. For example, "heart murmur" always has the heart as target. This attribute is used when the observation target site needs to be refined, to distinguish right and left etc.
If the subject of the Observation is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses. For example, if the subject is a lake, the site could be inflow and outflow, etc. If the subject is a lymphatic node, "hilus," "periphery," etc. would still be valid target sites.
The result value of an observation action. As was true with HL7 v2, this value can be of any data type. However, there are clearly more or less reasonable choices of data types as indicated below.
Kind of observation :: Data type ::Notes
(1) Quantitative measurements :: PQ ::Physical quantity (real number with unit.) This is the most usual choice. Note that numeric values must not be communicated as a simple character string (ST.)
(2) Titer (e.g., 1:64) and other ratios (e.g. 1 out of 1000) :: RTO :: A ratio of two integer numbers (e.g., 1:128.) Sometimes by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32) Such conventions are confusing and should not be followed in HL7 messages.
(3) Index (number without unit) :: REAL :: When a quantity does not have a proper unit, one can just send the number as a real number. Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %). An integer number should only be sent when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see below.)
(4) Ranges (e.g., < 3; 12-20) :: IVL<PQ> :: Interval of physical quantity. Note that sometimes such intervals are used to report the uncertainty of measurement value. For uncertainty there are dedicated data type extensions available.
(5) Ordinals (e.g., stage "IIa") :: CV, INT :: At this point, ordinals should be reported either as code values, (e.g., +, ++, +++; or I, IIa, IIb, III, IV) or as integers. In the future ordinals may be addressed by a separate data type.
(6) Nominal results, "taxons" (e.g. organism type.) :: CD :: The Concept Descriptor (CD) is the most common data type to use for categorical results (e.g., diagnosis, complaint, color.) Such qualitative results are rarely simple Code Values (CV) if there is a tightly defined code system which everyone uses.
(7) Image (still, movie) :: ED :: The encapsulated data type allows one to send an image (e.g., chest X-ray) or a movie (e.g., coronary angiography, cardiac echo.)
(8) Waveform :: Waveforms can be sent using the waveform template developed by the Automated Data SIG for version 2.3. A mapping onto version 3 is shown farther below. In addition one can use the Encapsulated Data (ED) data type to send waveforms in other formats.
(9) Formalized expressions :: ST :: The character string data type may exceptionally be used to convey formalized expressions that do not fit in any of the existing data types. However, use of the string data type is not allowed if the meaning can be represented by one of the existing data types. Note that many of the data types do have character string literal expressions too, so the field in the message can be formatted using character string literals and still have a distinct data type.
OpenIssue: We should revisit the proper attribute to be used to transmit clinical documents.
|
|
|
Class steward is Patient Administration
A formalized group of people with a common purpose (e.g. administrative, legal, political) and the infrastructure to carry out that purpose. Examples include companies and institutions, a government department, an incorporated body that is responsible for administering a facility, an insurance company.
The postal and residential addresses of an organization.
|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| |NK1^4^00193^Address| |OM1^28^00613^Address of Outside Site(s)| |PID^11^00114^Patient Address| |PID^12^00115^County Code|
The standard industry class code of the organization.
|
|
Class steward is Orders/Observation
An Outbreak is a Public_health_case where the occurrence in a community or region of cases of an illness in excess of those normally expected. The designation of an outbreak implies that a public health assessment of causality or at least of relatedness among cases has taken place. An outbreak is considered to be a special type of public health case (where a case, in this instance, may include many affected individuals), and may not simply be an aggregate of multiple cases although an outbreak may also be designated as an aggregate of multiple individual public health cases.
The period of time during which the outbreak takes place. The date on which an outbreak starts is the earliest date of onset among the cases assigned to the outbreak, and its ending date is the last date of onset among the cases assigned to the outbreak.
OpenIssue: Needs additional thought. Consider that this is already available.
Interested committees Structured Document Committee
A paragraph is a structure. It can contain a caption and it can contain entries.
|
|
|
This class specifies element name and value of element to be used to specify query response instance matches.
Identifies name of element field in HMD specified for query response.
Represents a valued element structure for the element specified in the query response.
|
|
|
Class steward is Patient Care
Participation defines how an Entity, in a particular Role, functions during the scope of an Act. Participation is limited to the scope of the Act, as opposed to Role, which defines the competency of an Entity irrespective of any Act. Note that a particular Entity in a particular Role can participate in an Act in many ways. Thus, a Person in the Role of Individual_healthcare_practitioner, can participate in a Patient_encounter as an a rounding physician or as an attending physician.
All people, things and locations involved in an Act (or for scheduling purposes "all resources of an activity") are associated with the Act as either actors or targets. Actors are mostly professional provider personnel, but also the patient (for self-administered services,) or a proxy (e.g. next of kin.) Actors can participate in an action in different ways. For example, primary surgeon, assistant surgeon, sterile nurse, and nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action. However, payers, supervisors, provider organizations (e.g., "MicroLab") and their delegates may be actors too, even though they might not be individual persons who have their "hands on" the action. The patient himself is a performing actor in self-care procedures (e.g. fingerstick blood glucose, insulin injection, etc.) The people and organizations that can be actors of a service action are capable of and accountable for their independent decisions. Capability of independent decision and accountable usually applies only to persons under the law, including both organizations and natural (human) persons. The notion of multiple actors, each with a specific Participation.type_cd (and possibly a Participation.function_cd), touches and partially overlaps the Role.type_cd of the involved Entity, and understanding the distinctions is important to use the RIM constructs correctly. On the one "side" actor functions look similar to Entity roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g., certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.) The professional credentials of a person may be quite different from what a person actually does. The professional credentials define an Entity's Role while what a person actually does during the course of an Act is defined by the Participation class. The most common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists. The opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse. Thus, roles and certification refer to the static capabilities of a person (person-related) while actors and Participation.type_cd refer to the particular function an actor played in the Act (activity-related.) The actor concept interferes with sub-activities. Whenever multiple actors are involved in an Act, each actor performs a different task (with the extremely rare exception of such symmetrical activities as two people pulling a rope from either end.) Thus, the presence of multiple actors could be equally well modeled as an Act consisting of sub-services (through the Act_relationship class,) where each service would have only one performing actor For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthesist. These three actors really perform different tasks, which can be represented as three related services: (a) the consent, (b) the surgery proper, and (c) the anesthesia service in parallel to the surgery. If we used the sub-services, the consenter, surgeon and anesthesist could simply be of actor type "performer." Thus the more sub-services we use, the fewer different actor types need to be distinguished, and the fewer sub-services we use, the more distinct actor types we need. Note that the perception of a task as "atomic" or "composite" (of sub-tasks) depends on local business rules and may differ from department to department. In principle, every task can be thought of as being a composite of sub-tasks. We thus say that actions are "fractal." The paradigmatic example of the fractal nature of activities is a "robotic arm" doing some simple action as reaching for a tool in front of it. The seemingly simple activity of the robotic arm decomposes into complex control and coordination procedures and movements, action of separate motors and switches, etc. (We sometimes use the key-phrase "robotic arm discussion" to recall the fractal nature of actions, since this example has been brought up over and over again, independently by different people.) As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In most cases, however, human resources are scheduled by teams (instead of individuals,) billing tends to lump many sub-tasks together into one position, and overall responsibility often rests with one attending physician, chief nurse, or head of department. This model allows both the multi-actor and the muli-service approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall service. Actors can participate in an action in different ways. For example, primary surgeon, assistant surgeon, sterile nurse, and nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action. However, payers, supervisors, provider organizations (e.g., "MicroLab") and their delegates may be actors too, even though they might not be individual persons who have their "hands on" the action. The patient himself is a performing actor in self-care procedures (e.g. fingerstick blood glucose, insulin injection, etc.)
The Stakeholders, people and organizations that can be actors and targets of a service action are capable of and accountable for their independent decisions. Capability of independent decision and accountable usually applies only to persons under the law, including both organizations and natural (human) persons. This "legal person" as a subject of legal rights and obligations is a very obvious interpretation of the RIM Stakeholder construct (it is a well-known legal notion.)
The notion of multiple actors with specific functions touches and partially overlaps on two "sides" with related concepts of the RIM, and understanding the distinctions is important to use the RIM constructs correctly. On the one "side" actor functions look similar to Stakeholder roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g., certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.) The professional credentials of a person may be quite different from what a person actually does. The most common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists. The opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse. Thus, roles and certification refer to the static capabilities of a person (person-related) while actors and Actor.type_cd refer to the particular function an actor played in the service (activity-related.)
On the other "side" the actor concept interferes with sub-activities. Whenever multiple actors are involved in a service, each actor performs a different task (with the extremely rare exception of such symmetrical activities as two people pulling a rope from either end.) Thus, the presence of multiple actors could be equally well modeled as a service consisting of sub-services (through the Service_relationship class,) where each service would have only one performing actor
For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthesist. These three actors really perform different tasks, which can be represented as three related services: (a) the consent, (b) the surgery proper, and (c) the anesthesia service in parallel to the surgery. If we used the sub-services, the consenter, surgeon and anesthesist could simply be of actor type "performer." Thus the more sub-services we use, the fewer different actor types need to be distinguished, and the fewer sub-services we use, the more distinct actor types we need.
Note that the perception of a task as "atomic" or "composite" (of sub-tasks) depends on local business rules and may differ from department to department. In principle, every task can be thought of as being a composite of sub-tasks. We thus say that actions are "fractal." The paradigmatic example of the fractal nature of activities is a "robotic arm" doing some simple action as reaching for a tool in front of it. The seemingly simple activity of the robotic arm decomposes into complex control and coordination procedures and movements, action of separate motors and switches, etc. (We sometimes use the key-phrase "robotic arm discussion" to recall the fractal nature of actions, since this example has been brought up over and over again, independently by different people.)
As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In most cases, however, human resources are scheduled by teams (instead of individuals,) billing tends to lump many sub-tasks together into one position, and overall responsibility often rests with one attending physician, chief nurse, or head of department. This model allows both the multi-actor and the muli-service approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall service.
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.
A code depicting the type of accommodation associated with this patient encounter (e.g., private, semi-private) during the period of time the encounter was associated with the specific Place.
|PV2^2^00182^Accommodation Code|
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.
A code specifying how the participant is involved in the act, e.g., as physically present, over the telephone, or in written communication. Particularly for author (originator) participants this is used to specify whether the information represented by the act was initially provided verbally, (hand)written, or electronically.
A Participant can make a comment about this service item in the note_text attribute.
Specifies whether the participant has performed some sort of signature for his participation in the act or whether such a signature is required. For example, a surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants. See also: Participation.signature_txt.
The signature by which the associated Entity endorses that its participation in the Act is as stated in the Participation.type_cd and that it assumes accountability for the Act accordingly. For example, an AUTHOR assumes accountability for the truth of the Act statement to the best of his knowledge, whereas an information RECIPIENT would only sign the fact that he has received the information.
The signature can be represented in many different ways either inline or by reference according to the ED data type. Typical cases are:
1) Paper-based signatures: the ED data type may refer to some document or file that can be retreived through an electronic interface to a hardcopy archive.
2) Electronic signature: this attribute can represent virtually any electronic signature scheme.
3) Digital signature: in particular, this attribute can represent digital signatures, for example, by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
A code depicting the state of the participation (e.g., pending, active, complete, cancelled).
The effective time range of the participation. Note that this is particularly important when the time range of the participation is less than the time range of the act.
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.
|
|
|
Class steward is Patient Administration
A relationship between a Living_subject in the Role of patient and a Healthcare_provider, typically established for the provision of healthcare services to the patient by the provider.
OpenIssue: · Refer to PAFM for business rules and appropriate code sets.
A code depicting the nature of publicity protections in place for this patient.
|GT1^38^00743^Publicity Indicator| |GT1^39^00744^Protection Indicator| |IN2^36^00743^Publicity Indicator| |IN2^37^00744^Protection Indicator| |NK1^22^00743^Publicity Indicator| |NK1^23^00744^Protection Indicator| |PD1^11^00743^Publicity Indicator| |PD1^12^00744^Protection Indicator|
An indication of the person's VIP type, for example, board member, diplomat, etc..
|PV1^16^00146^VIP Indicator|
Class steward is Patient Administration
A financial account established for a patient to track the billable amount for services received by the patient and payment made for those services.
A code depicting the type of adjustment applied to the patient billing account.
OpenIssue: Need example values.
|PV2^30^00731^Patient Charge Adjustment Code|
The amount recovered on a bad debt patient account.
|PV1^33^00163^Bad Debt Recovery Amount|
The amount of the patient billing account that was turned over to bad debt for collection.
|PV1^32^00162^Bad Debt Transfer Amount|
A indicator as to whether a certification is required.
|IN3^4^00505^Certification Required|
The current unpaid balance of a patient account.
|PV1^46^00176^Current Patient Balance|
A count of the number of insurance plans expected to provide insurance coverage for this patient account.
A code indicating the expected payment source.
The date a notice of admission was sent.
|IN1^24^00449^Notice of Admission Date|
A indicator documenting whether the insurance company requires a written notice of admission.
|IN1^23^00448^Notice of Admission Flag|
A code depicting a category for the source of payment.
OpenIssue: Need examples values.
|PV1^20^00150^Financial Class|
A reference to the unique identifier of the price schedule to be used for charges in the patient billing account.
|PV1^21^00151^Charge Price Indicator|
The date a report of eligibility was received.
A indicator to control the purge of the patient billing account and related data.
An indication as to whether the baby in a delivery patient stay should be billed separately.
Rationale: The attribute description (an indication as to whether the baby in a delivery patient stay should be billed directly) indicates the correct class.
|PD1^9^00761^Separate Bill|
The date authorization to bill was obtained.
|PV2^28^00729^Signature on File Date|
A code indicating a special program governing the billing account.
OpenIssue: Need example codes.
|PV2^18^00719^Special Program Code|
A indicator identifying whether the patient has reached the stoploss limit established in the contract master.
|IN2^68^00808^Stoploss Limit Flag|
An indicator as to whether charges should be suspended for a patient.
|IN2^66^00806^Suspend Flag|
The total amount of the adjustment made to the patient billing account.
|PV1^48^00178^Total Adjustments|
The total charge amount of the patient billing account.
|PV1^47^00177^Total Charges|
The total of the payments made on a patient billing account.
|PV1^49^00179^Total Payments|
|
|
|
Class steward is Patient Administration
Interested committees Patient Care
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).
A code depiciting the acuity (complexity of patient care, resource intensiveness of the patient care) of a patient's medical condition upon arrival. Values may be derived from formal acuity coding schemes such as RBS.
OpenIssue: PAFM and PC must work together on defining the concept of severity in the model.
The source of the referral for a patient encounter.
A indication that the Living_subject was born during this Patient_encounter.
|PV2^36^00737^Newborn Baby Indicator|
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
|PV1^36^00166^Discharge Disposition|
A categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) in which care is delivered. (Note that there is a many-to-many relationship between practice setting and the physical location where care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.)
An indication that pre-admission tests are required for this patient encounter.
|PV1^12^00142^Preadmit Test Indicator|
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).
|PV1^14^00144^Admit Source|
A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional courtesy, VIP courtesies.
|PV1^22^00152^Courtesy Code|
A code depicting the reason for the status change (e.g., patient cancelled the scheduled encounter, patient didn't arrive for the encounter).
OpenIssue: Need example values. Consider a more general strategy for dealing with update semantics and corresponding reasons.
Text describing the patient valuables left for safe keeping.
|PV2^5^00185^Patient Valuables|
Descriptive text identifying where valuables of patient is located.
|PV2^6^00186^Patient Valuables Location|
OpenIssue: This may not work properly with just the one association to cover both arrival and departure; the committee must examine other options such as more than one association, or a coding solution in the universal service id or some other mechanism to fix this problem.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An individual human being.
The address(es) of a Person.
|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| |NK1^4^00193^Address| |OM1^28^00613^Address of Outside Site(s)| |PID^11^00114^Patient Address| |PID^12^00115^County Code|
Identifies the person's transient state of mobility or factors which impact their state of mobility, e.g., ambulates with assistive devices, wheelchair-bound, bed-bound, etc.
OpenIssue: Verify that permanent vs. transient conditions are handled as separate attributes. Note that the presence of this attribute brings up to question the entire issue of observations and metaobservations made by non0clinicians for non-clinical purposes.
|GT1^34^00145^Ambulatory Status| |IN2^32^00145^Ambulatory Status| |NK1^18^00145^Ambulatory Status| |PV1^15^00145^Ambulatory Status|
A code identifying a person's disability, e.g., vision impaired, hearing impaired.
OpenIssue: Need example values.
|GT1^52^00753^Handicap| |IN1^48^00753^Handicap| |NK1^36^00753^Handicap| |PD1^6^00753^Handicap|
The amount of education a person achieved.
OpenIssue: Need example values.
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.
|GT1^44^00125^Ethnic Group| |IN2^42^00125^Ethnic Group| |NK1^28^00125^Ethnic Group| |PID^22^00125^Ethnic Group|
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.
|GT1^37^00742^Living Arrangement| |IN2^35^00742^Living Arrangement| |NK1^21^00742^Living Arrangement| |PD1^2^00742^Living Arrangement|
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.
|GT1^30^00781^Guarantor Marital Status Code| |IN2^43^00119^Marital Status| |NK1^14^00119^Marital Status| |PID^16^00119^Marital Status| |STF^17^00119^Marital Status|
A value representing a person's mother's maiden name (e.g. McKinnon, Reeves, Hughes)
Rationale: This is one of a set of attributes (e.g. a person's name, gender and date of birth) that is typically used as a distinguishing characteristic when determining which (of several) person records several represents the person in question.
A code depicting the race of a person.
OpenIssue: Need example values.
|IN2^71^00113^Race| |NK1^35^00113^Race| |PID^10^00113^Race|
A person's religious preference.
OpenIssue: Need example values.
|GT1^41^00120^Religion| |IN2^39^00120^Religion| |NK1^25^00120^Religion| |PID^17^00120^Religion|
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.
|
|
|
Class steward is Patient Administration
The language used by a person to communicate with other persons.
OpenIssue: See if this class and the Language_ability code can be collapsed into a single class using a prodiciency code for each language that is a set or list of entries.
A code indicating the language utilized by a person (e.g. Spanish, Italian, German).
|GT1^36^00118^Primary Language| |IN2^34^00118^Primary Language| |NK1^20^00118^Primary Language| |PID^15^00118^Primary Language|
An indication of whether or not the language is the one preferred by the person. This indicates the preferred language for a patient bill.
|
|
|
Class steward is Patient Administration
A physical place or site with its contained structures, if any. Place may be natural or man-made. The geographic position of a place may or may not be constant. Examples include a field, lake, city, county, state, country, lot (land), building, pipeline, power line, playground, ship, truck.
Places may be work facilities (where relevant acts occur), homes (where people live) or offices (where people work.) Places may contain sub-places (floor, room, booth, bed.)
Places may also be sites that are investigated in the context of health care, social work, public health administration (e.g., buildings, picnic grounds, day care centers, prisons, counties, states, and other focuses of epidemiological events.)
The address of this place.
|LOC^5^00948^Location Address| |RXA^11^00353^Administered-at Location| |RXD^13^00299^Deliver-to Location| |RXD^13^01303^Dispense-to Location| |RXE^8^00299^Deliver-to Location| |RXG^11^00299^Deliver-to Location| |RXG^11^01303^Dispense-to Location| |RXO^8^00299^Deliver-to Location|
A free text note that carries information related to a site that is useful for entities accessing that site. It could include directions for finding the site when address information is inadequate, GPS information is not available, and/or the entity accessing the site cannot make direct use of the GPS information. It could also include information useful to people visiting the location. E.g., "Last house on the right", "If owner not present, check whereabouts with neighbour down the road".
EXTREF: PHCDM-02.01.04.01
GPS coordinates of the place.
OpenIssue: This is really the GPS coordinates, and needs a different data type to capture the integers. Also, it needs a description.
Indicates whether the facility is considered mobile.
A set of codes that locates the site within a mapping scheme. For example, map coordinates for US Geological Survey maps.
|
|
|
Class steward is Patient Administration
An authorization for patient services by a third party prior to the delivery of the patient service.
The number of authorized encounters.
The date the authorized period begins.
A unique identifier assigned to the pre authorization.
Rationale: IN1-28
OpenIssue:
|IN1^28^00453^Pre-Admit Cert (PAC)|
The date and time the pre authorization is issued.
The date and time the preauthorization was created.
A description of restrictions associated with the preauthorization.
A code depicting the status of a preauthorization.
OpenIssue: Need examples values.
The date and time of the last status change.
|
|
|
Class steward is Orders/Observation
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.
The anatomical site or system through which the procedure reaches its target (see target_site_cd.) For example, a Nephrectomy can have a trans-abdominal or a primarily retroperitoneal approach; an arteria pulmonalis catheter targets a pulmonary artery but the approach site is typically the vena carotis interna or the vena subclavia, at the neck or the fossa subclavia respectively. For non-invasive procedures, e.g., accupuncture, the approach site is the punctured area of the skin.
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses.
Some approach sites can also be "pre-coordinated" in the Service definition, so that there is never an option to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
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.
The anatomical site or system that is the focus of the procedure. For example, a Nephrectomy's target site is the right or left kidney; an arteria pulmonalis catheter targets a pulmonary artery. For non-invasive procedures, e.g., accupuncture, the target site is the organ/system that is sought to be influenced (e.g., "the liver".)
If the subject of the Act is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the act focuses.
Some target sites can also be "pre-coordinated" in the Service definition, so that there is never an option to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
|
|
|
Class steward is Orders/Observation
A public health case is an Observation representing a condition or event that has a specific significance for public health. Typically it involves an instance or instances of a reportable infectious disease or other condition. The public health case can include a health-related event concerning a single individual or it may refer to multiple health-related events that are occurrences of the same disease or condition of interest to public health. An outbreak involving multiple individuals may be considered as a type of public health case. A public health case definition (Act.mood_cd = "definition") includes the description of the clinical, laboratory, and epidemiologic indicators associated with a disease or condition of interest to public health. There are case definitions for conditions that are reportable, as well as for those that are not. There are also case definitions for outbreaks. A public health case definition is a construct used by public health for the purpose of counting cases, and should not be used as clinical indications for treatment. Examples include AIDS, toxic-shock syndrome, and salmonellosis and their associated indicators that are used to define a case.
OpenIssue: Need to work wito broaden the concept, the name and the description.
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.
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.
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.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
A role of a Healthcare_provider. Examples include physician, midwife, nurse practitioner.
OpenIssue: Compare these values with the vocab domain when it exists.
The fellowship field of a physician.
OpenIssue: Need example codes. Need to reconcile with specialty_cd of Healthcare_provicer.
The physician residency code.
OpenIssue: Need example codes for this attribute.
|
|
|
Class steward is Control/Query/MasterFiles
This class contains the specification of all HL7 Version 3 queries. Attributes common to all queries appear in this class specification.
Specifies the time the response is to be returned.
This attribute may be valued by the initiating application to identify the query. It is intended to be used to match response messages to the originating query.
|EQL^1^00696^Query Tag| |ERQ^1^00696^Query Tag| |QAK^1^00696^Query Tag| |SPR^1^00696^Query Tag| |VTQ^1^00696^Query Tag|
Defines the maximum size of the response that can be accepted by the requesting application. The accepted units are drawn from HL7 Table 0126 - Quantity limited request.
|QRD^7^00031^Quantity Limited Request|
This attribute is the name of the query as defined by a function-specific chapters of this specification or by an implementation specific agreement. There is a one to one correspondence with a conformance statement for this query name. The query name is an identifier for this conformance statement. The HL7 standard will maintain a table of the standard queries as specified by an HL7 technical committee. Implementation specific queries will extend this table.
Indicates whether the subscription to a query is new or is being modified. Reference HL7 Table 0395 - Modify indicator for valid values.
Identifies the time fram in which the response is expected. Reference HL7 Table 0091 - Query priority.
Defines the timing and grouping of the response instances. References HL7 Table - 0394 - Response Modality for valid values.
|
|
|
Class steward is Control/Query/MasterFiles
This class carries information sent with responses to a query.
This attribute is valued by the initiating application to dientify a query. Here it is intended to be used to match response messages to the originating query.
|URS^9^00695^R/U Quantity/Timing Qualifier|
This attribute has same semantic meaning as specified in Query.message_query_name.
This attribute allows the responding system to return a precise response status. Reference HL7 Table 0208 - Query response status for values for this coded attribute.
|QAK^2^00708^Query Response Status|
Specifies number of matches for processed query specification that occur in current bundle of matches.
Specifies number of matches for processed query specification that have yet to be sent to receiver.
Specifies total number of instance matches for query specification associated with this query response instance.
Class steward is Control/Query/MasterFiles
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.
Class steward is Control/Query/MasterFiles
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.
Class steward is Control/Query/MasterFiles
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.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Administration
An introduction of a patient from a source caregiver to a target caregiver or provider institution, typically for the purpose of obtaining the target caregiver's assessment and treatment recommendations. A referral may authorize a specified quantity of a particular kind or level of service. A referral may also simply be a recommendation or introduction.
OpenIssue: What is the distinction between the reason_txt and the desc atriibutes? Their descriptions do not reveal the difference, nor does the class description.
The number of authorized referral visits.
OpenIssue: Unclear what this attribute does, how it is used, and whether it belongs here. Authorized_visits_qty sounds more like a property of a health coverage.
Free form text describing the referral.
OpenIssue: These attributes seem to overlap with features and functionality inherited from the Service class. Notably Referral.desc is identical to Service.txt and Referral.reason_txt is either also in Service.txt or represented through -- possibly coded -- associated Services (e.g., observations).
Free form text providing the reason for the referral.
OpenIssue: These attributes seem to overlap with features and functionality inherited from the Service class. Notably Referral.desc is identical to Service.txt and Referral.reason_txt is either also in Service.txt or represented through -- possibly coded -- associated Services (e.g., observations).
|
|
|
Identifies RIM element as subject of selection criteria evaluation.
Identifes common relational operators used in selection criteria. Reference HL7 Table 0209 - Relational operator for suggested values.
|VTQ^5^00700^Selection Criteria|
Value supplied for comparison using criteria.
|VTQ^5^00700^Selection Criteria|
|
|
|
Establishes a relationship link between two scoped Roles.
Class steward is Scheduling
A specific time interval of a Schedule, that can be tentative, scheduled, or blocked to prevent use.
OpenIssue: A booked resource_slot is a relationship between a patient and a provider, and a resource_slot is part of a schedule, which is a relationship between a provider and the entity that has the authority to fill the providers schedule. Therefore, resource_slot should be both a type of Role_relationship, and should use the existing "has_parts :: (0..n) Role_relationship :: is_part_of :: (0..1)" to associate with the relevant Schedule.
Defines the start, duration, and repeat cycle for a Resource_slot.
Class steward is Control/Query/MasterFiles
Contains the specification of a column of a virtual table for a query response.
Identifies HL7 data type to be associated with this column of a virtual table.
|RDF^2^00702^Column Description|
Identifies the content in column of a virtual table. For RIM content this is the element name of the corresponding attribute.
|RDF^2^00702^Column Description|
Identifies maximum width for this column in virtual table response.
|RDF^2^00702^Column Description|
|
|
|
Class steward is Patient Administration
A Role defines the competency of an Entity. An Entity, in a particular Role, can participate in an Act or can be related to another Entity in a particular Role. Note that a particular Entity in a particular Role can participate in an Act in many ways. Thus, a Person in the Role of Individual_healthcare_practitioner, can participate in a Patient_encounter as an a rounding physician or as an attending physician. A Role defines the competency of an Entity irrespective of any Act, as opposed to Participation which is limited to the scope of an Act.
Attributes of Role are those that are particular to the entity while in the particular role.
The address for the Entity in this Role.
|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| |NK1^4^00193^Address| |OM1^28^00613^Address of Outside Site(s)| |PID^11^00114^Patient Address| |PID^12^00115^County Code|
The "rich" code for Roles
A certificate for the relationship between the two entities. The certificate subject is the Entity at the target end of the Relationship, the certificate issuer is the Entity at the source end of the Relationship. The issuer certifies for his relationship to the target. For example, an employer can certify for his employee, an insurance can certify for his enrollee, a health authority for its licensee, a school for its graduate, etc.
The certificate can be represented in many different ways, either inline or by reference, according to the ED data type. Typical cases are:
1) Paper-based certificate: the ED data type may refer to some document or file that can be retreived through an electronic interface to a hardcopy archive.
2) Electronic certificate: this attribute can represent virtually any electronic certification scheme, such as, an electronically (incl. digitally) signed electronic text document.
3) Digital certificate (public key certificate): in particular, this attribute can represent digital certificates, as an inline data block or by reference to such data. The certificate data block would be constructed in accordance to a digital certificate standard, such as X509, SPKI, PGP, etc.
Note: for self-signed digital certificates both source and target of the relationship instance would be the same object instance (the relationship would be cyclic.)
A code specifying on a high, technical, and tightly controlled level the kind of role. This code is similar in nature as the names of the classes derived from Role in a refined message information model (R-MIM.)
Used with composition-relationships (e.g., has-parts, has-ingredient, has-content) and specifies how much of the target entity is comprised by the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10. The relationship numerator_qty specifies a relative amount (proportion) because Role-relationship.numerator_qty is the numerator of a fraction whose denominator is the relationship.denominatory. Therefore the relationship quantity must also be an amount quantity (refer to the Entity.qty definition), compound quantities such as percentages or concentrations are prohibited in this attribute and are not needed.
The time span during which the Entity assumes this Role.
The same piece of material may be given different identifiers by different responsible parties. For example, a manufacturer may assign a manufacturer id, a distributor may assign a catalog number, etc. All those identifiers can in principle occur under the Material.id attribute, i.e., as a property of the material itself. However, this attribute allows to make the scope of the id more clear, i.e. it helps to easily distinguish a specific manufacturer’s id from a distributor’s id much more directly and obvious as can be done using the assigning authority component of the instance identifier data type.
This attribute is for associations between entities where position is a relevant concept. For example, some containers have discrete positions in which content may be located. Depending on the geometry of the container, the position may be referenced as a scalar ordinal number, or as a vector of ordinal numbers (coordinates.) Coordinates always begin counting at 1.
Some containers may have customary ways of referring to the positions or no way at all. In absence of any specific regulation for a specific container type, the rule of thumb is that the coordinate that is changed earlier is positioned first. For an automated blood chemistry analyzer with a square shaped tray, this means that the first coordinate is the one in which direction the tray moves at each step and the second coordinate is the one in which the tray moves only every 10 (or so) steps.
OpenIssue: Other than for the container-content relationship, no use of the position_nbr attribute has been defined. There is also some conceptual overlap with other ways to describe position elsewhere in the model. For example, for a Role_relationship between a Material and a Facility entity, describing the current location of a mobile equipment, the position_nbr overlays with the notion of position in terms of GPS coordinate. Also, anatomical location of one entity in an biological entity is a position of sorts.
Used with composition-relationships (e.g., has-parts, has-ingredient, has-content) and specifies how much of the target entity is comprised by the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10. The relationship numerator_qty specifies a relative amount (proportion) because Role-relationship.numerator_qty is the numerator of a fraction whose denominator is the relationship.denominatory. Therefore the relationship quantity must also be an amount quantity (refer to the Entity.qty definition), compound quantities such as percentages or concentrations are prohibited in this attribute and are not needed.
In circumstances where a ratio is intended, this attribute values the numerator.
OpenIssue: If the only values are active/inactive, then this attribute may be derivable from effective_tmr.
|PID^27^00130^Veterans Military Status|
The electronic communication addresses for the Entity in this Role.
|GT1^6^00410^Guarantor Ph Num- Home| |GT1^7^00411^Guarantor Ph Num-Business| |GT1^18^00422^Guarantor Employer Phone Number| |GT1^46^00749^Contact Person’s Telephone Number| |IN1^7^00432^Insurance Co Phone 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| |IN3^16^00517^Certification Contact Phone Number| |IN3^19^00520^Certification Agency Phone Number| |NK1^6^00195^Business Phone Number| |NK1^31^00749^Contact Person’s Telephone Number| |OM1^17^00602^Telephone Number of Section| |OM1^29^00614^Phone Number of Outside Site| |PID^13^00116^Phone Number - Home|
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
The following constraint applies to this association:
Invariant (Role x) { not(x.played_by.equals(null)) or not(x.scoped_by.equals(null)) }
|
|
Class steward is Scheduling
A Role of an Entity that can be scheduled.
Duration for a single schedulable unit in a schedule for a resource.
OpenIssue: Not sure what this means.
Interested committees Structured Document Committee
A document structure that can contain a caption, and can contain nested structures.
|
|
|
Holds specification of sort order for instance matches to a query.
Specifies sequence of sort order. Refer to HL7 Table 0390 - Sequencing for valid values.
Identifies a RIM element in a query response.
|
|
Interested committees Structured Document Committee
A structure is a container within a document. Structures have captions which can be coded. Structures can nest, and structures can contain entries.
An optional identifier which must be unique within the document.
|
|
|
Class steward is Orders/Observation
Substance_administration is an Act using a Material as a therapeutic agent. The effect of the therapeutic substance is typically established on a biochemical basis, however, that is not a requirement. For example, radiotherapy can largely be described in the same way, especially if it is a systemic therapy such as radio-iodine.
Because Substance_administration deploys material substances, a number of attributes arguably pertain to the Material rather than the Substance_administration action. Therefore, some information may be representable in two ways: as attributes of the Substance_administration act or as attributes of the Material. For example, an amoxicillin treatment is usually described as "Substance_administration.cd = Amoxicillin"; however, it could also be described as "Substance_administration.cd = Administration" with an associated "Material.cd = Amoxicillin". At this point naming the Substance_administration action after the administered substance is the preferred strategy, so long as it is noted that "Substance_administration.cd = Amoxicillin" really represents "Substance_administration.cd = Administration-of-Amoxicillin". This design allows simple medications to be described without having to use the Material class. Only if such actions as dispensing are involved, or if a recipe prescription is written, should one have to deploy the Material class.
The detailled anatomical site where the medication is routed. Note, this attribute is only needed if the route_cd requires further specification. For example, if the route_cd is "by mouth", no further specification of approach site is needed. If, however, route_cd is intravenous or intra-muscular, the precise site may be specified in this attribute (e.g., right forearm or left deltoid muscle respectively.)
OpenIssue: There is some overlap with route_cd. Will have to determine if body site is better to be included with route or if it is better to try to split route and body site (so that for instance "SQ" is a route, while "left forearm" is the body site.
This attribute should not generally be used; it is only provided for a special purpose. In some countries, especially Japan, there is a regulatory requirement to note the total daily dose on the prescription and associated documentation. The purpose of this requirement obviously is to encourage and facilitate reviewing the total dose prescribed to avoid over- (or under-) dosage. Rather than to define a "total daily dose" attribute as HL7 v2.3 did, we define this general purpose dose_check_qty attribute that can be used in various ways as required by local business rules or regulations. For example, in Japan one would use this field as a total daily dose by calculating the "real" dose as noted above and then adjusting the denominator to 1 d (one day). For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the total daily dose as dose_check_qty = dose_qty (1) * strength_qty (250 mg) * activity_dttm (3 /d) = 750 mg/d. For an intravenous example, this term would be dose_check_qty = dose_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100 mL/h which can be calculated on a daily basis as dose_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d.
So, in Japan, the denominator of the dose_check_qty unit must always be 1 /d. In other countries the constraints on the dose_check_qty may be different or, most likely, the attribute would not be used at all. In any case this dose_check_qty attribute must not be used to carry any functional information.
The dose_qty is the amount of the therapeutic agent or other substance given at one administration event. If specified as an interval, the dose is a value in the specified range. This attribute can be used alone or in combination with a strength. In theory, for medications provided to patients, a physician’s prescription could suffice with just the dose specification. For example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength. The pharmacist can figure out the right preparation given what is available in stock or on the marketplace. When the pharmacist dispenses a particular preparation with a particular strength and packet size from a particular manufacturer, etc., this detail should be communicated using the Material class.
The physical form in which the substance is delivered. For therapeutic medications, examples include tablet, capsule, suppository, and solution. For environmental interventions, such as chlorination of the water supply, examples might include liquid or tablets.
OpenIssue: This field must have a mandatory HL7 table for interoperability purpose. Such a table could cover at least 90% of all cases.
Identifies the period of time over which the maximum total quantity of a therapeutic substance may be administered to a subject. e.g. 500 mg/day; 1200mg/week. In the situation of multiple reptitions, each max_dose_qty corresponds to the equivalent repetition of the max_dose_period_qty.
Identifies the maximum total quantity of a therapeutic substance that may be administered to a subject over the period of time identified by max_dose_period_qty. e.g. 500 mg/day; 1200mg/week. In the situation of multiple reptitions, each max_dose_qty corresponds to the equivalent repetition of the max_dose_period_qty.
With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified. If specified as an interval, the dose is a value in the specified range. The Pharmacotherapy.rate_qty is specified as a physical quantity in time (a duration.) Hence, the rate_qty is really the denominator of the dose rate (the dose_qty is the numerator). For example, if a Ringer’s solution is to be given at 100 mL/hour i.v., the dose_qty would be 100 mL and the rate_qty would be 1 h. Note that there is no difference in the actual values of dose_qty and rate_qty as long as the quotient of both has the same value. In this example, we could just as well specify dose_qty as 50 mL and rate_qty as 30 min, or 200 mL and 2 h or any other combination where the quotient equals 100 mL/h.
Note that in principle one could again suffice with just the dose_qty attribute specifying the rate right in that one attribute (e.g., dose_qty = 100 mL/h.) However this practice is not allowed. Systems that implement the semantics of units according to the Unified Code for Units of Measure would have no problem noting the fact that a dose_qty is really a rate. Other system however will have difficulties to tell an at-once dose from a dose rate from just looking at the units. If a system wishes to deal only with a single quantity describing the dosage, it can always calculate such a quantity as real_dose_qty = dose_qty x strength_qty / rate_qty.
The route by which the medication is administered. Medication route - when the medication is delivered to a living patient - is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise applied to the body (body_site_cd). It is an open issue whether a specialized route_cd could be replaced by a general anatomic site code. The typical routes are per os (PO), sublingual (SL), rectal (PR), per inhalationem (IH), ophtalmic (OP), nasal (NS), otic (OT), vaginal (VG) , intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and intra-cardial (IC). However, there are other routes and there are many variations as to how to access a specific route. For instance, an oral administration with the patient swallowing will usually have the same effect as if the same substance is given through a gastric tube. A more systematic approach to break down the route into components such as site of primary entry (e.g. oral, nasal), site/system of substance uptake (e.g. gastrointestinal, bronchial, nasal mucosa), method (e.g., swallow, inhale), and device (e.g., gastric tube, tracheal tube) should be considered. When the medication is delivered to an environmental site, or a location, the route code indicates a site on its "body".
Indicates whether an ordered or intended Substance_administration may be or has been substituted for a different Substance_administration. The fact that the actual service differs from the planned or ordered service, and the details of the variance can be seen by comparing the service as planned or ordered from the service as performed. Both service records should be sent in a message where this difference is important. The Pharmacotherapy.substitution_cd attribute is mainly used in an order, to specify whether an ordered service may be substituted and in what way it may be substituted.
Class steward is Orders/Observation
Supply orders and deliveries are very simple services that mainly focus on the delivered product. The product is associated with the supply service via Participation.type_cd="product". Just as with Medication services there are in principle two ways to represent the type and identity of supplied material, i.e. as the Supply.type_cd or as the Material.type_cd of the target material. With general supply orders the precise identification of the Material, its manufacturer, serial numbers, etc. is important, and supply services are only very marginal parts of the electronic patient record. Therefore, most of the detail information about the supply should be represented using the Material class.
Note that if delivery needs to be scheduled, tracked, and billed separately, one can associate Transportation services with the supply.
Pharmacy dispense services are represented as supply services, associated with a medication service. The medication class represents the administration of medication, while dispensing is supply.
Specifies the quantity ordered or supplied (depending on the mood_cd.)
|
|
|
Interested committees Structured Document Committee
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
|
|
|
Interested committees Structured Document Committee
A cell in a table.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML model.
This attribute is part of the XHTML table model.
Interested committees Structured Document Committee
A column in a table.
Interested committees Structured Document Committee
A group of table columns.
Interested committees Structured Document Committee
A table column or column group.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
Interested committees Structured Document Committee
A table data cell.
Interested committees Structured Document Committee
A table header cell.
Interested committees Structured Document Committee
A row in a table.
Interested committees Structured Document Committee
A group of table rows.
Specificies whether this is a header, footer, or body row group.
Interested committees Structured Document Committee
A table row or row group.
|
|
|
Interested committees Structured Document Committee
A table structure is either a column structure, a row structure, or a table cell.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
This attribute is part of the XHTML table model.
An optional identifier which must be unique within the document.
This attribute is part of the XHTML table model.
Class steward is Orders/Observation
Interested committees Patient Care
Transportation is the moving of a payload (people or material) from a location of origin to a destination location. Thus, any transport service has the three target instances of type payload, origin, and destination, besides the targets that are generally used for any service (i.e., performer, device, etc.)
OpenIssue: This may not work properly with just the one association to cover both arrival and departure; the committee must examine other options such as more than one association, or a coding solution in the universal service id or some other mechanism to fix this problem.
OpenIssue: The specializations of this class need to be harmonized in January 2001.
Interested committees Structured Document Committee
The unstructured blob is used to represent an unstructured document body (meaning, a document body that does not have a standardized internal structure).
The unstructured blob is stored in this field.
|
|
Class steward is Patient Care
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.
Ownership_level_cd indicates the category of representation for the personnel managing the list, whether personal, team or organizaion. Other values may be added as needed by an organization.
|
RIM_Datatype_Generalizations RIM_Datatypes RIM_Datatypes_Demographic RIM_Datatypes_Generic RIM_Datatypes_Instances |
RIM_Datatypes_Quantity RIM_Datatypes_Text RIM_Datatypes_Thing RIM_Datatypes_Time |
|
AD : PostalAndResidentialAddress ADXP : AddressPart EN : EntityName ENXP : EntityNamePart LIST<ADXP> : List_ADXP LIST<ENXP> : List_ENXP |
ON : OrganizationName PN : PersonNameType ST : CharacterString TN : TrivialName |
|
ANT : Annotated BAG : Bag EIVL : EventRelatedPeriodicIntervalOfTime HIST : History HXIT : History_item IVL : Interval IVL<INT> : Interval_of_integer IVL<TS> : Interval_of_time LIST : Sequence LIST<ADXP> : List_ADXP LIST<BL> : List_of_Boolean LIST<CR> : List_CR LIST<ENXP> : List_ENXP LIST<INT> : List_INT NPPD : NonParametricProbabilityDistribution PIVL : PeriodicIntervalOfTime PPD : ParametricProbabilityDistribution SET : Set |
SET<AD> : Set_Address SET<CE> : Set_CE SET<CV> : Set_CV SET<ED> : Set_ED SET<HXIT<T>> : Set_of_HXIT SET<II> : Set_of_II SET<INT> : Set_INT SET<OID> : Set_OID SET<ON> : Set_ON SET<PQ> : Set_of_Physical_Quantity SET<ST> : Set_ST SET<TEL> : Set_TEL SET<TS> : Set_of_TS SET<UVP<T>> : Set_UVP T : T UVN : UncertainValueNarrative UVP : UncertainValueProbabilistic |
|
IVL<INT> : Interval_of_integer IVL<PQ> : Interval_PQ IVL<TS> : Interval_of_time LIST<ADXP> : List_ADXP LIST<BL> : List_of_Boolean LIST<CR> : List_CR LIST<ENXP> : List_ENXP LIST<INT> : List_INT SET<AD> : Set_Address SET<CCR> : Set_CCR SET<CD> : Set_CD SET<CE> : Set_CE SET<CS> : Set_CS SET<CV> : Set_CV |
SET<ED> : Set_ED SET<EN> : Set_EN SET<HXIT<T>> : Set_of_HXIT SET<II> : Set_of_II SET<INT> : Set_INT SET<OID> : Set_OID SET<ON> : Set_ON SET<PQ> : Set_of_Physical_Quantity SET<ST> : Set_ST SET<TEL> : Set_TEL SET<TS> : Set_of_TS SET<UVP<T>> : Set_UVP |
|
ANY : DataValue BIN : BinaryData BL : Boolean INT : IntegerNumber LIST<BL> : List_of_Boolean MO : MonetaryAmount |
PQ : PhysicalQuantity QTY : Quantity REAL : RealNumber RTO : Ratio |
|
ANY : DataValue BIN : BinaryData BL : Boolean ED : EncapsulatedData |
LIST<BL> : List_of_Boolean ST : CharacterString |
|
ANY : DataValue GTS : GeneralTimingSpecification QTY : Quantity |
SET<TS> : Set_of_TS TS : PointInTime |
|
|
The postal and residential address data type is used to communicate mailing and home or office addresses. The main use of such data is to allow printing mail labels (postal address), or to allow a person to physically visit that address (residential address).
For example, a post box address is a postal address but not a residential address. Most residential addresses are also postal addresses. The residential address is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Only those parts of addresses that are conventional for designating mailboxes or home or office addresses are part of the address data type.
The postal and residential address data type is essentially a sequence of address part values, but adds to this a "use" code for information about when and if the address can be used for a given purpose. The property "formatted" has a character string value with the address formatted in lines and with proper spacing.
<Comment>Remember that semantic properties are bare of all control flow semantics. The property formatted could be implemented as a "procedure" that would "return" the formatted address, but it would not usually be a variable to which one could assign a formatted address. However, HL7 does not define applications but only the semantics of exchanged data values. Hence, the semantic model abstracts from concepts like "procedure", "return", and "assignment" but speaks only of property and value.</Comment>
The address use code is a set of indicators what a given address is to be used for. Examples include residential address (RES, to visit), postal address (PST, to send mail), temporary address (TMP), birth address (BRT), and bad address (BAD, useless address kept for the record.)
An address without specific use code might be a default address useful for any purpose, but an address with a specific use code would be preferred for that respective purpose.
An address part is essentially a character string that may have a type-tag signifying it’s role in the address. Typical parts that exist in about every address are street, house number, or post box, ZIP code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). Addresses are usually broken up into lines, which is indicated by special line-break tokens.
Addresses are conceptualized as text with added mark-up. The mark-up breaks the address into lines and describes the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The model is similar to HTML or XML markup of text.
The type of an address part indicates whether an address part is the ZIP code, city, country, post box, etc.
Annotated<T> is a generic data type extension supporting arbitrary free-text annotations (note) for any value of type T. The data type of the note property is CE, meaning that the note may be free text (usually) or may alternatively be coded.
Note that annotations are annotations of specific values. It is improper use of annotations to tag information to values which belong to another structure. For example, “specimen hemolyzed” is a property of a specimen, not of an observation value, and yet, in HL7 v2.x it was common to send this as an annotation to the observation segment.
Annotations must not be used when there are methods defined that are more robust. In HL7 v2.x installations, there has been a great number of annotations, about reference ranges or interpretation of values, recommendations, and more. In HL7 v3 most of this can – and must – be communicated in properly defined data structures. For example, recommendations may be treated as Service recommendation objects. Knowledge about interpretation can be presented in a defined text attribute, or as detailed knowledge structures.
Another problematic example is the utterance “forwarded to reference lab.” This is likely not an annotation of any specific data attribute, but rather a complex statement about the specimen or an order. However, this is an interesting case that may or may not be covered by properly standardized HL7-structures. What this shows is that such cases should be brought to the attention of the standards committee rather than hidden in some code tagged to a data value to which it doesn’t belong. In general, annotations should be used sparingly – almost never on a routine basis –, or else are an indication for a use case that should be given proper attention in the information model.
The domain of annotation notes can not be defined or circumscribed; every concept could potentially be used as an annotation. Therefore, coded annotations are very likely to be non-standardized and non-interoperable.
HL7 does not define a standard domain of coded annotations. In the HL7 methodology, the use cases and information requirements are explicitly modeled as well defined data elements. Instead of using coded annotations, HL7 users and implementers should reuse this same HL7 methodology to extend the standard, e.g., adding new classes, fields, messages, etc. Such extended messages are not standard HL7 messages, but are still clearer and better than lengthy tables of coded annotations; furthermore HL7 extensions may be fed into the HL7 standardization process.
Coded annotations should therefore be only used casually and temporary, to provide immediate remedy to an urgent business need, never to define long-lasting solutions.
This is the annotation as free-text or in coded form. Free text notes are conveyed in the original text property of the CE value, while the code property is NULL. The annotation is meant for display to users or administrators or for computer-processing of exceptions. The annotation must not be used for routine data exchange that is covered elsewhere by HL7. Example: "original was illegible."
|
|
|
The type DataValue defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type.
Every data value is of a data type. The data value implicitly carries the information about its own type. Thus, given a data value in an HL7 message, one can inquire about its data type. However, one can not change the data type of a data value simply by changing this type property (but see Section 2.3 for type conversions.)
A property can be of an exceptional value. Exceptional values express missing information and possi-bly the reason why the information is missing. Exceptional values are also called NULL-values, and the exception is called the "flavor" of NULL.
Thus, every data value is either a proper value or it is it NULL. If the value is NULL, the nullFlavor property is non-NULL. If the value is not NULL, its null flavor attribute is NULL (not applicable.)
When a property, RIM attribute, or message field is called mandatory this means that any non-NULL value of the type to which the property belongs must have a non-NULL value for that property. In other HL7 specification the term "mandatory" is used while this specification formulates the mandatory con-straint explicitly.
A bag is an unordered collection of elements where each element can be contained more than once in the bag. The bag is defined only briefly here for completeness, since bags are a commonly recognized collection type.
<ITS Note>A bag can be represented in two ways. Either as a simple enumeration of elements, including repeated elements, or as a "compressed bag" whereby the content of the bag is listed in pairs of element value and number. A histogram showing absolute frequencies is a bag represented in compressed form. The bag is therefore useful to communicate raw statistical data samples.</ITS-Note>
The semantic primitive for bags is the contains-function that maps element values to non-negative integer numbers, where zero means that the element value is not contained in the bag. An empty bag is distinguished from an exceptional bag value (the NULL bag.)
All communicated information must ultimately be physically encoded as binary data. Binary data is the most primitive yet the omnipotent encoding of all information.
Binary data is a sequence of uninterpreted bits. A bit is identical with a Boolean value. Thus, all binary data is semantically a sequence of Boolean values. The binary data type is protected, it should not be used directly but only inside the encoded data (ED) type described below.
ITS Note: the representation of arbitrary binary data is the responsibility of an ITS. How the ITS accomplishes this depends on the underlying Implementation Technology (whether it is character-based or binary) and on the so represented data. Semantically character data is represented as binary data, however, a character-based ITS should not convert character data into arbitrary binary data and then represent binary data in a character encoding. Ultimately even character-based implementation technology will communicate binary data.
It follows from the definition of the sequence generic type (LIST) that an "empty" sequence of binary data is not a valid value but counts as a NULL-value. In other words, non-NULL binary data contains at least one bit.
The Boolean type stands for the values of two-valued logic. A Boolean value can be either "true" or "false". With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic.
|
|
|
The following means that CC can only be used for local codes!
invariant(CC x) where x.nonNull .and(x.codeSystem.value(2.16.840.1.113883.3).nonEmpty) { x.modifier.nonEmpty; /* actiually: x.modifier.cardinality.equals(1); */ }
The plain code symbol.
Specifies the code system that defines the code.
A common name of the coding system.
If applicable, a version descriptor defined specifically for the given code system.
A name or title for the code under which the sending system shows the code value to its users.
For one modifier that tells the HL7-defined category of the coded concept. Only if the codeSystem is not registered with HL7.
The text or phrase used as the basis for the coding.
A set of other concept descriptors that translate this concept descriptor into other code systems.
Fixed to “has-generalization” (GEN).
An HL7 defined code for the category of the concept.
|
|
|
A concept descriptor represents any kind of concept. The CD refers to a concept usually by citing a code defined in a coding system. A given concept may be expressed in multiple terms where each term is a translation or re-encoding of the meaning in another code system. In addition (and different from translations) compositional code system are supported. In exceptional cases, the concept descriptor may not contain a code but only free text describing that concept. The CD is typically used through one of its restrictions described in Section 5.1.3.
This is the plain code symbol, e.g., "784.0" is the code symbol of the ICD-9 code "784.0" for headache. The code must be defined in the coding system.
A non-exceptional CD value has a non-NULL code citing a valid code from an identified coding system. Conversely, a CD value without the code or with a code not from the cited coding system is an exceptional value (NULL of flavor other).
This property specifies the code system that defines the code. Code systems shall be referred to by ISO Object Identifiers (OID). The OID allows unambiguous reference to standard HL7 codes, other standard code systems, and local codes. HL7 shall assign an OID to each of its code tables as well as to external standard coding systems that are being used with HL7. Local sites can use their OID to construct a globally unique local coding system identifier.
A non-exceptional CD value (i.e. a CD value that has a non-null code property) has a non-NULL code system specifying the system of concepts that defines the code. In other words whenever there is a code there is also a code system.
<ITS-Note>Although every non-NULL CD value has a defined code system, in some circumstances, the external representation of the CD value needs not explicitly mention the code system. For example, when the context mandates one and only one code system to be used specifying the code system explicitly would be redundant. However, in that case the code system property assumes that context-specific default value and is not NULL.</ITS-Note>
An exceptional CD of NULL-flavor “other” indicates that a concept could not be coded in the coding system specified. Thus, for these coding exceptions, the code system that did not contain the appropriate concept must be provided in the code system property.
Some code domains are qualified such that they include the portion of any pertinent local coding system that does not simply paraphrase the standard coding system (CWE.) If a CWE qualified field actually contains such a local code, the coding system must specify the local coding system from which the local code was taken. However, for CWE domains the local code is a valid member of the domain, so that local codes in CWE domains constitute neither an error nor an exceptional (NULL/other) value in the sense of this specification.
This is a common name of the coding system referred to by the codeSystem OID. The code system name is optional and has no function in communication. The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret the code system OID. It is suggested -- though not absolutely required -- that ITS provide for code system name fields in order to annotate the OID for human comprehension.
HL7 systems must not functionally rely on the code system name. The code system name can never modify the meaning of the code system OID value and can not exist without the OID value.
This is a version descriptor defined specifically for the given code system. The code system version is cited as a plain character string. HL7 shall specify how these version strings are formed. If HL7 has not specified how version strings are formed for a particular coding system, version designations have no defined meaning for such coding system.
For the purpose of this specification, the term "version" means the following: Different versions of one code system must be compatible in general. Whenever a code system changes in an incompatible way, it will constitute a new code system, not simply a different version, regardless of how the vocabulary publisher calls it.
For example, the publisher of ICD-9 and ICD-10 calls these code systems, 'revision 9' and 'revision 10' respectively. However, ICD-10 is a complete redesign of the ICD code, not a backward compatible version. Therefore, for the purpose of this data type specification, ICD-9 and ICD-10 are different code systems, not just different versions. By contrast, when LOINC updates from revision "1.0j" to "1.0k", HL7 would consider this to be just another version of LOINC, since LOINC revisions are backwards compatible.
The display name is a name or title for the code, under which the sending system typically or actually shows the code value to its users. It is included both as a courtesy to an unaided human interpreter of a code value and as a documentation of the name used to display the concept to the user. The display name has no functional meaning; it can never exist without a code; and it can never modify the meaning of the code.
Note: display names may not alter the meaning of the code value. Therefore, display names should not be presented to the user on a receiving application system without ascertaining that the display name adequately represents the concept referred to by the code value. Communication must not simply rely on the display name. The display name’s main purpose is to support debugging of HL7 protocol data units (e.g., messages.)
A concept descriptor may have modifiers if the code system defines such modifiers. Modifiers can only be used with code systems that define rules of postcoordination, where multiple codes together make up one concept. A concept descriptor with modifiers is called a code phrase.
For example, SNOMED allows constructing concepts as a combination of multiple codes and HCFA procedure codes come with modifiers. Say, SNOMED RT defines a concept 'leg', a role relation 'has-laterality', and another concept 'left', the concept role relation allows to add the modifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example "has-laterality: left" is an element in the modifier.
The order of modifiers is preserved, particularly for the case where the coding system allows postcoordination but defines no role names (e.g., some ICD-9 codes, SNOMED, HCFA procedure codes.)
<ITS-Note>Since all the modifier names and subordinate codes of a code phrase should come from the same coding system, a code phrase’s coding system should be made the default for all subordinated modifier names and values.</ITS-Note>
This is the text or phrase used as the basis for the coding. The original text exists in a scenario where an originator of the information does not assign a code, but where the code is assigned later by a coder (post-coding.) In the production of a concept descriptor, original text may thus exist without a code.
Although the concept descriptor’s value property is NULL, original text may still exist for the CD value. Any CD value with the code property of NULL signifies a coding exception. In this case, the text property is a name or description of the concept that was not coded. Such exceptional CD may contain translations. Such translations directly encode the concept described in the original text property.
Neither display name nor original text is part of the information a receiving system must recognize. An information producer is responsible for the proper coding of all information in the value attribute, for any information consumer may safely ignore the display name and original text attributes.
A concept descriptor can be converted into an ED value representing only the original text of the CD value.
The translation property of a concept descriptor y holds a set X of other concept descriptors x in X that translate the concept descriptor y into different code systems. Each element x in X was translated from the concept descriptor y. Each translation x may also contain translations. Thus, when a code is translated multiple times the information about which code served as the input to which translation will be preserved.
Note: the translations are quasi-synonyms of one real-world concept. Every translation in the set is supposed to express the same meaning 'in other words.' However, exact synonymy does rarely exist between two structurally different coding systems. For this reason, not all of the translations will be equally exact.
|
|
|
The data type "Coded with Equivalents" (CE) is a restriction of the concept descriptor (CD). The CE suppresses the CD modifier property, which is not applicable. The CE also restricts the translation property such that the translation is a set of CV values. CV values may not themselves contain translations.
The CE type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The CE type provides for a primary code value, plus a set of alternative or equivalent representations.
Inherited from CD.
Inherited from CD.
Inherited from CD.
Inherited from CD.
Inherited from CD.
This property is inhertited from CD.
This property is inhertited from CD. Its data type is further restricted to a set of code values (CV) where translations are not allowed. Thus one CE can only have one flat set of translations.
The concept role is used to send code modifiers with optionally named roles. Both modifier roles and values must be defined by the coding system.
For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the modifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg".
The use of modifiers is strictly governed by the code system used. The CD does not permit using code modifiers with code systems that do not provide for modifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.) The rules of the modifier use must be governed by the code system (e.g., recent SNOMED RT revision, GALEN.)
This property indicates if the meaning of the role is inverted. This can be used in cases where the underlying code system defines inversion but does not provide reciprocal pairs of role names.
For example, a code system may define the role relation "causes" besides the concepts "Streptococcus pneumoniae" and "Pneumonia". If that code system allows its roles to be inverted, one can construct the post-coordinated concept "Pneumococcus pneumonia" through "Pneumonia -- causes, inverted -- Streptococcus pneumoniae."
Roles may only be inverted if the underlying coding systems allows such inversion. Notably, if a coding system defines roles in inverse pairs or intentionally does not define certain inversions, the appropriate role code (e.g. "caused-by") must be used rather than inversion.
<ITS-Note>The property "inverted" should be conveyed in an indicator attribute, whose default value is false. That way the inverted indicator does not have to be sent when the role is not inverted.</ITS-Note>
This is the role name. The role name specifies the manner in which the value contributes to the meaning of a code phrase.
For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the modifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example "has-laterality" is the CR.name.
If a coding system allows postcoordination but no role names the name attribute can be NULL. The name attribute must be of type CV for which CD must not be substituted.
The code related to the primary code of a code phrase through the role relation.
For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the modifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example "left" is the CR.value.
This component is of type concept descriptor and thus can be in turn have modifiers. This allows modifiers to nest. Modifiers can only be used as far as the underlying code system defines them. It is not allowed to use any kind of modifiers for code systems that do not explicitly allow and regulate such use of modifiers.
|
|
|
The Coded Simple Value (CS) is a restriction of the concept descriptor (CD). The CS suppresses all properties of the CD, except for code and display name. The code system and code system version is fixed by the context in whichy the CS value occurs. Original text is not applicable to CS values.
CS can only be used for a coded attribute which has a single HL7-defined value set, and where code additions to that value set require formal HL7 action (such as harmonization.) For these examples, the designation of the domain qualifier will always be CNE and the context determines unambiguously which HL7 value set applies. Such coded attributes that are designated "structural" codes must be assigned the CS restriction.
This property is inherited from CD.
This property is inherited from CD.
|
|
|
The Coded Value (CV) is a restriction of the concept descriptor (CD). The CV suppresses the CD properties translation and modifier, which are both not applicable. The CV also constrains the original text to a character string (ST) instead of the more general encapsulated data (ED) type.
This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE and the CWE domain qualifier.
This property is inherited from CD.
This property is inherited from CD.
This property is inherited from CD.
This property is inherited from CD.
This property is inherited from CD.
This property is inherited from CD. Its data type is further constrained to ST.
|
|
|
The encoded data type can convey any data. However, in order for that data to convey meaning, encoded data must be decoded and further interpreted. Encoded data may be a plain character string, formatted text, or any of several kinds of multimedia data. The kind of encoding is conveyed in three properties:
1. type - specifies the protocol, or application used to decode and interpret the data (also known as the "media type" as referring to multi-media data.)
2. charset - identifies the character set and character encoding for character-based "media."
3. compression - data may be given in a compressed form in which case compression identifies the compression algorithm used.
Encoded data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encoded data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote.
For character-based encoding types, this property specifies the character set and character encoding used. The charset is defined according to Internet RFC 2278, IANA Charset Registration Procedures, [http://www.isi.edu/in-notes/rfc2278.txt].
The charset domain is maintained by the Internet Assigned Numbers Authority (IANA) [http://www.isi.edu/in-notes/iana/assignments/character-sets]. The IANA source specifies names and multiple aliases for most character sets. For the HL7’s purposes, use of multiple alias names is not al-lowed. The standard name for HL7 is the one marked by IANA as "preferred for MIME." If IANA has not marked one of the aliases as "preferred for MIME" the main name shall be the one used for HL7.
OpenIssue: There are at least 10 different MIME designators for Japanese charsets some being singular character sets (e.g., JIS X208, X212, etc.) or various versions thereof, some being suites of character sets and a switching encoding (e.g., ISO2022, EUC-JP, Shift-JIS, etc.) Allowing that many charsets and versions for Japanese HL7 would be a disservice to the goal for HL7 interoperability. It is unclear what charsets besides JIS X221 (ISO 10646) is needed at all. HL7 Japan is asked to submit two or three (maximum) IETF/MIME registered charsets along with their preferred IETF registered charset code and a description for inclusion into this standard.
The compression code indicates whether the raw byte data is compressed, and what compression algorithm was used.
Compression may not be allowed for encoded data depending on the attribute or component that is declared encoded data. Character strings (see Section 4.3) may never be compressed.
The integrity check is a short binary value representing a cryptographically strong checksum that is calculated over the binary data. The purpose of this property, when communicated with a reference is for anyone to validate later whether the reference still resolved to the same data that the reference resolved to when the encoded data value with reference was created.
The integrity check is calculated according to the integrity check algorithm. By default, the Secure Hash Algorithm-1 (SHA-1) shall be used. The integrity check is binary encoded according to the rules of the integrity check algorithm.
The integrity check is calculated over the raw binary data that is contained in the data component, or that is accessible through the reference. No transformations are made before the integrity check is calculated. If the data is compressed, the Integrity Check is calculated over the compressed data.
This property defines the algorithm used to compute the value in integrity check.
The cryptographically strong checksum algorithm Secure Hash Algorithm-1 (SHA-1) [FIPS PUB 180-1: Secure Hash Standard. As of April 17, 1995.] is currently the industry standard. It has superseded the MD5 algorithm only a couple of years ago, when certain flaws in the security of MD5 were discovered. Currently the SHA-1 hash algorithm is the default and mandatory only choice for the integrity check algorithm. However, there is no assurance that SHA-1 will not be superseded at anytime when its flaws will be discovered.
For character based information the language property specifies the language of the text. The principles of the code domain of this attribute is specified by RFC 1766, Tags for the Identification of Languages [http://www.isi.edu/in-notes/rfc1766.txt]. It is a set of pre-coordinated pairs of one 2-letter ISO 639 language code and one 2-letter ISO 3166 country code.
Language tags do not modify the meaning of the characters found in the text; they are only an advice on if and how to present or communicate the text.
<Comment>For this reason, any system or site that does not deal with multilingual text or names in the real world can safely ignore the language property.</Comment>
<ITS-Note> representation of language tags to text is highly dependent on the ITS. An ITS should use the native way of language tagging provided by its target implementation technology. Some may have language information in a separate component, e.g., XML has the xml:lang tag for stings. Others may rely on language tags as part of the binary character string representation, e.g., ISO 10646 (Unicode) and its “plane-14” language tags.
The language tag should not be mandatory if it is not mandatory in the implementation technology. Semantically, language tagging of strings follows a default-logic. If nothing else is specified the local language is assumed. If a language is set for an entire message or document, that language is the default. If any information element or value that is superior in the syntax hierarchy specifies a language, that language is the default for all subordinate text values.
If language tags are present in the beginning of the encoded binary text (e.g., through Unicode’s plane-14 tags) this is the source of the language property of the Encoded Data value. </ITS-Note>
Rationale: The need for a language code for text data values is documented in RFC 2277, IETF Policy on Character Sets and Languages [http://www.isi.edu/in-notes/rfc2277.txt]. Further background information can be found in Using International Characters in Internet Mail [http://www.imc.org/mail-i18n.html], a memo by the Internet Mail Consortium.
The reference is a telecommunication address (TEL), such as a URL for HTTP or FTP, that will resolve to precisely the same binary data that could as well have been provided as inline data.
The semantic value of an encoded data value is the same, regardless whether the data is present inline data or just by-reference. However, an encoded data value without inline data behaves differently, since any attempt to examine the data requires the data to be downloaded from the reference.
An encoded data value may have both inline data and a reference. The reference must point to the same data as provided inline.
By-reference encoded data may not be allowed depending on the attribute or component that is declared encoded data. Character strings (see Section 4.3) must always be inline.
A thumbnail is an abbreviated rendition of the full data. A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data. A thumbnail is typically used with by-reference encoded data. It allows a user to select data more efficiently before actually downloading through the reference.
Thumbnails may not be allowed depending on the attribute or component that is declared encoded data. Character strings (see Section 4.3) never have thumbnails, and a thumbnail may not itself contain a thumbnail.
<ITS Note>The ITS should consider the case where the thumbnail and the original both have the same properties of type, charset and compression. In this case, these properties need not be represented explicitly for the thumbnail but might be "inherited" from the main encoded data value to its thumbnail.</ITS-Note>
Rationale: Originally, the term thumbnail refers to an image in a lower resolution (or smaller size) than another image. However, the thumbnail concept can be metaphorically used for media types other than images. For example, a movie may be represented by a shorter clip; an audio-clip may be represented by another audio-clip that is shorter, has a lower sampling rate, or a lossy compression.
The encoded data’s type property identifies the encoding of the data and identifies an method to interpret or render the data. The domain of the encoded data’s type property are the MIME media types, defined by the Internet Assigned Numbers Authority (IANA).
The encoded data’s type is a mandatory property, i.e., every non-NULL instance of encoded data must have a defined type property.
The IANA defined domain of media types is established by the Internet standard RFC 2046 [ftp://ftp.isi.edu/in-notes/rfc2046.txt]. RFC 2046 defines the media type to consist of two parts:
1. top level media type, and
2. media subtype.
However, this specification treats the entire media type as one atomic code symbol in the form defined by IANA, i.e., top level type followed by a slash "/" followed by media subtype. Currently defined media types are registered in a database [http://www.isi.edu/in-notes/iana/assignments/media-types] maintained by IANA. Currently more than 160 different MIME media types are defined, with the list growing rapidly. In general, all those types defined by the IANA may be used.
To prevent the interoperability-problems associated with this diversity, this specification prefers certain media types to others. This is to define a greatest common denominator on which interoperability is not only possible, but that is powerful enough to support even advanced multimedia communication needs. (see the full text of the HL7 v3 data type semantics specification.)
The event-related periodic interval of time allows specifying a periodic interval of time based on activities of daily living, important events that are time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time.
The event is a common (periodical) activity of daily living based on which the event related periodic interval is specified. Such events qualify for being adopted in the domain of this attribute for which all of the following is true:
- the event commonly occurs on a regular basis, - the event is being used for timing activities, and - the event is not entirely determined by time.
Examples are: the hour of sleep (HS), before meal (AC), after meal (PC), etc.
The offset is an interval that marks the offsets for the beginning, width and end of the event-related periodic interval measured from the time each such event actually occurred.
For example: if the specification is "one hour before breakfast for 10 minutes" the offset’s low boundary is -1 h and the offset’s width is 10 min (consequently the offset’s high boundary is -50 min.)
|
|
|
An entity name data value specifies a name of a person, organization, place or thing. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts (ENXP), such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". The entity name data type is essentially a sequence of entity name part values.
A code indicating the reason for which the name is used. Includes the following: normal (the name normally used), license (encompassing birth certificates, school records, degrees and titles, licenses, etc.), artist (encompassing stage names, pseudonyms/writer names), indigenous/tribal, religious.
This additional component will allow an interval of time to be associated with the entity name being described by the data type. This should be an optional component.
An entity name part is a character string token that may have a type code signifying the role of the part in the whole entity name. Typical name parts that exist in about every name are given names, and family names, titles, etc.
Each name part may have a qualifier. The qualifier is a set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. For example, a given name may be flagged as a nickname, a family name may be a pseudonym or a name of public records.
Each name part may have a type code, identifying given names, family names, prefix, suffix, etc. The type code may not be available for unknown person names.
A code indicating the reason for which the name is used. Includes the following: normal (the name normally used), license (encompassing birth certificates, school records, degrees and titles, licenses, etc.), artist (encompassing stage names, pseudonyms/writer names), indigenous/tribal, religious.
The general timing specification (GTS) semantically is a general set of points in time. The purpose of the GTS is to specify the complex timing of events and actions (mainly in orders and scheduling systems.) The GTS also supports the cyclical validity patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing in the south during winter and north during summer) and office hours.
The GTS data type has the following aspects:
- GTS as a general set of points in time (SET?TS?). From this aspect GTS answers whether any given point in time falls in the timing covered by the GTS value.
- GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS.
- GTS as a generator of a sequence of intervals of point in time (LIST?IVL?TS??). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact.
- GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form.
The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals.
This generic data type is used to collect an entire history of any other data value. A history is a non-empty set of data values that conform to the history item (HXIT) type, i.e., data values that have a valid-time property. The history information is not limited to the past; expected future values can also appear.
The earliest history item is the item in the set whose valid time’s low boundary (validity start time) is less or equal (i.e. before) that of any other history item in the set. Likewise, the latest history item is the item in the set whose valid time’s high boundary (validity end time) is greater or equal (i.e. after) that of any other history item in the set.
The semantics does not principally forbid the time intervals to overlap. However, if two history items have the same low (high) boundary in the valid time interval, it is undefined which one is considered the earliest (latest). Except earliest is the derived history that has the earliest item excluded. Except latest is the derived history that has the latest item excluded.
A type conversion exists between an entire history HIST<T> and a single history item HXIT<T>. This conversion takes the latest data from the history. The purpose of this conversion is to allow an information producer to produce a history of any value instead of sending just one value. An information-consumer, who does not expect a history but a simple value, will convert the history to the latest value.
Note from the definition of history item (HXIT) below, that HXIT<T> semantically extends T. This means, that the information-consumer expecting a T but given an HXIT<T> will not recognize any difference (substitutability of specializations.)
ITS Note: the order of history items in the lists should be backwards in time.
|
|
This generic data type extension is tags a time range to its base data value. The time range is the time in which that data was, is, or is expected to be valid. If the base type T does not possess a valid time property, the HXIT<T> adds that property to the base type. If, however, the base type T does have a valid time property, that property can be mapped to the valid time property of the HXIT<T>.
Note that data types are specifications of abstract properties of values. This specification does not mandate how these values are represented in an ITS or implemented in an application. Specifically, it does not mandate how the represented components are named or positioned. In addition, the semantic generalization hierarchy may be different from a class hierarchy chosen for implementation (if the implementation technology has inheritance.) Keep the distinction between a type (interface) and an implementation (concrete data structure, class) in mind. The ITS must contain a mapping of ITS defined features of any data type to the semantic properties defined here.
The time interval during which the given information was, is, or is expected to be valid. The interval can be open or closed infinite or undefined on either side.
The Instance Identifier (II) data type is used to uniquely identify an instance, thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, etc. Instance identifiers are defined based on ISO object identifiers.
This is a human readable name or mnemonic for the assigning authority. This name is provided solely for the convenience of unaided humans interpreting an II value. The assigning authority name need not be unique or globally meaningful.
Note: no automated processing must depend on the assigning authority name to be present in any form.
The assigning authority name is not the name for the individually identified object, but for the namespace, that immediately contains that object identifier. Two cases exist. 1) If the extension property is non-NULL, the root OID identifies the assigning authority, hence the assigning authority name is a name or mnemonic for the entire root OID. 2) If the extension is NULL, the assigning authority name is the name or mnemonic of the namespace property of the OID value.
A character string value of the identifier. The extension must be unambiguous (unique) within the domain of the root OID. The extension property may be NULL in which case the root OID is the complete unique identifier.
It is recommended that systems use the OID scheme for external identifiers of their communicated objects. The extension property is mainly provided to accommodate legacy alphanumeric identifier schemes.
Open Issue: the 3-2-4 grouping in U.S. social security numbers is pure decoration and has no meaning. Some systems save space not storing the dashes and may not fill in the dashes when sending social security numbers. This means, that equivalence of two identifiers may be weaker than the equivalence of the extensions as character strings. For example, a system may has to consider the SSNs "123456789" and "123-45-6789" to be equivalent. It is therefore recommended to strip off all decorating meaningless characters when comparing extensions. However, what constitutes a meaningless character is entirely dependent upon the identifier scheme identified in the root property. Since social security numbers are numeric strings, they could also be assigned to the end of an OID. This specification will be more restrictive in the future to reduce the number of different cases.
The root of an instance identifier guarantees the uniqueness of the identifier. The root alone may be the entire unique identifier, an extension value is not needed.
In the presence of a non-null extension, the root is commonly interpreted as the "assigning authority", that is, it is supposed that the root OID somehow refers to an organization that assigns identifiers sent in the extension. However, the root does not have to be an organizational OID, it can also be and OID specifically registered for an identifier scheme.
Rationale: DICOM objects are identified by OID only. For the purpose of DICOM/HL7 integration, it would be awkward if HL7 required the extension to be mandatory and to consider the OID only as an assigning authority. Since OID values are simpler and do not contain the risks of containing meaningless decoration, we do encourage systems to use simple OID identifiers as external references to their objects.
The identifier is valid in this optional time-range. By default, the identifier is valid indefinitely. Any specific interval may be undefined on either side indicating unknown effective or expiry time.
Note: identifiers for information objects in computer systems should not have restricted valid times, but should be globally unique at all times. The identifier valid time is provided mainly for real-world identifiers, whose maintenance policy may include expiry (e.g., credit card numbers.)
Integer numbers are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two exceptional values are defined for the positive and negative infinity.
|
|
|
An interval is a set of consecutive values of any ordered data type. An interval is thus a continuous subset of its base data type. Any ordered type can be the basis of an interval. It does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the ordered data type.
For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meters exists, there is no interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets may not be consecutive. Intersections of intervals are always intervals.
The center is defined of finite intervals and is then the arithmetic mean of the interval (low pus high divided by 2). The purpose of distinguishing the center as a semantic property is for conversions of intervals to point values. This is most relevant when intervals are used to express uncertainty.
This is the upper boundary of the interval.
Indicates whether the interval is closed or open at the high boundary. For a boundary to be closed, a finite boundary must be provided, i.e. unspecified or infinite boundaries are always open.
This is the low boundary of the interval.
Indicates whether the interval is closed or open at the low boundary. For a boundary to be closed, a finite boundary must be provided, i.e. unspecified or infinite boundaries are always open.
The width is the difference between high and low boundary. The purpose of distinguishing a width property is to handle all cases of incomplete information symmetrically. In any interval representation only two of the three properties high, low, and width need to be stated and the third can be derived.
When both boundaries are known, width can be derived as high minus low. When one boundary and the width is known, the other boundary is also known. When no boundary is known, the width may still be known. For example, one knows that an activity takes about 30 minutes, but one may not yet know when that activity is started.
A sequence is an ordered collection of discrete values.
A sequence has a head and a tail. All non-NULL sequences must have at least a head or a tail that is non-NULL. A sequence without at least either a head or a tail is indistinguishable from the NULL value. A NULL sequence has length zero.
The length of a sequence is the count of elements in the sequence. NULL elements are counted as regular sequence elements with the exception of the last element. As stated above, a sequence without at least a non-NULL head or a tail is a NULL-sequence of zero length. Therefore, if the last element of a sequence is NULL it is not counted towards the length of the list.
Two lists are equal if and only if both their head and their tail are equal.
A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units.
Equality of two monetary amounts -- unlike physical quantities -- is determined as the joint equality of their value and currency properties independently. (This is according to the general definition of equality as defined in Section 3.2.3.) If the currencies are not equal, the amounts can not be compared. Conversion between the currencies is outside the scope of this specification. In practice, foreign exchange rates are highly variable not only over long and short amounts of time, but also depending on location and access to currency trade markets.
The currency unit as defined in ISO 4217.
This is the magnitude of the monetary amount in terms of the currency unit.
Note: monetary amounts are usually precise to 0.01 (one cent, penny, paisa, etc.) For large amounts, it is important not to store monetary amounts in floating point registers, since this may lose precision. However, this specification does not define the internal storage of real numbers as fixed or floating point numbers.
The precision attribute of the real number type is the precision of the decimal representation, not the precision of the value. The real number type has no notion of uncertainty or accuracy. For example, "1.99 USD" (precision 3) times 7 is "13.93 USD" (precision 4) and should not be rounded to "13.9" to keep the precision constant.
This is a generic data type to specify a value as a non-empty set of uncertain values forming a probability distribution (histogram.) All the elements in the set are considered alternatives and are rated each with its probability expressing the belief (or frequency) that each given value holds.
The purpose of the non-parametric probability distribution is chiefly to support statistical data reporting as it occurs in measurements taken from many subjects and consolidated in a histogram. This occurs in epidemiology, verterinary medicine, laboratory medicine, but also in cost controlling and business process engineering.
Semantically, the information of a stated value exists in contrast to the complement set of unstated possible values. Thus, semantically, a non-parametric probability distribution contains all possible values and assigns probabilities to each of them.
ITS Note: even though semantically the NPPD assigns probabilities to all possible values, not all values need to be represented explicitly. Those possible values that are not mentioned in a NPPD data structure will have the rest-probability distributed equally over all unmentioned values. For example, if the value set is {A; B; C; D} but the NPPD value states just {(B; 0.5); (C; 0.25)} then the rest-probability is 1 - 0.75 = 0.25 which is distributed evenly over the complement set: {(A; 0.125); (D; 0.125)}. Semantically, the NPPD is the union of the stated probability distribution and the unstated complement with rest-probability distributed evenly.
Just as with UVP, the type T is not formally constrained, even though there are reasonable and unreasonable use cases. Typically one would use the non-parametric probability distributions for unordered types, if only a "small" set of possible values is assigned explicit probabilities, or if the probability distribution can (or should) not be approximated with parametric methods. For other cases, one may prefer parametric probability distributions.
The ISO Object Identifier is defined by ISO/IEC 8824:1990(E) clause 28.
According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The demotion to LIST<INT> represents this path of object identifier component values from the root to the leaf.
The value and namespace properties take the opposite view. The leaf (the last object identifier component value in the list) is considered the value property and the all the preceding object identifier component values except for the leaf are considered the namespace property. The namespace property is an OID by itself. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the concepts of identifier value versus identifier assigning authority (namespace.)
<ITS-Note>For Implementation Technologies that do not have native support for ISO OIDs, the ITS representations for OIDs may be a character string literal rather than a recursive data structure. The character string literal is more concise and most of the time OIDs will only be compared for equality but not analyzed further.</ITS-Note>
A name for an organization, such as “Health Level Seven, Inc." An organization name consists only of untyped name parts, prefixes, suffixes, and delimiters.
|
|
|
The periodic interval of time specifies an interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the interval prototype that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval’s width equals two minutes and the period at which the interval recurs equals eight hours.
The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified.
For example: "every eight hours for two minutes" specifies only the period and the phase’s width but no boundary of the phase. Conversely, "every eight hours starting at 4 o’clock" specifies only the period and the phase’s low boundary but not the phase’s high boundary. "Every eight hours for two minutes starting at 4 o’clock" is fully specified since the period, and both the phase’s low boundary and width are specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic data type PIVL?T? where the type parameter T is restricted to the point in time (TS) data type and it’s extensions. The parametric probability distribution of point in time (PPD?TS?) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time (PIVL?PPD?TS??) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is.
A periodic interval may be specified aligned to the calendar underlying the phase. A non-aligned periodic interval recurs independent from the calendar. An aligned periodic interval is synchronized with the calendar. For example, "every 5th of the month" is a calendar aligned periodic interval. The period spans 28 to 31 days depending on the calendar month. Conversely, "every 30 days" is an independent period that will fall on a different date each month.
The calendar alignment specifies a calendar cycle to which the periodic interval is aligned. The even flow of time will then be partitioned by the calendar cycle. The partitioning is called the calendar "grid" generated by the aligned-to calendar cycle. Each occurrence interval will then have equal distance from the earliest point in each partition. In other words, the distance from the next lower grid-line to the beginning of the interval is constant.
For example, with "every 5th of the month" the alignment calendar cycle would be month of the year (MY.) The even flow of time is partitioned in months of the year. The distance between the beginning of each month and the beginning of its occurrence interval is 4 days (4 days because MY starts counting with 1.) Thus, as months differ in their number of days, the distances between the recurring intervals will vary slightly, so that the interval occurs always on the 5th.
The period specifies how frequently the periodic interval recurs. The period is a physical quantity in the dimension of time (TS.diff.) For an uncertain periodic interval (PIVL<PPD<TS>>) the period is a probability distribution over elapsed time (PPD<PQ>). A non-NULL period exists for every non-NULL periodic interval.
The phase specifies the interval prototype that is repeated every period. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no begin or end but is infinite in both future and past. A phase must be specified for every non-NULL periodic interval. The width of the phase must be less or equal the period.
Since most of the functionality of entity name is in support of person names, the person name (PN) is only a very minor restriction on the entity name. This restriction applies to the part qualifier.
|
|
|
A parametric probability distribution is a generic data type extension specifying an uncertain value of a quantity data type using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain interoperability if receiving applications can not deal with a certain probability distribution.
Since a PPD<T> extends the base type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that can not deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution.
Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a PPD<PQ> for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability would be translated to f’(x’) that maps a length x’ to a probability as f’(x’) = f((x’? ? ) / ?).
Where applicable, the PPD specification conforms to the ISO Guide to the Expression of Uncertainty in Measurement (GUM) as reflected by NIST Technical Note 1297, Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results. The PPD specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the PPD.
The standard deviation of the probability distribution. The standard deviation is used to normalize the data for computing the distribution function. Applications that can not deal with probability distributions can still get an idea about the confidence level by looking at the standard deviation.
The standard deviation of a probability distribution over a type T is of a related type that can express differences between values of type T. If T is REAL or INT, T.diff is also REAL or INT respectively. However if T is a point in time (TS), T.diff is a physical quantity (PQ) in the dimension of time.
The standard deviation is what ISO GUM calls "standard uncertainty."
This code specifies the type of probability distribution. Possible values are as shown in the attached table. The NULL value (unknown) for the type code indicates that the probability distribution type is unknown. In that case, the standard deviation has the meaning of an informal guess.
Many distribution types are usually defined in terms of special parameters (e.g., the parameters alpha and beta for the gamma-distribution, number of degrees of freedom for the t-distribution, etc.) For all distribution types, however, the mean and standard deviation are defined. The PPD data type is specified with the parameters mean and standard distribution only.
ITS Note: an ITS does not need to represent any of the specialized parameters for the distribution types. As it turns out, all of these specialized parameters can be calculated from the mean and standard deviation.
The three distribution-types unknown (NULL), uniform and normal must be supported by every system that claims to support PPD. All other distribution types are optional. When a system interpreting a PPD representation encounters an unknown distribution type, it maps this type to the unknown (NULL) distribution-type.
A physical quantity is a dimensioned quantity expressing the result of a measurement act and are represented as pairs of value and unit. However, semantically, a physical quantity is more than a pair of value and unit. To find out whether two physical quantities are equal, it is not enough to compare equality of their two values and units independently. For example, semantically 100 cm equals 1 m although neither values nor units are equal. To define equality we introduce the notion of a canonical form.
Every physical quantity has a canonical form. The canonical form is a physical quantity expressed as a pair of value and unit such that each dimension in a given unit system has one and only one canonical value-unit pair. Defining the canonical form is not subject of this specification, only asserting that such a canonical form exists for every physical quantity. A physical quantity is equal to its canonical form.
For example, for a unit system based on the Système International (SI) one can define the canonical form as (a) the product of only the base units; (b) without prefixes; where (c) only multiplication and exponents are used (no division operation); and (d) where the seven base units appear in a defined ordering (e.g., m, s, g, ...) Thus, 1 mm Hg would be expressed as 133322 m-1.s-2.g. As can be seen, the rules how to build the canonical form of units may be quite complex. However, for the semantic specification it doesn’t matter how the canonical form is built, nor what specific canonical form is chosen, only that some canonical form could be defined.
Two physical quantities are equal if each their values and their units of their canonical forms are equal. Two physical quantities compare each other (and have an ordering and difference) if the units of their canonical forms are equal.
This is the unit of measure.
Note that equality of physical quantity does not require the values and units to be equal independently. Value and unit is only how we represent physical quantities. For example, 1 m equals 100 cm. Although the units are different and the values are different, the physical quantities are equal! Therefore one should never expect a particular unit for a physical quantity but instead provide automated conversion between different comparable units.
This is the magnitude of the quantity measured in terms of the unit.
The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type’s totally ordered value subsets.
The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution.
Real numbers are the superset of integer numbers, rational numbers, and irrational numbers. Real numbers are needed beyond integers whenever quantities of the real world are measured, estimated, or computed from other real numbers.
The precision property indicates the quality of the approximation of a decimal real number representation. Precision is the number of significant decimal digits in that decimal representation. The precision attribute is the precision of a decimal digit representation, not the precision or accuracy of the real number value. Precision does not play a role in deciding whether two real number values are equal.
The purpose of the precision property for the real number data type is to faithfully capture the whole information presented to humans in a number. The amount of decimal digits shown conveys information about the uncertainty (i.e., precision and accuracy) of a measured value.
Note: the precision of the representation is independent from uncertainty (precision accuracy) of a measurement result. If the uncertainty of a measurement result is important, one should send uncertain values as defined elsewhere. The rules for what digits are significant are as follows:
1. All non-zero digits are significant.
2. All zeroes to the right of a significant digit are significant.
3. When all digits in the number are zero the zero-digit immediately left to the decimal point is significant (and because of rule 2, all following zeroes are thus significant too.)
Note, these rules of significance differ slightly from the more casual rules taught in school. Notably trailing zeroes before the decimal point are consistently regarded significant here. Elsewhere, e.g., 2000 is ambiguous as to whether the zeroes are significant. This deviation from the common custom is warranted for the purpose of unambiguous communication.
Examples:
2000 has 4 significant digits.
2e3 has 1 significant digit, used if one would naturally say "2000" but precision is only 1.
0.001 has 1 significant digits.
1e-3 has 1 significant digit, use this if one would naturally say "0.001" but precision is only 1.
0 has 1 significant digit.
0.0 has 2 significant digits.
000.0 has 2 significant digits.
0.00 has 3 significant digits.
4.10 has 3 significant digits.
4.09 has 3 significant digits.
4.1 has 2 significant digits.
The precision of the representation should match the uncertainty of the value. However, precision of the representation and uncertainty of the value are separate independent concepts.
For example "0.123" has 3 significant digits in the representation, but the uncertainty of the value may be in any digit shown or not shown, i.e., the uncertainty may be 0.123±0.0005, 0.123±0.005 or 0.123±0.00005, etc. Note that external representations should adjust their representational precision with the uncertainty of the value. However, since the precision in the digit string is granular to ±0.5 the least significant digit, while uncertainty may be anywhere between this raster, 0.123±0.005 would also be an adequate representation for the value between 0.118 and 0.128.
ITS Note: on a character based Implementation Technology the ITS need not represent the precision as an explicit attribute if numbers are represented as decimal digit strings. In that case, the ITS must abide by the rules of an unambiguous determination of significant digits. A number representation must not produce more or less significant digits than were originally in that number. Conformance can be tested through round-trip encoding - decoding - encoding.
|
|
|
A ratio quantity is a quantity constructed through division of a numerator quantity with a denominator quantity. Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number.
The purpose of the ratio data type is to support certain quantities produced by laboratories, such as titers (e.g., "1:128"). Ratios are not simply "structured numerics", blood pressure measurements (e.g. "120/60") are not ratios.
This is the denominator quantity. The default is the integer number 1 (one.) The denominator must not be zero.
This is the numerator quantity. The default is the integer number 1 (one.)
A set is a value that contains other values of a certain data type as its elements. The elements are contained in no particular ordering. All elements in the set are distinct, the same element value can not be contained more than once in the set.
The primitive semantic property of a set is the contains-relation of elements in the set. On this semantic primitive, all other properties are defined. A set may only contain distinct non-NULL elements. Exceptional values (NULL-values) can not be elements of a set.
The empty set is a set without any elements. The empty set is a proper set value, not an exceptional (NULL) value. The cardinality of a set is the number of distinct elements in the set.
The cardinality definition is not sufficient since it doesn’t converge for uncountably infinite sets (REAL, PQ, etc.) and it doesn’t terminate for infinite sets. In addition, the definition of integer number type in this specification is incomplete for these cases, as it doesn’t account for infinities. Finally the cardinality value is an example where it would be necessary to distinguish the cardinality aleph0 of countably infinite sets (e.g., INT) from aleph1, the cardinality of uncoutable sets (e.g., REAL, PQ).
The character string is a restricted encoded data type (ED), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encoded data as character data (as opposed to bits), depending on the charset property of the encoded data type.
<ITS-Note> because many of the properties of the encoded data are bound to a default value, an ITS need not represent these properties at all. In fact, if the character encoding is also fixed, the ITS only represents the encoded character data.</ITS-Note>
<Comment> ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organisation, control, or representation of data." ISO/IEC TR 15285 " An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) " or in Japan, JIS X0221 " is a globally applicable character set that uniquely identifies all characters of any language in the world.
In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an ST value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown ED values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. </Comment>
The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer.
T is one particular data typoe. Used to type generic parameters and to provide an extension base. T is a restriction of ANY to one particular type.
A telecommunication address is a locator for some resource (information or services) mediated by telecommunication equipment. The semantics of a telecommunication address is that a communication entity responds to that address (the responder.) and therefore can be contacted by a communication initiator. The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encoded data, ED.)
A given telecommunication address value may have limited validity through time and may be tagged by a use code to indicate under what circumstances a specific telecommunication address may be preferred among a set of alternatives.
The telecommunication address is an extension of the Universal Resource Locator (URL) that specifies as an Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type is for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc.
The purpose of the use code is to advise a system or user which telecommunication address in a set of like addresses to select for a given telecommunication need.
Examples include: home (H), primart home (HP), vacation home (HV), work phone (WP), mobile contact (MC), etc.
Note: the telecommunication use code is not a complete classification for equipment types or locations. Its main purpose is to suggest or discourage the use of a particular telecommunication address. There are no easily defined rules that govern the selection of a telecommunication address.
This General Time Specification (GTS) identifies the periods of time during which the telecommunication address can be used. For a telephone number, this can indicate the time of day in which the party can be reached on that telephone. For a web address, it may specify a time range in which the web content is promised to be available under the given address.
The trivial name (TN) is an entity name that consists of only one name part without any name part type or qualifier. The TN, and its single name part are therefore equivalent to a simple character string.
A point in time is a scalar defining a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, natural time is independent from calendars. The semantic properties of point in time are best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As a kind of quantity, points in time are a difference-scale quantity, where no absolute zero-point exists, where only differences are defined but no ratios. For example, no point in time is -- absolutely speaking -- "twice as late" as another point in time.)
Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal.
A code specifying the calendar used in the literal representation of this point in time.
At this time, no other calendars than the Gregorian calendar (GREG) are defined. However, the notion of a calendar as an arbitrary convention to specify absolute time is important to properly define the semantics of time and time-related data types. Furthermore, other calendars might be supported when needed to facilitate HL7’s use in other cultures.
The purpose of this attribute is mainly to faithfully convey what has been entered or seen by a user in a system originating such a point-in-time value. The calendar property also advises any system rendering a point-in-time value into a literal form of which calendar to use. However, this is only advice; any system that renders point-in-time values to users may choose to use the calendar and literal form demanded by its users rather than the calendar mentioned in the calendar property. Hence, the calendar property is not constant in communication between systems, the calendar is not part of the equality test.
The time elapsed since any constant epoch, measured as a physical quantity in the dimension of time (i.e., comparable to one second.) It is not necessary for this specification to define a canonical epoch; the semantics is the same for any epoch, as long as it is constant. Two point-in-time values are equal if and only if their offsets (relative to the same epoch) are equal.
The purpose of the precision property for the point in time data type is to faithfully capture the whole information presented to humans in a calendar expression. The number of digits shown conveys information about the uncertainty (i.e., precision and accuracy) of a measured point in time. Although, the precision of a calendar expression is not a sufficient measure for the uncertainty of the value, the precision of the calendar expression should match the accuracy of the measurement.
Note: the precision of the representation is independent from uncertainty (precision accuracy) of a measurement result. If the uncertainty of a measurement result is important, one should send uncertain values as defined in Section 7.8.
The precision property is dependent on the calendar. A given precision value relative to one calendar does not mean the same in another calendar with different periods.
For example "20000403" has 8 significant digits in the representation, but the uncertainty of the value may be in any digit shown or not shown, i.e., the uncertainty may be to the day, to the week, or to the hour. Note that external representations should adjust their representational precision with the uncertainty of the value. However, since the precision in the digit string depends on the calendar and is granular to the calendar periods, uncertainty may not fall into that grid (e.g., 2000040317 is an adequate representation for the value between 2000040305 and 2000040405.)
<ITS Note>On a character based Implementation Technology the ITS need not represent the precision as an explicit attribute if point in time values are represented as literal calendar expressions. A point in time representation must not produce more or less significant digits than were originally in that value. Conformance can be tested through round-trip encoding -- decoding -- encoding.</ITS-Note>
The time zone is specified as the difference between the local time in that time zone and Universal Coordinated Time (UTC, formerly called Greenwich Mean Time, GMT). The time zone is a physical quantity in the dimension of time (i.e., comparable to one second.) A zero time zone value specifies UTC. The time zone value does not permit conclusions about the geographical longitude or a conventional time zone name.
For example, 200005121800-0500 may be eastern standard time (EST) in Indianapolis, IN, or central daylight savings time (CDT) in Decatur, IL. Furthermore in other countries having other latitude the time zones may be named differently.
When the time zone is NULL (unknown), "local time" is assumed. However, "local time" is always local to some place, and without knowledge of that place, the time zone is unknown. Hence, a local time can not be converted into UTC. The time zone should be specified for all point in time values in order to avoid a significant loss of precision when points in time are compared. The difference of two local times where the locality is unknown has an error of +-12 hours.
In administrative data context, some time values do not carry a time zone. For a date of birth in administrative data, for example, it would be incorrect to specify a time zone, since this may effectively change the date of birth when converted into other time zones. For such administrative data the time zone is NULL (not applicable.)
This data type is defined as an Internet standard RFC 1738 [ftp://ftp.isi.edu/in-notes/rfc1738.txt].
The address is a character string whose format is entirely defined by the URL scheme.
The URL scheme identifies the protocol used to access the resource. URL schemes are registered by the Internet Assigned Numbers Authority (IANA) [http://www.iana.org], however IANA only registers URL schemes that are defined in Internet RFC documents. In fact there are a number of URL schemes defined outside RFC documents, part of which is registered at the World Wide Web Consortium (W3C).
Similar to the MIME media types, HL7 makes suggestions about URL schemes classifying them as mandatory, recommended, other, and deprecated. Any scheme not mentioned has status other.
Rationale: This specification explicitly limits itself to URLs. Universal Resource Names (URN) are not covered by this specification. URNs are a kind of identifier scheme for other than accessible resources. This specification is only concerned with accessible resources, which belong into the URL category.
|
|
This is a generic data type extension to specify one uncertain value tagged with a coded confidence qualifier. The confidence qualifier is a coded representation of the confidence as used in narrative utterances, such as "probably", "likely", "may be", "would be supported", "consistent with", "approximately", etc.
The confidence qualifier assigned to the value.
No standard terminology of confidence qualifiers exists, and it is unclear whether it can ever possibly exist. For instance, is “probably” more or less confidant than “could be”? The use of the confidence qualifier is thus only suited to communicate information between humans.
|
|
This is a generic data type extension to specify one uncertain value tagged with a probability. The probability expresses the information producer’s belief that the given value holds. How the probability number was arrived at is outside the scope of this specification.
Probabilities are subjective and (as any pieces of data) apply in a context. The context of any data item is the data structure in which that item appears. While the context dependence is important for any information, it is critical to understand the context dependency of probabilities: when new information is found the probability might change. Thus, for any message (document, or other information representation) the information -- and particularly the probabilities -- reflect what the information producer believed was appropriate at the given time and for the given purpose for which the message (document) was created.
Since probabilities are subjective measures of belief, they can be stated without being "correct" or "incorrect" per se, let alone "precise" or "imprecise". Notably, one does not have to entertain experiments to measure a frequency of some outcome in order to specify a probability. In fact, whenever statements about individual people or events are made, it is not possible to confirm such probabilities with "frequentists" experiments.
The type T is not formally constrained. In theory, discrete probabilities can only be stated for discrete data values. Thus, generally UVP<REAL> and UVP<PQ> values should not be stated. However, by definition a discrete value set is one that is finite or countably infinite, and abiding by this definition any measured value or real number recorded with digits is discrete. Thus, the distinction between discrete and continuous values is not practical for our purpose. Indeed, even though integer numbers are discrete (countably infinite) estimating a single integer number and tagging it with a probability is not reasonable. Most textbook on statistics treat estimations of integers or ordinals as real numbers when defining the estimated value of a random sample X as the sum of x * p(x) over all x in X.
This is the probability assigned to the value. The probability is a real number between 0 and 1. If the probability is unstated (NULL), an UVP<T> is indistinguishable from a simple data value T.
There is no "default probability" that one can assume when the probability is unstated. Therefore, it is impossible to make any semantic difference between an UVP<T> without probability and a simple T. UVP<T> does not mean "uncertain", and a simple T does not mean "certain". In fact, the probability of the UVP<T> could be 0.999 or 1, which is quite certain, where a simple T value could be a very vague guess.
|
Acknowledgement Attention_line File_of_batch Get_more_results |
Message Message_interaction Query Query_ack |
Query_by_parameter Query_by_selection Query_message_interaction Response_field |
|
Clinical_document |
Document_service |
|
Device Imaging_modality |
Resource_slot |
Schedulable_resource |
|
Access Act Act_relationship Container |
Diet Participation Procedure |
Substance_administration Supply Working_list |
|
Living_subject |
Referral |
|
Patient_encounter |
Person |
Qualified_practitioner |
|
Consent Material |
Observation Patient_encounter |
Transportation |