White Pa Assignio Sp ecification - PDF A

HIS2Assi

HIS2As

White Pa

Methomation

V 1-01, 2

ignio

ssignio

aper on HIS2

od for usinn Systems

27.4.2011

2Assignio Sp

ng Valid Cs and Docu

pecification

linical Datument Ma

ta and Doanagemen

ocuments nt and Arc

from Hoschival Sys

spital Infostems

Page 1

r-

HIS2Assignio Page 2

1 Contents 1 Contents .......................................................................................................................................... 2

2 Title .................................................................................................................................................. 4

3 Denotation ....................................................................................................................................... 4

4 Point of Contact/Feedback and Queries ......................................................................................... 4

5 Authors ............................................................................................................................................ 5

6 Conventions ..................................................................................................................................... 6

7 Legal Provisions / Disclaimer ........................................................................................................... 6

8 Target Audience .............................................................................................................................. 7

9 Preliminary Remarks ....................................................................................................................... 9

10 Introduction ............................................................................................................................... 12

11 Assignio – the People-Powered Platform in Germany .............................................................. 16

12 Specific National Characteristics, International Standards ....................................................... 19

13 HealthVaultTM Document Life Cycle: Export from a Primary System and Import into Assignio 22

14 Precepts of Assignio/ HealthVault™ for Handling Patient Data ................................................ 26

15 Assignio and the ICT Infrastructure in the German Healthcare System.................................... 27

16 Use Cases and Registering with Assignio .................................................................................. 28

16.1 Common Scenarios ................................................................................................................ 28

16.2 Common Use Cases: Examples .............................................................................................. 28

16.3 Initial Registration of an Individual on Assignio .................................................................... 29

16.4 Legal Aspects of Registration on the Assignio Portal ............................................................ 33

16.5 Variants of Data Exchange between HIS and Assignio .......................................................... 33

16.6 Document Processing in Assignio .......................................................................................... 34

17 Primary System: HIS .................................................................................................................. 36

17.1 Drill Down: Processing HL7 CDA Release 2 Structured Data ................................................. 37

17.1.1 Discharge summaries, Other Documents and Objects, Document Formats ................ 37

17.1.2 HL7 CDA Release 2 ......................................................................................................... 38

17.1.3 Separate CDA Code Example for Assignio ..................................................................... 46

17.2 Linking Document Management and Archival Systems ........................................................ 50

17.3 Drill Down HIS and DMAS: PDF/A as Shareable, Long-term Archival Format in HIS and DMAS 52

17.3.1 Basics of PDF/A-1 and PDF/A-2 ................................................................................... 52

17.3.2 Outlook to PDF/A-2 ....................................................................................................... 54

17.3.3 Data in PDF/A ................................................................................................................ 55

17.3.4 Signatures in PDF/A ....................................................................................................... 55

HIS2Assignio Page 3

17.3.5 PDF/A and CDA Transformation ................................................................................. 57

18 Custom Programming/Opportunities for an Application Market ............................................. 59

19 Security of Data and Documents, Validity and External Services ............................................. 61

19.1 Verifying Signatures and Freedom from Malware ................................................................ 61

19.2 IT Security as per ISO 27001 / 27799 etc. .............................................................................. 65

19.3 Risk Management .................................................................................................................. 65

20 Other Technologies and Standards – Relationship with Assignio ............................................. 66

20.1 Example: Microsoft®: HIS- SharePoint Server - Assignio ....................................................... 66

20.2 IHE Integration ....................................................................................................................... 66

20.3 Integration of www.fallakte.de ............................................................................................. 67

20.4 Semantic Interoperability and Terminology Server .............................................................. 68

20.5 Differentiation from Formats such as XLS, CSV etc. .............................................................. 68

20.6 DICOM ................................................................................................................................... 69

20.7 Communication Server / Integration Server ......................................................................... 69

21 Concluding Remarks .................................................................................................................. 70

22 List of Attachments ................................................................................................................... 71

HIS2Assignio Page 4

2 Title

This specification is titled

HIS2Assignio Version 1.0

It is published as a White Paper and describes

Applications / Connectors for Interoperability of Hospital Information Systems (HIS) or Document Management and Archival Systems (DMAS) with Assignio.

3 Denotation

The Specification/White Paper in the current version is denoted

HIS2AssignioV1-0.pdf

4 Point of Contact/Feedback and Queries

Feedback and queries should be directed to:

Microsoft® Deutschland GmbH

[email protected]

HIS2Assignio Page 5

5 Authors

The document was created by

eHealthOpen Ltd.

Authors:

Dipl.-Inform. Med. Heino Kuhlemann (eHealthOpen Ltd.)

Dr. med. Markus Mohr (ManaThea GmbH)

Co-contributors:

Helge Schroda (Microsoft® Deutschland GmbH)

Jens Seeliger (Microsoft® Deutschland GmbH)

Herbert Jank (Siemens IT Solutions and Services GmbH)

Ingo Bienek (Siemens IT Solutions and Services GmbH)

Dr.-Ing. Thomas Meischner (Siemens IT Solutions and Services GmbH)

Input and review: preview copies of this document were provided to selected validation partners prior to publication. Feedback and comments have been evaluated and, where appropriate, included in the document. This is a dynamic publication – meaning that feedback continues to be welcomed.

Thanks go to Dr. Bernd Wild (Executive Board PDF/A-Competence Center - www.pdfa.org) for his detailed feedback and comment on the contents.

HIS2Assignio Page 6

6 Conventions This specification essentially puts forward a set of recommendations, and this applies also to ele-ments marked as mandatory.

Further information on the capabilities of Assignio, and the requirements of the platform, can be provided on request.

In the recommendations in this specification, readers will find a distinction between must – should – can. This distinction aids decisions on whether to develop applications which meet minimum re-quirements, and when to expand levels with added functionality. This structure reflects common market practice for specifications and guidelines published by recommending institutions and other authorities:

• Mandatory (MUST): requirements which must be met to fulfill data privacy and documentation obligations, etc. They are denoted in the text by the word must.

• Recommended (SHOULD): requirements which should be enacted. These are denoted in the text by should / recommended.

• Optional (CAN): These requirements can be implemented. They are denoted in the text by the word can.

7 Legal Provisions / Disclaimer

The use of information technology is subject to a range of legal provisions. This applies not just to Assignio but also to all the systems deployed.

Microsoft® and the other authors of the White Paper do not undertake to provide any legal advice, but can on request recommend specialized lawyers for advisory and legal services concerning appli-cation usage scenarios. No liability concerning legal conformity is accepted by the enterprises in-volved in this White Paper or specifications. All liability is explicitly excluded.

According to the best of the knowledge of the paper’s authors and the participating manufacturers, the legal requirements in Germany can be fulfilled with a secure connector/applications and by As-signio itself.

Given individual rights of self-determination concerning personal information, it is the patient who takes decisions on how his or her data is to be used. The patient decides which data to use when helping to safeguard his health and manage illnesses and healthcare throughout his life. Data privacy is not at odds with patient protection here – rather, it helps make patients safer and more secure. Empowered individuals (in the eyes of the law) act as empowered patients, and it is they who take the decisions, rather than any third party. Accordingly, if an individual wishes to involve family mem-

HIS2Assignio Page 7

bers, trusted health professionals and other entities in his healthcare and data management, he can do this with specifically authorized applications.

Positioning with respect to German Medical Equipment Act (Medizinproduktegesetz, MPG) based on Medical Device Directive (MDD) of the European Union

• The intended purpose of Assignio is to store data and to enable sharing of healthcare data about individuals and their family members. This functionality is “patient-citizen”-centered.

• Assignio is not a medical product in the sense of the German Medical Equipment Act, and is not a substitute for medical diagnosis or therapy by healthcare professionals such as doctors or hospi-tals.

• As things stand, legislators have not yet reached a final verdict on whether healthcare platforms should be classified as medical equipment. Should Assignio be classified as such by the legislator, certification is planned.

• Third-party applications and devices authorized as medical equipment can use Assignio as a plat-form. Provided the portal’s rules and guidelines are observed, users can identify the origin of data and can trust that it has not been tampered with.

8 Target Audience

This document is written for:

• Medical facilities who wish to set up Assignio connectivity in cooperation with their system pro-vider

• Producers of hospital information systems and document management systems who themselves wish to offer an application

• Various manufacturers who wish to develop and offer an application to connect with Assignio

The document serves as an overview for product managers and innovators from medical facilities. The drill-down points highlighted in the document illustrate a few of the details for technical experts. Microsoft HealthVault is currently in use in four countries: healthvault.com in the USA healthvault.co.uk in the UK healthspace.com in Canada and under assignio.de in Germany. Other countries will follow and establish a service based on HealthVault technology.

HIS2Assignio Page 8

This document is designed around the specifics of the German healthcare system. Although it does accommodate international standards, its context is on the whole a national one, since it discusses the current status in Germany, developments on provider markets, and the specific requirements of hospitals and clinics. Analogies from this document for markets other than Germany are highly welcome, and are specifi-cally supported by the authors. Accordingly, this paper is designed to be a contribution to a cross-border initiative to make IT systems in the healthcare sector more compatible with one another.

HIS2Assignio Page 9

9 Preliminary Remarks

This White Paper describes what technical possibilities there are for transferring data and documents simply, securely and sustainably from a Hospital Information System (HIS) or Document Management and Archival System (DMAS) to the Assignio health management platform.

Where the term HealthVault™ is used in this document (the technical platform has widespread validi-ty), the technical specifications are equally valid for Assignio, the version localized to Germany. Where the term Assignio is used, the information is valid for operation in Germany and for additional services of providers or external vendors – see Figure 1. This is also the reason why the document is titled HIS2Assignio, even if much of it is internationally valid. On the German market, the view of documents is driven by the need to ensure cross-system compatibility and long-term manageability of files. Accordingly, formats are used which remain readable for decades, irrespective of which sys-tem generated them. At the very least, the formats can be converted by standardized procedures.

Assignio (“I assign” or “I allocate”) is the name of the Siemens IT Solutions and Services GmbH online platform powered by Microsoft® HealthVault™ technology. Empowering people to manage their own health records, the platform acts as a secure repository for the medical data of individuals.

In HIS2Assignio, a hospital information system is first and foremost taken to be the classical primary system. The classical HIS and other solutions such as DMAS and subsystems – in other words all the systems together – today form a modern, overarching HIS taxonomy which embraces the totality of information technology at the hospital. This White Paper also reflects this totality. The document does not use the term Enterprise Content Management (ECM), preferring to speak of Document Management and Archival Systems (DMAS) to underline the fact that this is the basic functionality relevant in document usage. However, providers of ECM systems are equally included in the target audience.

The document also illustrates a few specific examples of data and document exports and imports.

Using applications and compatible devices approved for Assignio, individuals can securely record, retrieve and exchange data on their health & wellness, and that of their family members. The plat-form helps individuals manage their health throughout their lives. Individuals using Assignio can ac-cess their health data anywhere and share this as needed with doctors and other health profession-als.

HIS2Assi

Figure 1: T

This docand docutreatmehealth mquestionright, mamedical ation wit

ignio

The shell model

ument descrument typesnt which an

managementn irrespectiveade possiblerecords as ath healthcar

l

ribes a specifs which can bindividual w. These valide of whateve by what tec way of optie profession

fic, well-defibe stored in Aishes use as

d clinical docuer treatmentchnology hasmizing healtals.

ned transferAssignio – than “accountuments and t he or she iss to offer, forhcare manag

r path whichhe results ant statement”data remain undergoing

r people to hgement – eit

concerns ond document-type medic

n accessible tat the time.

have this accether by them

nly part of thtation of inpacal record in to the individ. It is an indivess to a sum

mselves or in

Page 10

he data atient personal dual in vidual mary of cooper-

HIS2Assignio Page 11

An individual's personal safe – a secure online repository for storing personal health and fitness data - can contain far more data types than just the HIS documents. This document therefore does not describe the paths taken by all this data into an HIS or DMAS (Assignio2HIS). The focus of this White Paper is HIS2Assignio. The well-defined documents from the HIS which are in the Assignio safe can however be transferred back to the HIS by essentially mirroring the procedure. Depending on the utilization periods, this essentially creates the HealthVault™ Document Life Cycle, discussed in this document. The cycle is geared more to personal life situations of the individual than to archival peri-ods (see Figure 2). After all, Assignio is not an archival system for hospitals; it serves as a personal data safe throughout the life of the individual.

Clinics that see their patients as mature, empowered individuals can utilize the opportunities of the Assignio platform and associated application market.

The standard stable data transfer paths embrace and expand the status quo in Germany’s national health market and the standards already defined and established.

When it comes to documenting hospital treatment, there are already various shareable documents offering long-term archival stability and interoperability; others are approved by relevant authorities for future developments. The requirements which these digital archival formats have to meet make them suitable for use in Assignio.

What breathes life into a standard is not its definition, but the extent to which it is actually practiced in the wider market.

The White Paper takes up this idea, and accordingly it does not specify proprietary developments or theoretical models, focusing instead on standard practice, taking into account the normative pa-rameters of the market or recommendations published in guidelines, codes of practice, etc. of rele-vant associations.

The paper also provides drill-downs with more detailed treatment of various points for technically-minded readers.


10 Introduction

Putting people at the heart of the platform, Assignio helps individuals maintain their health and manage their health, fitness and wellness details securely.

If individuals wish to authorize medical facilities or other healthcare professionals to integrate and use this data via a secure platform application, Assignio serves as a platform offering a combination of

• The patient’s views of his or her structured data and documents

• Healthcare providers’ views of structured patient data, and verifiable documents provided by the patient in a legally compliant form

• Views of data pertaining to fitness, wellness, Ambient Assisted Living (AAL) etc.

Assignio supports all the processes in which the “citizen-patient” is directly involved, also treatment processes in which the patient is actively engaged in terms of processing the information. Treatment processes which include multiple facilities, or in single facilities where doctors and other healthcare professionals need to share information, are not the “use case” of individual-centered applications. This is more the subject of projects such as www.fallakte.de etc.

Valid clinical documents such as signed discharge summaries are designated as such, and can be in-tegrated into treatment and healthcare processes. Even when such reports are provided by the pa-tient rather than the clinic, the origin and validity of the documentation can still be authenticated.

However, the mere fact that a patient has decision-making power regarding his or her data safe is no guarantee that the information is complete. It is in any case impossible to give a 100% guarantee of completeness of anyone’s health records over the course of a lifetime – as we already know from decades of paper-based files distributed across a range of medical facilities, without any possibility of access. When dealing with one specific clinical “incident”, it is indeed possible to produce a largely complete case history. But this still does not address the need to manage health and healthcare de-velopment throughout the lifetime of an individual.

The process of transferring data and documents from the HIS to the Assignio platform, either on re-quest or on the explicit authorization of the patient, is fully compliant with essential data privacy requirements. When data is collected and reconciled in a secure place for the patient, it is the pa-tient’s needs, and his or her right to decide on matters of personal data privacy, which is at the heart of the platform. The patient decides which data he or she wishes to make available to selected indi-viduals.

The White Paper HIS2Assignio addresses developers of software applications which retrieve well-defined data and documents from the hospital information system or document management and archival system. It also addresses users and medical facilities who wish to implement innovative eHealth solutions with their software providers and are seeking an overview of what is feasible. These applications can be developed by


• Producers of Hospital Information Systems (HIS)

• Producers of Document Management and Archival Systems (DMAS)

• Other providers who wish to offer interoperability with Assignio

As shown in Figure 2, the documents defined for export remain suitable over time – even over many years –for re-importing into various HIS or DMAS. Accordingly, there can be short-term and long-term HealthVault™ Document Life Cycles. Documents do not have to be re-imported into the system from which they originate. It is possible to import the data back into any system.


Figure 2: The HealthVault™ Document Life Cycle

HealthVaultDocument Life Cycle

AuthentifizierungVerification

Security CheckLogging

Trust Status Checking

KIS Document Life Cycle Management

signed / unsignedHospital Infomation Systems

Document Management & Archival SystemsHealthcare Professionals

pdf/aTIFF

CDA XMLJPG

AssignioThe individual`s own safe

PDF/ATIFF

CDA XMLJPG

AuthenticationInformation provision

LoggingPatient security

Use in other primary systems

Data from HIS

Data from various sources for life-long health management

Devices etc.

PDF/A

CDA XML

JPG

TIFF

Medical Practice Document Life

Cycle analog to other

Systems


The initial goal is to pave the way to simple procedures, not to create a “networked health IT” with extensive semantic interoperability. Even if the use of structured data is the overarching goal, Level 1 is very much the human interoperability aspect, focusing on documents which are suitable as a whole for reading. Then comes Level 2, with a content structure permitting specific document sec-tions to be extracted for use, such as findings, diagnosis, prognosis etc.

Level 3 defines the use of individual data fields such as coded diagnoses, etc. for further processing, taken from relevant documents. The following assumptions apply:

• An available readable document (Level 1) such as PDF/A-1b is today more valuable than a Level-3-CDA document which will not be available until the distant future. The usability of contents from PDF/A-1a and PDF/A-2 is discussed later. Other chapters provide a more detailed treatment of HL7 Version 3 CDA and PDF/A, illustrating how content can be used on the basis of documents standards.

• It is not the technical format which determines the clinical relevance of data. Accordingly, classi-cal archival formats and modern specifications can all contain information which is important for the patient.

• The objective remains to evolve the platform toward using data and information on field level with semantic interoperability. The reconciliation mechanism of the HealthVault product already provides the technical basis to make this possible.


11 Assignio – the People-Powered Platform in Germany

Assignio, the localized version of HealthVault™ for Germany, adapted to the German context, is

The information-sharing platform for individuals, their hospitals and healthcare professionals.

For over a decade, Microsoft® has been stepping up its investment in solutions for the healthcare sector, focusing primarily on the highly specific challenges of this field. In collaboration with partners, Microsoft® is working to improve health standards worldwide through software innovation. Stand-ardizing healthcare data, and facilitating its exchange, help give people everywhere the best-possible quality of life and affordable healthcare.

Through open systems and connectivity options, Microsoft® is building a scalable, patient-centric IT system for health data enabling users to manage their personal health information. Microsoft® also offers solutions for health solution providers, enabling them to consolidate and re-use their data and build on this repository of information to optimize patient care.

Microsoft® HealthVault™ has been developed for individuals, providing a secure online platform for people to store and retrieve their health information and choose who they wish to share it with.

Individuals can use their data in conjunction with health service providers in a range of ways, e.g. to oversee and manage their health and wellness activities.

To accommodate the specific requirements of the healthcare system in Germany, and adapt Health-Vault™ to the German context, an extensive localization process has been completed with special security and use case procedures.

The national version Assignio – the health platform is

• Non-proprietary: Assignio is open for collaboration with partners with regard to connectivity and onboarding of health systems, their data and documents in appropriately standardized form.

• Citizen-centric: Patients themselves decide how their data to be used. Individuals can choose to allow members of their family access, or authorize doctors to use their information for treatment or advice purposes by retrieving information via special applications with access authorization.

• Secure: Documents and data are as secure as in a safe. And patient security – protecting the life and health of the patient – can finally be the number one priority.

• Open: Assignio is open for a wide range of software applications which, following an admission & approval process, can enrich the Assignio application world and deliver benefits to individuals.

• Contemporary, a lifetime partner: Through appropriate applications, individuals can manage their data at all stages of their lives, even though to deciding how and where to live in old age. From birth (specific characteristics, or illnesses) to death, the platform reconciles the complete array of information.


The acceptance of a patient-centric health platform such as Assignio is contingent on having a broad-based portfolio of applications and devices which connect to Assignio and offer people additional benefit in maintaining and managing their health data. With Siemens IT Solutions and Services as its sales partner and operator in Germany, Microsoft has acquired a partner who is committed to de-veloping the HealthVault -based solution into a comprehensive ecosystem in Germany. Siemens IT Solutions and Services is committed to ensuring secure, confidential storage of health data in high availability German data centers, utilizing all possible technical and organizational means to uphold compliance with data privacy legislation, ensure data integrity, as well as authenticity and confidenti-ality in data exchange. The operator has also developed a charter (https://partner.assignio.de/de/Downloads.aspx) which sets out the interests of all the participants and partners in the ecosystem. The system is governed by basic rules on fairness and transparency, and is overseen by a supervisory board with both internal and external members. The Assignio partners play a key role in developing the Assignio health platform into a connected, nationwide ecosystem.

HIS2Assi

Figure 3 Po

These pawhich pral alwaysquality imnew, as yecosystealize the

The figur

ignio

otential partne

artners are crovide individs a priority –mprovementyet untried c

em, Microsofe business ide

re below sum

ers for the Assig

chiefly healthduals with th

– are free to t, process opconcepts to dft® and Siemeas of partne

mmarizes the

gnio platform (b

hcare provideheir services develop theiptimization, deliver mutu

mens IT Solutiers and lever

e various par

based on Micro

ers such as hon the platf

ir own busininitiatives to

ual benefit toions and Serrage networ

rtner levels i

osoft® HealthVa

hospitals, doform and – wess models.

o cut costs oro individuals vices will actk effects.

in the Assign

ultTM)

ctors and rehwith the inter

These can br save time, oand partner

tively move a

io ecosystem

habilitation crests of the ie anything for the pursurs. In developahead to ope

m:

Page 18

centers ndividu-rom it of ping the eration-

HIS2Assi

Figure 4: P

Applicatate applvelopmement systions on develop take the

In GermaAssigniofor regisorganizaware itsewhich enhave a suals conplatform

12 Spe

Like the governeare alreanational

ignio

Partner levels in

ion partnersications on t

ent partners stems develoboard, and tappropriatem into prod

any, the serv health platftering and lo

ations, ID proelf is kept consures the sopecial positionect to their

m.

ecific Nat

health systed by the prinady establish systems also

n the Assignio e

s are essentiatheir own accsuch as the op the requisthen market

e concepts fouction.

vice providerform. To provogging onto tovider partneonstantly up oftware conton within ther PC at home

ional Cha

ems themselvnciple that, whed in practico count for s

ecosystem

ally service pcount and coproducers ofsite applicatt the applicator the applica

r Siemens ITvide people the platformers such as Mto date by Mtinues to adde ecosystem

e, enabling th

racteristic

ves, technicawhere internce, these intesomething. L

providers in tommunicatef hospital infions, work wtions to applation partne

Solutions anwith facilitie

m, the platforMicrosoft® wMicrosoft® indress latest r

m. Assignio suhem to load

cs, Interna

al recommenational standernational st

Legal situatio

the healthca directly withformation sy

with the platflication partnrs, and help

nd Services ises to choose rm operator

with the Windits Secure S

requirementupports integhealth data

ational Sta

ndations anddards can alstandards shoons, market c

re system whh the patient

ystems or docform operatoners. The conimplement t

s responsibletheir usernaalso uses the

dows Live ID.oftware Devs. The platfo

gration of dedirectly into

andards

d standards inso be implemould take preconditions, a

hich build ants. Applicatiocument manor to get thensulting partthe applicati

e for operatiames (pseudoe services of. The platfor

velopment Liorm’s device evices which their record

n healthcaremented natioeference. Hoand what is h

Page 19

nd oper-on de-nage- applica-tners ons and

ng the onyms) f external m soft-fecycle, partners individ-

ds on the

e IT are onally, or

owever, happen-


ing in a society – all these essentially determine whether and how information technology is de-ployed.

The White Paper takes into account mandatory frameworks – such as those of the German Institute for Medical Documentation (Deutsches Institut für Medizinische Dokumentation und Information / DIMDI), Federal Network Agency (Bundesnetzagentur / BNetzA) and Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik / BSI) regarding electronic signatures, and frameworks that set out concepts and guidelines, e.g. of the German Association for Medical Informatics, Biometry and Epidemiology (Deutsche Gesellschaft für Medizinische Informatik, Bi-ometrie und Epidemiologie / GMDS).

Also of relevance is what happens in practice, what the current jurisdiction is. This also determines whether an application will be successful in practice or not.

This White Paper for the German market is based on evaluation of the non-mandatory and mandato-ry international and national standards, common practice, and projected market development.

With the content being localized for Germany, there is no one-to-one equivalency with international concepts. Nevertheless, the White Paper has been translated into English for international readers.

The HIS2Assignio specification is geared both to international standards and trends and to the specif-ics of the German healthcare system. The Assignio concept of interoperability complements the es-tablished consensus in recommendations put forward by specialist associations on interoperability, legal conformity, evidential function, legal certainty and data privacy.


These recommendations include specifications published by the following bodies (most of these are specifically German):

• German Association of Producers of IT Solutions for Healthcare – Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.V. (www.vhitg.de)

• Association for Digital Document Standards e.V. - PDF/A Competence Center (www.pdfa.org) of the German Association for Medical IT, Biometrics and Epidemiology e.V. (www.gmds.de)

• Association of German Hospitals (www.dkgev.de)

• Competence Center for electronic signatures in the healthcare sector, e.V. (www.ccesigg.de)

• Federal Network Agency (www.bundesnetzagentur.de)

• Federal Office for Information Security – Bundesamt für Sicherheit in der Informationstechnik (www.bsi.bund.de)

• Electronic Case File Association www.fallakte.de

• Integrating The Healthcare Enterprise (IHE) www.ihe-d.org

• HL7 User Group Germany e.V. www.hl7.de / SCIPHOX

…also, the relevant professional associations for the various contexts in which Assignio is used. This serves to show that application and interface developments are embedded in what is happening on the market.

The options described in this document for connectors/applications present just some of the oppor-tunities available for placing data and documents in Assignio. The analogy between document man-agement systems and hospital information systems is drawn deliberately, because document man-agement in interaction between HIS/general primary systems and DMAS is already established prac-tice between various manufacturers and in numerous hospitals on the German market. It is therefore logical and consistent to use documents in state-of-the-art archival format such as PDF/A-1a with XMP-structured data, and this is also comparatively easy to do in terms of underlying technology.

A hospital does not necessarily need a DMAS in order to use applications for HIS2Assignio transfers. The hospital merely needs the services which can generate the standard formats; having such facili-ties is in any case both advisable and necessary in a hospital, irrespective of Assignio and DMAS.

In line with the recommendations of the above named associations, documents which are appropri-ate for long-term archiving – and therefore ubiquitous in the digital world – are also suitable for im-port into Assignio:

• TIFF

• PDF/A-1 or PDF/A-2

• VHitG HL7 CDA Release 2

• jpg

• XAIP (XML-based archival information packages as per BSI)


Conformity is also recommended with non-normative guidelines and recommendations such as those of GMDS. The Assignio platform is aligned with real life, and does not build a set of theoretical constructs which are far removed from being workable in practice.

13 HealthVaultTM Document Life Cycle: Export from a Primary System and Import into Assignio

In recent years, the system-neutral Document Life Cycle (as per GMDS) has become established for long-term archival on the producer and user markets in Germany. Depending on the implementation status, in some cases current archival formats such as TIFF or PDF/A are the common practice; in other cases the focus is shifting to HL7 CDA Release 2 (Clinical Document Architecture).

At present, scanned documents are in PDF/A or TIFF format. These formats contain solely metadata, so are primarily for Level 1 (readable documents). However, since such documents can also contain important information, Assignio supports the use of scanned documents as well as digitally-created documents.

Interoperability is not accomplished by unifying systems but by rendering data and documents in neutral formats – neutral in the sense of syntactic and semantic interoperability.

Clinical data belongs to the medical facilities, with extensive entitlements on the part of the patient to view this information. The data does not belong to be manufacturers – the role of the systems is merely to manage the data.

Standard HL7 CDA Release 2 approved by VHitG permits multi-provider use of content, which is the desirable goal.

PDF/A with the Extensible Metadata Platform (XMP) and CDA can each be transformed in both direc-tions, see also Drill-down on PDF/A.

With the specification deliberately restricted to standardized document types, the significant ad-vantage is long-term document usability, or shareability. A “document” is considered to be a collec-tion of data presented as a unit. This general understanding of what a document is embraces all the salient steps required to transfer this “unit of data collections” between various stakeholders secure-ly and validly, with a clearly authenticable origin.

The following figures illustrate the processes of copying documents to the Assignio platform.

To prepare the ground, Figure 5 illustrates the basic steps, together with the checking mechanisms which underwrite the secure export of the checked document or data. This process takes place under the control and sovereignty of the hospital, before the data and documents are transferred to the Assignio safe. A validation service is used which verifies that the criteria named in the figure are all


fulfilled. The electronic signature is optional, meaning data can still be exported or stored in the As-signio safe without it. In reality, many documents, particularly older ones, can have signatures which might have been valid at the time of creation, but are now technically obsolete. Even so, the signa-ture is essentially still valid, and this state of affairs is documented clearly in verification logs. Figures 6 and 7 show a document creation process and pre-export preparation in greater detail.

Figure 5: Overview: Export – Check – Import


Figure 6: Creating a document suitable for Assignio


Figure 7: Ready for export

CAN step 3: Further metadata can be transferred with the document. The long-term archival format TIFF, PDF/A or a CDA XML format document is transferred to Assignio.

MUST step 1: having received a formal explanation of what the process entails, the patient consents to the export to Assignio, either during hospital treatment or afterwards. There must be official documentation that the explanatory session has taken place and the patient has given consent, and this must be archived.

SHOULD step 2: if the export documents have a qualified electronic signature or timestamp, this should be documented in a verification log which is also sent to Assignio. Otherwise the check of PDF/A conformity should be documented.

HealthVault Document Lifecycle – Ready for Export

Inhouse validation

TIFF

pdf/a

CDA XMLJPG

TIFF

pdf/a

CDA XMLJPG

Consent

HIS / DMAS with signatureand document services

Export2Assignio

HIS / DMAS


14 Precepts of Assignio/ HealthVault™ for Handling Patient Data

Assignio is governed by the following principles:

1. Patients have sovereignty over their own data and – at least initially – the sole right of disposi-tion. Patients can accept and keep medical documents which they wish to store or view, or ex-clude them from the upload process and thus delete them. Individuals can upload data from their personal devices to Assignio to create an overall picture of their health development. In addition, pre-approved applications can be authorized to upload specific healthcare data which is presented in chart form. Patients have the choice of keeping or deleting this data.

2. Data and documents are not modified in the platform. 3. Apart from the individual him or herself, and the applications which the individual has explicit-

ly authorized, no one is able to access this data. 4. To exchange patient data with Assignio, the hospital must operate a Assignio application under

its own sovereignty. The application must be certified secure and in working order by an onboarding process conducted by the Assignio operator. In addition, the application function-ality must be expressly authorized by the patient. The onboarding process is not dealt with in this paper, however a description can be downloaded from: https://partner.assignio.de/de/Downloads.aspx

5. To obtain one-off or continuous access to the patient’s Assignio safe and upload its own data, the hospital must conduct a formal information meeting with the patient, and document the patient’s agreement to having his or her data exported to Assignio.

6. Assignio does not perform any archiving tasks for the medical facilities with regard to their ob-ligation to archive information in an auditable form. Overall, it has neither the objective nor role of doing the hospital documentation or to act as a substitute for other documentation functions in the facility.

7. Assignio supports processes in which individuals are actively involved in terms of processing, providing and using information. Clinical therapy paths which serve to connect doctors and other healthcare professionals lie outside the scope of Assignio.


15 Assignio and the ICT Infrastructure in the German Healthcare System

The positioning of Assignio with regard to ICT planning in Germany is based on the following assump-tions:

• Assignio complements the functionality of the electronic health card, its applications or other

forms of professional data exchange between complementing service providers.

• Assignio offers the possibility of providing individuals with documents generated with the ICT infrastructure of electronic health cards such as discharge summaries, and helps individuals man-age their own health information.

• Assignio enables stakeholders such as doctors and hospitals to fulfill their legal duty of disclosure to patients with regard to storage of information.

• Assignio itself is located as a secure platform with the operator. Data is placed in and retrieved from Assignio by software applications which each address various use cases and have to fulfill different set of requirements.

• Certain scenarios are subject to the requirements of ICT infrastructure or of gematik (www.gematik.de). These are future electronic health card-related applications subject to specific legal provisions, and are not described in this paper.

• Through encapsulating applications, it is possible to set up patient-oriented use cases and applica-tions in the doctor-patient relationship for which it is neither necessary nor feasible to use ICT in-frastructure.

• Depending on the scenario, it may also be necessary to consider gematik specifications. However, both individuals and applications can get started irrespective of this – for example, by uploading data from medical documentation which they have a right to view under German Civil code (§ 809-811 BGB, § 611 / 242 BGB), state hospital legislation, and also under section 1 and 2 of the German Basic Law, which sets down individual rights of self-determination concerning personal information.

• Given the patient’s right to view medical information, facilities might wish to provide a type of medical “account statement”. In reality, a formal viewing session at the service provider’s site may not be feasible. Above all, this is not patient-oriented.


16 Use Cases and Registering with Assignio

16.1 Common Scenarios

The examples below give readers a good idea of the use cases which can be appropriately addressed by Assignio:

• Outpatient treatment (acute, chronic, short-term, long-term) – discharge summaries, interim reports to professional associations, and medical certificates are all placed in Assignio

• Inpatient treatment (acute, chronic, one-off, multiple) – discharge letters, medical certifi-cates, rehab requirements

• Rehab measures – outpatient or inpatient discharge summaries and interim reports are transferred to Assignio

• Relevant images for confirmed diagnoses and treatments performed (DICOM, JPG, TIFF etc.)can all be placed in Assignio – DICOM is presently unsuitable owing to its size

• Second opinions obtained by patients on the basis of document material already present in Assignio

• Prevents examinations from being performed multiple times by referencing information al-ready stored in Assignio

16.2 Common Use Cases: Examples • John W.:

When visiting relatives, John suffers sudden chest pain causing him to seek outpatient treat-ment in the emergency department of the nearest hospital. He is diagnosed with heart prob-lems, and is prescribed suitable drugs. Once this condition has stabilized and he is discharged from the hospital, a discharge summary is uploaded to John's Assignio account by the hospi-tal. John's GP can be provided with this information for use in later checkups.

• Denise Z.: On the advice of her pediatrician, Denise sets up a Assignio account for her newborn child and for every other member of the family. This enables her to manage the records for her entire family, also for her father, whom she and her brother care for. As the years pass, she accumulates a significant repository of documents. Information concerning inpatient treat-ment of her newborn child is also stored in the Assignio account. Once treatment is com-plete, the reports, including operation records, are sent to Assignio.

• Harry S.: When Harry is discharged from hospital following a tummy tuck, the hospital sends the dis-charge letter straight to Assignio to ensure prompt post-operative care by his doctor – Harry lives over 150 km away from the hospital, which specializes in plastic surgery. Two days after his discharge, Harry notices reddening around the site of the operation and is running a high-temperature. He immediately seeks treatment from his local hospital. By authorizing access


to his documents on Assignio – this can be done on a patient terminal or Smartphone – Harry can give hospital staff instant access to the original treatment data.

Individuals can participate in these Assignio services simply by opening an account. This requires initial registration.

16.3 Initial Registration of an Individual on Assignio

Opening a user account in Assignio comprises a few very simple steps. And if the person already has an account with an external ID provider, registration is even simpler. At present, Assignio supports Windows Live ID and providers who use the open ID standard. It is also possible to create1 a Win-dows Live ID and Assignio account at the same time, which further simplifies the process.

Figures 8 to 10 show the steps for registering with Assignio; for reasons of simplicity, it is assumed the individual already has a Windows Live ID:

1This will be integrated with one of the next updates of the platform. HealthVault as the technology includes this functionality

HIS2Assi

Figure 8: R

ignio

Registering withh Assignio with

a Windows Livve ID

Page 30

HIS2Assi

Figure 9: E

ignio

Entering relevannt personal dat

ta is all that is nneeded

Page 31

HIS2Assi

Figure 10:

Once thesimple, f

The user

The userer, and cmation pthe systehave thethrough what infanonym

There is

There is tions andspecific sform, an

What is derstanduser. Daon the p

ignio

Confirming the

e user has cofamiliar proc

r’s Assignio a

r’s account incan be modifpertaining toems followine option of dthe informa

formation is ization.

no further v

no discussiod persons rescope of info

nd described

important foding that autta exchange

part of the us

e information e

onfirmed thecess.

account is no

nformation ified if requiro the Assigniong authenticaefining a psetion stored istored in the

verification o

on in this papeceive accessormation). Thin detail in t

or potential Athorizations f involving pe

ser in the aut

entered

e authorizatio

ow ready for

n Assignio caed at a later o account, oation is the ueudonym as in the accoune Assignio ac

f the details

per of how uss to the datahis functionathe online he

Assignio partfor applicatioersonal recorthorization p

on and servi

use.

an differ fromdate. At no r vice versa.

unique ID. In their logon nnt. Since use

ccount, they

entered by t

sers can reta(access can

ality is intuitielp.

tners – applions and for irds in Assignprocess.

ce agreemen

m the informtime does thThe sole infodefining the

name. This pers have a cocan take ste

the user for

ain control obe limited toive; it is easil

cation develindividuals aio requires a

nt, the accou

mation storedhe ID provideormation exc

eir profile setpseudonym c

mplete pictups to counte

the Assignio

ver their dato specific perly deduced b

opers or opere managed

at least one a

unt is created

d with the IDer receive infchanged betttings, users can be “softeure at all timer this de-

o account.

ta and how ariod of time

by users of th

erators – is t separately bactive interv

Page 32

d – in a

D provid-for-tween also

ened” mes of

applica-or to a

he plat-

the un-by the ention


16.4 Legal Aspects of Registration on the Assignio Portal

The registration process indicates that a Assignio account is opened on the Assignio portal in con-formity with legal requirements. Assignio offers a range of options for using the accounts, including family data management. Parents can manage data for their children; and adults for their elderly parents, provided the latter give their consent. Individuals can create a separate Assignio account for each person, or manage separate records for members of their family within their own account. When an account is created, the operator requires a person to submit his or her consent to the stor-age of personal data of a specific nature which the person can submit voluntarily. The person creat-ing the account must also confirm to the operator that he/she is in possession of any required con-sent to manage the data of other individuals.

Carers can also use the Assignio platform, creating accounts for individuals under their charge, and entering themselves as the data manager. Adults can use the platform on behalf of their parents, provided the people in question submit their written consent.

For legal reasons, a disclosure agreement must be submitted to verify consent to the transfer of data to Assignio. The patient can obtain the essential forms either on the Assignio portal, or directly from healthcare professionals or hospitals. This is in many cases already part of clinical practice for obtain-ing patient consent to electronic data processing. Without the written, documented consent of the patient – which must be archived – it is not permissible for hospitals and other service providers to exchange data with Assignio on behalf of the patient.

Further information is available here:

https://partner.assignio.de/de/Downloads.aspx

16.5 Variants of Data Exchange between HIS and Assignio For a detailed description of how applications can connect with Assignio, readers should consult a dedicated White Paper2 on this subject.

Essentially, a differentiation is made between native (online) and linking applications. The latter are also termed offline applications, because they also function when the patient is not logged into As-signio at the time. Linking applications are primarily intended for allowing communication with an Assignio account without intervention of the patient – always under the proviso that the patient has first authorized the account access.

There are two basic approaches for connecting offline applications to Assignio: DOPU (Drop Off and Pick Up), and Patient Connect. Drop Off and Pick Up is intended for cases where a user wishes to authorize one single document transfer (unidirectional) rather than persistent access authorization. In a DOPU connection, the user agrees a connection ID and access code with the service provider, and receives from the provider a link to the data transfer functionality of Assignio. The data is anon-

2http://download.microsoft.com/download/7/4/E/74EA8944-199C-4F56-B3BB-8105869425BC/HealthVault%20Application%20Integration%20Recommendations%20v1.pdf


ymized, password-encoded and placed in an Assignio cache (this is the drop-off). The user can then follow the link, enter the connect ID and password to pick up the data, and place it in his or her per-sonal record. The process also functions if the user does not yet have a Assignio account. Ideally, the link is provided to the user electronically, and all the provider needs is the user's e-mail address. However, the provider can also print out the link and send it to the user. The sending application does not get access to the records already in the account, nor is the application notified when the patient picks the data up. The application does not itself have to be authorized in Assignio– the pa-tient merely authorizes the one-off data transfer, so the application does not need an online compo-nent.

The Patient Connect process serves to configure a longer-term, and importantly bidirectional link between the hospital information system and Assignio. A connection is established between a pa-tient ID in the hospital information system, and a personal record in Assignio. The first time the con-nection is established, the process is similar to Drop Off and Pick Up, the difference being that, in-stead of being asked to authorize the one-off data transfer, the user is asked to authorize persistent access by the hospital application itself. The user is told which functionality the application has, and which data types have to be enabled for data exchange for reading or writing. Like Drop Off and Pick Up, the Patient Connect process does not need an online component.

The concept of the master/child application permits application development partners to create an application (the master), onboard it on the platform, and then provide it as a child application to their customers. These customers then operate the application on their own account, making it available separately to users, i.e. independently of the master application. This concept is also dis-cussed in the above-mentioned White Paper.

16.6 Document Processing in Assignio Assignio-based medical records created through data exchange with applications contain data and document structures which are have different levels of processing detail:

• Illness, health development, medication, measurement values etc. are stored in a structured repository, comparable with individual tables per data type.

• Individual documents (PDF/A-1b, JPG, TIFF etc.) placed in the account are listed in chronolog-ical order and can be selected and opened individually.

• Thanks to embedded structured information, VHitG-compliant and special PDF/A-1a format-ted discharge summaries are segmented technically into individual sections (chiefly clinical examination results such as blood pressure), meaning that an individual does not have to read an entire report to retrieve a single item of information. Instead, it is possible to view a chronological sequence of values for any area of concern – in this example BP. This Assignio functionality is also known as the reconciliation process. The complete discharge summary is also stored and presented as an entity, without compromising its integrity in any way.

The following figure illustrates the reconciliation process for a VHitG discharge summary.


Figure 11: Reconciliation process for a VHitG discharge summary

© Si IT S l ti d S i G bH 2010 All R ht b h lt


17 Primary System: HIS

Hospital Information Systems (HIS) are not only able to export data to Assignio, but also selectively to extract, aggregate and then to export the data into a secondary format. The systems achieve this through various approaches.

It does not essentially matter whether an HIS has a document management and archival system of its own or uses a third-party system. Using its own or integrated services such as Adobe Rendition Ser-vices, it produces neutral or durable formats such as PDF/A or TIFF, or ideally also HL7 CDA Release 2. Where this is not possible, specialized document management systems can perform these tasks in their entirety.

The following description is also applicable for practice management systems which are able to pro-duce medical documents in HL7 CDA Release 2 or PDF/A format.


17.1 Drill Down: Processing HL7 CDA Release 2 Structured Data

17.1.1 Discharge summaries, Other Documents and Objects, Document Formats

The purpose of a discharge summary is to give an epicrisis of inpatient and/or outpatient treatment, its content and procedure, all presented in a comprehensible manner. Accordingly, the discharge summary is among the most important means of communicating and sharing medical information quickly and efficiently.

The logical structure of the summary is based on a set of internal milestones which have been stand-ardized for over a century:

• Identification in the salutation of which medical professionals are being notified

• Patient identification

• Diagnosis

• Therapies

• If appropriate, pathologies (histological examinations)

• Reason or reasons for inpatient and/or outpatient treatment

• Findings that gave grounds for the selected therapy

• Progress of inpatient and/or outpatient treatment

• Medication (permanent, new)

• Final recommendations

There are significant differences in length and level of detail, depending on the origin and medical discipline, and a summary can usually be anywhere between one and 10 pages long.

Various other documents such as insurance queries or expert opinions can also play a role. In tech-nical terms, the objects primarily comprise “binary objects”, i.e. image files, which are important for diagnosis and therapy and are therefore in some cases even transferred separately to Assignio.

The members of the German Association of Producers of IT Solutions for Healthcare – Verband des Hersteller von IT-Lösungen für das Gesundheitswesen e. V. (VHitG) – have reached a formal agree-ment on the format of a discharge summary in the last three years.

According to Version 1.50 of the implementation guidelines, valid from 2 January 2011, the authori-tative format for all types of discharge summary (also rehabilitation) is HL7 CDA Release 2. It is stated that the guideline is an aid to implementation, helping developers and users develop and configure communication though discharge summaries. The supporting documents provide examples of let-ters, stylesheets, schemata, schemata rules and additional information.


There are various ways of generating these document types:

• The simplest approach to generating a discharge summary, document or object in general is to use a generic technical service which is able to transfer the clinical information to a HL7 CDA Release 2 or PDF/A document (here: PDF/A-1b only). However, generating true PDF/A-1a requires specialized services – these are available on the open market and can easily be integrated into a hospital information system. The HIS can then transfer documents of this type directly to Assignio, together with an identification of the patient and sending facility, and a timestamp. These rendition services can be maintained by HIS manufacturers inside or outside the system, or be provided by specialized service providers and software foundries in the form of middleware applications between HIS and Assignio.

• A complementary or standalone procedure is to use a communication server which converts the proprietary HIS format to HL7 CDA Release 2 or PDF/A format and transfers the convert-ed discharge summaries, documents and objects to Assignio either itself or using middle-ware.

17.1.2 HL7 CDA Release 2

There are already a number of medical associations in Germany who are engaging intensively with the issue of HL7 CDA Release 2 discharge summaries as per VHitG recommendations, and have even published this in examples on their website, for example (the North Rhine Doctors’ Association).

Release 1 of the Clinical Document Architecture (CDA) was officially approved as American Health Level Seven (HL7) ANSI standard in November 2000; in May 2005, an extension of the HL7 Reference Information Model (RIM) was published and Release 2 came out. The key difference between the releases is the semantic representation of clinical events.

This markup standard is therefore an ideal basis for all types of interoperable data exchange. With the VHitG workgroup already promoting the standard, the first HIS software foundries have already implemented the standard directly, and producers of medical practice management software are also now adopting the same practices.

A CDA clinical document has the following six for properties:

• Persistence – permanent existence in the sending or receiving systems

• Stewardship – responsibility for managing the document

• Potential for authentication – electronic signature or timestamp

• Context – default context valid for entire document


• Wholeness – individual items from the document cannot be used without reference to the document as a whole

• Human readability – this ensures that sections of the XML document can be made readable with very simple means such as stylesheets

In summary, a CDA document consists of a CDA header and a CDA body, which in turn comprises body structures and body entries. External references can be linked to the entries.

These chief components of a CDA document are as follows (since Release 1):

HIS2Assi

Figure 11:

• Tt

• Tj

• Tf

In the dyboards –

ignio

CDA header an

The CDA heatication, case

The CDA bodject or struct

The CDA bodfollowing cla

• obse

• proc

• enco

• subsplan

• supp

• orga

• obse

• regio

ynamic mode– which pres

nd CDA body w

ader identifiee status, the

dy comprisetured marku

dy entries arasses are ava

ervation –cod

cedure –e.g.

ounter –deta

stanceAdminnned adminis

ply –of mate

anizer –serve

ervationMed

onOfInterest

el of summaent the med

ith constituent

es and classi patient and

s clinical findp within rec

re augmenteailable:

ded observa

an operation

ails on earlier

nistration –mstration

rial or medic

es to group o

dia –multime

t –denotes a

rizing and undical view of t

elements

ifies the docu participatin

dings and caursively nest

ed by HL7-RIM

tion such as

n, or other tr

r, present or

medication re

cation

other CDA en

edia content

particular as

nderstandingthe patient –

ument and cg service pro

n contain eitted documen

M classes an

findings or d

reatment, ex

r planned pat

elated details

ntries (batter

as part of th

spect of an i

g medical fin– are transiti

contains infooviders.

ther an unstrnt sections.

d their attrib

diagnosis

xclusively dia

tient contact

s – medicatio

ries, clusters

e document

mage which

dings, use caoned to a m

rmation on a

ructured bin

butes. Typica

agnostic inte

t

on anamnesi

)

t

is of interes

ases and stomore technica

Page 40

authen-

ary ob-

ally the

rvention

is or

t

ory-al rendi-


tion, the interaction model. The most frequent use cases are the complete discharge summary, a change to the summary, and document and object attachments.

Examples of documents of this type are provided in the attachment to this paper.

17.1.2.1 HealthVault Thing Types

The thing types in Microsoft® HealthVault ™ define native XML structures which can be used to pre-sent clinical status and findings from a HL7 CDA Release 2 context in subcontainers. These are simple XML files created through transformation and validation and then placed in Assignio.

These data types can be extended both in the private context of an application and also in a commu-nity context. The latter can be useful when several application developers have agreed on a common approach, but there has yet been no consensus at a higher level (e.g. industry association)3.

The essential structure of thing types is a Microsoft® entity established as a community promise un-der the Microsoft® Health Solution Group. This means change requests are taken up as soon as there is broad support from recognized players pushing for the change in question. This prevents the data structure from becoming bloated, but does provide adequate flexibility to make necessary modifica-tions to data storage structures.

Changes to thing types are all globally valid, in other words across all international instances of HealthVault. Accordingly, changes to thing types in the USA are automatically integrated into the Assignio structures here in Germany. A developer of an application can therefore be confident that the application can be used internationally, irrespective of where in the world it works with Health-Vault.

Below are a couple of examples of thing types showing the integrated results Blood Pressure Meas-urement and Allergic Episode:

3Further general explanation here, but especially Extending HealthVault Data Types and HealthVault Data Types: Custom Data Types

HIS2Assi

Blood pr

ignio

ressure meassurement:

Page 42

HIS2Assi

Allergic e

The thindocumeous clinisummar

It is imponot necespread intumors adiagnostbasis is avarious fcan be eboratory

It is impoand stan

ignio

episode:

g types presnt which hascal contentsy can be res

ortant to notessarily bindin Switzerlanare documentic interventialways the mformats (a ch

expected pery results.

ortant to clandardizing dif

ented here as been broke to be grouphaped in this

te that the cing for Germd – is largelynted as per ICions are inclu

most recent vharge is paya year. The LO

rify these pofferent term

are the resulen down intoped into sepas way into m

lassificationsmany. The SNy replaced in CD-O. Operauded in the Oversions of thable for someOINC classific

oints becauseminologies an

lts of a compo its structuraarate, standa

more easily re

s and other dOMED CT claGermany by

ative proceduOPS classificahese classifice) from the Dcation is also

e the terminnd classificati

plex transforal and conte

ardized sectioeadable units

document stassification –y ICD 10 clasures, includination (Operacations, and tDIMDI (wwwo suitable in

ology serverions at the H

mation of annt elements,ons. An extes.

andards pre– used in thesification codng anesthesiation & Procethese can be

w.dimdi.de). Germany for

rs are taskedIS level, mea

n HL7 CDA Re, enabling th

ensive discha

eferred in thee USA and alsde, and maliiology, or puedure Keys).e downloadeOne or two r documenti

d with harmoaning they w

Page 43

elease 2 he vari-rge

e USA are so wide-gnant

urely The

ed in updates ng la-

onizing work only

HIS2Assi

with a sitended a

The nextGerman

17.1.2.2

As in anythorizeddocume

For examThe patital signs signaturtion.

The techfication:

KeyInfo DigestMCanonicaSignaturTransfor

The code

ignio

ngle valid claand has been

t chapter conterminology

Embedding

y other docu change has nt origin.

mple, the hosent must firsthe documee to ensure t

hnical attribu

Method alizationMereMethod rms

e to electron

assification on implement

ntains a CDAy and classifi

g CDA Signa

ument type, ebeen made

spital signs ast obtain theent digitally athe list has n

utes of the el

XS

thod CPPd

nically sign a

or taxonomyted.

A code exampcation criter

tures in Assi

electronic sigto the docum

a list of medie items from and might alsnot been tam

lectronic sign

X.509 certificSHA1 C14N11 PKCS1 Predefined XSdata_other

document u

y, unless corr

ple for Assignria.

ignio

gnatures in Cment, and th

cations whica pharmacyso assign it a

mpered with,

nature in Mi

cates by Veris

SLT transfor

using a X.509

responding v

nio showing

CDA documehere is a fully

ch the patien. To provide

a timestamp. and its issue

crosoft® Hea

sign, Comod

mations with

9 certificate l

version mapp

how thing ty

ents authentiy valid audit t

nt is to take fa fully verifia. The pharmaer is in fact t

althVault™ fo

o, Geotrust a

h reference t

ooks like this

ping is expre

ypes are ma

icate that notrail back to

following disable path, thacist verifieshe hospital i

ollow the W3

and Entrust

to data_xml

s:

Page 44

ssly in-

pped to

o unau-the

scharge. he hospi-s the n ques-

3C speci-

and

HIS2Assi

This ste

•

•

of the He

Broken d

The valid

•

as follow

The valid

•

can look

ignio

p is impleme

HealthRecorItemTypes.ty

ealthVaultTM

down to XML

dity of the ce

HealthRecor

ws:

dation step a

HealthRecor

k like this:

ented by the

rdItem.Sign()ype.Sign()

M .NET SDK in

L level, the s

ertificate can

rdItem.Vaida

at such, by m

rdItem.IsSign

procedures

) or

n C#.

tep typically

n be checked

ateCertificate

means of

natureValid()

y looks like th

d by

e()

)

his:

Page 45

HIS2Assi

All the fuwhich m

17.1.3 S

The origCDA Releta, validatransformalways twhich haquire a cFigure 12

ignio

unctions andmakes verifica

Separate CD

inal XML docease 2 formaated in indivmation into akes place was been provclinical docum2 in the form

d proceduresation of the s

DA Code Exam

cuments (VHat, are segmeidual sectiona range of ot

when the patvided by a coment to be g

m of a transfo

s required fosignatures an

mple for Ass

HitG dischargented into sens (e.g. bloodther XML fileient selects a

onnector. Thigiven in the Rormation pro

r these checn easy matte

signio

ge summary)everal XML sd pressure, aes, the Nativand permits is reconciliatRoot XML Noocess broken

cks are provider.

composed aschemata, thallergic episove Structures

a VHitG disction is triggeode. This recon down to XM

ded by Healt

as per VHitG e Assignio Tde) and brokor Thing Typ

charge summred automatonciliation pML level:

thVaultTM .NE

specificatioThing Types Sken down bypes. This pro

mary documetically, but dorocess is sho

Page 46

ET SDK,

n in HL7 Schema-y XSL

ocess ent oes re-

own in

HIS2Assi

Figure 12:

The basiin the tra

Once thischemattype schta for an

The tranin Attach

Then compreferabprovided

Another Rhine Doformatte

Relevant

Allergic e

 tion[x:code/@co

cess of a VHitG

ary whose cio is to creat

ent to Assignby the patiengh by an apphment 2a) an

with integratassociated w

process as suigned Assign

t sections is tachment 5a)achment 5b)

rmation state

de='10155-0']/x:

discharge sum

code is reprote and then s

io, the next snt accepting

plication in a nd blood pre

ted plausibiliwith the two

uch. This cannio applicatio

taken from a) together w).

ement (see a

entry/x:observat

mary into thing

duced in fullselect the su

step is to lin the documesingle proce

essure measu

ity and errorschemata ab

n be performon (C#, Ruby

a discharge sith the trans

also Attachm

tion[x:code/@cod

g types

l in Attachmemmary in th

k it with the ent in questioess, as illustraurement (Att

r handling arbove.

med in a varieon Rails, Jav

ummary alreformation st

ment 3) are s

de='84100007']">

ent 1. The fie HIS or DM

Assignio thinon. Multipleated by the stachment 2b

re shown in t

ety of ways, va). An exam

eady in use (tatement for

hown below

>

Page 47

rst step AS.

ng type thing

schema-b).

the code

but ple is

(North r HTML

w:


<xsl:variable name="EffectiveTime" select="/*/x:effectiveTime/@value"/> <xsl:element name="allergic-episode"> <xsl:apply-templates select="/*/x:effectiveTime"/> <xsl:apply-templates select="x:entryRelationship"/> <xsl:apply-templates select="x:value"/> </xsl:element> </xsl:template>  <xsl:template match="x:entryRelationship/x:observation[x:code/@code='84100007']/x:value"> <xsl:element name="name"> <xsl:element name="text"> <xsl:value-of select="@displayName"/> </xsl:element> </xsl:element> </xsl:template>  <xsl:template match="x:entry/x:observation[x:code/@code='84100007']/x:value"> <xsl:element name="reaction"> <xsl:element name="text"> <xsl:value-of select="@displayName"/> </xsl:element> </xsl:element> </xsl:template>

Blood pressure measurement:

 <xsl:template match="x:section[x:code/@code='8716-3']/x:entry/x:observation[x:code/@code='251076008']"> <xsl:variable name="EffectiveTime" select="x:effectiveTime/@value"/> <xsl:element name="blood-pressure"> <xsl:apply-templates select="x:effectiveTime"/> <xsl:apply-templates select="x:entryRelationship"/> <xsl:apply-templates se-lect="ancestor::x:section/x:entry/x:observation[x:code/@code='364075005'][x:effectiveTime/@value=$EffectiveTime]/x:value"/> <xsl:apply-templates se-lect="ancestor::x:section/x:entry/x:observation[x:code/@code='364074009'][x:effectiveTime/@value=$EffectiveTime]/x:value"/> </xsl:element> </xsl:template>  <xsl:template match="x:observation[x:code/@code='271649006']/x:value"> <xsl:element name="systolic"> <xsl:value-of select="@value"/> </xsl:element> </xsl:template>  <xsl:template match="x:observation[x:code/@code='271650006']/x:value"> <xsl:element name="diastolic"> <xsl:value-of select="@value"/> </xsl:element> </xsl:template>  <xsl:template match="x:observation[x:code/@code='364075005']/x:value"> <xsl:element name="pulse"> <xsl:value-of select="x:numerator/@value"/> </xsl:element> </xsl:template>  <xsl:template match="x:observation[x:code/@code='364074009']/x:value"> <xsl:element name="irregular-heartbeat"> <xsl:choose> <xsl:when test="@code='248649006'"> <xsl:text>false</xsl:text> </xsl:when> <xsl:otherwise> <xsl:text>true</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:element>


</xsl:template>

The following code serves to transform the time measurement:

 <xsl:template match="x:effectiveTime"> <xsl:element name="when"> <xsl:element name="date"> <xsl:element name="y"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'1'"/> <xsl:with-param name="Length" select="'4'"/> </xsl:call-template> </xsl:element> <xsl:element name="m"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'5'"/> </xsl:call-template> </xsl:element> <xsl:element name="d"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'7'"/> </xsl:call-template> </xsl:element> </xsl:element> <xsl:element name="time"> <xsl:element name="h"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'9'"/> </xsl:call-template> </xsl:element> <xsl:element name="m"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'11'"/> </xsl:call-template> </xsl:element> <xsl:element name="s"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'13'"/> </xsl:call-template> </xsl:element> <xsl:element name="f"> <xsl:call-template name="GetTimePart"> <xsl:with-param name="Value" select="@value"/> <xsl:with-param name="Start" select="'15'"/> </xsl:call-template> </xsl:element> </xsl:element> </xsl:element> </xsl:template> <xsl:template name="GetTimePart"> <xsl:param name="Value"/> <xsl:param name="Start"/> <xsl:param name="Length" select="'2'"/> <xsl:choose> <xsl:when test="normalize-space(substring($Value, $Start, $Length))!=''"> <xsl:value-of select="substring($Value, $Start, $Length)"/> </xsl:when> <xsl:otherwise> <xsl:text>0</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:template>


17.2 Linking Document Management and Archival Systems

In the German market, perspectives on exportable documents are shaped largely by the necessities of digital archiving. This is an advantage for using documents in Assignio, because the standard for-mats are also shareable.

Given the legal retention period – usually 30 years – document management formats have become established which are durable, non-proprietary and therefore interoperable. Since all makers of hos-pital information systems generate these formats with either their own or integrated third-party document management and archival systems, the formats are also available for export to Assignio. Even though by no means every hospital has introduced this procedure, they do all have an infor-mation system that can deliver these additional services.

An application of this nature can be produced and delivered by the following entities:

• Hospital information systems

• Document management and archival systems

• Specialized eHealth application providers

Accordingly, perhaps with some retrofitting, hospitals have the basic procedures enabling them to designate all archived documents – where feasible for selection – as ready for Assignio.

It is essential to note that Assignio does not act as a substitute for hospital archiving. Its focus is the patient, and it works with document copies. However, to enable views of valid documents sourced from medical facilities, hospital documents are verified by technical means and the results of this check are documented.

What has to be defined is a set of metadata which is dependent on the given situation in the hospi-tal. To enable data to be authenticated, information such the document ID from the producing or archiving system will need to be included (amongst other items). The following example record can be seen as the minimum:


• Patient ID from the HIS

• Document ID from the HIS/DMS

• First name

• Last name

• Date of birth

• Address

• Document type

• Author and signatory

• Result of signature validation

• …

The basic requirement is to make archival formats usable in Assignio, even though it must remain the goal to enable the use of structured data eventually. However there will always be important patient documents in hospital archives, and it is better to have these usable in image format than not at all. An image format is an important first step toward human interoperability – in other words to having readable documents. TIFF is the widespread legacy format, and the current standard format can be considered to be PDF/A. Pure PDF is not considered to have the requisite long-term stability and is also more vulnerable to malware.

German professional entities and associations such as www.gmds.de / www.vhitg.de give recom-mendations for the following durable standards, i.e. formats offering long-term stability:

• TIFF with or without electronic signature and timestamp

• PDF/A with or without electronic signature and timestamp

• JPG

In addition, the modern formats VHitG HL7 CDA Release 2 and possibly XAIP container as per BSI 031254 can serve as the basis for documents and signature information.

4BSI TR 03125

The XAIP containers are specified in the Technical Directive of BSI TR 03125 and required as archive containers. Since the TR does not have a normative character for the healthcare sector and in addition is still the subject of public discussion, the outcome is still pending. Processing payload data from XML-based containers is however also possible with Assignio.


Documents which are not assigned a signature by the HIS can be given a timestamp when they are exported, making it possible to check the validity of the document at a later date. Documents with a timestamp and/or a qualified electronic signature should go through the validation process before they are placed in Assignio. The result of the validation should be transferred with the document as PDF/A or XML.

The basic procedure is illustrated in Figures 6 and 7.

17.3 Drill Down HIS and DMAS: PDF/A as Shareable, Long-term Archival Format in HIS and DMAS

17.3.1 Basics of PDF/A-1 and PDF/A-2

The PDF format has an established track record with regard to long term stability and shareability. It is possible therefore to easily integrate TIFF documents together with their metadata from medical archives and systems into Assignio. TIFF is a de-facto industry standard, rather than a publicly speci-fied standard. The public standard for long-term archiving is PDF/A. This format is successively re-placing TIFF for new production.

Unlike pure image formats such as TIFF or JPEG, PDF is an object format which can comprise a range of object types, including text, images, fonts, graphics, signatures etc. It was developed with the aim of enabling hardcopy-equivalent rendition of the content across multiple platforms.

Being a platform to accompany the entire lifecycle of an individual, Assignio uses the standardized legacy documents. To ensure these legacy documents can continue to be used going forward, the present formats must follow standards. Therefore, for the transfer from HIS or DMAS to Assignio, the long-term archiving format PDF/A is advisable, as is the use of structured data in XML.

PDF/A offers – at least in limited form – the possibility of using contents and processing them further. In other words, bidirectional transformations are possible between CDA and PDF/A.

Today, PDF/A documents can be generated straight from both the HIS and DMAS. Rendition services are available on the market, meaning that it is not strictly necessary to roll out a document manage-ment and archival system in order to produce PDF/A and place these documents in Assignio.

By using PDF/A for document sharing in the health sector, multiple requirements are filled at one stroke; like the process itself, exported data and documents must be documented and archived for the long term. This requirement can be fulfilled with a document management and archival system, but there are other options for secure long-term document retention.

Vice versa, all hospitals which operate a clean archiving concept compliant with guidelines such as those of GMDS, etc, usually transform their documents to PDF/A prior to archiving and (optional)


electronic signature. For reasons of long-term stability, this is advisable even when the original for-mat is a CDA XML, the reason being that an additional file is produced.

At present, PDF/A is published and in use as ISO 19005 Part 1 Version PDF/A-1. The next version will be PDF/A-2, with publication due in 2011. Many document service providers have now integrated PDF/A-1, and preparations for PDF/A-2 are underway. Following this logic, producers are free to de-cide which version they work to, because the standardization logic ensures downwards compatibility. In other words, a PDF/A-1-compatible document is automatically also compliant with PDF/A-2.

In PDF/A-1 (and also A-2), various conformity levels are differentiated. PDF/A-1a (Level A) concerns semantic correctness and structure. It is not enough, for example in text documents, for just the vis-ual rendition of the text to be equivalent to the original. The semantic structures in the text must also be stored in PDF/A (for example headlines, paragraphs, captions etc). The idea behind this is open accessibility, by which it should be possible to have the content of the document read out. Beyond this, level 1a demands that each character must have a Unicode equivalent. A consequence of these requirements is that level 1a-compliant documents can only be generated from source documents which already exist in electronic form and which have the corresponding semantic structures.

PDF/A-1b (Level B) does not make these strict demands. The sole issue it addresses is visual integrity. PDF/A-1b is practicable and recommendable particularly when documents are obtained by digitizing hardcopy documents (scan to PDF/A), when documents are created by printer drivers, or when they are converted from semantically sparse source formats such as PDF or PostScript. The present mar-ket share of PDF/A-1b is way over 90%. What all PDF/A conformity levels have in common are the basic attributes of PDF/A such as:

• Integration of all fonts (or effective subsets) used in the document

• No active content such as JavaScripts or dynamic forms (XFA)

• No embedded binary content apart from images in formats (JBIG, TIFF/G4, JPEG)

• No encryption or access restrictions, or user rights and DRM

• Limited to functionality of PDF 1.4

• No levels and transparencies

• No compression methods which are subject to license such as LZW

Being totally devoid of active content, PDF/A-1 is also termed “electronic paper”. This eliminates the risk of malicious software, which frequently makes use of JavaScript exploits. However, to ensure compliance with PDF/A rules, it is advisable to conduct quality checks using validation tools.

The format also secures data consistency and offers methods for additional security measures: for example, the electronic signature can be used to secure the persistence of documents and check data integrity. As with normal PDF documents, the electronic signature can be integrated in PDF/A format. PDF/A has inherited this unique possibility through its origins in PDF 1.4.

PDF/A-1a is particularly suitable for generating accessible documents – of special significance for applications of the Assignio platform.

To distinguish it from a normal PDF file, a PDF/A-1 file has a metadata entry showing the conformity level with PDF/A. Validation tools must be used to determine whether a PDF/A file with this entry is in fact PDF/A compliant. The tools check structure and conformity.


Essentially, PDF/A-1 does not permit embedding of third-party files, in other words no other binary documents such as office, film or sound files can be integrated into a PDF/A-1 document. This is also valid for the standard PDF/A-2, due to be published shortly. It is not until PDF/A-3, currently under review, that there will be provisions for embedding third-party formats, provided they have a valid MIME tag.

PDF/A-1 therefore only supports the integration of metadata, i.e. data via the document itself. The best known metadata in a PDF/(A) document is probably author, creation date, creation program, title, subject and version. In a PDF 1.4 document, this metadata used to be hardwired into the docu-ment as basic attributes. PDF/A works with metadata in XMP (eXtensibleMetadataPlatform) format. Metadata is stored in PDF/A in an XML structure based on XMP schemata. As well as the numerous XMP schemata in the PDF/A standard, users can also create their own extensions and include any metadata of their choice in the PDF/A document. The drawback of this flexible approach is that ow-ing to the completeness principle of PDF/A, all custom-defined XMP schemata must be embedded with the rest of the data, in addition XMP schemata definitions and XMP data can be quite extensive and complex, even when they have only a relatively limited set of attributes. This can push up the size of a PDF/A document considerably. What is more, there are currently no tools with query and conclusion functions which can derive benefit from this semantic web-based rendition of metadata in XMP.

17.3.2 Outlook to PDF/A-2

As the PDF/A-2 standard is rolled forward in the first half of the year, the aim is to use as the basis the developments and standards which have appeared since publication of A-1 in 2005. PDF/A-1 was still based on the company standard PDF 1.4 by Adobe, whereas PDF/A-2 is now completely based on ISO32000-1, the ISO-standardized PDF format which emerged from PDF 1.7. Other new develop-ments are as follows (not an exclusive list):

• JPEG2000 image compression: along with JPEG image compression which was already sup-ported in A-1, the new format also permits JPEG2000, an image format which is now also ISO standardized. Particularly for digitizing (scan to PDF/A), this extension plays a key role, since it enables even higher compression rates, particularly with color images, while retaining the same quality as JPEG. In addition, JPEG 2000 permits both lossless and lossy compression.

• Levels: in version A-1, the use of levels was not permitted. Levels make it possible to inte-grate alternative content (such as multilingual content) or superimpose image captions. Their use is now permitted in A-2, an ability which users particularly in technical environments had been pushing for to assist conversion of CAD drawings to PDF/A. Without levels, it is frequently impos-sible to use converted drawings properly.

• Transparencies: another irritating restriction in A-1 was the inability to use transparencies – transparent graphic objects such as are common today in numerous publications, slide presenta-tions and graphics. Previously, objects of this type had to be flattened into a nontransparent im-age, which drove up the size of the resulting PDF/A document. This is not necessary in A-2.

• OpenType: In PDF/A-1 the use of open type fonts was not permitted, and fonts had to be converted to Type 1 or TrueType. In PDF/A-2 this font standard as per ISO/IEC 14496-22 is now explicitly permitted.


• Integration of PDF/A documents: as the first step toward integrating third-party files (see above), PDF/A-2 now permits PDF/A-1- and PDF/A-2 compliant documents to be embedded (but only these two types). Accordingly, it is now possible to build up a PDF/A-2 compliant “record”, a framework document in PDF/A-2 format that contains other PDF/A documents such as corre-spondence, scanned hardcopies, presentations etc. This construction enables individual docu-ment pages to be signed – a multipage PDF/A document can be broken down into single page documents and re-grouped in a PDF/A-2 container. The integrated PDF/A documents then each bear the signatures.

There are no changes in PDF/A-2 with regard to electronic signatures. As in PDF/A-1,, only PKCS#7-based signature containers are permitted alongside PKCS#1. The specification fails to include the ETSI specification on PAdES (PDF based Advanced electronic Signatures) which addresses issues of em-bedding re-signatures or archival-compliant signature containers.

17.3.3 Data in PDF/A Until the PDF/A-3 standard is published, a workaround is the sole way of integrating standard-compliant data into a PDF/A document where the data represents XML source documents or other-wise enriches the content, rather than being purely metadata. The workaround can be a private en-try in the main catalogue of the PDF/A structure which references the corresponding content stream. All the current PDF/A validation programs ignore entries of this type, provided they do not use any forbidden constructions. The ISO standard does not expressly forbid this type of embedding.

However, to make things more transparent, an XMP extension scheme (PDF/A Extension Scheme) should be defined to hold information about the embedded data as well as the name of the (private) catalogue entry. This would enable third-party programs to retrieve information about the nature and location of the payload data.

This type of data embedding is particularly suitable for text and therefore XML data.

17.3.4 Signatures in PDF/A

Since PDF 1.3, this document format has permitted electronic signatures to be integrated in files. This functionality is based on PKCS#7-compliant signature containers, similar to storing associated signa-tures in P7S files. Apart from the signature, containers of this type contain certificates, certificate chains, signature attributes and possibly also timestamps.

The external services which verify signatures must be able to handle the usual formats. The growing number of medical facilities in Germany which already work with electronic signatures in routine practice, usually deliver associated or integrated PKCS#7 files in PDF/A or in future also XML signa-tures.

Although it was initially possible to sign only selected objects in a PDF structure, the entire docu-ments is now included – excepting of course for the signature container itself. If there are multiple


signatures, the additional ones are simply appended as new document versions to the existing PDF. This approach is also a fundamental characteristic of PDF. The integrated electronic signatures essen-tially comply with PDF/A rules; the only limitations concern visible graphic representations with which a signed document is also indicated as being signed to the user. To make this possible, the signature fonts and also color space definitions must be integrated into the document. This is not relevant for invisible signatures.


17.3.5 PDF/A and CDA Transformation

The transformation of CDA documents to PDF/A is essentially equivalent to the conversion of XML documents to a human readable, page- and document-oriented rendition. As a rule, XLS transfor-mations are used which convert the XML structure of a CDA-conformant document to either an HTML or (via XSL-FO) directly to a PDF document. By selecting appropriate XSL transformation state-ments, it is possible to obtain a CDA document with the visual layout of choice. The goal is always to obtain a rendition which has as much visual clarity is possible, and it is readable as possible for the end user – the doctor, patient etc.

In the next step, the HTML or PDF document is converted to a validated PDF/A document. The visual presentation is equivalent to the source HTML or PDF. All fonts and graphics in supported formats are included. In a final step, the CDA XML structure is embedded in the PDF/A document as “pay-load” information. A predefined and embedded PDF/A XMP extension scheme indicates to every PDF interpreter the payload data content and the location in the PDF/A file.

Finally, the PDF/A-CDA document can be assigned one or more electronic signatures which are also integrated into the document. If the CDA XML structure already has a XMLDSig signature, this is re-tained following embedding in the PDF/A document and can be re-validated when the payload data is extracted later.

HIS2Assi

Figure 13

Figure 13:

The beneforming

• The dovisual

• This is ble con

• All resment,

• There

• Accessport in

• If nece

The PDF/

Figure 14: ignio

3 illustrates

Transformatio

efit of a PDFto standards

ocument canpresentation

a static, frozntent, and su

ources requiensuring it c

are definitel

s to the paylonto platforms

essary, the X

/A documen

Transformatio

this sequenc

n of HL7 CDA R

/A containers.

n be viewed an across all p

zen documenuch changes

ired to rendecan be repro

ly no active c

oad structurs such as Ass

SL styleshee

nt can also be

n of PDF/A to r

ce:

Release 2 to PDF

r of this type

and printed iplatforms.

nt. It is not pare identifia

er the documduced at any

contents, me

e is possible signio or HIS,

t can also be

e transforme

readable XML d

F/A

e is that it can

in original qu

possible withable.

ment contenty time, even

eaning there

at any time,, and evalua

e embedded

ed back (or fo

documents

n satisfy a ra

uality with a

h normal mea

t – fonts, ima long into th

is practically

, enabling aution of conte

in the docum

orward) to X

nge of dema

ny PDF viewe

ans to make

ages etc – are future.

y no danger

utomated proent in CDA st

ment for ren

XML, as show

ands, while a

er. There is a

changes to t

re part of the

of malware.

ocessing, wittructures.

ndition.

wn in Figure 1

Page 58

also con-

a unified

the visi-

e docu-

th im-

14:

HIS2Assi

In this wmation tstage. Acprocesse

18 Cu

Based onand serv

ignio

way, it is possto validate eccordingly, Pes, offering (

stom Prog

n the descripvices which c

• ChecFormpolic

• Chec

• Chec

• Verif

• Validrors

sible to use mlectronic sign

PDF/A is not interactive)

gramming

ption of the wcan be provid

cking docummat etc.) for cies or comp

cking docum

cking TIFF fo

fying that ge

dating integrand excepti

metadata fornatures, anda static formfallback mec

g/Opportu

workflows usded by Assig

ment formats malware, us

patible secon

ments genera

rmat docum

enerated XM

rity of documons.

r transferringd to extract tmat. As descrchanisms for

unities for

se cases, belnio-accredite

(proprietarysing tools andndary service

ted in HL7 C

ments for ma

ML document

ments with e

g PDF/A validhis data withibed, it perm

r various doc

r an Appli

ow are examed service pr

y structures, d procedure

es.

CDA Release 3

lware.

s are well fo

lectronic sig

dation historh the clinical

mits extensiveument conve

cation Ma

mples of somroviders:

Microsoft® Ws already ava

3 or PDF/A fo

rmed and co

natures, incl

ries and othe content at ae transformaersions.

arket

me of the app

Word, Rich Tailable in IT s

ormat for m

omply with s

uding handl

Page 59

er infor-a later ation

plications

Text security

alware.

tandards

ing er-


• Validating integrity of documents with qualified timestamps, including handling of errors and exceptions.

• Assignio connector application for standard enterprise service buses.

• Calendar function for medical appointments.

• …

These applications can either be part of the hospital information system or act as an middleware between this system and Assignio. Assignio is thus kept completely free of dynamic applications and services.

Services are coded at the code level appropriate for Microsoft-based structures (e.g. .NET). The SDK is based on C#.


19 Security of Data and Documents, Validity and External Services

19.1 Verifying Signatures and Freedom from Malware

Assignio does not change documents and data.

The security required on a trustworthy eHealth platform means that integrity and validity of data and documents must be checked and verified to prevent malicious software from entering the system. In addition, the reduction of the number of document formats makes for less technical risk.

Therefore, before data and documents are placed in Assignio, a range of checks must be performed by internal or external services. These can be organized into two general categories:

1. Services to protect against documents being manipulated by malicious software, in order to maintain security of the platform overall. This check is performed at hospital level, before da-ta is transferred to Assignio.

2. Services to check the authenticity and integrity of each individual document when it is placed in Assignio, and to provide legally compliant documentation of the integrity, taking into ac-count shareability. This check is also conducted at hospital level.


Figure 20: The external services


The validity check through electronic signatures is an essential constituent in processing secure, standard medical documents and data.

There is only a small (but growing) number of clinics using the qualified electronic signature (QES) in routine practice, but it is particularly the innovative clinics from the University, private and in part the public sectors which are successfully paving the way to avoiding paper with QES.

A electronic signature contains relevant information concerning the trusted status of the medical information: a valid, qualified electronic signature or a qualified timestamp give secure information on the origin, correctness and usability of medical documents and the data they contain. Being so authoritative, the electronic signature should therefore not be ignored – rather, it should be validat-ed and the result of this check should be documented.

A verification log should document whether a document had a electronic signature at the time it was placed in Assignio.

A document without a valid signature is however not rejected. Instead it is treated like an unsigned document. Assignio does therefore not make it mandatory for data and documents to have a signa-ture. Rather, the system making the transfer decides whether documents shall be signed or not, and this system ultimately also decides on the trusted status of the document.

There is explicitly no “must” about creating a qualified timestamp when a document enters the As-signio system. Even if a electronic signature “pales” over time, meaning a fresh signature is required later if a document is to retain its evidential function, this has no retrospective impact on the validity at the time of import into Assignio. Therefore, Assignio does not work with re-signing mechanisms, but external services can offer long term archival with legally compliant evidential function. These archive services are available both in Germany and internationally on the market.

If we consider the path taken by documents and data from the hospital information system to As-signio, the following requirement emerges if use is to be made of the intrinsic value of a given signa-ture.


Intermediary validation services should perform the following:

• Perform a legally compliant check that the document originates from an authorized system

• Document the results of the signature and timestamp validity check before transfer to As-signio

• Verify the conformity of document formats

• Verify freedom from viruses and malware

• Document the validation log and transfer to Assignio

• Ensure shareability of data placed in Assignio

The HIS signs and exports and provides a validation protocol (OCSP query about the signature, etc.) via middleware, which delivers timestamp and validation services between the supplying HIS applica-tion and the receiving platform Assignio.

The process of validating signatures and timestamps is shown in Figure 20.

Assignio does not explicitly assume the function of long-term storage of documents or cryptograph-ically signed documents. However, the special requirements to be met by long-term stable infor-mation packages/documents in Germany means that formats and packages are specified that enable Assignio to support communication and interoperability. These are signed PDF/A and CDA XML pack-ages.

Current political and technical developments are increasingly shifting the focus in international mal-ware. Apart from mass attacks, plus an increasing number of targeted attacks on specific groups, individuals and even special technical areas, there is also always the risk that an already created doc-ument, such as a discharge summary, carries with it a certain amount of potentially harmful “rou-tines”, which when executed work to the detriment of the facilities or person where they are activat-ed.

This “payload” can be targeted, i.e. be aimed at an individual, or be part of a general “pollution” of documents with no particular individual as a target.

Regardless, it is important to apply the basic security rules set down in security policies of medical practices or hospitals with respect to checking files. In some cases there will be no security policy, or the requisite tools to implement it will fall short of the mark or are missing altogether. This offers hardware and software service providers the opportunity to custom-program tools for these clients.

Consequently, it is necessary to introduce multiple levels of security in checking and validating doc-uments at various points:

• On the side creating the discharge summary and other documents or objects (action level: Sending HIS)


Meaning: malware check before document creation, then document production in HL7 CDA Release 2 or PDF/A format, electronic signature and final validation of the generated docu-ment (possibly by techniques such as hash-value, checksums etc.).

• Documents forwarded from Assignio to other facilities (e.g. transfer from Assignio to HIS; ac-tion level: Receiving HIS)

• Meaning: Validation of the electronic signature of a document to detect changes, possibly al-so using other techniques such as hash-value, checksum, etc. If the document is converted, it is essential to check for malware.

19.2 IT Security as per ISO 27001 / 27799 etc.

The description of security services such as virus scanning, etc. provides for the security of users of approved Assignio applications. The clinic manages the requirements for secure documents and data using a security concept according to the recommendations listed here. This is not a MUST, but a CAN. Possible overall concepts for medical facilities are ISO 27001, ISO 27 799, etc., ensuring security is not addressed in isolation in separate process chains. However, this is not a MUST for the use of Assignio, because the relevant processes are secured by (de) central services.

The necessary security concepts today embrace the various requirements that must be met by medi-cal facilities, even without Assignio in the equation.

19.3 Risk Management

Despite having the various instances to verify relevant documents before and after transformation to the formats as described, the question arises of what happens in the event these mechanisms fail or changes are identified that prevent the data transfer to Assignio.

Key tools and methods for this purpose are provided by procedures of ISO 27001 and also by BSI, especially taking into account ITIL v2 and v3.

In such cases, it is of key importance to establish and operate an asset-based risk management sys-tem (RMS). This can, for example, be used as a special part of ISO 27001 or in subsections such as IT-based implementation of ITIL v2 or v3.


20 Other Technologies and Standards – Relationship with Assignio

20.1 Example: Microsoft®: HIS- SharePoint Server - Assignio

Various vendors of hospital information systems and document management systems also offer inte-gration with SharePoint. Selected documents in Microsoft ® SharePoint servers are provided in Web Parts. As a rule, two variants are selected:

1. Microsoft ® SharePoint Server complements the central document management and hospital in-formation system for special applications (portals, quality management, etc.) and is connected via an interface.

2. Microsoft ® SharePoint Server is enriched through document management systems with features which fulfill extensive requirements with respect to the Document Life Cycle. This enriches Share-Point to the extent that it can also act as the central DMS platform in a facility.

The processing of documents for management in Microsoft ® SharePoint Server at the same time prepares them for use in Assignio.

20.2 IHE Integration

Predominantly active in the international arena5, less so in Germany6, the initiative Integrating the Healthcare Enterprise (IHE) is a unit founded by specialists with the aim of achieving maximum in-teroperability between different IT systems in healthcare. This interoperability, at least in Germany, is pioneering the integration of medical images and graphics (e.g. DICOM) and is fully equivalent to the international level. The issue of IHE is still rather insignificant in the context of document ex-change, with the exception of direct implementation in the electronic case file (eFA)7. By way of comparison, Austria and Switzerland are already more advanced. However, it is conceivable there will be greater emphasis in the coming years as European cooperation expands.

IHE Cross Enterprise Document Sharing (XDS) offers a decisive perspective, and will set the trajecto-ry in terms of technology for interoperability in document exchange.

For the integration of a VHitG discharge summary, for example, it means that regardless of the re-lease version of the CDA body (Release 1 of 2000, Release 2 of 2005, or future releases and changes),

5www.ihe.net

6www.ihe-d.de

7www.fallakte.de and www.efallakte.de


the medical payload can always be transferred with the document. Differences mainly concern the CDA headers, as it is here that most of the internal changes to metadata play an important role in implementing changes with relation to one another. The outcome is maximum compatibility be-tween the VHitG discharge summary, IHE transformation platform and (as described below) the elec-tronic case file.

The international websites of the IHE provides the technical background8, enabling transformation and transaction statements to be implemented relatively easily. Volume 2 of the technical descrip-tions, and Chapter 3.1.4ff are of particular interest. The standards referenced are ebRIM (OASIS / ebXML Registry Information Model v3.0) and EbRS (OASIS / ebXML Registry Services Specifications v3. 0). These pertain to all infrastructure profiles, but document in particular the statements in the context of XDS.

20.3 Integration of www.fallakte.de

In contrast to the “comprehensive” HIS, and lifelong patient/healthcare files (“continuity of care rec-ord ” / CCR), the electronic case file (eFA) is a direct view of a specific medical case. The eFA is also tied to a specific purpose: the use of the information is permitted only for the purposes of treatment as agreed with the patient, but can be communicated fully among clinicians.

The transfer of eFA data to other contexts such as Assignio is therefore always done by the doctor, with the express consent of the patient. In this workflow, the doctor must transfer a medical docu-ment from the eFA to the HIS and then, at the request of the patient, transfer it from the HIS to As-signio. This is all based on the patient's right of access to his treatment records – a service view of the patient as a client. The patient’s right of access can be satisfied by this form of copying.

Currently, however, the only legal and proper way is this: when the clinic and patient wish the doc-ument to be usable in Assignio, the document must go via the primary systems, and then via a down-stream process. From the perspective of the connector described here, this is therefore simply a document that is placed in Assignio via HIS2Assignio.

In addition, in terms of the political context there are two key aspects to mention:

• Within the VHitG, the eFA is being established as normal functionality in the standard solu-tions of the IT industry.

• At gematik, integration of eFA is a value-added service in the ICT infrastructure (at the level of a migration project).

At present the Munich City Hospital is integrating eFA into its hospital information systems using IHE in the manner described. The certificates of the eFA 1.2 specification relate to compatibility of cli-ents, services, and peer-to-peer connections.

8http://www.ihe.net/Technical_Framework/index.cfm#IT


20.4 Semantic Interoperability and Terminology Server

Apart from a purely technical standardization of formats enabling direct communication between proprietary, heterogeneous systems, semantic standardization is also necessary to create a common understanding of concepts and work processes across linguistic and logical barriers.

Terminology servers are used in medicine to ensure that each document has a structure and content that complies with current terminology (e.g. ulna fracture, venous bleeding, aneurysm, Hashimoto's thyroiditis, etc.), classifications (e.g. ICD -10, ICD-O, OPS, SNOMED CT, LOINC, etc.) and other stand-ards or semi-standards (such as the classical structure of the discharge summary). These terminolo-gies are made machine-readable for application systems (and users) by deploying a terminology server (an example of a rendition service).

It is on the side of the HIS that these systems have their most important function: to homogenize and harmonize medical terminology and classifications so as to forge a common, clear and unambiguous terminology understood by all healthcare professionals. Terminology servers are also able to create and maintain a custom dictionary of linguistic or strategic dialects (e.g. deep anterior rectum resec-tion) and associated abbreviations, which are not found within typical classifications, and then apply a transformation rule to convert this terminology to a valid procedure (e.g. OPS-Code 5-484.55).

Terminology servers are not part of the task remit of Assignio. They are one level before Assignio, but are an important prerequisite for turning medical jargon into valid HIS terminology from the outset, and using this taxonomy as the basis for transferring discharge summaries and other information to Assignio.

What is also important in this context is the specific versioning of the individual classifications in rela-tion to one another, and their specific documentation, as required, for example, in terminological description of malignant skin diseases according to the ICD-O. The coding of these versions can be carried and stored in separate metadata, or be communicated in an XML log file when the document is transferred to Assignio.

20.5 Differentiation from Formats such as XLS, CSV etc.

In producing information in medicine, the ongoing problem in daily practice is that often no regard is paid to the existing standards that can serve as a basis for creating documents or objects, and nor is the relevance of often newly emerging data structures sufficiently thought through. The outcome is that these individual information units or entities often end up as a conglomerate that at best can only be understood by the people who created it. However, downstream users who should or must get to grips will the information will not understand what it is about.


It makes little sense to integrate XLS, CSV, TXT documents, etc. into the workflow discussed here unless – because they are important and cannot be omitted – they are first converted to a useful format such as PDF/A or CDA XML and possibly digitally signed.

In the interest of homogenizing and harmonizing medical documents, it makes sense to limit the range of available formats. Restricting use to formats and industry standards such as HL7 CDA Re-lease 2 and PDF/A is an essential step to achieving the desired semantic interoperability.

20.6 DICOM

Basically Assignio is technically suitable for processing DICOM and JPEG2000. Since processing and delivery of diagnostic-quality images is not the primary aim, images should be placed in the platform in JPG format.

However, if specific use cases require the use of DICOM, HealthVault is designed with the technical means to handle this. Alternatively, a DICOM file or entire DICOM Worklist can also be included in a VHitG discharge summary and be transferred it to Assignio. Given the usual size of DICOM objects, this approach is not particularly feasible, so it is advisable to create smaller JPG files and incorporate them into the transfer.

20.7 Communication Server / Integration Server

In both medical and non-medical environments, the primary purpose of communication servers is to make available medical information between one or more primary systems and the related subsys-tems. The server carries out transparent conversions between the various information formats for the practical users of this information.

Since there are frequently different versions, dialects, and above all version levels of medical infor-mation, integration servers have the function of homologizing and updating individual statuses to the latest status with generally recognized validity.

Primary and secondary transformation processes following receipt of an HL7 message from a com-munication server (such as HL7 to HL7 CDA Release 2 or PDF/A) can in turn generate DMAS-appropriate documents and objects, preventing a break in the cycle of continuity of the HL7 CDA Release 2 or PDF/A compliant data transfer to Assignio.


21 Concluding Remarks

Assignio offers many opportunities for managing information and documents over the lifetime of an individual. Clinically valid data is made accessible by the methods described in this paper, with the result that it is this clinical information which forms the basis of a health platform. The platform of-fers extensive opportunities for placing additional data in the account or for using this data in treat-ment. Applications available now or in the future can address different use cases. Data has a differ-ent objective and subjective relevance, with different grades of content and often ephemeral rele-vance. To make all these distinctions available for individuals to use, the platform must offer various trust and security levels. Having confidence in the validity of information is particularly relevant when a platform is not just managing the fitness data of a largely healthy person but also complex, multi-morbid conditions of the elderly. Confidence in information validity is an important foundation, and individuals now and in the future are entitled to have this information from medical systems made available.

HIS2Assignio is an essential component in the use of valid medical data with the participation of indi-viduals – for their lifetimes and their health.


22 List of Attachments

Attachment 1: Example – VhitG discharge summary

Attachment 2a: Microsoft® HealthVaultTM XML schemata for allergic episode

Attachment 2b: Microsoft® HealthVaultTM XML schemata for blood pressure measurement

Attachment 3: Transformation example for attachments 1-2

Attachment 4: Console program (C#) for transformation. Note: this attachment contains the files specified on page 46 of this paper. The files contain an XML transformation statement including the source code of the executable program. For test purposes, it is sufficient to copy file Attachment-sHIS2Assignio.zip into a separate subfolder and unpack it. The executable Attachment-4.exe carries out the XML transformation of the VhitG discharge summary to individual thing types (blood pres-sure and allergic episode). The XML file is specified as ClinicalDocument.xml. Note that the executa-ble is C#-source code which for demo purposes just shows the simplicity of the transformation pro-cess.

Attachment 5a: VHitG discharge summary of North Rhine Doctors’ Association

Attachment 5b: XML-HTML transformation statement for 5a

AttachmentsHIS2Assignio.zip

Date post:	19-Mar-2022
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times