alexanderkiel

proxy_cache_path /tmp/nginx keys_zone=FHIR:10m;

# our origin server with added Cache-Control headers since HAPI has none
server {
    listen 8080;

    location / {
        proxy_pass http://hapi.fhir.org/;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header Cache-Control "public, must-revalidate, max-age=1";

alexanderkiel

library Retrieve
using FHIR version '4.0.0'
include FHIRHelpers version '4.0.0'

codesystem gender: 'http://hl7.org/fhir/administrative-gender'

context Patient

define InInitialPopulation:
  Patient.gender ~ Code 'male' from gender

alexanderkiel

import timeit
from array import array

def c_add(c1, c2):
    r1, i1 = c1
    r2, i2 = c2
    return (r1 + r2, i1 + i2)

def c_square(c):
    r, i = c

alexanderkiel

{
  "resourceType": "bundle",
  "entry": [
    {
      "fullUrl": "urn:uuid:38f5cc57-a667-4c44-b9a9-8e8ce1bd86a8",
      "resource": {
        "resourceType": "Patient",
        "name": {
          "family": "___________________________",
          "given": [

alexanderkiel

{
  "resourceType": "Bundle",
  "id": "Example-HIVSimple",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "https://intrahealth.github.io/simple-hiv-ig/Patient/Patient-HIVSimple",
      "resource": {
        "resourceType": "Patient",
        "id": "Patient-HIVSimple",

alexanderkiel

Flattening Concept

Problem Statement

Researchers like to have flat tables of the extracted DUP data. We have already TORCH which extracts the DUP data. In that process, TORCH creates one FHIR bundle per patient and a single core bundle with data not connected to a specific patient like medications.

The patient bundles contain FHIR resources according to the CDS profiles. However the data inside the resources is already minimised which is beneficial for the flattening process. On top of that we have the CRDTL description of every data extraction which contains all constraints the FHIR data fulfills on top of the constraints of the CDS profiles.

Flattening