Class: Service

Description of: Service

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.

Attribute definitions for: Service

activity_time :: GTS

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.

availability_ind :: BL

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.

availability_time :: TS

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.

body_site_cd :: CD

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.

completion_cd :: CV

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.

confidentiality_cd :: SET<CV>

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.

critical_time :: GTS

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.

id :: SET<II>

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.

instructions_txt ::

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.

interpretation_cd :: SET<CV>

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."

interruptible_ind :: BL

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.

max_repeat_nmb :: INT

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.

method_cd :: CD

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.

mood_cd :: CV

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.

orderable_ind :: BL

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.

priority_cd :: CV

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.

service_cd :: CD

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.

set_id :: ST

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.

status_cd :: CV

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.

storage_cd :: CV

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.

substitution_cd :: CV

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.

txt :: ED

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_nbr :: INT

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.

Association definitions for: Service

is_covered_by (0,n) :: Healthcare_benefit_coverage_item :: provides_coverage_for (1,n)

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?

is_documented_by (0,n) :: Clinical_document_header :: documents (0,n)

OpenIssue: This many-to-many association should be resolved.

represented_as (0,n) :: Service_list_item :: represents (1,1)

is_charged_to (0,1) :: Patient_billing_account :: has_charges_for (0,n)

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?

is_source_for (0,n) :: Service_relationship :: has_source (1,1)

is_associated_with (0,n) :: Financial_transaction :: pertains_to (1,1)

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?

has (0,n) :: Service_target :: in (1,1)

is_target_for (0,1) :: Service_relationship :: has_target (1,1)

is_assigned_to (0,1) :: Patient_encounter :: has_assigned_to_it (0,n)

OpenIssue: Association naming is very broad: "has assigned to" does not say what this assignment means.

has (0,n) :: Service_actor :: for (1,1)