Introduction
This guide provides defintions and explanations for all of the components required to build and publish HSPC applications.
Overview
The HSPC development efforts exists to fulfill the mission of HSPC: "Improve health by creating a vibrant, open ecosystem of interoperable platforms, applications, and knowledge assets. The various systems, technologies, tools, and applications created by HSPC exist to enable the ecosystem."
HSPC Sandbox
The HSPC Sandbox is the heart of the HSPC ecosystem. The HSPC Sandbox is a place where a developer can build and test apps according to standards that allow the apps to be fully compatible with production systems from Healthcare industry leaders. The HSPC Sandbox provides EHR simulation, tools, and data to enable a user or a team of users to quickly bring an app to production.
HSPC Platform
The HSPC Platform are the backend systems that enable the HSPC Sandbox and support the FHIR and SMART on FHIR specifications. The HSPC Platform uses technologies such as MySQL, HAPI FHIR, JPA, OpenID Connect, OAuth2, Java, HTML, and JavaScript to build authentication servers, resource servers, messaging servers, and reference applications. The HSPC Platform artifacts are open source. A developer that is interested in platform components may host and extend HSPC Platform artifacts. A developer that is interested in app development should use the HSPC Sandbox and the hosted HSPC Platform components found there.
SMART on FHIR Apps
The SMART on FHIR specification defines how an app can become integrated within the EHR. EHR integration involves the following:
- The app being authorized to be launched from within the EHR.
- Gain context from
- Gain access to data within the EHR
Most of the tools and sample apps produced by HSPC are SMART on FHIR apps.
HL7 FHIR
For an application or system to be HSPC compatible it must use HL7 FHIR to exchange data. FHIR describes an object model, a messaging payload, and an API. FHIR users resources to model clinical and administrative concepts, profiles for semantic interoperability, and RESTful HTTP networking protocol. FHIR modeling efforts try to model the most common 80% of real-world object models as representations in FHIR Resources. To accommodate the less common 20%, FHIR Resources offer extension mechanisms.
Syntactic Interoperability
Syntactic interoperability refers to the ability of separate systems to use a common representation for structure. HSPC achieves syntactic interoperability using FHIR Resources. An example of syntactic interoperability is where two systems agree that a "patient" has a "first name" that is a xs:string and a "date of birth" that is a xs:date. Syntactic interoperability is the first level of interoperability.
Semantic Interoperability
Semantic interoperability refers to the ability of separate systems to understand each other. Semantic interoperability is buildt upon syntactic interoperability. HSPC achieves semantic interoperability using FHIR Profiles. An example of semantic interoperability is where two systems agree that a "patient" with a coded value for "ethnicity" will use the HL7 codes for ethnicity (http://www.hl7.org/fhir/v3/Ethnicity/index.html). There is a lot of modeling activity around different profiling efforts. Profiles that are known to the HL7 FHIR community can be found on the Profiles tab of the Resource definition (http://www.hl7.org/fhir/observation-profiles.html).
Detailed Clinical Models
From wiki.hl7.org: Detailed Clinical Models (DCM) are descriptions of items of clinical information that include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications. A DCM is a conceptual specification of the semantics of discrete structured clinical information. It provides the data elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and modelers.