I was asked to make a short presentation to the CDC to talk about scalable Pandemic Reporting with FHIR and how our SAFHIR platform can support reporting in this crazy world created by COVID-19. The event was a 2-day workshop organized to promote the use of HL7 FHIR at CDC. There was an illustrious list of presenters including ONC Deputy, Steve Posnack, CEO of HL7, Chuck Jaffe, and the inspiration behind SMART-on-FHIR, Ken Mandl.
Rather than talk about our Scalable and Secure Architecture for FHIR it seemed more important to help the CDC understand how to embrace FHIR in a way that leads to implementable solutions that are embraced by the Healthcare and Public Health sectors.
Why am I able to talk on this subject? I am certainly not an expert in quality standards or public health reporting. However while working for our parent company, NewWave, I designed and built the CMS’ Blue Button 2.0 API that is at the heart of the CMS Interoperability and Patient Access Rule. That API became the driver behind the CMS Interoperability and Patient Access Rule that is now being implemented by health plans across the country.
I am also heavily involved in the Da Vinci Project as a Co-Chair and Implementation Guide author and I oversee Onyx’s development work on the Gravity Social Determinants of Health (SDoH) project.
At Onyx we took the lessons learned from building Blue Button 2.0 and partnered with Microsoft to build SAFHIR – a Secure Architecture for FHIR.
We did this because we realized that implementing a FHIR API is just one piece of the solution. It is everything that you need to wrap around the FHIR API to deliver a workable solution that is the key to success. SAFHIR integrates all of the additional capabilities and creates an Easy button to implement FHIR solutions that are based on FHIR Implementation Guides.
If we do some design-style thinking we can break the problem down into three basic elements:
- The Data: How do you get it, how does it need to be organized and structured
- Attribution: How is the data related to the people, groups, organizations and functions
- Access: Which people or systems need access and how is that access authorized.
So the first lesson:
It’s not just about the data
At Onyx we have been watching and contributing to the Situational Awareness for Novel Epidemic Response (SANER) project that is addressing pandemic reporting and we see how SAFHIR can act as the intermediary in a multi-tier reporting fabric.
- Because you need to ingest data from different sources
- Manage the data relationships
- Administer the access to the data
SAFHIR provides the platform to address these three challenges.
So the second Lesson:
Modular beats monolithic
When we start thinking in this way a number of other lessons surface:
- IGs enable developers to understand API capabilities
- FHIR Tools accelerate development
- IGs can be internal (without HL7 Copyright content)
- We did this on the BB2.0 project. We worked with the FHIR community to define the resources we need to use. But we didn’t submit an IG for publication because it was specific to CMS as a data holder. However, The CMS BB2.0 IG became the inspiration for the CARIN Consumer-Directed Exchange Blue Button IG
- The BB2.0 IG also helped thousands of developers understand how to interpret and interact with the API.
- You can use the structure of an IG to communicate the interface specifications you are using internally.
- IGs are best when developed with the implementer community
- Don’t go it alone
- Implementers help you understand the realities of real-life implementation
- Look to prior art and leverage established profiles wherever possible
- FHIR gives you almost infinite flexibility when you start from the base specification. But every deviation from the profiles that are in common use (think US Core) adds another brick in the wall that is the barrier to adoption.
- Using existing profiles wherever practicable reduces the barriers to implementation and subsequent adoption
So there you have four more rules from the trenches to guide your adoption of FHIR.
In summary, what can we learn from building a FHIR Solution that is used by thousands of developers:
1. Break the problem down in to reusable building blocks
2. Use Standards and prior art wherever possible
3. Engage the community