D-MIM Walkthrough Care Provision Domain

Patient Care

Patient Care Normative Ballot Content

Description

1.2 Domain Message Information Model

1.2.2 Description

1.2.2.1 Overall Organization of the Care Provision DMIM

This domain-level document describes in detail the focal act of the domain, the Care Provision Act, which establishes the context for the entire domain.

In addition to the Care Provision Act itself, this section includes a walk-through of the associations on the Care Provision Act. These associations include participations (to Providers and Targets of Care), components (e.g., to Clinical Statements), and pertinent information (to any additional information required for care, such as listed in the choicebox of the CMET Clinical Statement).

Most of the variability in the Care Provision DMIM will be expressed through patterns of detailed clinical information called Care Structures and through Detailed Clinical Models. In the 2011 meetings, Patient Care decided to differentiate between clinical structures and infrastructural structures. Infrastructural structures can be exhanged as messages of their own. The clinical structures are not messages, but internal message components or detailed specifications for semantic interoperability. The walk-throughs of these patterns are included in the different Topic sections. These patterns are expressed in each Topic section as RMIM's and HMD's. For now, the patterns are called CMET's, despite the limitation of their use to the Care Provision Domain. When these structures pass normative ballot in the Care Provision Domain, they will be submitted as shared CMET's for use by multiple domains. The CMET's described in the different Topics include many structures such as: explanation of the use of Clinical Statement proper instead of the former Care Statement; Concern Tracking; Worklist; Care Plan; among others. These CMET's are utilized in the message specification topics such as the Care Transfer and Care Record Topics in order to simplify the illustrations.

However, in this section, the focus will be on the meaning of the Care Provision Act and on the associations surrounding the Care Provision Act.

1.2.2.2 Care Provision Act in Patient Care

An understanding of this act is central to the concept of patient care by professionals. Normally, a patient is completely responsible for his or her own care. However, when people are ill, it is difficult for them to be completely responsible themselves. Part of the process of healthcare is that patients request that healthcare providers help them with their care. This request to help is central to the contract between patients and their healthcare providers. It is also common in healthcare for one professional to request the help of another professional in the context of this contract with the patient. This Care Provision Act represents a statement about the scope of responsibility that is shared between the patient, sometimes family members, and one or more healthcare providers. The discussion that follows is intended to further elucidate the concept of shared responsibility and extends the patient-related concepts of care to Care Provision in general.

Care Provision Act: The meaning of the Care Provision Act begins with an examination of the meaning of "Care" and the meaning of "Provision" in the context of this domain.

Stipulated Dictionary Definitions: Care (5): CHARGE, SUPERVISION, MANAGEMENT: responsibility for or attention to safety and well-being (under a doctor's...), (the ... of all the churches) CUSTODY: temporary charge

Provision (2a): the act or process of providing (the ... of a play area for the children)

Provide (3): to supply what is needed for sustenance or support (the Lord will...), (we'll have to ... for him) Merriam- Webster's Third New International Dictionary Unabridged, copyright 1961-2002.

Guidance: In the HL7 Reference Information Model (RIM), the term "Act" always represents the record of the "process of doing." "Care Provision" represents a constraint on the definition of "Act" that takes the form, "The Act of Care Provision" where "Care Provision" is the noun form of the infinitive "to provide care." Therefore, the "Act of Care Provision" is the recording of a process that defines the responsibility for supplying support. It is a statement of SUPERVISION, MANAGEMENT, and CUSTODY.

In healthcare, many workers are assigned to the care of facilities and devices as well as living subjects. This Act of Care Provision is to be used when the explicit accountability for the care of a living or non-living subject is a component of the intended semantic. In other words the subject of care is defined in the subject participation, which constrains the semantic of care provision, e.g. subject is in a patient role; subject is in the role of a manufactured device.

In healthcare, the condition of the medical device, home of the patient, or other non-living subjects may need to be managed as well as the conditions of the patients' bodies themselves. Accordingly, "Care Provision" is often combined with the HL7 concepts of "Concern Tracking" and "Care Plan," structures that are found in the different Topic areas of the Care Provision Domain.

Examples: equipment care, patient care, facility care, responsibility for population monitoring, responsibility for an environmental site.

Other Examples of the Scope of Care Provision include:

• preferred primary care provision: the primary care physician being the primary performer participation, author being the patient
• referral from general practitioner to specialist: (a Care Provision in request mood, where the author participant is the GP, and the primary performer participation is the specialist)
• case management: case manager is the performer to a patient or group of patient subject participants coverage assignment: assigning nurses to patients each shift
• environmental site care: the environmental site is the subject participant and a company is the performer participant
• population monitoring: a population is the subject participant and the government agency is the performer participant

1.2.2.3 Care Provision DMIM Walk-through

1.2.2.3.1 CareProvision Focal Class

The Care Provision act is used to describe all aspects of care provision like the patient details and the name of care professionals. This central act has relationships to itself and several other acts. Most of these relationships connect directly to acts of the Clinical Statement eg (observation, activities, encounters). It also has Participations which define roles of entities, e.g. the role of patient or provider of care. The details of the Care Provision Domain are described hereafter, beginning with the attributes.

1.2.2.3.2 CareProvision Attributes

classCode: The vocabulary domain specified for Act.classCode includes PCPR (Patient Care Provision) as a specialization of the Act class.

moodCode: Like all Acts in the RIM, the Care Provision Act may be expressed in many moods.These moods distinguish the different aspects of the business lifecycle of a Care Provision Act. These moods, which are central concepts for the DMIM, are defined as follows:

Code	Definition
RQO (request)	A "Care Transfer Request" is a question to another care provider regarding their ability to accept the responsibility of Care Provision for the subject. Typically the request is made by a care provider, recorded within one computer system, and then transmitted to a second system for analysis and response by the receiving care provider. However, support is also provided to allow the patient to self-refer themselves. A referring Responsible party such as a State or Court may also author a Care Transfer Request. In a Care Transfer Request, the receiving provider is listed as the performer. The scope of responsibility including CareProvision.code, reasons for care provision, and component care plans that set the specific expectations for care apply to the scope of responsibility for the receiver of the request.
PRMS (promise)	A "Care Provision Promise" is the statement of commitment to accept the responsibility of Care Provision as specified in the promise. It is assumed the receipt of a request message triggers a promise across a messaging interface from the requesting party. Due to the patient safety implications of care responsibility, there is no support for the type of "Implicit Promise" found in the Lab Domain. An acceptance of responsibility must be communicated as an explicit Promise. In this case, the performer is the sender of the promise. Likewise, the scope of responsibility including CareProvision.code, reasons for care provision, and component care plans that set the specific expectations for care apply to the scope of responsibility for the sender of the promise.
EVN (event)	An Event according to the RIM is a service that actually happens, may be an ongoing service or a documentation of a past service. For Care Provision, a Care Provision Event is a record, which summarizes the events that happened during care including who is responsible for the care provided. An author of the "Care Provision Event" records and summarizes the events The performer is responsible for carrying out the care events. The author and performer can be the same person. Care Provision Event messages may be sent during the course of care to describe the progress of care or may be sent at the termination of care to describe all the activities that occurred during the provision of care. In this case, the performer is the sending provider.
DEF (definition)	Definition mood code can be used to express a guideline or protocol.
INT (intent)	Intent can be used to express the intended activities in a care plan. In particular the appropriate selection of observations and activities from a guideline that are included in the care plan for one particular patient. So the intended Acts are individualized from the guideline.
PRP (proposal)	Proposal is used to suggest an idea to someone else, but not with the status of a request. It is further used as placeholder for the use in Care Plan R-MIM. For instance, it can be used by a consultant to recommend a course of action. Care Provision Acts in different moods are linked by the fact that promises are created to fulfill requests, and events are created to fulfill promises and/or requests.

id: This attribute identifies a particular Care Provision. Identifier attributes can be used to identify an instance of a class. Sometimes more than one attribute may be needed to identify an instance of a class. The identifier attributes always have a value. The values of identifier attributes are unique among all instances of the class. Since identity is static, values of identifier attributes never change. Identifier attributes are assigned the set of instance identifier (SET<II>) data type and generally have the name "id" that allow for multiple identifiers to be specified. The identifier attribute is a set of instance identifiers. This indicates that there may be multiple, unique identifiers for an Act. In the CareProvision Act, the "id" is used to give a unique id to all information that belongs together. It is used to identify the current care provision concerning a particular concerns and the responsible providers. It is further used in queries and to trace back information of earlier care provisions for e.g. predecessor concerns, or related concerns and so on.

code: This attribute describes a kind of Care Provision Act in accordance with the definition of Act.code in the RIM. At this point in time, this attribute is CWE, and no value set is currently defined. CareProvision.code represents the kind of care provision and the person that is responsible for it. This guidance applies: Care Provision is a statement of responsibility. The code for this statement should apply to a commonly accepted legal/regulatory/accrediting standard scope for responsibility. It is understood that these may differ by jurisdiction. In the US Realm, examples include: JCAHO; state licensing of hospitals, nursing homes, and home health agencies; medical and nursing specialty boards; etc. For example, a hospital discharge summary in a Wisconsin licensed hospital might use a code for "Wisconsin hospital care" or perhaps a JCAHO-certified acute care designation. This code is not to be interpreted as a setting code or an encounter code, but must be consistent with other related concepts, i.e. document type, encounter type, and scoping organizations for licensure or accreditation of participating providers. Local needs may require extensions of any given value set depending on local regulations and accreditations. A general value set for these concepts (that is expected to be extended by local agreement) will be defined by HL7, since external vocabularies do not at this time support this concept.

The intention for the use of CareProvision.code is to define a traditional scope of domain expertise, e.g. Orthopedic Care; Oncology Care; Acute Care; Long-term Care, etc. This scope described by this general domain of expertise would then be further constrained by the list of Conditions listed as Reasons for Care and the Care Plans identified as components of the Care Provision Act. This entire scope of care is then included in the particular request, promise, or delivery of care represented by the mood codes used in the Care Provision Act.

For the time being, any act.code from any code system can be included here. For example codes from SNOMED CT:

• Preventive care:169443000: preventive procedure
• Surgery: 257556004: surgery
• Delivery: 386216000: human parturition, function

Each coding system is identified by the Object Identifier (OID), e.g. for SNOMED CT this would be: 2.16.840.1.113883.6.5

derivationExpr: The derivation expression attribute allows a string expression on derivation and is supported in an observation instance. The derivationExpr will be replaced by a data type in the near future. To be used by Decision support. Use cases will be included in a later stage. Is also used in the Care Plan. DSS will provide use cases in the near future and determine how decisions on this attribute will effect its use here.

negationId: There are 2 answering possibilities for the negation indicator: true, false. True means care is provided, false means no care is provided. However, the use of negation indicator in Care Provision Act is not encouraged. If it is used, a clear use case, and explicit interpretation guidelines must be provided to prevent medical errors. See terminfo project for future guidelines for application of negation.indicator

title: One title can be given to the Care Provision in free generated text.

text: This attribute can be used for a brief label of the care provision or short statement of type of Care Provision. It is not intended for a full text explanation of all that happened, or the reason for the care provision or the request. Such use is handled via explicit relationships to the care statement and conditions.

statusCode: The statusCode attribute is used to indicate the current state of the CareProvision class. The statusCode attribute corresponds to the Act state machine and for the Care Provision Act has the following valid values:

<<<< The original table can be reused for 2012 NE >>>>

effectiveTime: The effectiveTime attribute represents the time interval for which the care provision is provided. For intent care provision, the time will be proposed start and end date/time where applicable while care provision events, the time will be the actual start and end date/time (for a more generic description of effective, please refer to the RIM).

priorityCode: The priorityCode attribute has a potential overlap with some vocabularies. This potential conflict is resolved as follows:

priorityCode should only be used to indicate the urgency with which the communication recipient should respond to the information in the Act. For example, the request for a procedure should be treated as 'urgent'. Consequently, it is desirable that the use of priorityCode should be limited to acts that are in 'Intent' mood.

Act.code vocabulary expressions should be used to qualify the clinical immediacy of the expression that is in the code attribute. For example, the concept 'an Emergency appendectomy' should be expressed totally within Act.code.

Code Definition

A (ASAP) As soon as possible, next highest priority after stat. R (routine) Routine service, do at usual work hours. S (stat) With highest priority (e.g., emergency).

confidentialityCode: The confientialityCode attribute Code Definition ConfidentialityByAccessKind A value set that allows access to information by subject / role and relationship based rights (These concepts are mutually exclusive, one and only one is required for a valid confidentiality coding). ConfidentialityModifiers Modifiers of role based access rights (multiple allowed).

reasonCode: The reasonCode attribute specifies the motivation, cause, or rationale of a Care Provision, when such rationale is not reasonably represented as a "has reason" ActRelationship type linking to a Condition Observation.

Code Definition

PAT (patient request) The Patient requested the care provision. MEDNEC (Medical Necessity) Required for medical reasons(s). ActBillableClinicalServiceReason An abstract vocabulary domain linked to an external code set representing the reason for the Clinical Service being performed.

This domain excludes reasons specified by diagnosed conditions. Examples of values from this domain include duplicate therapy and fraudulent prescription.

This CareProvision Focal Act has six Entry points:

• Care Provision: DMIM for Care Provision messages
• CareRecord: R-MIM for Care Record
• Care Transfer Request: R-MIM for Care Transfer Request
• Care Transfer Promise: Accept Care Transfer
• Care Plan: Care Plan Structure
• A_PrincipalCareProvision: This defines the primary performer of a specified care provision. The care provision performer may generally be the primary provider or only within a specific health care facility. This relationship is usually solid over time and is recorder only for administrative purposes; actual care provided by this health care provider is recorder separately.

These RMIMs will be described in more detail in the respective topic section as to what purpose each has. In future additional entry points can be expected.

1.2.2.3.3 Care Provision ActRelationships

The Act Relationships attached to Care Provision are recursive relationships, relationships between Care Provision and Supporting Clinical Statement, and relationship to ControlActEvent. They will be described here.

Recursive Care Provision Act Relationships

Component2

sequelTo/sequel

Because the change from the Care Statement to Clinical Statement CMET, the relationships between Care Provision Act and Clinical Statement had to change. It was decided to keep it simple and ensure that any kind of further specialization can be done on the level of an R-MIM as specialization / constraints on the Clinical Statement and hence be templated.

Act Relationships between Care Provision and Supporting Clinical Statement

One linkage from Care Provision Act to Supporting Clinical Statement goes through the StatementCollectorActList. This Statement Collector allows any clinician to create and dynamically maintain one or more lists of clinical statements. Typical examples of lists are a problem list, which can be maintained multidisciplinary, a activities list, e.g. for a set of tasks listed in a care plan, an allergy list to which a new discovered allergy is added, and so on.

ActRelationships The relationship from Q_CareProvision to A_SupportingClinicalStatement is a pertinentInformation1. Allowing any kind of information. The ActRelationship has the following attributes: typeCode: PERT

sequenceNumber

1.2.2.3.4 CareProvision Associations

In the Care Provision DMIM, the Care Provision Act is surrounded by associations. The associations required for communication responsibility for Care Provision include:

   Participations to "Provider" choice box (author, performer, primaryInformationRecipient)
   Participations to "Target" choice box (subject, recordTarget)
   Participations to "R_AssignedPerson" CMET (verifier, dataEnterer)
   Recursive "Is Sequel" ActRelationship, in which an earlier or a later care provision relationship can be established (sequelTo).
   Recursive "Has Component" ActRelationship (component3)
   Recursive "Has Pertinent Information" ActRelationship (pertinentInformation3)
   The "Refers To" ActRelationship to current Encounter (reference)
   The Care Provision "Has Reason" ActRelationship to Conditions (reason)
   The "Has Component" ActRelationship to Care Statements (component1)
   The "Has Component" ActRelationship to StatementCollector (component2)
   The "Has Pertinent Information" ActRelationship to StatementCollector (pertinentInformation1)
   the "Has Subject Of" ActRelationship to Care Statements (subjectOf)
   the "Has Final Objective" ActRelationship .to Care Statements (final goal)

These associations along with the Care Provision Act itself provide all the relationships needed to communicate:

   Who is the provider with responsibility?
   What or who is provider responsible for?
   What prior lifecycle Act of Care Provision is fulfilled by this Care Provision instance, if applicable?
   What prior instance of the same Care Provision Act is replaced by this instance, if applicable?
   What encounter this Care Provision Act is created within, if applicable?
   Which Condition(s), i.e. Reasons for Care, are included in the provider's scope of responsibility?
   What Care Plan activities are included in the provider's scope of responsibility?
   What Observations and Acts have been carried out in this care provision or in earlier care provisions?

XXXX Care Provision DMIM Walk-through changes required

• refer to clinical statement
• make explicit the function and role of the statemencollectoractclass