Changes between Version 29 and Version 30 of Archtectural Overview Security


Ignore:
Timestamp:
Mar 9, 2008, 11:45:52 AM (16 years ago)
Author:
KOBAYASHI, Shinji
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Archtectural Overview Security

    v29 v30  
    194194
    195195 * EHRでの実在しない場所（たとえば，全てのPARTY_SELFインスタンスが空の代替物である場合）これは，もっとも安全なアプローチであり，EHRとEHR外部で行われるべき患者をEHR.ehr_IDと目的識別子で関連付けることによってつなげることを意味している。このアプローチはより公開された環境により適応したものである。
     196 * EHR STATUSオブジェクト(目的属性)で一度示されたものは他のどこにも存在しない。これもまた，EHR STATUSオブジェクトが何らかの方法で防御されるのであれば比較的安全な方法である.
     197 * PARTY_SELFのインスタンス全てにおいて。これは，安全な環境では合理的な解決法であり，ローカルにあるレコードを部分的にコピーする際にも便利である.
    196198
    197199 * Nowhere in the EHR (i.e. every PARTY_SELF instance is a blank placeholder). This is the most secure approach, and means that the link between the EHR and the patient has to be done outside the EHR, by associating EHR.ehr_id and the subject identifier. This approach is more likely for more open environments.
    … …  
    199201 * In every instance of PARTY_SELF; this solution is reasonable in a secure environment, and convenient for copying parts of the record around locally.
    200202
     203この単純な機構は適切に使われれば情報が盗まれたりクラックされたりするようなことに対抗して基本的に保護することができる。もっとも安全な状況では，クラッカーは
     204
    201205This simple mechanism provides a basic protection against certain kinds of information theft or hacking if used properly. In the most secure situation, a hacker has to steal not just EHR data but also separate demographic records and an identity cross reference database, both of which can be located on different machines (making burglary harder). The identity cross-reference database would be easy to encrypt or protect by other security mechanisms.
    202206