E-ARK Content Information Type Specification for Patient Medical Records

Preface

I. Aim of the Specification

This document is one of several related specifications which aim to provide a common set of usage descriptions of international standards for packaging digital information for archiving purposes. These specifications are based on common, international standards for transmitting, describing and preserving digital data. They also utilise the Reference Model for an Open Archival Information System (OAIS), which has Information Packages as its foundation. Familiarity with the core functional entities of OAIS is a prerequisite for understanding the specifications.

The specifications are designed to help data creators, software developers, and digital archives to tackle the challenge of short-, medium- and long-term data management and reuse in a sustainable, authentic, cost-efficient, manageable and interoperable way. A visualisation of the current specification network can be seen here:

Figure 1: Diagram showing E-ARK specification dependency hierarchy. Note that the image only shows a selection of the published CITS and isn’t an exhaustive list.

Overview of the E-ARK Specifications

Common Specification for Information Packages (E-ARK CSIP)

This document introduces the concept of a Common Specification for Information Packages (CSIP). The main purposes of CSIP are to:

• Establish a common understanding of the requirements which need to be met to achieve interoperability of Information Packages.
• Establish a common base for the development of more specific Information Package definitions and tools within the digital preservation community.
• Propose the details of an XML-based implementation of the requirements using, to the largest possible extent, standards which are widely used in international digital preservation.

Ultimately the goal of the Common Specification is to reach a level of interoperability between all Information Packages so that tools implementing the Common Specification can be adopted by institutions without the need for further modifications or adaptations.

Specification for Submission Information Packages (E-ARK SIP)

The main aims of this specification are to:

• Define a general structure for a Submission Information Package format suitable for a wide variety of archival scenarios, such as document and image collections, databases or geospatial data.
• Enhance interoperability between Producers and Archives.
• Recommend best practices regarding the structure, content and metadata of Submission Information Packages.

Specification for Archival Information Packages (E-ARK AIP)

The main aims of this specification are to:

• Define a generic structure of the AIP format suitable for a wide variety of data types, such as document and image collections, archival records, databases or geospatial data.
• Recommend a set of metadata related to the structural and the preservation aspects of the AIP as implemented by the eArchiving Reference Implementation (earkweb).
• Ensure the format is suitable to store large quantities of data.

Specification for Dissemination Information Packages (E-ARK DIP)

The main aims of this specification are to:

• Define a generic structure of the DIP format suitable for a wide variety of archival records, such as document and image collections, databases or geographical data.
• Recommend a set of metadata related to the structural and access aspects of the DIP.

Content Information Type Specifications (E-ARK CITS)

The main aim of a Content Information Type Specification (CITS) is to:

• Define, in technical terms, how data and metadata must be formatted and placed within a CSIP Information Package to achieve interoperability in exchanging specific Content Information.

The number of possible Content Information Type Specifications is unlimited. For a list of existing Content Information Type Specifications see the DILCIS Board webpage (DILCIS Board, http://dilcis.eu/).

II. Organisational Support

This specification is maintained by the Digital Information LifeCycle Interoperability Standards Board (DILCIS Board, http://dilcis.eu/). The role of the DILCIS Board is to enhance and maintain the draft specifications developed in the European Archival Records and Knowledge Preservation Project (E-ARK project, http://eark-project.com/), which concluded in January 2017. The Board consists of eight members, but no restriction is placed on the number of participants taking part in the work. All Board documents and specifications are stored in GitHub (https://github.com/DILCISBoard/), while published versions are made available on the Board webpage. The DILCIS Board have been responsible for providing the core specifications to the Connecting Europe Facility eArchiving Building Block https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eArchiving/.

III. Authors & Revision History

A full list of contributors to this specification, as well as the revision history, can be found in the Postface material.

CITS eHealth1

E-ARK Content Information Type Specification for Patient Medical Records

Version: 2.0.1

Date: 2024-12-13

1. Introduction
1.1. Purpose
1.2. Scope
1.2.1. Extracting data in a relational database structure
1.2.2. Extracting data and metadata as aggregations of patient medical records
1.3. Layered Data Model
2. Specification
2.1. CITS eHealth1 Specification Requirements Structure
2.2. Principles
2.2.1. Principle 1– use of existing standards
2.2.2. Principle 2 – the Complete Patient Medical Record and Patient centricity
2.2.3. Principle 3 – ability to create cohorts for research purposes
2.2.4. Principle 4 – support for born digital and digitised records
2.2.5. Principle 5 – bulk submission of Patient records from producers
2.3. Standards
2.4. Data Structure and Aggregations
2.4.1. Case Structure and Data Aggregation
2.4.2. Using the eHealth1 specification together with the Common Specification for Information Packages (CSIP)
2.4.3. Placement of data in an eHealth1 Information Package
2.5. General Requirements
3. Implementation
3.1. Use of METS in eHealth1
3.1.1. Root METS File
3.1.1.1. Root METS root element
3.1.1.2. Root METS header element (element metsHdr)
3.1.1.3. Root METS descriptive metadata section (element dmdSec)
3.1.1.4. Root METS administrative metadata section (element amdSec)
3.1.1.5. Root METS file section (element fileSec)
3.1.1.6. Root METS structural map (element structMap)
3.1.2. Representation METS File
3.1.2.1. Representation METS root element
3.1.2.2. Representation METS header element (element metsHdr)
3.1.2.3. Representation METS descriptive metadata section (element dmdSec)
3.1.2.4. Representation METS administrative metadata section (element amdSec)
3.1.2.5. Representation METS structural map (structMap element)
3.2. Use of Descriptive Metadata in eHealth1
3.2.1. Archival Information
3.2.2. Patient Identifiers
3.2.3. Patient Personal Information
3.2.4. Patient Clinical Information
4. Deprecated Requirements in eHealth1
5. Glossary
6. Appendices
6.1. Appendix A: CITS eHealth1 Information Package METS Examples
6.1.1. Example 1: Example of a whole representation METS document describing a submission information package representation following CITS eHealth1 (citsehpj_v2_0).
6.1.2. Example 2: Example of a whole METS document describing a submission information package following CITS eHealth1 (citsehpj_v2_0).
6.2. Appendix B: External Schema
6.2.1. E-ARK SIP METS Extension
6.2.2. E-ARK CSIP METS Extension
6.3. Appendix C: External Vocabularies
6.3.1. OAIS Package Type
6.3.2. IANA media types
6.3.3. Content information type specification
6.3.4. File group names
6.3.5. Structural map label
6.3.6. Structural map typing
6.3.7. Note type
6.3.8. Content Category
6.3.9. Package Status
6.3.10. Alternative record ID's
6.3.11. Structural map divisions labels in eHealth1
6.3.12. dmdSec status
6.4. Appendix D: E-ARK CITS eHealth1 Metadata Requirements
6.4.1. E-ARK eHealth1 representation METS Profile 2.0.1 (citsehpj_v2_0) Requirements
6.4.2. E-ARK eHealth1 root METS Profile 2.0.1 (citsehpj_v2_0) Requirements

1. Introduction

1.1. Purpose

The purpose of this document is to describe the Content Information Type Specification (CITS) for Patient Medical Records (eHealth1). This specification is supported by METS profiles for the Root and Representation METS files and an accompanying Guideline document.

1.2. Scope

This specification makes the following assumptions:

• A business case for the creation of an eHealth archive includes the incorporation of a backlog of physical and digital patient records.
• An eHealth archive concerns the Complete Patient Medical Records for patients within the jurisdiction. Note that the term ‘jurisdiction’ does not imply that a Central Health Archive must be at a national or federal level. Many health administrations are organised at a state or region level, and the specification is equally valid for this scenario. Note also that there are significant potential benefits for the use of the standard for archiving of Patient Medical Records if complied with by all regional administrations within a federation. This can also apply to environments where there are private healthcare providers, and a Central Health Archive is being created by a controlling administration.
• The use cases considered by the specification for an eHealth archive are described in the accompanying Guideline.

There are two options for extracting patient records from an EMR or EHR system which can be dependent to a certain extent on the source system data structure:

1.2.1. Extracting data in a relational database structure

If the structure of the source EHR/EMR system is wholly a relational database, then the extraction of selected records can be made into a long-term database preservation format (SIARD) that preserves the properties of the database such that the data can be imported into a relational database management system (RDBMS) at the time of access. Access can happen through database queries or a search field.

Further information on the limitations of this approach, particularly for the use cases behind the eHealth1 CITS is given in the accompanying Guideline.

The SIARD specification, together with a Content Information Type Specification for SIARD, represents the SIP profile for the relational databases content type. More information can be found at https://dilcis.eu/content-types/siard.

Extractions can be made from such wholly relational database systems programmatically that create the aggregated structure required for eHealth1 and as seen in traditional EMR systems and physical Patient Record archives. For the use cases described in this Content Information Specification it is recommended that this approach is followed.

1.2.2. Extracting data and metadata as aggregations of patient medical records

Digitisation of physical Patient Medical Records or extraction of electronic records from more traditional EMR systems produces a case type structure of files and accompanying metadata as described in the Guideline. Being extracted in this manner makes them directly accessible for validation, data management, indexing and searching. The structured semantic metadata description is explicit rather than hidden inside an RDBMS. This methodology also supports the incremental extraction of records over time for submission to the Archive and in addition:

• Records from different sources can be merged (complete Patient Medical Records can be synthesised from multiple submissions)
• Search and access is possible across all records and sources
• Records can be managed individually and uniformly
• The original EMR/EHR system software does not need to be licensed or preserved

This specification considers this particular extraction method within the context of the use cases as described in the Guideline.

1.3. Layered Data Model

This section introduces the role of the CITS eHealth1 and its dependencies on the basic structures of the Information Package.

This specification is created based on the requirements of the Common Specification for Information Packages (CSIP), the specification for Submission Information Packages (E-ARK SIP) and the specification for Archival Information Packages (E-ARK AIP). To fully understand its requirements, we highly recommend that users review the requirements and the terminology of the source documents, before using this specification.

The data model structure is based on a layered approach for information package definitions Figure 2. The Common Specification for Information Packages (CSIP) forms the outermost layer. The general SIP, AIP and DIP specifications add respectively, submission, archiving and dissemination information to the CSIP specification. The third layer of the model represents specific content information type specifications, such as this CITS eHealth1 specification. Additional layers for business-specific specifications and local variant implementations of any specification can be added to suit the needs of the organisation.

Figure 2: Data Model Structure

Every level in the data model structure inherits metadata entities and elements from the higher levels. In order to increase adoption, a flexible schema has been developed. This will allow for extension points where the schema in each layer can be extended to accommodate additional information on the next specific layer until, finally, the local implementation can add specific entities or metadata elements to satisfy specific local needs. Extension points can be implemented by:

Embedding foreign extension schemas (in the same way as supported by METS [http://www.loc.gov/standards/mets/] and PREMIS [http://www.loc.gov/standards/premis/]). These both support increasing the granularity of existing metadata elements by using more detailed data structures as well as adding new types of metadata.

Substituting metadata schemas for standards more appropriate for the local implementation.

The structure allows the addition of more detailed requirements for metadata entities, for example, by:

• Increasing the granularity of metadata elements by using more detailed data structures, or
• Adding local controlled vocabularies.
• For consistency, design principles are reused between layers as much as possible.

2. Specification

2.1. CITS eHealth1 Specification Requirements Structure

The Content Information Type Specification for Patient Medical Records (CITS eHealth1) aims to define the necessary elements required to preserve the accessibility and authenticity of Patient Medical Records over time and across changing technical environments. The specification elevates the level (and adjusts the cardinality) of some of the requirements set out in the Common Specification (CSIP) and package specifications (namely SIP) and adds new requirements for the package structure, descriptive metadata and accompanying METS files. The specification sets out general principles that underpin the specific requirements. Further context for the requirements and principles can be found in the accompanying Guideline to this document.

2.2. Principles

2.2.1. Principle 1– use of existing standards

Wherever possible the eHealth1 specification encourages the use of existing international specifications for patient administrative, clinical, diagnostics, medication information and vocabularies for diseases, conditions and treatments.

2.2.2. Principle 2 – the Complete Patient Medical Record and Patient centricity

CITS eHealth1 supports the creation of a centralised (national or regional) health archive of Complete Patient Medical Records, where the intention is to make data available to next of kin and should contain as much of the original data from source systems as possible. Data is organised to be patient centric and so access to a complete record from multiple submissions is possible.

2.2.3. Principle 3 – ability to create cohorts for research purposes

CITS eHealth1 supports the creation of a centralised (national or regional) health archive of Complete Patient Medical Records, where the intention is to make data available to researchers and should allow the creation of search databases and indexes based on key patient demographic and clinical data.

2.2.4. Principle 4 – support for born digital and digitised records

The specifaction allows for data submitted by producers (or generated at the archive) to be extractions from Electronic Record Management (EMR) or Electronic Health Record (EHR) systems or to be data generated through digitisation of physical records.

2.2.5. Principle 5 – bulk submission of Patient records from producers

Based on the principals above, the intellectual content of archival information packages (AIPs) in a health archive will most likely be limited to data about a single Patient. However, the specification recognises that submissions are likely to be made from healthcare providers on a batch basis on a regular schedule and the submission format should allow inclusion of multiple Patient records. Processes at the archive can then parse submission collections into individual patient SIPs and ingest into the archive such as to create individual patient AIPs.

2.3. Standards

Controlled vocabularies and coding provide a standardised way for the unambiguous recording of health data. Most EMR and all EHR systems will hold coded data concerning Patient Cases that can be extracted as metadata for the Patient Medical Record and will use international standard vocabularies such as ICD or SNOMED. Data can be recorded in standardised (such as ISO 13606 or FHIR) formats or to a local format which is specified by the health archive and referenced within a Submission Agreement. Background information on eHealth standards such as ISO 13606, FHIR, ICD and SNOMED is given in the Guideline.

2.4. Data Structure and Aggregations

2.4.1. Case Structure and Data Aggregation

The names of aggregation levels within an archive and represented within an archival package (IP) will depend on the agreements between data producers (Creators) and archives. EAD3 has defined a set of values (class, collection, file, fonds, item, otherlevel, recordgrp, series, subfonds, subgrp, subseries) for that purpose, and it allows other values to be used in addition if they are defined as “otherlevel”. However, even though the aggregation levels in this context could be described in this way, the EAD template for archival description is considered unsuitable for describing the aggregations in a Patient Health Archive but may be used for general archival information Implementation.

A Central Patient Health Archive has a single purpose and may be instituted as a stand-alone entity or as a sub-entity within a larger institution (e.g. National Archive or Health Authority). The overall aggregation of a health archive is therefore implicit (it is an aggregation of Patient Medical Records), and further aggregation levels must be defined that suit the use cases for navigation within the archive and for the way in which the archive is populated.

Patient Medical Records will be submitted to a Central Health Archive either when a patient is known to have died or after a period of time when it is not feasible that a patient is still alive (determined through regulations). Depending upon the availability of a National Death Register, the accessibility and responsiveness to such a register and the periodic batching of archival extracts at healthcare providers, it cannot be expected that individual patient submissions from multiple creators will be at all coordinated. Aggregation of a total patient record at the archive prior to submission into the preservation system is therefore deemed impractical in this specification.

The proposed data structure for the aggregations of the submissions of Patient Medical Records is as shown in the data model in Figure 3. As patient data is likely to be submitted in batches, each submission package will contain information from multiple Patients, and it is likely that these submissions will be split by the archive on receipt to create Patient-specific archival information packages (AIPs) in order to simplify the dissemination process. In this context, the submission package could be considered as a submission information collection (SIC) or collation of SIPs which is compiled to simplify extraction and transmission. However, for the purposes of this specification, the term SIP is used to mean both a submission package for a single Patient Record or a submission package containing multiple Patient Records.

The levels of the aggregation in an eHealth1 package are as follows:

• Patient: An individual who has received healthcare at any number of healthcare providers and who is described by Patient Personal Information Implementation. Each patient will be identified by means of a unique identifier (ID) which is provided from the source EMR system. This unique ID connects the Patient Personal Information and the Patient Medical Record in the information package.
• Case: A Patient Medical Record can be structured in various ways, which may be dictated by national standards, guidance or local practice. A Patient’s Complete Medical Record will consist of multiple individual thematic Cases which may be concerned with particular medical conditions, periods or treatments. The proposed aggregation allows for flexibility in this grouping. These cases will be held in a healthcare provider’s local archive and may contain a number of Sub-cases and/or Documents with associated Data Files.
• Sub-case: A Sub-case is an allowable type of component consisting of a set of Documents and Data Files that is nested below a Case. Sub-cases may originate in departments within a large hospital or may be related to a different diagnosis to other Sub-cases. A Sub-case may have common (to the Case) or specific metadata.
• Document: A Document is a component that may consist of multiple related Data Files with common metadata; for example, a document may be a PDF file together with associated attachments, or there may be a document and a separate signature sheet. A document can be considered to be an entity that is approved/signed as a whole.
• Data File: A Data file is a component that contains data and has an associated MIME file type. A Data File can be a single bit stream or can encapsulate bit streams and attributes according to a standard such as a DICOM or MP4, in which case it will have a recognised MIME file type. A Data File, which is a container for multiple byte streams and metadata, can be included in the package as a Data File or can be unpacked and included as separate Byte Streams and metadata in METS. It is expected that containers such as DICOM and MP4 files will be submitted unaltered in Submission Information Packages (SIPs) and that any decision to unpack them is part of a preservation plan at the archive.
• Byte Stream: A Byte Stream is a component that contains data, has an associated MIME file type and is encapsulated in a container such as MP4, DICOM or Matroska. Each Byte Stream has its own associated metadata, such as technical metadata, but which is generally only accessible with specialised tools (such as ffprobe for video container formats).

Figure 3: eHealth1 SIP Data Model

2.4.2. Using the eHealth1 specification together with the Common Specification for Information Packages (CSIP)

The eHealth1 specification conforms to and extends the Common Specification for Information Packages (CSIP) and the Specification for Submission Information Packages (E-ARK SIP). When extractions are made from EMR systems according to the structure described, they can be transmitted in a package following the principles described in the CSIP and IP specifications.

2.4.3. Placement of data in an eHealth1 Information Package

Patient data will most likely be submitted by hospitals or other healthcare providers in periodic batches, consisting of multiple patient records. The eHealth1 specification allows for the inclusion of multiple patients per package, and so these batches can be transmitted in a single submission. The number of patients included in each AIP is then a matter for local implementation, Section 6.1.

Patient Medical Records are placed in a single representation within the ‘representations’ folder of the package. The representation should contain a METS file at its root (Representation METS), the folder structure of the representation should follow that defined by the CSIP and it must have a data folder. Within the data folder, there should be a folder for each Patient Record identified by a name that is unique within the package scope, follows the requirements of CSIP and contains to the Patient’s unique individual ID.

It is recommended, but not mandated that within each Patient Record folder that there are further folders that physically represent a Case, Sub-case, Document structure to aid human readability and navigation of the archive. If Patient Administrative and Patient Clinical Information is to be supplied, then this should be included at the root of each Patient Record. Figure 4 shows an example of a folder structure for a package where there are multiple Patient submissions and Patient Clinical information is included.

The package should contain a patient administrative information or manifest file within the root metadata/descriptive folder that at minimum contains the names of the patients whose records are contained in the package and a reference to their Patient ID.

Figure 4: Example of Package Folder Structure and Multiple Patient Submissions and Case Structure

2.5. General Requirements

EHGR1 – submission packages MUST contain at least one representation containing data from one or more Patients.

EHGR2 – data from multiple Patients if present MUST be divided into separate Patient Record folders in the data folder of the representation.

EHGR3 – Patient data in a Patient Record SHOULD follow a logical structure such as that of the of the source system e.g a Case/Document/File or Case/Sub-case/Document/File , but may take account of local language and/or source system directory structures. If local terms are used, the addition of a revised vocabulary to the package for data structure terms is recommended, which should be placed in the schemas folder.

EHGR4 – each submission package SHOULD contain a submission agreement in the root /documentation folder.

EHGR5 – there MUST be a Patient manifest or Patient Administrative Information file located in the root /metadata/descriptive folder that at minimum contains a list of Patient names and unique identifiers. The Patient Administrative Information file MAY contain personal and demographic information such as to aid searches for next of kin and research cohorts.

EHGR6 – each Patient Record SHOULD contain Patient Administrative and Clinical Information file(s).

3. Implementation

3.1. Use of METS in eHealth1

CSIP specifies that METS files be located at the root of the package folder structure (Root METS) and optionally in each of the representations within its respective root folder (Representation METS).

3.1.1. Root METS File

The root METS file must adhere to the requirements of the CSIP and Information Package specifications. In addition, there are specific requirements for the eHealth1 CITS, and in some cases, the level of the CSIP or package requirements have been increased (but never decreased).

3.1.1.1. Root METS root element

The eHealth1 CITS specification does not change or extend any of the requirements for the Root METS root element. Information is given below regarding the specific content type attributes to be used in an eHealth1 CITS.

Example: METS example of root METS element for an IP following the CITS eHealth1

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="ehealth1-root-mets-example" TYPE="OTHER" csip:OTHERTYPE="Patient Medical Records" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0" LABEL="Patient Medical Records from Skane University Hospital" PROFILE="https://citsehealth1.dilcis.eu/profile/E-ARK-eHealth1-ROOT.xml">
</mets:mets>

3.1.1.2. Root METS header element (element metsHdr)

The following describes the differences in the package metsHdr element between CSIP, IP and the eHealth 1 CITS specification.

Example: METS example of root METS Header for an IP following CITS eHealth1

<mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
  <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
    http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
  </mets:altRecordID>
  <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
    http://submissionagreement.kb.se/dnr330-1122-2009/20110613/
  </mets:altRecordID>
  <mets:altRecordID TYPE="REFERENCECODE">
    FM-12-2387/12726,2007-09-19
  </mets:altRecordID>
  <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
    SE/FM/123/123.1/123.13
  </mets:altRecordID>
  <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
    <mets:name>
      piql eHealth SIP Creator
    </mets:name>
    <mets:note csip:NOTETYPE="SOFTWARE VERSION">
      VERSION 1.1
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
    <mets:name>
      Skane University Hospital
    </mets:name>
    <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
      ID:89101112
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
    <mets:name>
      Sven Svensson
    </mets:name>
    <mets:note>
      Phone: 08-123456, email: sven.svensson@mail.mail
    </mets:note>
  </mets:agent>
  <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
    <mets:name>
      The Swedish Health Agency
    </mets:name>
    <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
      ID:1234567
    </mets:note>
  </mets:agent>
</mets:metsHdr>

3.1.1.3. Root METS descriptive metadata section (element dmdSec)

The CSIP and IP specifications do not make any assumptions regarding the use of specific descriptive metadata schemas. The structure of the eHealth1 CITS is built on the concept of being patient-centric, and so a standardised metadata schema is preferred for Patient Administrative Information. The use of schemas such as ISO 13606 or HL7 FHIR is suggested but is not mandatory as local regulations and standards may be used.

Example: METS example of Root METS dmdSec following CITS eHealth1 with reference to HL7 FHIR Patient Administrative Information is used

<mets:dmdSec ID="dmd-ehealth-file" CREATED="2018-04-24T15:27:45.702+01:00" STATUS="CURRENT">
  <mets:mdRef LOCTYPE="URL" xlink:href="metadata/descriptive/patients.xml" xlink:type="simple" MDTYPE="OTHER" OTHERMDTYPE="FHIR.Patient" MIMETYPE="application/xml" SIZE="643" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
  </mets:mdRef>
</mets:dmdSec>

3.1.1.4. Root METS administrative metadata section (element amdSec)

The eHealth1 CITS specification does not change or extend any of the requirements already defined by the CSIP or IP specifications’ administrative metadata section. The eHealth1 root METS document amdSec element SHOULD comply with the amdSec requirements in the CSIP profile. Note that in eHealth1, it is required that any rights or digital provenance metadata that is general to the package should be held within the root metadata folder and that any rights or digital provenance metadata that is specific to the data held in the representations should be held in the respective representation metadata folder.

3.1.1.5. Root METS file section (element fileSec)

The CSIP does not make the use of the METS fileSec element mandatory, but it is strongly recommended. In the eHEALTH CITS, the use of the METS fileSec element at the package level becomes mandatory, such as to reference the mets files within each representation.

Example: METS example of Root METS fileSec following CITS eHealth1 with file information.

<mets:fileSec ID="file-sec-example">
  <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
    <mets:file ID="file-submission-agreement" MIMETYPE="application/pdf" SIZE="43445212" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/subagreement.pdf">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-ptr-documentation-file" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2012-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/file2.docx">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
    <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/fhirpatient.xsd">
      </mets:FLocat>
    </mets:file>
    <mets:file MIMETYPE="application/xml" USE="Package METS" CHECKSUMTYPE="SHA-256" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" ID="file-ptr-schema2" SIZE="6814">
      <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-representation" USE="Representations" ADMD="digiProv-eHealth-file rights-eHealth-file" DMDID="dmd-eHealth-file" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0">
    <mets:file ID="file-ptr-repmets1" MIMETYPE="xml" SIZE="1338744" CREATED="2018-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/rep1/mets.xml">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
</mets:fileSec>

3.1.1.6. Root METS structural map (element structMap)

The METS structural map element is the only mandatory element in the METS specification. It provides an overview of the components described in the METS document. It can also link the elements in the structure to associated content files and metadata. In the eHealth1 CITS, the package structMap describes the high-level structure of all the content in the package and links to at least one representation.

The representation METS file is referenced from the package METS.xml via the <mptr> element, and hence the requirements for the structMap element within the package METS.xml (CSIP requirements CSIP80 to CSIP118) are unchanged. Because a representation is present, the need for a Content Division in the package METS.xml structMap is not required (CSIP101 to CSIP104 and CSIP109).

Implementers are welcome to define additional structural maps for their internal purposes by repeating the structMap element. The specific requirements for elements, sub-elements and attributes for eHealth1 CITS, which differ from the CSIP, are listed in the following table.

3.1.2. Representation METS File

The representation METS files is used to describe the data structure as included in the data folder of the Representation Medical Record) via the structMap element and to reference any additional descriptive metadata.

3.1.2.1. Representation METS root element

Particular notice is drawn to the specific requirements for a representation METS root element as described in the CSIP specification.

Example: METS example of representation METS root element for an IP following the CITS eHealth1

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" OBJID="PatientRecord_Submission" TYPE="OTHER" csip:OTHERTYPE="Patient Medical Records" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0" PROFILE="https://citsehealth1.dilcis.eu/profile/E-ARK-eHealth1-REPRESENTATION.xml" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd">
</mets:mets>

3.1.2.2. Representation METS header element (element metsHdr)

There are no requirements for a specific header element in the representation METS. The eHealth1 representation metsHdr element should comply with the metsHdr requirements in the SIP profile. Note that the information contained in the representation header element relate specifically to the representation METS document.

3.1.2.3. Representation METS descriptive metadata section (element dmdSec)

The Representation may contain additional descriptive metadata within the metadata/descriptive folder as described in the CSIP. It is recommended however that Patient Clinical Information related to the Patient Cases that can contain clinical information (diagnoses, conditions, procedures, allergies, family history, care plans) such as can be found in ISO 13606 or the HL7 FHIR Clinical Module and that has been extracted from the source EMR system is included within each individual Patient Record in the repname/data folder, such as to simplify separation of Patient records into individual SIPs at the Archive. Use of metadata standards and codings (e.g. International Classification of Diseases ICD, https://www.who.int/classifications/icd/en/, Systematized Nomenclature of Medicine, SNOMED CT, ) is encouraged. Where used, references to the specific schemas os resources should be given together with relevant version information.

3.1.2.4. Representation METS administrative metadata section (element amdSec)

The administrative metadata section contains four sub-sections, each used to record different types of metadata for package content:

• technical metadata (element techMD) records technical metadata;
• rights metadata (element rightsMD) records intellectual property rights information;
• source metadata (element sourceMD) records descriptive, technical or rights metadata for an analogue source for a digital library object; and
• digital provenance metadata (element digiprovMD) records digital preservation information (e.g. audit information covering a digital library object’s life-cycle).

The CSIP only describes the use of the elements digiprovMD and rightsMD within the administrative metadata section of the METS.

The CSIP (and METS) categorises preservation metadata as administrative metadata, specifically Digital Provenance metadata (following the available guidelines published by the PREMIS EC guidelines: http://www.loc.gov/standards/premis/guidelines2017-premismets.pdf). Hence all preservation metadata should be referenced from a digiprovMD element within the amdSec.

The METS amdSec element should include references to all relevant metadata located in the folder “repname/metadata/preservation”. The package level METS.xml file should only reference package level preservation metadata. Representation level METS.xml files should only reference representation level preservation metadata.

In eHealth1, it is required that any rights or digital provenance metadata that is general to the package can be held within the root metadata folder and that any rights or digital provenance metadata that is specific to the data held in the representation should be held in the representation metadata folder.

The eHealth1 representation METS document amdSec element should comply with the requirements in the CSIP profile.

Example: METS example of representation fileSec for an IP following the CITS eHealth1

<mets:fileSec ID="file-sec-example">
  <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
    <mets:file ID="file-ptr-documentation-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File1.docx">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-ptr-documentation-file2" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2012-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
    <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/fhirpatient.xsd">
      </mets:FLocat>
    </mets:file>
    <mets:file MIMETYPE="application/xml" USE="Package METS" CHECKSUMTYPE="SHA-256" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" ID="file-ptr-schema2" SIZE="6814">
      <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="fileGrp-patient_12345-information" USE="data/patient_12345" ADMID="digiProv-eHealth-file2 rights-eHealth-file2">
    <mets:file ID="file-ptr-patient-administrative-file1" MIMETYPE="application/xml" SIZE="2352367" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="D2DF16632617402BF279D61DBC9F73675E033ABA6B94A78D4B9607CE5CAAFA3E" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/patient_12345/patient_12345_admin.xml">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-ptr-patient-patient-condition-file2" MIMETYPE="application/xml" SIZE="1344782" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="FD7EE6C02AC30570BA8C73E0E8CCDDA77C5428F3E6F6BEA7834F9B1AEB4D8F20" CHECKSUMTYPE="SHA-256">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/patient_12345/patient_12345_condition.xml">
      </mets:FLocat>
    </mets:file>
  </mets:fileGrp>
  <mets:fileGrp ID="filegrp-patient_12345_document1" USE="data/Patient_12345/case1/subcase1/document1/datafile1" ADMD="digiProv-eHealth-file2 rights-eHealth-file2" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0">
    <mets:file ID="file-ptr-document1-file0" MIMETYPE="PDF" SIZE="1337808" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="E5C853A25A1A86ADDBFA5F54FBF5F0F2D97E8F257E2DB7640CA85E462D38652A" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/patient_12345/case1/document1/patientnotes0.pdf">
      </mets:FLocat>
    </mets:file>
    <mets:file ID="file-ptr-document1-file1" MIMETYPE="application/mp4" SIZE="3189002" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="1A7FF5D05D4BEDBFD09447F633586646EF55F59480A1FF30B5D26D6866604F2F" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
      <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/patient_12345/case1/document1/procedure.mp4">
      </mets:FLocat>
      <mets:stream ID="file-ptr-document1-file2-stream1" MIMETYPE="video/mp4" SIZE="4236737" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="3A4DF1ADB67D2E74F4A6A7E39A7714ED330F066144D0A8774DA83B1BB77FA9EB" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
      </mets:stream>
      <mets:stream ID="file-ptr-document1-file2-stream2" MIMETYPE="audio/mp3" SIZE="1132354" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="7176A627870CFA3854468EC43C5A56F9BD8B30B50A983B8162BF56298A707667" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
      </mets:stream>
    </mets:file>
  </mets:fileGrp>
</mets:fileSec>

3.1.2.5. Representation METS structural map (structMap element)

The METS structural map element is the only mandatory element in the METS specification and is hence mandatory within the representation METS. The representation METS.xml is referenced from the package METS.xml via the <mptr> element, and hence the requirements for the structMap element within the package METS.xml (CSIP requirements CSIP80 to CSIP118) are unchanged. Because a representation is present, the need for a Content Division in the package METS.xml structMap is not required (CSIP101 to CSIP112 and CSIP 116, 118 and 119).

There MUST be one structural map present following the requirements of the CSIP.

Example: METS example of the eHealth1 mandatory structural map present in the representation METS for eHealth1 with Case Structure

<mets:structMap ID="struct-map-example-representation" TYPE="PHYSICAL" LABEL="eHealth1">
  <mets:div ID="struct-map-example-div" LABEL="eHealth1-repmets-example">
    <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ehealth-file2" ADMID="digiProv-eHealth-file2 rights-eHealth-file2">
    </mets:div>
    <mets:div ID="struct-map-doc-div" LABEL="Documentation">
      <mets:fptr FILEID="file-grp-documentation">
      </mets:fptr>
    </mets:div>
    <mets:div ID="struct-map-schema-div" LABEL="Schemas">
      <mets:fptr FILEID="file-grp-schema">
      </mets:fptr>
    </mets:div>
    <mets:div ID="struct-map-data-div" LABEL="Data">
      <mets:div ID="struct-map-patient_12345-record-div" LABEL="Patient Record">
        <mets:fptr FILEID="filegrp-patient_12345-information">
        </mets:fptr>
        <mets:div ID="struct-map-patient_12345-record-case-1" LABEL="Case">
          <mets:div ID="struct-map-patient_12345-record-case-1-subcase-1" LABEL="Subcase">
            <mets:fptr FILEID="filegrp-patient_12345-document1">
            </mets:fptr>
          </mets:div>
        </mets:div>
      </mets:div>
    </mets:div>
  </mets:div>
</mets:structMap>

3.2. Use of Descriptive Metadata in eHealth1

3.2.1. Archival Information

Medical Records or a mixed archive containing other types of records. In the case of a single subject archive the description of the archive is implicit and may be recorded outside of the archival packages themselves. In the case of a mixed archive it will be necessary to include archival description records in each archival package which should then follow the requirements of the Common Specification for Archival Information and use a standardised schema such as EAD3 or Dublin Core.

3.2.2. Patient Identifiers

Patients must have a nationally unique identifier that is referenced within the source EMR system and can be referenced to a National Death Register, such as a Social Security or other unique individual identifier.

3.2.3. Patient Personal Information

Patient Personal Information should, wherever possible conform to an international or national standard for describing patient information within EMR of EHR systems (e.g. HL7 FHIR contains a well-specified resource for Patient Personal Information and provides schemas in a number of formats)¹. At a minimum this file must contain patient names and unique identifiers and should contain personal and demographic information.

3.2.4. Patient Clinical Information

Structured Patient Clinical Information such as diagnoses, procedures, medication, allergies, etc., can add significant value to the Health Archive and, in particular, to the research use cases as described in 4.3. Clinical metadata associated with the Patient or Patient Cases can be added to the package or PatientRecord_ID/metadata/descriptive folders in the package. Clinical metadata should, wherever possible, conform to an international or national standard for describing patient clinical information with EMR and EHR systems (e.g. HL7 FHIR contains well-specified resources for clinical, diagnostic and medication data and provides schemas in a number of formats)². Clinical metadata should use recognised vocabularies and coding such as ICD and SNOMED.

4. Deprecated Requirements in eHealth1

The work to improve this specification is ongoing. On occasion we retire a requirement, these are listed here for information. The majority of these deprecated requirements were duplicates of those in the CSIP and SIP specifications and have been removed for reasons of maintaining currency.

5. Glossary

6. Appendices

6.1. Appendix A: CITS eHealth1 Information Package METS Examples

6.1.1. Example 1: Example of a whole representation METS document describing a submission information package representation following CITS eHealth1 (citsehpj_v2_0).

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="Patient_Records_Submission" TYPE="OTHER" csip:OTHERTYPE="Patient Medical Records" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0" PROFILE="https://citsehealth1.dilcis.eu/profile/E-ARK-eHealth1-REPRESENTATION.xml">
  <mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
      http://submissionagreement.kb.se/dnr330-1122-2009/20110613/
    </mets:altRecordID>
    <mets:altRecordID TYPE="REFERENCECODE">
      FM-12-2387/12726,2007-09-19
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
      SE/FM/123/123.1/123.13
    </mets:altRecordID>
    <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
      <mets:name>
        piql eHealth SIP Creator
      </mets:name>
      <mets:note NOTETYPE="SOFTWARE VERSION">
        VERSION 1.1
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Skane University Hospital
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:89101112
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="SUBMITTER" TYPE="INDIVIDUAL">
      <mets:name>
        Sven Svensson
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:4569865123
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
      <mets:name>
        Sven Svensson
      </mets:name>
      <mets:note>
        Phone: 08-123456, Email: sven.svensson@mail.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        The Swedish Health Agency
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:1234567
      </mets:note>
    </mets:agent>
  </mets:metsHdr>
  <mets:amdSec>
    <mets:digiProvMD ID="digiProv-eHealth-file2" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis3.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="984" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:digiProvMD>
    <mets:rightsMD ID="rights-eHealth-file2" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis4.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="563" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:rightsMD>
  </mets:amdSec>
  <mets:fileSec ID="filesec-docx-file-1">
    <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
      <mets:file ID="file-ptr-documentation-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File1.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-documentation-file2" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2012-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
      <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/fhirpatient.xsd">
        </mets:FLocat>
      </mets:file>
      <mets:file MIMETYPE="application/xml" USE="Package METS" CHECKSUMTYPE="SHA-256" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" ID="file-ptr-schema2" SIZE="6814">
        <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="fileGrp-patient_12345-information" USE="data/patient_12345" ADMID="digiProv-eHealth-file2 rights-eHealth-file2">
      <mets:file ID="file-ptr-patient-administrative-file1" MIMETYPE="application/xml" SIZE="2352367" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="D2DF16632617402BF279D61DBC9F73675E033ABA6B94A78D4B9607CE5CAAFA3E" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/patient_12345/patient_12345_admin.xml">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-patient-patient-condition-file2" MIMETYPE="application/xml" SIZE="1344782" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="FD7EE6C02AC30570BA8C73E0E8CCDDA77C5428F3E6F6BEA7834F9B1AEB4D8F20" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="data/patient_12345/patient_12345_condition.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-patient_12345_document1" USE="data/Patient_12345/case1/subcase1/document1/datafile1" ADMD="digiProv-eHealth-file2 rights-eHealth-file2" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0">
      <mets:file ID="file-ptr-document1-file0" MIMETYPE="PDF" SIZE="1337808" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="E5C853A25A1A86ADDBFA5F54FBF5F0F2D97E8F257E2DB7640CA85E462D38652A" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/patient_12345/case1/document1/patientnotes0.pdf">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-document1-file1" MIMETYPE="application/mp4" SIZE="3189002" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="1A7FF5D05D4BEDBFD09447F633586646EF55F59480A1FF30B5D26D6866604F2F" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="/data/patient_12345/case1/document1/procedure.mp4">
        </mets:FLocat>
        <mets:stream ID="file-ptr-document1-file2-stream1" MIMETYPE="video/mp4" SIZE="4236737" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="3A4DF1ADB67D2E74F4A6A7E39A7714ED330F066144D0A8774DA83B1BB77FA9EB" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
        </mets:stream>
        <mets:stream ID="file-ptr-document1-file2-stream2" MIMETYPE="audio/mp3" SIZE="1132354" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="7176A627870CFA3854468EC43C5A56F9BD8B30B50A983B8162BF56298A707667" CHECKSUMTYPE="SHA-256" ADMID="digiprov-eHealth-file2 rights-eHealth-file2">
        </mets:stream>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-example-representation" TYPE="PHYSICAL" LABEL="eHealth1">
    <mets:div ID="struct-map-example-div" LABEL="eHealth1-repmets-example">
      <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ehealth-file2" ADMID="digiProv-eHealth-file2 rights-eHealth-file2">
      </mets:div>
      <mets:div ID="struct-map-doc-div" LABEL="Documentation">
        <mets:fptr FILEID="file-grp-documentation">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-schema-div" LABEL="Schemas">
        <mets:fptr FILEID="file-grp-schema">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-data-div" LABEL="Data">
        <mets:div ID="struct-map-patient_12345-record-div" LABEL="Patient Record">
          <mets:fptr FILEID="filegrp-patient_12345-information">
          </mets:fptr>
          <mets:div ID="struct-map-patient_12345-record-case-1" LABEL="Case">
            <mets:div ID="struct-map-patient_12345-record-case-1-subcase-1" LABEL="Subcase">
              <mets:fptr FILEID="filegrp-patient_12345-document1">
              </mets:fptr>
            </mets:div>
          </mets:div>
        </mets:div>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

6.1.2. Example 2: Example of a whole METS document describing a submission information package following CITS eHealth1 (citsehpj_v2_0).

<mets:mets xmlns:mets="http://www.loc.gov/METS/" xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" xmlns:sip="https://DILCIS.eu/XML/METS/SIPExtensionMETS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd             http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd             https://DILCIS.eu/XML/METS/CSIPExtensionMETS              https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd              https://DILCIS.eu/XML/METS/SIPExtensionMETS              https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd" OBJID="ehealth1-root-mets-example" TYPE="OTHER" csip:OTHERTYPE="Patient Medical Records" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0" LABEL="Patient Medical Records from Skane University Hospital" PROFILE="https://citsehealth1.dilcis.eu/profile/E-ARK-eHealth1-ROOT.xml">
  <mets:metsHdr CREATEDATE="2018-04-24T14:37:49.602+01:00" LASTMODDATE="2018-04-24T14:37:49.602+01:00" RECORDSTATUS="NEW" csip:OAISPACKAGETYPE="SIP">
    <mets:altRecordID TYPE="SUBMISSIONAGREEMENT">
      http://submissionagreement.kb.se/dnr331-1144-2011/20120711/
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSSUBMISSIONAGREEMENT">
      http://submissionagreement.kb.se/dnr330-1122-2009/20110613/
    </mets:altRecordID>
    <mets:altRecordID TYPE="REFERENCECODE">
      FM-12-2387/12726,2007-09-19
    </mets:altRecordID>
    <mets:altRecordID TYPE="PREVIOUSREFERENCECODE">
      SE/FM/123/123.1/123.13
    </mets:altRecordID>
    <mets:agent ROLE="CREATOR" TYPE="OTHER" OTHERTYPE="SOFTWARE">
      <mets:name>
        piql eHealth SIP Creator
      </mets:name>
      <mets:note csip:NOTETYPE="SOFTWARE VERSION">
        VERSION 1.1
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="ORGANIZATION">
      <mets:name>
        Skane University Hospital
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:89101112
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="SUBMITTER" TYPE="INDIVIDUAL">
      <mets:name>
        Sven Svensson
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:4569865123
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">
      <mets:name>
        Sven Svensson
      </mets:name>
      <mets:note>
        Phone: 08-123456, Email: sven.svensson@mail.mail
      </mets:note>
    </mets:agent>
    <mets:agent ROLE="PRESERVATION" TYPE="ORGANIZATION">
      <mets:name>
        The Swedish Health Agency
      </mets:name>
      <mets:note csip:NOTETYPE="IDENTIFICATIONCODE">
        ID:1234567
      </mets:note>
    </mets:agent>
  </mets:metsHdr>
  <mets:dmdSec ID="dmd-ehealth-file" CREATED="2018-04-24T15:27:45.702+01:00" STATUS="CURRENT">
    <mets:mdRef LOCTYPE="URL" xlink:href="metadata/descriptive/patients.xml" xlink:type="simple" MDTYPE="OTHER" OTHERMDTYPE="FHIR.Patient" MIMETYPE="application/xml" SIZE="643" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
    </mets:mdRef>
  </mets:dmdSec>
  <mets:amdSec>
    <mets:digiProvMD ID="digiProv-eHealth-file" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis1.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="984" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:digiProvMD>
    <mets:rightsMD ID="rights-eHealth-file" STATUS="CURRENT">
      <mets:mdRef LOCTYPE="URL" xlink:href="metadata/preservation/premis2.xml" xlink:type="simple" MDTYPE="PREMIS" MIMETYPE="application/xml" SIZE="563" CREATED="2018-04-24T14:11:29.309+01:00" CHECKSUM="66EEDDF0A22EF57078694B67CA45DF301034556D6CB493531356C4FFE92AB6B1" CHECKSUMTYPE="SHA-256">
      </mets:mdRef>
    </mets:rightsMD>
  </mets:amdSec>
  <mets:fileSec ID="filesec-docx-file-1">
    <mets:fileGrp ID="filegrp-documentation" USE="Documentation">
      <mets:file ID="file-ptr-documentation-file1" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessing.document" SIZE="43445212" CREATED="2012-08-15T12:08:15.432+01:00" CHECKSUM="160D71F56C2CE685CE7FBD679076FD76B3C67EE9AB5062F5EF5C99AE39C1F43B" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File1.docx">
        </mets:FLocat>
      </mets:file>
      <mets:file ID="file-ptr-documentation-file2" MIMETYPE="application/vnd.openxmlformats-officedocument.wordprocessingml.document" SIZE="31462826" CREATED="2012-08-15T14:44:45.432+01:00" CHECKSUM="0FE9683451D0390BCDEF19CE10CFD287A2D944B6A33D246681FEF27F44FFAF1D" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="documentation/File2.docx">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-schemas" USE="Schemas">
      <mets:file ID="file-ptr-schema1" MIMETYPE="text/xsd" SIZE="123917" CREATED="2018-04-24T14:37:49.617+01:00" CHECKSUM="4073D09CA1BAE023D5A7E2010819BF0E8A8EB3C015444D0673733630DE08461C" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="schemas/fhirpatient.xsd">
        </mets:FLocat>
      </mets:file>
      <mets:file MIMETYPE="application/xml" USE="Package METS" CHECKSUMTYPE="SHA-256" CREATED="2015-12-04T09:59:45" CHECKSUM="B565CA93CD86950503F233A7906E4DB709088BA42B9D109D4A8D6F183799603F" ID="file-ptr-schema2" SIZE="6814">
        <mets:FLocat xlink:href="schemas/METS.xsd" xlink:type="simple" LOCTYPE="URL">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
    <mets:fileGrp ID="filegrp-representation" USE="Representations" ADMD="digiProv-eHealth-file rights-eHealth-file" DMDID="dmd-eHealth-file" csip:CONTENTINFORMATIONTYPE="citsehpj_v2_0">
      <mets:file ID="file-ptr-repmets1" MIMETYPE="xml" SIZE="1338744" CREATED="2018-04-24T14:33:23.617+01:00" CHECKSUM="B1CF59678A21C2805370536AB1097735D7E9F3FDDDCAE3757426ED85F6350A48" CHECKSUMTYPE="SHA-256">
        <mets:FLocat LOCTYPE="URL" xlink:type="simple" xlink:href="representations/rep1/mets.xml">
        </mets:FLocat>
      </mets:file>
    </mets:fileGrp>
  </mets:fileSec>
  <mets:structMap ID="struct-map-example-1" TYPE="PHYSICAL" LABEL="CSIP">
    <mets:div ID="struct-map-example-div" LABEL="struct-map-example">
      <mets:div ID="struct-map-metadata-div" LABEL="Metadata" DMDID="dmd-ehealth-file" ADMID="digiProv-eHealth-file rights-eHealth-file">
      </mets:div>
      <mets:div ID="struct-map-documentation-div" LABEL="Documentation">
        <mets:fptr FILEID="filegrp-documentation">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-schema-div" LABEL="Schemas">
        <mets:fptr FILEID="filegrp-schemas">
        </mets:fptr>
      </mets:div>
      <mets:div ID="struct-map-reps-rep1" LABEL="representations/rep1/mets.xml">
        <mets:mptr LOCTYPE="URL" xlink:type="simple" xlink:href="representations/rep1/METS.xml" xlink:title="filegrp-representation">
        </mets:mptr>
      </mets:div>
    </mets:div>
  </mets:structMap>
</mets:mets>

6.2. Appendix B: External Schema

6.2.1. E-ARK SIP METS Extension

Location: https://earksip.dilcis.eu/schema/DILCISExtensionSIPMETS.xsd

Context: XML-schema for the attributes added by SIP

Note: An extension schema with the added attributes for use in this profile. The schema is used with a namespace prefix of sip.

6.2.2. E-ARK CSIP METS Extension

Location: http://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd

Context: XML-schema for the attributes added by CSIP

Note: An extension schema with the added attributes for use in this profile. The schema is identified using the namespace prefix csip.

6.3. Appendix C: External Vocabularies

6.3.1. OAIS Package Type

Maintained By: DILCIS Board

Location: http://earksip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml

Context: Used in @csip:OAISPACKAGETYPE

Note: Describes the type of the alternative record ID.

6.3.2. IANA media types

Maintained By: IANAs

Location: https://www.iana.org/assignments/media-types/media-types.xhtml

Context: Values for @MIMETYPE

Note: Valid values for the mime types of referenced files.

6.3.3. Content information type specification

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyContentInformationType.xml

Context: Values for @csip:CONTENTINFORMATIONTYPE

Note: Lists the names of specific E-ARK content information type specifications supported or maintained in this METS profile.

6.3.4. File group names

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyFileGrpAndStructMapDivisionLabel.xml

Context: Values for fileGrp/@USE

Note: Describes the uses of the file group <fileGrp> that are supported by the profile. Own names should be placed in an own extending vocabulary.

6.3.5. Structural map label

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyStructMapLabel.xml

Context: Values for structMap/@LABEL

Note: Describes the label of the structural map that is supported by the profile. Own labels should be placed in an own extending vocabulary.

6.3.6. Structural map typing

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyStructMapType.xml

Context: Values for structMap/@TYPE

Note: Describes the type of the structural map <structMap> that is supported by the profile. Own types should be placed in an own extending vocabulary.

6.3.7. Note type

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyNoteType.xml

Context: Used in @csip:NOTETYPE

Note: Describes the type of a note for an agent.

6.3.8. Content Category

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyContentCategory.xml

Context: Values for mets/@type

Note: Declares the categorical classification of package content.

6.3.9. Package Status

Maintained By: DILCIS Board

Location: http://earksip.dilcis.eu/schema/SIPVocabularyRecordStatus.xml

Context: Used in @RECORDSTATUS

Note: Describes the type of the alternative record ID.

6.3.10. Alternative record ID's

Maintained By: DILCIS Board

Location: http://earksip.dilcis.eu/schema/SIPVocabularyRecordIDType.xml

Context: Used in altrecordID/@TYPE

Note: Describes the type of the alternative record ID.

6.3.11. Structural map divisions labels in eHealth1

Maintained By: DILCIS Board

Location: https://citsehealth1.dilcis.eu/schema/VocabularyEHealth1.xml

Context: Predefined values for different eHealth1 classifications

Note: Describes the extra terms supported by this profile. Own names should be placed in an own extending vocabulary.

6.3.12. dmdSec status

Maintained By: DILCIS Board

Location: http://earkcsip.dilcis.eu/schema/CSIPVocabularyStatus.xml

Context: Values for dmdSec/@STATUS

Note: Describes the status of the descriptive metadata section (dmdSec) which is supported by the profile.

6.4. Appendix D: E-ARK CITS eHealth1 Metadata Requirements

6.4.1. E-ARK eHealth1 representation METS Profile 2.0.1 (citsehpj_v2_0) Requirements

6.4.2. E-ARK eHealth1 root METS Profile 2.0.1 (citsehpj_v2_0) Requirements

Postface

I. Authors

I. Reviewers

II. Revision History

Statement of originality

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

III. Contact & Feedback

The CITS 3D Product Model is maintained by the Digital Information LifeCycle Interoperability Standard Board (DILCIS Board). For further information about the DILCIS Board or feedback on the current document please consult the website (http://www.dilcis.eu/) or contact us at info@dilcis.eu.