1 / 6

HL7 hData Security Elements

HL7 hData Security Elements. 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

chace
Download Presentation

HL7 hData Security Elements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related