HTI-2 (if finalized as written) represents a reckoning for some EHRs. There are two models of achieving the FHIR API (aka the current (g)(10) - Standardized API for patient and population services criteria). 1. Facade model - the FHIR API is pointed at the operational database of the EHR. Data is converted on the fly to FHIR format. The facade model historically comes with some drawbacks in that features like versioning, provenance, or even tracking when a resource was updated can be difficult. The EHR had to build here - very few, if any, "buy" options exist for facades - so each feature of the FHIR specification needed to be built. EHRs like Epic or @OracleHealth pursued this path. 2. FHIR server model - the EHR synchronizes data to a FHIR server, translating to FHIR as it pushes. The main advantage with FHIR servers is that if you can get the data synchronized, you immediately have the full FHIR specification available to you (or as much as the FHIR server had implemented). This is powerful in that it limits the engineering lift on building out all the features of the FHIR specification. The challenge is in that act of synchronization. ETL (extract, transform, and load) can work, but if you are not doing ETLs constantly, your server becomes out-of-date with the EHR. Streaming events to the FHIR server is hypothetically the best option, but challenging to implement correctly. Writing back to the EHR (although not mandated) is similarly challenging, in that each API call to the FHIR server would need to be translated to the EHR's data model (or the writeback would need to circumvent the FHIR server and go direct to the EHR, echoing out changes). EHRs like @eClinicalWorks pursued this path, pushing data out to their FHIR server in nightly batches (which is very dubiously in compliance at all with the original Cures criteria). With HTI-2, the new CDS Hooks criteria may push the FHIR server model to a breaking point. CDS Hooks requires EHRs to enable in-workflow hooks that trigger out to external clinical decision support applications, allow them to pull FHIR resources, and suggest actions back to the user in the EHR. If the FHIR server is out-of-date, the CDS Hooks flow is not only wrong, but dangerous - CDS application could suggest entirely wrong protocols. This will basically require EHRs to move to a "FHIR server with streaming" architecture (which is bullish for groups like @Redox that help with streaming data) or to build FHIR facades. Lastly, if the EHR is already having to stream data to the FHIR server, they're essentially building another new HTI-2 criteria - the FHIR Subscriptions criteria. With that essentially built, the value of the FHIR server continues to decrease. Longwinded, but it will be interesting to see if there are comments to this extent and to track implementations here after HTI-2 gets finalized.

Wow, another week, another bombshell of an HHS-rule via @FierceHealthIT: fiercehealthcare.com/regulat… Big implications for payer vendors, public health vendors, and beyond