- FHIR Capability Statement Resource
- Electronic Health Records Exchange Through FHIR
- Medical Terminology
- Processes Data
- Processes Information
- Processes Documentation
- Health Information Exchange
- Electronic Health Records
- FHIR Smart
- Smart on FHIR
A Capability Statement documents a set of capabilities (behaviors) of an FHIR (Fast Healthcare Interoperability Resources) Server for a particular version of FHIR that may be used as a statement of actual server functionality or a statement of required or desired server implementation.
Get The Data
- ResearchNon-Commercial, Share-Alike, Attribution Free Forever
- CommercialCommercial Use, Remix & Adapt, White Label Log in to download
Capability Statements provides for a degree of automatic configuration and adaptation. However, capturing absolutely every variation that could impact the interoperability of two systems, let alone keeping that detailed information up-to-date as systems evolve through maintenance and upgrades, is rarely practical. Therefore, capability statements should be seen as an interim step. They provide a degree of automation. However, they also provide a great deal of human-readable content that can minimize the need for direct communication between the operators of the systems being configured to interoperate.
The capability statement is a key part of the overall conformance framework in FHIR (Fast Healthcare Interoperability Resources). It is used as a statement of the features of actual software, or of a set of rules for an application to provide. This statement connects to all the detailed statements of functionality, such as StructureDefinitions and ValueSets. This composite statement of application capability may be used for system compatibility testing, code generation, or as the basis for a conformance assessment.
Specifically, capability statements are used in one of three ways:
1. Instance: The capability statement describes the capabilities of a deployed and configured solution available at a particular access point or set of access points. The statement describes exactly how to interface with that deployed solution and thus provides for a degree of self-configuration of software solutions.
This is the type of statement that FHIR restful solutions are expected to make available on invocation of the capabilities operation. It is also the type of statement that forms a basis for the testing, certification or commissioning of specific software installations.
2. Capability: The capability statement describes the generic capabilities of a software application or component solution. The solution might be available for purchase or other acquisition and might be deployed and configured at any number of independent sites. Because it is not dependent on any particular implementation, the profile cannot provide specific details such as endpoint addresses. It may also need to document various configurations in which the application can be set up or describe the degree of customizability associated with the solution.
This type of statement may be used as a marketing tool by software and system developers to formally describe their capabilities. It can also be used as the basis for conformance testing of software solutions independent of a particular installation.
3. Requirements: The capability statement describes the capabilities of the desired system. It might be used as part of an architectural design process to document needed system capabilities, or might be used as part of an RFP process to formally document the requirements of a requested solution and to document the criteria by which proposals will be evaluated.
These three types of profiles can be used together. A requirements statement can be compared against the solution statements proffered by respondents to an RFP. A solution statement for a software package forms the starting point for the implementation statement associated with a particular installation of that software package.
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.
About this Dataset
John Snow Labs; Health Level Seven International;
|Source License URL
|Source License Requirements
FHIR, HL7, Medical Terminology, Processes Data, Processes Information, Processes Documentation, Health Information Exchange, Electronic Health Records, FHIR Smart, Smart on FHIR
FHIR Capability Statement Resource, Electronic Health Records Exchange Through FHIR
|Name of the concept in the FHIR structure
|required : 1
|A Computer-ready name (e.g. a token) that identifies the structure - suitable for code generation. Note that this name (and other names relevant for code generation, including element & slice names, codes etc) may collide with reserved words in the relevant target language, and code generators will need to handle this.
|The type the structure describes.
|A free text natural language description of the structure and its use
|The value of the keyword should be an object or an array of objects. If the keyword value is an object, then for the data array to be valid each item of the array should be valid according to the schema in this value.
|The enum is used to restrict a value to a fixed set of values. It must be an array with at least one element, where each element is unique.
|The value of the keyword should be an array of unique strings. The data object to be valid should contain all properties with names equal to the elements in the keyword value.
|The value of this keyword can be anything. The data is valid if it is deeply equal to the value of the keyword.
|Computer Ready Name
|This is a CapabilityStatement resource
|The logical id of the resource
|The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
|A reference to a set of rules that were followed when the resource was constructed
|Extensions for implicitRules
|The base language in which the resource is written.
|Extensions for language
|A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data
|These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently
|May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and managable