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-95 20000426
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.
|
Acknowledgement Attention_line |
Batch Document_service |
Message |
|
Bad_debt_collection_agency |
Insurer |
Organization |
|
Administrative_patient_accident Administrative_patient_death |
Disability Patient |
Patient_information_disclosure Patient_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 |
|
Acknowledgement Attention_line |
Batch Document_service |
Message Stakeholder |
This draft HL7 Reference Information Model (RIM) is the result of the seventh HL7 RIM harmonization cycle. RIM change proposals from several HL7 Technical Committees were reviewed and acted upon during a RIM Harmonization Meeting held March 23, 2000 in Salt Lake City, UT. Technical Corrections have not been applied.
This version of the HL7 RIM is being provided to the Technical Committees and Special Interest Groups of HL7 for review and technical corrections. Comments on this model should be addressed to the co-chairs of the Methodology and Modeling Committee and/or sent to the M&M e-mail list at mnm@lists.hl7.org
|
|
|
Class steward is Patient Care
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
|
|
|
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 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|
The scheduled appointment’s timing and quantity as scheduled by the filler application.
|SCH^11^00884^Appointment Timing Quantity|
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.
OpenIssue: Clarify definition. What is the relationship between the appointment and the notification event? It is difficult to distinguish the idea of the appointment reason and the event reason. Also, I see event reason and cancellation date. Don't seem consistent.
|SCH^6^00883^Event Reason|
Text providing the service(s) expected to be provided in the scheduled encounter.
The scheduled date and time for the start of an appointment.
A unique identifier assigned to an appointment.
|ARQ^2^00861^Filler Appointment ID| |SCH^2^00861^Filler Appointment ID|
Code describing the status of the appointment with respect to the filler application. Sample values: Booked, Started, Complete, Cancelled, Discontinue, Deleted, Overbook.
|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.
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.
OpenIssue: This may have to be changed after we figure out what tis "encounter" thing really is.
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|
Parameters and preferences regarding the selection of an appropriate resource for an appointment. The first component of this field is a code identifying the parameter or preference and the second component is the actual data value for that parameter.
OpenIssue: Add v2.3 enumerated data if any exits. Review to determine whether or not there is a structure that needs to be more explicitly represented.
|APR^2^00909^Resource Selection Criteria|
Actual times referenced by the repeat pattern in Appointment_request.repeat_pattern_expr in cases where the actual administration times vary within an institution.
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|
Parameters and preferences regarding the selection of an appropriate location for the appointment.
OpenIssue: Add v2.3 enumerated values if any exist. Review to determine whether or not there is a structure that needs to be more explicitly represented.
|APR^3^00910^Location Selection Criteria|
The urgency of the request.
OpenIssue:
|ARQ^12^00871^Priority|
The general reason that the appointment is to take place. This code should define either the patient's problem or the general nature of the service. Sample values: CHECKUP, WALKIN.
|ARQ^7^00866^Appointment Reason| |SCH^7^00866^Appointment Reason|
The interval between repeating appointments.
OpenIssue: May require a new data type or attribute group. Talk to CQ about the need for a repeating interval datatype. OpenIssue: Add v2.3 enumerated values if any exist. Review to determine whether or not there is a structure that needs to be more explicitly represented.
|ARQ^13^00872^Repeating Interval|
How long the appointment repetitions should continue, once they have begun.
OpenIssue:
|ARQ^14^00873^Repeating Interval Duration|
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|
Code describing the status of the appointment request. Sample values: Pending, Waitlist, Cancelled, Blocked, Denied.
Parameters and preferences regarding the selection of an appropriate time slot for an appointment.
OpenIssue: Add v2.3 enumerated values if any exist. Review to determine whether or not there is a structure that needs to be more explicitly represented.
|APR^1^00908^Time Selection Criteria|
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
|
|
|
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 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: 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: This many-to-many association should be resolved.
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.
Class steward is Patient Care
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: Review/explain cardinatlity
OpenIssue: The same person can be a contact for more than one patient and a patient can have more than one contact persons.
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.
Duration for a single schedulable unit in a schedule for a resource.
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
OpenIssue:
|DB1^8^01290^Disability Unable to Work Date|
Rationale: 2.3 abstract message definition
OpenIssue:
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 Control/Query/MasterFiles
Specialization of Service to add the characteristics unique to documents.
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 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 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|
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|
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?
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?
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?
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: This class now contains the attributes of a "master" class and therefore is not associated with an individual patient.
OpenIssue: Is this multiplicity correct? Is the Parent-Child tree structure correct? Is there an associative class for the relationship?
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?
|
|
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|
OpenIssue: Is the fully optional many-to-many on both ends correct?
|
|
|
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)
OpenIssue: this is not a location oriented data item
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.
OpenIssue: Does this match any V2.3 field?
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 Patient Care
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
This attribute allows a URL to define the address to which the message reply should be directed.
Unique identifier of the sending application of message.
|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 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.
Class steward is Patient Administration
Interested committees Orders/Observation
A person who is subject to receive, is receiving, or has received Healthcare services.
OpenIssue: This is really the state of the relationship between other stakeholder classes, or other classes not in the stakeholder tree. Context of state is unclear. May have something to do with structural changes in the RIM. May be a throwaway. May also be a methology issue. See minutes for 6/99.
Rationale: This class now contains the attributes of a "master" class and therefore is not associated with an individual patient.
OpenIssue: Is the fully optional many-to-many on both ends correct?
The relationship between a person and a healthcare provider organiztion by which a person establishes a patient relationship to a healthcare provider association.
OpenIssue: Consider merging Patient and Patient_provider_association into a single class, or at least consider changing the name to encompass numbers.
Rationale: 2.3 abstract message definition
OpenIssue:
OpenIssue: Review/explain cardinatlity
OpenIssue: The same person can be a contact for more than one patient and a patient can have more than one contact persons.
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 Patient Care
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|
A type of medical management area in which care is scheduled to be delivered.
OpenIssue: This may need to be a repeating field with a type code to differentiate the entries to clarify scheduled, actual, administrative, etc. Clarify how this code is relevant to purpose_cd.
Text describing the patient valuables left for safe keeping.
|PV2^5^00185^Patient Valuables|
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: This may have to be changed after we figure out what tis "encounter" thing really is.
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: Association naming is very broad: "has assigned to" does not say what this assignment means.
Rationale: Allows removal of generalization (patient_clinical_item) with single specialization
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 Patient Administration
The relationship between a person and a healthcare provider organiztion by which a person establishes a patient relationship to a healthcare provider association.
OpenIssue: Consider merging Patient and Patient_provider_association into a single class, or at least consider changing the name to encompass numbers.
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|
The relationship between a person and a healthcare provider organiztion by which a person establishes a patient relationship to a healthcare provider association.
OpenIssue: Consider merging Patient and Patient_provider_association into a single class, or at least consider changing the name to encompass numbers.
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 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
OpenIssue:
|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.
Rationale: PAFM has received several requests to change birthplace from an ST to AD or XAD type.
|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., Alone, Family, Relatives, Institution, . . .).
|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 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?
|
|
|
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| |IN2^44^00787^Insured's Employment Start 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|
Date the person's employment ends.
|GT1^32^00783^Guarantor Employment Stop Date| |IN2^45^00783^Guarantor Employment Stop Date|
|
|
|
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
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.
The end date of the authorized period.
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).
The last date that the provider is the preferred provider for the patient.
Rationale: Requested additional to v2.3.1.
Rationale: A person's PCP can be either a practitioner or a 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.
|
|
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 Inter-Enterprise (ADT/Finance/Inter-Enterprise)
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.
Free form text describing the referral.
Free form text providing the reason for the referral.
|
|
|
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.
OpenIssue:
|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
OpenIssue:
Type of resource controlled by this set of slots: provider, location, or equipment.
OpenIssue:
Start date and time for this set of slots
OpenIssue:
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 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.
OpenIssue: Needs to be further fleshed out. Is it needed as a class if it is this thin?
|ARQ^5^00864^Schedule ID| |SCH^5^00864^Schedule ID|
|
|
|
Class steward is Orders/Observation
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.
An indicator depicting the availability of a result or report for use in patient care (e.g., available for patient care, unavailable for patient care). Once a result or report has been made available for patient care, it cannot be changed or deleted, although it can be superceded or have an addendum added.
OpenIssue: "AV" and "UN" should probably be added to service.status_cd as additional states, because once a result or report has been made available for patient care it's behavior changes significantly, and because there are clear allowable transitions between existing state values and the values of this indicator. If these values are added to service.status_cd, then the state model needs to be revised, and this attribute is not necessary. This is the allowable state transitions of the availability_status_cd field in the Chap 9 TXA segment: START --> AV | UN; AV --> AV | OB; UN --> UN | CA | OB | AV; OB --> FINAL; CA --> FINAL.
For HL7, messaging the Service.availability_time will be set according to the sender system. If the receiver system records the received information as new, it may set it’s own recording time to the time it received this information, rather than to the time specified by the information sender.
The Service.recording_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.
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.
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 is a short human readable instruction on the timing, quantity and manner of service performance. In prescriptions, this is called the "Sig." Note that the timing, quantity and other performance parameters must be controlled using the appropriate attributes in the Service and service-relationship classes. The instructions_txt attribute is mainly used to capture the step between human authoring of an instruction and coding in the computer-processible attributes in Service and service_relationship.
OpenIssue: If you have service instruction text, the description should be modified to exclude these.
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.
A report identifier that remains constant across all document revisions that derive form 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.id, and has the value of 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 "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 service.family_id as the parent report being replaced, and increments the value of service.version_nbr by 1. The state of the parent report being replaced becomes "superceded" explicitly by another message, but is still retained in the system for historical reference. The parent report being replaced is referenced via a service_relationship, with service_relationship.type_cd set to equal "replaces".
OpenIssue: If we do use this attribute, we should decide whether or not, at the RIM level, it is required or optional. Document lineage is explicit via service_relationships.
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.
A code depicting the storage status of a report. If availability_ind is true, allowable storage codes are AC and AA. If availability_ind is false, allowable storage codes are AR and PU.
OpenIssue: Note that if we fold availability_ind into service.status_cd, this definition will need to be revised.
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.
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.
OpenIssue: If we do use this attribute, we should decide whether or not, at the RIM level, it is required or optional. Document lineage is explicit via service_relationships.
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: 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: 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 Orders/Observation
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.
OpenIssue: Need code examples. 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
OpenIssue:
|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.
OpenIssue:
|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.
OpenIssue: How does this attribute work with the start_dttm for the request. This offset is relative to the appointment and would apopear to present a conflict with the other attribute.
|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 Patient Care
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| |NK1^8^00197^Start Date|
The date the affiliation between the associated stakeholders ends.
|IN2^56^00796^Relationship To The Patient Stop Date| |NK1^9^00198^End Date|
Class steward is Orders/Observation
Supply orders and deliveries are very simple services that mainly focus on the delivered product. The product is associated with the supply service 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 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 : Postal_and_residential_address ADXP : Address_part ON : Organization_name |
PN : Person_name_type PNXP : Person_name_part |
|
ANT : Annotated BAG : Bag HIST : History HXIT : History_item IVL : Interval IVL<INT> : Interval_of_integer IVL<TS> : Interval_of_time LIST : List LIST<ADXP> : List_ADXP LIST<INT> : List_INT LIST<PNXP> : List_PNXP NPPD : Non-parametric_probability_Distribution PPD : Parametric_probability_distribution |
SET : Set SET<AD> : Set_Address SET<CDXL> : Set_CDXL SET<CRR> : Set_CRR SET<CV> : Set_CV SET<II> : Set_of_II SET<ON> : Set_ON SET<TEL> : Set_TEL SET<UDVP<T>> : Set_UDVP UDVP : Uncertain_discrete_value_using_probability UVN : Uncertain_value-narrative |
|
IVL<INT> : Interval_of_integer IVL<TS> : Interval_of_time LIST<ADXP> : List_ADXP LIST<INT> : List_INT LIST<PNXP> : List_PNXP SET<AD> : Set_Address SET<CDXL> : Set_CDXL |
SET<CRR> : Set_CRR SET<CV> : Set_CV SET<II> : Set_of_II SET<ON> : Set_ON SET<TEL> : Set_TEL SET<UDVP<T>> : Set_UDVP |
|
BIN : Binary_data BL : Boolean INT : Integer MO : Monetary_amount N : Number |
NULL : No_information PQ : Physical_quantity REAL : Real RTO : Ratio |
|
ED : Encapsulated_data ST : Character_string |
|
GTS : General_timing_specification TS : Point_in_time |
This Address data type is used to communicate postal addresses and residential 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). The difference between postal and residential address is whether or not there is just a post box. The residential address is not supposed to contain other information that might be useful for finding geographic locations or doing epidemiological studies. These addresses are thus not very well suited for describing the locations of mobile visits or the "residency" of homeless people.
OpenIssue: A temporal context to this address needs to be added to cover cyclical changes (custodial parent rotation for a child's address).
Indicates that this address is not working
A purpose code indicates what a given address is to be used for. Examples are: prefered residency (used primarily for visiting), temporary (visit or mailing, but see History), preferred mailing address (used specifically for mailing), and some more specific ones, such as "birth address" (to track addresses of small children). An address without specific purpose code might be a default address useful for any purpose, but an address with a specific purpose code would be prefered for that respective purpose.
This contains the actual address data as a list of address parts that may or may not have semantic tags.
This type is not used outside of the Address data type. Addresses are regarded as a token list. Tokens usually are character strings but may have a tag that signifies the role of the token. Typical parts that exist in about every address are ZIP code, city, country but other roles may be defined regionally, nationally, or on an enterprize level (e.g. in military addresses). Addresses are usually broken up into lines which is indicated by special line break tokens.
The role of an address part (if any) indicate whether an address part is the ZIP code, city, country, post box, etc.
The value of an address part is what is printed on a label.
Generic data to allow arbitrary free text annotations for any message element instance.
The annotation as free text and/or in coded form. The annotation is meant for display to users or administrator or for computer-processing of exceptions. The annotation must not be used for routine data exchange that is covered elsewhere by HL7. Examples: Specimen Inadequate for Processing, Result Sent to State Medical Department, Specimen Hemolysed.
OpenIssue: Proper code examples must be developed and documented.
The information itself.
Represents any data type in Version 3.
BAG is an unordered collection of items. Items may occur more than once in the bag.
The R parameter defines the multiplicity (min,,max) for the collection.
Binary data is a sequence of uninterpreted raw bytes (8 bit sequences, or octets).
The boolean type stands for the values of two-valued logic. A boolean value can be either true or false.
|
|
|
A concept descriptor communicates a real world concept (such as a finding or a diagnosis). A given concept may be expressed in multiple terms where each term is a translation of some other term, or is a (re-)encoding of the original human readable text.
This is the original text or phrase entered by a clinician that was the basis for the initial coding. This can also be the text that was displayed to the clinician in a selection menu and thus was the basis for the selection of the particular initial code term in the set of translations.
These are the translations or quasi-synonyms of one real world concept. Every translation in the set is supposed to "say the same thing in different words." The translations in the set form one directed graph that is fully connected.
|
|
|
A code phrase is a list of code values which all together make up a meaning. This can be used for example in SNOMED, where you can combine multiple codes into a new composite meaning. HL7 used to combine codes and modifiers for the OBR specimen source. And HCFA procedure codes also come with modifiers.
A set of concept_role_relations that modify the meaning of the primary code in 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-latrality: left" is an element in the Code_phrase.modifier_cd.
A code value that may be modified in this 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 "leg" is the Code_phrase.primary_cd.
This data type holds one code phrase as one translation in a set of translations describing a concept. The additional information in this data type points to the source code used in the translation process and describes who or what performed the translation and what the quality of this translation is.
This is the code in the list of translations on which this translation was based. This is a required component which means, whoever adds an additional translation must reference the source code. No reference here means that the given translation is the original code.
OpenIssue: THIS IS A REFERENCE TO A CDXL. How represent this?
This identifier tells what system performed the translation. This information can be useful to audit the translation process or to estimate the quality of the term based on prior experience with a the translation of a given producer. This identifier refers to some system not a particular human coding clerk. However, the system identifier can be fine grained enough so that the human operator can be Determined in the process of unraveling the identifier.
An estimation of the translation quality. This is a value between 0 and 1, where 1 stands for an absolutely accurate translation and 0 stands for random fuzz. We do not require a special method to be used here to estimate the quality. This can just be a subjective estimation of the form we use in eliciting probabilities for a belief network. But we can recommend some example methods of how those values can be computed. We can also map all other quality estimations mentioned in the literature onto the interval [0..1] of real numbers.
All the meaning of the translation is found here, the rest is descriptive stuff.
A collection data type is a collection of one or many instances of a particular element type. One particular semantic variation of the collection data type is specified in the S parameter of the collection.
The notion of a collection data type should once and forever supersede the traditional notion of "repeatability." [This means, the MDF meta model needs to be modified where it mentions "repeated" etc.]
The T parameter defines the type being collected.
The S parameter is the kind of collection. Collections are of one of the following kinds:
SET an unordered collection of unique element type instances.
BAG an unordered collection of element type instances. Instances may occur more than once in the bag.
LIST an ordered collection of element type instances.
The R parameter defines the multiplicity (min,,max) for the collection.
The concept role relation is used to send code modifiers targeted for specific roles. Both modifiers and roles are defined by some coding systems and can only be used for coding systems that define those. 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".
Note, that the use of modifiers is (as it always was) strictly governed by the code system used. In other words, it will not be permissible through this data type to use code modifiers with code systems that do not provide for modifiers (e.g. pre-coordinated systems, such as LOINC or ICD-10 PCS.) The rules of the modifier use must be governed by a code system (e.g., recent SNOMED RT revision, or GALEN.)
May invert the meaning of the role, in cases where the underlying code system 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 for its roles to be inverted, a user can construct the post-coordinated concept "Pneumococci pneumonia" through "Pneumonia - causes,inverted - Streptococcus pneumoniae."
Note that roles may only be inverted if the underlying coding systems allows such inversion. Notably, if a coding system defines roles in pairs, the appropriate role code (e.g. "caused-by") must be used rather than inversion.
The inversion_ind defaults to false.
Default: False
A code denoting the manner in which the value role relation 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 Concept_role_relation.name.
Note that the role_relation.name is in itself a code value (CV) and must be defined by the code system that allows the use of such targeted modifiers. It is not allowed by a user to make up role names on an ad hoc basis.
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 Concept_role_relation.value.
This component is by itself of type Code_phrase, which allows modifiers to be themselves modified. Remember that all these modifiers can only be used if the 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.
|
|
|
A code value is exactly one symbol in a code system. The meaning of the symbol is defined exclusively and completely by the code system that the symbol is from.
An object identifier referring to the code system that defines the code value. The OID allows to unambiguously refer to standard HL7 codes, other standard code systems, as well as local codes. HL7 assigns OIDs to its code tables as well as to external standard code systems that are being used with HL7. Local sites can use their OID to construct a local code system identifier that is globally unique.
A version descriptor defined specifically for the given code system.
A sensible name for the code as a curtesy to an interpreter of the message. THE PRINTNAME HAS NO MEANING, it can never be sent alone and it can never modify the meaning of the code value
A name for the concept to be used in case that the concept is not codeable in the specified coding system. If the value attribute is set, the replacement attribute MUST NOT be set. In no way can a replacement string modify the meaning of the code value
CONDITIONAL: iff value not set.
This is the plain symbol, like "784.0"
Abstract generalized type for any discrete type.
|
|
|
The free text data type can convey any data that is primarily meant to be shown to human beings for interpretation. Free text can be any kind of text, whether unformatted or formatted written language or other multi media data.
For text/plain media defines the character encoding if different from default encoding. Defaults to the encoding used for ST.
Indicates that the raw byte data is compressed and what compression algorithm was used.
Contains the free text data as raw bytes.
The cryptographically strong checksum algorithm SHA-1 (Standard Hash Algorithm-1) 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 as quickly as MD5 was superseded.
Default: SHA-1
Rationale: The ic_algorithm is recognized now so that HL7 is prepared to accommodate the change to another algorithm should such algorithm supersede SHA-1.
The ED.integrity_check attribute is a cryptographically strong checksum (SHA-1 algorithm by default) that is calculated over the binary data block. The system resolving a data reference can calculate the checksum over the received data and can thus validate whether the data received is actually the same data that the HL7 message has referred to earlier.
Rationale: Since the data referenced is only coupled to the message by a telecommunication address, the coupling between message and referred data is quite loose and insecure. This component closes this gap.
Used to select an appropriate method to render the free text data. Draws from IANA defined MIME type codes.
Defaults to "text/plain"
This is a telecommunication address (TEL) that is supposed to resolve to precisely the same binary data that could have been sent in the ED.data component directly.
The TEL data type in its TEL.valid_time component allows to announce a deadline time until which the originator of the ED instance promises to keep the reference valid.
Rationale: Large data blocks such as radiographic images can be sent in HL7 messages inline in ED.data. However, there is a need to save network bandwidth by deferring the transmission of such large data blocks until actually needed.
A thumbnail is a low resolution/small image that represents a high-resolution/large image. Thumbnails allow a user to select data more effectively before actually downloading it. The thumbnail concept can be metaphorically used for other data as well, e.g., an movie represented by a shorter clip, an audio by another audio with lower sampling rate, etc.
Rationale: This helps conservation of network bandwidth for large binary data content, such as radiographic images, or catheterization movies.
General timing specification is a primitive data type that is conceptually an arbirary set of points in time. It is any combination of (1) a point in time, and (2) an interval of time. This includes uncertain points and intervals of time. At this point, values are defined in terms of a literal expression syntax. Regardless how comples the literal definition of a GTS value is, it will always decompose into an ordered sequence of points or intervals of time.
ExtRef: The specification of the semantics and literal expression is found elsewhere. Should it, can it be included in the RIM description field?
Rationale: For a more complete discussion of the problem and approach to arbitrary time schedules, refer to the attached material
- HL7 v3 Data Type Specification, version 0.95, p. 146 ff
- The Unified2 Service Action Model Proposal (USAMP-II) revision 2.3, part A, section 2.5.3, p. A-34 ff.
- Open letter to Mead Walker, about the rationale of the current literal approach to GTS.
To summarize: the v3 data type specification document includes a semantic model of all time schedules that is based on the following ideas:
- Singular time intervals as continuous sets of time points, specified through low and high boundary or width (in case no boundary is known.)
- Periodic time intervals as discontinuous sets of time points, specified through a period duration and a time offset (phase) interval.
- The set-operations intersection and union on such continuous and discontinuous sets of time to form arbitrary sets of time.
- The reduction of any arbitrary set of time into an outer bound interval and a sequence of occurrence intervals, no matter how complex the definition of this arbitrary set is.
- The use of probability distribution data types to account for the uncertainty in scheduling and time orders, or, in other words, to allow "fuzzy" constraining of time sets.
- Time can be specified in terms absolute even flow of time, or aligned to calendars
Since the mathematical approach to the timing specification may not be very well appreciated among the HL7 users and implementers, and since calendars add to a considerable inherent complexity, we assumed that hiding the semantic model behind a literal expression syntax may be easier to handle for most technical committees and demo implementers at this time. Therefore we encapsulated the entire semantics of the arbitrary sets of time behind a literal expression syntax.
We do offer the semantic model in the HL7 v3 data type specification, but we do not force it upon users and implementers in general.
Generic data type to give the history of some information. This is an ordered list of data of the same type along with the time interval giving the time the information was (or is) valid. The order of history items in the lists should be backwards in time. The history information is not limited to the past history, expected future values can also appear.
|
|
|
Generic data to give the time range in which some information was, is, or is expected to be valid.
The time interval 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 information itself.
|
|
|
This data type is used to uniquely identify some entity that exists within some computer system. Examples are object identifier for RIM class instances, things like medical record number, placer and filler order number, service catalog item number, etc.
This is the required field that guarantees the uniqueness of the identifier and that permits the origin of the identifier to be determined (un-raveled). This can be the only field in institutions that use OIDs for their internal object identifiers.
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 time range in which the identifier is valid. May be undefined on either side (effective or expiration).
The character string value of the identifier. For example, the character string "123-45-6789" for a MRN (Medical Record Number).
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 special ineger values are defined for the positive and negative infinity.
|
|
|
Generic data type that can express a ranges or intervals of values. An interval is a set of consecutive values of any totally ordered data type. An interval is thus a continuous subset of its base data type.
Parameter T: Any ordered type can be the basis of an interval. It does not matter whether the base type is discrete or continuous or whether any algebraic operators are defined for that type.
The upper boundary.
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.
Default is False
The lower boundary.
Indicates whether the interval is closed or open at the lower boundary. For a boundary to be closed, a finite boundary must be provided, i.e. unspecified or infinite boundaries are always open.
Default value is False.
LIST an ordered collection of items.
The R parameter defines the multiplicity (min,,max) for the collection.
|
|
|
A monetary amount is a quantity expressing the amount of of money in some currency.
The currency unit (e.g., US$, Deutsch Mark, Pound sterling), which is a real world concept.
The magnitude of the monetary amount in terms of the currency unit..
Representation of a number.
|
|
Generic data type to specify an uncertain discrete value as a set of <value, probability> pairs (uncertain discrete values). The values are considered alternatives and are rated with probabilities for each of the values to apply. Those values that are in the set of possible alternative values but not mentioned in the non-parametric probability distribution data structure will have the rest probability distributed equally over all unmentioned values. That way the base data type can even be infinite (with the unmentioned values being just neglected).
As for type of T, any data type that is discrete can be used. Usually we would use non-parametric probability distributions for unordered types only and only if we assign probabilities to a "small" set of possible values. For other cases one may prefer parametric probability distributions.
The set of probabilities making up the distribution.
A No Information MEI can occur in place where an MEI of any other MET is expected (except as otherwise stated in the standard, e.g. by a "mandatory-ness" constraint.) This is like a NULL in SQL but with the ability to specify a certain flavor of missing information.
The flavor of the null value. Can be interpreted as the reason why the information is missing.
The ISO Object Identifier is defined by ISO/IEC 8824:1990(E) clause 28.
A name for an organization, such as "Health Level Seven, Inc."
Rationale: The Organization Name (ON) data type is much less elaborated than the Person Name data type because it was felt that the use case for distinguishing organization name parts is much weaker than for person name parts. So it was decided to keep the organization name as a simple character string.
The ON.type_cd was adopted from HL7 v2.3.1 even though, there is doubt as to the applicability of the concept "Display name"; and even though, there is doubt, whether a ticker symbol is unique for each organization (each Stock exchange, even each newspaper may have it’s own symbol.) We did not significantly redesign this from version 2.3, since any "correct" redesign would have exploded the complexity of the ON type beyond what was felt as appropriate.
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 actual name data as a simple character string.
Abstract generalized type for any type that at least contains naturally ordered subsets.
|
|
A person_name_type is for one full name of a person. A name such as "Jim Bob Walton, Jr." is one instance of a Person_name_type. The parts of this name "Jim", "Bob", "Walton", and "Jr." are person_name_parts. A person may have multiple names as defined through the RIM class Person_name.
This contains the actual name data as a list of name parts that may or may not have semantic tags.
|
|
|
This type is not used outside of the Person Name Variant data type. Person Name Variants are regarded as token lists. Tokens usually are character strings but may have a tag that signifies the role of the token. Typical name parts that exist in about every name are given names, and familiy names, other part types may be defined culturally.
Classifications of a name part. One name part can fall into multiple categories, such as given name vs. familiy name and name of public records vs. nickname.
The value of a name part.
|
|
|
Generic data type to specify an uncertain value of an ordered data type using a parametric method. That is, a distribution function and its parameters are specified. Aside from the specific parameters of the distribution a mean and standard deviation is always specified to help maintain interoperability is receiving applications can not deal with a certain the probability distribution.
Parameter T: The base data type may be discrete or continuous. Discrete ordered types are mapped to natural numbers by setting their "smallest" possible value to 1, the second to 2, and so on. The order of non-numeric types must be unambiguously defined.
The mean (expected value or first moment) of the probability distribution. The mean is used to standardize the data for computing the distribution. The mean is also what a receiver is most interested in. Applications that can not deal with distributions can still get the idea about the described quantity by looking at its mean.
Each type of PPD has a different set of parameters.
OpenIssue: This set of data types should be modeled as a set of subtypes of PPD, with the type component (above) indicating which subtype it is and with the appropriate set of parameter components for each subtype.
The standard deviation (square-root of variance or square-root of second moment) of the probability distribution. The standard deviation is used to standardize the data for computing the distribution. Applications that can not deal with distributions can still get the idea about the confidence level by looking at the standard deviation.
The type of probability distribution. Possible values are as shown in the attached table.
A physical measurement is a dimensioned quantity expressing the result of a measurement act. It consists of a value and a unit.
The unit, which is a real world concept.
The magnitude of the quantity measured in terms of the unit.
Abstract generalized type for any quantitative type.
Floating point numbers are approximations for real numbers. Floating point numbers occur whenever quantities of the real world are measured or estimated or as the result of calculations that include other floating point numbers.
The precision of the floating point number in terms of the number of significant decimal digits.
The value without the notion of precision or with an arbitrary precision. We only specify an internal (unusable) data type for true real numbers of infinite precision.
|
|
|
A ratio quantity is a quantity that comes about through division of a numerator quantity with a denominator quantity. Ratios occur in laboratory medicine as "titers", i.e., the maximal dissolutions at which an analyte can still be detected.
The denominator quantity.
Default is one, must not be zero.
The numerator quantity.
Default is one.
SET is an unordered collection of unique items.
Parameter R: parameter defines the multiplicity (min,,max) for the collection.
A string of characters where every character used by any language anywhere in the world is represented by one uniquely identifiable entity within the string. This type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names..
|
|
|
This is a dereferencable locator for some instance. For example, a bunch of radiology images that can be retrieved on demand. A given instance of this data type may not be valid forever.
This is an arbitrary address string that must be meaningful to the protocol.
The purpose of the "use code" is to advise in a system or user's selecting an appropriate telecommunication address to reach a party for a given telecommunication need. The following mandatory value domain is defined:
PR - primary residence (home)
OR - other residence (other home)
WP - work/business/office communication address
VR - vacation residence
AS - automated answering service
EC - emergency contact
BP - beeper/pager
CL - cellular/wireless phone
This is a General Time Specification (GTS) that identifies the periods of time during which this 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 axis of natural time. This naive concept of an absolute time scale is not concerned with relativity of time as is important in astrophysics and cosmology.
|
|
|
Generic data type to specify one uncertain value as a pair of <value, probability>.
The probability assigned to the value.
The value to which a probability is assigned.
The universal resource identifier is defined and maintained outside HL7 by the IETF and W3C. In HL7 the URI is used to refer to addresses of communicating entities used in order to transmit any kind of information. This may be used for HL7 messaging addresses, but is also used for non-HL7 communication and non-computer communication. Designated applications are clearly: (a) Web servers (HTTP), (b) File Transfer Protocol servers (FTP), (c) Telephone numbers, (d) Telefax numbers, (e) Dialup Modem connections.
Rationale: The data type used for phone contacts and other telecommunication addresses (e.g., e-mail, web-pages, FAX, etc.) was called Technical Instance Locator. It was very similar to an Internet and W3C standard Universal Resource Locator/Identifier. That is, it consisted of two parts: a protocol descriptor and an address.
The TIL was designed as a wrapper around standard URIs in order to have the freedom to add additional protocols used in healthcare but not necessarily on the wide Internet. We feared that a direct reliance on Internet protocols might require difficult negotiations with IETF/W3C working groups before HL7 could use important extensions. Especially at the time the TIL was designed, we were not aware of a URI scheme for phone and FAX numbers – an absolutely necessary requirement for HL7.
We now learned that a URI scheme for telephone/FAX/data-modem is in a solid IETF Internet draft status, so HL7 can use this work directly. We further learned that the definition of URI schemes is not regulated by a difficult negotiation process, so that HL7 could add additional URI schemes easily as needed. We therefore concluded that relying directly on Internet standard URIs is feasible and sufficient for HL7, while being (of course) much simpler to use for HL7 implementers
|
|
|
Generic data type to specify one uncertain value as a pair of <value, qualifier>. The 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.
T is discrete or continuous.
The confidence assigned to the value.
The value to which an uncertainty qualifier is assigned.
|
Acknowledgement Attention_line |
Document_service |
Message |
|
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 |