hData Record Format, Release 2

tacitmarigoldInternet and Web Development

Jan 25, 2014 (3 years and 2 months ago)

202 views


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

hData Record Format
, Release

2

August

2013


Responsible Group



Service Oriented Architecture Work Group






Health Level Seven International

Primary Contributor and Editor

Mark A. Kramer

mkramer@mitre.org

The MITRE Corporation

Contributor

M
uhammad

Asim

muhammad.asim@philips.com

Philips Healthcare

Contributor

Gerald Beuchelt

work
@beuchelt.com

Contributor

David Hay

david.hay25@gmail.com

Contributor

Paul Knapp

pknapp@
pknapp
.com

Contributor

Samuel Sayer

s
sayer@mitre.org

The MITRE Corporation

SOA co
-
chair

Ken Rubin

ken.rub
i
n@hp.com

Hewlett
-
Packard Compa
ny

SOA co
-
chair

Vince McCauley

vincem@mccauleysoftware.com

McCauley Software

HL7® Version 3 Standard, © 2013 Health Level Seven® International All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Re
g. U.S. Pat & TM Off.

Use of these materials is governed by HL7 International's
IP Compliance Policy
.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

Important Notes

HL7 licenses its standards and select IP free of charge.
If you did not acquire a free license from HL7
for this document
, you are not
authorized to access or make any use of it. To obtain a free license,
please visit

http://www.HL7.org/implement/standards/index.cfm
. If you are the individual that
obtained the license for this HL7 Standard, specification or other freely licensed work (in
each and
every instance "Specified Material"), the following describes the permitted uses of the Material.

A.
HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS
, who register and agree to the
terms of HL7’s license, are authorized, without additional
charge, to read, and to use Specified Material
to develop and sell products and services that implement, but do not directly incorporate, the Specified
Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH
PROFESSI
ONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part,
into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL
MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B.

HL7 ORGANIZATION MEMBERS
, who register and agree to the terms of HL7's License, are
authorized, without additional charge, on a perpetual (except as provided for in the full license terms
governing the Material), non
-
exclusive and worldwide basis, the rig
ht to (a) download, copy (for
internal purposes only) and share this Material with your employees and consultants for study
purposes, and (b) utilize the Material for the purpose of developing, making, having made, using,
marketing, importing, offering to
sell or license, and selling or licensing, and to otherwise distribute,

Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant
patent and other intellectual property rights of third parties (which may includ
e members of HL7). No
other license, sublicense, or other rights of any kind are granted under this Agreement.

C.
NON
-
MEMBERS
, who register and agree to the terms of HL7’s IP policy for Specified Material, are
authorized, without additional charge, to read

and use the Specified Material for evaluating whether to
implement, or in implementing, the Specified Material, and to use Specified Material to develop and
sell products and services that implement, but do not directly incorporate, the Specified Material

in
whole or in part. NON
-
MEMBERS wishing to incorporate additional items of Specified Material in whole
or part, into products and services, or to enjoy the additional authorizations granted to HL7
ORGANIZATIONAL MEMBERS, as noted above, must become ORGAN
IZATIONAL MEMBERS of HL7.

Please see
http://www.hl7.org/legal/ippolicy.cfm
for the full license terms governing the Material.




hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

Table of Contents

Important Notes

................................
................................
................................
................................
..........
2

Table of Contents

................................
................................
................................
................................
........
3

1

Introduction
................................
................................
................................
................................
.........
5

1.1

Changes Since Version 1.0

................................
................................
................................
.......
7

1.2

Namespaces

................................
................................
................................
.............................
8

1.3

Notational Conventions

................................
................................
................................
...........
9

1.4

JSON Support

................................
................................
................................
...........................
9

1.5

Relation
ship to FHIR

................................
................................
................................
.................
9

1.6

Areas Not Covered by this Specification

................................
................................
...............

10

2

Organization of the hData Record

................................
................................
................................
....

11

2.1

Overall Structure

................................
................................
................................
...................

11

2.2

Ro
ot File

................................
................................
................................
................................

12

2.3

Paths and Templates

................................
................................
................................
.............

16

2.3.1

Section and Resource Paths

................................
................................
........................

16

2.3.2

Path Templates

................................
................................
................................
...........

17

2.4

Resource Types and Representations

................................
................................
...................

19

3

Atom Feeds
................................
................................
................................
................................
.......

20

3.1

Elements of Atom <feed> profiled for hData

................................
................................
.......

20

3.2

Elements of Atom <entry> profiled for hData

................................
................................
......

20

3.3

Optional Metadata Extensions for Atom <entry>

................................
................................

21

3.4

Optional Metadata Processing

................................
................................
.............................

24

3.5

XML and JSON Representations of Atom Feed

................................
................................
.....

24

4

hData Content Profiles

................................
................................
................................
.....................

26

4.1

Purpose of hData Content Profiles

................................
................................
.......................

26

4.2

Suggested Contents of hData Content Profiles

................................
................................
....

26

5

Normative Schemas

................................
................................
................................
.........................

28

5.1

Root Document Schema

................................
................................
................................
.......

28

5.2

Metadata Extension Schema

................................
................................
................................

29

6

Examples

................................
................................
................................
................................
..........

31

6.1

hData Record Example (Non
-
Normative)

................................
................................
.............

31

6.2

Root Document Example (Non
-
Normative)

................................
................................
..........

31

6.3

Atom Feed Example (Non
-
Normative)
................................
................................
..................

33


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

7

Glossary (Non
-
Normative)
................................
................................
................................
................

35

8

Bibliography
................................
................................
................................
................................
......

36





hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

1

Introduction

HL7 is working to improve the quality of health care by assuring the interoperability of health
information. Standard representations of patient status, such as the
Clini
cal Document Architecture
(
CDA
)

[1]
, and standard message formats, including
Health Level Seven

(
HL7
)

Version 2.x and Version 3
Messages, are important aspects of realizing that vision. However, the goal of easily accessing and
integrating information from multiple, independent health care providers has not yet been realized.
For example, creating a patie
nt
-
centric

virtual

lifetime health record by dynamically federating multiple
data sources requires new information architectures that are highly scalable and capable of operating
in loosely coupled environments.

hData seeks to simplify the exchange of inf
ormation found in Electronic Health Records (EHR) systems
by leveraging common web technologies such as
Representational State Transfer (
REST
)

architectures
and the Atom
S
yndication
P
rotocol

[2]
, resulting in rapid development
and lightweight web
-
enabled
applications. Using mainstream technologies brings a host of advantages, including proven scalability, a
rich tool ecosystem, rapid innovation, and a large community of web developers. The medical
information community
also need
s to move in this direction
to
exploit

mobile
platforms
,
which
unquestionably will be

primary endpoints for clinicians and patients alike.

With bandwidth and
processing limitations, there will be a premium placed on web
-
enabled, efficient, incremental data

exchange.

hData is designed to facilitate information interoperability by establishing a standard
presentation of

resources at a web interface, and a standard set of
REST

web services interact with those resources.
By
design,
hData
is content agnostic
. R
ather than being limited to a particular set of schemas, hData can
equally be used for
medical
documents suc
h as CDAs or
Continuity of Care Records (
CCRs
)
,

HL7 Version
2.x
messages
,

images,
MS
-
Word
documents, spreadsheets, or
Fast Health Interoperable Reso
urces
(
FHIR
)

[3]
, with almost no limitations on the type of content that can be represented and transported.

In this sense,
hData is not
a
n

alternative nor

a
competitor to FHIR

(which also defines REST transport)
,
but a
complement

to

FHIR
that enables exchanges involving

a
heterogeneous

mix of FHIR and non
-
FHIR
resources.

The resource hierarchy is fundamental idea in
hData
. T
he
resource
hierarchy represents a logical
arrangement of information from a data repository, form
atted for exchange, and mapped to URLs.
In a
typical

realization, an hData
-
enabled

web

server will respond to external requests by reading or writing
to a clinical data repository, delivering

data
in one or more

declared wire formats
.
hData represents an
i
nterface to
a clinical data repository, not the repository itself.

hData is
comprised of
two

related standards:

1.

hData Record Format (HRF). The subject of this specification, the HRF defines the presentation of
data at a web interface

as a resource hierarchy
, including the URL location of data, security
considerations associated with the data, links to formal data definitions, as well as provenance and
other critical information.
Resources

can be

any type, either XML documents (such as

CDA
documents, H7v3 messages, or
FHIR resources
, etc.) or other
content
types such as MS Word

hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

documents or DICOM files.
While the HRF is
mostly
discussed here in
terms of

an EHR, it is fully
extensible and can be adapted to many other situations where dat
a is to be organized and shared.


2.

hData
REST
ful Transport
(HRT)

[4]
.

While the resources in the HRF can be accessed by any
appropriate transport, the
HRT

defines a simple set of web operations (HTTP requests) indicating
actions
to be performed on the resources identified in the HRF
. These operations include GET

(to
obtain a copy of the resource),
P
OST

(to upload a resource), and
OPTIONS

(to access information
about allowable operations on the resource).
The
HRT

was created as

a
R
EST

implementation

of
the HL7/OMG SOA Retrieve, Locate, Update, Service (RLUS) model

[5]
.

The HRF and HRT together define a
framework

for
creating data exchanges. However,
hData

does
not

define specific
payloads

or
resource
hierarchies. These choices fall to implementers of hData. hData
implementers can either create

their own implementation
,

follow

an existing

hData
Content Profile
(HCP)
, or work together with information exchange partners to create their own HCP
.
HCPs
are
i
mplementation guides

creat
ed by organizations

to
enable consistent use of hData
i
n a given domain,
making exchange of information easier and more predictable. HCPs can themselves be the subject of
standardization processes.
HCPs are an open, extensible set
, defined by subject matter experts

in
different domains
.

Section
4

provides guidelines for creating HCPs.

The relationship
s

between these

components

is shown in
Figure
1
. This figure

shows that the
hdata
Record Format
(HRF)
specifies the format of the hData Record (HDR)
. The HDR
relies on logical and
physical resource models provided externally by domain experts or information exchange partners. The
HDR also
may conform to one or more hData Content Profiles (HCPs), which are implementation guides
for the use of hData in certain do
mains.
The server that hosts the HDR prov
ides a service
interface for
clients

to interact with the resources in the HDR, drawing on information in a persistent data store
. In
the case of a REST implementation, the HRT standard specifies those services.

The

physical data model
provided by technologists and implementers
furnishes

the wire format for

data exchanged between
client and server
.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


Figure
1
. Relationship of hData c
omponents


1.1

Changes Since Version 1.0

V
ersion
2.0
of
the
HRF introduces several nomenclature changes.
These nomenclature changes
are
intended to
use
terminology in a more standard way and make

the specificat
ion more
accessible
.
These changes are primarily of concern to those

familiar
with the previous version of

the HRF, and

readers of
the HRT
Version 1.0
:




In the documentation, w
e
now
refer to

resources

instead of
section document
s
,
to better align with
common REST vocabulary

and
Fast Healthcare Interoperable Resources (
FHIR
)
, and to remove

the
unintended
allusion

to
HL7
Clinical Document Architecture (CDA).



In the root file and documentation, we use t
he term
resource type

is now used instead of
extension
, to better alig
n with use of the term resource, and
also differentiate from
file extension
s

and XML sch
ema extensions
.

Version 2.0 also introduces sc
hema changes in
the root file.
In addition to the nomenclature change
mentioned above, t
he root file now explicitly links sections in the HDR to the Content Profiles from
which they have been derived.
For simpl
icity, sections no longer support having mixed or multiple
resource types in single section.



hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

A new concept of
path templates

has been introduced (see Section
2.3.2
). Path templates are used in
the root file to define paths to resources that include other resource identifiers. This makes it possible
to define sections
that group resources in interesting ways; for example, according to patient ID, by
year or month of
service, or under a combination of patient ID and encounter ID. Significantly, path
templates eliminate the need for multiple patient
-
specific service endpoints (and repeated root files),
previously required when resources were grouped by patient ID.

By de
fault, p
aths to resources now include a

resource prefix, the at symbol (@). The
prefix
is
prepended
to the resource identifiers when constructing paths,
to
signal the difference between
resource path
s and
section path
s
.
With the introduction of path templa
tes, resource identifiers can
appear as sections, causing the ambiguity addressed by the
resource

prefix
.

This change also aligns the
HRF and FHIR.

The purpose of hData Content Profiles has been clarified
, and guidelines on their format have been
relaxed,
moving
closer to their original purpose as

implementation guides that promote

uniform usage
of the hData framework in certain domains.

Additional metadata for the Atom feed has been simplified
, and made optional,

since some content
models

such as FHIR

now

include
their own internal

models of provenance.
The definition of the Atom
feed now includes only resources, not resources and subsections, as previously defined.

JSON support for hData Atom feeds and root files is fully described in Version 2.0. While s
erver support
for JSON remains optional, examples are provided and XML conversion rules are described to assure
consistent JSON formatting.

1.2

Namespaces

This document uses the following namespaces. This specification uses a number of namespace prefixes
thro
ughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not
semantically significant.
Note that namespace identifiers are not necessarily resolvable links.

Namespace Prefix

Name
space URI

Description

hrf

http://hl7.org/schemas/hdata/2013/08/hrf

Namespace for elements in this
document

h
md

http://
www.hl7
.org/schemas/
hdata/
2013/08
/

hmd

Namespace for
hData
metadata

extensions appearing in Atom
feeds

xs

http://www.w3.org/2001/XMLSchema

XML Schema namespace

ds

http://www.w3.org/2000/09/xmldsig#


Namespace for XML Digital
Signature

atom

http://www.w3.org/2005/Atom


Namespace for the Atom
syndication format

Table 1
.
N
amespaces referenced in the h
D
ata
s
pecification


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

1.3

Notational Conventions

The keywords "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

[6]
.

When describing XML schemas, this specification uses the
following notation
al conventions.

Element
names do not include the namespace prefix
if the namespace is mentioned in close proximity in the
text
.
At
tributes are denoted with the @ sign
.

If present,
t
he pair in parenthesis after the element name
contains th
e data type and the
cardinality, or just the cardinality if the element takes no value.
Cardinality is indicated as
0..1, 1, 1..*,
or 0..*
.

Note also that only the W3C XML schemas linked in
S
ection
5

are normative


any schema fragment or
other schema description within the main body of this document are informational only.

1.4

JSON Support

The r
oot file
and Atom feed defined in this specification
can b
e represent
ed

in XML or
JavaScript Object
Notation

(JSON)
[7]
. JSON
is
used by many web and mobile applications and app
r
eciated
by developers
as a
light
weight alternative to XML.
Due to the lack of JSON schema,
JSON formats are defined via a set
of XML conversion rules and examples.

These rules are
closely aligned with the proposed
XML to JSON
conversion rules in FHIR
. However, since
FHIR uses a constrained version of XML

allowing only
attributes, those

rules do

not cover every eventuality. Similar XML constraints are not possible in
hData, since resources are defined externally.
In the following

set of rules
, FHIR
-
hData differences are
indicated in italics:



A complex
XML
element (an
XML
element
that contains oth
er elements and/or attributes)

is
represented by a JSON object
, whos
e

name

is th
e same as the XML element name

(default
namespace)
or qualified element name (non
-
default namespaces)
.



If
a complex element

has a text value

(
between the opening and closing
tags
)
, the text value is
represented by a
JSON
property with the name “<value>”.



XML attributes

appear as JSON properties,
using the
at sign (@) followed
with

the
name of the
attribute as the property na
me
.

The use of the at sign (@) in this

context indicates “attribute”,
unrelated to the resource prefix discussed in Section
2.3.2
.



Object and property names in JSON must appear in doubl
e quotes and are case
-
sensitive.



Potentially r
epeated elements are represented as JSON arrays.




Integer values are represented using a native JSON int, while boolean is represented using JSON's
"true" and "false" values. Other primitive types such as strin
g, decimal, etc. are represented as a
JSON strings, using the same serialization as the XML form (including dateTime, which is
represented as plain text, not in one of the proposed JSON custom date formats).



N
on
-
default namespaces are included in the attri
bute or object names. Although
JSON
does not
support namespaces, use of namespaces avoids potential collisions
between attribute names,
and
makes

the semantic source of the element

unambiguous
.

1.5

Relationship to FHIR

T
he

HL7 FHIR initiative

occurred
subsequent

to hData

Release 1
and has

adopted many of the ideas
of
hData

[8]
, including:


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511



U
se common web standards
such as REST and Atom



Disaggregation of

large
medical
records into


granular clinical
resources

identified by URL
s



Access to clinical resources via REST interface



Use

of

simplified
, easily validated

XML representations

The main difference between hData and FHIR is that FHIR defines specific health care resources and a
fixed mapping between these resources and URLs, w
hile hData can be used for any resources and
allows the implementer to define the organization of these resources.
For this reason, hData and FHIR
and complementary:
hData can be used in situations where information exchange partners need to
exchange non
-
F
HIR resources, such as C
onsolidated
CDA,
health and non
-
health
benefits information,
dental information, and
public health data
, and b
ecause hData
can also exchange FHIR resources
,
hData can be applied when exchanges involve a combination of FHIR and
non
-
FHIR resources.


1.6

Areas Not Covered by this Specification

As emphasized elsewhere in this specification, the HRF
does not
define specific payloads or resource
hierarchies.

Resource models, both logical and physical, are external to hData. Implementers c
reate
their own resource hierarchies to fit their
particular
business purpose.
Web s
ervices are defined by the
companion specification, the HRT, but certain aspects of behavior are not
, and must be defined
externally
. For example, the specification does no
t define the lifecycle of a resource, what happens as a
consequence of resource creat
ion, updating, or deletion,

or

the expected time scales for response
actions (such as pharmacy action responding to a new medication prescription
)
.

This specification does

not specify how patient consent, privacy policy, and access controls are to be
implemented. Server implementations have the responsibility of authenticating users and limiting
access to health data according to organizational policy, patient consent, and
applicable governmental
statutes.

Because HRT uses common web techniques, web
-
based security methods for authentication
and protection data protection can be used.
The RHEx project
[9]

has
demonstrated how to

combine
hData with

appropriate authentication
and data security
.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

2

Organization of the hData Record


2.1

Overall Structure

The basic approach of the hData Record Format is to represent medical info
rmation through linked
resources
, organized through an abstract hierarchy, simila
r to the folder
-
file paradi
gm of many
computer file systems

(
see Figure 2
)
.
As mentioned earlier, the hierarchy is typically not an actual data
repository, but rather an abstract arrangement of information
derived
from
a

repository, whose form
we do not specify.

To draw a distinction from an actual file system, we use the word “section” instead “folder” and
“resource” instead of “file”

(
unless the resource is an actual file
)
. At the top of the hierarchy is a special
reso
urce called the “root file”, which describes many of the properties of the hierarchy (see
2.2
).

The root of the hierarchy
represents
all the infor
mation from

the repository meant to be shared. This
can correspond

to
virtually any collection of data, such as
patient records, pharmacy
or lab
information,
billing data, image data, benefits information, consent forms, etc
. Because of the
flexibility of
hData, it is also possible to set up
one HDR for a large data pool, or
many

separate

HDRs
,
each

correspond
ing

to a single patient
. hData can
also
represent the
resource
hierarchy

used in FHIR

(
one level
deep,

one section per

resource type
)
. hData puts no
constrai
nts on the hierarchy
structure
.

Each section
(node in the hierarchy)
contains a set of subsections and/or resources.
R
esources are
groupe
d into sections, with each section having at most one
resource type
, which is declared in the
root document. Fo
r example, a section may contain laboratory results. Sections can also contain other
sections,
for example,
there may be a

section for radiolo
gy under laboratory results. It is
RECOMMENDED that the

semantics

and rationale for the grouping

be docume
nted in
an HCP

(see
S
ection
4.2
). Since hData can accommodate multiple HCPs concurrently, multiple groupings MAY be
established in parallel
.
As a result, t
he same
resource MAY

exist in more than one place in the
hierarchy.

Typically, the hierarchy is static, and only the contents of each se
ction are dynamic. However, HRT
Version 1.0
defines operations to dynamically create and delete sections and subsection
s. Under the
requirements of the HRT, changes to the hierarchy must be concurrently registered in the root
document by the server. Therefore, a client can always depend on the root document accurately
describing the entire hierarchy.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


Figure
2
. Information
hierarchy in an hData r
ecord

2.2

Root
File

The root file is
a
special
resource
,

l
ocated
at the
top
of the hierarchy
,

that describes certain properties
of the
HDR
.
The contents of the root file are depicted
in a UML diagra
m
in

Figure
3
.

A pseudo
-
XML
syntax description that provides a visual sense of what the end resource instances will look like in XML

is shown in

Figure
4
.

For more information about the pseudo
-
XML syntax, refer to the FHIR
documentation

[3]
.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


Figure
3
.
UML diagram of root f
ile


<?xml version="1.0" en
coding="UTF
-
8"?>

<
Root

xmlns="http://hl7.org/schemas/hdata/2013/08/hrf">


<
id
><!
--

1..1
String

unique id for root file
--
></id>


<version><!
--

1..1
String

version of root file
--
></version>


<created><!
--

1..1
xs:dateTime

time of original

creation
--
></created>


<lastModified><!
--

1..1
xs:dateTime

time last modified
--
></lastModified>


<profile> <!
--

0..* content profile implemented in HDR
--
>


<
id
><!
--

1..1
String

local id for profile
--
></id>


<
referen
ce
><!
--

1..1
String

reference to HCP
--
></reference>


</profile>


<section> <!
--

1..* section in HDR hierarchy
--
>


<
path
><!
--

1..1
String

segment for constructing fu
ll path
--
></path>


<
profileID
><!
--

0..*
String

id of source profile
--
></profileID >


<
resourcePrefix
><!
--

0..1
xs:boolean

prepend @ to resource in path?
--
></resourcePrefix>


<
resourceTypeID
><!
--

0..1
String

id of resource type

of section
--
></resourceTypeID>


<
metadataSupport
><!
--

0..1
xs:boolean

provides metadata processing?
--
>



</metadataSupport>


<section> <!
--

0..* subsection in HDR hierarchy
--
>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


<!
--

elements of subsections
--
>


</section>


</section>


<resourceType> <!
--

0..* a logical resource used in HDR
--
>


<
id
><!
--

1..1
String

local id for resource type
--
></id>


<
reference
><!
--

1..1
String

reference to resource type
--
></reference>


<
representation
><!
--

0..*
String

physical format of resource
--
>


<
mediaType
><!
--

1..1
String

media type
--
></mediaType>


<
validator
><!
--

0..*
String

reference to validators
--
></validator>


</representation>


</resourceType>

</Root>

Figure
4
.
Pseudo
-
XML representation of root f
ile


In the following, we give the normative definitions of each element of the root file. T
he
namespace of
all elements
in the root file
is “hrf”

unless otherwise noted. Attributes are denoted with
the
at

sign
(@).


Following
the name of
each element in parentheses are the data type and the
cardinality, or only

the cardinality if the element takes no value.
The top
-
level element is <Root>. The root file
contains the
following elements
(REQUIRED if not mark
ed otherwise)
:

Elements and Attributes of <Root>:



id

(xs:string, 1)

-

This element uniquely identifies the
root
document

and the hData
R
ecord itself
.
This element has no specific semantics or meaning. A possible implementation could be

a textual
representa
tion of a UUID.



version
(xs:integer, 1)
-

The version of the
HRF

used within

the root file
. The version number for
records complying with this version of the specification is
2
.




created
(xs:dateTime, 1)
-

Creation
time
of the
root
file
. This data
SHOULD be significant to at least
the second.



lastModified
(xs:dateTime, 1)
-

Last modification of the
root document
. This data SHOULD be
significant to at least the second.



profile

(0..*)


This
element represents a content profile

implemented in this HD
R.

If the HDR
conforms to an HCP, it SHOULD be listed here.
H
DRs are not required to follow any
HCP, however,
without an HCP
, it may be difficult to standardize information exchange among multiple partners
.



resourceType (
1
..*)


This element represents a
r
esource
type used by this HDR
.
Each
type of
resource
used in this

HDR

MUST have a resourceType element
.



section

(
1
..*)
-

This element represents a section in the HDR hierarchy. Each

HDR

section

except the
top level section (the root of the hierarchy) of th
e hierarchy

MUST have a

corresponding

section
element.

Elements

of
<
profile
>

:



id

(xs:string, 1)
-

This
attribute
contains
a local

identifier for the
profile. The
id

MUST be unique
within
the root document.



reference(xs:string, 1)


A r
eference to the HCP defining this content profile.
It is RECOMMENDED
to use a

URL resolving to the
HCP
.

Every pr
ofile MUST have a reference to its

defining document.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

Elements

of
<
section
>
:



path (xs:string, 1)
-

This text attribute is a path segment,
consis
ting of a literal

or a template
. The
path is used to construct the full path to the section (see Section

2.3
)
. Valid
characters
for a literal
path

are the Unreserve
d Characters in URI Generic Syntax
[10]
, specifically,

[a
-
z][A
-
Z][0
-
9] and

hyphen, period, underscore, and tilde
.
A

section
path MUST NOT begin with any resourcePrefix
used in the HDR.
Template

path
s
use the same character set

as

literals, except

templates

are
delimited by braces (curly brackets).
It is RECOMMENDED that organizations creating
HCPs

use
a
unique identifier such as
their domain name in the first path segment to avoid namespace
collisions in the full path name.

Within an organization, different content profiles must avoid using
the same section paths unless sharing a section is intended.



profileID(xs:string, 0..*)
-

Indicates the hData Content Profile(s) defining this section. The profileID
is inherited from its parent sections, and hence usually only specified in top
-
level sections.



resourcePrefix(xs:boolean, 0..1)
-

Indicates whether to

use an “@” sign before the resource id in
the path associated with a resource . If this element is omitted, the value of resourcePrefix is
inherited from the section’s parent sections. If the element does not occur in any parent, the “@”
sign is used by d
efault. If resourcePrefix is false, path templates MUST NOT be used.



resourceType
ID

(xs:string, 0
..1
)
-

The value of this element
MUST be equal to
the id attribute of a

<resourceType> element.
Only resources whose
type matches the

resourceTypeID element
ca
n

appear in

the section.

If no resourceTypeID

i
s given, the section may not contain resources, only
other sections.

The top level se
ction (
the root of the hierarchy
)

has no resourceType, and

cannot
contain resources
.



metadataSupport(xs:boolean, 0..1)
-

Ind
icates whether the section uses hData metadata extensions
and the server provides metadata processing operations. If element is omitted, by default, the
section does not support the hData metadata extensions.



section (section, 0..*)


The subsections belon
ging to the current section.



Elements

of
<
resourceType
>
:



id

(xs:string,1)
-

This attribute contains a local identifier for the resourceType. It MUST be unique
within the root document.
It is RECOMMENDED to use a human
-
readable

class or type name for
the i
d.

A section MAY have a resource type of “Root”, indicating the c
lient will find another root

file
in this section that defines additional levels of the hierarchy.



reference(xs:string, 1)


A reference to the definition of the resource type.
The reference MUST be
a globally unique identifier.
It is RECOMMENDED to use a URL
resolving

to
version
-
controlled
documentation of the

resource
detailing the semantics

of the resource
.




representation

(
0
..*)
-

This element re
presents
a

physical
representa
tion of the resource,

used
for
“on the wire”

communication.

If more than one representation

is given, the first one listed is the
default
.
If no representation

is given, the mediaType is assumed to be “application/xml”. It is
RECOMMENDED to provide an expl
icit
representation

to enable validation of the content.

Elements

and Attributes
of <
representation
>
:



media
Type (xs:string,
1
..1
)
-

C
ontains the
media

type of the resource.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511



validator(xs:string, 0..*)
-

An optional
reference to a validator for this

represe
ntation
, such as a
n

XML Schema Definition
(XSD)
or Schematron. It is RECOMMENDED to use a URL resolving to the
validator.

The root document schema MAY be extended to support additional features
.


Using the

XML
-
to
-
JSON
conversion rules given in
1.4
,
Figure
5

illustrates
JSON

pseudo
-
code for the

root
file:

{


"Root":{


"@xmlns":"
http://hl7.org/schemas/hdata/2013/08/hrf",


"id":"unique id for root file",


"version":"version of root file",


"created":"time of original creation",


"lastModified":"time last modified",


"profile":[{


"id":"local id for root file",



"reference":"reference to HCP"


}],


"section":[{


"path":"segment for constructing full path",


"profileID": [{


"<value>":"id of source profile"


}],


"resourcePrefix":"prepend @ to resource in path?",


"resourceTypeID":"id or resource type of section",


"metadataSupport":"provides metadata processing?",


"section":[{


. . . optional subsections . . .


}]


}],


"resourceType":[{


"id":"local id for resource type",



"reference":"reference to resource type",


"representation": [{


"mediaType":"media type",


"validator":[{


"<v
alue>":"reference to validator"


}]


}]


}]


}

}


Figure
5
. Pse
udo
-
J
SON representation of the root f
ile


2.3

Path
s

and Templates


Section and Resource Paths

2.3.1
The full path to a
ny

section is obtained by starting with a forward slash (“/”), and concatenating the
path segments, separated by forward slashes.

The full path to any
resource is obtained by starting with the full sectio
n path, adding a forward slash,
and
appending
the

resourcePrefix (an
”@” sign
)

concatenated with the
resource identifier
.

The “@”

hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

sign prevents the server from interpreting a resource as a section
.
It i
s RECOMMENDED that
implementers use the resource prefix; furthermore, w
hen
ever

path templates
(
see
Section
2.3.2
)

are

used

in a branch of the hierarchy
, the resourc
ePrefix MUST be used in
that branch
.

If

the implementer
chooses

to omit the “@”, they must declare resourcePrefix=”false” in the section or a parent section.
The resourcePrefix is true by default.

To prevent interpr
eting a section as a resource,

path segme
nt name
s

MUST NOT begin with
the “@”
sign
.


The following

inheritance rule applies to the resourcePrefix

and profileID
: If
either of these elements
are not given in a section
,
the value of the element is determined by
traversing up the hierarchy to
parent
sections.
Thus, it is only necessary to declare these
inherited
elements in
top
-
level sections.


Path Templates

2.3.2
Path segments may be specified by templates.
Templates
are denoted by curly brackets and
c
ontain a
text, for example
, {P
atient.id}.
There is no
intrinsic meaning to the bracketed text
.

The semantics of
substitution SHOULD be defined in the corresponding HCP.
Furthermore,

it is RECOMMENDED that the
implementer choose the bracketed text to hint at the proper substitution
s
, as follows:



If the substit
ution is a resource id or property, use the resource
id
and
dot notation to indicate

an

element or attribute that resolves

to a string, for example, {Patient.id}
.



For dates and times,
use
an ISO 8601

[11]

symbol

or string

, suc
h as YYYY, MM, DD, or YYYY
-
MM
-
DD
.



If neither of the above applies, any descriptive text

can be used
.

Templates allow the implementer to create
"
dependent r
esource
s
" that are
owned by an existing
resource.
A

"dependent resource"
typically
has an implicit life
-
cycle dependency on its parent. When a
parent resource is deleted,
the
dependent resource
s

are typically also deleted

(
however this behavior
is application
-
dependent and should
be documented in an HCP
)
.

It is RECOMMENDED to use the fol
lowing

section
pattern
for

dependent
resource
s
:


..
/[resourceType]/{resource.id}/
../
[dependentResourceType]/{dependentResource.id}

Consider the following example.

In t
he

DICOM logical model

[12]
, an imaging
study

such as an MR
I

is
composed o
f a number of series
, and each series has a number of images. Based on the dependent

resource URI pattern, the path to an image resource
could be
:


..
/Patients/123
4
/Radiology/Studies/5
67
/Series/
2
/Images/
@
4

I
ncluding the

Radiology
section
in this example
does not break the dependent resource
pattern, but
might be included by the implementer to

make

it clear that the studies are

radiology

studies,
or to
provide a place in the hierarchy
below which
other
r
adiology
-
related

resources

might be a
dded.
The
corresponding templated path

is:


..
/Patients/{Patient.id}/Radiology/Studies/{Study.id}/
Series/{Series.id}/Images


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

Now s
uppose that the Studies section has been defined to contain resources of resourceType “Study”,
defined at the behavior level in

an HCP to contain all radiology studies associated with the patient, and

the Series section has been defined
to contain resources of resourceType “Series”
, and defined
at the
behavior
al

level in an HCP
to

contain

all Series associated with a given Study.

Suppose as well that t
he
templated sections are defined without
a
resourceType (i.e., they
may not contain
resources).

In this case, t
o obtain the list of Series in a Study 567 as an Atom
feed,

the user would

do a

read
operation (
in HRT, an
HTTP
GET
) on
the path
:


../
Patients/1234/Radiology/Studies/567
/Series


Atom feed

of Series in Study 567

To get the
resource representing

Study 567,
the read operation must include the resourcePrefix
:


../
Patients/1234/Radiology/Studies/
@
567


Study 567

The
“@” sign

cl
arifies
to the server that it should not treat “567” as a section name.
The
d
isambiguation
sections and resources is

the rationale for requiring

the
resourcePrefix
in paths that
involve

template
s
.

Contrast the previous example with this one
:


../Patients/1
234/Radiology/Studies/567

→ E
mpty list; no resources in S
ection 567

Another

potential

use of templates is to
list
resources by date
, for example:


../Patients/{Patient.id}
/Radiology/Studies/{YYYY}/{MM}/{DD}

In this case the YYYY hint is used, rather than
{Study.date}, because the latter would suggest that the
user should substitute an xs:date, not just the year associated with the Study.
Given this pattern and
appr
opriate behavioral description:


../Patient
s/1234/Radiology/Studies/2012


List of S
tudies

from the
2012


../Pati
ents/1234/Radiology/Studies/2012/11

→ L
ist of
Studies from
Nov 2012

../Patients/1234/Radiology/Studies/@2012


Study
2012 or Not Found Error (HTTP 404)

I
t
is
valid in hData

for the same

resource
to appear in

multiple sections
.
In the

example, the Study

567

can appear in each of the following sections

(assuming it was conducted in 2012)
:


../Patients/1234/Radiology/Studies

../Patients/1234/Radiology/Studies
/2012

../Radiology/Studies/
2012

Note that t
he latter section, which does not inc
lude the patient id,

provides

access radiology studies in
a patient
-
independent manner
.
Despite the fact that

a

resource can be acc
essed through multiple
sections,
the paths point to the same

underlying resource
, and any updates would be applied to the
sam
e

resource.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

Templates are used in the root file to define the HDR, but templates MUST NOT appear in requests

to
the server
. Upon receiving a request, the server will find the appropriate section by matching the
section path. If the URL does not match any
template, the HRT will signal an error (
for REST transport,
HTTP 404)
. The creator of the H
DR

SHOULD be certain that the matching process will result in a unique
section without consideration of th
e template variable value
.
An example of bad practice,
whic
h does
not follow the dependent resource pattern
, is the following:


..
/
{Patient.id}/{Study.id}/{Series.id}


↔ ../1234/567/2

Bad Practice

While not forbidden by this standard, this section structure
would lead

to unreadable
paths, potentially
indeterminate for the server trying to
determine the correct section by
match
ing

a given specific path
to

multiple templates.

2.4

Resource Types and Representations

A
resource is a logical
e
ntity that may have multiple
physical
(“on the wire”)
format
s

[13]
.
The

resourc
e
T
ype refers to the class or category of the entity, for example,
Condition, Pr
ocedure,
A
llergy,
or
Visit
.
Sections MUST NOT contain more than one type of resource. The r
esources in a section MUST
correspond by type wi
th the resourceTypeID registered in the root document under the section.

Sometim
es,
an

implementer might want to have a

section
that groups

multiple types, for example,
to
group all

items related to an office visit

(observations, labs, medications, etc.)
.

In this case, we
recommend that the implementer
define a
resource
type to represent the group, for example, an
office visit

resource. This resource

should
have the capability of including

related items as links.
In this
way,

the section
can
have one consistent resourceType, but still provide access to
a
heterogeneous
group of
items.

Each resource
Type

MUS
T have at least one
representation
.

The
representation

denotes a
representation of the resource suitable for exchange, i.e.,
a wire format f
or the resource.

Each
representation MUST have a media type; if not stated, the media type is assumed to be
“application/xml”.
Each
representation

may include validators, used to by client and/or server to
confirm that an exchanged resource conforms to the

given type
specification
.

It is RECOMME
NDED that
the validator be a URL

that resolves to directly the XSD file,
the
Schematron, or similar
validator
.




hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

3

Atom Feed
s

Each section has

an associated
Atom feed

that

lists each resource in the section, and conta
ins

metadata pertaining to each resource.
In the HRT
REST

implementation
, the Atom feed is returned via
an HTTP GET on the section URL.

Atom feeds MUST conform to the
Atom 1.0
Syndication Format

[2]
.

In this section, we profile

the use of Atom in

hData. Th
is

profile provides hData
-
specific semantics for
Atom elements.
Elements
not
specifically mentioned
here MUST be used in accordance with the Atom
1.0
Syndication Format.
For example,

the atom specification states that

<atom:aut
hor> MUST exist at
either the feed level or the level

of individual entries
,
but is not required on entries if given for the
feed.

The Atom feed MAY be extended to support additional features.

3.1

Elements of Atom <feed> profiled for hData

The namespace for th
e following elements is atom
, unless otherwise stated:



title(
xs:string
, 1)

-

This
REQUIRED
element
SHOULD provide a human
-
readable text description of
the feed
.



id(
xs:anyURI
, 1)
-

This REQUIRED element MUST pro
vide a unique identifier for this feed instan
ce
. It
is
RECOMMENDED to use

a
URI

in the urn:uuid schema
.



updated(
xs:dateTime,
1)

-

This
REQUIRED
element
MUST

provide the time
accurate to the second
when the
section

represented by this feed
or any of its child elements were last modified.
Modifications could be new, updated, or deleted
resource
s or
section
s, or changes to the
metadata.



link

rel=”self”

(0..1
)
-

This element
is REQUIRED for

transports (such as HTTP) that identify sections
b
y w
eb resource identifiers (see

[2]
,
Section

4.2.7).
In this case, the

@
href
attribute
MUST have the
preferred URI for retrieving this Atom feed, i.e., the full
URL
path to the section including additional
search

parameters
.

The @
type attribute MUST be ”application/atom+xml”.



link ref=”next”

(0..1)
-

Since feeds can contain a large number of entries, a server may return a
partial list of entries (see
[14]
,
Section

10.1). If so, the list MUST contain a link element with
ref=”next”,
whose "href" value is the URI of the next partial list. The feed
MAY provide a link
elements with “rel” attribute values of “previous”, “first”, and “last”, that can be used to navigate
t
hrough the complete set of

entries. The first such partial list returned MUST contain t
he most
recently edited member r
esources, next partial list will contain the next most recently edited set of
resources, and so on
[14]
.



lin
k ref=”previous” (0..1)
-

see above



link rel=”first” (0..1)
-

see above



link ref=”last”

(0..1)
-

see above



entry(0..*)
-

This element contains represents an individual resource, acting as a container for
metadata and data associated with the resource.

3.2

Elem
ents
of Atom
<entry>

profiled for hData

The namespace for
the following elements is atom
, unless otherwise stated
:


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511



title(xs:string, 1)
-

This REQUIRED element contains a human
-
readable text
short description

of the
resource
.



id
(xs:string, 1)


-

This REQUIR
ED element
is a version
-
independent reference to the resource.
It is
RECOMMENDED
to use a

URL whose

tail element is the logical id of the resource
.



link
(0..1)

-


This element is REQUIRED if the entry contains no content element. The
@
href attribute
of the link
MUST have
a globally unique URI that
resolves to

the specific version of the
resource

referred to by the entry

(if versioning is not supported, then the href MUST resolve to the
resource)
. The @type attribute SHOULD be identical to the
default
media

type of the referenced
resource

(see Section
2.2
)
.



published(xs:dateTime, 0..1)
-

This OPTIONAL element contains the time the resource was ini
tially
created or first available.

If the resource was derived from another origin, this element contains the
time of derivation.



updated
(xs:dateTime, 1)


-

T
his
REQUIRED element contains the last modified time
of the resource
.
If the

resource has never be
en updated,

this element
MUS
T use the
published

time.




content
(0..1)

-

This
OPTIONAL
element
MAY contain

a representation
of the reso
urce
under the
following conditions:

o

The representation of the resource matches the representation of the Atom feed

(e.g.,

XML
with

XML
, or JSON with JSON
)
,

o

There is no privacy or authorization concern releasing the
resource

to all users that can access
the Atom feed. If there are any privacy or security concerns, the
resource

MU
ST NOT be
included in the feed, and

o

There is no performance concern regarding having the additional material in the feed.

3.3

Optional
Metadata

Extensions

for Atom <entry>

Although the HRF is content agnostic, the HRF provide
s

optional metadata augmentation for content
models that do not native
ly support the

data

necessary for understanding the source, history, and
other context information associated with the resource.
Extension

is unnecessary for some content
models

that include context information as part of the content model. For example,
F
HIR defines a

Provenance resource that tracks information about the entities, activities, and people involved in
producing a resource
.
In this case, P
rovenance information exists

inside

the logical
model,
not
metadata that lives
somewhere
outside the model
.
However, there are

other resource types, such as

jpg image
s and

pdf document
s, where context

information
cannot be easily added

to the resource
.


For these uses, hData provides an optional provenance metadata element represents the origins and
processing

history of a resource, including the information sources used for creating or updating the
resource. A UML diagram of the provenance element is shown in
Figure
6
.
In the following, all
elements and attributes are from the
h
md

namespace, unless otherwise specified.



c
onfidentiality (0..1, xs:string)


This
optional
element contains controls for confidentiality
. It is
RECOMMENDED to use a
clinical document confidential
ity code

from CDA R2

[15]



provenance(0..*)
-

This OPTIONAL element represents the activities, parties, and additional
information involved in producing, modifying, or distributing a resource. It is RECOMMENDED to

hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

include one pro
venance element for each significant lifecycle event affecting the resource (see
below).

Elements of
<
provenance
>
:



eventT
ype (xs:
s
tring, 1)
-

It is RECOMMENDED to use one of the following
event

types, derived
from the
HL7 EHR
Lifecycle

Model

[16]
:

o

originate

-

initial event of creating the resource

o

receive
-

initial
or update
event of receiving this resource
from an external party


o

amend
-

information in the resource was updated

(use if no more specific action applies)

o

translate

-

language translation was provided

o

verify
-

a party has reviewed and verified the
resource

o

attest
C
omplete
-

a party has confirmed

the resource

is complete

o

attest
A
ccurate

-

a party has confirmed the resource is correct

o

view
-

the resource is accessed or
viewed

o

transmit

-

a copy of the resource has been provided to a third party

o

deidentify
-

removing identifying information from the resource

o

reidentify
-

adding identifying information to the resource

o

converge
-

information from other sources has been merge
d into this resource

o

archive
-

re
source

was copied to an archive

o

destroy
-

resource was marked as deleted

o

deprecate

-

record is marked as deprecate
d



recorded(xs:dateTim
e,1)
-

The time the event
was recorded



subject
(xs:anyURI,0..1)
-

A identifier of the res
ource produced as a result of the event, which may
be
a version
-
specific URI of the
resource.

If not provided, it is assumed the subject is the logical
resource described by the entry.



description(xs:string,0..1)
-

A
n OPTIONAL

description of the
event



part
y(1..*)


This REQUIRED element identifies the persons, organizations, and information
sources involved in the event



signature (
xs:string,
0..*)
-

Th
is OPTIONAL element contains a digital

signature information on the
resource

referred to by the subject o
f this
provenance
. This signature MUST conform to the
W3C
XML Signature Syntax and Processing (Second Edition)

[17]

specification. The digital signature is
always included as a plain string with appropriate escaping for both XML and JSON.


Elements and attributes of <party>:



partyT
ype(xs:string,1)
-

Identifies the type of party. It is RECOMMENDED to use the
following v
alue
set:

o

practi
ti
oner
-

the participant was

a healthcare provider

o

patient
-

the participant was
the patient or a person acting on behalf of the patient


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

o

organization
-

the participant was
an organization

o

software
-

the participant was
a software process

o

re
source

-

the participant was a resource

o

document
-

the participant is an external document



role (xs:string, 1)
-

This attribute indicates

the specific role of the party
. It is RECOMMENDED to use
the following list of roles, which if used MUST semantically correspond to the authoritative list of
participant roles in
HL7 CDA R2 header
:

o

authenticator
-

provided legal attestation

o

author

-

originated the resource

o

custo
dian

-

acted on the resource as an information maintainer

o

e
nterer

-

entered the information

o

informant

-

human who provided information that contributed to the resource

o

participant

-

participated in some other role besides ones mentioned here

o

performer

-

pe
rformed the activity

o

source

-

non
-
human information source from which the resource is derived

o

t
arget

-

received information

o

verifier
-

validated the completeness or accuracy of the record



identifier (xs:string, 1
)

An i
dentifier of the
party, such as a na
me or URI.



description(xs:string,

0..1)
-

Human
-
readable description of the party



provenance
(
provenance
, 0..*)
-

If the party is an information source (the type is resource or
document and the role is source),
provenance

elements can be used recursively to give the
provenance

of that information source. In this way, the metadata can provide a complete trace of
all information sources, back to origin.


Figure
6
. UML Diagram of optional provenance
metadata e
lement



hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

3.4

Optional
Metadata

Processing

The
metadata

for a
resource

is only valid for the system that currently hosts the
resource
.
If an HDR is
copied in portions or in its entirety, the system to which it is copied MUST recompute the
metadata

acco
rding to the following rules:

1.

The
<atom:id>

MUST
be kept unchanged.

2.

The

provenance

MUST be updated by adding a new
provenance

element.

3.

Confidential
i
ty SHOULD be copied verbatim.

If a specific hData Content Profile requires additional or special metadata

processing instructions, these
processing instructions MUST be specified

in the content profile
.


3.5

XML and JSON Representations of Atom Feed

The Atom feed can be returned in either XML or JSON formats. As described in the HRT specification,
the preferred format is given in the request via a format parameter in the URL query string, or as part
of
content negotiation, via
the

Accept HTTP

header.
The pseudo
-
code for XML representation of the
Atom feed is given in
Figure
7
.

The

JSON
template for the Atom feed is given in
Figure
8
.

<?xml version="1.0" encoding="utf
-
8"?>

<feed xmlns="http://www.w3.org/2005/Atom"


xmlns:hmd=
"
http://
www.hl7.org
/schemas/hdata/2013/08/
hmd
"
>


<title>
<!
--

1..1

string

Text statement of purpose

--
>
</title>


<id>
<!
--

1..1

xs:anyURI

Unique uri for this feed

--
>
</id>


<updated>
<!
--

1..1

xs:dateTime

When the section was last updated

--
>
</updated>


<link rel="self" href="[URI for retrieving this Atom feed]"/>
<!
--

0..1

--
>


<link

rel="first" href="[paging: url for first page of result]"/>
<!
--

0..1

--
>


<link rel="previous" href="[paging: url for previous page of result]"/>
<!
--

0..1

--
>


<link rel="next" href="[paging: url for next page of result]"/>
<!
--

0..1

--
>


<link rel="las
t" href="[paging: url for last page of result]"/>
<!
--

0..1

--
>


<author><!
--

0..1 Who created resource?
--
>


<name>
<!
--

1..1

string

Name of Human or Device that

authored the resource

--
>
</name>


<uri>
<!
--

0..1

uri

Link to the resource for the author

--
>
</uri>


</author>


<entry><!
--
0..*

--
>


<title>
<!
--

1..1

string

Text summary of resource

--
>
</title>


<id>
<!
--

1..1

uri

Logical id
(uri) for this resource

--
>
</id>


<link rel="self" href="[
Version
-
specific URI of resource]
">
<!
--

0..1

--
>
</link>


<published>
<!
--

0..1

xs:dateTime

Time reso
urce was initially available

--
>
</published>


<updated>
<!
--

1..1

xs:dateTime

Time of last update for resource

--
>
</updated>


<!
--

hData Metadata Extensi
ons:

--
>


<hmd:confidentiality>
<!
--

0..1

string

Confidentiality code

--
>
</hmd:confidentiality>


<hmd:provenance><!
--

0..1 Lifecycle events of resource
--
>


<hmd:eventType>
<!
--

1..1

string

Lifecycle event type

--
>
</hmd:eventType>


<hmd:recorded>
<!
--

1..1

string

Time of the event

--
>
</hmd:recorded>


<hmd:subject>
<!
--

0..1

xs:anyU
RI

Version of resource produced by this event

--
>


</hmd:subject>


<hmd:description>
<!
--

1..1

string

Description of the event

--
>
</hmd:description>



<hmd:party><!
--

1..* Persons, organizations, and information involved in event
--
>


<hmd:partyType>
<!
--

1..1

string

Type of party

--
>
</hmd:partyType>


<
hmd:role>
<!
--

1..1

string

Role of party in event

--
>
</hmd:role>


<hmd:identifier>
<!
--

1..1

string

Name or URI of party

--
>
</hmd:identifier>


<hmd:description>
<!
--

1..1

string

Description of party

--
>
</hmd:description>


<
hmd:provenance>


<!
--

0..1 Further provenance, if party is an information source
--
>


</hmd:provenance>


</hmd:party>


<S
ignature xmlns="http://www.w3.org/2000/09/xmldsig#">


<!
--

0..1

Enveloped Digital Signature


--
>



</S
ignature>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


</hmd:provenance>


</entry>


<S
ignature xmlns="http://www.w3.org/2000/09/xmldsig#">


<!
--

0..1

Enveloped Digital Signature


--
>


</S
ignature>

</feed>

Figure
7
. XML Pseudo
-
code for Atom feed


{


"feed":{


"@xmlns":"http://www.w3.org/2005/Atom",


"@xmlns:hmd":"
http://www.hl7.org/schemas/hdata/2013/08/metadata
",


"@xmlns:ds":"
http://www.w3.org/2000/09/xmldsig#
",


"title":"text description",


"id":"unique id for this feed",


"link":[{


"@rel":"link relation: self|first|previous|next|last",


"@href":"link URL"


}],


"updated":"time of creation of feed",


"author":[{


"name":"name of author of feed",


"uri":"uri for author of feed"


}],


"entry":[{


"title":"description of entry",


"id":"logical id (URI) for this resource",


"link":[{


"@type":"default media type of resource",


"@href":"URI for this version of the resource"


}],


"published":"resourc
e time of creation",


"updated":"resource time of last update",


. . . optional hData metadata . . .


"hmd:confidentiality":"clinical document confidentiality code",


"hmd:provenance":[{


"hmd:eventType":"lifecycle event type",



"hmd:recorded":"time of the event",


"hmd:subject":"optional URI of version of resource resulting from event",


"hmd:description":"description of the event",


"hmd:party":[{


"hmd:partyType":"type of party",


"hmd:role":"role played by party in the event",


"hmd:identifier":"name or URI identifier of the party",


"hmd:description":"description of the party",


"hmd:provenance":[{


. . . optional additional pro
venance if party is an information source . . .


}]


}],


"ds:S
ignature":"optional digital signature"


}]


}]
,


"ds:Signature":"optional digital signature"


}

}

Figure
8
. JSON r
epresentation o
f

Atom f
eed




hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

4

hData Content Profiles

4.1

Purpose of hData Content Profiles

An hData Content Profile (HCP) is an implementation guide for hData. HCPs are needed because hData
does not
stipulate

the specific
layout, purpose,

or

behavior of
an
HDR
. An HCP can be
created

by any
person or organization who wishes to standardize the use of
hData for a particular purpose

or

business

domain
. By crea
ting,

sharing
, and conforming to

HCPs, information exchange partners can align and
standardize their inform
ation services.
C
lients

can read the ro
ot file

and determin
e

which content
pro
files are implemented
, then reference

the documentation of
those HCPs

to

learn

more about the
HDR.

HCPs

are not required to use hData. A HDR can be created with
out

conforming to
any external
documentation. However, this approach naturally tends to limit the use of the HDR

to small teams that
share a common understanding of the HDR. The main purpose of an HCP is to enhance the scalability
of information exchange beyond small, highl
y
-
connected

groups by encouraging uniform use.

Note that a single HDR can be compliant with multiple HCPs.
In this case, the implementer should copy
and combine the information in the example root files from each HCP to create a single
root file,
creating
a combined list of profiles, sections, and resourceTypes. Any conflicts in resourceTypeIDs that
occur as a result of this process must be manually resolved.

4.2

Suggested Contents of
hData Content Profile
s

Although t
he

content and

format of an hData Content P
rofile is not specified by this document, and is
not part of the hData standard
,
there is certain information that implementers and clients will need

to
create or use an hData Record that conforms to an HCP, including:



An e
xplanation of the
purpose and

applicable business requirements

for the HCP



A list of the required and optional sections and their paths relative to the base URL, establishing
the hierarchical structure of the HDR



A list of all the resource types

and documentation,

or reference to source documentation,
explaining the syntax and semantics of the resource. If the HCP contains XML resources, a complete
list

or reference to

all XML schemas

should be included
.



A sample root file

for the HCP

that can be copied by an imple
menter wanting to create a compliant
HDR.



If the domain for the HCP must adhere to a behavioral model or a set of business rules, these
should be documented with applicable UML diagrams or similar documentation, including the
lifecycle of resources, if any
.



Search parameters
and query strings associated with sections of the HDR.
When specified
, query
strings can be appended to section paths to filter the contents of a section, with the result being
returned as an Atom feed.



Security requirements, such as pr
ivacy policy, patient consent, and access control that apply to the
data stored in the overall record, as well as each section.



Documentation of
additional testing or

conformance requirements, if any
.


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511



A version
-
aware URL for identification that should
res
olve to a publicly accessible HTML resource
that contains links to all documents needed for the HCP.
This is needed for any root file conforming
to the HCP.



If there are multiple versions of the HCP, a change log to help users track changes

between
version
s.

Any
suitable

technical document format can be used for an HCP. For example, if the HCP is to be used
in the US realm by US Federal Government, authors could adopt the U.S. National Information
Exchange (NIEM) Information Exchange Package Documentation (
IEPD) format
.





hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

5

Normative
Schemas

5.1

Root Document

Schema

This section contains the schema for the root document (see Section
2.2
). All instances of root
documents M
UST validate against this schema definition.

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"

targetNamespace="http://hl7.org/schemas/hdata/2013/08/hrf"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:hrf="http://hl7.org/sch
emas/hdata/2013/08/hrf">


<xs:element type="xs:string" name="id"/>

<xs:element type="xs:float" name="version"/>

<xs:element type="xs:dateTime" name="created"/>

<xs:element type="xs:dateTime" name="lastModified"/>

<xs:element type="xs:string" name="referenc
e"/>

<xs:element type="xs:string" name="path"/>

<xs:element type="xs:string" name="profileID"/>

<xs:element type="xs:boolean" name="resourcePrefix"/>

<xs:element type="xs:string" name="resourceTypeID"/>

<xs:element type="xs:boolean" name="metadataSupport"/
>

<xs:element type="xs:string" name="mediaType"/>

<xs:element type="xs:string" name="validator"/>


<xs:group name="extensionElement">


<xs:sequence>


<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>


<xs:any
namespace="##local" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>


</xs:sequence>

</xs:group>


<xs:element name="profile">


<xs:complexType>


<xs:sequence>


<xs:element ref="hrf:id"/>


<xs:element ref="hrf:reference"/>


<x
s:group ref="hrf:extensionElement" minOccurs="0" maxOccurs="unbounded"/>


</xs:sequence>


</xs:complexType>

</xs:element>


<xs:element name="section">


<xs:complexType>


<xs:sequence>


<xs:element ref="hrf:path"/>


<xs:element ref="hrf:pr
ofileID" minOccurs="0" maxOccurs="unbounded"/>


<xs:element ref="hrf:resourcePrefix" minOccurs="0"/>


<xs:element ref="hrf:resourceTypeID" minOccurs="0"/>


<xs:element ref="hrf:metadataSupport" minOccurs="0"/>


<
xs:group ref="hrf:extensionElement" minOccurs="0" maxOccurs="unbounded"/>


<xs:element ref="hrf:section" minOccurs="0" maxOccurs="unbounded"/>


</xs:sequence>


</xs:complexType>

</xs:element>


<xs:element name="representation">


<xs:complexType>


<xs:sequence>


<xs:element ref="hrf:mediaType"/>


<xs:element ref="hrf:validator" minOccurs="0" maxOccurs="unbounded"/>


<xs:group ref="hrf:extensionElement" minOccurs="0" maxOccurs="unbounded"/>


</xs:sequence>


</xs:complexType>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

</xs:element>


<xs:element name="resourceType">


<xs:complexType>


<xs:sequence>


<xs:element ref="hrf:id"/>


<xs:element ref="hrf:reference"/>


<xs:element ref="hrf:representation" minOccurs="0" maxOccurs="unbounded"/>


<xs:group

ref="hrf:extensionElement" minOccurs="0" maxOccurs="unbounded"/>


</xs:sequence>


</xs:complexType>

</xs:element>


<xs:element name="Root">


<xs:complexType>


<xs:sequence>


<xs:element ref="hrf:id"/>


<xs:element ref="hrf:version"/>


<xs:element ref="hrf:created"/>


<xs:element ref="hrf:lastModified"/>


<xs:element ref="hrf:profile" minOccurs="0" maxOccurs="unbounded"/>


<xs:element ref="hrf:section" maxOccurs="unbounded"/>


<xs:element ref="hrf:resourceType"
minOccurs="0" maxOccurs="unbounded"/>


<xs:group ref="hrf:extensionElement" minOccurs="0" maxOccurs="unbounded"/>


</xs:sequence>


</xs:complexType>

</xs:element>

</xs:schema>


5.2

Metadata

Extension

Schema

This section contains the schema for the
hData

metadata

extensions

(see Section

3.3
). All instances of
metadata documents MUST validate against this schema definition.

<xs:schema attributeFormDefault="unqu
alified" elementFormDefault="qualified"

targetNamespace="
http://hl7.org/schemas/hdata/2013/08/hmd
"

xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:hmd="http://hl7.org/schemas/hdata/2013/08/hmd">

<xs:import na
mespace="http
://www.w3.org/2005/Atom"

schemaLocation="http://
www.projecthdata.org/hd
ata/schemas/hrf2/atom.xsd
"/>


<xs:element type="xs:string" name="confidentiality"/>

<xs:element type="xs:string" name="eventType"/>

<xs:element type="xs:dateTime"
name="recorded"/>

<xs:element type="xs:anyURI" name="subject"/>

<xs:element type="xs:string" name="description"/>

<xs:element type="xs:string" name="partyType"/>

<xs:element type="xs:string" name="role"/>

<xs:element type="xs:string" name="identifier"/>

<x
s:element type="xs:string" name="signature"/>


<xs:element name="party" type="hmd:PartyType"/>

<xs:element name="provenance" type="hmd:ProvenanceType"/>


<xs:complexType name="PartyType">


<xs:sequence>


<xs:element ref="hmd:partyType"/>


<xs:elemen
t ref="hmd:role"/>


<xs:element ref="hmd:identifier"/>


<xs:element ref="hmd:description"/>


<xs:element ref="hmd:partyType"/>


<xs:element name="provenance" type="hmd:ProvenanceType" minOccurs="0"
maxOccurs="unbounded"/>


<xs:element ref="h
md:signature" minOccurs="0"/>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


</xs:sequence>

</xs:complexType>


<xs:complexType name="ProvenanceType">


<xs:sequence>


<xs:element ref="hmd:eventType"/>


<xs:element ref="hmd:recorded"/>


<xs:element ref="hmd:subject"/>


<
xs:element ref="hmd:description"/>


<xs:element name="party" type="hmd:PartyType" maxOccurs="unbounded"/>


</xs:sequence>

</xs:complexType>


</xs:schema>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

6

Examples

6.1

hData Record
Example (Non
-
Normative)

This section outlines
an

hData Record that conta
ins
patient and practi
ti
oner information, patient
-
specific
Consolidated CDA

(CCD
A
),
FHIR resources
containing information about

conditions and
medications,
and DICOM
studies
. The following
are
the
resource
-
containing section paths
:

../Patients

../Practitioners

../Patients/{Patient.id}/
CCDA

../Patients/{Patient.id}/Conditions

../Patients/{Patient.id}/Medications

../Patients/{Patient.id}/Radiology/Studies

../Patients/{Patient.id}/Radiology/Studies/{Study.id}/Series/

../Patients/{Patient.id}/Radiol
ogy/Studies/{Study.id}/Series/{Series.id}/Images

In this example, we assume

t
he s
ections ending with identifiers, such as ../Patients/{Patient.id},
do not
contain resources
, therefore a resourceTypeID does not appear for these sections
.

We also assume the

hierarchy is described by a

single HCP, and the resource prefix is used by default.

FHIR resources are
used for patients, practitioners, conditions, and medications.

6.2

R
oot Document

Example

(Non
-
Normative)

The contents of the hData Record are described

in

the root document

(s
ee S
ection
2.2
)
.
For the hData
record outlined above, the root

document looks like this
:

<?xml version="1.0"
encoding="UTF
-
8"?>

<
Root

xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance"


xmlns="http://hl7.org/schemas/hdata/2013/08/hrf">


<
id
>urn:uuid:ab443e5e
-
b6a7
-
e951
-
956c
-
caef491bbc08</id>


<
version
>2.0</version>


<
created
>2013
-
07
-
14T15:07:38.6875000
-
05:00</created>


<
lastModified
>2013
-
07
-
16T08:12:02.2832000
-
05:00</lastModified>


<
profile
>


<
id
>SampleHCP</id>


<
reference
>http://example.com/hcp/samp
leHCP.pdf</reference>


</profile>


<
section
>


<
path
>Practitioners</path>



<
profileID
>SampleHCP</profileID >


<
resourceTypeID
>Practitioner</resourceTypeID>


</section>


<
section
>


<
path
>Patients</path>


<
profileID
>SampleHCP</profileID >


<
resourceTypeID
>Patient</resourceTypeID>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


<section>


<path>{Patient.id}</path>


<section>


<path>CCDA</path>


<resourceTypeID>CCDA</resourceTypeID>


</section>


<section>


<path>Condition
s</path>


<resourceTypeID>Condition</resourceTypeID>


</section>


<section>


<path>Medications</path>


<resourceTypeID>MedicationPrescription</resourceTypeID>


</section>


<section>


<path>Radiology</path>


<section>


<path>
Studies</path>


<resourceTypeID>ImagingStudy</resourceTypeID>


<section>


<path>{Study.id}</path>


<section>


<path>Series</path>


<resourceTypeID>Series</resourceTypeID>


<section>


<path>{Series.id}</path
>


<section>


<path>Images</path>


<resourceTypeID>Image</resourceTypeID>


</section>


</section>


</section>


</section>


</section>


</section>


</section>


</section>


<
resourceType
>


<
id
>Practitioner</id>


<
reference
> http://hl7.org/implement/standards/fhir/practitioner.htm</reference>


<
representation
>


<
mediaType
>application/fhir+xml</mediaType>


<
validator
>http://hl7.org/implement/standards/fhir/practitioner.xsd</validator
>


<
validator
>http://hl7.org/implement/standards/fhir/practitioner.sch</v
alidator>


</representation>


</resourceType>

<
resourceType
>


<
id
>Patient</id>


<
reference
> http://hl7.org/implement/standards/fhir
/patient.htm</reference>


<
representation
>


<
mediaType
>application/fhir+xml</mediaType>


<
validator
>http://hl7.org/implement/standards/fhir/patient.xsd</validator>


<
validator
>http://hl7.org/implement/standards/fhir/patient.sch</validator>


</representation>


</resourceType>


<resourceTy
pe>


<
id
>CCDA</id>


<
reference
>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258


</reference>


<
representation
>


<
mediaType
>application/xml</mediaType>


<
validator
>https://www.lantanagroup.com/validator/</validator>


</representation>


</resourceType>


<resourceType>


<
id
>Condition</id>


<
reference
>http://hl7.org/implement/standards/fhir/condition.htm</reference>


<
representation
>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


<
mediaType
>application/fhir+xml</mediaType>


<
validator
>http://hl7.org/implement/standards/fhir/condition.xsd</validator>


<
validator
>http://hl7.org/implement/standards/fhir/condition.sch</validator>


</representation>


</resourceType>


<resourceType>


<
id
>MedicationPrescription</id>


<
reference
></reference>


<
representation
>


<
mediaType
>application/fhir+xml</mediaType>


<
validator
>http://hl7.org/implement/standards/fhir/medicationprescription.xsd


</validator>


<
validator
>http://hl7.org/implement/standards/fhir/ medicationprescription.sch


</validator>


</representation>


</resourceType>


<resourceType>


<
id
>ImagingStudy</id>


<
reference
>http://medical.nema.org/Dicom/2011/11_03pu.pdf</reference>


<
representation
>


<
mediaType
>application/dicom</mediaType>


</representation>


</resourceType>


<resourceType>


<
id
>Series</id>


<
reference
>http://medical.nema.org/Dicom/2011/11_03pu.pdf</reference>


<
representation
>


<
mediaType
>application/dicom</mediaType>


</representation>


</resourceType>


<resourceType>


<
id
>Imag
e</id>


<
reference
>http://medical.nema.org/Dicom/2011/11_03pu.pdf</ref
erence>


<
representation
>


<
mediaType
>image/jpeg</mediaType>


<
validator
>TBD</validator>


</representation>


<
representation
>


<
mediaType
>image/png</mediaType>


<
validator
>TBD</validator>


</representation>


</resourceType>

</Root>


6.3

Atom Feed Example

(Non
-
Normative)

The
Atom feed provides a list of

resources

at a section level

(see S
ectio
n
3
). Below is a sample feed for
the
C
onditions

section
.

Entries are metadata for FHIR Condition resources, pursuant to the
resourceType of the Conditions section.
Although
FHIR resources have an internal model of
provenance
, hData metadata is provided for illustration purposes
.
Other sections will have very similar
feeds.


<?xml version="1.0" encoding="utf
-
8"?>

<feed xmlns="http://www.w3.org/2005/Atom">


<title>List of cond
itions</title>


<id>urn:uuid:1145c09c
-
73d0
-
4297
-
9835
-
620e4afa9deb</id>


<updated>2013
-
07
-
18T11:01:02.91000
-
05:00</updated>


<link rel="self" href="http://example.com/hDataServerRoot/1234/Conditions"/>


<author>


<name>The hData Server at Example.com
</name>


<uri>http://example.com/hDataServerRoot</uri>


</author>


<entry>


hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511


<title>Tonsillitis</title>


<id>http://example.com/hDataServerRoot/1234/Conditions/@7281</id>


<link href="http://example.com/hDataServerRoot/1234/Conditions/@7281"/>


<published>2009
-
02
-
28T09:44:55.11000
-
05:00</published>


<updated>2009
-
03
-
04T10:13:28.52000
-
05:00</updated>


<summary>Presentation moderate tonsilitis culture taken</summary>


<
confidentiality xmlns="http://www.hl7.org/schemas/hdata/2013/08/hmd">low


</confidentiality>


<provenance xmlns="http://www.hl7.org/schemas/hdata/2013/08/hmd">


<eventType>amend</eventType>


<recorded>2009
-
03
-
04T10:13:28.52000
-
05:00</re
corded>


<description>Strep test positive</description>


<party>


<partyType>practitioner</partyType>


<role>author</role>


<identifier>Dr. Zachary Smith</identifier>


<description>PCP</description>


</party>


</provenance>


</entry>


<entry>


<title>Contact dermatitis</title>


<id>http://example.com/hDataServerRoot/1234/Conditions/@29283</id>


<link href="http://example.com/hDataServerRoot/1234/Conditions/@29283"/>


<published>2011
-
07
-
06T10:30:33.
07000
-
05:00</published>


<updated>2011
-
07
-
06T10:30:33.07000
-
05:00</updated>


<summary>Localized irritation due to poison ivy exposure</summary>


</entry>

</feed>



hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

7

Glossary (Non
-
Normative)

Fast Healthcare Interoperable Resources (FHIR)

[3]

-
An HL7 initiative that defines a set of granular
objects (“resources”) that represent the basic elements of healthcare, such as patients, problems,
medications, and the like, and defines REST services for exchanging these objects.

hDat
a Record (HDR)

-

A specific instance of an hData service endpoint, using the hData Record
Format, consisting of a specific virtual hierarchical organization of exchangeable resources, including a
root file that declares the structure and the type of resou
rces associated with each position in the
hierarchy. The HDR optionally declares the conformance to one or more hData Content Profiles (HCPs).

hData Record Format (HRF)

-

The subject of this specification, the HRF defines the
hierarchical
presentation of d
ata at a
web interface,
security considerations associated with the data, links to
formal data definitions, as well as provenance and other critical information
.

hData RESTful Transport (HRT)
[4]
-

The HRT is an
specification

of the Object Management Group
(OMG)
defin
ing

how
an

abstract hierarchical organization defined within the HRF specification
can be

access
ed

and modified through a
REST

approach, using HTTP as the access protocol. It creates a unique
mapping
of the HDR
to
a URL

structure, and defines how HTTP verbs such as GET, P
OST
, DELETE, etc.
affect the underlying information.

hData Content Profile (HCP)
-

An hData implementation guide that profiles a purpose
-
specific use of
hData. An HCP stipulates a particular res
ource hierarchy, resource types, business rules, and other
information needed to implement information exchanges in a domain using hData.

Representational State Transfer (REST)

[13]

-

A popular web
-
oriented style of stateless
client
-
server
interaction that uniquely identifies a set of resources by URIs and provides basic create, read, update,
and delete operations, most often implemented using HTTP.

Retrieve, Lo
cate, and Update Service (RLUS)

[5]

-

A standard of the Object Management Group (OMG)
and HL7

defining the capabilities, responsibilities, inputs, outputs, and expected behavior of a system
component capable of querying information and returning data and metadata between systems
.



hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

8

Bibliography


[1]

Health Level 7 International, "Clinical Document Architecture Release 2," May 2005.
[Online]. Available:
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7. [Accessed
July 2013].

[2]

IETF Network Working Group, "Th
e Atom Syndication Format," December 2005. [Online].
Available: http://www.ietf.org/rfc/rfc4287. [Accessed 1 July 2013].

[3]

G. Grieve, E. Kramer and L. Mckenzie, "FHIR v0.09," 2013. [Online]. Available:
http://hl7.org/implement/standards/fhir/. [Accesse
d 1 July 2013].

[4]

G. Beuchelt and et al., "hData RESTful Transport v 1.0," 2012. [Online]. Available:
http://www.omg.org/spec/HData/1.0/Beta2.

[5]

Health Level Seven International, "HL7 Resource Location and Updating Service," 2006.

[6]

IETF
Network Working Group, "Key words for use in RFCs to Indicate Requirement Levels,"
March 1997. [Online]. Available: http://www.ietf.org/rfc/rfc2119.txt. [Accessed 1 July
2013].

[7]

IETF Network Working Group, " The application/json Media Type for JavaScr
ipt Object
Notation (JSON)," July 2006. [Online]. Available: http://tools.ietf.org/html/rfc4627.
[Accessed July 2013].

[8]

G. Beuchelt, R. Dingwell, A. Gregorowicz and H. Sleeper, "hData
-

A Simple XML
Framework for Health Data Exchange," in
Proceedings
of Balisage: The Markup Conference
2009
, Montréal, 2009.

[9]

Office of the National Coordinator for Health Information Technology Standards and
Interoperability Framework, "RESTful Health Exchange (RHEx)," 2012. [Online]. Available:
http://wiki.siframew
ork.org/RHEx. [Accessed July 2013].

[10]

IETF, "URI Generic Syntax," January 2005. [Online]. Available:
http://tools.ietf.org/html/rfc3986. [Accessed July 2013].

[11]

International Organization for Standarization (ISO), "Date and Time Format
-

ISO 8601
,"
December 2004. [Online]. Available:
http://www.iso.org/iso/home/standards/iso8601.htm. [Accessed 1 July 2013].

[12]

National Electrical Manufactureres Association (NEMA), "Digital Imaging and
Communications in Medicine (DICOM)," Medial Imaging & Techn
ology Alliance, August

hData Record Format, Release 2


©2009
-
13 The MITRE Corporation. Unlimited distribution. Public Release Approval 09
-
4511

2011. [Online]. Available: http://medical.nema.org/standard.html. [Accessed 1 July 2013].

[13]

R. Fielding, "Architectural Styles and the Design of Network
-
based Software
Architectures," Irvine, 2000.

[14]

IETF Network Working
Group, "The Atom Publishing Protocol," October 2007. [Online].
Available: http://www.ietf.org/rfc/rfc5023. [Accessed July 2013].

[15]

Health Level Seven International, "CDA Relase 2," [Online]. Available:
http://www.hl7.org/implement/standards/product_br
ief.cfm?product_id=7.

[16]

Health Level Seven International, "HL7 EHR System Functional Model, R1.1," July 2012.
[Online]. Available:
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=269. [Accessed
July 2013].

[17]

W3C Consortium, "W
3C XML Signature Syntax and Processing (Second Edition)," June
2008. [Online]. Available: http://www.w3.org/TR/xmldsig
-
core. [Accessed July 2013].