In general, an activity definition is simply a conceptual description of some specific action that should be taken. An instance of an Activity Definition does not indicate that any action has been performed (as an event resource does), nor does it indicate the actual intent to carry out any particular action (as a request resource does). Instead, an activity definition provides a reusable template that can be used to construct specific request resources such as Service Request and Medication Request.
Note that this is conceptually similar to the Task resource as well, with the distinction being that Activity Definition represents the description of a task in the abstract, while the Task resource is used to track a specific instance of a task as it moves through the steps of a workflow.
An Activity Definition resource provides a description, or template, of an action to be performed. These actions can be purely text-based descriptions of the action to be performed, only interpretable by a human user, or they can be structured definitions with enough information to construct a resource to represent the request or activity directly. This process of converting the Activity Definition into a specific resource in a particular context is performed with the “$apply” operation.
In the simplest case, the process maps the elements specified in the Activity Definition to the corresponding elements on a resource of the appropriate type, using the kind element of the definition to determine the type of resource to be created.
More dynamic scenarios can be achieved in one of two ways, either by providing dynamic value expressions, or by specifying a Structure Map that transforms the definition into the appropriate request resource.
Note that systems will likely vary widely in the degree of support they provide for the “$apply” operation. In particular, the fact that a system supports applying definitions of one category, does not imply that it supports applying definitions for all categories. For example, a service focused on medication order sets may have sophisticated support for Medication Request activities, but no support at all for the Service Request activities.
Fast Healthcare Interoperability Resources (FHIR) is a draft standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization.
Its goal is to facilitate interoperation between legacy healthcare systems, to make it easy to provide healthcare information to healthcare providers and individuals on a wide variety of devices from computers to tablets to cell phones, and to allow third-party application developers to provide medical applications which can be easily integrated into existing systems.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs (Uniform Resource Locators). FHIR was supported at an American Medical Informatics Association meeting by many EHR (Electronic Health Record) vendors which value its open and extensible nature.