Most discussions about FHIR are simple interaction diagrams like this: Many Sources (n != 1) The Real story needs to consider that the “Source” above is a single box representing 10,000 potential source systems that hold data about the patient: (map is a static view of CareQuality network) More important is that the above map
I want to drive discussion on this, so will take a position that many may disagree with. This position is that for Treatment and Payment the best format for clinical data is Document based. The consumption side is a different topic, and today a big frustrating point. Although publication should be Document based, these documents
This week the ITI and PCC face-to-face meeting approved new/updated FHIR conformance resources (ImplementationGuide, StructureDefintion, CapabilityStatement, ValueSet, CodeSystem, and OperationDefinition) for publication. These have been aligned with FHIR R4. * PIXm — supplement soon to be released to Public Comment* NPFS — supplement soon to be released to Public Comment* (mACM) — supplement soon to
There is a new standard from IETF – ACME — https://datatracker.ietf.org/doc/rfc8555/ Abstract Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately
I get the following question about every other month. Here is the version I just responded to: In this project I encountered a requirement to use SHA-256. Apparently this was in reaction to the SHA-1 collision vulnerability (https://shattered.io/) from late 2017. IHE XDS requires the hash to be SHA-1. Have you heard of any requests
The HIPAA Accounting of Disclosures is obsolete and dangerous. Patients are expected to become more engaged with their healthcare and do this using applications. Applications are sometimes software that runs on the Patient’s phone, but sometimes software running at a third party cloud. Patients should not be expected to have done a software code review
For those that struggle with the way that IHE documents the specific requirements of audit logging per type of security event or per ITI transaction; there is an easier tool. The IHE Gazelle “Security Suite” Tool has each audit log message broken down and explained. My hope is that soon this tool is the way
IHE has created a FHIR based Patient identity management system for health information exchanges. This builds on PDQm and PIXm, by adding a Feed mechanism, and a subscription to the Feed. Added to this is a set of requirements and expectations around how Merging (Link and UnLink) are to be implemented. The result of a
This is an update of what is going on in Security and Privacy in, and around, the FHIR specification. —————tl;dr———————– FHIR R4 includes Security Considerations classification SMART-on-FHIR first flavor is Normative Addition of X-Provenance and X-Consent http headers GDPR assessment against FHIR indicates good coverage of needs in FHIR already Maturing AuditEvent and Provenance to
The IHE ITI, PCC, and QRPH workgroups met in OakBrook, IL this week at the RSNA Headquarters. We still are not meeting in Treviso Italy., but we have heard that the July meeting will be in Sardinia Italy. Right before the big tourism time. Specifically we will be at the Facilities of Sardegna Ricerche at Polaris, Parco Scientifico e
