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