دوستان علاقه مند به HIS که از من در مورد جزئیات و ساختار HIS سوال می کردند یک متن خوبی را انتخاب کرده و در صفحه وب می گذارم که ادامه یکی از مقالات کوتاه قبلی است که با ترجمه گذاشته بودم. امیدوارم مورد توجه قرار گیرد.

What is HIS

A hospital information systems (HIS) is a computer system that is designed to manage All the hospital’s medical and administrative information in order to enable health professional perform their jobs effectively and efficiently.

Hospital information systems were first developed in the 1960s and have been an essential part in hospital information management and administration. Early systems consisted of large central computers connected to by dumb terminals, which are now being replaced by networked microcomputers. The systems were used to manage patient finance and hospital inventory.

Hospital information systems now focus on the integration of all clinical, financial and administrative applications and thus could also be called an integrated hospital information processing systems (IHIPS).

Components a hospital information system consist of two or more of the following:

(CIS) - Clinical Information System

(FIS) - Financial Information System

(LIS) – Laboratory Information System

(NIS) – Nursing Information System

(PIS) – Pharmacy Information System

(RIS) – Radiology Information System

(PACS) - Picture Archiving Communication System


A Look at the list above shows how complex a hospital information system can be.

Advancement in computer technology and the development of information exchange standards such HL7 and DICOM, make the task administering and integrating such systems a little more easier.

No hospital information system can be regarded as a success unless it has the full participation of its users. Thus human and social factors would have to be considered in its design, more often than not, they can be easily addressed by providing adequate training and education about the system.




A Clinical Information System (CIS) is a computer based system that is designed for collecting, storing, manipulating and making available clinical information important to the healthcare delivery process.

Clinical Information Systems may be limited in extent to a single area (e.g. laboratory systems, ECG management systems) or they may be more widespread and include virtually all aspects of clinical information (e.g. EMR).

Clinical Information Systems provide a clinical data repository that stores clinical data such as the patient’s history of illness and the interactions with care providers. The The repository encodes information capable of helping physicians decide about the patient’s condition, treatment options, and wellness activities as well as the status of decisions, actions undertaken and other relevant information that could help in performing those actions.

Some of the areas addressed by Clinical Information Systems are:

Clinical Clinical Decision Support : This provides users with the tools to acquire, manipulate, apply and display appropriate information to aid in the making of correct, timely and evidence-based clinical decisions.

EMRs - Electronic Medical Records : this contains information about the patient, from their personal details, such as their name, age, address and sex to details of every aspect of care given by the hospital (from routine visits to major operations).

Training and Research: Patient information can be made available to physicians for the purpose of training and research. Data mining of the information stored in databases could provide insights into disease states and how best to manage them.

Fore years, research has been done to show the value of Clinical Information Systems, and these have highlighted not just the benefits but also the barriers that might be faced by hospitals who implement such systems.

Some of the benefits are:

Easy Access to Patient Data: Clinical Information Systems can provide convenient access to medical records at all points of care. This is especially beneficial at ambulatory points, hence enhancing continuity of care. Internet-based access improves the ability to remotely access such data.

Structured Information: The clinical information captured in Clinical Information Systems is well organised, thus making I easier to maintain and quicker to search through for relevant information. The information is also legible, making it less likely that mistakes would be made due to illegible writing.

Improved Drug Prescription and Patient Safety: Clinical Information Systems improve drug dosing and this leads to the reduction of adverse drug interactions while promoting more appropriate pharmaceutical utilization.

Despite the benefits being offered by Clinical Information Systems, they are not without the barriers that prevent them from being rolled out in every hospital. These include some of the following:

Initial cost of acquisition: the high cost of basic infrastructure of clinical information technology can be a stumbling block to many healthcare organizations.

Privacy Privacy and Security: There are still huge concerns in the healthcare industry about the privacy of patient data on computer systems and how to keep such information secure. The HIPAA and Data Protection Act passed by respective governments in the US and the UK were introduced to address some of these concerns.

Clinician Resistance: Clinicians usually have 10-20 minutes to see their patients and if their interactions with a CIS during these sessions proves to be counterintuitive by taking up more time than is necessary, there is bound to resistance to it use.

Bound to resistance to it use.

Integration of Legacy Systems: This poses a stiff challenge to many organizations.




Financial Information Systems (FIS) are computer systems that manage the business aspect of a hospital. While healthcare organisations’ primary priority is to save lives and not making profits, they do acquire running costs from day to day operations; including purchases and staff payroll.

Healthcare business activities can be quite complex and the introduction of Financial Information Systems aims to ease that daunting task that faces hospitals.

Some of the features of Financial Information Systems are:

PAYROLL: Handles all the recurring and non-recurring payments and deductions for employees. All recurring transactions can be automatically generated each payroll period with non-recurring transactions such as overtime added to the payroll upon approval. It is also possible to maintain employee pay rates, entitlements, full salary movements and payroll histories.

PATIENT ACCOUNTING: This concentrates on financial transactions generated during a patient’s visit to the hospital. These include inpatient and outpatient charges, doctors’ fees generated across the hospital, the cost of procedures, operations and medications.

ACCOUNTA PAYABLE : Handles the processing of invoices and payments within the hospital.

ACCOUNTS RECEIVABLE:   This provides support for and the maintenance of the records of all clients, invoices and payments.

GENERAL LEDGER : This handles the collection, processing and reporting of financial data generated by all transactions, enabling a current, accurate and instant view of the financial status of the hospital at any point in time.

FIXED ASSET MANAGEMENT : This deals with asset data retention and depreciation forecasting. The transfer of fixed assets between locations, cost centres or departments; reclassification of assets and reassessments of asset values can functions that can be done by the Financial Information System.

CLAIMS MANAGEMENT: Manages all claims that are made to insurance companies.

CONTACT MANAGEMENT : Keeps track of all ongoing contracts.




A laboratory information system (LIS) is a computer information system that manages laboratory information for all the laboratory disciplines such as clinical chemistry, haematology and microbiology.

Laboratory Information Systems provide modules for sending laboratory tests order to the instruments through its multiple instrument interfaces, some are known as to have as many as five hundred, track those orders and then capturing the results as soon as they become available. The result can then be analysed and a report the generated from it.

This report can be sent off for printing at a specific point, sent off to other systems either to be added to patient’s electronic medical record or for billing.

Laboratory Information Systems communicate with other information systems using clinical information standard such as HL7. Laboratory systems might also make use of LONIC (Laboratory Observation Identities, Names and Codes) to exchange laboratory results with other systems.

Other features that include:

Patient management: Patient details like the admission date, admitting physician, and admission number can be maintained by a Laboratory Information System. Other information concerning the patient’s specimen including the ordering physician, department ordering the test, specimen type, date/time of collection and receipt, and the initials of the collecting technician, can also be managed in a Laboratory Information System.

Decision Support: Lab orders can be cross-referenced against classification codes such as ICD-9 and LONIC, and also verified that that the correct test is being carried out.

Patient Tracking: A patient tests can be catalogued and called up when the need to review them comes up.

Quality Assurance: Ensures that the tests carried out using the currently available standards.

Management Reporting

Workload Recording.




Nursing information systems (NIS) are computer systems that manage clinical data from a variety of healthcare environments, and made available in a timely and orderly fashion to aid nurses in improving patient care.

To achieve this, most Nursing Information Systems are designed using a database and at least one nursing classification language such as North American Nursing Diagnosis (NANDA), Nursing Intervention Classification (NIC) and Nursing Diagnosis Extension and Classification (NDEC).

Some of the features that are provided by Nursing Information Systems include:

Patient Charting: A patient’s vital signs, admission and nursing assessments, care plan and nursing notes can be entered into the system either as structured or free text. These are the stored in a central repository and retrieved when needed.

Staff Schedules: Nurse can self schedule their shifts using scheduling rules provided in shift modules. The shifts can later be confirmed or changed by a scheduling coordinator or manager. Shift modules are designed to handle absences, overtime, staffing levels and cost-effective staffing.

Clinical Data Integration: Here clinical information from all the disciplines can be retrieved, viewed and analysed by nursing staff and then integrated into a patient’s care plan.

Decision Support: Decision support module can be added to Nursing Information Systems, and they provide prompts and reminders, along with guides to disease linkages between signs/symptoms, etiologies/related factors and patient populations. Online access to medical resources can also be made available.

There are benefits to be enjoyed by implementing Nursing Information Systems and they includ:

Improved workload functionality: Staffing levels and appropriate skill mix per shift can be more easily determined by the shift modules. This leads to less time spent in designing and amending rosters.

Better care planning: Time spent on care planning is reduced, while the quality of what is recorded is improved. This makes for more complete care plans and more complete assessments and evaluations.

Better drug administration: Electronically prescribed drugs are more legible, thus making it less likely that drugs would be wrongly administered to patients.

Despite the benefits Nursing Information Systems have to offer, they are not widely used in healthcare and where they have been installed, they have not been readily accepted. This could probably due to lack of adequate training and failure of educate the end-user what the reasons are for its introduction. Moreover, very little research has been done to determine the cost benefits or cost effectives of such information systems.



Pharmacy information systems (PIS) are complex computer systems that have been designed to meet the needs of a pharmacy department. Through the use of such systems, pharmacists can supervise and have inputs on how medication is used in a hospital.

Some of the activities which Pharmacy Information Systems have been employed in pharmacy departments include:

Clinical Screening: The Pharmacy Information System can assist in patient care by the monitoring of drug interactions, drug allergies and other possible medication-related complications. When a prescription order is entered, the system can check to see if there are any interactions between two or more drugs taken by the patient simultaneously or with any typical food, any known allergies to the drug, and if the appropriate dosage has been given based on the patient’s age, weight and other physiologic factors. Alerts and flags come up when the system picks up any of these Prescription Management: The Pharmacy Information System can also be use to mange prescription for inpatients and/or outpatients. When prescription orders are received, the orders are matched to available pharmaceutical products and then dispensed accordingly depending on whether the patient is an inpatient or outpatient. It is possible to track all prescriptions passed through the system from who prescribed the drug, when it was prescribed to when it was dispensed. It is also possible to print out prescription labels and instructions on how medication should be taken based on the prescription.

Inventory Management: Pharmacies require a continuous inventory culture in order to ensure that drugs do not go out of stock. This is made even more difficult when there are multiple dispensing points. When don manually it is very difficult to maintain an accurate inventory. Pharmacy Information Systems aid inventory management by maintaining an internal inventory of all pharmaceutical products, providing alerts when the quantity of an item is below a set quantity and providing an electronic ordering system that recommends the ordering of the affected item and with the appropriate quantity from approved suppliers.

Patient Drug Profiles: These are patient profiles managed by the Pharmacy Information System and contain details of their current and past medications, known allergies and physiological parameters. These profiles are used for used for clinical screening anytime a prescription is ordered for the patient.

Report Generation: Most Pharmacy Information Systems can generate reports which range from determining medication usage patterns in the hospital to the cost of drugs purchased and /or dispensed.

Interactivity with other systems: It is important that Pharmacy Information Systems should be able to interact with other available systems such as the clinical information systems to receive prescription orders and financial information system for billing and charging.




A radiology information system (RIS) is a computer system that assists radiology services in the storing, manipulation and retrieving of information.

RIS were first used in the 1970s and their primary aim was to manage and store radiology information.

The introduction of client/server computing, improved digital imaging and computer network technologies, along with the advancement of the DICOM and  HL7 standards have put RIS along side picture archiving communication system (PACS) as an ideal solution for managing radiological images.

Since the 1990s, organisations have taken the steps to fully integrate PACS with radiology information systems, when the basic features and adapt needed to mange the acquisition, processing and storage of radiological information, becomes the responsibility of the RIS.

Some of the areas that can be addressed by radiology information systems are:

Patient Management: radiology information systems can be used to manage a patient’s entire workflow within the radiology department, images and reports can be added to and retrieved from electronic medical records (EMRs) and viewed by the authorised radiology staff.

Scheduling: Patient appointments for inpatients and outpatients can be scheduled when an order is received. Functions for scheduling the various available radiology staff with the allocated time slots can also be handled by the radiology information system.

Patient Tracking: The patient can be tracked from admission to discharge, with all the radiology procedures carried out recorded. This would include the patient’s past, present and future appointments.

Results Reporting: Reports concerning the results of an individual patient, a group of patients or a particular procedure can be generated using a radiology information system.

Film Tracking: Individual films can be tracked.




Picture Archiving Communication System (PACS) is a loose term to describe a set of systems that facilitate the archiving, processing and viewing of digital radiological images and their related information.

The images are acquired, archived and retrieved over a network for diagnosis and review by physicians. These images can be interpreted and viewed at workstations, which can also double as archive stations for image storage.

The introduction of client/server computing, improved digital imaging and computer network technologies, along with the advancement of the DICOM and HL7 standards have put PACS along side radiology information systems (RIS) as an ideal solution for managing radiological images. Some of these images include:

X-ray photos

Cycloplegia Retinoscopy

Computed Tomography

Magnetic Resonance Imaging

Radio Isotope



PACS first emerged in the 1980s, although initially trumpeted as a solution to lost films, healthcare organisations, especially the larger ones, have found that digital images can easily be lost as well.

One of the main benefits that PACS provides is the ability to provide a timely delivered and efficient access to images, interpretations and related data throughout the organisation. This helps to ease consultations between physicians who can now simultaneously access the same images over networks, leading to a better diagnosis process.

It is also beneficial to physicians in emergency situations, as they need not wait for long periods in order to view a patient’s radiological images as these are instantly available on the network when ready.

Another feature of PACS is the ability to digitally enhance the images, providing more detailed and sharper images. This improves diagnostic capabilities at radiological examinations.

Since the 1990s, organisations have taken the steps to fully integrate PACS with RIS, when the basic features and adapt needed to mange the acquisition, processing and storage of images, becomes the responsibility of the PACS.

The high costs of PACS has led to vendors offering mini-PACS, which is a cheap alternative for organisations that cannot afford the cost of a full PACS system or those seeking to implement seeing to implement some form of a digital image management system but would rather start off with something small.

While PACS are considered to be at a minimum hospital wide, mini-PACS usually tend to be departmental-based (radiology, emergency room, or orthopedics). Mini-PACS are easy to maintain and cheap to repair, and they can gradually be upgraded to a fully functioning hospital wide PACS.


Advantages of PACS

Rapid access to critical information to decrease exam-to-diagnosis time. This is especially useful in emergency and operating rooms.

Elimination of film, handling and storage cost.

Images can be easily shared between reading radiologists, other physicians and medical records.

Images can be archived at secure locations using database servers manages the transfer, retrieval and storage of images and relevant information; the archive provides permanent image storage.

Radiologists can access soft-copy images instantly after acquisition to expedite diagnosis and reporting at the almost any available workstation.

Web servers can be used to most cost-effectively share images with other departments, even referring physicians across town. They can access the images using the Internet or the local intranet.



برچسب‌ها: EHR, HL7, HIS, سیستم مدیریت بیمارستان, پرونده الکترونیک سلامت
نوشته شده توسط علی نیک مرام در ساعت 8:25 | لینک  | 

Privacy Preserving

  W Ehealth (سلامت Wireless) : سلامت الکترونیک محافظت شده خصوصی و ایمن

با استفاده از هشدار


سرویس سلامت الکترونیک در جاده یک موضوع مهم در سرویس الکترونیک سلامت نسل بعدی است. سیستم های سرویس سلامت بدیع برای فراهم کردن و حمایت سرویس الکترونیک سلامت منحصر به فرد برای نیازهای پزشکی روی جاده مورد نیاز هستند. در این مقاله، ما یک سیستم الکترونیک سلامت بدون سیم محافظتی خصوصی و ایمنی بدیع بر پایه مفهوم و قالب هشدار (یک معماری آگاه مفهومی و ایمنی برای هشداردهی تصادفات ترافیک) و PHR ( پرونده سلامت شخصی ) یکپارچه کردیم. سیستم مفروض، که WEHealth نامیده می شود، یک سرویس PHR سرویس گرا است که از طریق آن رانندگان می توانند اطلاعات سلامتی را در ترافیک به ویژه تحت موقعیت های اورژانسی مشاوره و ویرایش کنند. مهم تر، WeHealth یک سیستم سلامت الکترونیک آگاه خصوصی و ایمن است. زیر ساخت مفروض از حملات  خصوصی / ایمنی جلوگیری می کند.


آغاز قرن بیست و یک جرقه ای در ذهن ما برای استفاده از اطلاعات سلامت الکترونیک برای بهبود سلامت روی جاده ها بود. مردم به ثبت سلامتی روی جاده ها نیاز دارند. در موقعیت های فوری، به عنوان مثال تصادفات ترافیک کمک مراقبتی و پزشکی می تواند در حفظ جان مردم ، بسیار کمک کننده باشد، وقتی تصادفات ترافیکی علت اصل جراحت و مرگ و میر افراد در هر سال هستند. در موقعیت های حاضر مردم بیشتر از گذشته نگران سلامتی خود هستند. به عنوان مثال، آنها می خواهند شرایط سلامتی شان مانند فشار خون، دمای بدن و ... را در هر روز ثبت و کنترل کردند حتی اگر آنها در ماشین باشند. می خواهند از برخی از اتفاقات مانند حمله قلبی جلوگیری کنند. امروزه تحقیق سلامت الکترونیک بازمانده است. انستيتو علمی سلامت (NHI)شروع به کارگیری سیستم ثبت سلامت فردی(PHR) کرده است که هسته سلامت الکترونیک است. در سال 2000، عمل توسعه و تحقیق تکنولوژی اطلاعات و شبکه بندی، نیازهای اعمال تکنولوژی اطلاعات برای سرویس های سلامتی را مشخص کرده است. اما سرویس های سلامتی روی جاده ها هنوز چالش برانگيز است. بزرگترین موانع ، موضوعات خصوصی و ایمنی هستند، چون بیشتر داده های پزشکی درباره بیماران هستند و بنابراین به میزان زیادی حساس هستند. هکرها یا حمله کنندگان می توانند منتظر بمانند، پیغام های مراقبت سلامتی را در جامعه بین فراهم کنندگان سرویس سلامت و بیماران اصلاح و حذف کنند. به عنوان مثال، فرض کنید تصادف ترافیکی رخ داده است و مردم مجروح شده اند. پیغام های مراقب سلامت از فراهم کنندگان سلامت به این بیماران انتقال داده می شوند. حمله کنندگان ممکن است منتظر پیغام بمانند و اطلاعات پزشکی حساس را از مردم دریافت کنند. به هر حال، شناسه های بیمار به حمله کنندگان می رسد، کسانی که می توانند اطلاعات مفهومی بیمار را ثبت و بررسی کنند.هکرها می توانند این اطلاعات خصوصی را به فروش برسانند.در واقع، هر دو نقص خصوصی و ایمنی می تواند موجب نتایج جدی قانونی و مالي شود. این مقاله با انگيزه نیاز برای فراهم کردن سیستم سلامت الکترونیک محافظت خصوصی و ایمن روی جاده ها بسط یابد. به عنوان مثال، مردم در ماشین ها می توانند لباس هایی بپوشند که علائم هشدار اولیه برای حمله های قلبی مانند ضربان قلب، فشار خون و ... کنترل کند. این علائم می توانند به سیستم پرونده الکترونیک سلامت فرستاده شوند، جایی که مدل حمله قلبی می تواند حمله قلبی را پیشگویی کند. اگر حمله قلبی ممکن باشد، روندهای حفظ زندگی فوری باید فعال شود. تلاش اولیه را برای فرض قالب معادل سلامت الکترونیک در شبکه های Wireless ماشینی ارائه کردیم. قالب مفروض یک سکو برای دسترسی PHR و فراهم کردن مراقبت سلامتی پزشکی است. در این مقاله، ما:

 1) یک قالب حصاری را فرض کردیم که کاربران در شبکه ماشینی Wireless می توانند به سیستم پرونده سلامت دسترسی داشته باشند. این معماری WEHealth قالب هشدار و (معماری آگاه از خصوصی و ایمنی را برای هشدار تصادفات ترافیک) و PHR (پرونده سلامت فردی، که توسط NIH توسعه داده شد) را یکپارچه می کند.

 2)روش تایید و اختیار را با استفاده از کمربندی های هشدار به عنوان زیر ساختار pki مشخص می کند.

 3)روش محافظت خصوصی را از طریق مستعارسازی بیان می کند (پردازش جایگزین کردن شناسه های واقعی با شناسه های مستعار).

 ما از کمربند های هشدار دهنده به عنوان زیرساخت برای توزیع مستعارها استفاده کردیم. مستعارها هویت های واقعی کاربران را پنهان می کنند. بنابراین، با استفاده از کمربندها به عنوان زیر ساخت، نه تنها می توانیم به ایمنی برسیم، بلکه می توانیم از حمله های هویت به عنوان مثال حمله های Sybil جلوگیری کنیم.

امکان دارد که برخی از زیرساخت ها بتوانند برای جلوگیری از سطح معین محافظت خصوصی و ایمنی استفاده شوند. به عنوان مثال، یک فراهم کننده سرویس سلامت میتواند به عنوان یک نماینده سرویس عمل کند که مستعارها را برای وسایل نقلیه پیشنهاد دهد و کلید سرویس عمومی را برای وسایل نقلیه منتشر کند. به هر حال، تعداد کمی ریسک وجود دارند. یک مثال حمله با نفرت، حمله ای است که پروسه ضریب آمیز جنایی از تلاش برای بدست آوردن اطلاعات حساس است. مانند نام کاربر، رمز عبور، و پرونده سلامت فردی.

پیشنهاد ما برپایه هشداری است که از فشار فیزیکی روی کمربند برای اجتناب از حمله های ایمنی است. به عنوان مثال، حمله های Sybil و افزایش محافظت خصوصی. تمام تأییدها، محافظت خصوصی و پروسه ایمنی روی زیرساخت بدون تداخل انسانی انجام می شوند. ریسک ها خیلی کمتر از نرم افزار برپایه راه حل است. عیب آن، این است که گران است چون زیرساخت دادیم. اما مزیتش آن است که محافظت ایمنی و خصوصی قوی تری را فراهم کند. وقتی ما درباره پرونده های سلامت فردی که اطلاعات بسیار حساس هستند، نگرانیم، استفاده از هشدار به عنوان زیرساخت منطقی است. به علاوه، هشدارها می توانند آلارم های شدید را برای ماشین های بعدی برای اجتناب از تصادف های شدید منتشر کنند، که اغلب به مسائل پزشکی جدی منجر می شود  چون وسایل نقلیه باید کمربندها را باز کنند که پیغامهای آخرین تصادف را برای ماشینهای عبوری منتشر کنند . بنابراین هشدار میتواند از پیغامهای آلارم برای ماشین ها عمل کند . سایر روشها مانند منتشر کننده رادیویی منتشر کننده بدون سیو محلی و ... شماهای غیر فعال هستند. اگر وسیله نقلیه در کانال ویژه نباشد نمی توانند پیغامهای آلارم را دریافت می کند .

این مطالعه کارهایی را انجام می دهد که شامل:

  1)توسعه یک سیستم سلامت الکترونیک یکپارچه که مردم می توانند برای دسترسی به سیستم  PHR استفاده کنند سوالات پزشکی از سایر افراد پرسیده می شود و نجاتهای پزشکی را در اورژانس در صورت لزوم فراهم میکند. 2)استفاده از زیر ساخت هشدار را برای افزایش پرونده های سلامت الکترونیک و برای محافظت موارد خصوصی بیماران اقزایش میدهد .

 II.کارهای مربوطه

زمینه مراقبت الکترونیک از اوایل سال 1990 ایجاد شده است. بهرحال تلاشهای زیادی روی سلامت در جاده ها تمرکز کرده حتی با این حقیقت که تصادفات جاده اي علت اصلی جراحت ها و مرگ ومیر ها در هر سال هستند .

بررسی موضوعات تحقیق و گرایش به سیستم های سلامت الکترونیک در [kGo6] یافت شده است که موانع و چالشها و وضیت کنونی سلامت الکترونیک را بررسی میکند Dokovsky و همکارانش، سیستم کنترل از راه دور را با استفاده از شبکه های Wireless 2.5/36 فرض کردند. Zhao و همکاران سیستم ارتباط تلفنی vitalpoll را با استفاده از بلوتوث و تکنولوژیهای اینترنت با معماری مرور مشتری توسعه  دادند. سیستم  کنترل سلامتی  و محیطی در مقاله بر پایه شبکه حسگر بدون سیم شکل گرفته توسط Mica2 Motes بود. سایر سیستمهای سلامت الکترونیک مشابه با استفاده از شبکه های حسگر بدون سیم Codeblue, Bignurse T Remotecare, Motecare هستند. Kargi و همکاران انشعاب های قانون و نیازمندیهای  خصوصی و ایمنی سیستم های کنترل را فرض کردند که در شبکه های حسگر بدون سیم استفاده میکند برای انشعابهای قانونی ، کشورهای مختلف قوانین مختلفی دارند ایمنی سلامت الکترونیک شامل یکپارچگی اطمینان و در دردسترس موضوع مهم محلی است اما سیستم های کنترل که در مکان ثابت  به کار گرفته میشوند مانند کلینیک یا خانه وسایل نقلیه در طول جاده حرکت می کنند . به کار گرفتن تمام جاده ها با حسگر ها غیر ممکن است slamanig و همکاران موضوهای خصوصی را در سلامت الکترونیک بیان کردند .

علاوه بر حملات سنتي، نویسنده ،حمله آشکار ناچیز و آنالیز آماری متاداده هایي را فرض می کند. نویسنده مستعارسازی داده پزشکی، مدیریت شناسه تأیید مستعار و ... را فرض کرد. به هر حال، حمله Sybil می تواند باعث مشکل شود. مفهوم k- بی نامی مفروض توسط Samarati و همکاران، حریم خصوصی قابل تحمل را توسط ارتباط کاربر به حداقل k مثبت عمومی کرد. سیستم مکان Crivket حریم خصوصی را به عنوان یک ضابطه طراحی اولیه در نظر گرفت. در این سیستم مکان داده می تواند به کمک دیجیتال فردی توسط کاربر نسبت به هر شخص دیگر تحویل داده شود. مکان خصوصی دیگر که بحث شد توسط استفاده از یک مفهوم جدید از ناحیه مرکب مشخص شد که واحد مساوی با جمع آوری و مرتب سازی بسته ها ایجاد می کند. مفهوم تایید مستعار با استفاده از مجموعه گمنامی فرض شد. هر کاربر یک مجموعه از بی نامی را دارد که می تواند اطلاعات هویت واقعی را پنهان کند.Elmufhi و همکاران و weerasingle و همکاران مهر زمان برای تأیید پرونده های سلامت الکترونیک هستند مزیت استفاده از مهرهای زمان شامل ضمانت های خط زمان و یکنواختی، امتیازات دسترسی محدود به زمان و جلوگیری از تکرار پیغام تأیید است. مهر زمان وقتی مفید است که سیستم استفاده می شود، به خاطر هزینه های بالا تلفن همراه از زمان اتصال استفاده می شود.


III. هشدار

فلسفه متضمن هشدار، این است که تصمیم گیری درباره انتشار اطلاعات مربوط به ترافیک باید در زیر ساخت قرار گیرد و در پایه ماشین هایی قرار نگیرد که ممکن است اطلاعات غیرصحیح یا ناکامل درباره جاده دریافت کنند. زیرساخت در هشدار، با جاسازی حسگرهای کمربندی در جاده در فاصله های مشخص حاصل می شود. همانگونه که در شکل 1 توضیح داده شده. فرض اولیه ما آن است که هشدار توسط حالت اثبات شده است. اگر حمله کننده ها بخواهند کمربندها را پاره کنند، کمربند به تیم نگهداری به سرعت هشدار می دهد. کمربند جدید جایگزین کمربند هشدار داده شده می شود. هر کمربند شامل مجموعه حسگرهای فشار فیزیوالکترونیک، جمع آوری ساده و موتور ترکیبی و چندین فرستنده و گیرنده کوچک است. حسگرهای فشار در هر کمربند به پیغام ها اجازه می دهند تا با ماشین در حال عبور ارتباط برقرار کنند، نیاز به وسیله نقلیه را از بین می برد، در حالی که از مسائل ایمنی مشخص شده در نوشته vanet اجتناب می کند. دو مزیت در استفاده از کمربندها روی زیر ساختار جاده وجود دارد. اول، کمربندها نسبت به دستکاری کردن حساس هستند، دوم، آنها در جای بهتر قرار می گیرند تا ماشین های عبوری را شناسایی کنند و با آنها در یک روش ساده و ایمن ارتباط برقرار کنند.

 وسائل نقلیه در هشدار با ابزار مقاوم به دستکاری تجهیز می شوند، به عنوان مثال، ثبت کننده داده واقعه (EDR)، بسیار شبیه به جعبه های سیاه شناخته شده در برد فضاپیما است. تمام زیر اسمبلی های وسیله نقلیه، شامل واحد فرستنده گیرنده Wireless ، سرعت سنج صفحه نشان دهنده محتوای گاز، حسگر فشار تایر و سنسورهایی برای دمای خارج هستند که اطلاعاتشان را به TRD انتقال می دهند. در نتیجه به فاصله زمان i، TRD می تواند اطلاعات مانند بالاترین و پایین ترین سرعت را در طول زمان i، موقعیت و زمان قوی ترین کاهش سرعت در طول 2 همانند مکان p، زمان t، سیر هدف در مسیر خط را ذخیره کند.

 A.ارتباطات کمربند به کمربند

هر کمربند با چندین گیرنده و فرستنده مجهز می شوند و کمربندها با یکدیگر به صورت مستقیم ارتباط ندارند. به جای آن، کمربند مجاور با ماشین در حال عبور ارتباط برقرار می کند. با ارجاع به شکل 1، جاده دولاینی، که هر لاین کمربند مخصوص خودش را دارد. به عنوان مثال، کمربند c شامل دو زیر کمربند قانون است، که هر کدام به مسیر در جهت مخالف توجه دارند. در مورد بزرگراه تقسیم شده، کمربندها در سمت مخالف مسیر توسط ارتباط سیمی زیر وسط متصل می شوند.

اگر کمربند c پیغام m را به کمربند بعدی B بفرستد، m را پنهان خواهد کرد. برای عبور پیغام پنهان شده m به کمربند B، کمربند C  ،  m را به ماشین در حال عبور d خواهد فرستاد. (همانگونه که در زیر توصیف خواهد شد). وقتی ماشین d به کمربند B می رسد، پیغام m از بین می رود و توسط کمربند B کدگشایی می شود. در عوض، کمربند B تصمیم می گیرد که پیغام را به کمربند A بفرستد. این با استفاده از کلید متقارن  که فقط برای A و B شناخته شده است، انجام می شود.

 b.ارتباطات کمربند به ماشین

با ارجاع به شکل 1، وقتی حسگرهای فشار در کمربند c چرخ های جلویی ماشین c را حس کردند، گیرنده-فرستنده، رادیویی در کمربند، پیغام سلام بسیار ضعیف را روی کانال کنترل استاندارد شامل ID، C کمربند همانند اطلاعات دست تکان دادن خواهد فرستاد. اگر اطلاعات مربوط به ترافیک وجود داشته باشد که به ماشین c، کمربند c مربوط باشد، این اطلاعات را به ماشین خواهد فرستاد. کمربند c ممکن است پیغام m را برای کمربند بعدی B بگیرد پیغام m پنهان می شود. زمان ارتباط بین کمربند و ماشین اثبات شده است که کافی است.

 C.ارتباطات ماشین به ماشین

با ارجاع به شکل 1، فرض کنید که کمربند D پیغام فوری برای ارسال به کمربند C دارد. کمربند B پیغام را که پنهان کرده است به ماشین b خواهد فرستاد و بیت فوری را برای ماشین b تنظیم خواهد کرد که ماشین b باید تلاش کند تا با ماشین هایی که در جهتی به سمت C حرکت می کنند، از طریق پیغام پنهان شده، توسط رادیو ارتباط برقرار کند.

IV. معماری

هر وسیله نقلیه توسط یک فرستنده-گیرنده Wireless با محدودۀ کوتاه و یک پردازشگر ساده به کار گرفته می شود. محدوده انتقال m، 1 است. این می تواند یکی از ابزارهای کوتاه برد کنونی باشد، مانند ابزار Zig Bee یا ابزارهای اینفرارد. هر دو فرستنده-گیرنده بدون سیم و پردازشگر به TRD مجهز می شوند.

همانگونه که در شکل 2 نمایش داده شده است، زیرساخت برای WEHealth شامل ایستگاه پایه فرستنده-گیرنده بدون سیم، کمربندی های هشدار، ایستگاه چک کردن کمربند، سرویس های سرویس و اینترنت است. فرستنده-گیرنده Wireless می تواند بخشی از شبکه LAN بدون سیم باشد. ایستگاه چک کردن کمربندها می تواند چندین فایل آن طرف تر باشد مانند  فایل ایستگاه چک کردن کمربندی مراکز تایید و نمایندگان مستعار هستند.

 7.تایید و اختیار

تایید پروسه، تعیین یک فرد یا چیزی است که در حقیقت کسی یا چیزی که شناسانده می شود. کمربندها با فرستنده-گیرنده، که ایستگاه چک کردن کمربندها نامیده می شوند، به صورت Si+1,Si و ... نمایش داده می شوند و به عنوان کمربندهای تأیید عمل می کنند. هر دو سرورها و ماشین ها از طریق مرکز ، تایید خواهند شد وقتی هر دو آنها می توانند شامل شوند. اگر سرور معتبر باشد، وسیله نقلیه، ID کاربر، رمز عبور کاربر و کلید عمومی ماشین را برای سرور فراهم خواهد کرد. سپس سرور می تواند وسیله نقلیه را تأیید کند.

وسایل نقلیه می توانند سرور را به صورت زیر تائید کنند:

  • سرور به عنوان مثال PHR، کلید عمومی را برای کمربندهای ایستگاه چک کرده با استفاده از روش پنهان سازی سیستمی انتقال خواهد داد.
  • کمربندها کلید عمومی سرور PHR را برای وسایل نقلیه فراهم خواهند کرد.
  • وسیله نقلیه کلید عمومی را از یکی از کمربندها می گیرد وقتی وسیله نقلیه از آن می گذرد و مهر زمان را با استفاده از کلید عمومی برداشته شده پنهان می کند. متن Cipher به سرور PHR ارسال می شود. اگر سرور PHR واقعی باشد، همه زمان را آشکار خواهد کرد و آن را به ماشین بر خواهد گرداند.
  • وسیله نقلیه می تواند چک کند که مهر زمانی از سرور با هر زمان اصل تولید شده توسط خودش یکسان است یا خیر.

همانگونه که در شکل 3 نمایش داده شده است،ایستگاه پایه تائید سرور سرویس است که هر دو کلید عمومی و خصوصی را ایجاد خواهد کرد. کلید عمومی به ایستگاه چک کردن کمربندهای si،    ،... ارسال خواهد شد که i کمتر از مقدار ایستگاه های چک N است و . وسایل نقلیه که برای این جاده تازه هستند، کلید عمومی را برای ارتباط با سرور نیاز خواهند داشت. وقتی چرخ های  سلولی وسیله نقلیه از ایستگاه چک کردن کمربند si می گذرد، کلید عمومی به وسیله نقلیه ارسال خواهد شد. وسیله نقلیه سپس یک مهر زمانی را تولید خواهد کرد و مهر زمان را با استفاده از کلید عمومی pk(r) پنهان خواهد کرد. متن cipher  pk(r) به سرور انتقال داده می شود. در سرور سرویس، متن cipher با استفاده از کلید خصوصی اشکار می شود، همانگونه که نشان داده شده است Dpk(r) و سرور سرویس به مهر زمان از متن cipher می رسد. سرور سرویس مهر زمانی را به وسیله نقلیه بازمی گرداند. در وسیله نقلیه، اگر مهر زمان از سرور با مهر زمان روی  وسیله نقلیه یکسان باشدف سرور معتبر است. عملیات به صورت موفقیت آمیز پیش میروند. در غیر این صورت، عملیات به پایان خواهند رسید.


سرور می تواند وسایل نقلیه را با چک کردن ID کاربر و رمز عبور تائید کند. با دانستن رمز عبور فرض می کنیم که تضمین کند که نام کاربر صحيح است. از ابتدا با استفاده از رمز عبور اختصاص داده شده یا شناسائي شده و ID کاربر ثبت نام می شود و در هر استفاده متوالی، کاربر باید از رمز عبور شناس مانده قبلی استفاده کند. رمز عبور کاربر توسط کلید عمومی سرور پنهان می شود. بنابراین هیچ کس نمی تواند آن را به استثنای سرور آشکار کند. یک مثال از چنین تائیدی آن است که سیستم PHR کاربر دانش را تائید می کند. هر کاربر DHR در سیستم PHR ثبت نام می کند و در PHR با استفاده از نام کاربری و رمز عبور وارد می شود. وقتی یک کاربر وارد می شود، می تواند به پرونده های سلامت دسترسی  داشته باشد. ، وسیله نقلیه که توسط سرور سرویس تائید شده است، سرور معتبر است که رمز عبور UID را پنهان خواهد کرد و کلید عمومی وسیله نقلیه را با استفاده از کلید عمومی سرور پنهان خواهد کرد، همانگونه که در PIC(UID+Passwd vpk) نمایش داده شده است. متن cipher به سرور سرویس منتقل می شود. سرور سرویس اوّل متن cipher را با استفاده از کلید خصوصی آشکار می کند و سپس معتبر می کند، اگر کاربر واقعا با چک کردن ID کاربر و رمز عبور در سیستم باشد. اگر کابر معتبر باشد، محتوای سرویس با استفاده از کلید عمومی وسیله نقلیه پنهان می شود، همانگونه که توسطVpk(Phr)   نمایش داده می شود. این متن cipher به وسیله نقلیه منتقل می شود و با استفاده از کلید خصوصی وسیله نقلیه  در وسیله نقلیه آشکار می کند.

وقتی سرور کابر تائید شدند، تایید سازی روابط بین سرور و کاربر می تواند تضمین شود. اگر سرور تلاش کند که پنهان را به کاربر ارسال کند، سرور از کلید عمومی وسیله نقلیه برای پنهان کردن پیغام استفاده می کند. اگر کاربر تلاش کند که پنهان را به سرور بفرستد. کاربر با استفاده از کلید عمومی سرور آن را پنهان خواهد کرد.

 VI. محافظت از حریم خصوصی

پیغام مبادله بین وسایل نقلیه موارد خصوصی راننده /کاربر را آشکار خواهد کرد. به عنوان مثال، مکان کاربر، تعیین کننده سرعت، الگوهای تحرک و ... بنابراین نام مستعار موارد خصوصی کاربر به ویژه مکان خصوصی و بی نام باید محافظت شوند. مکان خصوصی به این معنی است که مکان یک کاربر می تواند به هویت او متصل شود. ارائه های نامناسب ان داده ها باعث می شود که موارد خصوصی برای کاربران دارای نقص باشد، که در عوض به نتایج جدی  قانون منجر می شود.

ایده اولیه محافظت خصوصی مستعار سازی است. مستعار سازی روندی است که تمام هویت های فردی در ثبت داده توسط یک نعیین کننده مصنوعی جایگزین می شوند. نام مستعار مصنوعی به بازگردادن داده به منشاء آن از داده نام کد تمام داده های مربوط به فرد از بین رفته اند، منجر می شود. اگر چه ما فقط درباره مستعار سازی روی لایه کاربردی بحث كرديم، اين ایده می تواند برای لایه های پایین تر باشد بعبارتي جهت جلوگیری از شکاف هویت از لایه هاي پایین تر استفاده شود. ما به نماینده مستعارسازی نیاز داریم که یک نام مستعار را برای وسایل نقلیه اختصاص دهد. وسایل نقلیه نام های واقعی شان را پنهان می کنند از نام های مستعار برای ارتباطات بعدی استفاده می کنند. ایستگاه چک کردن کمربند، نماینده های مستعارسازی هستند که هویت های مصنوعی را برای وسایل نقلیه ایجاد می کند. وقتی چرخ های جلویی وسیله نقلیه روی ایستگاه چک کردن کمربند فشار آورده شود، وسایل نقلیه یک نشان از کمربند دریافت می کنند. اگر وسیله نقلیه برای این ناحیه اجازه تازه وارد باشد، پیغام«سلام» فرستاده می شود.« سلام. من تازه وارد هستم». کمربندهای ID وسیله نقلیه را با کنترل ID فیزیکی فرستنده-گیرنده کنترل می کنند. اگر ID جدید باشد، یک نام مستعار برای وسیله نقلیه با ارزش زمان برای زندگی (TTL) ایجاد خواهد کرد و این پیغام TTL - مستعار را به هر دو وسیله نقلیه و سرور سرویس انتقال خواهد داد. در غیر اینصورت،درخواست مستعارسازی را رد خواهد کرد. وقتی وسیله نقلیه به نام مستعار میرسد. آنها می توانند از این ID مصنوعی برای ارتباط برقرار کردن با سرور سرویس استفاده کنند.


یک حمله ممکن، حمله Sybil است که تعداد زیادی از هویت های مستعار را با استفاده از آنها برای رسیدن به اثر بزرگ غیر نسبی ایجاد می کند. ID های مستعار چندگانه را در هر نماینده ID ایجاد می کند (که ایستگاه ها چک کردن کمربند،  si، و ...هستند). به هر حال، ما می توانیم از این نوع حمله جلوگیری کنیم. کمربندهای نماینده ID ، لیست ID انطباق میدهند و در هر دوره زمان، به صورت غیر فعال لیست ID را بین سیستم ها انطباق می دهد. وقتی ID ، ID فیزیکی فرستنده - گیرنده وسیله نقلیه است. این ID منحصر به فرد و اثبات شده در مقابل دستکاری است. حمله کننده Sybil نمی تواند به این ID تکیه کند. اگر نماینده ID ، ID صفر در لیست ID را یافت، درخواست مستعارسازی را رد خواهد کرد. شکل 5 نشان می دهد که لیست ID بین کمربندهای نماینده ID و سرور سرویس ترکیب می شود. یک وسیله نقلیه می تواند به نام مستعار معتبر در طول TTL برسد.

   نگرانی ديگر معنا شناسی کمربندها است. معنا شناسی کمربند ها آن است که کمربندها زیر ساختارهای ساده هستند. به پیشنهاد اصلی هشدار انتظار نمی رود که کمربندها نتوانند پنهان سازی و آشکارسازی را انجام دهند، چون سخت افزار کمربندها ساده و ارزان است. به هر حال، راه حل های یک چینی برای پنهان سازی و آشکارسازی وجود دارند. Wong و همکاران پنهان سازی آشکارسازی متقارن را پیشنهاد کردند  که روی چیپ Xilinx xc4000 پیاده سازی شده است که کامل و ارزان است. بنابراین، ما می توانیم قابلیت پنهان سازی آشکارسازی را بدون افزایش هزینه انجام دهیم.

 VII. دسترسی به پرونده سلامت فردی

•        A. سیستم پرونده سلامت فردی

PHR (پرونده سلامت فردی) یک کاربرد کامپیوتری است که اطلاعات سلامت فردی را ذخیره می کند. بنابراین چندین نوع PHR، به عنوان مثال، بر پایه PC، بر پایه اینترنت، و PHR بر پایه اینترنت را توسعه داده است که از طریق مرورگر وب ویرایش می شود، در دسترس قرار می گیرد. PHR شامل تاریخچه پژشکی بیمار، آلرژی های دارویی، برنامه های مراقبت، آلرژی، جراحی، تست پژشکی و ... است.

 •        B. دسترسی به PHR

WEHealth یک راهی برای دسترسی به سیستم PHR فراهم می کند، در حالی که مردم روی جاده ها حرکت می کنند. وقتی دسترسی به PHR به چند عملیات تعاملی نیاز دارد، به رانندگان توصیه نمی شوند که عمل کنند. اما افراد دیگر در وسیله نقلیه می توانند عملیات دسترسی را انجام دهند. در وسایل نقلیه ایستگاه موبایل سلولی نصب می شود که می تواند به ایستگاه پایه سلول دسترسی داشته باشد.

به خاطر محدودیت عرض باند، ما باید مطمئن شویم که برخی از عرض باندها برای موقعیت های حفظ زندگی محافظت می شوند.بنابراین وسیله نقلیه، سهم عرض باند را از کمربندها خواهد گرفت، قبل از این که به PHR دسترسی داشته باشد. وقتی که عرض باند کافی برای PHR و جود دارد، دسترسی ایجاد می شود. کاربر می تواند از طریق صفحه نمایش وسیله نقلیه عمل کند. کاربر به سیستم PHR با استفاده از نام کاربر رمز عبور وارد خواهد شد. وقتی وارد سیستم شد، کاربر می تواند پرونده های سلامت را ببینید و ویرایش کند. یک صفحه سیستم PHR در شکل 6 نمایش داده شده است. به عنوان مثال، کاربر می تواند روی کلمه«داروها» برای گسترش آن و چک کردن داروهایی كه باید تهیه کند کلیک کند.

 VIII. پرس وجوی پزشکی

پرس و جوهای پزشکی می توانند در سیستم منتشر شوند. کاربران می توانند با سایر افراد درباره سوالات پزشکی  از طریق کمربندها پرس و جوی کنند، به عنوان مثال:«نزدیک ترین بیمارستان کدام است؟» آیا آنجا پزشکان حضور دارند؟ این سوالات به کمربندها ارسال خواهد شد. سایر وسایل نقلیه این پرس و جوها را از کمربندها برمی دارند. اگر برخی جواب را بدانند،به آن پاسخ خواهند داد و جفت سوال-پاسخ به کمربندها ارسال خواهند کرد. برای هر چندین مایل، ما ایستگاه چک کردن si را داریم که در شکل 2 نمایش داده می شود. ایستگاه چک کردن تمام جفت های سوال-جواب را جمع آوری خواهد کرد و این پیغام ها را به سرور پرس و جو انتقال خواهد داد. سرور پرس و جو این پیغام ها را به اینترنت خواهد فرستاد. کاربران اینترنتی همانند متخصصان پزشکی آنلاین می توانند جواب ها را ارسال کنند. درخواست کننده پرس و جو می تواند وارد سرور پرس و جو شود وبه جواب ها در خانه یا ماشین دسترسی داشته باشد. در هر حالی که کاربر نام مستعار دارد و هویت کاربر فاش نشده است.

 IX. مثال کاربردی: مراقبت پزشکی بعد از تصادف

وقتی تصادف رخ می دهد، نیاز فوری برای مراقبت پزشکی وجود دارزد. WEHealth می تواند مراقبت پزشکی را در سه روز فراهم کند. زیر ساختار هشدار می تواند به انتشار هشدار تصادف و پرس وجوهای پزشکی کمک کند. سیستم سلولي به سرعت می تواند تصادف را به مجری قانون و نزدیکترین مراکز پزشکی گزارش دهد. مامور نجات تصادف ترافیک می تواند نجات را از راه دور  نیز انجام دهد. سیستم PHR می تواند پرونده های سلامت بیماران را فراهم کند. سه سیستم  می توانند با هم ترکیب شوند و به صورت موازی در یک زمان عمل کنند.

پیاده سازی مثال در شکل 7 نمایش داده شده است. برای ساده کردن پیاده سازی، از سیستم سلول(شامل ایستگاه های موبایل) به عنوان شبکه ارتباط بدون سیم استفاده می کنیم. ایستگاه های موبایل روی هر وسیله نقلیه کمربند ایستگاه چک کردن هشدار نصب می شوند. ایستگاه های موبایل روی وسایل نقلیه می توانند تلفن های سلول اولیه باشند. ما می توانیم از تلفن سلول به عنوان تداخل نهایی کاربر استفاده کنیم. متن پیغام می تواند محتوایی داشته باشد که روی صفحه نمایش داده شود. وقتی تقریباً تمام تلفن های سلول می توانند متن پیغام را ارسال و دریافت کنند، پیغام به عنوان تداخل پایه کار خواهد کرد. برای تلفن های هوشمند، لپ تاپ ها و یا سایر ابزارها که ویژگی هایی مانند صفحه نمایش بزرگتر، پردازش سریعتر یا حافظه بیشتر را دارند، ما می توانیم یک تداخل کاربری پیشرفته مانند پورتال وب فراهم کنیم. ورودی ها،تغییرات و مسیرها بین ایستگاه های پایه سلولی و سرورها نیاز به اصلاح شدن ندارند. وقتی یک تصادف رخ می دهد.

 یک سوی از عملیات وجود دارند،همانگونه که در شکل 8 نمایش داده شده است. اوّل، تصادف به مجری قانون، نزدیک ترین مرکز پزشکی، سیستم های جزء، سرورهای پرس و جو و ... از طریق سیستم های سلولی ارسال می شود. این سیستم ها گزارش تصادف را دریافت می کنند، آن را تائید کرده و به آن پاسخ می دهند(مانند دادن دستور به ماشین های درگیر، با اجازه بیماران در تصادف، پرسنل پزشکی می توانند به سیستم PHR آنها از طریق سیستم سلول برای استخراج پرونده هاي پزشکی بیمار وآغاز روندهای پزشکی تا جای ممکن دسترسی داشته باشد. برخی از پرس و جوهای پزشکی می توانند روی اینترنت جمع آوری شوند ، به عنوان مثال، یک پرس و جو/ در خواست، از نوع ویژه فوق. در همان زمان، وسائل نقلیه در هر دو جهت می توانند تصادف را به کمربندها گزارش کنند. وقتی کمربندها گزارش های کافی را جمع آوری می کنند و تصادف را تائید می کنند، کمربندها پیغام های هشدار و یک مسیر پیغام جدید برای ماشین ها برای جلوگیری از تصادف ایجاد می کنند.

 به ویژه، ایمنی و خصوصی در WEHealth در مورد یک تصادف محافظت می شوند. کمربندها کلید عمومی را برای ماشین ها توزیع می کنند. هر دو وسیله نقلیه و سرور PHR تایید می شوند. همانگونه  که در بخش 7 بحث شد. پرونده هاي پزشکی حساس پنهان می شوند. پیغام های دیگر مانند پیشنهادهای نجات تصادف از سیستم جزء پنهان می شود. نام های مستعار به جای هویت های واقعی استفاده می شوند. حمله کنندگان نمی توانند هويت ویژه را آزمایش کنند.


این مقاله یک سیستم مراقبت WEHealth را فرض کرده است که می تواند در بخشی از تلاش جامع مانند علامت الکترونیک باشد. این کار دری را، براي تحقیقات آینده روی مراقبت سلامت ملی به ویژه روی شبکه های بدون سیم وسایط نقلیه باز می کند.با استفاده از این مفهوم  و حصاری هشدار PHR ، WEHealth یک کاربرد سرویس سلامت در ترافیک همانند سکوی آگاهی خصوصی و بدیع است. کاربران روی جاده می توانند پرس وجوهایی را انجام دهند که مي تواند توسط سايرکاربران جاده ها ، كاربران اينترنت و متخصصين online‌ جوابدهي شود. كاربران می توانند به پرونده سلامت فردی پرسنل دسترسی داشته باشند. در یک موقعیت تصادف کاربران در جست و جوی  کمک پزشکی با استفاده از پزشکان داوطلب و با مشاوره خبرگان نجات تصادف كه آنلاین هستند. در همان زمان زیر ساخت می تواند به سایر وسایل برای جلوگیری از تصادف شدیدتر هشدار دهد. ارتباط این مطالعه شامل رسیدن به امکان پذیری ایجاد زیرساخت اطلاعات سلامت ملی و توسعه قالب کمک پزشکی در نجات تصادف است. یک ارتباط مهم آن این است که ایمنی و حریم خصوصی تحت زیر ساخت پیشنهاد ما حفظ شوند.                  


 گردآوری و ترجمه : مهندس علی نیک مرام

کپی با ذکر نام و یا آدرس وبلاگ بلا مانع است



نوشته شده توسط علی نیک مرام در ساعت 10:53 | لینک  | 

Privacy Preserving

رابطه پرونده  الكترنيك سلامت و حفظ حريم خصوصي

با استفاده از تعيين كنندهاي مستعار

  چكيده- با اشتراك گذاشتن اطلاعات دقيق و قابل اعتماد .در مراقبت از سلامتي لازم است. هم اكنون اطلاعاتي درباره بيماران در پرونده هاي پزشكي محفوظ است كه توسط تعداد زيادي از تأمين كنندگان سلامت جداگانه نگهداري مي شود. ارتباط بين اين ها براي سيستم هاي پرونده الکترونیک سلامت جهاني لازم است، اما اين بايد به روشي انجام شود كه نه تنها نيازمندي هاي محرمانه داده سنتي را راضي مي كند، بلكه با نيازهاي خصوصي فردي بيماران نيز برخورد داشته باشد. ما در اينجا حصاري در ارتباط با پرونده الکترونیک پزشکی به روشي ارائه مي دهيم كه به بيمار كنترل روي آنچه كه به او مربوط است، را بدهد. اين روش با استفاده از تعيين كننده هاي مستعار انجام شده است. ما توضيح مي دهيم كه چگونه اين مهارت مي تواند با استفاده از تكنولو‍‍‍ژي هاي حاضر پياده شود. يك مورد مطالعه براي نمايش اين كه چگونه مهارت ما دقت نيازهاي داده و نيازهاي خصوصي بيماران را قانع كنند استفاده شده است.


       اطلاعات داراي يك طراحي مفيد در هر قلمرو كاري است.  اما در هر قلمرو ، رسالت افراد بسیار مهم است و  می تواند از تحقیق پزشکی سودگیرد. متاسفانه اطلاعات پزشکی درباره یک فرد ویژه توسط فراهم کنندگان خدمات سلامت مختلف نگهداری می شود و در پایگاههای مجزا در فرصت های ناسازگار ذخیره می شود. بنابراین ارگانهای سیاسی قدرتمندی در بسیاری از کشورها وجود دارند تا این را به سیستم های ثبت سلامت الکترونیکی در کل کشور(EHR) Electronic Health Record  متصل سازند.

از وقتی اطلاعات به اشتراک گذاشته می شود، جمع آوری داده، نگرانی های ایمنی اشتراك را به وجود می آورد که قبلاً جداگانه نگهداری می شد و نقاط ویژه ای از خطا را برای کنترل دسترسی فراهم می کرد. علاوه برآن طبیعت فردی اطلاعات پزشکی به این معنی است که ما باید به امور معرفی هر بیمار توجه داشته باشیم . در حالی که مکانیزم های اطمینان داده سنتی به دادن کنترل  اطلاعات به مالک آن درباره دسترسی پذیری کمک می کند، خصوصا به معنای دادن موضوع اطلاعات  به کسی است که به آن دسترسی دارد . بنابراین حتی پرونده الکترونیک سلامت توسط روسای حکومتی مدیریت و نگهداری خواهد شد، بیمارانی که این پرونده ها را دارند باید روی کسی که این اطلاعات را می بیند کنترل  داشته باشد.

به ویژه تأسیس یک سبستم پرونده الکترونیک سلامت (EHR) مسئله اتصال اطلاعات جمع آوری شده درباره خویشاوندانشان  در پایگاه داده جداگانه ایجاد می کند.این اطلاعات ممکن است به چندین گذشته بازگردانده و ممکن است در ناحیه جغرافیایی بزرگ پخش شوند و ممکن است توسط تعداد زیادی از تامین کنندگان سلامت بررسی شوند. این پرونده هاي پزشکی خصوصی کمبود یک تعیین کننده رایج را خواهند داشت. اغلب اوقات گفتن این که به چه کسی تعلق دارد  مشکل است. این وضعيت به این معنی است که ایجاد سیستم های پرونده الکترونیک سلامت توسط موضوع خصوصی مجزا می شوند.

  • نیاز برای اتصال پرونده هاي بیماران  وقتی شباهت های پزشکی قانونی کمبود یک تعیین کننده رایج دارند. اتصال آنها از طریق تعیین کننده داده حالت اسم، تاریخ تولد، جنسیت و آدرس مشکل است. به هر حال این کار ممكن كافي نباشد چون این داده ممکن است کامل نباشد یا به خاطر خطای ورودی داده دقیق نباشند. پیشنهاد به بیماران برای بررسی پرونده ها، کمک به آنها برای تصمیم گیری درباره این که متصل شوند یا نشوند، نگرانی های مخصوصی را براي اجازه دادن ایجاد می کنند به عنوان مثال یک بیمار ، پرونده پزشکی مربوط به بیمار دیگر با نام مشابه خودش را مشاهده می کند.
  • نیاز برای اجازه دادن به بیماران برای این که ارتباطات خصوصی مطمئنی داشته باشند. نگرانی های خصوصی فردی ممکن است آرزوی علوم اتصال پرونده ها را ایجاد کند. به عنوان مثال یک بیمار ممکن است نخواهد وجود پرونده هاي پزشکی را برای تامین کنندگان سلامت ویژه آشکار کند. مانند تکنیک های اعتیاد دارویی با نقطه برای یک بیمار پنهان کردن این حقیقت که آنها در موسسه پزشکی ویژه ای در گذشته شرکت کرده بودند ، موفقیت آمیز است. حتی برای تعیین کنندگان بیمار  که در آن موسسه کاری کردند نیز نباید آشکار شود. و عدم اجازه به بیماران برای پنهان کردن اطلاعات ،یک راه حل خوب نیست، چون بیماران داده ای را که به حفظ امور خصوصی آنها مربوط است را از بین خواهند برد بنابراین تجمع شباهت های پزشکی آنها را تحت تأثیر قرار می دهد.
  • نیاز برای غلبه بر قوانین خصوصی در برنامه های ویژه .  برخلاف امور خصوصی بیمار ، قوانینی وجود دارند که دسترسی به تمام داده های پزشکی بیمار به ویژه در موارد اورژانسی که زندگی بیمار در خطر است را مجاز نکرده.

در این مقاله ما یک معماری را برای حفظ تعیین کنندگان بیمار توصیف می کنیم که تمام نیازهای ایمنی بالا را نیز دارد. ما علاقه مندبه اين سناريو هستیم كه بيمار بيش از يك پرونده الكترونيك پزشکی (EMR ) براي فراهم كنندگان مراقبتهاي سلامت دارد و درهر کدام داده پزشکی معینی از آنها كه در برخي حساس و بعضی دیگر نیستند. بعبارتي ما می خواهیم به (Electronic Medical Record)EMR  متصل شویم تا به داده ها اجازه دهیم از پرونده الکترونیک سلامت واحد برای دیده شدن توسط فراهم کنندگان سلامت مجاز جمع آوری شوند، اما به گونه ای انجام شود که تمایلات خصوصی بیمار را نیز حفظ کند.


II . زمينه

        مشاهدات پرونده هاي الکترونیک پزشکی فردی توسط یک فراهم کننده سلامت ویژه پذيرفته مي شود. اين پرونده ها شامل برخي ويژگيهاي هويتي است (مانند ،آدرس ، جنسیت ، سن). هر EMR   بطور نرمال يك شناسه منحصر به فرد در داده هاي ارائه كنندگان مراقبت ها دارد كه هويت بيمار را معين ميكند. .هر EMR   شامل چندین جنبه از ثبت های پزشکی توزیع شده بیمار است. برای رسیدن به این هدف یک شناسه واحد می تواند بین تمام سیستم های پرونده هاي الکترنیک پزشکی استفاده شوند و بیمار را در تمام پایگاه داده ها از طریق شناسه فردی قابل تعیین سازد. به هر حال پیاده سازی این پیشنهاد به عنوان یک مشکل دیده می شود و چند سال به خاطر فرصت داده مسائل مزبور به سلامت طول بکشد.

اكنون پروژه هاي EHR  در چندين كشور از جمله در آمريكا ، انگليس و استراليا براي كمك به توليد EHR  ملي و پرونده الكترونيك سلامت براي هر بيمار در حال پيشرفت است. هر پرونده الكترونيك سلامت شامل جنبه هاي مختلف پرونده پزشكي توزيع شده است. در اين پرو‍ژه ، يك شناسه منحصر به فرد براي كل سيستم EHR  استفاده می شود و كليه داده هاي پرونده الكترونيك سلامت تنها با يك شماره شناسه قابل شناسائي است. با اين حال پياده سازي چنين پروژه اي بسيار مشكل بوده و چندين سال بطول مي انجامد.

علاوه بر آن عمل ایمنی ضعیفی برای استفاده از همان شناسه هایي که  برای چندین سرویس دیجیتال به خاطر اثر ایمنی در نظر گرفته می شود وجود دارد که شامل این شناسه است که سرویس های مربوطه را خواهد داشت. بنابراین داشتن یک شناسه فردی بیمار به خاطر ریسک های ایمنی که دارد برای تمام فراهم کنندگان سلامتی ممکن نيست كه مورد قبول باشد. به ویژه داشتن یک شناسه واحد ممکن است تمایلات خصوصی بيمار را برهم بزند، چون بیماران اغلب مزایایی را در حفظ هویت مجزا می بینند.

بنابراین، نیاز برای دسترسی و جمع آوری پرونده هاي الکترونیک توزیع شده بیمار در همان زمان تضمین می کند که نگرانی های خصوصی بیمار تامین شده است. به منظور داشتن یک ارتباط EMR موفق ، ما نیاز داریم که نیازمندی های زیر را در نظر بگیریم:

1)پرونده الکترونیک سلامت منحصر به فرد بیمار باید به یک روش دقیق  و ایمن ساخته شود. به عنوان مثال پرونده هاي دو بيمار متفاوت با نام مشابه  Smith  John نباید ادغام شوند.

2)هویت های محلی بیمار(در هر فراهم کننده سلامتی) نباید به هر بخش خارجی اعلام شود.

3)بیماران باید تنها افرادی باشند که درباره مکان EMR اطلاع داشته باشند.

اتصال تعداد زیادی از پرونده های الکترونیک پزشکی، بطور قانونی برای جمعیت هایی از بیماران زمانی که حریم خصوصی هر بیمار حفظ شود یک کار دقیق است. تا امروز دو روش اولیه برای ایجاد شناسه هاي منحصر به فرد هر بیمار وجود داشته است. دستي و اتوماتيك.

به عنوان مثال روش دستی سیستم ارتباط داده استرالیای غربی برای اتصال پرونده های پزشکی بیماران توسعه داده شد و در پروژه طراحی شده برای مطالعه دیابت در جمعیت استرالیای غربی استفاده شد. این سیستم از داده های الکترونیک این اتصال به فراهم کنندگان سلامت برای انتقال EMR بیمار استفاده می کند. پردازش ارتباط پرونده هاتوسط تیم تخصصی ویژه در انطباق داده با استفاده از داده شخصی شناسه هاي بیمار بدون دسترسی به داده بیمار مربوطه یا هویت فراهم کننده اطلاعات انجام  شد. این پردازش اتصال دستی آزمایشگاهی از وقتی سیستم تأسیس شده فقط یک بار انجام شد. اگرچه برای اهداف این پروژه پزشکی کافی است:

  • قابلیت اطمینان و دقت شناسه ها و داده های فردی برای تشخیص پزشکی لازم است. با جدا کردن بیمار از این پروسه اتصال، این روش در استفاده از بهترين ايمني و دانش از تاریخچه پزشکی گذشته بيمار ، دچار خطا مي شود. ارتباط دقیق برای اهداف تحقیقاتي که به صورت زمان به ویژگی های جمعیت نه تمام افراد مربوط است ، بحرانی نیست .
  • بيمار هيچ كنترلي روي اين  پروسه ارتباط ندارد زيرا كه كنترل اختيار مراقبت هاي سلامت با كسي است كه به اطلاعات متصل است.

ارتباط پرونده ها توسط ابزارهای اتوماتیک انجام شده است. به عنوان مثال الگوریتم های انطباق احتمال برای آنالیز پرونده ها برای تعیین این که به این پرونده ها مربوط هستند یا خیر استفاده شده است.

این شباهت ها توسط بخش ستونی آنالیز می شوند. به عنوان مثال خبرگان انتخاب یا سیستم های انطباق که از یک متن ارائه واضح داده هویت بیمار یا یک نسخه پنهان استفاده کند.

این پرونده ها می توانند به بخش سوم به یک روش امن مانند نماینده منتقل شود ، که به پنهان کردن منبع پرونده ها کمک می کنند. انطباق اتوماتیک به نتایج زیر منجر شود:

 انطباق شامل انطباق ممکن یا عدم انطباق. برای هر نیازمندی ، یک ارتباط بالا مورد قبول نیست وقتی به یک پروسه ارتباط دقیق برای تشخیص پزشکی نیاز داریم. همچنین ارتباط EMR بیمار با استفاده از داده هویت ممکن است به نیازمندی خصوصی بیان شده در نیازمندی  برسد.بنابراین استفاده از انطباق بخش سوم یا روش های انطباقی احتمالی برای اتصال EMR کافی به نظر نمی رسد.

 III.کارهای مرتبط

        به جای آن بهتر است بیمار نقش اصلی را در پروسه ارتباط  EMR بازی کند، زمانی که بیمار از تاریخچه پزشکی خودش، مکان قبلی سکونت و... آگاه است. پروسه ارتباط EMR می تواند توسط ارتباط شناسه محل بیمار در هر فراهم کننده سلامت با یک روش امنی که در نیازهای فوق الذکر موجبات رضایت را فراهم کند. مدیریت شناسه و هویت یکپارچه ( FIM ) تکنیک هائی را توصیف می کند که چگونه به کاربران اجازه دهند که ارتباطی را بین شناسه های محلی با ایجاد یک تعیین کننده مستعار منحصر به فرد ایجاد کنند. معماری FIM مجموعه ای از تعاملات را بین یک فراهم کننده هویت(Idp) و یک فراهم کننده سرویس(sp) برای ساده سازی چندین سرویس مانند ثبت و مبادله گرایش به اتصال حساب تعیین می کند. یک فراهم کننده شناسه(Idp)، شناسه ای است که کاربران را معتبر می کند و بیانیه ای از تایید و اعتبار و نیز بیانیه ای از مشخصه در ارتباط با (SAML) زبان امن و ویژگی پرتکل ایجاد می کند. یک فراهم کننده سرویس(SP) یک شناسه ای است که سرویس های برپایه وب را برای کاربران فراهم می کند. یک شناسه می تواند نقش Idp یا sp یا هر دو را داشته باشد. در کاربردهای ما، یک فراهم کننده سلامت هر دو نقش را بازی می کند، یک  Idpبرای فراهم کردن اختیار برای کاربران EMR و یک sp  در فراهم کردن دسترسی به EMR بیماران .

از وقتی این فراهم کنندگان سلامت در یک توافق قابل اعتماد هستند ، با استفاده از این خط مشی بیماران می توانند شناسه های محلی خود را در فراهم کنندگان سلامت متفاوت مرتبط کنند. نتیجه این پروسه ارتباط، یک ارتباط جدید بین پرونده های الکترونیک پزشکی بیماران است. پروسه اتصال هویت می تواند با استفاده از تعیین کننده مستعار منحصر به فرد انجام شود که با هر شناسه محلی مرتبط است. این تعیین کننده مستعار به عنوان مرجعی برای بیمار به خدمت گرفته خواهد شد و وقتی استفاده می شود که این فراهم کنندگان سلامت بخواهند اطلاعاتی درباره هر بیمار را مبادله کنند. با استفاده از مدیریت هویت منحصر به فرد، بیماران می توانند EMR ها را به یک روش دقیق و ایمن به اشتراک بگذارند. بدبختانه، این پروسه در فراهم کردن نیازمندی فوق الذکر دچار خطا می شود. در این جا، هر فراهم کننده سلامت می داند که بیمار EMR سایر فراهم کنندگان سلامت را حفظ خواهد کرد که همان تعیین کننده مستعار به اشتراک خواهد گذاشت. علاوه بر آن، بیمار ممکن است به ایجاد چندین حساب منحصر به فرد به منظور اتصال هویت ها در هر فراهم کننده سلامت نیاز داشته باشد که به شبکه شناسه منحصر به فرد پیچیده منجر می شود که مدیریت آن برای بیمار مشکل است.

در کل، هیچ کدام از تکنیک های حاضر برای مدیریت شناسه منحصر به فرد برای کاربردهای ارتباط پرونده  سلامت ایده آل نیست، از وقتی که آنها به اندازه کافی به ملاحظات هندسی مرتبط با اطلاعات پزشکی فردی توجه نکرده اند. هدف ما، این است که نشان دهیم چگونه سطوح لازم امنیت و خصوصی برای ارتباط پرونده های پزشکی می تواند توسط تکنولوژی های حاضر حاصل شود.

 IV. معماری برای مدیریت شناسه EHR

      اگرچه مدیریت شناسه منحصر به فرد نمی تواند یک ارتباط بین شناسه های محلی بیمار  به روشی که رضایت هر بیمار را در تمایلات خصوصی شان فراهم کند، ما در اینجا نشان می دهیم که مکانیزم یکپارچه سازی می تواند گسترده شود تا راه حلی برای این مسأله فراهم کند. ما نقش فراهم کنندگان شناسه را برای شمول سرویس ارتباط هویت برای تمام شناسه های محلی بیماران و عمل به عنوان یک واسطه برای ارتباطات بین فراهم کنندگان سلامت گسترش دادیم. برای انجام این کار معماری شامل چهار تابع است: ارتباط شناسه، کنترل دسترسی، ارزیابی و جمع آوری پرونده (شکل 1).

  A .  تابع ارتباط هویت

        تابع ارتباط شناسه جزء اصلی معماری مدیریت شناسه سیستم پرونده های الکترونیک سلامت است. دو سرویس را فراهم می کند. ارتباط شناسه و اعتباربخشی. پروسه های ارتباط، تابع ارتباط شناسه به دسترسی های بیماران به سیستم EHR اعتبار می بخشد و برای بیمار سرویسی را فراهم می کند که اجازه دسترسی  به سیستم های فراهم کنندگان سلامت را می دهد که منحصر به فرد هستند. سرویس ارتباط شناسه به بیماران اجازه می دهد که به سبک های پزشکی الکترونیک برای پرونده های الکترونیک سلامت توسط ارتباط شناسه اولیه EHR ثانویه بیمار که توسط هر فراهم کننده سلامت استفاده می کند. انجام شود.

 B. تابع کنترل دسترسی

        بیان تمایلات کنترل دسترسی بیمار و اجبار استفاده های قانونی پرونده های الکترونیک سلامت نیازمندی های بحرانی در هر سیستم EHR هستند. در معماری ما تابع کنترل دسترسی، مسئول ارزیابی تمام درخواستهای دسترسی بعنوان سیاست های کنترل دسترسی که توسط بیمار و اختیارات پزشکی مناسب تنظیم می شود می باشد. در اینجا بیماران تمایلات خصوصی را با انتخاب سیاست های کنترل دسترسی مناسب تنظیم می کنند در حالی که مراجع پزشکی قانونی و مشروع استفاده از EHR را با تنظیم سیاست های کنترل دسترسی کافی تضمین می کند که همکاران پزشکی به اطلاعات دسترسی دارند که برای نقش کنونی آنها که شامل دسترسی برتر  به EHR کامل بیمار در اورژانس ها است مورد نیاز است.

 C. تابع رسیدگی

تابع رسیدگی تمام درخواستها و فعالیت های کاربران  را که در سیستم پرونده های الکترونیک سلامت رخ می دهد ثبت می کند.(برای مثال درخواستهای EHR و پیامهای جوابهای EHR). این داده انبوه می تواند برای کشف کاربرانی که از سیستم استفاده نا بجا می کنند آنالیز شود و می تواند بعنوان منبعی از مدرک وقتی بررسی تخطی  ایمنی هست استفاده شود. چنین قابلیتی برای ایجاد حسی از اعتماد در کاربران  قانونی سیستم است.

 D. تابع تراکم پرونده

سیستمهای پرونده الکترونیک سلامت کنونی، فاقد یک شمای یکپارچه EMR ومعناشناسی رایج است.  بنابراین تابع تراکم پرونده سیستم EMR مسئول نرمال کردن EMR های دریافت شده و جمع آوری آنها با روشی که داده یکپارچه را حفظ می کند و یک EHR فراگیر و سازگار تولید می کند. به هر حال ریسک های جمع آوری داده کانال های بی معنی از جریان اطلاعات را با ایجاد ارتباط بین تکه های مختلف اطلاعات ایجاد می کند.

حل مسائل تجمیع داده و جریان اطلاعات نیاز به دانش فراگیر پرونده های الکترونیک سلامت دارد که شامل ترکیبی از پرونده سلامت الکترونیک است. این در حوزه این مقاله است، اما ما توجه می کنیم که موضوع در حال حاضر توسط "الگوهای" استاندارد برای پرونده های پزشکی مشخص می شود.

 V. پروتکل ها

برای درک اینکه چگونه توابع مفروض در بخش IV به خوبی کار می کند، این بخش پروتکل پیام را با استفاده از سیستم پرونده الکترونیک سلامت برای پردازش و پاسخ به درخواست توصیف می کند. پروتکلهای کلیدی پروتکلهای ارتباط شناسه هستند، یک پروتکل درخواست EHR ، یک پروتکل ساخت EHR و یک پروتکل پاسخ EHR هستند.

 A) پروتکل ارتباط شناسه

ما فرض می کنیم که به بیمار شناسه اولیه Idp توسط تابع ارتباط هویت اختصاص داده شده است و هویتهای ID1 و ID2 به ترتیب در فرآهم کننده سلامت 1 و 2 حفظ می شوند. همچنین، ما فرض می کنیم که سیستم پرونده الکترونیک سلامت وهر فراهم کننده سلامت در حقیقت یک کلیدPki  را دارد که در پردازش تعیین شناسه استفاده می شود. همچنین فرض می کنیم که سیستم EHR توافق قابل اعتماد و متحدی با دو فراهم کننده سلامت دارد و لیستی از فراهم کنندگان سلامت شرکت کننده را حفظ می کند. گامهای زیر  جزئیات را توضیح می دهد که چگونه بیمار به پرونده الکترونیک سلامت که پرونده الکترونیک پزشکی توسط دو فراهم کننده سلامت نگهداری می شود، با ارتباط به هویتهای محلی آنها ID2, ID1 ، متصل می شود:

1)           بیمار به سیستم پرونده الکترونیک سلامت با استفاده از شناسه اولیه IDP وارد می شود.

2)           تابع ارتباط شناسه، بیمار را معتبر می شناسد.

3)           از بیمار درخواست می کند تا به پرونده الکترونیک پزشکی خود دریک فراهم کننده سلامت ویژه ارتباط ایجاد کند.

4)           تابع ارتباط شناسه به سیستمی پاسخ می دهد که تمام فراهم کنندگان سلامت شرکت کننده در ایجاد را دارد

5)           بیمار لینک فراهم کننده سلامت خود را انتخاب می کند. مانند فراهم کننده سلامت 1

6)          تابع ارتباط شناسه مرورگر بیمار را برای فراهم کننده سلامت 1 هدایت می کند.

7)           سیستم فراهم کننده سلامت 1، تایید درخواست بیمار را تصدیق می کند.

8)           بیمار با استفاده از شناسه محلی، ID1  وارد می شود.

9)           فراهم کننده سلامت 1 بیمار را تایید می کند.

10)       تابع ارتباط شناسه تعیین کننده مستعار IDs1 منحصر به فردی را ایجاد می کند که به عنوان هویت مرجع به خدمت گرفته می شود که هر دو فراهم کننده سلامت 1 و تابع ارتباط هدف را وقتی با یکدیگر ارتباط برقرار می کنند برای این بیمار استفاده خواهد کرد.

11)       تابع ارتباط شناسه ، تعیین کننده مستعار IDs1 جدید را به فراهم کننده سلامت 1 ارسال می کند که با شناسه محلی بیمار ID1 مرتبط باشد.

12)       تابع ارتباط شناسه، سرویس ارزیابی ورود server  با این پروسه  ارتباط را به روز می کند.

13)       برای ارتباط با شناسه محلی دوم ID2، بیمار نیاز دارد تا مراحل 3 تا 12 را با انتخاب فراهم کننده سلامت 2 تکرار کند.

وقتی بیمار تمام شناسه های محلی خود را به شناسه اولی به این روش متصل کرده است، ما با درخت شناسه ایجاد شده در تابع ارتباط شناسه کارمان را به پایان می رسانیم. ریشه این درخت، شناسه اولیه بیمار IDP و برگ های شناسه های مستعار IDs1 و IDS2 هستند که در هر درخواست های ارتباط بیمار ایجاد می شوند.  هر تعیین کننده مستعار با فراهم کننده سلامت ویژه به اشتراک گذاشته می شود. وقتی فراهم کننده سلامت تعیین کننده مستعار با شناسه محلی بیمار مرتبط است، برای هر درخواست آینده شامل این پرونده الکترونیک سلامت بیمار استفاده خواهد شد.

 B. پروتکل درخواست EHR

ما در این جا فرض می کنیم که پزشکی که با فراهم کننده سلامت 1 کار می کند، یک پرونده الکترونیک سلامت برای هر بیمار با هویت ID1 را درخواست کند. گامهای زیر نشان می دهد که چگونه این درخواست توسط سیستم فراهم کنند سلامت 1 انجام می شود.

1)     پزشک به سیستم پرونده الکترونیک سلامت فراهم کننده سلامت 1 وارد می شود.

2)     سیستم فراهم کننده سلامت ، پزشک را تایید می کند.

3)     پزشک درخواستی را برای پرونده الکترونیک سلامت ID1 بیمار ایجاد می کند.

4)     سیستم EMR فراهم کننده سلامت اول، شناسه محلی بیمار ID1 را با تعیین کننده مستعار مرتبط آن جایگزین می کند.

5)     درخواست به صورت دیجیتال توسط فراهم کننده سلامت کلیه Pki امضا می شود.

6)     درخواست به سیستم پرونده الکترونیک سلامت هدایت می شود.

در این گامها، توجه کنید که درخواست پرونده الکترونیک سلامت با استفاده از تعیین کننده مستعار محلی بیمار انجام می شود که اطلاعاتی را درباره تعیین محل ID1 به سیستم EHR آشکار نمی کند. بنابراین، نیازمندی خصوصی بیمار 2 در بخش II حاصل می شود.

ابتدا این درخواست توسط سیستم پرونده الکترونیک سلامت دریافت می شود، گامهای زیر اجرا می شوند:

1)     سیستم EHR ، امضای دیجیتال درخواست EHR دریافت شده را تایید می کند.

2)     ثبت این درخواست EHR به server ارزیابی ارسال می شود.

3)     درخواست EHR به تابع کنترل دسترسی هدایت می شود که گامهای انجام میگیرد:

a)     درخواست EHR به نقطه اجرای خط مشی (PEP) ارسال می شود.

b)     PEP به تاییدهای SAML می رسد که شامل اطلاعاتی درباره درخواست کننده می دهد: مانند نام، نقش پزشکی ، زمان و مکان)

 c)      PEP به شناسه اولیه IDs1 مستعار دریافت شده به درخواست اصلاح شناسه اول انجام شده برای تابع ارتباط شناسه می رسد. (که IDP است).

d)     PEP تمام اطلاعات به نقطه تصمیم سیاست (PDP) را ارائه می دهد، اگر دسترسی مجاز باشد.

e)     PEP تمام سیاستهای مربوط به درخواست و ارزیابی آنها را می گیرد. (آنهائی که توسط بیمار و اختیارات پزشکی انجام شده است)

f)       PDP ، PEP را از نتیجه تصمیم آگاه می سازد.

g)     PEP تصمیم را توسط ارسال یک درخواست به تابع ارتباط شناسه برای ساخت EHR برای شناسه  اولیه در IDp در ارتباط با سیاستهای کنترل دسترسی انجام می دهد یا نشان می دهد که دسترسی مجاز نیست.

h)     با استفاده از پروتکل درخواست EHR، پزشک قادر به درخواست پرونده الکترونیک سلامت بیمار بدون نیاز برای دانستن مکان تشکیل پرونده الکترونیک پزشکی است. به علاوه، شناسه محلی بیمار به بخش دیگر افشا نشده است، که نیازمندیهای خصوصی شناسه بیمار در بخش II را فراهم می سازد.

 C. پروتکل ساخت EHR

تابع ارتباط شناسه یک درخواست پرونده الکترونیک سلامت را از نقطه اجرای سیاست دریافت می کند، گامهای زیر انجام می شوند:

1)     برای هر سیاست کنترل دسترسی، تابع ارتباط شناسه مکان مجاز پرونده الکترونیک سلامت را با یافتن تعیین کننده مستعار مربوطه مجاز تعیین می کند مانند IDs2.

2)     تابع ارتباط شناسه یک درخواست پرونده الکترونیک سلامت با استفاده از تعیین کننده مستعار بیمار IDs2 را ایجاد می کند و این درخواست به صورت دیجیتال توسط کلید Pki سیستم EHR امضا می شود.

3)     درخواست به فراهم کننده سلامت دوم سیستم EMR ارسال می شود.

4)     فراهم کننده سلامت دوم سیستم EMR تعیین کننده مستعار IDS2 به شناسه محلی مربوط ID2 را منطبق میکند.

5)     سیستم EMR فراهم کننده سلامت دوم این درخواست را به هر سیاست کنترل ارزیابی محل پردازش میکند.

6)     سیستم فراهم کنندگان سلامت دوم EMR را بازیابی می کند و شناسه محلی ID2 بیمار را با تعیین کننده مستعار مربوطه جایگزین می کنند(یعنی با IDs2).

7)     EMR حاصله به صورت دیجیتال با کلید PK1 فراهم کننده سلامت دوم امضا می شوند و سپس به سیستم EHR ارسال می گردد.

8)     تابع جمع آوری یا تراکم EMR, EHR امضا شده را دریافت می کند و یک پرونده الکترونیک سلامت مناسب برای این بیمار می سازد.

 در این گام ها، درخواست EMR ارسال شده به فراهم کننده سلامت هیچ چیزی در مورد درخواست کننده آشکار نمی کند، بنابراین این حقیقت را که بیمار، پرونده الکترونیک سلامت در کلینیک درخواست کننده دارد را پنهان می کند. همچنین، تمام EMR ها که توسط تابع جمع آوری EHR متعلق به همان بیمار دریافت می شوند و بنابراین EHR حاصله یک خلاصه دقیق از EMR بیمار است. ما توجه می کنیم که نگرانیهای خصوصی بیمار در بخش 2 در این جا به خوبی تامین می شوند.


D. پروتکل پاسخ EHR

وقتی پرونده الکترونیک سلامت توسط تابع جمع آوری EHR تولید می شود EHR حاصله به شرکت کننده پزشکی با مراحل زیر ارسال می شود:

1)     سیستم IDPR, EHR بیمار شناسه اولیه را با IDs1 تعیین کننده مستعار در طرف درخواست کننده جایگزین می کند.

2)     پرونده الکترونیک سلامت به صورت دیجیتالی توسط سیستم EHR قبل از ارسال آن به فراهم کننده سلامتی 1 امضا می شود.

3)     این عمل با ارسال یک پیغام به Log Server ارزیابی ثبت می شود.

4)     سیستم فراهم کننده سلامت اول، EHR را دریافت می کند و آن را به تعیین کننده IDS1 برای شناسه محلی ID1 مربوطه تبدیل می کند.

5)     سیستم اول فراهم کننده سلامت، پرونده الکترونیک سلامت را برای پزشک جمع آوری می کند.

      با توجه به کل پروسه درخواست EHR که پزشک ، EHR بیمار را به عنوان نتیجه یک ارتباط دقیق و جمع آوری EMR توزیع شده بیمار دریافت کرده است چون پروسه ارتباط اصلی توسط بیمار انجام شده بود. همچنین ، پزشک نمی داند که این اطلاعات از کجا جمع آوری شده است، بنابراین نمی تواند هیچ استنباطی از تاریخچه  پزشکی بیمار در کنار اطلاعات موجود در پرونده الکترونیک سلامت داشته باشد.

 VI پیاده سازی

در این بخش، ما به طور مختصر توضیح می دهیم که چگونه تابع مدیریت شناسه مفروض برای پرونده الکترونیک سلامت می تواند با استفاده از تکنولوژی های حاضر پیاده سازی شود.

 A) تابع ارتباط شناسه

این تابع شامل سه پروسه است: اعتبار سنجی، شناسه منحصر به فرد و حفظ درخت شناسه. در بخش IV توضیح داده شد که تابع ارتباط شناسه نقش فراهم کننده اطلاعات را بازی می کند همانگونه که در مدیریت شناسه منحصر به فرد با مسئولیتهای اضافی تعریف شد.

پیاده سازی یک Server  ارتباط شناسه (نرم افزار زیر ساختار) و حضور سرورهای هویت سلامت می تواند با استفاده از قالب منحصر به فرد شناسه برقرار شده از پروژه پیوستگی اختیار انجام شود که ارتباط هویت را از طریق استفاده از پروتکل ثبت نام امکان پذیر می سازد که پروتکل کامل آن پردازشهای مورد نیاز در شبکه منحصر به فرد را فراهم می کند. درخت شناسه بیمار، که ارتباط بین هویت بیمار و تعیین کننده مستعار مربوطه آن را فراهم می کند، به آسانی در پایگاه داده منطقی با ایجاد  جدولی برای ذخیره تمام شناسه ها پیاده سازی می شود. شناسه اولیه، کلید اولیه برای این جدول خواهد بود و تعیین کننده های مستعار مختلف را به هم متصل می کند بنابراین، اختصاص شناسه اولیه برای تعیین کننده کلیدی و بقای تعیین کننده کلیدی مرتبط با شناسه اولیه ویژه آنان است.

 B. تابع کنترل دسترسی

برای بیان و ارزیابی سیاستهای کنترل دسترسی می توان از زبان کنترل دسترسی XACML ، یک استاندارد OASIS خوب، استفاده کرد. پیغام بین سیستم EHR و حضور فراهم کننده سلامت به زبان XACML مبادله می شوند. استاندارد SAML قالبی را برای مبادله اطلاعات ایمنی بین شرکای تجاری آنلاین تعریف می کند. علاوه بر آن، ویژگیهای XACML, SAML شامل ویژگیهایی است که برای ساده سازی استفاده ترکیبی آنها طراحی شده است و آنها را برای کاربرد EHR ایده آل می سازد.

 VII. مورد مطالعه

ما در این بخش، از مورد مطالعه برای توضیح این که چگونه معماریها مسائل ارتباط چندین EMR را حل می کند، بررسی می کنیم که شناسه رایج را به اشتراک نمی گذارد. همچنین، ما روی برخی از تمایلات خصوصی بیمار که باید وقتی پرونده الکترونیک سلامت مربوط می ساخت، مورد توجه قرار می گرفت تاکید کردیم.

 سناریو توضیحی به صورت زیر است:

Frank بیمار، 4 پرونده الکترونیک سلامت دارد که توسط دو کلینیک مسئولان عمومی، یک بیمارستان و یک کلینیک اعتیاد دارویی، همانگونه که در شکل 1 نمایش داده شده است. Frank سه موضوع سلامت حساس دارد، سلامتی عقل، مسائل جنسی و اعتیاد دارویی. فرانک ترجیح می دهد  برای موضوع بیماری جنسی اش پیش Tony که پزشک عمومی است برود، جایی که شناسه او FrankT است. همچنین او ترجیح می دهد که karen پزشک مخصوص مسائل سلامت عقلی اش اورا ویزیت کند، درجایی که شناسه او آنجا FrankKاست. در کلینیک اعتیاد دارویی، شناسه Frank ، FrankA است. تمامی این شناسه ها برای فرانک است و او نمی خواهد کسی درباره این چیزی بداند، مگر این که او اجازه دهد. همچنین، فرانک پرونده پزشکی عمومی دارد که در بیمارستان نگهداری می شود، این پرونده پزشکی وقتی ایجاد شده که او بعد از تصادف به بیمارستان رفته و در اورژانس ER (Emergency Room) ویزیت شده بود. در آنجا  شناسه فرانک frankH است.

 Frank هرگز فکر نمی کند که کسی پرونده او را ببینید. فرانک می خواهد دسترسی به پرونده های پزشکی او با استفاده از تنظیم قوانین دسترسی زیر محدود کند:

1)tony مجاز است تا پرونده سلامت فرانک را از بیمارستان با استفاده از شناسه های محلی frankT بازیابی کند. به هر حال، tony نباید همه چیز را درباره منبع پرونده پزشکی مجتمع بداند.

2) Karen مجاز است تا اطلاعات موجود در پرونده های سلامت فرانک در کلینیک اعتیاد دارویی و در بیمارستان را  جمع اوری و بازیابی کند. Frank باید این پروسه را با استفاده از شناسه محلی فرانک frankT انجام دهد. به هر حال او نباید چیزی درباره منابع جمع آوری پرونده های پزشکی بداند.

علاوه بر این نقشها، اختیارات پزشکی می خواهد به مسئول پزشکی اجازه دهد تا به هر موضوع ضروری در پرونده  سلامتی بیمار دسترسی نامحدود داشته باشد.

در بخشهای زیر، ما نشان می دهیم که چگونه فرانک می تواند به پرونده های الکترونیک پزشکی جداگانه خود لینک شود، چگونه فرانک می تواند تمایلات خصوصی اش را تنظیم کند، چگونه Frank پزشک می تواند پرونده سلامت الکترونیک فرانک را درخواست و دریافت کند و چگونه مسئول پزشکی ER می تواند به EHR فرانک در هر اورژانس دسترسی داشته باشد.

 A. فرایند ارتباط EMR

این پروسه با ثبت فرانک در سیستم پرونده الکترونیک سلامت آغاز می شود. ما فرض می کنیم که سیستم EHR توسط مسئول پزشکی دولتی مدیریت می شود. در نتیجه پروسه ثبت، فرانک با شناسه اولیه frankP اختصاص داده خواهد شد. کلینیک Tony کلینیک karen ، کلینیک اعتیاد دارویی  و بیمارستان شرکت کنندگان معتمد با سیستم EHR هستند.

اکنون فرض کنید که فرانک می خواهد تا به پرونده الکترونیک سلامت مختلف خود لینک شود، بطوریکه یک پرونده الکترونیک سلامت مناسب ایجاد شود ، وقتی توسط مسئول پزشکی مجاز به روشی درخواست شود، که به تمایلات خصوصی آن احترام گذاشته شود. پروسه لینک از طریق گامهای زیر ادامه خواهد یافت:

1) فرانک به سیستم پرونده الکترونیک سلامت با استفاده از شناسه اولیه اش FrankP دسترسی دارد.

2) سیستم EHR فرانک را تایید می کند.

3) فرانک درخواست می کند تا به پرونده الکترونیک سلامت لینک شود.

4) سیستم EHR با حضور در لیست فراهم کننده سلامت پاسخ می دهد.

5) فرانک برای لینک به EMR خودش در کلینیک Tony انتخاب می شود.

6) سیستم EHR ، مرورگر فرانک را برای سیستم کلینیک EMR هدایت می کند.

7) فرانک شناسه خود را که در کلینیک Tony نگهداری می شد، وارد می کند که FranyT است.

8)سیستم EHR یک تعیین کننده مستعار با نام franks1 ایجاد می کند و به درخت شناسه فرانک اضافه می کند این شناسه را به سیستم کلینیک Tony برای پیوند با شناسه مربوط به فرانک یعنی FrankT می فرستد.

9)پیغام تکمیل بین سیستم EHR و سیستم کلینیک Tony, EMR مبادله می شود.

10)تابع ارتباط شناسه، بررسی جزئیات این پروسه ارتباط را به Log Server ارسال می کند.

11) فرانک مطلع می شود که فرایند ارتباط کامل شده است.

برای ایجاد ارتباط با سایر EMR ها در کلینیک karen، کلینک اعتیاد دارویی و بیمارستان به پروسه بالا نیاز هست تا با سایر فراهم کنندگان سلامت تکرار کنند. در نتیجه ارتباط تمام EMR ها، شناسه اولیه فرانک یعنی FrankP مرتبط با تعیین کننده های مستعار                 Frank s4, Frank s3, Frank s2, Frank S1,   درون سیستم EHR هستند.

همچنین ارتباطات شناسه زیر را در فراهم کنندگان ارتباط خواهیم داشت.

· در کلینیک FrankS1: Tony با FrankT مرتبط است.

· در کلینیک FrankS2: karen با FrankK مرتبط است.

· در کلینیک اعتیاد دارویی: FrankS3 با frankA مرتبط است.

· در بیمارستان: FrankS4 با frankH مرتبط است.

 B: تنظیم سیاستهای کنترل دسترسی

فرانک از تابع کنترل دسترسی برای تنظیم سیاست های کنترل دسترسی اش برای تامین تمایلات خصوصی اش استفاده می کند. سیاست کنترل دسترسی در سیستم EHR از طریق جمله زیر بیان می شود:

در یک متن دسترسی مشخص، فرد اختیار دارد تا یک پرونده الکترونیک سلامت از شناسه های ID1،ID2،…   IDn بسازد، اما از ارزیابی زمینه های field1 ، field2  و ...fieldn منع می شود.

برای بیان قوانین کنترل دسترسی فرانک، وسیاست دسترسی اورژانسی به ماخذ پزشکی سیاستهای دسترسی زیر ایجاد می شود :

1) تحت سناریوی دسترسی طبیعی تونی مجاز است تا EHR را از طریق شناسه Franks4  بسازد.

2) تحت سناریوی دسترسی طبیعی ،  karen مجاز است تا EHR را با شناسه های franks3  و franks4 بسازد.

3)تحت سنتاریوی دسترسی اورژانسی هر مسئول پزشکی اختیار دارد تا EHR را از طریق شناسه های Franks1 ،franks2  ، franks3 ، franks4 بسازد.

این سیاست ها به زبان سیاست زبان XACML  ترجمه خواهد شد و سپس در پایگاه داده سیاست ها ذخیره خواهند شد.

  .C درخواست EHR

اکنون فزض کنید که  Karen ، GP یا پزشک عمومی به اطلاعات اضافی پزشکی درباره فرانک برای کمک به او جهت تشخیص دقیق بیماری ذهنی اش نیاز دارد. به هر حال Karen نمی داند که فرانک EMR دیگر دارد یا خیر. بنابراین او کل پرونده الکترونیک سلامت فرانک را از طریق ارسال یک درخواست از طریق سیستم پزشکی اش با استفاده از شناسه محلی FrankKدرخواست می کند. گام های زیر توضیح می دهد که چگونه این درخواست برای سیستم پرونده الکترونیک سلامت پردازش می شود.

1)Karen  به سیستم EMRکلنیک خود دسترسی دارد تایید می گردد.

2)Karen درخواست دسترسی EHR را برای FrankK  می فرستد.

3)سیستم EMR  Karen, شناسه محلی frank یعنی FrankK در درخواست EHR توسط تعیین کننده مستعار franks2 را جایگزین می کند.

4)سیستم Karen,  EMR  به صورت دیجیتال در خواست EHR را با استفاده از کلید PKI امضا می کند و سپس آن را به سیستم EHR ارسال می کند.

5)سیستم EHR درخواست EHR را برای تابع کنترل دسترسی برای ارزیابی آن دنبال می کند.

6)log این درخواست EHR به log Server ارزیابی ارسال می شود.

7)تابع کنترل دسترسی ویژگی های بیشتری (نام، نقش پزشکی، پارامترهای کنترل) را درباره Karen از سیستم EMR ، Karen درخواست می کند.

8)تابع کنترل دسترسی از تابع ارتباط شناسه درخواست می کند تا مستعار FrankS2 را برای شناسه اولیه مربوطه آن تعیین کند.

9)تابع ارتباط شناسه با شناسه اولیه FrankP پاسخ می دهد.

10)تابع دسترسی کنترل، سیاست های کنترل دسترسی مرتبط با شناسه اولیه FrankP را بازیابی می کند.

11)تابع کنترل دسترسی، درخواست دسترسی را برای هر سیاست کنترل دسترس ارزیابی می کند.

12)به ازای هر سیاست کنترل دسترسی فرانک 2 در بخش VII-B، تابع کنترل دسترسی یک درخواست برای تابع شناسه برای ساخت یک EHR از شناسه های franks3 و franls4 ارسال می کند  وقتی به Karen اجازه داده می شود تا EHR را از هویت ها بسازد.

13) تابع ارتباط شناسه یک درخواست EMR امضاء شده دیجیتال را برای سیستم EMR کلینیک اعتیاد با استفاده از تعیین کننده مستعار اولیه franks3  ، و برای سیستم EMR بیمارستان با استفاده از تعیین کننده مستعار franks4 ارسال می کند.

14) هر کدام از سیستم های EMR کلینیک اعتیاد دارویی و سیستم EMR بیمارستان مراحل زیر را انجام خواهند داد:

a) اصلاح تعیین کننده مستعار دریافت شده به هویت محلی مرتبط

b)ارزیابی درخواست EMR برای هر سیاست کنترل دسترسی محلی.

C) بازیابی EMR و جایگزین کردن شناسه محلی فرانک با تعیین کننده مستعار مربوط به او.

d) EMR حاصله به صورت دیجیتال توسط کلید PKI سیستم EMR امضا شده و سپس به سیستم EHR ارسال می شود.

15) EMR های دریافت شده به تابع جمع آوری فرستاده می شوند که پرونده الکترونیک سلامت فرانک را بسازد.

16)تعیین کننده مستعار فرانک در سیستم EMR ، Karen،یعنی franks2 به عنوان شناسه  این EHR تنظیم می شود.

17) EHR حاصله به صورت دیجیتال توسط کلید PKI سیستم EHR اضافه می شود و به سیستم EMR ، Karen فرستاده می شود.

18)این عمل با Log server ارزیابی log می شود.

19) سیستم EMR، Karen ، تعیین کننده مستعار فرانک یعنی frankS2 را با شناسه محلی فرانک FrankK جایگزین می کند.

20)پرونده الکترونیک سلامت  جمع آوری شده برای Karen در دسترس قرار می گیرد.

 در این پرو سه فراید زیر را درک می کنیم:

- karen، EHR فرانک را بدون این که بداند EMRها در کجا قرار دارد، درخواست می کند. که نگرانی خصوصی او را در بخش VII تامین می کند.

- شناسه محلی فرانک frankK برای سایر فراهم کنندگان سلامت ارائه نشده است که نیازمندی 2 را در بخش ll تامین می کند.

- سیاست کنترل دسترسی فرانک 2 در بخش vIl-B تامین شده است.

- EHR حاصله یک ارتباط دقیق از EMR فرانک است، وقتی او کسی است که بین آنها ارتباط ایجاد می کند و این نیازمندی خصوصی 1 و 2 را در بخش 2 تامین می کند.

 D: پروتکل دسترسی اورژانسی

حال فرض کنید که فرانک حمله قلبی دارد و به دپارتمان اورژانس بیمارستانی که قبلاً به آنجا رفته بود، برده شده است. John پزشک اورژانس نیاز دارد تا به پرونده الکترونیک سلامت frankA به منظور بررسی حساسیت فرانک به دارو دسترسی داشته باشد. برای انجام این درخواست EHR از طراحی 1 تا 20 در بخش vll-C  طی خواهد شد. تنها قضاوت در این موقعیت، سیاست دسترسی اورژانسی استفاده شده در گام 11 است که به صورت اورژانسی تعیین خواهد شد و شناسه هایی که در گام 12 ارسال شده اند. Franks1 ، franks2و franks3هستند که با شناسه محلی Franks4  هستند که به EHR اجازه می دهند تا از 4 مستعار فرانک ساخته شوند.

 VII. بحث

در این مقاله ما پروتکل های سیستم EHR را ارائه کردیم که می تواند از پرونده های پزشکی مختلف یک EHR درباره بیمار خاص بسازد ضمن رعایت احترام به حریم خصوصی بیمار.

مشکل لینک EMR با لینک شناسه محلی بیمار از طریق یک پسوند مفاهیم مدیریت شناسه موجود حل شده است.  لازمه اين فرآيند ارتباط صريح بيماران به تمامي شناسه هاي محلي آنها در نتيجه  ارتباط دقيق وامن است.

علاوه بر این نتیجه ، ارائه دهندگان مراقبت های بهداشتی می توانند برای برآورده شدن رضايت بيماران در حفظ حریم خصوصی آنها ،  با فاش نشدن شناسه هاي محلی آنها در سيستم پرونده الكترونيك  سلامت در طی فرایند ایجاد ارتباط يا زمان درخواست سرویس EHR اقدام كنند. در عوض، از یک نام مستعار شناسه  در داخل درخواست EHR استفاده می شود. از طریق سیستم EHR ، بیماران می توانند سیاست های كنترل دسترسی ترجيهي بر داده های سلامت خود تنظيم كنند، و اختيار پزشکی می تواند اطمینان حاصل كند که از پرونده پزشکی فقط به طريق قانوني استفاده می شود. در بهداشت و درمان (آنلاین)، دسترسی به پرونده الكترونيك سلامت يك نياز مهمي  به ویژه در زمان هاي اورژانسي  است. بنابراین ، بیشتر سیستم های بهداشت و درمان با استفاده از افزونگی و مکانیسم های تحمل خطا برای جلوگیری از هر گونه وقفه به خدمات پزشکی اجرا مي شوند. در مورد ما، این بدان معنی است که شناسه لينك داده در سیستم EHR نیاز به ساخت مشابه و قوی دارد. عملي كه بايد حل شود اين است كه پروسه ارتباط پرونده الكترونيك پزشكي بايد با فرض اينكه بيماران ميدانند EMR شان كجا قرار دارد انجام شود. با این حال ، با توجه به اینکه دهانه اطلاعات پزشکی زندگی کامل انسان، این احتمال وجود دارد که اکثر بیماران حتی نخواهند توانست تمام مراحل اقدامات پزشکی خود را از بدو تولد به خاطر داشته باشند. به این ترتیب ، نقش اختيارات پزشکی دولت در اقدام به عنوان سرویس 'کارگزاری' اعتماد و امن حیاتی خواهد بود.

IX نتیجه گیری و کار آینده

در سیستم های مراقبت های بهداشتی در آینده، سابقه پزشکی هر بیمار، كه توسط يك  نظام الکترونیک سلامت فراهم خواهد شد، بعنوان یک ابزار حیاتی برای تشخیص پزشکی و تحقیقاتي خواهد شد. بهر حال ساخت پرونده الکترونیک سلامت و جدا از سوابق الکترونیک پزشکی ثابت خواهد کرد که کار شدیدا دشوار می باشد. به طور خاص ، برای بیماراني كه  به چنين سيستمي اعتماد دارند، آنها باید مطمئن شوند مکانیسم های مناسبي در محل هستند كه در عین حفظ یکپارچگی داده هاي سلامت به حفظ حریم شخصی آنها كمك می کنند. در اینجا براي ما نشان داده شده که پرونده هاي جاری و روشهاي شناسه ارتباط ، برای برآورده شدن دقت و حفظ حریم خصوصی در سیستم های الکترونیک سلامت كافي بوده است. به عنوان یک راه حل، ما پیشنهاد مي كنيم يك معماري مديريت شناسه EHR جایی که پرونده بیمار به طور غیر مستقیم از طریق شناسه های مستعار لينك مي شود ، باشد.

نه تنها این کار تولید یک نتیجه دقیق، به عنوان تکنیک های مدیریت هویت فدرال موجود است ، بلكه همچنین می تواند موجب حفظ تمايلات خصوصي ومحرمانگی بیماران باشد. در کارهای آینده ما قصد به ادغام اين رویکرد با مکانیسم های کنترل دسترسی داريم ، و براي تعریف يك رویکرد مدیریت شناسه برای ایجاد ارتباط بین درختان تمام اعضای خانواده كه اجازه می دهد تا تشخیص و پژوهش دروني، بیماریهاي ژنتیکی انجام گيرد.

 گردآوری و ترجمه : مهندس علی نیک مرام

 کپی با ذکر نام  یا آدرس وبلاگ بلا مانع است

نوشته شده توسط علی نیک مرام در ساعت 10:30 | لینک  |