This wiki has undergone a migration to Confluence found Here

Introduction & Scope Care Provision Domain

From HL7Wiki
Jump to navigation Jump to search

Patient Care

Patient Care Normative Ballot Content

Introduction, Purpose and Scope of the Care Provision Domain

The Care Provision Domain addresses the information that is needed for the ongoing care of individuals, populations, and other targets of care. The "Act of Care Provision" is the recording of a process that defines the responsibility for supplying support to the target of care. It is a statement of supervision, management, custody, and responsibility for assessment, diagnosis, treatment and care.

The people or other entities associated with "Responsibility for Care," are divided into the health care providers and targets of care, where a patient may be considered both a provider and a target of care and where any person may carry multiple roles.

The purpose of the Care Provision models is to facilitate the exchange of a full Care Record (all data in the record), a Care Record summary (a predefined subset), or a Care Record excerpt (a variable set of 1 -n clinical statements, for instance as response to a query or quary profile), including the organizing clinical structures that are required for handing over responsibility for the record target in a meaningful and clinically relevant fashion.

The scope of the "Responsibility for Care" is defined in four "layers"

(1) The Act of Care Provision represents a kind of responsibility defined by CareProvision.code, which usually represents the scope of responsibility described by a governmental license, a certification agency, or other legally recognized entity such as the patient themselves. This part assumes, within the scope of individual jurisdictions, that there is a formal agreement of the patient with the (health care) provider.

(2) The reasons for the Care Provision further constrains the scope of responsibility to one or more "Concerns". This in particular allows providers and patients to narrow the responsibility to specified area's of concern.

(3) The third layer expresses the Care Plans or management plans. These plans further identify the expectations for specific observations and actions to be performed via the component relationship. The first layer is required in a statement of responsibility; the second two layers, which constrain the first layer, are optional.

(4) The single Clinical Statement or collection of Clinical Statements for which one author is responsible of its data quality as entered in the source system and exchanged via the message.

In the context of HL7, a "Concern" is worry about a state or process that has the potential to require attention, intervention or management. A problem list is an example of a list of concerns. The "Concern" itself has no meaning, so no Act.code. It is simply a mechanism to identify the concern, where the actual observations supporting it, need to be related to the concern. This is a one to many relationship.

For example, diabetes may be on the problem list. However, the scope of responsibility for an endocrinologist might be only the diabetes and not the other problems. Diabetes is then identified as the reason for the Care Provision. The expectation of the endocrinologist may only include recommendations for a modification to the diabetes care plan. This specific diabetes care plan modification is then a component of the Care Provision scope of responsibility. All diabetes related observations, diagnose, treatments are linked to the Concern class with the specific identifier.

In the same way in the public health arena, the responsibility for a population may be limited to managing an Outbreak of infectious disease.

Therefore, the essential concept in this Care Provision Domain is the recording of the responsibility for care provision. Management plans (care plans, clinical pathways) for the subjects of concern may be included in the scope of the responsibility for care provision.

This domain also includes the transfer of responsibility for care and the updating of pertinent information about respective responsibilities between collaborating care providers, such as the communications that occur when a patient is referred to a hospital by a general practitioner, or discharged from the hospital to a home health agency.

This domain recognizes the fact that care coordination often includes many types of providers that care for people, devices, facilities, and the general environment, not just clinicians delivering direct care to a patient. The pertinent information regarding care provision may include general summary information or granular primary information, but may not carry all the information known about a specific instance in the generating system. However, in general, the scope of the domain includes all the information needed for decisions to be made by a care provider. At a minimum, the domain includes the identifiers and other data needed to query a source system for the additional information needed for care.

The scope is formalized in the following scope statement

The Care Provision Domain describes the dynamics of processes, information structures and vocabulary used to communicate information pertinent to the care of living subjects, devices, geographic sites, and other physical entities by a responsible care provider. This domain supports multiple specifications appropriate to referrals and record communications supporting collaboration and the continuity of care between care providers.

Among other more generalized care activities that can be defined by analogy and interpretation of the scope above, the Care Provision Domain specifically supports:

  • Sharing of health record extracts and event summaries of the health record between collaborating providers (including the patient) in order to support the clinical decisions or decision support activities of the receiving persons or systems.
  • Request for the transfer of patient care responsibility of a specific type of care by a healthcare provider by a requesting healthcare provider, a responsible party, such as a care coordinator, advocate or family member or the patient themselves.
  • Acceptance or rejection of a request for care transfer as well as the ability to provide information about the intent to provide care to the requesting party.
  • Communication of a summary of relevant findings and outcomes of the care provided in response to a request for further information.
  • Further materials such as Care Plan, Allergy or Assessment Scales, requiring precize structures and vocabulary or specialized dynamic behaviours.
  • Specific, use case driven structures that facilitate the use of the Care Provision messages in specified circumstances.

Limits of Scope: The scope of the Care Provision Domain is also limited by its focus on Care Provision Act, "an HL7 Act that describes "the responsibility for supplying support to the target of care."

The Care Provision Domain is not intended to represent all the information communicated by systems that originate detailed pertinent information such as observation data or person registration data. The domains that support communication from these data generating systems tend to supply much more detail regarding the complex data context within which the data was generated. In that spirit, the intention of the Care Provision Domain is to communicate the instance identifiers and meta data for these granular instances of data such that the receiving system has enough information to query sending systems for more detail on specific items of pertinent information (assuming the sending systems support queries and instance identifiers).

Readers: Please see the Glossary Section for terms important to the Care Provision Domain

Care Provision Domain Normative Ballot Guidance

All Topics under the Care Provision Domain area "Patient Care Infrastructural Topics" relate to implementation specifications.

In contrast, the "Patient Care Clinical Content Topics" focus on additional information in the Care Provision Domain that may be specified at RMIM development or at system runtime. These will increasingly be handled as templates in the infrastructural messages. Harmonization with the aHL7 Templates workgroup is ongoing.

Guidance to balloters on Provider Act Relationships: Further harmonization needs to occur on the specific structures, e.g. CMET's, used by various domains to describe the providers of care. The broad description of potential providers used in this domain needs to be able to be constrained to the providers supported by CDA, Patient Administration, and Personnel Management for patient-related use cases. The CMET's chosen for this domain are described in the CMET documents.