forked from HL7/fhir-saner
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #52 from HL7/JiraChanges
Jira changes
- Loading branch information
Showing
239 changed files
with
307 additions
and
99,646 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,25 +1,28 @@ | ||
@startuml | ||
hide footbox | ||
participant "Measure Intermediary" as MeasureIntermediary | ||
participant "Measure Source" as MeasureSource | ||
|
||
actor "Public Health User" | ||
participant "Measure Consumer" as MeasureConsumer | ||
"MeasureIntermediary" -> "MeasureSource" : 1. Measure Consumer component of a Measure Intermediary gathers data from one or Measure Sources | ||
participant "Measure Source" as MeasureSource | ||
participant "Measure Intermediary/\nMeasure Consumer" as MeasureIntermediary | ||
|
||
|
||
"MeasureSource" -> "MeasureIntermediary" : 1. Measure Consumer component of a Measure Intermediary gathers data from one or Measure Sources | ||
activate "MeasureIntermediary" | ||
activate "MeasureSource" | ||
return | ||
deactivate "MeasureIntermediary" | ||
deactivate "MeasureSource" | ||
"Public Health User" -> "MeasureConsumer" : 2. User Initiates Search | ||
|
||
"Public Health User" -> "MeasureIntermediary" : 2. User Initiates Search | ||
activate "Public Health User" | ||
activate "MeasureConsumer" | ||
"MeasureConsumer" --> "Public Health User" : 3. Display Results | ||
"MeasureIntermediary" --> "Public Health User" : 3. Display Results | ||
deactivate "Public Health User" | ||
deactivate "MeasureConsumer" | ||
"Public Health User" -> "MeasureConsumer" : 4. User refines Focus or Form of Display | ||
|
||
"Public Health User" -> "MeasureIntermediary" : 4. User refines Focus or Form of Display | ||
|
||
activate "Public Health User" | ||
activate "MeasureConsumer" | ||
"MeasureConsumer" --> "Public Health User" : 5. Display Refined Results | ||
|
||
"MeasureIntermediary" --> "Public Health User" : 5. Display Refined Results | ||
|
||
deactivate "Public Health User" | ||
deactivate "MeasureConsumer" | ||
deactivate "MeasureIntermediary" | ||
@enduml |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
230 changes: 112 additions & 118 deletions
230
input/pagecontent/architecture.md → ...ontent/Architecture_and_Implementation.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,118 +1,112 @@ | ||
This guide envisions a system architecture comprised of small, easily deliverable | ||
components that can be used together to support deployment of reporting, analysis, | ||
alerting and data aggregation tools to support fast deployment of solutions supporting | ||
public health situation awareness. | ||
|
||
The technology uses for SANER includes both FHIR Servers and clients, | ||
implemented in or along side other [Health IT Systems](technology_environment.html) to | ||
support the [use cases](use_cases.html) of this IG. The use cases in turn are supported | ||
by the definitions of [actors](actors.html) that implement various [transactions](transactions.html) | ||
to implement the functionality described in this guide. These transactions exchange data | ||
conforming to [profiles](profiles_and_extensions.html) and using the [vocabulary](vocabulary.html) defined | ||
in this guide. | ||
|
||
### Major Components | ||
The major design components described by this guide support the following functions: | ||
|
||
* Reporting - Generates the data to be reported and make it available. | ||
* Presentation - Analyzes and display data. | ||
* Adaptation - Adapts between systems | ||
* FHIR Server - A FHIR Server is an obvious component in a FHIR based implementation guide. | ||
* External Storage - Stores data for later access. | ||
|
||
These functions are described in more detail in the sections below. | ||
|
||
### Reporting | ||
The reporting component is responsible for reporting utilization data known by an | ||
authoritative system in the hospital. There may be multiple authoritative systems | ||
for different kinds of reporting data. A reporting component will create FHIR Measurement | ||
Reports documenting the measures that are known to the authoritative system. These | ||
reports will be collected in some form of centralized storage or transmission solution. | ||
That solution could be as simple as a file system, or more complex (e.g., using | ||
cloud-based storage), and could involve different protocols, including S3, Azure Blob | ||
Storage, SFTP, or FHIR RESTful APIs and a FHIR Server. | ||
|
||
In this guide, the Reporting component is implemented by the [Measure Source](actors.html#measure-source) actor. | ||
|
||
### Presentation | ||
The presentation component selects some subset of available data and presents it to | ||
end users providing those users with the ability to interpret and act on the presented | ||
information. These components may generate maps showing hot spots based on some aspect | ||
of the measured data, charts and annotations of recent trends (e.g., current values | ||
plus projections over time), or other visualizations. | ||
|
||
In this guide, the Presentation component is implemented by the [Measure Consumer](actors.html#measure-consumer) actor. | ||
|
||
### Adapters | ||
Adapters bridge systems lacking certain capabilities with other systems requiring | ||
those capabilities, much like a ground adapter does with two pronged electrical outlet. | ||
|
||
In this guide, the Adapter component is implemented by the [Measure Intermediary](actors.html#measure-intermediary) actor. | ||
|
||
### FHIR Server | ||
Several off the shelf FHIR Server components exist which can be stood up in a data center | ||
or in the cloud to provide functionality that supports the FHIR Project. [HAPI on FHIR](https://hapifhir.io/) is | ||
a Java-based FHIR Server that is at the core of the [Smile CDR](https://smilecdr.com/) commercial | ||
offering. Microsoft offers the [Azure API for FHIR](https://azure.microsoft.com/en-us/services/azure-api-for-fhir/#overview). Firely offers | ||
[Vonk](https://fire.ly/products/vonk) which has both a free community edition and a commercial product. | ||
HL7 offers a page filled with [Open Source FHIR Server](https://wiki.hl7.org/Open_Source_FHIR_implementations) | ||
(and client) implementation software. | ||
|
||
The figure below shows a FHIR Server acting as an Intermediary between a Hospital and Public Health | ||
<div> | ||
{%include FHIRServer.svg%} | ||
<div> | ||
<!-- ![FHIR Server](FHIRServer.svg) --> | ||
|
||
However, a Hospital could simply configure it's own FHIR Server, and Public Health could then pull the data they need from it. | ||
<div> | ||
{%include PublicHealthPullFromHospital.svg%} | ||
<div> | ||
<!-- ![PublicHealthPullFromHospital](PublicHealthPullFromHospital.svg) --> | ||
|
||
Or, Public Health can configure it's own FHIR Server, and a Hospital can push the data to it. | ||
<div> | ||
{%include HospitalPushToPublicHealth.svg%} | ||
<div> | ||
<!-- ![HospitalPushToPublicHealth](HospitalPushToPublicHealth.svg) --> | ||
|
||
### External Storage | ||
Deployments can also use external storage, for example a file system, message queue, S3 bucket, Azure Blob Storage, SFTP, or even Direct Messaging | ||
to exchange data. In the figure below, a hospital pushes data to its own external storage, and public health pulls data from it. | ||
<div> | ||
{%include PublicHealthPullFromHospitalStorage.svg%} | ||
<div> | ||
<!-- ![Hospital Pushes To its own External Storage](PublicHealthPullFromHospitalStorage.svg) --> | ||
|
||
|
||
But a hospital might as easily push data to public health's external storage system. | ||
<div> | ||
{%include HospitalPushToPublicHealthStorage.svg%} | ||
<div> | ||
<!-- ![Hospital Pushes To Public Health Agency's External Storage](HospitalPushToPublicHealthStorage.svg) --> | ||
|
||
|
||
## Deployment | ||
System components are designed such that they can be individually deployed and configured. | ||
|
||
The following diagrams depict several different deployments with different responsibilties owned by a Hospital or Public Health Agency | ||
|
||
### Hospital Supported Infrastructure | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-0.svg%} | ||
<div> | ||
<!-- ![Hospital Supported Infrastructure](HospitalPushToExternalStorageAdaptedToPullAPI-0.svg) --> | ||
|
||
|
||
### Middle of the Road | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-1.svg%} | ||
<div> | ||
<!-- ![Middle of the Road](HospitalPushToExternalStorageAdaptedToPullAPI-1.svg) --> | ||
|
||
|
||
### Public Health Supported Infrastructure | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-2.svg%} | ||
<div> | ||
<!-- ![Public Health Supported Infrastructure](HospitalPushToExternalStorageAdaptedToPullAPI-2.svg) --> | ||
This guide envisions a system architecture comprised of small, easily deliverable | ||
components that can be used together to support deployment of reporting, analysis, | ||
alerting and data aggregation tools to support fast deployment of solutions supporting | ||
public health situational awareness. | ||
|
||
The technology uses for SANER includes both FHIR Servers and clients, | ||
implemented in or along side other [Health IT Systems](technology_environment.html) to | ||
support the [use cases](use_cases.html) of this IG. The use cases in turn are supported | ||
by the definitions of [actors](actors.html) that implement various [transactions](transactions.html) | ||
to implement the functionality described in this guide. These transactions exchange data | ||
conforming to [profiles](profiles_and_extensions.html) and using the [vocabulary](vocabulary.html) defined | ||
in this guide. | ||
|
||
### Major Components | ||
The major design components described by this guide support the following functions: | ||
|
||
* Reporting - Generates the data to be reported and make it available. | ||
* Presentation - Analyzes and display data. | ||
* Adaptation - Adapts between systems | ||
* FHIR Server - A FHIR Server is an obvious component in a FHIR based implementation guide. | ||
* External Storage - Stores data for later access. | ||
|
||
These functions are described in more detail in the sections below. | ||
|
||
### Reporting | ||
The reporting component is responsible for reporting utilization data known by an | ||
authoritative system in the hospital. There may be multiple authoritative systems | ||
for different kinds of reporting data. A reporting component will create FHIR Measurement | ||
Reports documenting the measures that are known to the authoritative system. These | ||
reports will be collected in some form of centralized storage or transmission solution. | ||
That solution could be as simple as a file system, or more complex (e.g., using | ||
cloud-based storage), and could involve different protocols, including S3, Azure Blob | ||
Storage, SFTP, or FHIR RESTful APIs and a FHIR Server. | ||
|
||
In this guide, the Reporting component is implemented by the [Measure Source](actors.html#measure-source) actor. | ||
|
||
### Presentation | ||
The presentation component selects some subset of available data and presents it to | ||
end users providing those users with the ability to interpret and act on the presented | ||
information. These components may generate maps showing hot spots based on some aspect | ||
of the measured data, charts and annotations of recent trends (e.g., current values | ||
plus projections over time), or other visualizations. | ||
|
||
In this guide, the Presentation component is implemented by the [Measure Consumer](actors.html#measure-consumer) actor. | ||
|
||
### Adapters | ||
Adapters bridge systems lacking certain capabilities with other systems requiring | ||
those capabilities, much like a ground adapter does with two pronged electrical outlet. | ||
|
||
In this guide, the Adapter component is implemented by the [Measure Intermediary](actors.html#measure-intermediary) actor. | ||
|
||
### FHIR Server | ||
Several off the shelf FHIR Server components exist, which can be stood up in a data center or in the cloud to provide functionality that supports the FHIR Project. HL7 offers a page filled with [Open Source FHIR Servers](https://wiki.hl7.org/Open_Source_FHIR_implementations) (and client) implementation software. | ||
|
||
The figure below shows a FHIR Server acting as an Intermediary between a Hospital and Public Health | ||
<div> | ||
{%include FHIRServer.svg%} | ||
<div> | ||
<!-- ![FHIR Server](FHIRServer.svg) --> | ||
|
||
However, a Hospital could simply configure its own FHIR Server, and Public Health could then pull the data they need from it. | ||
<div> | ||
{%include PublicHealthPullFromHospital.svg%} | ||
<div> | ||
<!-- ![PublicHealthPullFromHospital](PublicHealthPullFromHospital.svg) --> | ||
|
||
Or, Public Health can configure its own FHIR Server, and a Hospital can push the data to it. | ||
<div> | ||
{%include HospitalPushToPublicHealth.svg%} | ||
<div> | ||
<!-- ![HospitalPushToPublicHealth](HospitalPushToPublicHealth.svg) --> | ||
|
||
### External Storage | ||
Deployments can also use external storage, for example a file system, message queue, network or cloud storage, SFTP, or even Direct Messaging | ||
to exchange data. In the figure below, a hospital pushes data to its own external storage, and public health pulls data from it. | ||
<div> | ||
{%include PublicHealthPullFromHospitalStorage.svg%} | ||
<div> | ||
<!-- ![Hospital Pushes To its own External Storage](PublicHealthPullFromHospitalStorage.svg) --> | ||
|
||
|
||
But a hospital might as easily push data to public health's external storage system. | ||
<div> | ||
{%include HospitalPushToPublicHealthStorage.svg%} | ||
<div> | ||
<!-- ![Hospital Pushes To Public Health Agency's External Storage](HospitalPushToPublicHealthStorage.svg) --> | ||
|
||
|
||
### Deployment | ||
System components are designed such that they can be individually deployed and configured. | ||
|
||
The following diagrams depict several different deployments with different responsibilities owned by a Hospital or Public Health Agency | ||
|
||
#### Hospital Supported Infrastructure | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-0.svg%} | ||
<div> | ||
<!-- ![Hospital Supported Infrastructure](HospitalPushToExternalStorageAdaptedToPullAPI-0.svg) --> | ||
|
||
|
||
#### Middle of the Road | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-1.svg%} | ||
<div> | ||
<!-- ![Middle of the Road](HospitalPushToExternalStorageAdaptedToPullAPI-1.svg) --> | ||
|
||
|
||
#### Public Health Supported Infrastructure | ||
<div> | ||
{%include HospitalPushToExternalStorageAdaptedToPullAPI-2.svg%} | ||
<div> | ||
<!-- ![Public Health Supported Infrastructure](HospitalPushToExternalStorageAdaptedToPullAPI-2.svg) --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
|
||
Each of the measures or counts of groups of things such as available beds, ventilators, tests ordered, et cetera, with accompanying instructions describe (to a human) of what to include in a group creates a Measure which combine into a MeasureReport . A conceptual model of the Measure and MeasureReport artifacts appears below. | ||
<div> | ||
{%include ConceptualModel.svg%} | ||
</div> | ||
|
||
#### FHIR Resources | ||
The HL7 FHIR standard has similarly named resources that perform the same functions. | ||
A more detailed model about how these are related follows. | ||
* [MeasureReport](https://hl7.org/fhir/R4/MeasureReport) | ||
* [Measure](https://hl7.org/fhir/R4/Measure) | ||
|
||
<div> | ||
{%include Model.svg%} | ||
</div> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.