1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T H.813 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2017) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS E-health multimedia services and applications Personal health systems Interoperability design guidelines for perso
2、nal connected health systems: Healthcare Information System interface Recommendation ITU-T H.813 ITU-T H-SERIES RECOMMENDATIONS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexin
3、g and synchronization H.220H.229 Systems aspects H.230H.239 Communication procedures H.240H.259 Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia servi
4、ces H.350H.359 Quality of service architecture for audiovisual and multimedia services H.360H.369 Telepresence H.420H.429 Supplementary services for multimedia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mo
5、bility for H-Series multimedia systems and services H.510H.519 Mobile multimedia collaboration applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 VEHICULAR GATEWAYS AND
6、INTELLIGENT TRANSPORTATION SYSTEMS (ITS) Architecture for vehicular gateways H.550H.559 Vehicular gateway interfaces H.560H.569 BROADBAND, TRIPLE-PLAY AND ADVANCED MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 Advanced multimedia services and applications H.620H.629 Ubiquito
7、us sensor network applications and Internet of Things H.640H.649 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719 IPTV terminal devices H.720H.729 IPTV middleware H.730H.739 IPTV application event handling H.740H.749 IPTV metadata H.750H.759 IPTV multimedia application f
8、rameworks H.760H.769 IPTV service discovery up to consumption H.770H.779 Digital Signage H.780H.789 E-HEALTH MULTIMEDIA SERVICES AND APPLICATIONS Personal health systems H.810H.819 Interoperability compliance testing of personal health systems (HRN, PAN, LAN, TAN and WAN) H.820H.859 Multimedia e-hea
9、lth data exchange services H.860H.869 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T H.813 (11/2017) i Recommendation ITU-T H.813 Interoperability design guidelines for personal connected health systems: Healthcare Information System interface Summary The Continua
10、 Design Guidelines (CDG) defines a framework of underlying standards and criteria that ensure the interoperability of devices and data used for personal connected health services. The Continua Design Guidelines also contains design guidelines (DGs) that further clarify underlying standards or specif
11、ications by reducing options or by adding missing features to improve interoperability. ITU-T H.813 focuses on the following interface: HIS-IF Interface between Health users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Reco
12、mmendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. 2 Rec. ITU-T H.813 (11/2017) ITU-T H.810 Reco
13、mmendation ITU-T H.810 (2017), Interoperability design guidelines for personal connected health systems: Introduction. All other referenced documents can be found in clause 2 of ITU-T H.810. 3 Definitions This design guidelines document uses terms defined in ITU-T H.810. 4 Abbreviations and acronyms
14、 This design guidelines document uses abbreviations and acronyms defined in ITU-T H.810. 5 Conventions This design guidelines document follows the conventions defined in ITU-T H.810. 6 HIS interface design guidelines 6.1 Architecture 6.1.1 Overview of the HIS-IF The purpose of the HIS interface is t
15、o transfer patient information from a Continua health and fitness service (containing the HIS Sender) to either another health and fitness service or another health information service (containing the HIS Receiver). The health and fitness service can be the remote patient monitoring (RPM) server of
16、a disease management service provider or the application server of an ageing independently or health and fitness service provider. The patient information for transfer may include a report summarizing the patients current status, a detailed listing of specific patient results, readings from one or m
17、ore personal health devices (PHD), or a combination of these. The health information service may contain a hospitals enterprise health record (EHR), a physicians electronic medical record (EMR) or a personal health record (PHR) service used by the patient. Figure 6-1 represents the HIS interface rel
18、ative to the Continua end-to-end (E2E) architecture. Figure 6-1 HIS interface in the Continua E2E architecture At a higher level, there are different functional blocks that make up the HIS interface. Figure 6-2 illustrates this view of the architecture. Rec. ITU-T H.813 (11/2017) 3 Figure 6-2 HIS fu
19、nctional blocks The applications block contains enterprise healthcare applications such as a remote patient monitoring (RPM) system hosted by a disease management service provider or an EMR system at a physicians office. The data block contends with the format of the actual data transmitted between
20、the applications. It may be in coded format, free-text, or a combination of both. The messaging block handles how data is packaged to ensure consistency and readability across multiple transport methods. The messaging infrastructure deals with the infrastructure needed to transport this information
21、model, such as MLLP, FTP, web services and others. The message transport layer forms all the layers below the transport layer of the OSI stack. The security block ensures that the messages exchanged between applications are secure. 6.1.1.1 Purpose of HIS interface guidelines The HIS interface guidel
22、ines describe how Continua-certified health information services can exchange patient information with other Continua-certified health information services or with non-Continua electronic health record (EHR) systems. Figure 6-3 is a high level view of the scope of these guidelines. Figure 6-3 User s
23、cenario for the HIS interface 4 Rec. ITU-T H.813 (11/2017) The purpose of these guidelines is to establish the basic standards, rules and restrictions in the data, message and transport protocols necessary to enable the transfer of pertinent information from a Health but may be covered by the purcha
24、sing of the application or library used to create or read the ZIP file. 6.1.4 Data and selected standards The data transmitted from the HIS sender can be either summary, raw data or both. The summarization may be a result of analysis by an authentic disease management service provider. The data has
25、multiple characteristics that include: 1. Representation of measurements captured by PHDs. 2. Representation of notes, summary and other kinds of narrative information that are added by care givers or by the user themselves. 3. Representation of graphs that are added by intermediary services that re
26、present the trends of a users health. 4. Patient information that allows endpoints to catalogue the aforementioned data against existing patient records. To accommodate the wide variety of data characteristics, the HL7 clinical document architecture (CDA) HL7 CDA-PHMR based format is chosen. The CDG
27、 specifies constraints on the CDA in accordance with requirements set forward by the HIS interface. These constraints are henceforth called the personal healthcare monitoring report (PHMR). Wherever possible, the PHMR reuses the templates already set forth by a HL7 specification called continuity of
28、 care document (CCD) HL7 CDA-CCD. The reasons for reusing the CCD templates are: 1. The CCD templates already contain a number of constraints that are needed by the HIS interface. 2. The CCD is a harmonized specification of CDA (based on HL7 V3 RIM) and the ASTM E2369-05 standard specification for c
29、ontinuity of care record (CCR), see HL7 CDA-CCD. 3. Since the CCD has gained relevance in the marketplace, it is best if the PHMR is derived from the CCD so that it is a lesser burden to the EHR implementations that are designed to work with the CCD. 10 Rec. ITU-T H.813 (11/2017) The HL7 Personal He
30、alth Monitoring Report Implementation Guide HL7 CDA-PHMR has an independent lifecycle under a project called the “Personal Health Monitoring Report“ under the HL7 Structured Documents Workgroup (SDWG). 6.1.5 Security The five archetypal high-level areas of security requirements are a subset of 11.2.
31、3 of b-ISO 27000 and are as follows: Authorization Only fully identified and authenticated entities, equipped with access control credentials, should be able to avail themselves of services provided by systems. Accountability Users should be fully accountable for (and unable to repudiate) their acti
32、ons. It should be possible to determine, through a systems accountability features, who performed any given action and which actions have taken place in a specified interval. Availability A system should be available for use when required for critical operations. Critical data should be available wh
33、en required. The data and keys associated with encryption for the purposes of confidentiality should be recoverable. Administration Responsible security policy authorities should have secure, usable interfaces for defining, maintaining, monitoring and modifying security policy information. Assurance
34、 It should be possible to demonstrate to a sceptical observer that a system actually provides the claimed level of protection with periodic validation and that the protection is still effective. 6.1.6 Transport security The HL7 clinical document architecture (CDA) HL7 CDA-PHMR, which is the basis fo
35、r PHMR implementation, relies on the transport mechanism to implement security and authentication. The CDA does provide confidentiality status information to aid the application systems in managing access to sensitive data. The IHE XDS profile family assumes that a suitable security and privacy envi
36、ronment was established and that the relevant threats are managed by agreements and implemented by generic security mechanisms not unique to XDS. For direct communications, the transport security of the HIS interface is accomplished by the adoption of the security solution from the IHE XDR profile a
37、nd its prerequisite industry standards. For indirect communications via the IHE XDM profile, the transport security depends on the final delivery method employed. If the exported file is delivered to the HIS receiver via e-mail (the recommended method), then S-MIME is used to ensure security. Howeve
38、r, the cases in which the ZIP-packaged PHMR is further stored on removable media (i.e., USB, drive, CD-ROM, etc.) or transferred via FTP are not covered in this guideline and require their own security considerations. In addition, the XDS profiles assume that implementers of the document source and
39、document recipient have in place an agreement that defines when they interchange the PHMR data and how to manage the inconsistencies between security policies in both organizations. The XDS profiles further require the reconciliation of patient identification upon import of the document. The CDG spe
40、cifications for the HIS sender further narrow these framework provisions to allow reasonable design guidelines. However, it should be noted that the final security implementation must be designed by the communicating parties. 6.1.7 Document-level integrity, data origin authentication and non-repudia
41、tion Integrity, data origin authentication and non-repudiation are important security properties for personal healthcare monitoring report (PHMR) documents exchanged over the HIS-IF. Through the Rec. ITU-T H.813 (11/2017) 11 use of transport security (TLS, IHE ATNA) basic integrity and node authenti
42、cation is realized. However, non-repudiation requires additional measures such as a signature over the documents. This also strengthens the integrity property as a signature can protect the integrity of the document independent of how it is exchanged and thereby provides end-to-end integrity if it i
43、s exchanged multiple times. For the HIS-IF integrity, data origin authentication and non-repudiation are realized through the use of IHE document digital signature content profile. IHE DSG allows signing of documents in a submission set exchanged using the protocols in IHE ITI TF-1 XDM and IHE ITI T
44、FS XDR. Non-repudiation enabled HIS sender is a HIS sender that deploys security operations to assure that data integrity, data origin authentication and data origin non-repudiation properties are preserved when transmitting an observation document. Non-repudiation enabled HIS receiver is a HIS rece
45、iver that deploys security operations to assure that data integrity, data origin authentication and data origin non-repudiation properties are preserved when receiving an observation document. In other words, these security operations are mandatory only for non-repudiation enabled HIS senders and re
46、ceivers. This makes the decision to apply such measures a business decision based on risk assessments. It is a choice of a HIS receiver to deploy these security constructs should the need arise to enable interoperability with non-repudiation enabled HIS senders. 6.1.8 Consent management Consent in h
47、ealthcare includes concepts like opt-in, opt-out and secondary use and enables patients to regulate which care providers have access to which health information. Capturing consent in digital form increases consistency, compliance and efficiency for both patients and care providers. Consent managemen
48、t at the HIS-IF supports scenarios where a patient holds a consent policy at a Health & Fitness service which should also be applied at a HIS service. An example is a scenario where a patient defines his consent at a disease management organization and a condition occurs that requires involvement of
49、 another doctor. In such a case a nurse may, if permitted by the consent policy, forward his record together with the consent document allowing the receiver to use the information in accordance with the patients consent policy. In a variant, a HIS service may seek additional consent from the patient. Instead of Health & Fitness service to HIS exchanges, consent documents may also be exchanged from HIS to HIS services. For the HIS-IF the scope is limited to the exchange of the consent documents be
