Technical proposal
for Medical File System
Technical proposal for Medical File System
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Backend
Back-end is server part of EHR system, it consists on components with different business and architectural features
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
We provide FHIR API, Subscriptions, GraphQL, and SQL API. It can be extended with Custom Operations.

Service supports all major versions of FHIR: DSTU2, STU3, and R4. Strict validation ensures data consistency and integrity for all FHIR resources. With ”Subscriptions”, users can execute custom logic in their applications when specific data is changing.

GraphQL API
System supports default GraphQL implementation without any extensions. It generates different GraphQL scalars, objects, queries with args and unions from FHIR metadata.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
Auth Server
An authentication server is used to verify credentials when a person or another server needs to prove who they are to an application. The Auth0 Identity Platform takes a modern approach to identity and enables organizations to provide secure access to any application, for any user. Auth0 is a highly customizable platform that is as simple as development teams want, and as flexible as they need.

OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation. It allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party identity provider (IDP) service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log in to multiple unrelated websites without having to have a separate identity and password for each. System has built-in OAuth 2.0 OpenID Connect server and can work as Resource Server.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
Access Control
Provides a flexible model to customize request authorization rules. User is allowed to declare a set of checks for all incoming requests. If the incoming request satisfies those checks, it's considered authorised and being processed further. Otherwise the request is denied and the client gets 403 Unauthorized. Such checks are declared with AccessPolicy resource.

Module HL7v2 / X12
Integration adapters comes with HL7 v.2 and X12 integration modules. Not all the systems that interact with modern healthcare application speak FHIR yet. Support of other interoperability standards takes a lot of burden from developers.

FHIR/Bulk API
Providing exchange data with external FHIR systems.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
Load API
Providing exchange data with external systems (any other custom formats).

Custom Resources
Resource has a type. All resource types are described with "meta-resources" - Entity and Attribute. Entity defines the resource or complex type and set of Attributes describe its structure. Not all healthcare data fits the FHIR data models. System allows adding custom resources and attributes with an easy update of metadata over RESTful API.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
FHIR Resources
System stores FHIR resources almost as is with 3 types of isomorphic transformations:
  • References
  • Union (Choice Types)
  • First-Class Extensions
In FHIR, references are represented as URI string. In most cases, you are interested in discrete parts of references like resource id and type. For performance and accuracy reasons System parses reference and stores its parts in discrete fields.
Union (Choice) Types: some elements can have multiple types.
First-Class Extensions - while FHIR uses two different ways to define core elements and extensions, System provides unified framework to describe both. It supports user-defined attributes or "first-class extensions". So, can define new attributes (elements) for existing (FHIR) resources.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
Subscriptions
This module is a way to subscribe and get notifications about updating resources on the server. It is a common denominator of FHIR R4/R5 subscriptions specification with some extensions.

This module introduces two new resources into System:
  • SubsSubscription — meta-resource which binds events (create/update/delete resource) with a communication channel through which subscriber is notified about changes.
  • SubsNotification — resource which represents notification with its status (sent or not).

SDKs
System integrates quickly and easily with an SDK that supports your development team's language of choice.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
REST API - FHIR, GraphQL, Reactive API & Subscriptions
Audit
System automatically logs all auth, API, database and network events, so in most cases basic audit log may be derived from System logs. FHIR Standard introduced AuditEvent resource which into FHIR ecosystem. System provides comprehensive FHIR API for AuditEvent resource.

Terminology
System terminology comes with FHIR, ICD-10, SNOMED, RxNorm, LOINC, and US NPI. Users can extend it with other terminologies and custom value sets.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Database
FHIR-aware PostgreSQL with SQL on FHIR support System uses PostgreSQL exclusively but squeezes everything out of this database technology. Most of System flexibility and performance is coming from advanced PostgreSQL features like binary JSON, rich indexing system, etc. SQL is the second System API, which gives you extra power on structured data.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
BI and Analytical tools
Export System data to Power BI, or any other analytical tools
and other BI systems
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Real-time integration pipeline
Export while importing data from CCDA documents, there are many nuances on every step. How does your system receive CCDA documents? What data elements do you want to persist? How would your system deduplicate patient records?

Because answers to those questions are strictly system-specific, System does not provide a ready-to-use solution here. But we can implement new pipeline, using any favourite technology stack.
Download PPTX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Receiving CCDA files
The first step is to understand how System would receive CCDA files. In case when we have an user-facing application like Patient Portal or EHR user will upload his CCDA file manually. The other common case is bulk import from remote storage like SFTP server or S3 bucket.

Processing received files is usually a resource consuming task, so it’s better to make it asynchronous. This way our system would be responsive while the file is being converted, and the entire conversion process would be much more manageable. For example, we may notice a bug in the CCDA converting logic, our engineers will fix it and we would like to process all recently received files. Holding all received files in a queue will give you this ability.

There are dozens of ways to set up such a queue, probably the most simple one is to use the DocumentReference resource (if we know a patient to whom this document belongs). Alternatively we can use a dedicated queue service like Apache Kafka or just a custom table in our RDBMS. However, despite the storage we would use, we would store the original CCDA file to be able to access it at any time.

On the next step some kind of background job or a worker will pick received files from a queue and process them one after another.