Blockchain Healthcare App Development: HIPAA, Interoperability, and UX

Description

If you're a decision-maker in the healthcare space, this blueprint is super useful. It's designed to help you build HIPAA-compliant blockchain apps that easily integrate with Electronic Health Records (EHRs) and TEFCA. Plus, it’s all about making sure users have a fantastic experience along the way! This thing includes all the important regulatory timelines you need to know from 2024 to 2027, points out some cool new FHIR/TEFCA trends, and even gives you handy security-by-design checklists to work with.

Why this matters now

From 2024 to 2027, things are really going to change in the U.S. Get ready for some big changes in the world of health data exchange and privacy rules. This is definitely the biggest shift we've seen since the whole Meaningful Use movement kicked off. It’s a game changer for sure! So, here’s the scoop: CMS has wrapped up work on FHIR-based APIs for prior authorization and the exchange of payer data. Meanwhile, ONC is all set to lock in SMART on FHIR 2 as part of their HTI-1 initiative. Exciting times ahead in the healthcare tech world! 0 and USCDI v3. Plus, TEFCA QHINs are now up and running, and they've really broadened their reach! Oh, and let's not forget-- the FTC just rolled out some new guidelines for health apps regarding breach rules.

If you're getting into blockchain for stuff like consent, audit trails, supply chain management, or projects involving multiple parties, it’s super important that your app meshes well with this ever-changing landscape. Oh, and let's not overlook something really important--keeping that HIPAA-level privacy while also making sure the experience for clinicians is smooth and user-friendly is key! If you want to dive deeper into the details, you can take a look at the CMS fact sheet right here. It's a great resource!

The regulatory ground truth (2024-2027): what your roadmap must respect

Final Rule on CMS Interoperability & Prior Authorization (CMS‑0057‑F).
This new rule is really stirring the pot for some payers, especially those involved with Medicare Advantage, Medicaid/CHIP, and Qualified Health Plans on the Federally Facilitated Exchanges. They’ve got to get four FHIR APIs up and running: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. So, just to keep you in the loop, the operational side of things kicks off on January 1, 2026. Then, we’ll need to have those API requirements ready to roll by January 1, 2027. Mark your calendars! Just a heads-up about the timing: if you're looking to get things done quickly, you’ll want to remember that expedited requests take about 72 hours. For standard requests, you'll have around 7 days to wait. Also, by March 31 each year, you can expect to see public metrics on prior authorizations. You might want to take a look at some specific HL7 Implementation Guides (IGs) like Da Vinci CRD/DTR/PAS, PDex, CARIN, and SMART. They're definitely worth your time! If you're looking for more details on this, just head over to cms.gov. There's a ton of useful info waiting for you there!

Hey, just a heads up! The ONC HTI-1 final rule is set to go into effect on March 11, 2024. Mark your calendars because there are some important compliance deadlines lined up for January 1, 2026. So, this rule is all about making USCDI v3 the new go-to standard, and it also introduces the SMART App Launch IG 2. Pretty cool, right? We're diving into the certification process, kicking things off with Insights reporting, and at the same time, we're tightening up those information blocking rules. On top of that, it really helps bring some transparency to Decision Support Interventions (DSI), especially when we're talking about those predictive algorithms that come with certified health IT. For more info, check this out! You can find all the details here.

What's the scoop on TEFCA Status and the FHIR Roadmap? So, TEFCA got rolling in December 2023, and by February 2024, there were already seven Qualified Health Information Networks (QHINs) on board. Those are eHealth Exchange, Epic Nexus, Health Gorilla, KONZA, MedAllies, CommonWell, and Kno2. Pretty exciting stuff, right? Hey there! So, the Office of the National Coordinator for Health Information Technology (ONC) and the Recognized Coordinating Entity (RCE) have officially launched the FHIR Roadmap (version 2, December 2023). This new roadmap is all about rolling out some phased FHIR exchanges that are facilitated by Qualified Health Information Networks (QHINs) and even allow for direct QHIN-to-QHIN exchanges. Exciting stuff for healthcare tech! Get ready for some pilot programs kicking off in 2025! They’ll be launching gradually, so you can expect more requirements to roll out over time. The updated Standard Operating Procedures (SOPs) now come with some extra security measures and expand what you can do with data exchange. (hcinnovationgroup.com).

Hey, just a heads up! The FTC is rolling out some updates to the Health Breach Notification Rule (HBNR) starting on July 29, 2024.

This update really clarifies how health apps and connected devices play a role, going beyond just HIPAA regulations. This update gives consumers more insight into what they'll be notified about, like which third parties have access to their data. Plus, it really streamlines the timing. So, if there's a breach that impacts 500 or more folks, the FTC notice will drop at the same time as the notice to consumers, all happening within a 60-day window. Pretty neat, right? Absolutely, there are some civil penalties in place for folks who don’t follow the rules. (ftc.gov).
Keeping an Eye on Tracking Tech and Personal Health Information (PHI). The HHS OCR's push to tighten up on web trackers found on healthcare websites hit a bit of a bump in the road when it ran into some legal hurdles. In June 2024, a court ruling threw out their guidance, but there are still some risks to be aware of when it comes to exposing personal health information (PHI) through these trackers. This is especially true for pages that need you to log in first. Just a heads up! When it comes to your design choices, it's probably a good idea to play it safe. (reuters.com).
Reproductive Health Privacy Rule Shake-Up (2024-2025). So, in April 2024, the Office for Civil Rights (OCR) finalized a new rule that sets some limits on how specific protected health information (PHI) can be used or shared, especially in relation to legal reproductive care. Jump ahead to June 2025, and guess what? A federal court swooped in and pretty much threw out most of that rule nationwide. Just a heads-up: even though some parts of the Notice of Privacy Practices (NPP) got tossed out, there are still a few revisions that need to be finished up by February 16, 2026. So, make sure to keep that date on your radar! Stay on top of any ongoing legal cases and remember to tweak your notices and policies whenever necessary. (hhs.gov).
HIPAA Security: Check out NIST SP 800-66r2, which will be available in February 2024.
Think of this as your handy guide for figuring out how the HIPAA Security Rule protections match up with the NIST CSF and SP 800-53 r5 controls. It's really useful for figuring out risks, choosing the right controls, and doing some testing. Take a look at this link: csrc.nist.gov. You might find it interesting!
Information Blocking Enforcement Hey there! Just a heads up: starting September 1, 2023, the Office of Inspector General (OIG) is launching some serious civil monetary penalties (CMPs) for health IT developers and health information exchanges (HIEs) and health information networks (HINs). We're talking fines that could skyrocket to a jaw-dropping $1 million for every violation! On top of that, there are new "disincentives" for providers that are tied into CMS programs, and those updates should be wrapped up by 2024. Exciting times ahead! Oh, and just a quick heads-up--it's really important that blockchain workflows don’t interfere with how we access or use electronic health information (EHI). If you want to dive deeper into this, you can find all the details here. It’s worth a look!
HHS Healthcare & Public Health Cybersecurity Performance Goals (HPH CPGs, Jan-Feb 2024).

So, coming up in early 2024, we've got the HHS Healthcare and Public Health Cybersecurity Performance Goals. These are really important guidelines that aim to strengthen our cybersecurity efforts in the healthcare sector. Keep an eye out for these updates--they're set to roll out between January and February! So, there are actually ten Essential goals and another ten Enhanced goals that you should definitely keep in mind. So, we're diving into topics like MFA, email security, segmentation, centralized logging, third-party risks, and a bunch of other stuff. It's quite a mix! Brace yourself for a closer link to CMS and a stronger focus on HIPAA enforcement coming your way! Consider these as your helpful little road signs for putting everything into action. Take a look at the info over on alston.com. It's got all the juicy details you need!

HIPAA in a blockchain world: concrete guardrails

It's best to steer clear of putting any PHI on the blockchain. Hey, just a quick note: even if you hash PHI, there's still a chance it could be traced back to individuals. So, keep that in mind! When it comes to HIPAA's de-identification guidelines, you've got two main options. You can either ditch 18 specific identifiers entirely--this approach is known as Safe Harbor--or you can go for the Expert Determination process. Simple enough, right? Just a heads up: the hashes that come from those identifiers can kind of act like codes. So, it’s super important to treat them with caution. Make sure you’re only using them on data that’s been properly de-identified, following what the experts recommend. Better safe than sorry! The best way to handle PHI is to keep it off the chain in systems that are HIPAA compliant. That way, you can still anchor secure, tamper-evident proofs on-chain. (hhs.gov).
If you're dealing with ePHI, that means you're classified as a Business Associate. This covers a bunch of folks--like node operators, companies that run managed blockchain services, oracle providers, and vendors that help with observability--all of whom are involved in creating, receiving, maintaining, or sending around ePHI. Everyone involved needs to have Business Associate Agreements (BAAs) set up--yep, that includes those vendors, even if the data is encrypted and they don’t hold the keys. If you want to dive deeper into this, check out the HHS OCR cloud guidance. It has a lot of useful info! (hhs.gov).

Alright, let’s dive into how the features of blockchain stack up with the HIPAA Security Rule controls according to the NIST 800-66r2 guidelines.

Integrity: You know, leveraging on-chain hashes and append-only logs is a solid way to ensure integrity. It really helps keep things reliable and trustworthy! Hey there! Just a quick note about some important stuff related to 312(c)(1) and audit controls, specifically section 164. Let's dive into it! 312(b)). Just remember to back everything up with solid off-chain access logs, make sure your time's synced up, and keep your key management on point.
Transmission security: It’s really important to make sure you’re using strong AEAD ciphers and mTLS for any off-chain data transfers you’re doing. Trust me, it makes a big difference! 312(e)(1)). Hey, just a heads up! Don’t put all your eggs in one basket by using blockchain transport as your only “secure channel.” It can be pretty risky.
Risk analysis/management: Don’t forget to jot down your threat models! You’ll want to think about things like potential bugs in smart contracts, any chances of MEV leakage related to metadata, and the risk of re-identification. It’s all about staying ahead of the game! It’s a smart move to check these out by doing some tabletop exercises and penetration tests that line up with HPH CPGs. If you want to dive deeper into this, feel free to take a look at the NIST document right here. It’s got all the details you might need!
Trackers and SDKs Hey, just a heads up: it's best to avoid using advertising pixels when you're dealing with authenticated flows. Also, don't forget to evaluate those analytics SDKs by doing some Data Protection Impact Assessments (DPIAs). It's all about keeping things secure! So, even with the recent court ruling from 2024, the updated Health Breach Notification Rule (HBNR) from the FTC and those recent enforcement actions--like the one against GoodRx--really show just how risky it is for health data to end up in the wrong hands. It's a bit concerning, don’t you think? (ftc.gov).
Managing Reproductive Health Information. Hey, with the 2025 vacatur approaching, it’s really important to get your consent and segmentation processes in place. You want to make sure that any reproductive care data is clearly marked and protected from accidental leaks. It’s all about keeping that sensitive info safe! Just a quick reminder to make sure you update the Notice of Privacy Practices (NPPs) by February 16, 2026, if any changes are necessary. Don’t let that slip your mind! Also, let's make sure we set up those attestation workflows for any requests that come in from law enforcement. It’s important to have that process in place! For more info, just hop over to this hhs.gov link. It's got all the details you need!

Interoperability requirements you’ll meet on day one

Developed with FHIR R4.

0. You’ve got your training set on data up to October 2023, right? And then there’s the whole USCDI v3 thing coming up by 2026. Hey there! Just a heads up: beginning on January 1, 2026, certified electronic health record (EHR) APIs are going to incorporate USCDI version 3. On top of that, we're getting ready for the launch of SMART on FHIR 2. 0 now comes with more detailed scopes in the updated baseline. It’s a smart move for your app to request just the basic permissions, like patient/Observation.rs?category=laboratory. This way, you're keeping things simple and focused on what you really need! Hey, if you want to dive deeper into the details, you can check them out here.

Make sure that payer and provider workflows align with the CMS API guidelines. Hey there! Just a quick reminder--if you're handling prior authorization for the payers that are impacted, be sure to implement the Da Vinci CRD/DTR/PAS by the deadlines we talked about earlier. Hey, just a friendly reminder to make sure that the prior authorization status is accessible through the Patient Access API. Thanks! Oh, and don't forget to gear up to share those metrics and explain why some things got denied. Using blockchain could really shake things up! It allows us to timestamp artifacts and decisions, which means we can easily audit them across various organizations. Pretty cool, right? (cms.gov).
TEFCA Integration Options Hey there! If you're thinking about sharing records across the country, there's a better way to go about it. Instead of setting up those custom HIE links, why not connect through a QHIN Participant or Subparticipant? It's a lot more efficient! When you’re putting together your setup, don’t forget to keep TEFCA’s phased FHIR adoption in the back of your mind. Also, make sure to follow the newest security SOPs to stay protected.
If you're curious to learn more, you can dive into the details here. It's worth checking out!

Proven blockchain patterns that add value (without PHI on-chain)

Consent, Origins, and Big Picture Auditing.

Off-chain: Make sure to store your HL7 FHIR Consent resources and DS4P security labels securely in your PHI repository or through your EHR connection. It’s important to keep them safe!
On-chain: This is all about securely tying cryptographic commitments (think hashes) to important stuff like consent versions, provenance events, and data disclosures. It makes sure you can trust your audit trails, even when you’re collaborating with different organizations.
Let me break it down for you: So, the patient can easily give their consent directly through the app, thanks to FHIR Consent. Plus, if they want, they can also add DS4P labels, like tagging it as “substance-use” for better organization. How cool is that? So, basically, your service kicks things off by sending out an audit event that includes the essentials--who did what and why. This info gets hashed and stored on a secure chain that only certain folks can access, while all the detailed event info hangs out off-chain. So, when someone needs to get their hands on some data, they just show proof that they have consent, and then they can grab the policy-compliant data using FHIR. This data comes with those DS4P labels, making it super clear what’s what. Plus, auditors can easily check everything's legit against the on-chain anchors, so it’s all above board! (hl7.org).

2) Prior Authorization Transparency and SLA Enforcement

Let’s make the most of blockchain to really get a handle on the important milestones--things like CRD inquiries, documentation attestations, PAS submissions, and how quickly we hear back from payers.
This means we can keep a solid record of everything in a shared and secure way while the data moves around using FHIR/EDI. This will really help us keep an eye on the CMS timelines--like the 72 hours for inquiries and the 7 days for approvals. Plus, it'll make managing appeals a whole lot easier! If you want to dive deeper into it, you can check out more info here.

3) Supply Chain and Device Provenance (PHI-free)

If you're talking about the Drug Supply Chain Security Act (DSCSA) or how to keep track of implantable devices, you can't go wrong with blockchain. It's a super reliable way to monitor serial numbers, manage custody, and handle recalls. So, you know those FDA pilots, like MediLedger? They've really demonstrated that this approach is pretty effective, and what's cool is that it manages to keep everything under wraps using zk proofs to maintain confidentiality. We can totally use this same strategy for UDI and device supply chains without having to worry about any PHI concerns. Check it out here!.

Record Integrity Attestation (The Estonia Way).

Link the anchor database log integrity (just the log, not the actual content) to a permissioned blockchain. This way, we can easily catch any tampering that happens during EHR integrations. KSI-style models suggest that we can totally pull this off on a national level without putting public health information at risk. Take a look at this: e-estonia.com. It's pretty interesting!

Reference architecture (permissioned)

Trust and governance We've put together a consortium agreement along with Business Associate Agreements (BAAs) for everyone involved, including all the node operators. Plus, we’ve got some really reliable key management in place, using Hardware Security Module (HSM) technology to keep everything secure and auditable. Change management goes hand in hand with risk assessments, especially when you stick to the guidelines laid out in NIST 800-66r2. Feel free to take a look at it here.
Data plane We're using FHIR APIs to hook up with EHRs and QHINs--basically, we're all about that US Core, Bulk Data, and SMART 2 action. 0). We've got a DS4P labeler in the mix, plus a consent registry to keep everything in check. And don't worry about privacy--our document storage is all about client-side encryption to protect those sensitive files. If you want to dive deeper into it, check it out here. There’s some great info waiting for you!
Ledger plane We're using a permissioned blockchain, like enterprise Ethereum/Besu or Fabric, to keep track of our events. Also, we’ve set up privacy channels and private transactions for those multi-party workflows. Plus, we’re using zero-knowledge or commitment schemes to help with selective validation.
Security plane We’ve got our controls all lined up with HPH CPG standards. So, we’re talking about things like multi-factor authentication, email security, segmentation, centralized logging with SIEM, and keeping tabs on third-party incident reporting. We've got breach runbooks that align with HIPAA and FTC timelines, too. If you're curious to learn more, check it out here. You’ll find some pretty interesting stuff!
Ops plane We’ve streamlined the process of collecting evidence by automating it. Now, we’re linking controls to things like consent hashes, PAS response times, and TEFCA transaction IDs, making everything a lot easier to track and audit. This lets us whip up “compliance proofs” dashboards specifically for CISOs and auditors, which definitely makes things a lot easier.

UX that clinicians and patients actually adopt

So, let's talk about SMART on FHIR 2. We've got 0 ready to roll with some seriously cool least-privilege granular scopes!
Only ask for what you really need, like a lab-only Observation scope. It’s super important to clearly define the scope and intent of the project, along with the data sources you’re using. This transparency really helps to build trust with everyone involved. And let’s be real, it’s all about making life easier for clinicians. With just a tap, they can launch the EHR--no more slogging through those annoying “wall of consent” pages! Take a look at it over here: build.fhir.org. You might find it interesting!
The user experience for prior authorization is aligned with CMS guidelines.
Show the current status in real-time and include when decisions are expected to be made. It’d also be great to offer machine-readable reasons for any denials. Plus, let patients easily download their prior authorization documents through the Patient Access API. (cms.gov).
Consent that's simple to understand and easy to enforce.
Let’s keep it simple! Use easy-to-understand explanations and clear headings. If you're looking for some good ideas on how to create notices in your apps that really stand out, take a peek at the FTC’s HBNR examples. They’ve got some great tips that can help, even if HBNR doesn’t always apply to your situation. Let’s make sure that the “view/change permissions” feature is super user-friendly and easily accessible for everyone. It should shine as one of the top features users can quickly get to without any hassle. (ftc.gov).
Tracking Tech Hygiene
Make sure to avoid using marketing pixels and third-party beacons in secure areas where users need to log in. It's a good idea to run your analytics through a first-party proxy. Don’t forget to keep track of any time you share data externally. Also, it’s important to give users the choice to opt-out if they want to. The recent lawsuit over web tracking really sheds light on the possible dangers out there. (reuters.com).

Build checklist: security-by-design (maps to HIPAA + HPH CPGs)

Identity and access Hey, just a quick reminder: it's super important to set up Multi-Factor Authentication (MFA) for everyone--both admins and clinical users. Also, make sure everyone has their own unique login credentials and try to keep user accounts separate from those with special privileges. It’ll help keep everything secure! Hey, just a quick reminder to keep up with the regular token checks and app revocations as outlined in SMART 2. It's super important!

0. (alston.com).

Data protection
Make sure to use TLS 1. If you're working with modern ciphers, make sure you're using a version of 2 or higher. It's a good idea to use AEAD for your payloads and don’t forget to wrap your artifacts in envelope encryption for added security. Just a quick reminder: steer clear of logging any personal health information (PHI) or storing it on the chain. And don't forget to tag any sensitive categories with those DS4P labels! It’s super important to keep everything secure and organized. (build.fhir.org).
Integrity and audit
Make sure you have those event logs stored on-chain in a way that they can't be changed. It's also a good idea to sync your timestamps with NTP to keep everything accurate. Don’t forget to sign off on that FHIR Provenance, too! And hey, it’s smart to set up alerts for any data that slips out and doesn’t follow your guidelines. (csrc.nist.gov).
Third-party risk Make sure to get BAAs for any vendors that are dealing with PHI. This means anyone working with managed blockchain, monitoring services, or AI. Just a heads up: it’s super important to verify that your vendors are up to speed with the security requirements outlined in the HPH CPGs. Don’t forget to check that the contractual flow-downs are also sorted out! (hhs.gov).
Breach readiness
Put together some notification playbooks that follow the FTC and HIPAA guidelines, and remember to keep data minimization in mind to reduce any potential impact. Also, make sure to use message templates that check all the boxes for HBNR content requirements. (ftc.gov).
Information blocking avoidance Make sure to review your workflows and see if they line up with the ONC exceptions. It's super important not to slow down patient or provider access with any extra blockchain stuff that isn’t needed. Also, remember to back up data exports using FHIR/Bulk Data! (hklaw.com).

Practical integration patterns (worked examples)

So, basically, we’re talking about a TEFCA-enabled query that comes with consent anchoring. It’s all about making sure that when we’re looking up information, we’re doing it in a way that respects people's choices and privacy. So, the app checks to make sure you've got active Consent, sends out queries through the QHIN Participant, and then gets back those C-CDA/FHIR payloads. So, basically, these payloads are kept off the chain. Meanwhile, we create a hash for the audit event right on the chain, complete with those DS4P tags. Also, the TEFCA provenance fields and QHIN audit logs team up nicely to strengthen your ledger anchors. For more info, be sure to visit (rce.sequoiaproject.org). You'll find all the details you need there!

Da Vinci PAS round-trip with signed timelines that are notarized. So, here's the process: you start with a CRD request, then move on to the DTR questionnaire, and finally submit your PAS. What’s interesting is that we can compare the time it takes to get a decision on service records with the CMS thresholds. Plus, with these on-chain anchors, we can validate things across organizations while making sure that the content stays private. It's a pretty neat setup! (cms.gov).
Pharmacy and UDI supply chain info (no personal health information involved).
Use blockchain to track lot and serial numbers, manage custody, and handle recalls--kind of like what they do with the MediLedger model. Oh, and by the way, you can totally link device IDs in electronic health records (EHRs) with FHIR Device resources, and you can do this off-chain. Pretty handy, right? If you want to dive deeper into the details, just head over to this link: tabletscapsules.com. Happy exploring!

Common pitfalls (and how to avoid them)

Using public blockchains to handle clinical data.
A lot of public networks aren't able to sign Business Associate Agreements (BAAs), and they tend to leak metadata. So, even if you're just storing hashes, there's still a chance that things can get linked back together. I recommend going for permissioned networks that have solid governance in place. Plus, it’s a good idea to keep all that sensitive personal health information (PHI) stored off the blockchain. (hhs.gov).
It’s important to watch out for overly broad scopes and those sneaky dark patterns.
SMART 2. So, 0 is really looking for detailed scopes, while the FTC wants everything to be crystal clear. Just ask for what you really need! Be clear about what you're aiming for, the purpose behind it, and how long it’s all going to take. (build.fhir.org).
Overlooking the changes in TEFCA and FHIR requirements. When you're planning your integration, just keep in mind that the roadmap stages will require you to be flexible with the different levels of FHIR support among QHINs in 2025 and 2026. So, it's a good idea to think about creating some adapters and fallback options to handle any inconsistencies. (rce.sequoiaproject.org).

What “good” looks like at go‑live

Compliance posture We've got our HIPAA risk analysis all set up according to NIST 800-66r2, and we've also got signed Business Associate Agreements (BAAs) in place to keep everything above board. We’ve got the HPH CPG Essential controls set up, and we've actually put our breach playbooks to the test. Take a look at it here: csrc.nist.gov. You won’t want to miss this!
Interoperability posture Hey everyone! We’re excited to announce that we’re rolling out SMART 2! You're all set and ready to go for USCDI v3! We've set up Da Vinci IGs whenever we've needed them, and we're all linked up through a QHIN Participant for TEFCA. And hey, we've got Bulk Data export all set up, so you can dive into some real analytics. More info here: (himss.org).
UX posture Our system is all about keeping things straightforward and user-friendly. You’ll have clear options for giving and taking back your consent, plus we’ll keep you in the loop with transparent timelines for any prior authorizations. We don’t use any third-party trackers when you’re logged in, and we’ve really made it a point to design our interfaces with accessibility and mobile users in mind.
Learn more here: (ftc.gov).
Evidence We’ve implemented on-chain anchors to keep tabs on any changes in consent and disclosures, plus we’ve got everything backed up with signed Provenance. Our runtime dashboards are here to keep you in the loop about things like API uptime, service level agreements for prior authorizations, and how frequently we tap into those information-blocking exceptions. You'll always know what's going on!

Vendor/RFP questions that separate signal from noise

Hey there! I was wondering how you ensure that no PHI (Protected Health Information) ever ends up on-chain. It would be awesome if you could share some data flow diagrams to help visualize your process. Also, I'd love to know how you handle logging redaction. And on that note, what kind of cryptographic methods do you use for anchoring? Looking forward to your insights!

So, which Business Associate Agreements (BAAs) do you actually sign? Think about things like ledger hosting, nodes, monitoring, and those cool AI assistant features. Sure! I can definitely help you find templates that align with 45 CFR 164. Just let me know what specific aspects you're looking for, and I'll do my best to provide you with some options. 504(e)? (hhs.gov).
Could you please show us the SMART 2? You’ve got your 0 granular scopes that you work with, right? So, let’s talk about how you manage consent revocation--it’s impressive that you can handle that in less than an hour! And I’m really curious about the outcomes from your FHIR US Core conformance tests. What did you find? (himss.org).

Could you share a bit about your plan for connecting to TEFCA, whether you're a participant or a subparticipant? I'd love to hear how you make sure you’re sticking to those security SOPs. Also, what’s your approach for handling non-uniform support on the FHIR front? You can check out some updates on this over at Sequoia Project.

Take some time to outline how your controls line up with NIST 800-66r2 and the HPH CPGs. Could you also send over the quarterly evidence packages and the incident SLAs? Thanks! (csrc.nist.gov).

Hey there! Quick question about prior authorization--what versions of the Da Vinci Implementation Guides are you working with? Are you using CRD, DTR, or PAS? Also, I'm curious about how you create the denial reason artifacts that CMS needs. You can find more details about that here. Thanks!

Bottom line

Blockchain has some really cool possibilities for healthcare! It can offer trustworthy integrity, create audit trails that everyone can check, and help multiple parties work together smoothly. Here's the thing--it really stands out when it teams up with HIPAA-compliant data services, FHIR APIs, and TEFCA exchange, rather than trying to go head-to-head with them.

To really get the best out of it, it's a good idea to keep personal health information (PHI) off the chain. Instead, you can anchor your proofs on-chain. Plus, embracing SMART 2. Jumping into zero and USCDI v3 is definitely a savvy choice! Hey, just a quick reminder to beef up your setup with the HPH Clinical Practice Guidelines and NIST 800-66r2. It's super important for keeping everything solid! If you play your cards right, you won’t just be ready for the compliance wave coming in 2026-2027. You’ll also create an app that both clinicians and patients can’t wait to use! If you want to dive into the specifics, just click here to get all the info!