1. HL7 hData Security Elements

2. Security Considerations hData can be used in a broad variety of situations – EHR systems, line of business applications – “Edge” Applications (user interface, sensor devices) – Research and quality control “One size fits all” security approach will not work – Different level-of-assurance requirements – Performance impact – Different behavioral model

3. Flexible Security Approach Define a security baseline – hData Record Format (HRF): security meta data – hData RESTful Transport (REST): basic security mechanisms Provide security extensibility in the core protocol – HRF: meta data extension points (confidentiality, access control, consent) – REST: custom security mechanisms

4. Baseline Security Implementers MUST provide baseline security elements Deployers can configure (or de-configure!) baseline security at runtime – E.g. HRF must support signing SectionDocuments; deployers can decide that this is not necessary – E.g. REST must support TLS client authentication; deployers might disable all authentication “Must implement/may deploy” guarantees minimal set of interoperable security mechanisms

5. Extension Points Provide extension points for security mechanisms for HRF and REST – Allow domain experts to identify specific security requirements – Define standardized ways for documentation Runtime discovery of supported security mechanisms Customized security for domains and deployments

6. Risk Assessment Risk assessment recommended for all deployers Threats are specific to the specific domain Exploits are specific to the implementation and the deployment Some vulnerabilities will be shared across implementation – HTTP, TLS, etc. – Custom security mechanisms will introduce specific vulnerabilities Risk cannot be uniformly assessed across all deployments