Public health's cloud EHR is SaaS and has no Splunk-supported ehr:cim sourcetype. How should the analyst assess useful data?
Select an answer to reveal the explanation.
Short Explanation
A log the SaaS vendor does not emit cannot be collected. For a cloud EHR, that usually means the identity provider and the proxy or CASB, not a made-up ehr:cim sourcetype. Assess the doors that can actually be watched.
Full Explanation
Public health's cloud EHR is SaaS and has no Splunk-supported ehr:cim sourcetype, so the analyst should assess useful data by collecting what actually exists—typically identity-provider sign-ins plus CASB or proxy and web logs—rather than inventing a fictional native EHR sourcetype. Honest coverage for civic health systems uses the planes vendors actually expose to the SIEM and that Enterprise Security can map today.
Inventing an ehr:cim sourcetype and claiming the EHR is fully CIM-compliant fabricates readiness and misleads auditors and health officers. Disabling all public-health detections until the vendor ships a complete CIM EHR model abandons IdP and proxy coverage that already protects patient-access paths. Using only on-premises DHCP logs as a substitute for EHR access evidence cannot show who signed into the SaaS clinical system or which records were touched.
Exam caveat: SaaS without a native technical add-on means use IdP, CASB, and proxy or web evidence; do not invent CIM sourcetypes to claim full coverage.
Operational check: onboard Entra or other IdP sign-ins for EHR users, ensure CASB or proxy logs capture EHR URLs, map those sources to Authentication and Web, and document residual EHR API gaps for public-health leadership.