FHIR Implementation Guide for Stroke
0.0.0 - ballot
FHIR Implementation Guide for Stroke - Local Development build (v0.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This FHIR IG uses terminology, notations, and design principles specific to the HL7 FHIR standard. It is important to be familiar with the basic principles of FHIR and how to read the FHIR specifications. Therefore, readers who are not familiar with FHIR are encouraged to review the following explanation before reading the rest of this IG.
Fast Healthcare Interoperability Resources (FHIR) is a platform specification from Health Level 7 (HL7) that supports the exchange of healthcare information between systems and health applications. Clinical data should be available and understandable when a patient moves through the healthcare ecosystem. To ensure this, FHIR defines a set of functionalities employed throughout the healthcare process, in all jurisdictions and many different contexts. FHIR is universally applicable, meaning it can be used in a wide variety of implementation environments, for example, data sharing based on electronic health records, mobile phone applications, and cloud communications. Additionally, FHIR has a strong focus on rapid and easy implementation, which lowers the barriers to entry for new developers working with FHIR.
FHIR is designed to standardize and enable the exchange of all health-related information. This includes not only clinical data but also administrative and health-related research data. FHIR can be used in both human and veterinary medicine and is applicable globally in a wide variety of contexts, including inpatient care, acute care, long-term care, outpatient care, community care, etc. One of the benefits of HL7 FHIR is that it is independent of any electronic health record vendor or health system. Furthermore, the specification is free for everyone to use and there are many public examples available to assist in the development of new applications.
The fundamental components of FHIR are called resources, which are represented in XML or JSON. A resource is considered a set of information, called data elements, used for exchanging or storing data. For example, the 'Patient' resource contains demographic and administrative details about the person being cared for. There are various resources, covering different aspects of the health domain, from patient management and research to medical billing and clinical reporting. The main goal is that a set of resources can cover most clinical use cases. This can be achieved by combining resources through references. For example, by associating 'Patient' with 'Observation' (which stores clinical findings of a patient), 'Condition' (problem or diagnosis), and 'Medication' (composition, dose, and indication of the medicines), you can implement and adapt to specific use cases.
A Profile establishes the use of a resource in a specific scenario. The term 'Profiling' refers to the act of applying constraints to the so-called essential resources. These resources are formulated by expert working groups to accommodate the most common use cases. Due to their generic nature, the rules in this specification are intentionally flexible. By applying a set of constraints to a FHIR resource, it can be adapted to a specific scenario. There is a high likelihood that you will need something precisely tailored to your domain when using FHIR. Consequently, the FHIR specification anticipates the need to apply constraints to existing resources to create a profile that meets your requirements. For this reason, you can find national, regional, or even hospital-specific profiles. FHIR has consciously chosen to cover 80% of the data elements used in health systems with its resources. The remaining 20% refer to specific use cases and can be managed as FHIR extensions. Extensions are additional resources that help address data not covered by the existing essential FHIR profiles of HL7.
To enhance interoperability, adopting standardized terminology is essential. By using uniform terminology, it's possible to collect, document, and process health information based on similar data concepts. This enables healthcare professionals to share and compare clinical knowledge in a consistent manner and within an internationally accepted system. FHIR cannot determine every code needed in global health systems, so instead, they have made available two resources to manage codes and their respective meanings, namely:
* CodeSystem is a set of codes that establishes various codes and their meanings. The concept of a CodeSystem is similar to a catalog, housing various codes and their definitions. A CodeSystem can be SNOMED-CT or LOINC, or even one you have created yourself.
* ValueSet specifies a selection of codes from one or more CodeSystems, intended for use in a specific context. A ValueSet contains links to the authentic codes of a particular CodeSystem. The advantage is that when a CodeSystem is updated, the ValueSets that include codes from that CodeSystem are also automatically updated.
The 'Must Support' annotation in this implementation guide is used to indicate that a specific element is mapped to a variable from the measure set and should be filled with data if available in the system.
In cases where an element cannot be filled due to its unavailability in the source system and if the cardinality rules allow, the element can be left blank. However, if the cardinality rules require that an element be filled, the 'Data Absent Reason' extension MUST be used."
For further reading, we recommended using the following links: