Copyright 2000 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-98 20000814
Developed by: Modeling and Methodology
|
Authentication Clinical_document |
Clinical_document_header Consent |
Health_chart Health_chart_deficiency |
|
Certification_additional_opinion Guarantor_contract |
Healthcare_benefit_coverage_item |
Insurance_certification |
|
Champus_coverage |
Master_healthcare_benefit_product |
A collection of classes designated used as reference classes to master tables.
|
Bad_debt_collection_agency |
Insurer |
Organization |
|
Administrative_patient_accident Administrative_patient_death |
Disability Patient_information_disclosure |
Person_provider_association |
|
Bad_debt_billing_account Billing_information_item |
Financial_transaction |
Patient_billing_account |
|
Condition_node Diet Document_service Medication Observation |
Procedure Service Service_actor Service_list Service_list_item |
Service_relationship Service_target Supply Transportation |
|
Access Container Device Food |
Location_encounter_role Master_patient_service_location Material Material_relationship |
Responsibility Specimen Therapeutic_agent |
|
Contact_person Employee Language Language_ability |
Notary_public Person Person_employment |
Person_name Stakeholder_affiliate Transcriptionist |
This category is used as a temporary holding are while building the RIM. It should contain neither classes nor associations on a long-term basis.
This draft HL7 Reference Information Model (RIM) is the result of the eighth HL7 RIM harmonization cycle. RIM change proposals from several HL7 Technical Committees were reviewed and acted upon during a RIM Harmonization Meeting held July 13-14, 2000 in Burlington, VT. Technical Corrections were applied on August 18, 2000.
This version of the HL7 RIM is being provided to the Technical Committees and Special Interest Groups of HL7 for use at the August 31, 2000 RIM Harmonization meeting in Chicago. 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 Orders/Observation
Access tubes and drains are anything used (actually) to administer therapeutic agents (medication and vital elements) into the body, or to drain material (e.g., exsudat, pus, urine, air, blood) out of the body. Typically an access is a catheter, cannula or flexule proceeded into a compartment of the body.
Therefore, (target) body site and entry site are attributes of the access. Note that the Access role primarily exists in order to describe material actually deployed as an access, and not so much the fresh material as it comes from the manufacturer. For example, in supply ordering a box of catheters from a distributor, it is not necessary to use the access role class, since the material attributes will usually suffice to describe and identify the product for the order. But the Access role class is used to communicate about the maintenance, intake/outflow, and due replacement of accesses and drains.
Material in the role of an Access is 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.
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 Service.body_site.
Body site has been copied from the Service class into the Access role class. The value of the Access.body_site_cd should be identical to the value of the Service.body_site_cd of an associated access placement service. This attribute is used if such an associated access placement service is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a Target (resource) of many services, the target body site seems to have become an important attribute of the access itself. The body 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.)
The Access.entry_site_cd specifies the anatomic site where the access first enters the body. For example in a arteria pulmonalis catheter targets a pulmonary artery but the access entry 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 Service.body_site.
Entry site has been copied from the Procedure service class into the Access role class. The value of the Access.entry_site_cd should be identical to the value of the Procedure.entry_site_cd of an associated access placement service. This attribute is used if such an associated access placement service is not communicated. Since accesses are typically placed for a considerable period of time and since the access is used as a Target (resource) of many services, the entry site seems to have become an important attribute of the access itself. The entry site is one of the most distinctive descriptors that help in locating a specific access among many others.
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.
OpenIssue: Should this be a subtype iinstead of a role relatiionship.
Class steward is Orders/Observation
A stakeholder that is the source of information concerning a reported patient accident.
Rationale: Limit the scope of class to the information for which stakeholder is source.
OpenIssue: Amplify definition. Does this include incidents within the healthcare provider as well as accidents, e.g., auto accidents that lead to healthcare encounters.
|
|
|
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 connection shows the relationship of the acknowledgement to a specific HL7 V3 message
Specifies the relationship between a Query_ack instance and an Acknowledgement instance.
This relationship indicates the association of the Acknowledgement class in an HL7 V3 acknowledgement message.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
Includes data related to the act or process of bearing or bringing forth offspring. The information contained in this pertains to the newborn (not the mother.)
OpenIssue: Should this class be reviewed as a candidate for modeling as a service event?
An indication that the baby in a person birth event is detained after the mother's discharge.
|PV2^37^00738^Baby Detained Indicator|
A unique identifier assigned to a person's birth certificate.
OpenIssue: Consider modeling as stakeholder identifier.
A code depicting the method of birth (e.g., caesarean, vaginal, forceps, . . .).
The county in which the person's birth record is recorded.
The date the birth event was recorded.
The number of days in a patient encounter in which there is a person birth event that is allocated to the newborn.
An indication that the baby in the birth event was stillborn.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An undesirable or unfortunate happening that occurs unintentionally and usually results in harm, injury, damage, or loss.
Rationale: Better reflection of the admiistrative nature of this class
OpenIssue: Amplify definition, adjust rationale Is this an information description of the address, or is it a description of the site the accident occurred at? Or, is it the location within the healthcare provider at which the accident took place? Also, remove or improve rationale.
An indication that the accident resulted in death.
|ACC^6^00814^Accident Death Indicator|
Free form textual description of the accident.
The date and time the accident occurred.
|ACC^1^00527^Accident Date/Time|
A description of the location of the accident.
Rationale: specific to this usage
|ACC^3^00529^Accident Location|
The state in which the accident occurred.
|ACC^4^00812^Auto Accident State|
A code depicting the type of accident.
OpenIssue: Amplify definition. Provide some idea of how accidents are typed.
|ACC^2^00528^Accident Code|
The date and time the accident was identified.
Rationale: Move inherited attribute to specialization in order to allow removal of generalization (patient)clinical_item) with single specialization.
OpenIssue: The name and definition do not correspond.
|AL1^6^00208^Identification Date|
An indication that the accident is work related.
Rationale: as modeled, this is a characteristic of the accident, which is not the same as an injury.
OpenIssue: Improve rationale and/or definition. Why is it relevant to make the distinction between accident and injury?
|ACC^5^00813^Accident Job Related Indicator|
Rationale: Allows removal of generalization (patient_clinical_item) with single specialization
Class steward is Patient Administration
Interested committees Orders/Observation
Data collected that relates to the act of dying; the end of life; the total and permanent cessation of all the vital functions of a patient.
Rationale: Better reflection of the administrative nature of this class.
OpenIssue: Adjust definition, remove or improve rationale. Also consider modeling os observation
The identifier assigned to the death certificate.
OpenIssue: Consider modeling as stakeholder id.
The date that the death certificate is recorded.
A major classification of the cause of death.
The date and time of death.
OpenIssue: Amplify definition. Is this time death was recorded? Or the estimate of a clinician of when the patient died?
The name of the location where the death occurred.
OpenIssue: This reference to a location needs further analysis to see if there is a relationship to a class hiding in here somewhere or not.
The name of the source providing the death notification.
A code identifying the source type used for verification.
OpenIssue: Amplify and clarify definition. Would it be better than make death verification an observation?
The date the death information is verified.
Name of the person providing verification of death.
Class steward is Control/Query/MasterFiles
This abstract class represents TC specified content in an application specific response HL7 V3 message.
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Patient Administration
A planned patient encounter set for a specific time and place.
Amount of time allotted for the appointment. In cases of repeating appointments, this field describes the duration of one instance of the appointment.
|ARQ^9^00868^Appointment Duration| |SCH^9^00868^Appointment Duration|
Text providing the service(s) expected to be provided in the scheduled encounter.
A unique identifier assigned to an appointment.
|ARQ^2^00861^Filler Appointment ID| |SCH^2^00861^Filler Appointment ID|
Code for the reason that the notification event was triggered. It may describe the cancel reason, the delete reason, the discontinue reason, the add reason, the block reason or others.
|SCH^6^00883^Event Reason|
The scheduled date and time for the start of an appointment.
|SCH^11^00884^Appointment Timing Quantity|
Code describing the status of the appointment with respect to the filler application. Sample values: Booked, Started, Complete, Cancelled, Discontinue, Deleted, Overbook, To-be-rescheduled..
|AIG^14^00889^Filler Status Code| |AIL^12^00889^Filler Status Code| |AIP^12^00889^Filler Status Code| |AIS^10^00889^Filler Status Code| |SCH^25^00889^Filler Status Code|
A code depicting the urgency for the patient to be seen by a healthcare provider.
OpenIssue: Committee must revisit the multiplicities for this association.
OpenIssue: This may have to be changed after we figure out what tis "encounter" thing really is.
Links a schedule to its contents.
Rationale: This many-to-many association represents the over-booking of a resoruce slot Patient is just another resource and an appoinment can be booked without including the patient, i.e., a consult. It is not believed that this many-to-many will ever need to be resolved.
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
A request for the booking of an appointment.
Rationale: Separates an appointment from a request for an appointment.
OpenIssue: Review with Orders steward. Seems different paradigm from treatment of service events.
The type of appointment request with respect to administrative record keeping. May be used to lock a remote resource before committing or to record an appointment after it is completed. Examples are: NORMAL, TENTATIVE, COMPLETE.
OpenIssue:
|ARQ^8^00867^Appointment Type| |SCH^8^00867^Appointment Type|
A categorization of an appointment request by how the patient is presented to the healthcare provider. Examples are: NORMAL, WALKIN, EMERGENCY.
A code describing the cancel reason, the delete reason, the discontinue reason, the add reason, or any other code describing the reason for a specific request trigger event.
|ARQ^6^00865^Request Event Reason|
The date and time the appointment request was made.
The amount of time being requested for the appointment.
OpenIssue:
|ARQ^9^00868^Appointment Duration| |SCH^9^00868^Appointment Duration|
Unique identifier for an appointment request.
Rationale: Separates appointment from its request.
OpenIssue:
|ARQ^1^00860^Placer Appointment ID| |SCH^1^00860^Placer Appointment ID|
The urgency of the request.
|ARQ^12^00871^Priority|
The general reason that the appointment is to take place. This code should define the general nature of the service. Sample values: CHECKUP, FOLLOWUP, NEW-PATIENT, BRIEF-VISIT, EXAMINATION.
|ARQ^7^00866^Appointment Reason| |SCH^7^00866^Appointment Reason|
The date and time that the appointment is requested to begin in the form of a date/time range.
|ARQ^11^00870^Requested Start Date/Time Range| |ARQ^13^00872^Repeating Interval| |ARQ^14^00873^Repeating Interval Duration|
Code describing the status of the appointment request with respect to the filler application. Sample values: Pending, Waitlist, Cancelled, Blocked, Scheduled
OpenIssue: Committee must revisit the multiplicities for this association.
|
|
|
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.
|
|
|
Class steward is Information Management (Medical Records)
All instances that record information related to the relationship between a Health Chart Document Header and the Authenticator of the document.
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
This records the date that the contents of the healthcare document were verified by the authenticator.
Rationale:
OpenIssue:
Code indicating the type of authentication that was carried out for the document, e.g., authentication, legal authentication. A document can be "authenticated": a completion status in which a document has been signed manually or electronically by one or more individuals who attest to its accuracy; and/or a document can be "legally authenticated": a completion status in which a document has been signed manually or electronically by the individual who is legally responsible for that document. This is the most mature state in the workflow progression.
|
|
|
Class steward is Patient Administration
A billing account that has been turned over for bad debt collection.
OpenIssue: Review structure. Should statuses of accounts be handled as independent classes.
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|
The date the patient billing account was transferred to bad debt status.
|PV1^30^00160^Transfer to Bad Debt Date|
A code depicting the reason the patient billing account was transferred to bad debts.
|PV1^29^00159^Transfer to Bad Debt Code|
Class steward is Patient Administration
A role assumed by an organization stakeholder. This role is assigned one or more bad debt billing account.
OpenIssue: Review definition. How can account have a stakeholder role?
|
|
|
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
An additional medical opinion rendered for an insurance certification in order for the payor to provide payment for treatment. For example, many payors require a second or third surgical opinion when elective surgery is proposed.
The date that the additional opinion was obtained.
|IN3^22^00523^Second Opinion Date|
A code that depicts the status of the additional opinion, for example, second opinion required, third opinion required, documentation requested, documentation received.
OpenIssue: This is not a state variable for this class state transition diagram and therefore should not be named status_cd.
|IN3^23^00524^Second Opinion Status | |IN3^24^00525^Second Opinion Documentation Received|
|
|
|
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|
Class steward is Information Management (Medical Records)
Clinical documents are legally authenticatable persistent units of information generated by healthcare practitioners that document the care provided for patients.
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. Additionally, the envisioned high-level HL7 meta-model may represent "information containers" separately from the information itself. Enhancements to the service class, along with the complete specification of such a meta-model will likely obviate the need for this class, and we anticipate deleting this class from the RIM by mid-2001.
OpenIssue: There appears to be some problems with how this is modeled, and the committees should re-examine this. There must be either attributes or associations added to this class or a persuasive Rationale.
|
|
|
Class steward is Information Management (Medical Records)
Interested committees Orders/Observation
Documentation of a health related factor concerning a patient. See the class Document Header in the MDR 2300 model.
OpenIssue: This needs to be extended to be the state attribute of the class and to have all of its transition and code values identified. Needs to be reconciled with the other status codes that exist for this class. This should be just status_cd rather than completion_status_cd. - the other three fragments must be
OpenIssue: Expand definition. Header and "documentation" seem different. Remove reference to MDR 2300 and replace with explanatory material.
OpenIssue: The State transition diagram needs to be drawn. Information provided to RIM Harmonization 06/99 included: DI ---> AU | IN | LA | IP | PA DO ---> AU | PA | LA IP ---> IN | AU | LA | PA IN ---> AU | LA | PA PA ---> AU | LA AU ---> LA LA ---> <final state>
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
A code depicting the availability of the document.
OpenIssue: Please indicate how the different availability statuses are distinguished. Examples would be good.
A code depicting the reason for the latest change to the document.
OpenIssue: Include examples or other ways of indicating how change reasons are discriminated.
A code depicting the completion status of the document, e.g., incomplete, authenticated, legally authenticated.
OpenIssue: This needs to be extended to be the state attribute of the class, and to have all of its transition and code values identified. Needs to be reconciled with the other status codes that exist for this class. This should be just "status_cd" rather than "completion_status_cd" - the other three fragments must be incorproated into a single state machine. The class must also be identified as a Subject Class. There are also style guide issue here as well.
OpenIssue: Indicate typical completion status or describe what kind of states are designated with these statuses.
|TXA^17^00928^Document Completion Status|
A code depicting the confidentiality status of the document.
OpenIssue: Indicate typical confidentiality statuses or describe what kind of states are designated with these statuses.
A code indicating how the content of the document is to be presented.
OpenIssue: Indicate typical presentation codes or describe what kind of states are designated with these codes.
Code classifying the document as an original or a replacement document. An original document is the first version of a document. An addendum is an appendage to an existing document that contains supplemental information. The appendage is itself a document, and acquires a new value for Clinical_document_header.id. The parent document being appended is referenced via the has_as_parent_document association. The parent document being appended remains in place and its content and authentication status are unaltered. A replacement document replaces an existing document. The replacement document has the same value for Clinical_document_header.id as the parent document being replaced. The parent document being replaced becomes obsolete, but is still retained in the system for historical reference.
The specific date that the document was initiated.
The name on an electronic file containing the document.
A unique identifier assigned to the document.
The date the document was last edited.
The reporting priority of the clinical result.
OpenIssue: Indicate typical priority codes or describe what kind of states are designated with these codes.
|OM1^26^00611^Reporting Priority|
The date and time the clinical observation results are issued.
Rationale: closer to language used in V2.3
|OBR^22^00255^Results Rpt/Status Chng - Date/Time|
A code depicting the storage status of the document.
OpenIssue: Indicate typical storage statuses or describe what kind of states are designated with these statuses.
The date the information in the document was transcribed.
A code depicting the document type (e.g., discharge summary, progress note).
Represents the date/time of the current document version. A document versions when it replaces an existing document.
Version number is an integer starting at '1' and incrementing by 1. The first instance or original document should always be valued as '1'. The version number value must be incremented by one when a document is replaced. The value of Clinical_document_header.availability_status_cd of the prior version should become 'obsolete', explicitly via another message.
OpenIssue: May be a need for an instance ID that is unique for the document. This may remove the need for the version number; needs to be examined by the committee. There should probably be one or more recursive relationships here so that the relationship between documents is explicit. There may also be more than just 'append' and 'replace' for these type relationships.
OpenIssue: There appears to be some problems with how this is modeled, and the committees should re-examine this. There must be either attributes or associations added to this class or a persuasive Rationale.
OpenIssue: There are at least three different ways to accomplish this, including handling the existing RIM through MIM rules and verbage. This should be examined jointly between the committees and MnM to resolve the best way to do this.
OpenIssue: Review cardinality. Document recipient looks like a role class, perhaps requires relationship to the document header to exist.
OpenIssue: This association would appear to be mandatory from Transcriptionist to document header, since the transcriptionist instance (a role class) is not otherwise needed.
OpenIssue: Review cardinality.
OpenIssue: This many-to-many association should be resolved.
Class steward is Orders/Observation
The condition node service type is used to represent problems (medical conditions.) The primary purpose of the condition node is to arrange other services of the patient record into a longitudinal thread that represents the patient’s condition. Condition nodes are lined up along the time axis through links of type updates condition. Thus, a Condition node instance is not a condition or problem in itself, the condition is the entire thread or network of chain-linked condition nodes.
Each condition node represents a revision of the problem in the form of added evidence, or changing of the "name" assigned to the problem. A "name" is assigned to a problem thread by a condition node that binds another observations (diagnosis) to the thread. Consequently, conditions may change their "names" over time to represent the progression of disease, and the changing of knowledge about the disease.
A condition thread may have more than one current name. Consequently, conditions may accumulate names over time as different practitioners develop opinions or descriptions of the condition. It will not be unusual that these names may be in conflict with one another, such as when two clinicians disagree about the nature of a condition. In addition, these names may also change over time to represent the progression of disease or the changing of knowledge about the disease.
Class steward is Orders/Observation
Interested committees Patient Care
The Consent class represents informed consents and all slimilar medico-legal transactions between the patient (or his legal guardian) and the provider. Examples are informed consent for surgical procedures, 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 kinds of purposes, that remind the physician about the topics to mention. Such forms also contain patient education material. In electronic medical record communication consents thus are information entities on their own and need to be managed similar to medical activities. Thus, consents are modeled as a special class of Services.
The “signatures” to the consent document are represented electronically through Actor instances to the consent object. Typically an informed consent has actors of type performer (the physician 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 physician is not required (e.g. living will,) the performer may be the patient himself or a notary public.
Some consents have a minimal required delay between the consent and the service, so as to allow the patient to rethink his decisions. This minimal delay can be expressed in the service definition by the service_relationship.pause_qty attribute that delays the service until the pause time has elapsed after the consent has been completed.
|
|
Class steward is Patient Administration
OpenIssue: Add definition.
A code indicating the reason the contact should be used (e.g., contact my employer if patient is unable to work).
|GT1^47^00747^Contact Reason| |IN2^51^00791^Employer Contact Reason | |IN2^54^00794^Insured’s Contact Person Reason | |IN2^57^00797^Insurance Co. Contact Reason | |NK1^29^00747^Contact Reason|
OpenIssue: Needs to be re-examined after the LHSR work is completed.
OpenIssue: Review/explain cardinality.
OpenIssue: Review/explain cardinality.
OpenIssue: Review/explain cardinality
OpenIssue: Review/explain cardinality
|
|
|
Class steward is Patient Care
A container is a thing that is used to hold other things for some purpose of transportation or to protect its contents from loss or damage. Especially with amorphic substances (liquids, gases) the content can not be had without some container. However, the content of a container is always distinguishable and relatively easyly separable from the container, unlike the content (ingredient) of a mixture.
A container is related to a content material through a Material_relationship of type content.
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, te 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: Should this be a subtype instead of a role relationship?
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
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.
Date of last calibration and/or inspection of the device.
Name of the version of this device as designated by the manufacturer.
Duration for a single schedulable unit in a schedule for a resource.
Name of the software version number(s) and/or release associated with the device.
Association links an item of medical equipment to the calendar slots in which it is scheduled. A slot gives the starting date-time, and the length of time the item is scheduled for.
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
A pool of like-type equipment available for scheduling purposes.
OpenIssue: There are probably two concepts to be included in scheduling, both of which are vying for attention here. The first is the ability to establish a pool. Give me one ventilator, but I do not care which one. That is covered by the current definition. The other is the ability to aggregate resources and schedule them as a group or a team. Schedule a surgical team or request a set of equipment needed for a particular procedure. This latter grouping is not represented in these classes.
Unique identifier for the group
|AIG^5^00899^Resource Group| |AIP^5^00899^Resource Group|
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Request information about equipment that is controlled by a schedule
Rationale: Specializes the request by type of resource
The quantity of the specified resource or resource type.
|AIG^6^00900^Resource Quantity|
Identifies what type of equipment or equipment group is being requested in this instance of request.
|AIG^3^00897^Resource ID|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
An allocation of time defined when a specific piece of medical equipment is available for use for a healthcare service.
Association links an item of medical equipment to the calendar slots in which it is scheduled. A slot gives the starting date-time, and the length of time the item is scheduled for.
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.
A unique identifier assigned to the diagnostic related group.
Rationale: DG1^8 was retained in v2.3 for backward compatibility only.
OpenIssue: Resolve rationale. Does this mean the field should really not be here?
<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 very much like supply services, with some aspects resembling Medication services: the detail of the diet is given as a description of the Material associated as a target of type 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.)
The most important medically relevant parameter of a diet order is the supplied biologic energy (Calories) per day. This value may be specified in the Diet.energy_qty attribute as a physical quantity. 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".
|
|
|
Class steward is Patient Administration
Information about non-permanent disabilities. (Permanent disabilities are represented by Person.disability_cd.)
Rationale: DB1 segment
OpenIssue: How should this be associated with the Patient_encounter class? See DB1-4.
OpenIssue: Need to expand rationale.
The date that this administrative disability became effective.
Rationale: DB1-5
OpenIssue:
|DB1^5^01287^Disability Start Date|
The date the person was authorized to return to work.
Rationale: DB1-7
OpenIssue:
|DB1^7^01289^Disability Return to Work Date|
The date that this disability ended.
Rationale: DB1-6
OpenIssue:
|DB1^6^01288^Disability End Date|
The date the person was unable to work due to this disability.
Rationale: DB1-8
|DB1^8^01290^Disability Unable to Work Date|
Class steward is Information Management (Medical Records)
Rationale: Identity of the receiver is a key piece of information associated with a document. For reasons stated in another request, the TC would like this instance connection to be associated with an attribute of the patient care document header class.
OpenIssue: Add definition.
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
OpenIssue: Review cardinality. Document recipient looks like a role class, perhaps requires relationship to the document header to exist.
|
|
|
Class steward is Information Management (Medical Records)
Specialization of Service 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.
Represents the time an original document is initiated (e.g., dictated or input into a software interface). If a document is subsequently revised, the value of this attribute remains unchanged,
A report identifier that remains constant across all document revisions that derive from a common root. An original report is the first version of a report. It gets a new unique value for 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 a service_relationship, with service_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 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 imcremented more often to meet local requirements.
|
|
Class steward is Control/Query/MasterFiles
This class holds the specification of a RIM element response to a query specification.
Identifies the groups of elements that occur in a TC specified Query_response_message_type. It is assumed that names will be defined for aggregate element groups in the RIM that TC's will include in query response specifications.
Specifies relationship between Element_response_control and an instance of element_sort_control.
|
|
|
Class steward is Control/Query/MasterFiles
Holds specification of sort order for an element response mode 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.
Specifies relationship between Element_response_control and an instance of element_sort_control.
Class steward is Patient Administration
An employed person.
|
|
Class steward is Patient Administration
A person or organization which employs persons.
The date range during which the associated organization holds the role of employer.
OpenIssue: Review/explain cardinality
|
|
|
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|
The date and time the DRG was assigned to the encounter.
|DRG^2^00769^DRG Assigned Date/Time |
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|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An association between a Healthcare practitioner and a patient encounter.
A code depicting the role of the type of participation the healthcare practitioner assumes in the encounter (e.g. attending physician, admitting physician, consulting physician, referring physician).
ExtRef: UB FL 82 (for attending MD)
Class steward is Patient Administration
A role for a person who enters information into an automated system.
|
|
|
Class steward is Patient Care
Interested committees Patient Administration
A collection of encounters or condition nodes defining an interval of time of interest in analysis.
OpenIssue: The definition needs to reviewed by Patient Care.
Episode of care descriptive text.
OpenIssue: Not reviewed by Patient Care.
A code indicating the type of episode. The type code is dependent upon the reason for collection of patient encounters.
OpenIssue: Not reviewed by Patient Care.
A unique identifier assigned to the episode of care.
OpenIssue: Not reviewed by Patient Care.
An indication that the list of encounters associated with the episode is a closed list.
OpenIssue: Not reviewed by Patient Care.
OpenIssue: What does it mean to have a 'closed list'? Is this different from saying that the Episode is closed, that is that it is finished? If not, change the name to episode_closed_ind.
Text describing the outcome of the episode of care.
OpenIssue: Not reviewed by Patient Care.
An indication that the episode represents a recurring patient service.
OpenIssue: Not reviewed by Patient Care.
A collection or a series of Healthcare encounters for a patient.
This association should not be instantiated if the alternate association to condition mode is instantiated.
Rationale: This association serves the queries "give me encounters which deal with this episode."
OpenIssue: Are we certain that a Patient_encounter can be part of only one Episode of Care? And does an Episode_of_care have to have at least one Patient_encounter, or is this optional?
A state of being which has a beginning and an eventual end. "End" may represent resolution of an illness or death of the patient, family or other aggregate unit, e.g. population or community. Functionally, an episode of condition is a named, evolving aggregation of service_event.condition_nodes. Composition membership of condition nodes in episode of condition represents a judgment (e.g., clinical, administrative, financial) that the condition relates to one or more condition nodes. Examples include: pregancy, injuries, acute diseases, chronic diseases, risk factors, and wellness deficiencies.
|
|
|
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
A charge, credit, or adjustment to charges in a patient's billing account.
An alternate description of the transaction.
|FT1^9^00363^Transaction Description - Alt|
Explanatory text concerning a financial transaction.
|FT1^8^00362^Transaction Description|
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|
A code depicting the financial action covered in the transaction.
|FT1^7^00361^Transaction Code|
The date of the transaction.
|FT1^4^00358^Transaction Date|
A identifier assigned to the transaction for control purposes.
|FT1^2^00356^Transaction ID| |UB2^12^00564^Document Control Number|
A code depicting the transaction type (e.g., credit, charge, payment, adjustment, ...).
|FT1^6^00360^Transaction Type|
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|
OpenIssue: Is not the person who enters a financial transaction in a specific role? On behalf of an organization? When very loosely coupled systems exchange messages, they'll have to specify the role and accountability, won't they?
OpenIssue: Association names are not descriptive of what this association means. There is currently no way to describe fees for services in a master file. The issues of fees, fee schedule and their relationship to actual charges need to be modeled. Or does the assoication between RIM092.Master_service and Coverage_item allow to assign different fees to the same master service?
|
|
Class steward is Patient Care
Food is a role of material. Food is anything that is ingested by humans to address hunger and provide nutrition to the body. Food is often combined into dishes, which are combined into full meals. Since the Material_relationship class can express this combination there are little additional properties needed in the food class. There is only one classifier attribute that seem to be relevant and special for food. We call that classifier "preference", which is described below.
The food preference describes the "style" and properties of the food that is selected mainly to meet the preference and customs of the recipient of the food. The term "preference" was selected to express that this property of food meets a preference of the consumer, not in order to limit this attribute to describe only the preferred style of food but not the actual style. The following concept repertoire is defined:
Table 40: Preferences, or "styles" of food Concept Implies Code Definition non-vegetarian NVEG Supposedly every reasonable food is permitted. no beef NVEG NBEF Everything but beef (e.g., a hindu will absolutely not eat beaf.) no pork NVEG NPRK Everything but pork (e.g., muslims and jews) kosher NPRK KOSH Prepared after the traditional jewish rules no beef and no pork non-veg. NBOP Everything except beef and pork (e.g., many hindus today will not eat beaf, but will also stay away from pork), allowed meat is mutton, poultry, and fish. no meat but fish non-veg. NMBF Fish is the only allowed meat. vegetarian VEG No meat at all. The only allowed animal product is egg and milk. vegan VEG VEGN vegetarian without eggs
OpenIssue: Should this be a subtype instead of a role relationship?
|
|
|
Class steward is Patient Administration
The person or organization assuming financial responsibility for some or all of the charges in a patient billing account.
A code depicting the classification of the financial status of the guarantor.
The combined annual income of all members of the guarantor's household.
|GT1^27^00778^Guarantor Household Annual Income|
The number of people living at the guarantor's primary residence.
|GT1^28^00779^Guarantor Household Size|
OpenIssue: Review/explain cardinality.
|
|
|
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|
OpenIssue: This many-to-many association should be resolved with an association class.
|
|
|
Class steward is Information Management (Medical Records)
A record of health related events, facts, and related data for a particular patient.
The unique identifier for the health chart.
A classification code for the health chart (e.g., inpatient, outpatient, mental health, . . .).
The current status of the health chart.
OpenIssue: Is it true that all Health charts must have a location? This would appear to be better modeled as optional on both ends.
|
|
|
Class steward is Information Management (Medical Records)
This class captures a record of deficiencies in the Health record.
The date the chart deficiency was determined.
A description of the health chart discrepancy.
A code depicting the level of discrepancy found in the health chart.
OpenIssue: Need examples of the codes.
A code identifying the type of deficiency identified.
|
|
|
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|
The time period during which the coverage is asserted to be effective.
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|
OpenIssue: Is this multiplicity correct? Is the Parent-Child tree structure correct? Is there an associative class for the relationship?
OpenIssue: could the coverage_item be applicable for actual services (event) too? Use case: a service was done on the basis of an emergency indication without any prior knowledge to coverage. A request is sent to a billing system or insurance, asking whether this actual service was covered and in what way it was covered?
OpenIssue: Is this multiplicity correct? Is the Parent-Child tree structure correct? Is there an associative class for the relationship?
Rationale: This class now contains the attributes of a "master" class; insurance certification is associated with coverage_item.
OpenIssue: Are the multiplicities correct? Should there be an additional connection to Patient? Should there be an additional association to Healthcare_benefit_product? Or an association with a new class representing a Patient instance of a benefit product?
Rationale: This class now contains the attributes of a "master" class; insurance certification is associated with coverage_item.
OpenIssue: This cardinality does not work properly since you can now link to only a single coverage item. This will only work if that linked item is the Parent. This needs to be clarified or modified in some way.
Class steward is Patient Administration
A person or organization which is a purchaser of a health benefit product.
OpenIssue: Review/explain cardinality
Class steward is Information Management (Medical Records)
Rationale: Identity of the authenticator is a key piece of information associated with a document.
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
Class steward is Patient Administration
OpenIssue: There are at least three different ways to accomplish this, including handling the existing RIM through MIM rules and verbage. This should be examined jointly between the committees and MnM to resolve the best way to do this.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An organization or person responsible for the provision of healthcare services to an individual, or involved in the provision of healthcare related services.
The type of board certification held by the healthcare provider.
An indication that the healthcare provider is board certified.
The date of certification.
The date range during which the role of healthcare service provider is effective for the stakeholder
A unique identifier assigned to the healthcare service provider. For individual healthcare practitioners examples include US National Provider Identifier of Type 1, doctor number assigned by a healthcare provider organization. For healthcare provider organizations examples include US Federal Tax Identification Number, a hospital number assigned by another healthcare provider organization. OpenIssue: Is this identifier redundant with the identifier in stakeholder.
|OBR^16^00226^Ordering Provider| |ORC^12^00226^Ordering Provider| |PR1^12^00402^Procedure Practitioner| |RXA^10^00352^Administering Provider| |RXE^13^00305^Ordering Provider's DEA Number| |RXO^14^00305^Ordering Provider's DEA Number|
The date recertification is required.
A code depicting the particular subject area or branch of medical science, as practiced by a Healthcare practitioner.
Rationale: A person's PCP can be either a practitioner or a provider organization.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
A person responsible for the provision of healthcare services to an individual, or involved in the provision of healthcare related services. This class is not a healthcare_provider_organization. For example, a physician, midwife, nurse practitioner.
The fellowship field of a physician.
OpenIssue: Need example codes.
The name of the graduate school attended by the healthcare practitioner.
The date the practitioner graduated from graduate school.
A code indicating the position of a healthcare practitioner in an healthcare organization (e.g., head of department, trainee, hospital consultant, . . .).
OpenIssue: The example codes make this sound like a multi-axial description. Could not a hospital consultant also be a head of department. Review with vocabulary facilitator.
A code indicating the type of healthcare professional (e.g., medical doctor, nurse, pharmacist, laboratory worker, . . .).
An indication that the healthcare practitioner is a primary care provider.
The physician residency code.
OpenIssue: Need example codes for this attribute.
Duration for a single schedulable unit in a schedule for a resource.
Rationale: Provides visibility into scheduling details.
OpenIssue: Does this match any V2.3 field?
|APR^4^00911^Slot Spacing Criteria|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
A pool of like-type providers available for scheduling purposes. When no specific resource is requested but a resource role is requested, this field can be used to further qualify the type of resource being requested.
Unique identifier for the group
|AIG^5^00899^Resource Group| |AIP^5^00899^Resource Group|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Patient Administration
Request information about specific personnel that are controlled by a schedule.
A code indicating the type of healthcare professional (e.g., medical doctor, nurse, pharmacist, laboratory worker, . . .).
Rationale: Creates a separate class for types of providers.
|AIP^4^00907^Resource Role|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
An allocation of time defined when a provider is available to perform a healthcare service.
|
|
|
Class steward is Patient Administration
A patient encounter involving an admission to an inpatient facility.
The number of actual days of an inpatient stay. The actual days quantity can not be calculated from the admission and discharge dates because of possible leaves of absence.
|PV2^11^00712^Actual Length of Inpatient Stay|
The estimated number of days in an inpatient encounter.
|PV2^10^00711^Estimated Length of Inpatient Stay|
|
|
|
Class steward is Patient Administration
An affirmation by an insurance company that it will pay for a specified service.
A code depicting the reason an appeal was made on a non-concur for certification.
OpenIssue: Need example codes.
|IN3^17^00518^Appeal Reason|
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|
Rationale: This class now contains the attributes of a "master" class; insurance certification is associated with coverage_item.
OpenIssue: Are the multiplicities correct? Should there be an additional connection to Patient? Should there be an additional association to Healthcare_benefit_product? Or an association with a new class representing a Patient instance of a benefit product?
|
|
Class steward is Patient Administration
A person or organization which acts as a contact for insurance certifications.
OpenIssue: The description is incomplete. This should indicate whether the contact is in the payee organization, the payer organization, both or neither. Also, why is this not another role for the Contact_persohn class?
A code depicting the type of certification contact. (e.g., certification agency, certification operator, approving party, physician reviewer, . . .).
|
|
Class steward is Patient Administration
A role assumed by an organization as underwriter for a healthcare benefit product.
The date range during which the organization assumes the role of insurer.
OpenIssue: Review/explain cardinality.
|
|
|
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). ISO639 language table is a possible coding system.
|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
The proficiency level in a given mode of a person's communication for a 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 language proficiency in this mode (e.g. excellent, good, fair, poor)
|
|
|
Class steward is Orders/Observation
Interested committees Patient Administration
Any living organism or complex animal. This includes mammals, birds, fishes, bacteria, parasites, fungi and viruses.
OpenIssue: There are a number of duplicated attributes with Patient that need to be fixed. This probably needs to be remodeled properly.
Rationale: The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each Target_participation instance to select the appropriate target from among the possible targets.
The date and time of a living subject's birth or hatching.
The place the living_subject was born or hatched.
A text string representing the breed of the living subject.
A string description of the marking and coloring of the feathers, coat, scales, or skin of a living subject.
A code specifying the nature of publicity protections in place for this living subject.
The date and time that a living subject's death occurred.
An indication that the living subject is dead.
An indication that the living subject was euthanised.
A user-defined code representing the color of each eye.
A code specifying the gender of a living subject.
A code indicating the sexual status of a living subject.
A text string indicating the living subject's economic or psychological importance to the owner.
The country in which the living subject was born, captured or killed.
Represents the type of name, e.g., Common, Registered, Display, etc.
The primary name of a living subject.
A code indicating the primary use for which the living subject was bred or grown.
The quantity of individual living subjects represented by this instance of the class.
OpenIssue: This attribute is not the correct way to model populations, but it could be construed as this, which is incorrect. This needs to be modeled differently.
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 Patient Administration
An association between a patient encounter and a location that includes the period of the association, the function of the location, and the reasons for using and terminating it.
A code depicting the type of accommodation associated with this patient encounter (e.g. private, semi-private).
OpenIssues: Description should be updated to describe temporal nature of the accomadation assignment.. Double check the description of the Class.
|PV2^2^00182^Accommodation Code|
The period of time (start/terminate) that the association between the patient encounter and the facility is effective.
A code depicting the relationship of the facility location to the patient encounter (e.g., assigned, prior, temporary,pending...)
The status of location encounter role.
OpenIssue: Need example codes.
A code depicting the reason for the patient transfer associated with the patient encounter. Examples include roommate conflict, equipment malfunction, acuity change, etc.
|PV2^4^00184^Transfer Reason|
A indication that use of the location location has been or has not been approved.
|
|
|
Class steward is Patient Administration
Defines a collection of health benefits, specified as coverage items, that can be purchased as a single package or product from an insurer.
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|
The range of dates during which the healthcare coverage is effective. These dates represent the effective dates for the product, not the effective dates of coverage for a covered individual.
|IN1^12^00437^Plan Effective Date| |IN1^13^00438^Plan Expiration Date|
A indication as to whether the healthcare coverage is a group contract.
The unique identifier for the healthcare coverage benefit product.
Rationale: Duplicate of Healthcare_benefit_plan.benefit_plan_ID
OpenIssue: For CQ to resolve: we must have a data type for this that covers the instance identifier, the identifier type, and the assigning authority ID. This is a repeatable attribute.
|IN1^35^00460^Company Plan Code| |IN1^46^00471^Prior Insurance Plan ID|
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 Patient Administration
Interested committees Patient Care
A place where patient services are delivered.
The address of this location.
|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^01303^Dispense-to Location| |RXG^11^00299^Deliver-to Location| |RXO^8^00299^Deliver-to Location|
A description of the location to facilitate recognizing it and its characteristics.
Rationale:
OpenIssue:
|LOC^2^00944^Location Description|
the e-mail address for the patient location, if any.
Rationale: required by components of V2.3 field (XTN datatype)
For room or bed locations, identifies what types of eqipment are built in, e.g., telemetry equipment.
Rationale: Currently in 2.3 as LOC-8-Location Equipment.
OpenIssue: Note that this is just a placeholder for a 2.3 item and needs more work with internationalization and Inter-Enterprise.
A unique identifier of a patient care location.
|AIL^5^00905^Location Group| |FT1^16^00133^Assigned Patient Location| |LOC^1^01307^Primary Key Value - LOC| |NPU^1^00209^Bed Location| |PV1^3^00133^Assigned Patient Location| |PV1^6^00136^Prior Patient Location| |PV1^11^00141^Temporary Location| |PV1^39^00169^Servicing Facility| |PV1^42^00172^Pending Location| |PV1^43^00173^Prior Temporary Location| |PV2^1^00181^Prior Pending Location| |RQD^3^00277^Item Code - External| |RXA^11^00353^Administered-at Location| |RXD^13^00299^Deliver-to Location| |RXE^8^00299^Deliver-to Location| |RXG^11^00299^Deliver-to Location| |RXO^8^00299^Deliver-to Location|
The number of licensed beds at the location.
The name by which the service location is known.
The period from when the location opened until it closed.
Phone at the location.
|LOC^6^00949^Location Phone|
The specialty code of the service.
OpenIssue: This attribute may move to a masterfile class later.
OpenIssue: This does not appear to be a proper attribute of location. It appears to be an association to a clinical service (organization) that has a specialty code. At best, it might be re-structured or described to reference a set of specialty codes that can be supported by this location.
|LDP^4^00966^Speciality Type|
Duration for a single schedulable unit in a schedule for a resource.
Rationale: Provides visibility into scheduling details.
|APR^4^00911^Slot Spacing Criteria|
A code indicating the status of the location.
|NPU^2^00170^Bed Status| |PV1^40^00170^Bed Status|
A code indicating the type of patient care location (e.g., hospital, clinic, hospital ward, room, bed, . . .).
|LOC^3^00945^Location Type-LOC|
OpenIssue: Is it true that all Health charts must have a location? This would appear to be better modeled as optional on both ends.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Care
The Material class represents all physical and physiological things that are used, assessed, and acted upon in a service action. This includes pharmaceutical substances or disposeable supplies as well as durable medical equipment, prosteses, implantable devices, accesses, drains, literally everything.
Notably the material class includes facilities, such as immovable service locations or ambulances.
OpenIssue: There is some kind of problem with the name of this class and its associated relationship class. Also, there is some complexity with the connection to Location; this needs analysis and further work to determine the correct connection and structure. Considering changing Role relationships to service_resource class to subtyping.
A code signaling whether there are certain dangers or hazards associated with this material.
Concept Implies Code Definition tissue TIS The normal dangers associated with normal human or animal tissue. I.e. potential risk of unknown infections. Routine blood or excretions of humans and animals.
infectious INF Material known to be infectious with human pathogenic microorganisms. Those who handle this material must take precautions for their protection.
biohazard infectious BHZ Material contains microorganisms that is an environmental hazard. Must be handled with special care.
radioactive RAD Material is a source for ionizing radiation and must be handled with special care to avoid injury of those who handle it and to avoid environmental hazards.
poison POI Material is poisonous to humans. Special care must be taken to avoid incorporation, even of small amounts.
acid ACI Material is acid and may cause severe injury to human skin and eyes. Avoid any unprotected contact.
inflammable IFL Material is highly inflammable and in certain mixtures (with air) may lead to explosions. Keep away from fire, sparks and excessive heat.
explosive inflammable EXP Material is an explosive mixture. Keep away from fire, sparks, and heat.
A free text description of the material. May contain multimedia, such as a drawing or image depicting the material. (e.g., Physician's Desk Reference® includes photographs of tablets.)
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. Expiration dates 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.
A code to describe how the material needs to be handled to avoid damage. Example concepts / codes Concept Code Definition room temperature RMT Keep at room temperature, about 20 C body temperature BDT Keep at body temperature, about 36 to 37 C cool COO Keep cool at about 5 to 8 C frozen FRZ Keep frozen below 0 C deep frozen DFR Keep deep frozen, below 16 C nitrogen NTR Keep in liquid nitrogen dry DRY Keep in a dry environment dark DRK Protect against light no shock PSO Protect against shock upright UPR Keep upright, do not turn upside down no shake PSA Do not shake more
As a substantive class reflecting physical entities, material has instance identifiers. 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 material this is. Ideally each entity will have only one identifier assigned to it, however, since different systems will maintain different material data bases, there may be different instance identifiers assigned by different systems.
Note that for serial numbers assigned by specific manufacturers, catalog numbers of specific distributors, or for inventory numbers issued by owners, the attribute Responsibility.material_id : SET<II> 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 Responsibility.material_id may occur in Material.id just as well.
The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the container. A lot is a collection of products produced in one cycle. This means, for instance, if one bottle of a lot is spoiled, chances are high that the entire lot is spoiled. Conversely, product defects that occur in routine production are likely to be contained in one lot. Note that a lot number is not meant to be a unique identifier, but is meaningful only when the product kind and manufacturer is also identified.
For many materials, the individual thing has no relevance. Especially continuously divisible forms come only in "amounts" rather than as individuals. There is a specific class of physical quantities that can be used for amounts, count (number), amount of substance, mass, and volume. This class of physical quantities is called "extensive”" quantities. A quantity is called extensive if it can be added up (if it is additive.) For example, if you have 1 gallon of water and you add another gallon of water, you wave two gallons of water, since volume is an additive quantity. By contrast, if you have one gallon of Glucose 5% and add to it another gallon of Glucose 5% you still have Glucose 5%, thus, mass fraction is not an additive (extensive) kind of quantity.
Only extensive quantities are permitted as elements of the Material.qty set. Typically the kinds of quantities shown in Table 34 will occur. Extensive quantities are simpler to deal with than intensive quantities. Extensive quantities are never fractions or ratios, no denominator can cancel out the units of a numerator, and therefore, with extensive quantities we can conclude the kind of quantity from the unit of measure.
Table 34: Kinds of 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.
The Material.qty attribute permits to convey a collection of physical quantities. This collection feature must be used in the following way. When the set contains more than one quantity, the quantities must have different units. Furthermore, all quantities in the set must denote an equivalent amount. For example, for the material Glucose, we may specify an amount as the mass of 1 g. If we also want to specify the amount in amount of substance (moles) we must specify the equivalent of 1 g Glucose in mole, which is 5.556 mmol. For another example, if we specify the amount of a material Water as 1 L, and we want to provide a mass, the mass must be the mass of 1 L water, which is 1 kg.
The status_cd tracks the state of the state-transition model of the material. This may be a rather trivial state-transition model, since the more concrete and detailed state-transition models may be assigned to the material role classes.
OpenIssue: This is a code state variable and needs example code values.
This code describes what kind of material this is. It is an arbitrarily precise classification. We do not expect any single terminology to provide all concepts that are types of material, since it is simply too broad a domain. Instead of limiting the Material.type_cd to a single domain, we allow various code systems to be used, and thus, the actual domain of Material.type_cd becomes the union of all the possible code systems for material.
For example, specimen types (e.g., whole blood, serum, urine) can be used in this attribute. For chemicals, IUPAC codes might be used here. For arbitrary products one can use the Universal Product Code (UPC) code or a particular manufacturer’s serial number. For pharmacological substances yet another coding system may be applicable such as the U.S. National Drug Code (NDC.) The concept descriptor data type allows for multiple codes used as synonyms for each other, thus, one can specify an UPC code next to an NDC code and an IUPAC code.
OpenIssue: Should this be a subtype iinstead of a role relatiionship.
OpenIssue: Should this be a subtype instead of a role relationship?
OpenIssue: Should this be a subtype instead of a role relationship?
OpenIssue: Should this be a subtype instead of a role relationship?
|
|
|
Class steward is Orders/Observation
For many materials, the individual thing has no relevance. Especially continuously divisible forms come only in “amounts” rather than as individuals. There is a specific class of physical quantities that can be used for amounts, count (number), amount of substance, mass, and volume. This class of physical quantities is called “extensive” quantities. A quantity is called extensive if it can be added up (if it is additive.) For example, if you have 1 gallon of water and you add another gallon of water, you wave two gallons of water, since volume is an additive quantity. By contrast, if you have one gallon of Glucose 5% and add to it another gallon of Glucose 5% you still have Glucose 5%, thus, mass fraction is not an additive (extensive) kind of quantity.
Only extensive quantities are permitted as elements of the Material.qty set. Typically the kinds of quantities shown in Table 34 will occur. Extensive quantities are simpler to deal with than intensive quantities. Extensive quantities are never fractions or ratios, no denominator can cancel out the units of a numerator, and therefore, with extensive quantities we can conclude the kind of quantity from the unit of measure.
Table 34: Kinds of 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.
The Material.qty attribute permits to convey a collection of physical quantities. This collection feature must be used in the following way. When the set contains more than one quantity, the quantities must have different units. Furthermore, all quantities in the set must denote an equivalent amount. For example, for the material Glucose, we may specify an amount as the mass of 1 g. If we also want to specify the amount in amount of substance (moles) we must specify the equivalent of 1 g Glucose in mole, which is 5.556 mmol. For another example, if we specify the amount of a material Water as 1 L, and we want to provide a mass, the mass must be the mass of 1 L water, which is 1 kg.
OpenIssue: This name must be made consistent if the name of the Material class changes.
The role type may be used in the opposite direction.
For example, instead of listing a material instance representing a mixture and subordinate to it mentioning the ingredients as target material instances, one can use one ingredient and subordinate to it mention the mixture in which it happens to exist. This is the common way of thinking of pharmaceuticals. In most pharmaceuticals, we have one main ingredient which we consider “therapeutically active” and which we mention, although we know that this substance always comes as an ingredient of a mixture containing diluents, stabilizers, preservatives, flavors and colors. This active ingredient can then be specified as the top material instance ->inverted ingredient -> mixture -> ingredient -> other ingredients.
Another notable example for inversion of the relationship type is for containers. The content relationship type allows one to first list a container (e.g. package) and then provide a list of content as subordinate (target) material. In other cases, one wants to mention the material first and by the way describe it being contained in a container. Therefore, when the content is the important thing and the container just goes with it (e.g., for most medications,) one will use the inverted content link.
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. Take a checkboard, for example, in which rows are specified A-H and columns specified 1-8. In these cases, the non-numeric coordinate must be converted into a numeric. The 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 the checkboard example, this means that the columns are changed or traversed first. When you start placing the figures in the start position, you chiefly align them in the columns, and only then you start moving them ahead in rows (and columns too.)
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. Whereas the second coordinate is the one in which the tray moves only every 10 (or so) steps.
As a final example, the positions on a computer screen that works in usual left-to-right and top-to-bottom direction, the columns would be the first coordinate and the lines would be the second coordinate. (Note however, that this is just an example to clarify the rule. It does not mean that a character displayed on a screen would be an instance of the Material class. In fact, it’s immaterial.)
This attribute specifies how much of the target material is contained in the source material of a relationship. For example, if a box contains 10 eggs, the box is the relationship source is the box and the relationship target is the egg, where the relationship quantity is 10. For mixtures with multiple ingredients, the relationship quantities specify the relative amounts of the ingredients in the mixture (proportion.)
The quantity must be a quantity that specifies an “amount” (refer to Table 34 in Section 2.7.1.10). The amounts specified as the proportion quantity for each ingredient are taken to be numerators over the same denominator. For example, D5W is a mixture consisting Water (H2O) and 5% (= 50 g/L) Glucose (Glc.) The proportions can be either of the following pairs: H2O:1 g + Glc:50 mg; H2O:1 L + Glc:50 g; H2O:500 mL + Glc:25 g; or any combination that amounts to the same concentration of Glucose in Water.
Note that the value of the proportion quantity does not matter as long as the proportion between the ingredients of a substance is kept invariant. If, for example, we specify D5W as having ingredients 500 mL of H2O and 25 g of Glucose this does not mean that D5W could only be dispensed in multiples of 500 mL.
For some transient relationships between material one can specify a time in which the relationship is valid using the Material_relationship.tmr attribute. As with any interval of points in time, a start time, an end time, or a just a duration may be specified.
Material relationships can be of different types, i.e., may express different kinds of relationships. The relationship concepts are exhaustively defined in USAM specification Table 35, that is. The concepts of that table must be used.
Every relationship type implies certain roles for the material at each side of the relationship. The notion of roles in a material relationship is very similar to material roles as defined in Section 2.8 below. Where in Table 35 the roles are so generic that they are not represented as a material role class in the model, that generic role name is printed in italics. Role names in upright font refer to the same concept as represented by the material role class of the same name. In general a material filling that role should be accompanied by the detail defined in the role class, but it is not an absolute requirement. For example, if a material is taken as a container but none of the container-specific attributes are applicable, the instance of the Container role class need not be present.
|
|
|
Class steward is Orders/Observation
Medication is an indirect care-intervention using a material substance 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. Whether or not radiotherapy will be covered by a separate class is open.
Medication as a service indicates the administration of a generic class of medication to a patient. The administration of a particular preparation (in the U.S. typically represented by NDC code) requires the association of the material class with the Medication service. The material information is usually added to the order by the pharmacist when the prescription is filled as a revision or substitution to the original order.
Because medication deploys material substances, a number of attributes arguably pertain to the material rather than the medication action. Therefore, some information may be representable in two ways: as attributes of the medication service or as attributes of the material. This is especially obvious with the kind of substance applied. For example, an Amoxicillin treatment is usually described as Medication.type_cd = Amoxicillin; however, it could also be described as Medication.type_cd = administer with an associated Material target of type Amoxicillin. At this point naming the Service Action after the generic administered substance is the preferred strategy.
This design allow simple medications to be described without having to use the Material class. Only if such actions as dispensing, or such information as the manufacturer are relevant, or if a recipe prescription is written, should one have to deploy the Material class.
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. For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the total daily dose as
dosis_check_qty = dosis_qty (1) * strength_qty (250 mg) * frequency (3 /d) = 750 mg/d.
For the i.v. example above this term would be
dosis_check_qty = dosis_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100 mL/h
which can be calculated on a daily basis as
dosis_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d.
So, in Japan, the denominator of the dosis_check_qty unit must always be 1 /d. In other countries the constraints on the dosis_check_qty may be different or, most likely, the attribute would not be used at all. In any case this dosis_check_qty attribute must not be used to carry any functional information.
The dose is the amount of the therapeutic agent given at one administration event. This attribute can be used all by itself, or in combination with a strength. In theory, 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 dose form of the therapeutic substance. Examples are tablet, capsule, suppository, etc.
OpenIssue: This field must have a mandatory HL7 table for interoperability purpose. Such a table could cover at least 90% of all cases.
With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified. The Medication.rate_qty is specified as a physical quantity in time (a duration.) Hence, the rate_qty is really the denominator of the dose rate. For example, if an Ringer solution is to be given at 100 mL/h i.v., the dosis_qty would be 100 mL and the rate_qty would be 1 h. Note that there is no difference in the actual values of dosis_qty and rate_qty as long as the quotient of both has the same value. In this example, we could just as well specify dosis_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 dosis_qty attribute specifying the rate right in that one attribute (e.g., dosis_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_dosis_qty = dosis_qty x strength_qty / rate_qty.
The route of the medication. Medication route is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise applied to the body. 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, as the table below suggests 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 analyze 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. At this point the version 2.x code table is used.
The strength of a medication is the amount of therapeutic agent per each unit of administration (entitic mass, amount of substance, etc.) If the dose form is continuously divisible (e.g., liquid, gas), the strength is a concentration (volumic mass, amount of substance, etc.)
We generally discourage using this attribute, because in theory, 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.
When the strength attribute is used, the actual administered amount is the product of dose_qty and strength_qty.
|
|
|
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.
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|
The event time attribute allows a significant time for the message to be visible in the outer message envelope.
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|
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 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.
This association indicates a relationship in an HL7 V3 message.
This connection shows the relationship of the acknowledgement to a specific HL7 V3 message
|
|
|
Class steward is Information Management (Medical Records)
A role of a person that authenticates the signature of a party.
The date upon which the person assumed the role of notary public.
The county in which the notary is licensed.
The state in which the notary is licensed.
OpenIssue: Country sub-division might be a term with a more international flavor - might be sorted out with vocabulary and accepted code schemes.
|
|
|
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 are specific information about the observed object. The type and constraints of result values depend on the kind of action performed.
The observation action and observation result are modeled as being the 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 and observation result. So, in merging action with the result, the two codes are now only one.
Derived observations can be defined through association with other observations using relationships of derivation type (Service_relationship.type_cd = derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with an Hemoglobin (HGB) observation (Service_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (Service_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 Service_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.
OpenIssue: The definition of this field's syntax needs to be completed.
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 in the table below.
Kind of observation Data type Notes 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.) 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. 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.) 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. 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. 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. 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.) 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) type to send waveforms in other formats. 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. Bulk text reports ED A detailed procedure report should normally be sent in the attribute Service.descr. The Observation.value should be reserved for computer interpretable or automatically generated information. Note that the Encapsulated Data type (ED) can accommodate formatted text in such common formats as HTML, PDF, or Word Processor formats. The ED data type can also carry dictation that is not yet transcribed. We strongly discourage to send formatted text as result values. At the very least, the formatted text should be broken down into sections, one per sub-service object.
|
|
|
Class steward is Patient Administration
A type of stakeholder. A group of persons organized for some end or work; association. The administrative personnel or apparatus of a business.
The name of an organization.
|GT1^16^00420^Guarantor Employer Name| |GT1^21^00425^Guarantor Organization Name| |IN1^4^00429^Insurance Company Name| |IN1^9^00434^Group Name| |IN1^11^00436^Insured's Group Emp Name| |IN2^3^00474^Insured's Employer Name| |IN2^12^00483^Champus Organization| |IN2^70^00810^Insured Employer Organization Name And ID| |IN3^18^00519^Certification Agency| |LOC^4^00947^Organization Name-LOC| |NK1^13^00202^Organization Name-NK1|
The standard industry class code of the organization.
Class steward is Information Management (Medical Records)
The person who originates (e.g., dictated) a document. The originator may or may not be the same person responsible for authenticating the document.
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
A request for a service to be performed for a specific patient. Rationale: Specializes the request for the patient as a resource. OpenIssue:
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.
The unique identifier of a patient account.
|BLG^3^00236^Account ID| |MRG^3^00213^Prior Patient Account Number| |PID^18^00121^Patient Account Number|
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 authorization number or code received from the insurance company.
|IN1^14^00439^Authorization Information|
A code indicating the status of billing.
|IN1^32^00457^Billing Status| |PV1^41^00171^Account Status|
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|
The date the patient billing account was deleted.
|PV1^35^00165^Delete Account Date|
A code depicting the reason a patient billing account has been deleted.
OpenIssue: Need example values.
|PV1^34^00164^Delete Account Indicator|
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|
A code depicting the purge status of the patient billing account.
OpenIssue: Need example codes.
|PV2^16^00717^Purge Status Code|
The date the patient billing account was purged.
|PV2^17^00718^Purge Status Date|
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|
OpenIssue: This many-to-many association should be resolved with an association class.
OpenIssue: This association and the one between Service and Financial Transaction both come from Service_event. Why is it that they both existed for Service_event? Does the Financial Transaction for the service need to be associated with the same account as the service? Isn't Financial Transaction an associative class between an Account and a billable item (e.g. Service)? How does one distinguish charges to be billed to an account from charges actually billed?
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An 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: This MUST be discussed with Patient Care in the context of Episode and Service Event definitions. Episode and Encounter definitions needs to be discussed.
OpenIssue: The status_cd attribute as the state attribute may not be in the right place in the Gen/Spec tree.
OpenIssue: States of patient encounter (#234).
The date and time range that the patient encounter is valid. Encompasses what is often referred to as admit and discharge date and time.
ExRef: UB92 FL 17, UB91 FL 18
|PV1^44^00174^Admit Date/Time| |PV1^45^00175^Discharge Date/Time|
A code depicting the actual disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical advice, etc.). This attribute and the expected_discharge_disposition_cd attribute use the same table of values.
Rationale: Clarification of definition
|PV1^36^00166^Discharge Disposition|
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.
OpenIssue: PAFM and PC must work together on defining the concept of severity in the model.
Type of further action, if any, planned as part of the care of the patient (e.g., appointment given, appointment to be given, admission arranged, patient admitted, . . .).
A indication that the person is a newborn baby.
|PV2^36^00737^Newborn Baby Indicator|
A code depicting the reason for cancellation of an encounter.
OpenIssue: Need example values.
A code categorizing the encounter at a high level (e.g. inpatient, outpatient, emergency).
OpenIssue: Current x-ref is from Patient Type and Patient Class. Should this be two attributes?
|FT1^18^00148^Patient Type| |PV1^18^00148^Patient Type|
A textual description of the patient encounter.
|PV2^12^00713^Visit Description|
An identifier assigned to the discharge location.
|PV1^37^00167^Discharged to Location|
A code to further categorize the encounter based on site-specific needs (e.g. teaching case, cancer study case).
A code depicting the expected disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical adfice, etc.). This attribute and the actual_discharge_disposition_cd attribute use the same table of values.
Rationale: Clarification of definition
|PV2^27^00728^Expected Discharge Disposition|
A count of the number of insurance plans that may provide Healthcare benefit coverage for this patient encounter.
|PV2^20^00721^Expected Number of Insurance Plans|
The date the patient first experienced a similar illness. Used to determine pre-existing conditions
|PV2^29^00730^First Similar Illness Date|
A code indicating the type of follow-up required after completion of the patient encounter.
OpenIssue: Need example values.
A unique identifier assigned to the patient encounter.
|PV1^19^00149^Visit Number| |PV1^50^00180^Alternate Visit ID|
Text describing the patient valuables left for safe keeping.
|PV2^5^00185^Patient Valuables|
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 indicating the level of publicity allowed for external release about a patient encounter. Examples are general acknowledgement, limited acknowledgement, no acknowledgement. This attribute applies to administrative information.
|PV2^21^00722^Visit Publicity Code|
A code depicting the purpose of the patient encounter.
OpenIssue: Need example values.
An indication that the inpatient encounter is a readmission.
|PV1^13^00143^Readmission Indicator|
A code depicting the type of referral associated with this patient encounter.
OpenIssue: Need example values.
|PV2^3^00183^Admit Reason|
A code depicting the type of referral associated with this inpatient encounter.
OpenIssue: Need example values.
A code indicating the source category associated with this patient encounter.
OpenIssue: Need to clarify description and add example values.
|PV1^14^00144^Admit Source|
A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, VIP courtesies.
|PV1^22^00152^Courtesy Code|
A code depicting the states of the patient encounter (e.g. scheduled, active, discharged).
|PV2^24^00725^Patient Status Code|
The triage classification of the patient during an encounter.
Rationale: This attribute is related to an encounter rather than to the patient in general
A code depicting the urgency of the patient encounter (elective, urgent, emergency).
ExRef: UB92 FL 19
|PV1^4^00134^Admission Type| |PV2^25^00726^Visit Priority Code|
Descriptive text identifying where valuables of patient is located.
|PV2^6^00186^Patient Valuables Location|
OpenIssue: Committee should consider instead adding an association between Patient_encounter and Healthcare_service_provider. Can we find a way to collapse this from 3 to 2 classes.
OpenIssue: This may have to be changed after we figure out what tis "encounter" thing really is.
Rationale: Allows removal of generalization (patient_clinical_item) with single specialization
OpenIssue: Association naming is very broad: "has assigned to" does not say what this assignment means.
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.
This association should not be instantiated if the alternate association to condition mode is instantiated.
Rationale: This association serves the queries "give me encounters which deal with this episode."
OpenIssue: Are we certain that a Patient_encounter can be part of only one Episode of Care? And does an Episode_of_care have to have at least one Patient_encounter, or is this optional?
|
|
|
Class steward is Patient Administration
A release of patient information to a third party.
The data and time of the disclosure.
Free form textual description of the information disclosed.
Free form text description of the requested information.
A code indicating why information about the patient was disclosed.
OpenIssue: Need example values.
Date the disclosed patient information was requested.
A code indicating the priority of the request by a requester.
OpenIssue: Need example values.
Interested committees Information Management (Medical Records)
A role played by the stakeholder. The role of the stakeholder is the recipient of patient information. The stakeholder is the person or organization to whom the patient information is being disclosed.
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Patient Administration
A pool of like-type locations available for scheduling purposes.
OpenIssue:
Unique identifier for the group
OpenIssue:
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Patient Administration
Request information about specific locations that are controlled by a schedule
Rationale: Specializes the request by type of resource
OpenIssue: We must disambiguate the difference between Orders and Schedules
Identifies the role of the resource requested/scheduled for an appointment
Rationale: Creates a separate class for types of equipment
|AIG^3^00897^Resource ID|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Patient Administration
An allocation of time defined when a specific location is available for use for a healthcare service.
OpenIssue:
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
An allocation of time defined when a patient is available to receive a healthcare service.
OpenIssue:
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
A type of stakeholder. An individual human being.
OpenIssue: The status_cd attribute, currently the state attribute, is really the state of the relationship between a Person and an Organization and as such may not be modeled correctly and may not be in the right place. May also be a methodology issue.
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|
Identifies the person's transient state of mobility or factors which impact their state of mobility, e.g., pregnant, ambulates with assistive devices, etc.
Rationale: Enhances the attribute description using existing 2.3 terminology (GT1-34, IN2-32, NK1-18, PV1-15) to provide clarity.
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|
The date and time of a person's birth.
|GT1^8^00412^Guarantor Date/Time of Birth| |IN1^18^00443^Insured's Date of Birth| |NK1^16^00110^Date/Time of Birth| |PID^7^00110^Date/Time of Birth| |STF^6^00110^Date/Time of Birth|
For newborn persons in a multiple birth, the order in which this person was born.
Rationale: field is to contain the ordinal birth position, not a code for the position. V2.3 field is datatype NM.
|PID^25^00128^Birth Order|
The place the person was born.
|PID^23^00126^Birth Place|
The current citizenship of a person.
|GT1^35^00129^Citizenship| |IN2^33^00129^Citizenship| |NK1^19^00129^Citizenship| |PID^26^00129^Citizenship|
The date and time that a person's death occurred.
|GT1^24^00775^Guarantor Death Date And Time| |PID^29^00740^Patient Death Date and Time|
A indication that the person is dead.
|GT1^25^00776^Guarantor Death Flag| |PID^30^00741^Patient Death Indicator|
A code identifying a person's disability, e.g., blindness, deafness.
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.
OpenIssue: Ensure that the values above match the vocabulary submission.
|GT1^37^00742^Living Arrangement| |IN2^35^00742^Living Arrangement| |NK1^21^00742^Living Arrangement| |PD1^2^00742^Living Arrangement|
A code depicting the nature of a dependency that may exist between one stakeholder and another.
OpenIssue: Revisit the definition of this attribute as well as the use cases and possibly the name.
OpenIssue: Need examples.
|GT1^33^00755^Living Dependency| |IN2^31^00755^Living Dependency| |NK1^17^00755^Living Dependency| |PD1^1^00755^Living Dependency|
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: There does not appear to be sufficient separation of the concept carried by this attribute and the similar and possible conflicting information carried in the Stakeholder_affiliation class. It is also 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 person's military branch of service.
OpenIssue: Need example values.
|IN2^14^00485^Champus Service|
The name of a person's military rank.
|IN2^15^00486^Champus Rank/Grade|
The military status of a person.
OpenIssue: Need code schemes.
|PID^27^00130^Veterans Military Status|
A indication as to whether the person is part of a multiple birth.
|PID^24^00127^Multiple Birth Indicator|
A code depicting the nationality of a person.
OpenIssue: Need example values; needs clarification regarding ethnicity or country of origin or citizenship or what?
|GT1^43^00739^Nationality| |IN2^41^00739^Nationality| |NK1^27^00739^Nationality| |PID^28^00739^Nationality|
An indication that the person is an organ donor.
|PD1^8^00760^Organ Donor|
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.
A code indicating the state of a person, e.g., active.
An indication of the person's student status, for example, full-time student, part-time student, etc.
|GT1^40^00745^Student Indicator| |IN2^38^00745^Student Indicator| |NK1^24^00745^Student Indicator| |PD1^5^00745^Student Indicator|
OpenIssue: Is not the person who enters a financial transaction in a specific role? On behalf of an organization? When very loosely coupled systems exchange messages, they'll have to specify the role and accountability, won't they?
OpenIssue: Needs to be re-examined after the LHSR work is completed.
|
|
|
Class steward is Patient Administration
The state of being employed. An occupation by which a person earns a living; work; business.
OpenIssue: Clarify definition. Description mixes state, employed or unemployed; and Occupation. I can have an occupation and still be unemployed.
address of the person's work site.
EXTREF: This information is reported on UB92 FL 66.
|GT1^17^00421^Guarantor Employer Address| |IN1^44^00469^Insured's Employer Address| |NK1^4^00193^Address|
The date the person's employment begins.
|GT1^31^00782^Guarantor Hire Effective Date| |GT1^32^00783^Guarantor Employment Stop Date| |IN2^44^00787^Insured's Employment Start Date| |IN2^45^00783^Guarantor Employment Stop Date|
The type of hazards a person is exposed to in their employment.
A code depicting the employee classification, 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.
OpenIssue: What is the difference in the job class (employee classification table) vs Employment status in GT1-20 and IN1-42?
|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|
This field identifies the person's job status. For example, leave of absence, suspended.
|GT1^53^00752^Job Status| |IN2^48^00752^Job Status| |NK1^34^00752^Job Status|
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|
A code depicting the occupation of the person, 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|
The telephone number of a person at the person's place of employment.
|GT1^7^00411^Guarantor Ph Num-Business| |IN2^64^00804^Insured’s Employer Telephone Number| |NK1^6^00195^Business Phone Number| |PID^14^00117^Phone Number - Business|
Protective equipment needed for employment.
A person's salary amount.
A salary type (e.g., hourly, annual, commission, . . .).
A code depicting the status of the person's employment.
EXTREF: This information is reported on UB92 FL 64.
|GT1^20^00424^Guarantor Employment Status| |IN1^42^00467^Insured's Employment Status|
|
|
|
Class steward is Patient Administration
A name by which a person is or has been known.
OpenIssue: Consider whether class should be for all names with new person name data type, purpose code, context code and time intervals.
The time period during which the person name is applicable.
A name of a human being. Most people will have one name that is currently used.
ExtRef: This information is reported on UB FL 12.
|DG1^16^00390^Diagnosing Clinician| |GT1^3^00407^Guarantor Name| |GT1^4^00408^Guarantor Spouse Name| |GT1^45^00748^Contact Person's Name| |IN1^6^00431^Insurance Co. Contact Person| |IN1^16^00441^Name of Insured| |IN2^7^00478^Medicaid Case Name| |IN2^9^00480^Champus Sponsor Name| |IN2^22^00493^Special Coverage Approval Name| |IN2^49^00789^Employer Contact Person Name| |IN2^52^00792^Insured’s Contact Person’s Name| |IN3^3^00504^Certified By| |IN3^8^00509^Operator| |IN3^14^00515^Physician Reviewer| |IN3^15^00516^Certification Contact| |IN3^21^00522^Case Manager| |IN3^25^00526^Second Opinion Physician| |NK1^2^00191^Name| |NK1^30^00748^Contact Person's Name| |PID^5^00108^Patient Name| |PID^9^00112^Patient Alias|
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.
OpenIssue: This may be a means to identify which name is used by a particular stakeholder.
|
|
|
Class steward is Patient Administration
The "longterm" healthcare relationship between a person (or animal) and a healthcare provider.
A code depicting the nature of publicity protections in place for this person.
|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|
The effective date and time of the association.
The unique identifier by which the healthcare provider organization identifies the patient. In some instances the identifier is issued by the healthcare provider organization (e.g. medical record number); in other instances the identifier is issued by another organization (e.g., US Social Security number).
|PID^2^00105^Patient ID (External ID)| |PID^3^00106^Patient ID (Internal ID)| |PID^4^00107^Alternate Patient ID - PID| |PID^19^00122^SSN Number - Patient| |PID^20^00123^Driver's Licence Number-Patient| |STF^22^00123^Driver's Licence Number-Patient|
The preferred pharmacy of the person.
OpenIssue: This may not be the correct place for this attribute; more work needs to be done. Probably needs to be an association rather than an id.
The current state of the relationship between the patient and healthcare provider association (e.g., active, inactive).
An indication of the person's VIP type, for example, board member, diplomat, etc..
|PV1^16^00146^VIP Indicator|
OpenIssue: Committee should consider instead adding an association between Patient_encounter and Healthcare_service_provider. Can we find a way to collapse this from 3 to 2 classes.
|
|
|
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 Patient Administration
An association between a patient and a healthcare provider. The healthcare provider may be either an individual (e.g., primary care physician) or an organization (e.g., a clinic).
The date that the provider becomes the preferred care provider for the patient.
Rationale: Requested addition to V2.3.1.
A code describing the relationship between the patient and their preferred provider (e.g., internist, pediatrician, or gynecologist when the relationship is to an individual healthcare practitioner; oncology clinic when the relationship is to a healthcare provider organization).
Rationale: This class now contains the attributes of a "master" class; insurance certification is associated with coverage_item.
OpenIssue: This cardinality does not work properly since you can now link to only a single coverage item. This will only work if that linked item is the Parent. This needs to be clarified or modified in some way.
Rationale: A person's PCP can be either a practitioner or a provider organization.
|
|
Class steward is Patient Care
The term "procedure" typically stands for surgical procedures. But the Procedure class covers all direct care activities, whether performed by physicians, nurses, physiotherapy providers, etc.
All procedures other than dermatological has an anatomic site of access or entry and an anatomic site which the procedure is targeted at and that is reached through the entry site. For example an arteria pulmonalis catheter targets a pulmonary artery but the access site is typically the vena carotis interna or the vena subclavia, at the neck or the fossa subclavia respectively.
The coding system is the same as for Service.body_site.
|
|
|
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 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.
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|
Specifies relationship between Response_control and an instance of a Query class.
|
|
|
Class steward is Control/Query/MasterFiles
This class carries information sent with responses to a query.
Specifies number of matches for processed query specification that occur in current bundle of matches.
Specifies number of matches for processed query specification that have yet to be sent to receiver.
Specifies total number of instance matches for query specification associated with this query response instance.
This 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|
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|
Specifies relationship between a Query_ack and an instance of a Query_response_message_type.
Specifies relationship between a Query_ack and Tabular_row_data, which represents a virtual table response of a query conformance statement.
Specifies the relationship between a Query_ack instance and an Acknowledgement 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.
Specifies relationship between Query_by_parameter and an instance of a Query_spec_message_type.
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.
Specifies relationship between Query_by_selectioin and the Selection_criteria classes.
Represents the possibility of nested criteria to be applied to candidate response instances.
Represents the possibility of nested criteria to be applied to candidate response instances.
Class steward is Control/Query/MasterFiles
This abstract class represents TC specified content from the RIM for the query response.
Specifies relationship between a Query_ack and an instance of a Query_response_message_type.
Class steward is Control/Query/MasterFiles
This abstract class represents TC or HL7 implementor-specified elements from the RIM that are to be assigned values as inputs to a data server for a query specification.
Specifies relationship between Query_by_parameter and an instance of a Query_spec_message_type.
|
|
|
Class steward is Orders/Observation
Interested committees Patient Administration
An introduction of a patient from one caregiver to another caregiver or provider institution. The referral may authorize the patient to receive Healthcare services. 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).
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Individual resource request information about various kinds of resources that are controlled by a schedule.
OpenIssue:
A code indicating whether the identified resource can be substituted with an equivalent resource. Sample values are No, Yes with Confirmation, Yes with Notification, Yes.
|AIG^13^00895^Allow Substitution Code| |AIL^11^00895^Allow Substitution Code| |AIP^11^00895^Allow Substitution Code| |AIS^9^00895^Allow Substitution Code|
The duration for which the resource is requested for this appointment, if it is different than the overall duration of the appointment
OpenIssue:
|AIG^11^00893^Duration| |AIL^9^00893^Duration| |AIP^9^00893^Duration| |AIS^7^00893^Duration|
Date and time this resource is requested for the appointment. Either this field or a start_offset_qty must be specified for each resource.
|AIG^8^01202^Start Date/Time| |AIL^6^01202^Start Date/Time| |AIP^6^01202^Start Date/Time| |AIS^4^01202^Start Date/Time|
The offset for this resource is requested for the appointment, expressed relative to the scheduled start date/time of the Appointment. This field indicates that the resource is required for the appointment at a different time than the appointment's.
A code that describes the request status of scheduling a resource or activity within an appointment, from the point of view of the filler application. Sample values: Pending, Waitlist, Cancelled, Blocked, Resource not available.
|AIG^14^00889^Filler Status Code| |AIL^12^00889^Filler Status Code| |AIP^12^00889^Filler Status Code| |AIS^10^00889^Filler Status Code| |SCH^25^00889^Filler Status Code|
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
An allocation of time on a schedule for a resource that must be reserved prior to its use.
OpenIssue:
Number of slots allocated to a given purpose
Offset from start date and time when this allocated use will begin
Type of resource controlled by this set of slots: provider, location, or equipment.
Start date and time for this set of slots
Current status for this set of slots:Booked, Started, Completed, Available, Blocked, Overbooked
OpenIssue:
Links a schedule to its contents.
Rationale: This many-to-many association represents the over-booking of a resoruce slot Patient is just another resource and an appoinment can be booked without including the patient, i.e., a consult. It is not believed that this many-to-many will ever need to be resolved.
|
|
|
Class steward is Control/Query/MasterFiles
This class is used to specify the structure of the response to a query specification.
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|
Defines the timing and grouping of the response instances. References HL7 Table - 0394 - Response Modality for valid values.
Specifies relationship between Response_control and an instance of a Query class.
|
|
|
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|
Specifies relationship between TBL_response_control and an instance of Response_field.
|
|
|
Class steward is Patient Care
Material can have many kinds of relationships with Stakeholders. We subsume all the relationships between material and stakeholders under the notion of Responsibility. The reason being that responsibility for the existence of material, any specific property of material, or performance of functional material (devices) is with some stakeholder. The underlying reason for stakeholder associations to material is that the material is somehow acted upon by the stakeholders. In that sense, one could subsume the Responsibility association under the Service action class. However, just as we chose to represent minor sub-activities around Services as Actors with various actor types, we allow the responsibilities that come from actions of stakeholders to be persistently "coined" on the material.
For example, manufacturing is certainly an activity (Service) with the manufacturer (Organization) as an Actor and the material as a Target of type product. However, in many cases we are not interested in the activity of manufacturing the material, when it took place and what its circumstances were, but what we are interested in is just: who made it? This interest in the manufacturer is chiefly one of responsibility and liability: if the material is different than expected, does not perform well, or does harm, one would probably consider holding the manufacturer liable. Responsibility and liability are concepts that form the very basis of a society based on the law, and emphasis on those terms should by no means imply an undue "legalization" of relationships.
Other relationship types between Material and Stakeholder are: owner, distributor, custodian/holder. All those relationships can be considered to be characterized by responsibilities. This even goes so far as if a human fetus would be considered Material, motherhood (and fatherhood!) would be a type of Responsibility between a Stakeholder (Person) and that fetus. This example shows that responsibility has two aspects: responsibility is not only being held liable by others for malfunctioning, disappointment, and harm caused by the material; responsibility also means an ethical responsibility towards the "material" and even to the extent of being held liable by society for neglect of one’s responsibility towards that "material." This latter kind of responsibility is clearly present between fetus and parent, but also between animal and owner or custodian.
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.
Allows to specify a limitation in time during which the responsibility holds.
Specifies the kind of responsibility of the Stakeholder to the Material.
Concept Implies Code Definition manufacturer MAN Someone bringing a specific material instance into existence, or, if the material is not a specific instance, someone capable of doing so. distributor DST Someone distributing material between a manufacturer and a buyer or retailer. retailer distributor RET Someone selling a material, also giving advice to prospective buyers. transporter TRP Someone in transient possession of a material for the purpose of relocating it. owner OWN Someone to whom law grants the right to call a material his own, which entitles him to make decisions about the disposition of that material. holder HLD Someone who is currently in possession of the material, who holds, or uses it, usually based on some agreement with the owner. trainer TRN Of a companion animal, someone who is training the animal on behalf of the animal’s owner. parent PRN One of the two direct ancestors of a human fetus, in case a fetus is not considered a person. father parent FTH The male parent of a human fetus, in case a fetus is not considered a person. mother parent MTH The female parent of a human fetus, in case a fetus is not considered a person.
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
An occurrence of an event pertaining or attaching to a patient encounter.
OpenIssue: This class carries no association to indicate who documented the incident and when it was documented. Should not this be a special type of event/observation rather than a separate, free-hanging class?
A code depicting the incident type (e.g., body fluid exposure, equipment problem, inpatient fall, medication error, . . .).
The date and time the incident occurred.
A code depicting the potential impact of an incident on the quality of patient care.
OpenIssue: Need code examples.
A code depicting a classification of the incident type (e.g., preventable, user error, . . .).
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
A set of open, booked, and blocked slots for one or more resources.
OpenIssue:
Unique identifier for a Schedule.
|ARQ^5^00864^Schedule ID| |SCH^5^00864^Schedule ID|
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
A parameter/value pair that is used to state scheduling preferences for an Appointment.
Keyword for the parameter that is unique within the parameter type.
|APR^1^00908^Time Selection Criteria| |APR^2^00909^Resource Selection Criteria| |APR^3^00910^Location Selection Criteria|
The dimension of the parameter. HL7 values are: time, location, and equipment.
|APR^1^00908^Time Selection Criteria| |APR^2^00909^Resource Selection Criteria| |APR^3^00910^Location Selection Criteria|
Value of the parameter. This could be any data type, e.g., text, date/time, etc.
|APR^1^00908^Time Selection Criteria| |APR^2^00909^Resource Selection Criteria| |APR^3^00910^Location Selection Criteria|
|
|
|
Class steward is Control/Query/MasterFiles
This class expresses the semantics of query selection criteria as a "where" clause in a structured query language.
Identifies RIM element as subject of selection criteria evaluation.
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|
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|
Specifies relationship between Query_by_selectioin and the Selection_criteria classes.
|
|
|
Class steward is Patient Care
A service is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. A Service instance is a record of such an intentional action. A Service instance is a record of such an intentional action. The terms service, action, activity, and service action are all used interchangeably, but service has been selected as the principle name of this class.
Any intentional action can exist in different "moods." The mood of an action tells whether the action represents a fact (event) an order, a plan (intent), a goal, a risk, a potential (definition) or the like. A service instance represents an action in one and only one such mood. Thus, service definitions (master), orders, plans, and performance records (events) are all represented by an instance of class Service.
Any instance of a Service 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 a service instance is static and not part of the state, not part of the life cycle. The progression of the idea of a service 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 service instance. Related service instances that form such a "business cycle" are linked through the Service_relationship class.
Examples for services 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 kins, notary services, such as advanced directives or living will.
Services have actors and targets. Examples for actors are nurses, doctors, family members, notary publics, and service organizations -- every entity that is capable of independent decisions and can thus be responsible (and liable) for the actions performed.
Target participants 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.)
A service_event can have multiple active participants and multiple target participants, their specific role is distinguished in the "type_cd" of the respective instance of the participation class. In particular, a service event 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).
A service includes the "results," "answers" or informational "procedure products" gained during the service. In this model, "results" do not exist without a service, and every clinical result, including those results gained accidentally, are service events. 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.) The timing of actions is a very important concept that is explained in greater detail in USAMP-II part A, Section 2.5.3.
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.
Most health care services have a focus on a particular anatomic structure of the patient (the "target" of service.) This information is found in body_site_cd. The coding system to be used for anatomic site is not specified in detail. Anatomic sites, body parts, and functional body systems are huge and highly complex domains that require a very sophisticated terminology system. Candidates are Galen, SNOMED, or Read codes. Alternatively, a simple local coding system can be used to identify exactly the common body sites used.
Some body 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 administrative body sites (i.e. where medications are administered) HL7 used to define a table (0163) that must be used as defined in Table 4 below.
This is a code that limits the disclosure of information about this service. The codes refer to confidentiality policies as listed in the normative table [see USAMP-II document]
Confidentiality policies may vary from institution to institution and not all systems are capable of abiding by all details of the confidentiality policies suggested 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 can not 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 Zidovudin 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.
A similar confidentiality code attribute is therefore required in the Patient class to cover the entire patient record. But this is outside the scope of the present proposal.
The flags HIV, PSY, ETH, and SDV may only be used on service items that are not patient related. Typically, they are used in the service definition object ("master" service) to indicate a generic disclosure policy of any actual service item of that type.
Aggregations of data should assume the privacy level of the most private action in the aggregation.
This is the "biologically relevant" time of an action. The concept is best understood with observations, where 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. For surgical procedures the time between first cut and last suture is taken as the critical time of the procedure. For transport and supply services the critical time is the time en route or time of delivery respectively. Critical time and total time of a service may often be related in a certain way, which will be discussed in USAMP-II Part A, Figure 10.
This is an instance identifier of a particular Service object. For example, whenever a service is carried out, there is a new service object instantiated with an identifier that uniquely distinguishes this service object from every other service object.
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."
Indicates whether a service is interruptible by asynchronous events (such as "through"-conditions to turn false, or time running up.) See discussion on activity plans in the USAMP-II document, part A.
This is the maximum number of repetitions of a service. 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 USAMP-II specification, part A, on how specifically this is used.
For any service 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 thorroughly (e.g., blood pressure method: arterial puncture vs. Riva-Rocci, sitting vs. supine position, etc.) Method concepts can be "pre-coordinated" in the Service definition, so that there is never an option to select different methods. Pre-coordinating methods into the service code (type_cd) avoids having to standardize on method codes. 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 close to impossible. The pre-coordinated approach avoids relying on the impossible to be done.
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 (Service.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.
Although the authors of this proposal believe that the pre-coordinated approach to methods goes a long way and should be followed as far as possible, the same information structure can handle both the pre-coordinated and the post-coordinated approach.
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 USAMP-II model, where the service 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. The mood code is critical to the design of this model. Without the mood_cd, the model above would be at least three times as big, in order to distinguish service events, from orders, schedules, goals, and master service items.
One of the "infinitive" moods is used for describing potential services 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 indicates whether this service can be requested independently from other services. Some services can only occur as subordinate to a super-service; others are abstractions of services or service groups that should not be ordered in one piece. Since in principle everything that can be done can potentially be requested, this attribute is true by default. It is usually only used for master file definitions.
This attribute encodes the urgency under which the service 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 service, which is used to determine the charge. In master service definitions it indicates the available priorities.
A code for the kind of action (e.g., physical examination, serum potassium, etc.), used to be called "universal service identifier". The Service.type_cd specifies the service conceptually by using a code from a code system. We often refer to the Service.type_cd as the "name" of the Service. In any case, the type_cd or "name" is a handle on the concept of the action, not on the individual action instance.
Different code systems cover different kinds of services, which is why there is not one single code system to be used for the Servcie.type_cd. Furthermore, the data type Concept Descriptor (CD) allows the action to be named by multiple code systems at the same time, whereby each term from a coding system is assumed to be a synonym. For example, a Thrombectomy service may be named "34001" using the CPT-4 code, "P1-30322" in SNOMED, or "38.00" in ICD-10-PCS.
The state of the action (e.g., newly ordered, in process, completed.) The state is communicated in coded form. The codes are strictly defined by the state-transition model of a service class. No alternative coding system can be used for the status_cd attribute (CNE, coded no exceptions.)
OpenIssue: No particular State-Transition model has been included in this specification as of yet. Various state transition models have been proposed in the orders committee in the past (although these have never been reconciled.) This proposed model understands that, in principle, it must (and can) accommodate any state-transition logic that has been defined using the previous model. In particular, the extensive merging of classes and the mood code attribute do not impact the scope and definition of currently proposed state-transition models.
Indicates whether an ordered or intended service may be or has been substituted for a different service. 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 Service.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.
The description of a service is a piece of free text or multimedia data that describes the service in all necessary detail. There is no restriction on length or content imposed on the description 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 specially interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects.
Note that the description attribute is not a service "name." All names of the service can be communicated in the Service.type_cd attribute as codes together with readable print-names.
As with any attribute of class Service, the meaning of the description attribute is subject to the Service.mood_cd. For service definitions, the description can contain textbook like information about that service. For service orders, the description will contain particular instructions pertaining only to that order. Filler order systems must show the description field to a performing provider.
For Service records of actual services (Service.mood_cd = actual,) the description is an important part of the documentation. The description will contain textual reports on the service. This is true for any service, in particular for surgical procedures, where the description attribute is the place to put the entire surgery report. If the surgical procedure is reported as multiple interrelated Service instances, each instance may contain the part of the report pertinent to that step of the procedure. However, there is no need to break a service report apart into sub-services only to break the textual report apart into multiple sections. The Encapsulated Data type is capable of handling formatted textual reports in HTML, PDF, or word processor formats. In addition, the HL7 PRA working group defines standards to use XML as a markup language for report documents.
Note that textual reports should always be sent in the Service.descr; this includes reports of observation services. The Observation.value field is reserved for information that is processed automatically and that is accessible to automated processes. Human authored free text reports are not easily accessible to automated processing, which is why they should be communicated in the Service description attribute. Of course, free text documents can be analyzed by natural language parsers and similar tools. We encourage that any output of such natural language parsers be communicated in the Observation.value attribute in the form of structured machine accessible data. Since narrative text and observation value are in different attributes, they can be communicated together, without interfering with each other.
OpenIssue: The descriptive text for this attribute needs to be revised for clarity and consistency.
OpenIssue: This association and the one between Service and Financial Transaction both come from Service_event. Why is it that they both existed for Service_event? Does the Financial Transaction for the service need to be associated with the same account as the service? Isn't Financial Transaction an associative class between an Account and a billable item (e.g. Service)? How does one distinguish charges to be billed to an account from charges actually billed?
OpenIssue: could the coverage_item be applicable for actual services (event) too? Use case: a service was done on the basis of an emergency indication without any prior knowledge to coverage. A request is sent to a billing system or insurance, asking whether this actual service was covered and in what way it was covered?
OpenIssue: This many-to-many association should be resolved.
OpenIssue: Association names are not descriptive of what this association means. There is currently no way to describe fees for services in a master file. The issues of fees, fee schedule and their relationship to actual charges need to be modeled. Or does the assoication between RIM092.Master_service and Coverage_item allow to assign different fees to the same master service?
OpenIssue: Association naming is very broad: "has assigned to" does not say what this assignment means.
|
|
|
Class steward is Orders/Observation
All people, things and locations involved in a Service (or for scheduling purposes "all resources of an activity") are associated with the Service 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 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.
This attribute describes the business function of an actor in more detail. It can accommodate the huge variety and nuances of functions that actors 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.
Examples for function types are shown in the following table. The data type of this field also allows just a simple uncoded textual description to be sent.
Example concepts for the service- and site-specific functions of actors are (Function|Actor.type_cd|Definition) primary surgeon |performer |In a typical surgery setting the primary performing surgeon. first assistant assistant performr In a typical surgery setting the assistant facing the primary surgeon. The first assistant performs parts of the operation and assists in others (e.g., incision, approach, electrocoutering, ligatures, sutures.) second assistant |assistant performer |In a typical surgery setting the assistant who primarily holds the hooks. scrub nurse |assistant performer |In a typical surgery setting the nurse in charge of the instrumentation. third assistant assistant performer In a typical surgery setting there is rarely a third assistant (e.g., in some Hip operations the third assistant postures the affected leg.) nurse assistant |witness |In a typical surgery setting the non-sterile nurse handles material supply from the stock, forwards specimen to pathology, and helps with other non-sterile tasks (e.g., phone calls, etc.) anesthesist performer In a typical anesthesia setting an anesthesiologist or anesthesia resident in charge of the anesthesia and life support, but only a witness to the surgical procedure itself. To clarify responsibilities anesthesia should always be represented as a separate service related to the surgery. anesthesia nurse |assistant performer |In a typical anesthesia setting the nurse principally assisting the anesthesiologist during the critical periods. midwife |performer or assistant performer |A person (usually female) helping a woman deliver a baby. Responsibilities vary by locale, ranging from a mere assistant to a full responsibility for (normal) births and pre- and post-natal care for both mother and baby. Note that the Service_actor.function_cd designates the actual function performed in the service. This is quite different from a role associated with a person or a profession- or specialty-code, although, some of the Service_actor.function_cd concepts may suggest that they are the same. While a person’s role, a profession code, or a specialty code may signify a general capability and authority of that person, an Service_actor.function_cd rather represents a part or sub-task of the associated service activity. Most notably the function performing surgeon is not necessarily filled by a certified surgeon, but in many cases by a resident (in which case an attending surgeon is designated as the supervising actor.) The same is true for the anesthesist who doesn’t have to be an "anesthesiologist" and will in most cases be a resident.
An actor can make a comment about this service item in the note attribute.
Some Actors must provide a signature on the service instance. For example, a procedure report requires a signature of the performing and responsible surgeon. Or a consent requires the signature of the consenter. This attribute allows to specify whether or not such a signature is on file, it does not itself provide evidence for the signature.
required X A signature for the service is required of this actor. signed S A signature for the service is on file from this actor.
In today’s environment, with the advent of digital signatures, this treatment appears to be insufficient. We will continue to work on integrating this to a framework of digital signatures. However, there are severe technical obstacles to overcome: digital signatures do not exist over abstract information. Only concrete bit-representations of information can be signed. Since HL7 version 3 tries to separate abstract information from bit-encodings, it is not clear how such a digital signature could exist.
We are aware of the X.509 approach of Distinguished Encoding Rules (DER), but there is currently no definition for encoding HL7 data structures in DER, nor does it seem like the industry prefers DER as the principle message encoding rules. Furthermore, there needs to be a framework to integrate traditional paper-based signatures as well. Hence, we acknowledge that the Actor class may be the principle point of implementing electronically authenticated medical records, but we defer the elaboration of this approach to later.
This attribute can specify the time range during which the associated person was an actor of the specified Actor.type_cd in the associated service. This may be needed when the actor’s involvement spans only part of the service, and if this fact is worth mentioning. The Actor.tmr does not need to be used in cases where this detail is irrelevant.
Identifies a particular function or a set of functions that a person or ogranization performs in the Service. In practice, there are very many different actor types whose names and responsibilities vary. The number and kinds of involved actors also depend on the special kind of service. We attempted to define a few orthogonal axes along which actor types could be defined more regularly. For example, one axis would be physical performance of the action, another axis would be responsibility for the action, yet another would be authoring the information in the service object. An actor can have one or more of these functions to a certain degree. However, the business semantics of these functions is too variant to be mathematically analyzed. For this reason, we split the coding of the kind of actor’s involvement into two attributes. The Actor.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 Actor.function_cd is a mostly locally defined descriptor for the kind of professional activity carried out by the actor. Actor type concepts are (Concept |Code |Definition) [Performers, physically acting persons] performer |PRF |REQUIRED for every service event. A person who actually and principally carries out the action. Need not be the principal responsible actor, e.g. a surgery resident operating under supervision of attending surgeon, and may be the patient in self-care, e.g. fingerstick blood sugar. The traditional order filler is a performer. assistant performer |ASS |A person assisting in a service through his substantial presence and involvement This includes: assistants, technicians, associates, or whatever the job titles may be. escort |ESC |Only with Transportation services. A person who escorts the patient. [Authors and originators of information] author |AUT |REQUIRED for every service. A person who originates and takes responsibility for the information given in the service object, e.g., the report writer, the person writing the service definition, the guideline author, the placer of an order etc. data entry person |ENT |A person entering the data into the originating system. The data entry person is collected optionally for internal quality control purposes. informant |INF |A source of reported information (e.g., a next of kin who answers questions about the patient’s history.) For history questions, the patient is logically an informant, yet the informant of history questions is implicitly the subject. call-back contact |CBC |A contact (often not individual) to whom immediate questions for clarification should be directed (e.g., a care facility to be called by phone number.) [Signatures people having accountability without being physical actors] supervisor |SPV |A person who is legally responsible for the service carried out by a performer as a delegate. A supervisor is not necessarily present in an action, but is accountable for the action through the power to delegate, and the duty to review actions with the performing actor after the fact (e.g. head of a biochemical laboratory.) verifier |VRF | A person who verifies the correctness and appropriateness of the service (plan, order, event, etc.) and hence takes on accountability. witness |WIT |Only with service events. A person witnessing the action happening without doing anything. A witness is not necessarily aware, much less approves of anything stated in the service event. Example for a witness is students watching an operation or an advanced directive witness. consenter |CNS |The person giving consent to the service (usually the patient himself or a legal guardian.) A consenting person is an actor in the sense of asking or delegating an action to happen upon himself. reviewer REV A person reviewing the details of a service (order or documentation) after the fact. [Additional information recipients] referrer |REF |A person having referred the subject of the service to the performer (referring physician.) Typically, a referring physician will receive a report. tracker |TRC |A person who receives copies of exchange about this service (e.g., a primary care provider receiving copies of results as ordered by specialist.) An actor can do multiple of such functions identified by the Actor.type_cd at the same time. This can be represented using multiple Actor-instances each with a different Actor.type_cd value but relating to the same Stakeholder.
|
|
|
Class steward is Patient Care
A service list is owned by one and only one Stakeholder, which may be an individual, or organization (e.g., care team.) A Stakeholder can have multiple service lists. Each service list has a subject, i.e., a material (e.g. today’s schedule for operating room 12a,) or a patient (patient’s problem list) or another person. If the service list has no subject but just an owner, the owner is considered the subject. Thus, any stakeholder can maintain personal to-do lists, diaries, logbooks, etc.
A description of this list. This may be considerable amount of text that explains what the list is for and how it is used. This is especially relevant if the owner is an organization or work group.
Identifiers for the service list.
A short name that the owner of the list chooses to find this list among others. The name must be unique among all the lists that the stakeholder owns.
Code identifying the kind of service list. Refer to the following Table for defined list types.
Concept Implies Code Definition schedule SCH A work-list, a schedule, or a personal to-do list of items intended to be done. logbook LOG A diary of past services. issues ISS A collections of any kinds of services as issues that need to be resolved. problem list issues PRB A patient’s problem list as seen by a particular provider.
|
|
|
Class steward is Patient Care
A list item represents one service on a service list. It holds sequence and priority numbers to establish the list-specific ordering of the service.
A note may be attached to each list. Since stakeholder owned lists are not part of the medical record, these notes are private notes of the list owner and are not subject to the rules of auditing and archiving that apply to medical record items.
Items in the list can be ranked by priority. This is used to help deciding which item to address next when the items are not sequenced.
The items of the list can be sequenced using this attribute. It is a real number in order to allow dynamic insertion without having to renumber all the items every time an insertion or deletion is made.
|
|
|
Class steward is Orders/Observation
The Service relationship class is a recursive associative class with two associations to the Service class, one named "source" the other named "target". Consider every Service_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 Service are different as specified in Table 13 below.
In principle the assignment of functions (roles) to each side of the relationship "arrow" is completely arbitrary. However since a service is the core element of a medical record, proper attribution of the medical record items is an important issue. The relationships associated with a Service are considered properties of the source service object. That means, that the originator of the information reported in a service 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 service relationships are attributed to the responsible actor of the Service at the source of the Service_relationship (the "source service".)
With this recursive service 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.
Actions may also be grouped longitudinal, in a sequence of sub-actions to for temporal and conditional (non-temporal) action paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).
Actions may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections of actions 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 relationship class is not only used to construct action plans but also to represent clinical reasoning or judgements 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 judgements about clinical events are represented by the service relationship link too.
The Service_relationship.type_cd identifies the meaning and purpose of every service relationship instance.
Indicates when associated pre-conditions are to be tested. The following values are defined:
entry S= Condition is tested once before the service is executed (IF condition THEN service). beginning B= Condition is tested every time before execution of the service (WHILE condition DO service.) end E=Condition is tested at the end of a repeated service execution. The service is repeated only if the condition is true (DO service WHILE condition.) throughT= Condition must be true throughout the execution and the service is interrupted (asynchronously) as soon as the condition turns false (asynchronous WHILE loop.) The service must be interruptible. exit X= Condition is a loop checkpoint, i.e. it is a step of an activity plan and, if negative causes the containing loop to exit.
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 the relationship type 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 services, 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: a service 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 service swap their roles, that is, the reason and the suggested action swap their roles, so that cholecystectomy can be the source and colelithiasis can be the target. Note that the attribution rule is always unchanged, i.e., the service 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.
Concept Code Definition wait W Wait for this branch to terminate. kill K When all other concurrent branches are terminated, interrupt and discontinue this branch. exclusive wait X Wait for any one of the branches in the set of exclusive wait branches to terminate, then discontinue all the other exclusive wait branches. detached D Detach this branch from the other branches so it will not be resynchronized with the other branches.
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. We thus say the "condition is true" even if the test was negative if the negation_ind is true.
The time that should elapse after this activity has got clearance to execute and the actual begin of execution. Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the service is executed after its pre-conditions become true.
This integer number allows to specify another kind of ordering amongst the outgoing relationships of a service. This is used to represent the priority ordering of conditional branches in service 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 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 a service. 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 service 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 services 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. The values are defined as follows:
exclusive try once E1=The pre-condition associated with the branch is evaluated once and if true the branch may be entered. All other exclusive branches compete with each other and only one will be selected. This implements a COND, IF and CASE conditionals, or "XOR-split." The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
exclusive wait EW= A branch is selected as soon as the pre-condition associated with the branch evaluates to true. If the condition is false, the branch may be entered later, when the condition turns true. All other exclusive branches compete with each other and only one will be selected. Each waiting branch executes in parallel with the default join code wait (see below.) The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
inclusive try once I1=A branch is executed if its associated preconditions permit. If associated preconditions do not permit, the branch is dropped. Inclusive branches are not suppressed and do not suppress other branches.
inclusive wait IW=A branch is executed as soon as its associated conditions permit. If the condition is false, the branch may be entered later, when the condition turns true. Inclusive branches are not suppressed and do not suppress other branches. Each waiting branch executes in parallel with the default join code wait
Determines the meaning of a relationship between two Services. This attribute is probably the most important attribute in this entire model besides the Service.mood_cd. It is a "structural" attribute inasmuch as each of its values implies specific constraints to what kinds of Service objects can be related and in which way. Refer to the USAM specification document for defined service relationship types and examples of their use.
|
|
|
Class steward is Inter-Enterprise (ADT/Finance/Inter-Enterprise)
Interested committees Orders/Observation
Request information about various kinds of services that are controlled by a schedule.
OpenIssue: Should services be handled separately from resources? Make certain that resource requests for scheduling are different from ordered service requests in Orders.
OpenIssue: The definition does not encompass notifications (where it is not a request).
A code indicating whether the identified service can be substituted with an equivalent service. Sample values are: Yes; No; Yes, but confirm; Yes and notify.
OpenIssue: Also, should this be a Boolean (_ind) rather than _cd?
|AIG^13^00895^Allow Substitution Code| |AIL^11^00895^Allow Substitution Code| |AIP^11^00895^Allow Substitution Code| |AIS^9^00895^Allow Substitution Code|
The duration for which the service is requested for this appointment, if it is different than the overall duration of the appointment
|AIG^11^00893^Duration| |AIL^9^00893^Duration| |AIP^9^00893^Duration| |AIS^7^00893^Duration|
Date and time this service is requested for the appointment.
|AIG^8^01202^Start Date/Time| |AIL^6^01202^Start Date/Time| |AIP^6^01202^Start Date/Time| |AIS^4^01202^Start Date/Time|
The offset that this service is requested for the appointment, expressed in units of time relative to the scheduled start date/time of the appointment.
|AIG^9^00891^Start Date/Time Offset| |AIL^7^00891^Start Date/Time Offset| |AIP^7^00891^Start Date/Time Offset| |AIS^5^00891^Start Date/Time Offset|
A code that describes the request status of scheduling a service, from the point of view of the filler application.
OpenIssue:
|AIG^14^00889^Filler Status Code| |AIL^12^00889^Filler Status Code| |AIP^12^00889^Filler Status Code| |AIS^10^00889^Filler Status Code| |SCH^25^00889^Filler Status Code|
|
|
|
Class steward is Orders/Observation
Target is an associative class linking physical entities, including humans, other living subjects and inanimate material to the Service. The targets of a Service are like the objects and adverbial phrases of a verb in a sentence. This include direct objects (the things subjected to the action), indirect objects (e.g., beneficiary), and adverbials (e.g., means, location.)
Every target object is linked with the Service through a target instance. The target has a type_cd that identifies the function (or role) played by the target in the service. In the natural language analogy, the type_cd provides the case of the object and the preposition of an adverbial phrase.
The Target class maintains a choice to link to either a Person or a Material as its substance.
For person targets 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. For other than person targets this attribute is not applicable and shall not be valued.
This is the time range in which the associated person or thing was a target of the specified Target.type_cd in the associated service.
Just as with actors, different participation types can be identified for targets. By "target" of an action we basically mean objects of a verb. Objects appear in different cases: direct objects, indirect objects or adverbial objects according to their roles in a sentence. Target participation type codes distinguish those different roles. For instance, patient, guarantor, custodian, or family members are examples of target participation types. These are in the role of direct target on whom (accusative) or the indirect beneficiary (on behalf of whom) the service action is performed. In addition any material, specimen, device, or location used or produced by a service is a target of the service.
|
|
Class steward is Patient Care
According to Webster’s dictionary, a specimen is "an individual, item, or part considered typical of a group, class, or whole" or "a portion or quantity of material for use in testing, examination, or study." In the practice of clinical medicine and especially in previous HL7 specifications, specimen was tightly related to the container which holds the specimen. However, there is an important difference between a container and a specimen. Through the material class with roles for both specimen and container one can manage containers separately from specimen. With the same class one can manage empty specimen containers (material management) the same way as the container filled with specimen.
Body site has been retained as an attribute of the specimen, since it may be relevant in some cases, e.g., if multiple liver needle biopsies are taken from different lobes and locations of the liver. The value of the Specimen.body_site_cd should be identical to the value of the Service.body_site_cd of an associated specimen collection service. This attribute therefore is used only if such an associated specimen collection service is not communicated. When the rule is to always send a specimen along with a record of the specimen collection service, this attribute needs not be valued.
OpenIssue: Should this be a subtype instead of a role relationship?
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
A person or organization that has an investment, share, or interest in healthcare.
OpenIssue: The implications of declaring this an abstract class on the methodology are unclear.
The address of a stakeholder.
|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|
A code depicting the credit rating of a stakeholder.
OpenIssue: Need code examples.
|GT1^23^00774^Guarantor Credit Rating Code| |PV1^23^00153^Credit Rating|
The email address of a stakeholder.
OpenIssue: This should be treated as part of more general_com attribute type.
A unique identifier of a stakeholder.
The phone number of a stakeholder.
OpenIssue: This should be treated as part of more general_com attribute type along with the e-mail address.
|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|
A code depicting the type of stakeholder (e.g., person, organization, . . .).
|GT1^10^00414^Guarantor Type|
OpenIssue: This may be a means to identify which name is used by a particular stakeholder.
This relationship allows the originating organization for an HL7 V3 message to be identified
|
|
Class steward is Patient Administration
A person or organization which has an affiliation with another stakeholder.
OpenIssue: What is the distinct function of this class in contrast to stakeholder affiliation? The need for two classes is not at all obvious from the existing descriptions.
A code indicating the familiar relationship that exist between the affiliated [person-]stakeholders (e.g., brother, sister, parent, spouse, . . .).
|GT1^11^00415^Guarantor Relationship| |GT1^48^00784^Contact Relationship| |IN1^17^00442^Insured's Relationship to Patient| |IN2^62^00802^Guarantor’s Relationship To Insured| |IN2^72^00811^HCFA Patient Relationship to Insured| |NK1^3^00192^Relationship|
|
|
|
Class steward is Patient Administration
Interested committees Orders/Observation
A association between one stakeholder and another.
OpenIssue: What is the distinct function of this class in contrast to stakeholder affiliate? The need for two classes is not at all obvious from the existing descriptions.
A code indicating the nature of the affiliation between the associated stakeholders (e.g., employer, emergency contact, next of kin, . . .).
|GT1^11^00415^Guarantor Relationship| |IN2^11^00482^Dependent of Champus Recipient| |NK1^7^00196^Contact Role|
Description of the stakeholder affiliation.
The date the affiliation between the associated stakeholders begins.
|IN2^55^00795^Relationship To The Patient Start Date| |IN2^56^00796^Relationship To The Patient Stop Date| |NK1^8^00197^Start Date| |NK1^9^00198^End Date|
Class steward is Patient Care
Supply orders and deliveries are very simple services that mainly focus on the delivered product. The product is associated with the supply service as a Material target of type product (PRD). 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 (Target.type_cd = product.) With general supply orders the precise identification of the Material, its manufacturer, serial numbers, etc. is important, and supply services are only very marginal parts of the electronic patient record. Therefore, most of the detail information about the supply should be represented using the Material class.
Note that if delivery needs to be scheduled, tracked, and billed separately, one can associate Transportation services with the supply.
Pharmacy dispense services are represented as supply services, associated with a medication service. The medication class represents the administration of medication, while dispensing is supply.
Specifies the quantity ordered or supplied (depending on the mood_cd.) This is a physical quantity (PQ) that must be from a constrained set of extensive "amount" kind of quantities. Refer to Section 2.7.1.10 for a definition of such "amount" quantities.
Class steward is Control/Query/MasterFiles
This abstract class represents a row of data as specified by a query conformance statement with a virtual table response.
Specifies relationship between a Query_ack and Tabular_row_data, which represents a virtual table response of a query conformance statement.
Class steward is Control/Query/MasterFiles
This class holds the specification of a virtual table response to a query specification.
Specifies relationship between TBL_response_control and an instance of TBL_sort_control.
Specifies relationship between TBL_response_control and an instance of Response_field.
|
|
|
Class steward is Control/Query/MasterFiles
Holds specification of sort order in virtual table query response mode.
Specifies sequence of sort order. Refer to HL7 Table 0390 - Sequencing for valid values.
Identifies column of virtual table of query response.
Specifies relationship between TBL_response_control and an instance of TBL_sort_control.
Class steward is Control/Query/MasterFiles
This abstract class represents TC specified content in a declarative or imperative HL7 V3 message.
This association indicates a relationship in an HL7 V3 message.
Class steward is Orders/Observation
A therapeutic agent is anything that is brought to interact with the human body in order to achieve therapeutic effects.
OpenIssue: Currently there are no attributes of therapeutic agent 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 therapeutic agents obvious. If there are no properties defined for this class by September 2000 it will be deleted from the model.
Class steward is Information Management (Medical Records)
This field identifies the person transcribing the document. This is a conditional value; it is required on all transcribed documents.
Rationale: TXA - 11(00924)
OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.
OpenIssue: This association would appear to be mandatory from Transcriptionist to document header, since the transcriptionist instance (a role class) is not otherwise needed.
OpenIssue: Review cardinality.
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.
|
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 LIST<ADXP> : List_ADXP LIST<PNXP> : List_PNXP ON : OrganizationName |
PN : PersonNameType PNXP : PersonNamePart ST : CharacterString |
|
ANT : Annotated BAG : Bag EIVL : EventRelatedPeriodicIntervalOfTime HIST : History HXIT : History_item IVL : Interval IVL<TS> : Interval_of_time LIST : Sequence LIST<ADXP> : List_ADXP LIST<BL> : List_of_Boolean LIST<CR> : List_CR LIST<INT> : List_INT LIST<PNXP> : List_PNXP NPPD : NonParametricProbabilityDistribution PIVL : PeriodicIntervalOfTime PPD : ParametricProbabilityDistribution |
SET : Set SET<AD> : Set_Address SET<CV> : Set_CV SET<HXIT<T>> : Set_of_HXIT SET<II> : Set_of_II SET<INT> : Set_INT SET<OID> : Set_OID SET<ON> : Set_ON 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<TS> : Interval_of_time LIST<ADXP> : List_ADXP LIST<BL> : List_of_Boolean LIST<CR> : List_CR LIST<INT> : List_INT LIST<PNXP> : List_PNXP SET<AD> : Set_Address SET<CD> : Set_CD SET<CS> : Set_CS SET<CV> : Set_CV |
SET<HXIT<T>> : Set_of_HXIT SET<II> : Set_of_II SET<INT> : Set_INT SET<OID> : Set_OID SET<ON> : Set_ON 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 : EncodedData |
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.
|
|
|
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.)
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.
A code identifying the type of identifier. For example, codes to represent the US National Provider ID, US National Payor ID, US Health Care ID, medical record number, social security number.
The purpose of these identifier types is to provide some guidance for use to applications. However, no complete terminology of identifier types exists, and it is unlikely that it will ever exist (identifier "types" depend on the information model, and local practices.) Most processing logic should depend on the assigning authority. For example, to find a U.S. Social Security Number, one should look for the OID defined by HL7 for the U.S. Social Security Administration.
Open Issue: This property needs a value domain, which is probably very hard to define. If this property does not have a satisfactory reasonable value domain by summer of 2001, it will be deleted.
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 is essentially a character string, extended with a tag that indicates what kind of organization name it is.
A code identifying what an orgnization name is used for. It is "coded no exceptions", with the following mandatory table (from HL7 v2.3 XON):
L - Legal
A - Alias
D - Display
ST - Stock exchange
|
|
|
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.
A person name data value specifies one full name of a person. A name such as "Jim Bob Walton, Jr." is one instance of the person name type (PN). The parts of this name "Jim", "Bob", "Walton", and "Jr." are person name parts (PNXP). A person name is simply a list of person name parts.
Person names have no additional properties that add information to the sequence of person name parts. The property "formatted" has a character string value with the formatted person name.
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 name. It would not usually be implemented as a variable to which one could assign a formatted person name. 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.e.
Person names are sequences of character string tokens that may have a tag signifying the role of the token. Typical name parts that exist in about every name are given names, and family names, other part types may be defined culturally.
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
Note: a person may have multiple names as defined through the RIM class Person_name, which is outside the scope of this specification.
A person name name part has a type, such as given name vs. family name and name of public records vs. nickname. The type code may not be available for unknown person names.
Example: would you know what is the given name and what is the family name in "Rogan Sulma"?
|
|
|
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.
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.
|
Appointment Episode Individual_healthcare_practitioner_request |
Living_subject Patient_service_location_group Patient_service_location_request |
Patient_service_location_slot Referral |
|
Patient_information_recipient |
|
Consent Master_patient_service_location Material |
Observation Patient_encounter |
Service_scheduling_request Transportation |
|
Document_service |