14 posts tagged with "fhir-datastore"

Data privacy, locality, governance and compliance are huge issues in healthcare, and that's why we at Medplum support self-hosting. For those running on AWS, we use Aurora RDS, which supports auto-scaling. A common question we get is - how big is my database going to be?

Say for example, you have 1M active patients annually - how does that translate to database size?

Unfortunately, there is no straightforward answer to that question, but the right way to think about it is to make a FHIR resource count estimate, per patient, annually. Applications with a lot of messaging and observation data are generally more resource intensive, while those that have visit notes and prescriptions are generally less resource intensive.

Here's an example of a resource projection.

Resource Type	Count per Patient	Total Count (M)	Avg. Size / Resource (kb)	Avg. History Length	Total Storage (GB)
Patients	__	1	5	10.0	52.5
Encounters	10	10	2	2.0	42.0
Coverage	1	1	2	2.0	4.2
DiagnosticReport	10	10	2	2.0	42.0
Observation	15	15	2	2.0	62.9
MedicationRequest	10	10	2	2.0	42.0
Media	15	15	2	2.0	62.9

Average History Length (column 5) refers to the number of times the resource is edited, as changes are tracked, historical data will increase storage size.

To calculate the total storage, we use an "overhead factor" (representing metadata, indexes, etc) of 10%. The following formula shows how to estimate column 6 - Total Storage

totalStorage = resourceCount * patientTotal * avgSize * avgHistoryLength / (1024 * 1024) * (1 + overheadFactor)

In this example, summing the Total Storage column, you get an estimated total of 308.4 GB of data per year.

Hopefully, this lightweight exercise can help you and your organization get a sense of your database needs today and over time.

Related Resources​

• AWS Aurora Pricing
• AWS Aurora Instance Class Summary
• Medplum Self-hosting guide
• Self-hosting change log on Github

We are excited to hear about the release of Fast Healthcare Interoperability Resources (FHIR) R5, the latest version of the healthcare data interoperability standard. This new version builds on the previous versions of FHIR and incorporates new features and improvements to further support healthcare data exchange and interoperability.

FHIR R5 includes enhancements to the FHIR specification, including additional resources, improved support for clinical workflows, and improved alignment with other healthcare data standards. The new version also includes updates to the FHIR conformance framework, which helps ensure that FHIR implementations are interoperable with each other.

In the future, we will upgrade our service to support FHIR R5 side by side with R4. This includes ensuring that our solutions comply with the latest FHIR R5 specifications and testing our products for interoperability with other FHIR R5-compliant systems.

We will do this while maintaining our support for FHIR R4 - which most of our customers rely on today. We will use our Bot framework, TypeScript SDK and validation tools to help our customers implement the version of the spec that best suits their business needs.

We are excited about the potential of FHIR R5 to improve interoperability and enable better healthcare outcomes for patients. We continue to closely monitor industry adoption and compliance requirements and will strive to provide our customers with the most up-to-date solutions to meet their interoperability needs.

Thank you for your continued support, and we look forward to sharing more updates with you soon. If you are interested in updates related to FHIR R5, please reach out at hello@medplum.com.

Related Reading​

• FHIR Forums Announcement

Great workflow apps are core for us at Medplum, and we provide tools to build highly ergonomic asynchronous task tracking systems providers. Some examples of task management apps in the medical context are apps that:

• Review and approve lab reports
• Approve or reject medication refill requests
• Instantiate custom care plans for a patient

Medical systems in general and FHIR in specific have robust workflow resources to create, track and implement workflows. Tasks and ServiceRequests are the most common workflow resources for asynchronous work.

Setting up Queues or Worklists​

The core or a workflow app is a queue or sometimes called a worklist. This is exactly what it sounds like - a list of tracking tasks that represent the work to be done and it's current status. The FHIR Tasks as a group are often used to represent a queue. Tasks can be created programmatically, or via Questionnaire and Bot.

When populating the Task resource, it can be useful to populate the following fields:

• Task.focus - this is what the task is about, for example you can link it to a DiagnosticReport, MedicationRequest or CarePlan
• Task.businessStatus - this can be used for custom workflow, where you can set your own statuses that fit your workflow
• Task.code - this can be useful to cue the Task specific user interface (below), example might be "Lab Review"
• Task.executionPeriod - this can be useful for productivity tracking
• Task.for - this is usually a link to the Patient

Once you have created some Tasks you can view Tasks in the Medplum App.

Once you have confirmed that tasks are formed the way you want them to be, you can embed a search control in your Task tracking application, there are examples in the sample application.

Like in the Medplum App, it is recommended that you have one page in your app that supports permalinking to a specific task search as it is useful for collaboration, integrating into chat apps and other common workflow tooling scenarios.

Task specific User interface​

For each task, you will want to show a user interface that gives the user some context on how to resolve or take action on that task. This is very workflow dependent so customizability is important. You can see a video (70 seconds) on this topic here.

The exact components of the Task specific user interface are often driven by Task.focus or Task.code.

Dashboards​

Turnaround times and productivity tracking are crucial for observing the health of your task-based workflow. Assuming you populate the timestamps correctly in the resources, it is straightforward to calculate how many work hours a certain task takes, or the turnaround time.

Here is an example of a timestamp calculation:

• Turnaround Time for a Task: Task.executionPeriod.end - Task.authoredTime
• Work hours for a task: Task.executionPeriod.end - Task.executionPeriod.start

Using these calculations, it is straightforward to make a dashboard that gives a very clear picture into the status and health of your queues. In this example below, each of the graphs is a representation of a Task search, with results bucketed by turnaround time or by work hours.

Related Resources​

• Sample Task App Github repository
• Task center stage video
• Task Resource Documentation
• Tasks in the Medplum App

As we close out 2022, the Medplum team would love to thank our customers and community for joining us on this journey.

We wanted to highlight a few memorable moments and reflect on all that happened during the year. It was a lot of fun, and huge thank you to the team who pushed so hard to make all these things happen.

✅ Open sourced our repository

✅ Achieved SOC2 Type 2 and HIPAA certification

✅ First Enterprise customer went live!

✅ Launched our Youtube Channel and Discord Community

✅ Had our YC S22 Demo Day

✅ Launched our sample patient portal Foo Medical, video, source code

✅ CLIA/CAP Certified

✅ Launched on Hacker News

✅ 500+ Github Stars

✅ Published our Roadmap

Instead of going on about what the new year has to hold, I'll share a peek into the future in the most Medplum way possible - i.e. in excruciating technical detail. Please enjoy and feedback always welcome.

Product	2022	2023
Integration	Change log	Roadmap
Questionnaires	Change log	Roadmap
Scheduling	Change log	Roadmap
Communications	Change log	Roadmap
Care Plans	Change log	Roadmap
Medications	Change log	Roadmap
Charting	Change log	Roadmap
Billing/Payments	Change log	Roadmap
Auth	Change log	Roadmap
FHIR Datastore	Change log	Roadmap
Subscriptions	Change log	Roadmap
React	Change log	Roadmap
Search	Change log	Roadmap
Self-Hosting	Change log	Roadmap
Compliance	Change log	Roadmap
Audit/Logging	Change log	Roadmap