1 / 6

Comprehensive Security Considerations for hData Applications in EHR and Research Environments

The hData framework offers versatile applications across various scenarios, such as electronic health records (EHR) systems and sensor-driven edge applications. A "one size fits all" security model is ineffective; diverse security requirements and performance impacts necessitate a flexible security approach. By defining a security baseline and incorporating security metadata within the hData Record Format (HRF) and RESTful transport, stakeholders can customize security mechanisms. Ongoing risk assessment is essential as threats and vulnerabilities vary by domain and implementation type.

chace
Download Presentation

Comprehensive Security Considerations for hData Applications in EHR and Research Environments

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