cfu288 / mere-medical Goto Github PK

An offline-first, self-hosted web app to aggregate and sync all of your medical records from your patient portals in one place.

License: GNU Affero General Public License v3.0

Shell 0.09% TypeScript 97.65% JavaScript 1.23% HTML 0.09% CSS 0.60% Dockerfile 0.30% MDX 0.04%

mere-medical's Introduction

Mere Medical

A personal health record to aggregate and sync all of your medical records from multiple patient portals in one place. Currently supports thousands of hospitals and clinics and major electronic medical record systems. Self-hosted, privacy-focused, and offline-first.

See Docs • View Demo

Warning

Mere is currently pre-release software: updates may break backwards compatibility.

Note

This project is supported by a single developer who is also a full-time medical resident. If you would like to support this project, please consider donating or help by tackling one of the issues.

Note

If Mere doesn't fit your needs, another great open-source PHR is Fasten Health

What is Mere Medical

Mere Medical is a self-hosted web app to aggregate and sync all of your medical records from all your doctor and hospital visits in one place. See everything in a timeline view or quickly summarize your records.

Getting Started

Here are some ways to get Mere Medical running on your local computer

Docker Compose

version: '3.9'

services:
  app:
    image: cfu288/mere-medical:latest
    ports:
      - '4200:80'
    environment:
      - ONPATIENT_CLIENT_ID=${ONPATIENT_CLIENT_ID}
      - ONPATIENT_CLIENT_SECRET=${ONPATIENT_CLIENT_SECRET}
      - EPIC_CLIENT_ID=${EPIC_CLIENT_ID}
      - EPIC_SANDBOX_CLIENT_ID=${EPIC_SANDBOX_CLIENT_ID}
      - CERNER_CLIENT_ID=${CERNER_CLIENT_ID}
      - VERADIGM_CLIENT_ID=${VERADIGM_CLIENT_ID}
      - PUBLIC_URL=${PUBLIC_URL}

(back to top)

Local Development

Prerequisites

npm
nvm
Docker
nx

Installation

Clone the repo

git clone https://github.com/cfu288/mere-medical.git

Set up NPM and install NPM packages

nvm install v20.11.0
nvm use
npm install

If Nx is not installed, install it
```
npm i nx -g
```
if you are prompted to run migrations, run the following:
```
npx nx migrate --run-migrations
```

Create .env files for each project to run and fill with values

cp apps/api/.example.env apps/api/.env

vim apps/web/src/environments/config.json

Generate localhost ssl certs

mkdir -p .dev/certs
mkcert -key-file .dev/certs/localhost-key.pem -cert-file .dev/certs/localhost.pem localhost
mkcert -install

Serve each one on its own:

npx nx serve web
npx nx serve api

or together as a full app:

npx nx run-many --target=serve --projects=api,web

Run e2e tests
```
npx nx run web-e2e:e2e
```

Build and serve in docker container:

docker build -t mere-medical .
docker run -p 4200:80 -i -t \
  --name mere-medical \
  -e ONPATIENT_CLIENT_ID=<> \
  -e ONPATIENT_CLIENT_SECRET=<> \
  -e EPIC_CLIENT_ID=<> \
  -e EPIC_SANDBOX_CLIENT_ID=<> \
  -e CERNER_CLIENT_ID=<> \
  -e VERADIGM_CLIENT_ID=<ID_HERE> \
  -e PUBLIC_URL=https://localhost:4200 \
  mere-medical:latest

(back to top)

Design Goals

Respect user autonomy and user control.
Prioritize privacy/security and UX - if those are in conflict, ask the user what they would prefer but default to security.
Be transparent about decisions on data storage, handling, and usage.
Where feasible, build features to be local first (run on the users device). This essentially means client side/offline first. Mere's core functionality should continue to work without any internet connection.
For features that cannot be client-side, enable users to self-host server side functionality where feasible. This means that the user should be able to run Mere on their own server and not rely on a third party.
Optionally fall back to third party services when self-hosting is not feasible. Should only apply to features that are not core functionality and should always be opt-in.

(back to top)

mere-medical's People

Contributors

Stargazers

Watchers

Forkers

quadblassengale modernmediagrp reanimatedmanx ranaviveksingh publichealthinformationtechnology acastro5

mere-medical's Issues

[MAR-35] Monorepo cleanup

~~move nginx and docker files into subfolders~~
Fix eslint
fix jest
reorganize into libs (https://nx.dev/getting-started/integrated-repo-tutorial#local-linking-of-packages)
fix doc site to better fit nx (https://nx.dev/recipes/executors/run-commands-executor)
update readme to use github links
~~add simple smoke tests~~

_{From SyncLinear.com | MAR-35}

[MAR-41] Enable background medical record sync after a new connection is established/connection has not been refreshed for a day

Currently this process runs on the main thread. Moving this to a worker thread would improve performance and enable other stories to be completed as well.

_{From SyncLinear.com | MAR-41}

[MAR-54] Add Cerner EMR support

Allow users with patient portals on Cerner to use Mere

_{From SyncLinear.com | MAR-54}

[MAR-15] 1-Click deploy to digital ocean

Make deploying Mari Medical simple for new users

_{From SyncLinear.com | MAR-15}

[MAR-60] Add support for Athena Patient Portal

_{From SyncLinear.com | MAR-60}

[MAR-23] Explore how to handle cors issue in some EPIC sync

Tech or reach out to support? have backend handle?

_{From SyncLinear.com | MAR-23}

[MAR-27] Handle lab panel 0 values not rendering

_{From SyncLinear.com | MAR-27}

[MAR-61] Improve connection sync job management

Right now, connection sync jobs are triggered when a user visits the connections tab. Instead, it should be triggered whenever someone opens the app if a connection has not been updated in a day.

_{From SyncLinear.com | MAR-61}

[MAR-9] Implement offline mode with service workers

_{From SyncLinear.com | MAR-9}

[MAR-16] Make front end and back end deployable from a single container

_{From SyncLinear.com | MAR-16}

[MAR-40] Allow for backup import

Allow user to import a backup to restore data

_{From SyncLinear.com | MAR-40}

[MAR-36] Add smoke e2e tests

There is some infrastructure set up for unit tests and e2e tests, but testing is a current weak spot of Mere. Any PRs with tests would be appreciated.

_{From SyncLinear.com | MAR-36}

[MAR-3] Handle data export

Allow for export of data to csv or json

_{From SyncLinear.com | MAR-3}

[MAR-32] Edit user data

Allow a user to update their data in settings

_{From SyncLinear.com | MAR-32}

[MAR-45] [MAR-30] Enable user setting - Enable/Disable proxying

_{From SyncLinear.com | MAR-30}

_MAR-45

[MAR-52] Add FHIR R4 Support

Currently Mere supports DSTU2 only as some EMR's only support DSTU2. However, R4 supports new data resources like Encounter that would be very helpful. May need to decouple a few ui elements from DSTU2

_{From SyncLinear.com | MAR-52}

[MAR-2] Allow multiple users

Allow for the app to handle multiple users, each with their own medical records

_{From SyncLinear.com | MAR-2}

[MAR-39] Allow encrypted export

Allow user to export data as a blob or zip file.

Need to decide on how to best encrypt. AES 256 with PBKDF2? bcrypt, scrypt, Argon2

Research

PBKDF2 as a symmetric key

Another popular way PBKDF2 is used is as a means of turning a user supplied password into a symmetric key suitable for use with the AES algorithm. This relies on the fact that AES can use anby value as its input that meets certain length and entropy requirements and that PBKDF2 can produce a hash of any length which meets those requirements for entropy.

_{From SyncLinear.com | MAR-39}

[MAR-13] Update marketing page to reflect self-hostability and remove user sign-ups

_{From SyncLinear.com | MAR-13}

[MAR-63] Add true notification handling in app, where users can view, act on, and dismiss notifications

We currently have "notifications" in app, but they're more like alert pop ups that are temporary and non persistent. Enabling a notification panel can allow for long term notifications to users and allow users to interact and see long term background processes.

_{From SyncLinear.com | MAR-63}

[MAR-6] Handle deletion of one connection source without deleting the entire database

_{From SyncLinear.com | MAR-6}

[MAR-38] Disable OnPatient login without proxy enabled

_{From SyncLinear.com | MAR-38}

[MAR-20] Add error notifications

Use cases:

Failed login

_{From SyncLinear.com | MAR-20}

[MAR-22] Allow for refresh of data

For epic and onpatient

_{From SyncLinear.com | MAR-22}

[MAR-7] Add password protection and encryption to records

As a user, I'd love to be able to back up and sync my medical records to a "off-device" location of my choosing and have it automatically and securely sync my records across all of my devices.

Question / Clarification Areas

Do users want to sync their records to a db (postgres/couchDb, can be self hosted), or sync their records to a location of their choosing (dropbox, google drive, other storage) as a blob file. Or maybe they want both options? Each option has its pros and cons

Maybe this story can be split into two stories where we implement both - encrypted blob export and import with syncing of the blob to a user defined location (dropbox/local machines), AND later also implement opt-in sync of records to a DB (self hosted or cloud)

Notes

Data is mostly JSON, but can be images and PDF's in the future as well

Discussion

We want users to be able to both securely encrypt their medical data and back it up offline or offsite, while being able to efficiently and quickly sync their data across devices.

As we use RxDB as our in-browser database (essentially a wrapper on IndexedDB and PouchDB), we get some syncing and encryption features out of the box. The syncing feature is neat - RxDB can auto sync to a backend db and handle document conflict management. However, the question is whether or not these built encryption option is actually secure enough. RxDB only encrypts by field and needs to be explicitly marked as encrypted in the DB schema and does not encrypt entire documents or databases. Queryable fields cannot be encrypted as it prevents RxDB from working, so some metadata will always be exposed. Fields are AES encrypted, but only using a provided "password". Some work would need to go into figuring out how to make the password have enough entropy.

An alternative is just dumping the entire db from RxDB as JSON, encrypting the blob, and re-importing/decrypting as needed. This is simpler in a lot of ways and can be made more secure, as we're not selectively encrypting specific fields. We do lose out on the ability to sync just new documents as we have to send over the entire blob. We can also use more generic cloud services as save targets

To summarize, currently the main choices are:

Prefer syncing at the possible expense of less secure data
Prefer more security at the expense of inefficient data syncing

There are some more options in between these two extremes but I just wanted to highlight the primary choices.

Other things to consider - secret/password strategy - Need to sort out how to make passwords strong enough to encrypt a blob. Kevin suggested using a one-password like encrypted blob (secret key + password).

_{From SyncLinear.com | MAR-7}

[MAR-21] Timeline "Summary" Cards

Because of various implementation inconsistencies, we can't just save the records from each EMR and display them to the user. This also prevents us from synthesizing "second order" views, or more complex views that are more than displaying a single record (may be a combination of multiple records). Right now the timeline view is basically a data dump of the db - with each raw record mapping to a card. As we started to do more complex views like DiagnosicReports which is really a combination of multiple records, we started having subqueries and hacky workarounds done on each render to make these multiple records show up as one card. Its hard to know which Observations have already been connected to a diagnostic report and which ones have not, so we don't know which ones to show and which ones to hide. This is a problem later on if we need to show observations that are not actually linked to a DR, like maybe vitals or other observations.

We need to decouple the timeline view from the raw records, that way we can leave the raw records as is without any hacky modifications to them during sync, but generate a new layer of records from the raw records for the timeline to read from. These "view" records can be run sort of like a cron job → after a sync or on a regular basis. The timeline would just pull from the view records, not directly from the raw saved records. This would also be more efficient with larger sets of health records - no re-rendering and recalculating views every time the timeline is opened.

_{From SyncLinear.com | MAR-21}

[MAR-18] Explore the use of origin-private-file-system for local file storage

_{From SyncLinear.com | MAR-18}

[MAR-4] Integrate with Epic EMR

Allow for app to sync records Epic EMR

Support the following DSTU2 endpoints:

AllergyIntolerance.Read
AllergyIntolerance.Search
Binary.Read
CarePlan.Read
CarePlan.Search
Condition.Read
Condition.Search
Device.Read
Device.Search
DiagnosticReport.Read
DiagnosticReport.Search
DocumentReference.Read
DocumentReference.Search
Goal.Read
Goal.Search
Immunization.Read
Immunization.Search
Medication.Read
Medication.Search
MedicationOrder.Read
MedicationOrder.Search
MedicationStatement.Read
MedicationStatement.Search
Observation.Read
Observation.Search
Patient.Read
Patient.Search
Practitioner.Read
Practitioner.Search
Procedure.Read
Procedure.Search

_{From SyncLinear.com | MAR-4}

[MAR-33] Update user photo

_{From SyncLinear.com | MAR-33}

[MAR-8] Enable sync with CouchDB

or consider using gql and postgres

_{From SyncLinear.com | MAR-8}

[MAR-42] Dynamic registration only allows for 1 device to be registered at a time on Epic

When authenticating to an Epic source using the dynamic registration flow, only one device (aka one private key) can be registered at a time. Since we don't currently share private keys across devices, only the last signed in device can refresh data. Any devices (privkeys) that were previously registered to the same epic source become unregistered

_{From SyncLinear.com | MAR-42}

[MAR-31] Show exclamation mark next to abnormal lab value cards

_{From SyncLinear.com | MAR-31}

[MAR-19] Add notification button and panel

Needed for onboarding exp

_{From SyncLinear.com | MAR-19}

[MAR-48] Set up demo instance of mere medical at demo.meremedical.co with mock data

Users should be able to see a instance of mere medical with mock medical data on the demo site to better understand how the product works. Right now app.meremedical.co directs them to a fully working instance of the app with no mock data, making it hard to visualize how the app works. It would be helpful for prospective users to see how mere medical could look if they used it.

_{From SyncLinear.com | MAR-48}

[MAR-44] [MAR-10] Create onboarding flow

Welcome screen
Install PWA - on iOS with reason. Check if android gives user a prompt, if not also show separate screen
Add first connection
Future: Add server to sync to
Future: Encryption password
Should not be visible if instance is a demo instance

_{From SyncLinear.com | MAR-10}

_{From SyncLinear.com | MAR-46}

{
  ADMISSION_DIAGNOSIS_SECTION: [ "2.16.840.1.113883.10.20.22.2.43" ],
  ADMISSION_MEDICATION: [ "2.16.840.1.113883.10.20.22.4.36" ],
  ADMISSION_MEDICATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.44" ],
  ADVANCE_DIRECTIVES_SECTION: [ "2.16.840.1.113883.10.20.22.2.21", "2.16.840.1.113883.10.20.22.2.21.1" ],
  ADVANCE_DIRECTIVE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.48" ],
  ADVANCE_DIRECTIVE_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.108" ],
  AGE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.31" ],
  ALLERGIES_AND_INTOLERANCES_SECTION: [ "2.16.840.1.113883.10.20.22.2.6", "2.16.840.1.113883.10.20.22.2.6.1" ],
  ALLERGY_CONCERN_ACT: [ "2.16.840.1.113883.10.20.22.4.30" ],
  ALLERGY_INTOLERANCE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.7" ],
  ALLERGY_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.28" ],
  ANESTHESIA_SECTION: [ "2.16.840.1.113883.10.20.22.2.25" ],
  ASSESSMENT_AND_PLAN_SECTION: [ "2.16.840.1.113883.10.20.22.2.9" ],
  ASSESSMENT_SCALE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.69" ],
  ASSESSMENT_SCALE_SUPPORTING_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.86" ],
  ASSESSMENT_SECTION: [ "2.16.840.1.113883.10.20.22.2.8" ],
  AUTHORIZATION_ACTIVITY: [ "2.16.840.1.113883.10.20.1.19" ],
  AUTHOR_PARTICIPATION: [ "2.16.840.1.113883.10.20.22.4.119" ],
  BIRTH_SEX_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.200" ],
  BOUNDARY_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.11" ],
  BRAND_NAME_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.301" ],
  CAREGIVER_CHARACTERISTICS: [ "2.16.840.1.113883.10.20.22.4.72" ],
  CARE_PLAN: [ "2.16.840.1.113883.10.20.22.1.15" ],
  CARE_TEAMS_SECTION: [ "2.16.840.1.113883.10.20.22.2.500" ],
  CARE_TEAM_MEMBER_ACT: [ "2.16.840.1.113883.10.20.22.4.500.1" ],
  CARE_TEAM_MEMBER_SCHEDULE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.500.3" ],
  CARE_TEAM_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.500" ],
  CARE_TEAM_TYPE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.500.2" ],
  CATALOG_NUMBER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.302" ],
  CHARACTERISTICS_OF_HOME_ENVIRONMENT: [ "2.16.840.1.113883.10.20.22.4.109" ],
  CHIEF_COMPLAINT_AND_REASON_FOR_VISIT_SECTION: [ "2.16.840.1.113883.10.20.22.2.13" ],
  CHIEF_COMPLAINT_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1" ],
  CODE_OBSERVATIONS: [ "2.16.840.1.113883.10.20.6.2.13" ],
  COGNITIVE_STATUS_PROBLEM_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.73" ],
  COMMENT_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.64" ],
  COMPANY_NAME_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.303" ],
  COMPLICATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.37" ],
  CONSULTATION_NOTE: [ "2.16.840.1.113883.10.20.22.1.4" ],
  CONTINUITY_OF_CARE_DOCUMENT: [ "2.16.840.1.113883.10.20.22.1.2" ],
  COURSE_OF_CARE_SECTION: [ "2.16.840.1.113883.10.20.22.2.64" ],
  COVERAGE_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.60" ],
  CRITICALITY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.145" ],
  CULTURAL_AND_RELIGIOUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.111" ],
  DATE_OF_DIAGNOSIS_ACT: [ "2.16.840.1.113883.10.20.22.4.502" ],
  DECEASED_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.79" ],
  DEVICE_IDENTIFIER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.304" ],
  DIAGNOSTIC_IMAGING_REPORT: [ "2.16.840.1.113883.10.20.22.1.5" ],
  DICOM_OBJECT_CATALOG_SECTION_DCM_121181: [ "2.16.840.1.113883.10.20.6.1.1" ],
  DISCHARGE_DIAGNOSIS_SECTION: [ "2.16.840.1.113883.10.20.22.2.24" ],
  DISCHARGE_DIET_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.33" ],
  DISCHARGE_MEDICATION: [ "2.16.840.1.113883.10.20.22.4.35" ],
  DISCHARGE_MEDICATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.11", "2.16.840.1.113883.10.20.22.2.11.1" ],
  DISCHARGE_SUMMARY: [ "2.16.840.1.113883.10.20.22.1.8" ],
  DISTINCT_IDENTIFICATION_CODE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.308" ],
  DRUG_MONITORING_ACT: [ "2.16.840.1.113883.10.20.22.4.123" ],
  DRUG_VEHICLE: [ "2.16.840.1.113883.10.20.22.4.24" ],
  ENCOUNTERS_SECTION: [ "2.16.840.1.113883.10.20.22.2.22", "2.16.840.1.113883.10.20.22.2.22.1" ],
  ENCOUNTER_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.49" ],
  ENCOUNTER_DIAGNOSIS: [ "2.16.840.1.113883.10.20.22.4.80" ],
  ENTRY_REFERENCE: [ "2.16.840.1.113883.10.20.22.4.122" ],
  ESTIMATED_DATE_OF_DELIVERY: [ "2.16.840.1.113883.10.20.15.3.1" ],
  EXPIRATION_DATE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.309" ],
  EXTERNAL_DOCUMENT_REFERENCE: [ "2.16.840.1.113883.10.20.22.4.115" ],
  FAMILY_HISTORY_DEATH_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.47" ],
  FAMILY_HISTORY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.46" ],
  FAMILY_HISTORY_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.45" ],
  FAMILY_HISTORY_SECTION: [ "2.16.840.1.113883.10.20.22.2.15" ],
  FETUS_SUBJECT_CONTEXT: [ "2.16.840.1.113883.10.20.6.2.3" ],
  FINDINGS_SECTION: [ "2.16.840.1.113883.10.20.6.1.2" ],
  FUNCTIONAL_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.67" ],
  FUNCTIONAL_STATUS_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.66" ],
  FUNCTIONAL_STATUS_PROBLEM_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.68" ],
  FUNCTIONAL_STATUS_SECTION: [ "2.16.840.1.113883.10.20.22.2.14" ],
  GENDER_IDENTITY_OBSERVATION: [ "2.16.840.1.113883.10.20.34.3.45" ],
  GENERAL_STATUS_SECTION: [ "2.16.840.1.113883.10.20.2.5" ],
  GOALS_SECTION: [ "2.16.840.1.113883.10.20.22.2.60" ],
  GOAL_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.121" ],
  HANDOFF_COMMUNICATION_PARTICIPANTS: [ "2.16.840.1.113883.10.20.22.4.141" ],
  HEALTH_CONCERNS_SECTION: [ "2.16.840.1.113883.10.20.22.2.58" ],
  HEALTH_CONCERN_ACT: [ "2.16.840.1.113883.10.20.22.4.132" ],
  HEALTH_STATUS_EVALUATIONS_AND_OUTCOMES_SECTION: [ "2.16.840.1.113883.10.20.22.2.61" ],
  HEALTH_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.5" ],
  HIGHEST_PRESSURE_ULCER_STAGE: [ "2.16.840.1.113883.10.20.22.4.77" ],
  HISTORY_AND_PHYSICAL: [ "2.16.840.1.113883.10.20.22.1.3" ],
  HISTORY_OF_PRESENT_ILLNESS_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.4" ],
  HOSPITAL_ADMISSION_DIAGNOSIS: [ "2.16.840.1.113883.10.20.22.4.34" ],
  HOSPITAL_CONSULTATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.42" ],
  HOSPITAL_COURSE_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.5" ],
  HOSPITAL_DISCHARGE_DIAGNOSIS: [ "2.16.840.1.113883.10.20.22.4.33" ],
  HOSPITAL_DISCHARGE_INSTRUCTIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.41" ],
  HOSPITAL_DISCHARGE_PHYSICAL_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.26" ],
  HOSPITAL_DISCHARGE_STUDIES_SUMMARY_SECTION: [ "2.16.840.1.113883.10.20.22.2.16" ],
  IMMUNIZATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.2", "2.16.840.1.113883.10.20.22.2.2.1" ],
  IMMUNIZATION_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.52" ],
  IMMUNIZATION_MEDICATION_INFORMATION: [ "2.16.840.1.113883.10.20.22.4.54" ],
  IMMUNIZATION_REFUSAL_REASON: [ "2.16.840.1.113883.10.20.22.4.53" ],
  IMPLANTABLE_DEVICE_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.305" ],
  IMPLANTS_SECTION: [ "2.16.840.1.113883.10.20.22.2.33" ],
  INDICATION: [ "2.16.840.1.113883.10.20.22.4.19" ],
  INSTRUCTION: [ "2.16.840.1.113883.10.20.22.4.20" ],
  INSTRUCTIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.45" ],
  INTERVENTIONS_SECTION: [ "2.16.840.1.113883.10.20.21.2.3" ],
  INTERVENTION_ACT: [ "2.16.840.1.113883.10.20.22.4.131" ],
  LATEX_SAFETY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.314" ],
  LONGITUDINAL_CARE_WOUND_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.114" ],
  LOT_OR_BATCH_NUMBER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.315" ],
  MANUFACTURING_DATE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.316" ],
  MEDICAL_EQUIPMENT_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.135" ],
  MEDICAL_EQUIPMENT_SECTION: [ "2.16.840.1.113883.10.20.22.2.23" ],
  MEDICAL_HISTORY_SECTION: [ "2.16.840.1.113883.10.20.22.2.39" ],
  MEDICATIONS_ADMINISTERED_SECTION: [ "2.16.840.1.113883.10.20.22.2.38" ],
  MEDICATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.1", "2.16.840.1.113883.10.20.22.2.1.1" ],
  MEDICATION_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.16" ],
  MEDICATION_DISPENSE: [ "2.16.840.1.113883.10.20.22.4.18" ],
  MEDICATION_FREE_TEXT_SIG: [ "2.16.840.1.113883.10.20.22.4.147" ],
  MEDICATION_INFORMATION: [ "2.16.840.1.113883.10.20.22.4.23" ],
  MEDICATION_SUPPLY_ORDER: [ "2.16.840.1.113883.10.20.22.4.17" ],
  MENTAL_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.74" ],
  MENTAL_STATUS_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.75" ],
  MENTAL_STATUS_SECTION: [ "2.16.840.1.113883.10.20.22.2.56" ],
  MODEL_NUMBER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.317" ],
  MRI_SAFETY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.318" ],
  NON_MEDICINAL_SUPPLY_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.50" ],
  NOTES_SECTION: [ "2.16.840.1.113883.10.20.22.2.65" ],
  NOTE_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.202" ],
  NUMBER_OF_PRESSURE_ULCERS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.76" ],
  NUTRITIONAL_STATUS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.124" ],
  NUTRITION_ASSESSMENT: [ "2.16.840.1.113883.10.20.22.4.138" ],
  NUTRITION_RECOMMENDATION: [ "2.16.840.1.113883.10.20.22.4.130" ],
  NUTRITION_SECTION: [ "2.16.840.1.113883.10.20.22.2.57" ],
  OBJECTIVE_SECTION: [ "2.16.840.1.113883.10.20.21.2.1" ],
  OBSERVER_CONTEXT: [ "2.16.840.1.113883.10.20.6.2.4" ],
  OPERATIVE_NOTE: [ "2.16.840.1.113883.10.20.22.1.7" ],
  OPERATIVE_NOTE_FLUIDS_SECTION: [ "2.16.840.1.113883.10.20.7.12" ],
  OPERATIVE_NOTE_SURGICAL_PROCEDURE_SECTION: [ "2.16.840.1.113883.10.20.7.14" ],
  OUTCOME_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.144" ],
  PAST_MEDICAL_HISTORY: [ "2.16.840.1.113883.10.20.22.2.20" ],
  PATIENT_REFERRAL_ACT: [ "2.16.840.1.113883.10.20.22.4.140" ],
  PAYERS_SECTION: [ "2.16.840.1.113883.10.20.22.2.18" ],
  PHYSICAL_EXAM_SECTION: [ "2.16.840.1.113883.10.20.2.10" ],
  PHYSICIAN_OF_RECORD_PARTICIPANT: [ "2.16.840.1.113883.10.20.6.2.2" ],
  PHYSICIAN_READING_STUDY_PERFORMER: [ "2.16.840.1.113883.10.20.6.2.1" ],
  PLANNED_ACT: [ "2.16.840.1.113883.10.20.22.4.39" ],
  PLANNED_COVERAGE: [ "2.16.840.1.113883.10.20.22.4.129" ],
  PLANNED_ENCOUNTER: [ "2.16.840.1.113883.10.20.22.4.40" ],
  PLANNED_IMMUNIZATION_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.120" ],
  PLANNED_INTERVENTION_ACT: [ "2.16.840.1.113883.10.20.22.4.146" ],
  PLANNED_MEDICATION_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.42" ],
  PLANNED_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.44" ],
  PLANNED_PROCEDURE: [ "2.16.840.1.113883.10.20.22.4.41" ],
  PLANNED_PROCEDURE_SECTION: [ "2.16.840.1.113883.10.20.22.2.30" ],
  PLANNED_SUPPLY: [ "2.16.840.1.113883.10.20.22.4.43" ],
  PLAN_OF_TREATMENT_SECTION: [ "2.16.840.1.113883.10.20.22.2.10" ],
  POLICY_ACTIVITY: [ "2.16.840.1.113883.10.20.22.4.61" ],
  POSTOPERATIVE_DIAGNOSIS_SECTION: [ "2.16.840.1.113883.10.20.22.2.35" ],
  POSTPROCEDURE_DIAGNOSIS: [ "2.16.840.1.113883.10.20.22.4.51" ],
  POSTPROCEDURE_DIAGNOSIS_SECTION: [ "2.16.840.1.113883.10.20.22.2.36" ],
  PRECONDITION_FOR_SUBSTANCE_ADMINISTRATION: [ "2.16.840.1.113883.10.20.22.4.25" ],
  PREGNANCY_OBSERVATION: [ "2.16.840.1.113883.10.20.15.3.8" ],
  PREOPERATIVE_DIAGNOSIS: [ "2.16.840.1.113883.10.20.22.4.65" ],
  PREOPERATIVE_DIAGNOSIS_SECTION: [ "2.16.840.1.113883.10.20.22.2.34" ],
  PRESSURE_ULCER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.70" ],
  PRIORITY_PREFERENCE: [ "2.16.840.1.113883.10.20.22.4.143" ],
  PROBLEM_CONCERN_ACT: [ "2.16.840.1.113883.10.20.22.4.3" ],
  PROBLEM_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.4" ],
  PROBLEM_SECTION: [ "2.16.840.1.113883.10.20.22.2.5", "2.16.840.1.113883.10.20.22.2.5.1" ],
  PROBLEM_STATUS: [ "2.16.840.1.113883.10.20.22.4.6" ],
  PROCEDURES_SECTION: [ "2.16.840.1.113883.10.20.22.2.7", "2.16.840.1.113883.10.20.22.2.7.1" ],
  PROCEDURE_ACTIVITY_ACT: [ "2.16.840.1.113883.10.20.22.4.12" ],
  PROCEDURE_ACTIVITY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.13" ],
  PROCEDURE_ACTIVITY_PROCEDURE: [ "2.16.840.1.113883.10.20.22.4.14" ],
  PROCEDURE_CONTEXT: [ "2.16.840.1.113883.10.20.6.2.5" ],
  PROCEDURE_DESCRIPTION_SECTION: [ "2.16.840.1.113883.10.20.22.2.27" ],
  PROCEDURE_DISPOSITION_SECTION: [ "2.16.840.1.113883.10.20.18.2.12" ],
  PROCEDURE_ESTIMATED_BLOOD_LOSS_SECTION: [ "2.16.840.1.113883.10.20.18.2.9" ],
  PROCEDURE_FINDINGS_SECTION: [ "2.16.840.1.113883.10.20.22.2.28" ],
  PROCEDURE_IMPLANTS_SECTION: [ "2.16.840.1.113883.10.20.22.2.40" ],
  PROCEDURE_INDICATIONS_SECTION: [ "2.16.840.1.113883.10.20.22.2.29" ],
  PROCEDURE_NOTE: [ "2.16.840.1.113883.10.20.22.1.6" ],
  PROCEDURE_SPECIMENS_TAKEN_SECTION: [ "2.16.840.1.113883.10.20.22.2.31" ],
  PRODUCT_INSTANCE: [ "2.16.840.1.113883.10.20.22.4.37" ],
  PROGNOSIS_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.113" ],
  PROGRESS_NOTE: [ "2.16.840.1.113883.10.20.22.1.9" ],
  PROGRESS_TOWARD_GOAL_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.110" ],
  PROVENANCE_ASSEMBLER_PARTICIPATION: [ "2.16.840.1.113883.10.20.22.5.7" ],
  PROVENANCE_AUTHOR_PARTICIPATION: [ "2.16.840.1.113883.10.20.22.5.6" ],
  PURPOSE_OF_REFERENCE_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.9" ],
  QUANTITY_MEASUREMENT_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.14" ],
  REACTION_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.9" ],
  REASON_FOR_REFERRAL_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.1" ],
  REASON_FOR_VISIT_SECTION: [ "2.16.840.1.113883.10.20.22.2.12" ],
  REFERENCED_FRAMES_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.10" ],
  REFERRAL_NOTE: [ "2.16.840.1.113883.10.20.22.1.14" ],
  RESULTS_SECTION: [ "2.16.840.1.113883.10.20.22.2.3", "2.16.840.1.113883.10.20.22.2.3.1" ],
  RESULT_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.2" ],
  RESULT_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.1" ],
  REVIEW_OF_SYSTEMS_SECTION: [ "1.3.6.1.4.1.19376.1.5.3.1.3.18" ],
  RISK_CONCERN_ACT: [ "2.16.840.1.113883.10.20.22.4.136" ],
  SECTION_TIME_RANGE_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.201" ],
  SELF_CARE_ACTIVITIES: [ "2.16.840.1.113883.10.20.22.4.128" ],
  SENSORY_STATUS: [ "2.16.840.1.113883.10.20.22.4.127" ],
  SERIAL_NUMBER_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.319" ],
  SERIES_ACT: [ "2.16.840.1.113883.10.20.22.4.63" ],
  SERVICE_DELIVERY_LOCATION: [ "2.16.840.1.113883.10.20.22.4.32" ],
  SEVERITY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.8" ],
  SEXUAL_ORIENTATION_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.501" ],
  SMOKING_STATUS_MEANINGFUL_USE: [ "2.16.840.1.113883.10.20.22.4.78" ],
  SOCIAL_HISTORY_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.38" ],
  SOCIAL_HISTORY_SECTION: [ "2.16.840.1.113883.10.20.22.2.17" ],
  SOP_INSTANCE_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.8" ],
  STUDY_ACT: [ "2.16.840.1.113883.10.20.6.2.6" ],
  SUBJECTIVE_SECTION: [ "2.16.840.1.113883.10.20.21.2.2" ],
  SUBSTANCE_ADMINISTERED_ACT: [ "2.16.840.1.113883.10.20.22.4.118" ],
  SUBSTANCE_OR_DEVICE_ALLERGY_INTOLERANCE_OBSERVATION: [ "2.16.840.1.113883.10.20.24.3.90" ],
  SURGERY_DESCRIPTION_SECTION: [ "2.16.840.1.113883.10.20.22.2.26" ],
  SURGICAL_DRAINS_SECTION: [ "2.16.840.1.113883.10.20.7.13" ],
  TEXT_OBSERVATION: [ "2.16.840.1.113883.10.20.6.2.12" ],
  TOBACCO_USE: [ "2.16.840.1.113883.10.20.22.4.85" ],
  TRANSFER_SUMMARY: [ "2.16.840.1.113883.10.20.22.1.13" ],
  UDI_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.311" ],
  UNSTRUCTURED_DOCUMENT: [ "2.16.840.1.113883.10.20.22.1.10" ],
  US_REALM_ADDRESS: [ "2.16.840.1.113883.10.20.22.5.2" ],
  US_REALM_DATE_AND_TIME: [ "2.16.840.1.113883.10.20.22.5.3", "2.16.840.1.113883.10.20.22.5.4" ],
  US_REALM_HEADER: [ "2.16.840.1.113883.10.20.22.1.1" ],
  US_REALM_HEADER_FOR_PATIENT_GENERATED_DOCUMENT: [ "2.16.840.1.113883.10.20.29.1" ],
  US_REALM_PATIENT_NAME: [ "2.16.840.1.113883.10.20.22.5.1" ],
  US_REALM_PERSON_NAME: [ "2.16.840.1.113883.10.20.22.5.1.1" ],
  VITAL_SIGNS_ORGANIZER: [ "2.16.840.1.113883.10.20.22.4.26" ],
  VITAL_SIGNS_SECTION: [ "2.16.840.1.113883.10.20.22.2.4", "2.16.840.1.113883.10.20.22.2.4.1" ],
  VITAL_SIGN_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.27" ],
  WOUND_CHARACTERISTIC: [ "2.16.840.1.113883.10.20.22.4.134" ],
  WOUND_MEASUREMENT_OBSERVATION: [ "2.16.840.1.113883.10.20.22.4.133" ]
}

Found here

_{From SyncLinear.com | MAR-56}