NISTIR 7411

The Architecture Development Facilitator (ADF) 

First year report 

Steven J. Fenves 

Eswaran (Sub) Subrahmanian 

Puja Goyal 

Jean-Cyrus Angbo 

Faouzi Daoud 

Ram D. Sriram 
NISTIR 7411 

The Architecture Development Facilitator (ADF) 

First year report 

Steven J. Fenves 

Eswaran (Sub) Subrahmanian 

Puja Goyal 

Jean-Cyrus Angbo 

Faouzi Daoud 

Ram D. Sriram 

March, 2007 

ADF report 1
ABSTRACT 

This document serves as the summary report on the first year’s progress on the Architecture 

Development Facilitator (ADF) project covering the activities from December 15, 2005, to 

December 15, 2006. The ADF is intended to assist the Office of Network Coordinator for 

Health Information Technology (ONC) of the Department of Health and Human Services 

(HHS) and its agents in the deployment of the Nationwide Health Information Network 

(NHIN). ADF will serve as the repository of a set of predefined compatible health care IT 

components, called artifacts, which can then be combined to design, configure and deploy a 

large variety of health care IT system architectures. The design of ADF responds to the 

evolving nature of the NHIN by making absolutely no assumptions about the upper levels of 

the NHIN architecture and by not imposing any constraints on the architecture. 

An artifact is defined in ADF as either: (a) a service or system component of NHIN (service 

artifact) or (b) a unit of information interchanged between service artifacts (information unit 

artifact). Artifacts are represented in the ADF by a generic template applicable to all artifact 

types, type-specific template extensions for each type, and by the relationships between the 

artifacts. An example of the representation is presented in terms of the harmonized use cases 

released by the ONC. A sampling of distinct network architectures that may be configured from 

the sample set of artifacts is presented for illustrative purposes. 

Initial thoughts are summarized on a number of architectural issues considered during the past 

year that have not yet been fully developed, as well as the directions for the work we expect to 

undertake in the second year of the project. 

Keywords 

Health care networks; network architecture; bottom-up design; metamodeling. 

ADF report 2
TABLE OF CONTENTS 

ABSTRACT..........................................................................................................................2 

TABLE OF CONTENTS......................................................................................................3 

LIST OF FIGURES ..............................................................................................................4 

LIST OF TABLES................................................................................................................5 

LIST OF ACRONYMS ........................................................................................................6 

1. Introduction...................................................................................................................7 

2. Historical precedents.....................................................................................................7 

3. The structure of NHIN and the role of ADF.................................................................7 

4. The structure of ADF....................................................................................................8 

5. Artifacts.........................................................................................................................9 

6. An illustrative example ...............................................................................................12 

7. Sample architectures...................................................................................................17 

8. Aggregate artifacts......................................................................................................20 

9. Initial thoughts on ADF architectural issues...............................................................23 

10. Future work.................................................................................................................28 

References...........................................................................................................................29 

Appendix A – Data structure ..............................................................................................31 

Appendix B – Correspondence to Use Cases .....................Error! Bookmark not defined.

Appendix C – Comparison of architectures........................................................................48 

ADF report 3
LIST OF FIGURES 

Figure 1. Network of artifact interactions – laboratory result reporting.....................................15 

Figure 2. Combined network of artifact interactions – three use cases......................................17 

Figure 3a. Fully centralized architecture ....................................................................................18 

Figure 3b. Centralized architecture.............................................................................................19 

Figure 3c. Architecture with centralized IT services..................................................................19 

Figure 3d. Decentralized architecture.........................................................................................20 

Figure 3e. Fully decentralized architecture.................................................................................20 

Figure 4. An illustrative glass box aggregate artifact .................................................................21 

Figure 5. An illustrative black box aggregate artifact.................................................................22 

Figure 6. Initial architecture of ADF prototype..........................................................................27 

ADF report 4
LIST OF TABLES 

Table 1. Classification of artifact types ......................................................................................10 

Table 2. Classification of relationship types...............................................................................12 

Table 3a. Electronic Health Record Use Case service artifacts.................................................13 

Table 3b. Electronic Health Record Use Case information unit artifacts...................................14 

Table 3c. Bio-Surveillance Use Case service artifacts ...............................................................15 

Table 3d. Bio-Surveillance Use Case information unit artifacts ................................................15 

Table 3e. Consumer Empowerment Use Case service artifacts .................................................16 

Table 3f. Consumer Empowerment Use Case information unit artifacts...................................16

Table 4. Generalized architectures..............................................................................................18 

Table 5. Classification of message artifacts................................................................................22 

ADF report 5
LIST OF ACRONYMS 

ADF Architecture Development Facilitator 

CCHIT Certification Commission for Health Information Technology 

CDO Care delivery organization 

EHR Electronic Health Records 

EMR Electronic medical record system 

FHA Federal Health Architecture 

HHS Department of Health and Human Services 

HITSP Healthcare Information Technology Standards Panel 

LIS Laboratory information system 

METIS An Enterprise Architecture (EA) platform 

MPI Master Person/Patient Index 

NCVHS National Committee on Vital and Health Statistics 

NHIN Nationwide Health Information Network 

ONC Office of Network Coordinator for Health Information Technology 

PHA Public health agency 

PHR Patient health record system 

RLS Record locator service 

ADF report 6
1. Introduction 

This document serves as the summary report on the first year’s progress on the Architecture 

Development Facilitator (ADF) project for the Office of the Network Coordinator for Health 

Information Technology (ONC) in the Department of Health and Human Services (HHS), 

covering the activities from December 15, 2005, to December 15, 2006. 

Briefly, the ADF is intended to serve as the repository of a set of predefined compatible health 

care IT components, called artifacts, which can then be combined to design, configure and 

deploy a large variety of health care IT system architectures. 

2. Historical precedents 

The concept of bottom-up construction from compatible plug-and-play components being 

developed by the ONC in HSS and facilitated by the ADF may be novel in IT system design, 

but it has analogs in a number of other fields. 

In manufacturing, the concept was started in the first half of the 19th century by Samuel Colt 

and Cyrus McCormick with their quest for interchangeable components for revolvers and 

reapers, respectively. Geared towards mass production in its first 150 years, by the end of the 

20th century the concept, variously renamed “agile manufacturing,” “product families,” “mass 

customization” and “economical batch size of one,” became widely used for the production of 

virtually unique assemblies out of a set of predefined components. Complex medical devices, 

such as Computer Tomography (CT) and Nuclear Resonance (NR) scanners, illustrate the great 

variety of custom systems configured out of a repertoire of compatible components. 

In a different analogy, the practice of architecture for buildings is often viewed as the 

manipulation of space, volume, texture, light, shadow, and abstract elements in order to achieve 

pleasing aesthetics. This constructive phase of architecture is preceded by another phase, called 

programming, where the user requirements for the various functional spaces are compiled 

without regard to the spatial relationships among the spaces, except for some abstract measures 

of proximity between the spaces. The architectural designer then composes the spatial design 

out of these predefined functional components. The architectural dictum “form follows 

function,” attributed to the architect Louis Henri Sullivan, emphasizes that the overall form of a 

building results from satisfying the functional requirements of its components, rather than from 

some other source, such as historical precedent or style. 

3. The structure of NHIN and the role of ADF 

As implied by its name, the Architecture Development Facilitator is intended to assist the 

ONC)and its agents in the deployment of the NHIN (1). 

The design of the ADF is based on the following observations: 

ADF report 7
• As was the case of the Internet, the configuration and final detailed architecture of NHIN 

will not be fully determined by the time the first set of its component networks is deployed; 

• Again, similarly to the Internet, the initial configuration and architecture of NHIN will be 

subject major revisions and changes as the network evolves from initial pilot systems of 

limited geographic and functional scope to successively broader coverage with more and 

more intimate interconnections; 

• However, component networks of NHIN, once fielded, must appear to their users as 

unchanged in function and interactions even as they are integrated or interconnected into 

larger networks; 

• The components out of which NHIN will be constructed need to be highly modular, so that 

the components, individually or as part of larger networks, are readily replaceable in 

response to new healthcare needs, policies and standards, new enabling information and 

communication technologies as well as new administrative structures and business 

organizations. 

The design of ADF responds to the above imperatives by making absolutely no assumptions 

about the upper levels of the NHIN architecture and by not imposing any constraints on these 

architectural levels. 

4. The structure of ADF 

Rather than treating the design of the NHIN architecture in the “traditional” top-down fashion, 

ADF is dedicated to a strictly bottom-up approach. 

The principal element of the ADF is a repository of: 

• Predefined and mutually compatible components, henceforth called artifacts, which can 

then be combined to configure and deploy a large variety of health care IT system 

architectures for NHIN or any of its subnetworks; and 

• Documentation related to these artifacts, including but not limited to: requirements, use 

cases, conformance testing requirements, functional specifications, standards and the interrelationships between the artifacts, requirements, standards and conformance tests. 

Additional elements of ADF provide: 

• Visualization facilities for navigating among the artifacts in the repository, the interrelationships between these artifacts, and other relevant information for the purpose of 

presentations to decision makers and other public and elected officials; 

• Frameworks for maintaining all information pertaining to standards governing the NHIN 

components and their interactions, as well to conformance testing requirements, 

procedures and results for the components and applicable standards in the repository; 

• Eventually, public commentary management facilities so as to provide a framework for 

collecting and aggregating public comments on the components of the NHIN; and 

• Eventually, a framework for a versatile testbed where new artifact prototypes can be 

tested/simulated within the ADF, surrounded by virtual interacting artifacts, or the new 

artifact prototypes can be tested/simulated remotely in their actual intended setting with 

virtual interacting artifacts supplied from the ADF. 

ADF report 8
5. Artifacts 

5.1. Definition 

An operational definition of artifact is that an artifact is either: (a) a service or system 

component of NHIN (service artifact) or (b) a unit of information interchanged between service 

artifacts (information unit artifact). 

The initial list of artifacts is shown in hierarchical form in Table 1. The indentations in the table 

represent the multilevel classification of artifact types. Consistent with the design philosophy of 

the ADF presented above, the list of artifacts is open ended and expected to grow. The initial 

list was compiled from suggestions by NHIN and Federal Health Architecture (FHA) personnel 

and various NHIN documents, notably the various vendor presentations at the NHIN Kick-off 

Meeting on January 18, 2006 (2), and the Functional Requirement Aggregation spreadsheet 

dated June 27, 2006 (3). 

In terms of the classification of artifacts shown in Table 1, ADF itself is a service, more 

specifically a repository service. In the following, the expression “stored in ADF” is shorthand 

for “stored in the repository accessed by ADF.” 

Services/system 

Care delivery organization (CDO) system 

Care provider 

Laboratory 

Reference laboratory 

Repository service 

Master Person/Patient Index (MPI) 

Electronic medical record (EMR) system 

Laboratory information system (LIS) 

Record locator service (RLS) 

Patient health record (PHR) systems 

Terminology server 

Health information intermediary 

Public health agency (PHA) 

Communication service 

Locator service 

Message handling services (web, logging service , ...) 

Security service (firewall, authentication, access control, security, audit, ...) 

Translation service 

Retrieval service 

Routing service 

Registration service 

Interface 

CDO-CDO NHIN interface 

ADF report 9
Consumer System-Consumer NHIN Interface 

External user interface 

Application interface (clinical, reporting, research system, ...) 

Administrative service 

NHIN Administration 

NHIN Administration-audit trail 

NHIN Administration-consumer authorization 

NHIN Administration-organization registration 

NHIN Administration-system registration 

Registration services (patient, caregiver, system, organization registration, ...)

Utilization reporting systems 

Business process support systems 

Payer systems 

Health information intermediary 

Non-routine system and interface 

Data analysis systems 

Aggregate artifacts 

“Glass boxes” (composed of simple and aggregate artifacts in the ADF) 

“Black boxes” (composition not recorded) 

Patient 

Information unit 

Message 

Reference set 

Vocabulary 

Cross-reference index 

Standard 

Design/normative information 

Use case 

Requirement 

Specification 

Ancilliary document (contract, legal document, specification, ...) 

Table 1. Classification of artifact types 

5.2. Representation of artifacts in ADF 

Meta-data are associated with all artifacts in a generic template applicable to all artifact types 

and in type-specific template extensions for each type. 

Services and systems are represented in ADF by templates, listing: 

• Protocol describing the service (pre- and post-conditions, exception and error handling 

procedures, etc.) 

• Input data; 

• Controls (authorizations, etc.); 

ADF report 10
• Output data; and 

• Output signals (error messages, etc.). 

Inputs, controls, outputs and signals are grouped into information unit artifacts (messages), 

described below. Ideally, the representation of a service’s protocol should be detailed enough to 

simulate the service’s behavior for purposes of conformance testing. 

Repositories are represented by two templates: (a) a service template, similar to the one 

described above, that describes how the repository operates as a service; and (b) an information 

unit template describing the contents of a typical (or prototypical) unit of information in the 

repository. The actual content of a repository will never be stored in ADF. 

Communication, interfaces, administrative services, and non-routine systems and interfaces are 

represented by templates of their behavior, suitable for conformance testing. 

The detailed representation of aggregate artifacts is presented in Section 6 below. 

Some services, particularly message-handling, translation and retrieval services may further be 

represented in ADF as implementation-dependent alternative templates. Initial thoughts on 

their representation are given in Section 9. 

Patients are represented by the minimal set of attributes needed for communication and 

interaction with the other ADF artifacts. For purposes of conformance testing, sets of instances 

of synthetic “patients” may be stored in the repository. 

Messages are represented by templates specifying their information contents; the templates also 

define the appropriate acknowledgement messages and/or error signals. Some message types 

that may conform to several standards or conventions may further be represented in ADF as 

implementation-dependent alternative templates. For purposes of conformance testing, sets of 

instances of synthetic messages may be stored in the repository. 

Anciliary documents are represented by templates specifying their information contents. The 

contents of some key documents may be stored in the ADF. 

Reference sets are represented by templates specifying their information contents as well as by 

access paths to their contents. The contents of vocabularies for some limited bounded 

terminologies may be stored in the ADF. 

Standards are similarly represented by their templates as well as by access paths to their 

contents. The contents of some limited frequently used standards may be stored in the ADF. 

Design and other normative data are generally stored directly in the ADF. 

Details of the current data structure for representing artifacts are given in Appendix A. 

ADF report 11
5.3. Relationships 

ADF deals with the relationships among artifacts presented in Table 2 in a hierarchical format. 

Structural relationships 

is_a 

part_of/ has_parts 

version_of/has_versions 

application_dependent_version_of/has_application_dependent_versions

Configurational relationships 

from/to 

source/destination 

uses/used_by 

references/referred_by 

uses_standard/standard_governs 

Temporal /traceability relationships 

precedes/follows 

Table 2. Classification of relationship types 

6. An illustrative example 

6.1. Description of example 

This example models the three harmonized use cases dated March 19, 2006, released by the 

ONC. The terminology used is that of the use cases and may not always agree with the 

terminology used in the previous section for defining artifacts. A detailed correspondence 

between the events and actions of the use cases and the message artifacts of ADF is presented 

in Appendix B. 

6.2. Electronic Health Record Use Case 

First, the “Harmonized Use Case for Electronic Health Records (Laboratory Result Reporting)” 

is presented (4, (7, (10). 

The following departures have been made for the March 2006 version of the use case: 

• Only the events and actions included in the Healthcare Information Technology 

Standards Panel (HITSP) report have been used, on the assumption that the HITSP task 

force had eliminated actions that do not have standardization and communication 

implications; 

• Event 3.2.4.0 “View results using another clinical data system (non–EHR system)” has 

been eliminated; the event is treated the same way as the interaction with an Electronic 

Health Record (EHR) system; 

• Actions internal to a service (that is, actions not involving a transaction with another 

participant) have been eliminated; 

ADF report 12
• Actions that send, receive, or acknowledge a message have not been separately 

identified; as stated above, all message artifacts identify the sender and receiver services 

and include the acknowledgement message (as well as any error message(s)); 

• In general, messages representing transactions between participants are associated with 

use case events, rather than constituent actions of an event. The only exception is Event 

3.5.2.0 “Process query to provide laboratory test result location(s)” which comprises 

three distinct transactions; 

• The following transactions not contained in the March version of the use case have been 

added in order to provide a complete scenario that may eventually be simulated in the 

ADF: 

o care provider identification (to locator) 

o laboratory identification (to locator) 

o repository identification (to locator) 

o EHR identification (to locator) 

o patient presentation (to care provider) 

o EHR request (by care provider) 

o EHR delivery (to care provider) 

o EHR disclosure (by care provider to patient) 

o lab order (from care provider) 

o patient presentation (to laboratory) 

o EHR update (by care provider) 

o patient update (by care provider) 

o consultation request (by care provider) 

o consultation response update (by care provider); the last two transactions have 

been added to allow for consultation among care providers. 

Based on the items presented above, the ADF repository representation of the use case consists 

of the six service artifacts and the message artifacts presented in Tables 3a and 3b. These 

artifacts can serve as components or building blocks of any architecture for executing this use 

case, as illustrated in Section 7. 

Code1 Description Artifact type 

EHRS1 Patient -- 

EHRS2 Care provider Service - CDO 

EHRS3 Laboratory Service - CDO 

EHRS4 Locator Service – Repository - RLS 

EHRS5 Repository Service - Repository - LIS 

EHRS6 EHR Service - Repository - EMR 

Table 3a. Electronic Health Record Use Case service artifacts 

 

1

 The coding scheme is: first two or three letters: use case (EHR for Electronic Health Records; BIO for BioSurveillance; CE for Consumer Empowerment); following letter: artifact supertype (S for Service; I for 

Information unit); sequence number 

ADF report 13
The patient and the next four services represent the five stakeholders identified in the entitydriven perspectives discussed in the use case; the sixth service, the EHR), is referenced in the 

use case. 

Code Description From service To service 

EHRI1 care provider 

identification 

care provider locator 

EHRI2 laboratory 

identification 

laboratory locator 

EHRI3 repository 

identification 

repository locator 

EHRI4 EHR identification EHR locator 

EHRI5 patient identification patient locator 

EHRI6 patient presentation patient care provider 

EHRI7 EHR request care provider EHR 

EHRI8 EHR delivery EHR care provider 

EHRI9 EHR disclosure care provider patient 

EHRI10 lab order care provider laboratory 

EHRI11 patient presentation to 

laboratory 

patient laboratory 

EHRI12 lab results laboratory repository 

EHRI13 lab report repository care provider 

EHRI14 EHR update care provider EHR 

EHRI15 patient update care provider patient 

EHRI16 consultation request care provider care provider 

EHRI17 consultation response care provider care provider 

Table 3b. Electronic Health Record Use Case information unit artifacts 

All artifacts are of type message. The confirming and error message transactions are not shown. 

The model is shown graphically as an interaction diagram in 

Figure 12

. 

Yellow boxes denote the service artifacts and green boxes the message artifacts, the latter 

identified by their code in the list above. The connector branches are uni-directional, their 

direction defined by the “from” and “to” services in the table above; however, the superposition 

of two uni-directional connectors, such as in messages EHRI16 and 17, produces the visual 

appearance of bi-directional connectors. 

 

2

Formally, the network shown in Figure 1 is a bipartite graph, defined as a special graph where the set of nodes 

can be divided into two disjoint sets U and V such that every branch has one end-point in U and one end-point in 

V. The simplest way to think of a bipartite graph is one whose nodes can be colored with two colors (yellow and 

green in the figure) such that no branch exists between nodes of like colors. 

ADF report 14
Care 

provider Patient Laboratory Repository Locator EHR 

EHRI12

EHRI1

EHRI2 EHRI3 

EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI7, 8, 14

EHRI10

EHRI11 

EHRI13 

EHRI16, 17 

Figure 1. Network of artifact interactions – Laboratory result reporting 

These artifacts can be combined into a variety of distinct architectures. An illustrative set of 

possible generic architectures is presented in Section 7. 

6.3. Bio-Surveillance Use Case 

The representation of the “Bio-Surveillance Harmonized Use Case,” using only the “Individual 

Health Care Delivery Organization” flow path shown in the use case (5, (8, (11), consists of the 

artifacts shown in Tables 3c and 3d. 

 

Code Description Artifact type 

BIOS1 Care provider3 Service - CDO 

BIOS2 Public health agency Service – Repository 

 

Table 3c. Bio-Surveillance Use Case service artifacts 

Code Description From service To service 

BIOI1 Filtered data care provider care provider 

BIOI2 Aggregate data care provider care provider 

BIOI3 Randomized data care provider care provider 

BIOI4 Transformed data care provider care provider 

BIOI5 PHA request care provider public health agency 

BIOI6 Biohazard report care provider public health agency 

BIOI7 Notification to care 

providers 

public health 

agency 

care provider 

Table 3d. Bio-Surveillance Use Case information unit artifacts 

 

3

 same as EHRS2 – Care provider 

ADF report 15
6.4. Consumer Empowerment Use Case 

The representation of the “Consumer Empowerment Harmonized Use Case”, combining the 

three flow scenarios shown in the use case (6, (9, (12), consists of the artifacts shown in Tables 

3e and 3f. 

Code Description Artifact type 

CES1 Consumer4 -- 

CES2 PHR service provider Service – Repository -PHR 

CES3 Health care provider5 Service -- CDO 

CES4 Data or network system 

manager 

assumed to be 

Service – Repository - EHR 

CES5 EHR6 Service - Repository - EHR 

Table 3e. Consumer Empowerment Use Case service artifacts 

Code Description From service To service 

CEI1 PHR service selection 

and permissions 

Consumer PHR service provider 

CEI2 Authenticate to system Consumer Data or network system 

manager 

CEI3 Registration and 

medication data 

Consumer PHR service provider 

CEI4 Registration and 

medication data 

PHR service 

provider 

Data or network system 

manager 

CEI5 Registration and 

medication data 

PHR service 

provider 

Consumer 

CEI6 Summary & history PHR service 

provider 

Data or network system 

manager 

CEI7 Summary & history 

modification 

Consumer PHR service provider 

CEI8 Summary & history to 

health care provider 

PHR service 

provider 

Health care provider 

CEI9 summary & history to 

EHR 

Health care 

provider 

EHR manager 

Table 3f. Consumer Empowerment Use Case information unit artifacts 

A model combining all the three use cases is shown graphically in Figure 2. 

 

4

 same as EHRS1 - Patient 

5

 same as EHRS2 - Care provider 

6

 same as EHRS6 - EHR 

ADF report 16
Figure 2. Combined network of artifact interactions – three use cases 

7. Sample architectures 

The artifacts identified in Figure 1 (EHR use case) may be combined into the generalized 

architectures presented in Table 24 and illustrated in Figures Figure 3a through Figure 3e. The 

last column of Table 24 shows instances of each architecture extracted from the NHIN 

contractors’ presentations at the January 18, 2006, ONC Kickoff presentations (2). A more 

direct comparison of the conceptual architectures with the contractors’ presentations is shown 

in Appendix C. 

Architecture 

name 

Description Services 

outside 

Services 

inside 

Instances from 

Jan 18 Kickoff 

meeting 

presentations 

Fully 

centralized 

All services, including 

care providers, are 

concentrated in the core 

Health Care Delivery 

Organization 

Patient Care 

 provider 

Laboratory 

Locator 

Repository 

EHR 

Northrop Grumman 

 closed entity 

Centralized Care providers are 

external, but all other 

services are concentrated 

in the core Health Care 

Delivery Organization 

Patient 

Care 

 provider 

Laboratory 

Locator 

Repository 

EHR 

Northrop Grumman 

 open entity 

Centralized IT Patient-oriented services Patient Locator Accenture 

Patient Laboratory Repositor Locator EHR

EHRI12

EHRI1 EHRI2

EHRI3

EHRI4

EHRI5

EHRI6, 9,15

EHRI7, 8, 14

EHRI10

EHRI11

EHRI16, 17 EHRI13

PHR

BIOI5, 6, 7

BIOI1, 2, 3, 4

CEI8

CEI1, 3, 5, 7

CEI4, 6

CEI2

CEI9

Care PHA 

provider

ADF report 17
services are external, shared 

services are concentrated 

in the core Health Care 

Delivery Organization 

Care 

 provider 

Laboratory 

Repository 

EHR 

CSC 

IBM Comm. 1 

Decentralized All services and local 

data stores are external; 

the Regional (or 

National) Network 

Infrastructure Provider 

serves as the shared data 

repository 

Patient 

Care 

 provider 

Laboratory 

Repository 

Locator 

EHR 

IBM Comm. 2 

Fully 

decentralized 

All services and data 

stores are external; the 

only linkage being the 

locator serving as the 

Regional (or National) 

Network Infrastructure 

Provider 

Patient 

Care 

 provider 

Laboratory 

Repository 

EHR 

Locator IBM Comm. 3 

Northrop Grumman 

 independent entity 

Table 4. Generalized architectures 

In all the architectures shown it is assumed that the repository and EHR managers are on the 

same side of the inside-outside divide as the data repositories they manage. However, as can be 

seen from the table, all of the message artifacts, other than the Patient-to-locator message, will 

need to be represented in ADF as three implementation-dependent alternative templates for the 

following three cases: 

• services are both inside (no translation or standardization applies); 

• sending and receiving services are both outside; and 

• services are on opposite sides of the divide. 

Patient Care Laboratory Repository Locator EHR 

provider

EHRI1 EHRI2 EHRI3 EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI10 EHRI12 EHRI13 

EHRI16, 17 

Figure 3a. Fully centralized architecture 

EHRI11 EHRI7, 8, 14

ADF report 18
Figure 3b. Centralized architecture 

Figure 3c. Architecture with centralized IT services 

Patient Care 

provider

Laboratory Repository Locator EHR 

EHRI5 

EHRI16, 17 

EHRI10 EHRI12 EHRI13 

EHRI11 EHRI7, 8, 14

EHRI1 EHRI2 EHRI3 EHRI4

EHRI6, 9, 15 

Patient Care Laboratory Repository Locator EHR 

provider

EHRI1 EHRI2 EHRI3 EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI10 EHRI12 EHRI13 

EHRI16, 17 

EHRI11 EHRI7, 8, 14

ADF report 19
Patient Care 

provider

Laboratory Repository Locator EHR 

EHRI1 EHRI2 EHRI3 EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI10 EHRI12 EHRI13 

EHRI16, 17 

EHRI11 EHRI7, 8, 14

Figure 3d. Decentralized architecture 

Patient Care Laboratory Repository Locator EHR 

provider

EHRI1 EHRI2 EHRI3 EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI10 EHRI12 EHRI13 

EHRI16, 17 

EHRI11 EHRI7, 8, 14

Figure 3e. Fully decentralized architecture 

8. Aggregate artifacts 

ADF supports two types of aggregate service artifacts: ”glass boxes” and “black boxes.” Glass 

box aggregate artifacts are composed of artifacts and other aggregate artifacts contained in the 

ADF. Black box aggregate artifacts are represented as themselves and are not further 

decomposable. 

To illustrate the two types of aggregate artifacts, assume that the centralized IT services of the 

architecture illustrated in Figure 3c are to be made into an aggregate artifact, as shown in 

Figure 4. The message artifacts, reproduced in the table below, are now classified into three 

categories: 

• inside, if both the “from service” and the “to service” are inside the aggregate artifact; 

ADF report 20
• outside, if both the “from service” and the “to service” are outside the aggregate artifact; 

and 

• interface otherwise, i. e., either the “from service” is inside and the “to service” is outside 

the aggregate artifact or the “from service” is outside and the “to service” is inside the 

aggregate artifact. 

In the table below the messages are classified accordingly. The interface messages are 

highlighted in red and the inside messages in blue. 

Figure 4. An illustrative glass box aggregate artifact 

Figure 4 is the ADF representation of a glass box aggregate artifact: the component artifacts 

are identified, the inside messages are retained, and the interface messages are linked to the 

component artifacts. 

Code From service To service Classification of 

message artifact 

EHRI1 care provider locator interface 

EHRI2 laboratory locator interface 

EHRI3 repository locator inside 

EHRI4 EHR locator inside 

EHRI5 patient locator interface 

EHRI6 patient care provider outside 

EHRI7 care provider EHR interface 

EHRI8 EHR care provider interface 

EHRI9 care provider patient outside 

EHRI10 care provider laboratory outside 

EHRI11 patient laboratory outside 

EHRI12 laboratory repository interface 

EHRI13 repository care provider interface 

EHRI14 care provider EHR interface 

Glass box aggregate artifact 

Patient Care 

provider

Laboratory Repository Locator EHR 

EHRI1 EHRI2 EHRI3 EHRI4

EHRI5 

EHRI6, 9, 15 

EHRI10 EHRI12 EHRI13 

EHRI16, 17 

EHRI11 EHRI7, 8, 14

ADF report 21
EHRI15 care provider patient outside 

EHRI16 care provider care provider outside 

EHRI17 care provider care provider outside 

Table 5. Classification of message artifacts 

By contrast, the representation of the same network as a black box aggregate artifact is shown 

in Figure 5: the inside messages are not recorded and the interface messages connect to the 

aggregate artifact at the aggregate artifact’s interfaces, illustrated in the figure by blue triangles. 

Thus, all the internal structure of the aggregate artifact is suppressed. 

Black box aggregate artifact 

Patient Care 

provider

Laboratory Repository Locator EHR 

EHRI5 

EHRI16, 17 

EHRI10 EHRI12 EHRI13

EHRI11 EHRI7, 8, 14

EHRI1 EHRI2

EHRI6, 9, 15 

Interface 

Figure 5. An illustrative black box aggregate artifact 

It is anticipated that aggregate artifacts created with the aid of ADF from component artifacts in 

the ADF repository will become glass box aggregate artifacts. On the other hand, existing 

networks imported into the ADF from external sources will tend to be stored as black box 

aggregate artifacts. At the present, we do not plan to implement “make glass box” and “make 

black box” operations (functions) in the ADF prototype, although the need for these operations 

may arise in the production version of the ADF. Suffice to say that the “make black box” 

operation is relatively simple to implement: delete internal messages and transfer the endpoints 

of interface messages from the constituent artifacts to the aggregate artifact interfaces. The 

reverse operation, to “make glass box” from a black box aggregate artifact, requires 

considerable additional information: the location of endpoints of all interface messages and the 

existence and routing of all inside messages. 

Hierarchical or nested aggregate artifacts, that is, aggregate artifacts that have other aggregate 

artifacts as components, are possible and can be readily represented by the ADF facilities 

described above, with one qualification: 

• glass box aggregate artifacts of any arbitrary level of nesting are possible; 

ADF report 22
• lower-level sub-aggregate artifacts of glass boxes can be black boxes; but 

• black box aggregate artifacts cannot have sub-aggregates. 

9. Initial thoughts on ADF architectural issues 

In this section, we summarize a number of architectural issues considered during the past year 

that have not yet been developed to the same extent as the issues discussed above. 

9.1. Representation of implementation-dependent alternatives 

As stated above, many, if not most, message artifacts will have to be represented by several 

implementation-dependent alternatives. One key determinant of which alternative will be used 

in a given situation is whether the message artifact connects two services inside the network, 

outside the network, or across the network boundary. There may be other determinants based 

on different levels of security and/or privacy, different stages of certification, alternate interface 

standards or alternate translation services. 

The current idea is to have templates for all the alternatives stored in the repository and extract 

the appropriate alternative for each application. It remains to be seen whether this approach will 

work or whether, in order to avoid combinatorial problems, a more constructive, modular 

approach is needed. 

9.2. Representation of standards 

Individual artifacts are currently linked to standards by uses_standard relationships. The 

specific representation of the standards, and their linkage to the repository maintained by the 

parallel NIST activity on standards conformance checking, remains to be determined in 

consultation with that activity. Provisions have already been made to link conformance 

checking and approval/adoption status to the standards. 

9.3. Representation of use cases 

Use cases are currently the top nodes in the hierarchical metamodel of the ADF. The use cases 

are linked to the spreadsheets presented in Appendix A. The higher-level metamodel of present 

and potential use cases being developed for ONC is being coordinated with the ADF model so 

that eventually the merged metamodel can be stored in the ADF. 

ADF report 23
9.4. Archiving of previously generated networks 

Networks of healthcare information services will be generated from artifacts stored in the ADF. 

Since the NHIN will be dynamically growing, in possibly unforeseen ways, the ADF will have 

to retain full information about networks previously generated from ADF artifacts so that truth 

maintenance and version control can be strictly applied. This will be achieved by storing in the 

ADF the full specification of the set of artifacts extracted to form each particular network. Thus, 

for example, if a new version of a standard is issued, all affected artifacts in the repository can 

be identified through the standard_governs relationship of that standard; the specifications of 

all derived networks can then be scanned for the presence of affected artifacts. 

9.5. Representation of requirements 

The NHIN functional requirements proposed by National Committee on Vital and Health 

Statistics (NCVHS) are at the present in a state of flux (13). Furthermore, the requirements are 

stated as addressing various entities. These entities have not yet been formally related to the 

artifacts managed by the ADF. A preliminary study shows that the entities are of three types: 

• Entities that directly correspond to artifacts, such as “Laboratory”; 

• Entities that are aggregations of artifacts, such as “Care delivery organizations 

(CDOs);” or 

• Entities that are components of artifacts, such as “CDO-CDO interfaces.” 

If this classification is found to be generally applicable, the functional requirements can be 

treated as artifacts in the ADF and linked through the classification to the artifacts, 

aggregations or components affected. The only requirement on the ADF data structure is that 

all instances of aggregation and decomposition of artifacts corresponding to the entities 

addressed be represented in the data hierarchy shown in Table 1 and elaborated in Appendix B. 

If this proves to be too onerous, a correspondence table between artifacts and entities can be 

used. 

9.6. Business process implications of ADF 

In principle, the production version of ADF could be hosted by a government agency, a 

nonprofit organization or collective, or by one or more vendors. The hosting organization 

would have to provide many more services than just passively accepting submissions of 

artifacts and serving downloads from the repository. The organization would need to maintain a 

substantial service arm. The evaluation of submitted artifacts and the distribution of custom 

extensions to new artifacts, modifications of existing artifacts to reflect changes in any of the 

underlying technologies and, most frequently, development of new application-dependent 

alternatives of existing artifacts would be the prime responsibilities for the hosting organization, 

ADF report 24
along with the standard responsibilities for education, training and general maintenance of the 

system and the artifacts to keep up with the state of the art. 

The business process implications of the three alternatives are discussed below. 

9.6.1. Hosting by a government agency 

A government agency could host ADF on the basis of distributing results of governmentsponsored R&D, or a funding mechanism could be set up along the lines of the Agricultural 

Extension Service operated by the Department of Agriculture or the Manufacturing Extension 

Partnership administered by NIST (http://www.mep.nist.gov/index.html). The fee structure for 

artifacts downloaded from ADF as well as for custom modified artifacts, as described above, 

would depend on the subsidy provided by the funding. 

The hosting agency could be expected to have firm policies for accepting, evaluating, and 

screening submitted candidate artifacts and for updating the system and the artifacts in the 

repository to reflect developing regulations, healthcare advisories, vocabulary updates, etc., as 

well as for quality control, validation, verification, and certification of the artifacts released. 

Whether government hosting entails increasingly bureaucratic procedures and excessive 

reliance on standards remains to be ascertained, and these effects need to be minimized. The 

agency would also have to have firm policies for acting on requests for custom modifications; 

conceivably an advisory panel which would set priorities could guide the agency. 

9.6.2. Hosting by a nonprofit organization or collective 

A nonprofit organization funded by and representing a wide collective of healthcare 

stakeholders could be set up to host the production version of ADF and the associated services. 

It is to be expected that the hosting agency could eventually be self-supporting from the fees 

charged for updates, custom modifications and other services such as education and training. 

The process for accepting, evaluating, and screening submitted candidate artifacts would be 

essentially the same as discussed above for a government host. However, the staff needed for 

custom modifications, and thereby the charges to users, could be substantially reduced by a 

form of open-source programming: a participating healthcare provider organization could 

develop the application-dependent alternatives of existing artifacts that it needs and, with 

suitable quality controls, submit them to the hosting agency for inclusion in the repository for 

use by others. 

Provided that a broad enough range of stakeholders is included in the management of the 

hosting organization, the issues of accepting, evaluating, updating, quality control, validation, 

verification, and certification of the artifacts and acting on requests for custom modifications 

raised above could be expected to be resolved in the normal operation of a participatory 

collective. 

ADF report 25
9.6.3. Hosting by vendor organization 

It is difficult to conceive of a single commercial for-fee vendor providing all the ADF services 

outlined above to the entire US healthcare enterprise. As a starter, it is hardly possible to 

imagine the conditions under which the thousands of participating stakeholder organizations 

would agree on a single commercial provider for all services. It may be conceivable that a 

software vendor, on contract to a government healthcare institution, would accept, evaluate, 

and screen submitted candidate artifacts under the guidance of an advisory council for use by 

other vendors. 

By contrast, it is reasonable to expect that the competitive market of software and service 

vendors servicing the healthcare industry today would extend the range of its offerings to 

include commercial versions of ADF and the associated services described earlier, including 

intake services. It is to be expected that vendors will see ADF services as extensions of their 

current offerings and will offer these additional services to their current customers as well as 

attempt to use them to gain additional market share. In a healthy competitive market in ADFrelated services, it is to be expected that issues of pricing, coverage, updating and quality 

control will be resolved in the marketplace. It is also quite likely that some vendors will attempt 

to develop niche or boutique markets on the basis of medical specialization, type of healthcare 

provider organization, etc. 

Furthermore, it is to be expected that vendors will tightly couple ADF-related services with 

their present offerings into vertically integrated “silo” systems. A positive feature of this 

business approach is that commercial vendors will be more likely to provide direct interfaces to 

non-medical systems such as payor management and accounting, as they are doing today, than 

would the other types of hosting discussed (government or collaborative). On the other hand, if 

experience in other domains is a guide, standardization on a nationwide scale may suffer. The 

individual vendors’ tightly integrated “silos” can achieve tighter interoperability within their 

respective systems through proprietary procedures than through consensus standards. Issues of 

interoperability will arise only when data need to be exchanged among different vendors’ 

systems. Groups that may be severely affected by this mismatch are small healthcare entities, 

such as independent healthcare providers or small local laboratories, which may have to 

exchange data with several healthcare systems using different vendors’ IT systems. In the worst 

case, the healthcare system can get distorted by alliances formed on the basis of common IT 

systems rather than health care policies or business interests. These issues may be so severe that 

an external agency, either governmental or formed by the stakeholders, may be needed to 

mitigate. 

9.7. Metis prototype architecture 

The initial version of the ADF prototype has been implemented in Metis (14). Metis is a family 

of client and server products for creating, visualizing, changing, sharing and managing visual 

enterprise models. Metis provides an information management platform and a meta-model 

driven repository, combined with visual modeling capabilities. 

ADF report 26
Metis Enterprise consists of: 

• Metis Desktop — includes the Metis Client Tools for users to view, develop and manage 

models. These tools are the Model Browser, Model Annotator, Model Editor, Model 

Designer and Metamodel Developer. 

• Metis Enterprise Repository — a scalable and extensible object-based configuration 

management database (CMDB) that stores and organizes all the data. 

• Metis Enterprise Architecture Framework — a reference model based on best practices in 

enterprises and U.S. federal agencies. 

 

The anticipated architecture of the prototype is shown in Figure 6. 

Modeling module

ADF artifacts 

and models

(METIS)

Certification

interface 

module

• Care delivery 

organizations

• Laboratories

• Vendors

• NHIN

administrators

• ADF 

metamodel

administrator Public

interface

module

Management

interface

module

• Public

• Policy makers

Stakeholder

interface 

module

• Certification 

agencies

• Testing 

organizations

Figure 6. Initial architecture of ADF prototype 

ADF will consist of a number of distinct modules. The key module is the modeling module 

where the ADF metamodels, models, and artifacts are defined and housed. The modeling 

module is accessible only to the ADF metamodel administrator. The remaining modules are all 

interface modules for specific constituencies: 

• NHIN administrators; 

• Care delivery organizations; 

• Laboratories; 

• Information service providers (vendors); 

• Certification and testing agencies (HITSP, Certification Commission for Health 

Information Technology (CCHIT), etc.); 

• Policy makers; 

• Public participants. 

The interface modules will all be implemented as Web clients of a server that is linked to the 

modeling module. 

ADF report 27
10. Future work 

In this section, we briefly describe the work we expect to undertake in the second year of the 

ADF project. 

10.1. Detailed specifications for healthcare network interchange points 

As ONC defines the constraints affecting a health information service provider the ADF team 

will provide assistance as needed in the development of the specifications and constraints and 

will work on ensuring that the representations that emerge can be fully supported by the ADF. 

10.2. High level model for future NHIN use cases 

ONC has initiated an effort to define and organize a global metamodel of use cases so as to 

provide a framework for prioritizing AHIC priorities. The ADF team will work on harmonizing 

the metamodels with the dual objective of: 

• Providing a continuous model of present and future use cases from the high-level ONC 

model to the low-level model linked to artifacts in ADF; and 

• Ensuring that the combined model can be fully supported by the ADF. 

10.3. Detailed use cases for ADF interactions 

The ADF team will develop detailed use cases describing user interactions in at least the 

following categories: 

• Ambulatory EHR; 

• Ambulatory EHR with specialties; 

• In-patient EHR with amalgamation of services; and 

• Health information service providers. 

More generally, an attempt will be made to develop a use case for at least one user category for 

each of the ADF interfaces shown on Figure 6. 

10.4. Mockups of future interactions with ADF and design of interface 

modules 

In parallel with the use cases described above, mockups of the various interfaces and user 

interactions will be developed. These will serve as the basis for the design of the interface 

ADF report 28
modules as well as of the server that will be interposed between the METIS model and the 

interfaces. 

10.5. Refinement of ADF architecture 

The activities described above will form the basis for a refinement of the current architecture of 

ADF into a revised repository which will serve as Version 1.0 of the eventual operational 

prototype. 

Disclaimer 

No approval or endorsement of any commercial product, service or company by the National 

Institute of Standards and Technology is intended or implied. 

References 

(1) ONC Goals, Objectives, and Strategies: 

http://www.hhs.gov/healthit/ahic/materials/meeting06/ehr/ONC_goals.doc

(2) Vendor presentations at the NHIN Forum: 

http://www.hhs.gov/healthit/documents/AccenturePresentation.pdf

http://www.hhs.gov/healthit/documents/CSCForumslides.pdf

http://www.hhs.gov/healthit/documents/IBM_NHIN_Forum.pdf

http://www.hhs.gov/healthit/documents/NGC_NHIN_Forum.pdf

(3) Functional Requirement Aggregation spreadsheet: 

http://www.hhs.gov/healthit/documents/FunctReqAggregation.xls

(4) EHR harmonized use cases dated March 19, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Technical%20Committees/AHIC%20Harmonized

%20Use%20Cases/Harmonized%20EHR%20-

%20Lab%20Use%20Case%20Version%201.0.pdf

(5) BIO-Surveillance harmonized use cases dated March 19, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Technical%20Committees/AHIC%20Harmonized

%20Use%20Cases/Harmonized%20Biosurveillance%20-

%20Visit%20Utilization%20Lab%20Use%20Case%20Version%201.0.pdf

(6) Consumer Empowerment harmonized use cases dated March 19, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

ADF report 29
cs%20Technology%20Standards%20Panel/Technical%20Committees/AHIC%20Harmonized

%20Use%20Cases/Harmonized%20Consumer%20Empowerment%20-

%20Registration%20and%20Medication%20Use%20Case%20Version%201.0.pdf

(7) EHR selected standards dated June 29, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Standards%20Selection%20Final%20Deliverable,

%20June%2029/HITSP%20June%2029,%202006%20Deliverable/Electronic%20Health%20R

ecords/HITSP_EHR%20Selected%20Standards%20June%202006%20-%20Version%202.doc

(8) BIO-Surveillance selected standards dated June 29, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Standards%20Selection%20Final%20Deliverable,

%20June%2029/HITSP%20June%2029,%202006%20Deliverable/Biosurveillance/HITSP_BI

O%20Selected%20Standards%20June%202006%20-%20Version%202.doc

(9) Consumer Empowerment selected standards dated June 29, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Standards%20Selection%20Final%20Deliverable,

%20June%2029/HITSP%20June%2029,%202006%20Deliverable/Consumer%20Empowerme

nt/HITSP_CE%20Selected%20Standards%20June%202006%20-%20Version%202.doc

(10) EHR interoperability specifications dated August 18, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Interoperability%20Specification/Electronic%20He

alth%20Record/EHR%20IS%20Documents.zip

(11) BIO-Surveillance interoperability specifications dated August 18, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Interoperability%20Specification/Biosurveillance/B

IO%20IS%20Documents.zip

(12) Consumer Empowerment interoperability specifications dated August 18, 2006: 

http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informati

cs%20Technology%20Standards%20Panel/Interoperability%20Specification/Consumer%20E

mpowerment/CE%20IS%20Documents.zip

(13) National Committee on Vital and Health Statistics: http://www.ncvhs.hhs.gov

(14) Metis EA Tool: http://www.troux.com/products/metis

ADF report 30
Appendix A – Data structure 

The table below shows the data structure of artifacts current as of 12/31/2006. Lines preceded 

by a dot denote attributes. 

Artifact 

• Description 

• ID 

• Type 

• Code 

• Source 

• Submission_date 

• Related_use_case event/action 

• HITSP_status (“draft,””proposed,””approved”) 

• CCHIT_status (ditto) 

• AHIC_status (ditto) 

• Legislation_status (ditto) 

• HHS_status (ditto) 

• Federal_requirement (ditto) 

Service/system 

• Name 

• Specialization 

• Service area 

• National Provider ID 

• Employment Identification Number (EIN) 

• Location 

Care delivery organization (CDO) system 

Care provider 

Laboratory 

Reference laboratory 

Repository 

Master Person/Patient Index (MPI) 

Electronic medical record (EMR) system 

Laboratory information system (LIS) 

Record locator service (RLS) 

Public health record (PHR) system 

Terminology server 

Health information intermediary 

Communication service 

Locator service 

Message handling service (web, logging service , ...) 

Security service (firewalls, authentication, access control, 

security, audit, ...) 

Translation service 

Retrieval service 

Routing service 

Registration service 

ADF report 31
Interface 

CDO-CDO NHIN interface 

Consumer System-Consumer NHIN Interface 

External user interface 

Application interface (clinical, reporting, research system, 

...) 

Administrative service 

NHIN Administration 

NHIN Administration-audit trail 

NHIN Administration-consumer authorization 

NHIN Administration-organization registration 

NHIN Administration-system registration 

Consumer system 

Registration service (patient, caregiver, system, 

organization registration, ...) 

Utilization reporting system 

Business process support system 

Payer system 

Health information intermediary 

Non-routine system and interface 

Data analysis system & secondary use system 

Aggregate artifact 

“Glass box” (composed of simple and aggregate artifacts 

contained in the ADF) 

• Components 

“Black box” (composition not recorded) 

• Interfaces 

Patient 

• Name 

• Address 

• Personal ID Number 

• Health Plan ID Number 

Information unit 

Reference set 

Vocabulary 

Cross-reference index 

Standard 

• Standard type 

Design/normative information 

• Reference 

Use case 

Requirement 

Specification 

Ancilliary document (contract, legal document, specification, ...) 

ADF report 32
Message • From • To • Message_type • Applicable standard • Reference • Sender_ID • Receiver_ID • Sent timestamp • Received timestamp • Acknowledged timestamp • Transmission status 

Care provider identification message • Code: EHRI1 • From: care provider • To: locator • Message_type: CDO-CDO 

Laboratory identification message • Code: EHRI2 • From: laboratory • To: locator • Message_type: CDO-CDO

Repository identification message • Code: EHRI3 • From: repository • To: locator • Message_type: CDO-CDO 

EHR identification message • Code: EHRI4 • From: EHR • To: locator • Message_type: CDO-CDO 

Patient identification message • Code: EHRI5 • From: patient • To: locator • Message_type: patient-CDO 

Patient presentation message • Code: EHRI6 • From: patient • To: care provider • Message_type: patient-CDO 

EHR request message • Code: EHRI7 • From: care provider • To: EHR • Message_type: CDO-CDO 

EHR delivery message • Code: EHRI8 • From: EHR • To: care provider • Message_type: CDO-CDO 

ADF report 33
EHR disclosure message 

• Code: EHRI9 

• From: care provider 

• To: patient 

• Message_type: patient-CDO 

Laboratory order message 

• Code: EHRI10 

• From: care provider 

• To: laboratory 

• Message_type: CDO-CDO 

Patient presentation to laboratory message 

• Code: EHRI11 

• From: patient 

• To: laboratory 

• Message_type: patient-CDO 

Laboratory result message 

• Code: EHRI12 

• From: laboratory 

• To: repository 

• Message_type: CDO-CDO 

Laboratory report message 

• Code: EHRI13 

• From: repository 

• To: care provider 

• Message_type: CDO-CDO 

EHR update message 

• Code: EHRI14 

• From: care provider 

• To: EHR 

• Message_type: CDO-CDO 

Patient update message

• Code: EHRI15 

• From: care provider 

• To: patient 

• Message_type: patient-CDO 

Consultation request message 

• Code: EHRI16 

• From: care provider 

• To: care provider 

• Message_type: CDO-CDO 

Consultation response message 

• Code: EHRI17 

• From: care provider 

• To: care provider 

• Message_type: CDO-CDO 

Table A1. Data structure of artifacts

ADF report 34
ADF report 35

Appendix B – Correspondence to Use Cases

The spreadsheets that follows show the correspondence between the use case events/actions in 

the sequence of HITSP reports and the message artifacts used in this report. 

The tan-colored and white rows are taken from three sets of HITSP reports: 

1. the harmonized use cases dated March 19, 2006 (4, (5, (6) 

2. the selected standards dated June 29, 2006 (7, (8, (9) 

3. the interoperability specifications dated August 18, 2006 (10, (11, (12). 

Where reports 2 and 3 omit certain events or actions from the initial use cases, the cells are left 

blank. The last set of columns show the ADF message artifact codes and designations. The last 

column also contains comments in italics on why certain actions were not treated as distinct 

artifacts. It is to be emphasized that in ADF the actions of sending, receiving, and 

acknowledging a message, returning an error message to the sender, and acting on that error 

message are all parts of the message artifact and are therefore not treated separately. 

The turquoise-colored rows are artifacts (or participant actions on message artifacts) added so 

that information flows, service precedences, etc., can be modeled and displayed in the ADF. 
Code Description Code Description Code Description Code Desc

1.1.1.0 Event: Filter existing data to 

identify data required by public 

health agencies

1.1.1.0 Event: Filter existing data to identify data 

required by public health agencies

1.1.1.0 Event: Filter existing data to identify data required 

by public health agencies

1.1.1.1 Action: Filter collected data records 

to identify biosurveillance data

1.1.1.1 Action: Filter collected data records to identify 

biosurveillance data

1.1.1.1 Action: Filter collected data records to identify 

biosurveillance data

BIOI1 Filtered data

1.1.1.1.1, 1.1.1.1.2 

Action: Filter collected data records to identify biosurveillance data (Lab Results, Visit)

1.1.1.1.3 Action: Filter collected data records to identify 

biosurveillance data (Resource Utilization)

1.1.1.2 Action: Aggregate identified data 1.1.1.2 Action: Aggregate identified data BIOI2 Aggregate data

1.1.2.0 Event: Anonymize data required by 

public health agencies

1.1.2.0 Event: Anonymize data required by public 

health agencies

1.1.2.0 Event: Anonymize data required by public health 

agencies

1.1.2.1 Action: Required data are checked 

to ensure full privacy requirement compliance

1.1.2.1 Action: Required data are checked to ensure 

full privacy requirement compliance

1.1.2.1 Action: Required data are checked to ensure full 

privacy requirement compliance

1.1.2.2 Action: A randomized data linker is 

provided to allow authorized entities to re-link to patient data

1.1.2.2 Action: A randomized data linker is provided to 

allow authorized entities to re-link to patient data

1.1.2.2 Action: A randomized data linker is provided to 

allow authorized entities to re-link to patient data

BIOI3 Randomized data

1.1.3.0 Event: Format data required by 

public health agencies

1.1.3.0 Event: Format data required by public health 

agencies

1.1.3.0 Event: Format data required by public health 

agencies

1.1.3.1 Action: Transform data using 

approved standards

1.1.3.1 Action: Transform data using approved 

standards

1.1.3.1 Action: Transform data using approved standards BIOI4 Transformed data

1.1.3.1.1 Action: Transform data using approved 

standards (Lab Results)

1.1.3.1.2 Action: Transform data using approved standards (Visit)1.1.3.1.3 Action: Transform data using approved standards 

(Utilization)

1.1.4.0 Event: Identify Public Health 

Agencies that must be notified

1.1.4.0 Event: Identify Public Health Agencies that must be 

notified

1.1.4.1 Action: Determine which Public 

Health Agencies require notification

1.1.4.1 Action: Determine which Public Health Agencies 

require notification

BIOI5 PHA request

1.1.5.0 Event: Transmit relevant data to 

public health agencies

1.1.5.0 Event: Transmit relevant data to public health 

agencies

1.1.5.0 Event: Transmit relevant data to public health 

agencies

1.1.5.1 Action: Send results to public 

health agencies

1.1.5.1 Action: Send results to public health agencies 1.1.5.1 Action: Send results to public health agencies BIOI6 Biohazard report1.1.5.1.1 Action: Send results to public health agencies 

(Lab Results) 

1.1.5.1.2 Action: Send results to public health agencies 

(Visit)

1.1.5.1.3 Action: Send results to public health agencies 

(Utilization)

1.1.5.2 Action: Log interaction between 

organization systems and public health agencies

1.1.5.2 Action: Log interaction between organization 

systems and public health agencies

Harmonized Use Case for Biosurveillance

Healthcare Information Technology Standards Panel 

Technical Committees Selected Standards June 29, 

2006 Version 2.0

HITSP Interoperability Specification: Harmonized 

Biosurveillance - Visit Utilisation Lab Use Case Version Draft definition of AD

ADF report 
Code Description Code Description Code Description Code Descri

1.2.1.1 Action: Filter stored data to identify 

biosurveillance data

1.2.1.1 Action: Filter stored data to identify 

biosurveillance data

1.2.1.1 Action: Filter stored data to identify biosurveillance 

data

1.2.1.2 Action: Aggregate identified data 1.2.1.2 Action: Aggregate identified data 1.2.1.2 Action: Aggregate identified data1.2.2.0 Event: Anonymize data required by 

public health agencies

1.2.2.0 Event: Anonymize data required by public 

health agencies

1.2.2.0 Event: Anonymize data required by public health 

agencies

1.2.2.1 Action: Required data are checked 

to ensure full privacy requirement compliance

1.2.2.1 Action: Required data are checked to ensure 

full privacy requirement compliance

1.2.2.1 Action: Required data are checked to ensure full 

privacy requirement compliance

1.2.2.2 Action: A randomized data linker is 

provided to allow authorized entities to re-link to patient data

1.2.2.2 Action: A randomized data linker is provided to 

allow authorized entities to re-link to patient data

1.2.2.2 Action: A randomized data linker is provided to 

allow authorized entities to re-link to patient data

1.2.3.0 Event: Format data required by 

public health agencies

1.2.3.0 Event: Format data required by public health 

agencies

1.2.3.0 Event: Format data required by public health 

agencies

1.2.3.1 Action: Transform data using 

approved standards

1.2.3.1 Action: Transform data using approved 

standards

1.2.3.1 Action: Transform data using approved standards

1.2.4.0 Event: Identify Public Health 

Agencies that must be notified

1.2.4.0 Event: Identify Public Health Agencies that 

must be notified

1.2.4.0 Event: Identify Public Health Agencies that must be 

notified

1.2.4.1 Action: Determine which Public 

Health Agencies require notification

1.2.4.1 Action: Determine which Public Health 

Agencies require notification

1.2.4.1 Action: Determine which Public Health Agencies 

require notification

1.2.5.0 Event: Transmit relevant data to 

public health agencies

1.2.5.0 Event: Transmit relevant data to public health 

agencies

1.2.5.0 Event: Transmit relevant data to public health 

agencies

1.2.5.1 Action: Send results to public 

health agencies

1.2.5.1 Action: Send results to public health agencies 1.2.5.1 Action: Send results to public health agencies

1.2.5.2 Action: Log interaction between 

organization systems and public health agencies

1.2.5.2 Action: Log interaction between organization 

systems and public health agencies

1.2.5.2 Action: Log interaction between organization 

systems and public health agencies

1.3.1.0 Event: Provide listing of required 

biosurveillance data

1.3.1.0 Event: Provide listing of required 

biosurveillance data

1.3.1.0 Event: Provide listing of required biosurveillance 

data

1.3.1.1 Action: Notify involved 

organizations of data that must be transmitted to Public Health Agencies

1.3.1.1 Action: Notify involved organizations of data 

that must be transmitted to Public Health Agencies

1.3.1.1 Action: Notify involved organizations of data that 

must be transmitted to Public Health Agencies

BIOI7 Notification to CDOs

1.3.2.0 Event: Receive biosurveillance 

data

1.3.2.0 Event: Receive biosurveillance data 1.3.2.0 Event: Receive biosurveillance data

1.3.2.1 Action: Receive clinical data from 

the all data sources.

1.3.2.1 Action: Receive clinical data from the all data 

sources.

1.3.2.1 Action: Receive clinical data from the all data 

sources.

1.3.2.2 Action: Verify authenticity of 

transmission contents

1.3.2.2 Action: Verify authenticity of transmission 

contents

1.3.2.2 Action: Verify authenticity of transmission contents

1.3.2.3 Action: Acknowledge receipt of 

clinical data

1.3.2.3 Action: Acknowledge receipt of clinical data 1.3.2.3 Action: Acknowledge receipt of clinical data

1.3.2.4 Action: Log receipt and storage of 

lab test results

1.3.2.4 Action: Log receipt and storage of lab test results

Harmonized Use Case for Biosurveillance

Healthcare Information Technology Standards Panel 

Technical Committees Selected Standards June 29, 

2006 Version 2.0

HITSP Interoperability Specification: Harmonized 

Biosurveillance - Visit Utilisation Lab Use Case Version Draft definition of ADF 

ADF report 
Code Description Code Description Code Description Code Description

2.1.1.0 Event: Select a provider 

of PHR services

2.1.1.1 Action: Provide 

identification data

2.1.2.0 Event: 

Establish/Change permissions

2.1.2.0 Event: Establish/Change 

permissions

2.1.2.1 Action: Authenticate to 

system

2.1.2.2 Action: Establish/Modify 

permissions for access to the system

2.1.2.2 Action: Establish/Modify 

permissions for access to the system

2.1.30 Event: Log on to system2.1.3.1 Action: Authenticate to 

system

2.1.4.0 Event: View registration 

and medication data

2.1.4.0 Event: View registration 

and medication data

2.1.4.1 Action: Authenticate to 

system

2.1.4.2 Action: Request data 2.1.4.2 Action: Request data2.1.4.3 Action: Receive data 2.1.4.3 Action: Receive data2.1.5.0 Event: Modify 

registration and medication data

2.1.5.0 Event: Modify registration 

and medication data

2.1.5.1 Action: Authenticate to 

system

2.1.5.1 Action: Authenticate to 

system

2.1.5.2 Action: Request data 2.1.5.2 Action: Request data2.1.5.3 Action: Receive data 2.1.5.3 Action: Receive data2.1.5.4 Action: Modifiy data2.1.5.4a Alternate Action: 

Annotate data

2.1.5.5 Action: Transmit 

modified and/or annotated data

2.1.5.5 Action: Transmit 

modified and/or annotated data

2.1.5.5a Alternate Action: 

Transmit request to modify and/or correct data

2.1.5.5a Alternate Action: 

Transmit request to modify and/or correct data

2.1.6.0 Event: Close account 2.1.6.0 Event: Close account2.1.6.1 Action: Request to 

close PHR account

2.1.6.1a Alternate Action: 

Request registration and medication data sent to another provider of PHR services

2.1.6.2 Action: Receive 

confirmation of account closure

2.1.6.2a Alternate Action: 

Receive confirmation of account transfer

2.1.6.2a Alternate Action: Receive 

confirmation of account transfer

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

2.2.1.1 Action: Confirm 

consumer’s identity

2.2.1.2 Action: Create 

consumer’s account

2.2.1.3 Action: Maintain 

consumer’s permissions for system access

2.2.2.0 Event: Gather 

registration and/or medication data

2.2.2.0 Event: Gather 

registration and/or medication data

2.2.2.1 Action: Receive 

consumer request

2.2.2.2 Action: Confirm 

consumer identity

2.2.2.3 Action: Transmit 

request for registration/medication data to data or network system

2.2.2.3 Action: Transmit request 

for registration/medication data to data or network system

2.2.2.4 Action: Receive 

registration/medication data

2.2.2.4 Action: Receive 

registration/medication data

2.2.2.5 Action: Acknowledge 

receipt of registration/medication data

2.2.2.5 Action: Acknowledge 

receipt of registration/medication data

2.2.2.6 Action: Log interaction2.2.3.0 Event: Process request 

for registration and/or medication data

2.2.3.0 Event: Process request 

for registration and/or medication data

2.2.3.1 Action: Receive and 

validate the query request

2.2.3.1 Action: Receive and 

validate the query request

2.2.3.2 Action: Authenticate 

and verify the authorization of the requestor

2.2.3.3 Action: Transmit 

registration and medication data to an authorized system

2.2.3.3 Action: Transmit 

registration and medication data to an authorized system

2.2.3.4 Action: Log interaction

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

2.2.4.1 Action: Receive and 

validate query

2.2.4.2 Action: Authenticate 

and verify the authorization of the requestor

2.2.4.3 Action: Terminate acco2.2.4.3a Alternate Action: 

Transmit registration and medication data to the new provider of PHR services

2.2.4.3a Alternate Action: 

Transmit registration and medication data to the new provider of PHR services

2.2.4.4 Action: Transmit 

confirmation to consumer

2.2.4.5 Action: Log interaction2.3.1.0 Event: View registration 

and/or medication data

2.3.1.0 Event: View registration 

and/or medication data

2.3.1.1 Action: Submit 

authentication information to PHR

2.3.1.2 Action: Receive 

registration and medication data

2.3.2.0 Event: Integrate 

registration data into EHR or other care system

2.3.2.0 Event: Integrate 

registration data into EHR or other care system

2.3.2.1 Action: Transmit 

request for registration/medication data to provider of PHR services

2.3.2.1 Action: Transmit request 

for registration/medication data to provider of PHR services

2.3.2.1a Receive medication data 

(probably unitentionally left out of Use Case Event List)

2.3.2.2 Action: Accept data into 

EHR system

2.3.2.2 Action: Accept data into 

EHR system

2.3.2.3 Action: Confirm data 

integrity

2.3.2.3 Action: Confirm data 

integrity

2.3.2.3a Alternate Action: 

Produce exception list of errors

2.3.2.3a Alternate Action: 

Produce exception list of errors

2.3.2.4 Action: Parse and 

validate results content

2.3.2.4 Action: Parse and 

validate results content

2.3.2.5 Action: Acknowledge 

receipt of registration and medication data

2.3.2.5 Action: Acknowledge 

receipt of registration and medication data

2.3.2.6 Action: Log interaction 2.3.2.6 Action: Log interaction

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

2.3.3.1 Action: Receive and 

validate the query request

2.3.3.1 Action: Receive and 

validate the query request

2.3.3.2 Action: Authenticate 

and verify the authorization of the requestor.

2.3.3.2 Action: Authenticate and 

verify the authorization of the requestor.

2.3.3.3 Action: Transmit 

registration and medication data to an authorized system

2.3.3.3 Action: Transmit 

registration and medication data to an authorized system

2.3.3.4 Action: Log interaction 2.3.3.4 Action: Log interaction2.4.1.0 Event: Process request 

for registration and/or medication data

2.4.1.0 Event: Process request 

for registration and/or medication data

2.4.1.1 Action: Receive and 

validate the query request

2.4.1.1 Action: Receive and 

validate the query request

2.4.1.2 Action: Authenticate 

and verify the authorization of the requestor

2.4.1.3 Action: Authorize 

release of registration and medication data

2.4.1.4 Action: Transmit 

registration and medication data to an authorized system

2.4.1.4 Action: Transmit 

registration and medication data to an authorized system

2.4.1.5 Action: Log interaction

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
2.2.4.0 Event: Close account 2.2.4.0 Event: Close account

2.2.4.1 Action: Receive and 

validate query

2.2.4.2 Action: Authenticate 

and verify the authorization of the requestor

2.2.4.3 Action: Terminate acco2.2.4.3a Alternate Action: 

Transmit registration and medication data to the new provider of PHR services

2.2.4.3a Alternate Action: 

Transmit registration and medication data to the new provider of PHR services

2.2.4.4 Action: Transmit 

confirmation to consumer

2.2.4.5 Action: Log interaction2.3.1.0 Event: View registration 

and/or medication data

2.3.1.0 Event: View registration 

and/or medication data

2.3.1.1 Action: Submit 

authentication information to PHR

2.3.1.2 Action: Receive 

registration and medication data

2.3.2.0 Event: Integrate 

registration data into EHR or other care system

2.3.2.0 Event: Integrate 

registration data into EHR or other care system

2.3.2.1 Action: Transmit 

request for registration/medication data to provider of PHR services

2.3.2.1 Action: Transmit request 

for registration/medication data to provider of PHR services

2.3.2.1a Receive medication data 

(probably unitentionally left out of Use Case Event List)

2.3.2.2 Action: Accept data into 

EHR system

2.3.2.2 Action: Accept data into 

EHR system

2.3.2.3 Action: Confirm data 

integrity

2.3.2.3 Action: Confirm data 

integrity

2.3.2.3a Alternate Action: 

Produce exception list of errors

2.3.2.3a Alternate Action: 

Produce exception list of errors

2.3.2.4 Action: Parse and 

validate results content

2.3.2.4 Action: Parse and 

validate results content

2.3.2.5 Action: Acknowledge 

receipt of registration and medication data

2.3.2.5 Action: Acknowledge 

receipt of registration and medication data

2.3.2.6 Action: Log interaction 2.3.2.6 Action: Log interaction

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
2.3.3.0 Event: Process 

requested data

2.3.3.0 Event: Process 

requested data

2.3.3.1 Action: Receive and 

validate the query request

2.3.3.1 Action: Receive and 

validate the query request

2.3.3.2 Action: Authenticate 

and verify the authorization of the requestor.

2.3.3.2 Action: Authenticate and 

verify the authorization of the requestor.

2.3.3.3 Action: Transmit 

registration and medication data to an authorized system

2.3.3.3 Action: Transmit 

registration and medication data to an authorized system

2.3.3.4 Action: Log interaction 2.3.3.4 Action: Log interaction2.4.1.0 Event: Process request 

for registration and/or medication data

2.4.1.0 Event: Process request 

for registration and/or medication data

2.4.1.1 Action: Receive and 

validate the query request

2.4.1.1 Action: Receive and 

validate the query request

2.4.1.2 Action: Authenticate 

and verify the authorization of the requestor

2.4.1.3 Action: Authorize 

release of registration and medication data

2.4.1.4 Action: Transmit 

registration and medication data to an authorized system

2.4.1.4 Action: Transmit 

registration and medication data to an authorized system

2.4.1.5 Action: Log interaction

Harmonized Consumer 

Empowerment - Registration and 

Medication Use Case Version 11.0

Healthcare Information Technology 

Standards Panel Technical 

Committees Selected Standards June 

29, 2006 Version 2.0

HITSP Interoperability 

Specification: Harmonized 

Consumer Empowerment - 

Registration and Medication Use 

Case Version 11.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

3.1.1.0 Event: Provide patient identity 

information, update as needed

3.1.1.0 Event: Provide patient identity 

information, update as needed

3.1.1.0 Event: Provide patient identity 

information, update as needed

LI5 patient identification

3.1.1.1 Action : Provide identification data 3.1.1.1 Action : Provide identification data 3.1.1.1 Action : Provide identification 

data

3.1.2.0 Event: Identify providers of care, 

update as needed

3.1.2.0 Event: Identify providers of care, 

update as needed

3.1.2.0 Event: Identify providers of care, 

update as needed

LI6 identification of patient’s care 

provider(s)

3.1.2.1 Action: Provide list of providers of care 3.1.2.1 Action: Provide list of providers of 

care

3.1.2.1 Action: Provide list of providers 

of care

3.1.2.1a Alternate Action: Indicate that test 

result results should not be made available to other providers of care

3.1.2.1a Alternate Action: Indicate that test 

result results should not be made available to other providers of care

3.1.2.1a Alternate Action: Indicate that 

test result results should not be made available to other providers of care

LI7 patient presentation (to 

clinician)

LI12 patient presentation (to 

laboratory)

LI1 care provider identification

3.2.1.0 Event: Integrate results and view in 

EHR

3.2.1.0 Event: Integrate results and view in 

EHR

3.2.1.0 Event: Integrate results and view 

in EHR

3.2.1.1 Action: Receive lab test result as 

ordering clinician or provided of care

3.2.1.1a Alternate Action: Send request for 

historical lab test result content to data repository(ies)

3.2.1.1a Alternate Action: Send request for 

historical lab test result content to data repository(ies)

3.2.1.1a Alternate Action: Send request 

for historical lab test result content to data repository(ies)

LI8 EHR request

3.2.1.1b Alternate Action: Submit authentication 

information to the data repository

3.2.1.2 Action: Confirm data integrity of 

received results

3.2.1.3 Action: Parse and validate results 

content

3.2.1.4 Action: Merge data into EHR3.2.1.5 Action: New results are flagged within 

EHR

3.2.1.6 Action: Acknowledge receipt of lab 

results

3.2.1.6 Action: Acknowledge receipt of lab 

results

3.2.1.6 Action: Acknowledge receipt of 

lab results

3.2.1.7 Action: Log receipt of lab test results3.2.1.7a Alternate Action: Produce exception 

list of errors

3.2.2.0 Event: Receive notification of lab test 

results

3.2.2.0 Event: Receive notification of lab 

test results

3.2.2.0 Event: Receive notification of lab 

test results

LI14 lab result availability notification

3.2.2.1 Action: Receive notification that test 

results are available

3.2.2.1 Action: Receive notification that 

test results are available

3.2.2.1 Action: Receive notification that 

test results are available

Harmonized Use Case for Electronic 

Health Records (Laboratory Result Reporting) 

March 19, 2006

Draft definition of ADF artifacts

HITSP Interoperability Specification: EHR 

Laboratory Results Reporting

August 18, 2006

Version 1.0

Healthcare Information Technology 

Standards Panel Technical Committees 

Selected Standards June 29, 2006 Version 

2.0

ADF report 
Code Description Code Description Code Description Code Description

3.2.3.1 Action: Submit authentication 

information to locator system

3.2.3.2 Action: Clinician and locator system 

agree on patient identity through patient trait matching

3.2.3.2 Action: Clinician and locator system 

agree on patient identity through patient trait matching

3.2.3.2 Action: Clinician and locator 

system agree on patient identity through patient trait matching

LI15 agreement on patient identity

3.2.3.2a Alternate Action: Clinician and locator 

system agree on patient identity based on shared MPI

3.2.3.2b Alternate Action: Clinician and locator 

system agree on patient identity based on patient identifier matching

3.2.3.2b Alternate Action: Clinician and 

locator system agree on patient identity based on patient identifier matching

3.2.3.2b Alternate Action: Clinician and 

locator system agree on patient identity based on patient identifier matching

3.2.3.3 Action: Transmit request for specific 

lab test results based on order number or other unique test result identification

3.2.3.3 Action: Transmit request for 

specific lab test results based on order number or other unique test result identification

3.2.3.3 Action: Transmit request for 

specific lab test results based on order number or other unique test result identification

LI16 request lab results

3.2.3.3a Alternate Action: Browse, select and 

confirm the relevant test results for the correct patient and transmit request

3.2.3.3a Alternate Action: Browse, select 

and confirm the relevant test results for the correct patient and transmit request

3.2.3.3a Alternate Action: Browse, select 

and confirm the relevant test results for the correct patient and transmit request

3.2.3.4 Action: Receive the data repository 

location where the test results are stored

3.2.3.4 Action: Receive the data repository 

location where the test results are stored

LI17 receive lab result identifier

3.2.3.5 Action: Log interaction with locator 

service

3.2.4.0 Event: View results using another 

clinical data system (non-EHR system)

3.2.4.0 Event: View results using another 

clinical data system (non-EHR system)

3.2.4.0 Event: View results using 

another clinical data system (nonEHR system)

3.2.4.1 Action: Send request for lab test result 

content to data repository(ies)

3.2.4.1 Action: Send request for lab test 

result content to data repository(ies)

3.2.4.1 Action: Send request for lab test 

result content to data repository(ies)

LI8 treated as “EHR request”

3.2.4.2 Action: Submit authentication 

information to data repository

3.2.4.3 Action: Receive and view laboratory 

test results

3.2.4.3 Action: Receive and view 

laboratory test results

3.2.4.3 Action: Receive and view 

laboratory test results

LI16 treated as "request lab 

requests"

3.2.4.3a Alternate Action: Print lab results3.2.4.3b Alternate Action: Save lab results in 

local system for viewing at a later time

3.2.4.4 Action: Verify correct patient identity 

and correctness of lab results and error correct if necessary

3.2.4.5 Action: Acknowledge receipt of lab 

results

3.2.4.5 Action: Acknowledge receipt of lab 

results

3.2.4.5 Action: Acknowledge receipt of 

lab results

3.2.4.6 Action: Log interaction with data 

repository

LI8 EHR request (to EHR)

LI10 EHR disclosure (to patient)LI11 lab orderLI20 EHR updateLI21 patient updateLI22 consultation requestLI23 consultation response

LI2 laboratory identification

Harmonized Use Case for Electronic 

Health Records (Laboratory Result Reporting) 

March 19, 2006

Healthcare Information Technology 

Standards Panel Technical Committees 

Selected Standards June 29, 2006 Version 

2.0

HITSP Interoperability Specification: EHR 

Laboratory Results Reporting

August 18, 2006

Version 1.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

3.3.1.1 Action: Create test results 3.3.1.1 Action: Create test results 3.3.1.1 Action: Create test results3.3.1.2 Action: Send results to data repository 3.3.1.2 Action: Send results to data 

repository

3.3.1.2 Action: Send results to data 

repository

LI13 send lab results (to repository)

LI3 repository identification

3.3.1.3 Action: Log creation of test results3.4.1.0 Event: Store laboratory results 3.4.1.0 Event: Store laboratory results 3.4.1.0 Event: Store laboratory results3.4.1.1 Action: Receive test results from 

laboratory

3.4.1.2 Action: Verify authenticity of laboratory 

and lab test result file contents

3.4.1.3 Action: Acknowledge receipt of test lab 

results

3.4.1.3 Action: Acknowledge receipt of test 

lab results

3.4.1.3 Action: Acknowledge receipt of 

test lab results

3.4.1.4 Action: Store test lab results 3.4.1.4 Action: Store test lab results 3.4.1.4 Action: Store test lab results3.4.1.5 Action: Transmit lab test results to 

ordering clinician and other providers of care if appropriate

3.4.1.5 Action: Transmit lab test results to 

ordering clinician and other providers of care if appropriate

3.4.1.5 Action: Transmit lab test results 

to ordering clinician and other providers of care if appropriate

LI18 send lab report

3.4.1.6 Action: Log receipt and storage of lab 

test results

3.4.2.0 Event: Notify locator service of 

laboratory results

3.4.2.0 Event: Notify locator service of 

laboratory results

3.4.2.0 Event: Notify locator service of 

laboratory results

3.4.2.1 Action: Authenticate to locator service3.4.2.2 Action: Send result location and 

related information to locator service

3.4.2.2 Action: Send result location and 

related information to locator service

3.4.2.2 Action: Send result location and 

related information to locator service

LI19 lab report to EHR

3.4.2.3 Action: Log interaction with locator 

system

3.4.3.0 Event: Process Request for Laboratory 

Test Results

3.4.3.0 Event: Process Request for 

Laboratory Test Results

3.4.3.0 Event: Process Request for 

Laboratory Test Results

3.4.3.1 Action: Receive and validate the query 

request

3.4.3.1 Action: Receive and validate the 

query request

3.4.3.1 Action: Receive and validate the 

query request

3.4.3.2 Action: Authenticate and verify as 

ordering clinician or provider of care

3.4.3.3 Action: Authorize release of laboratory 

test results

3.4.3.4 Action: Transmit lab results of an 

identified patient to an ordering clinician or provider of care

3.4.3.4 Action: Transmit lab results of an 

identified patient to an ordering clinician or provider of care

3.4.3.4 Action: Transmit lab results of an 

identified patient to an ordering clinician or provider of care

LI18 send lab report (from 

repository)

3.4.3.5 Action: Log interaction

Harmonized Use Case for Electronic 

Health Records (Laboratory Result Reporting) 

March 19, 2006

Healthcare Information Technology 

Standards Panel Technical Committees 

Selected Standards June 29, 2006 Version 

2.0

HITSP Interoperability Specification: EHR 

Laboratory Results Reporting

August 18, 2006

Version 1.0

Draft definition of ADF artifacts

ADF report 
Code Description Code Description Code Description Code Description

3.5.1.1 Action: Receive test result (file) 

location information and related information

3.5.1.1 Action: Receive test result (file) 

location information and related information

3.5.1.2 Action: Verify authenticity of lab test 

result location and completeness of related information

3.5.1.3 Action: Index test result by appropriate 

patient and other indices

3.5.2.0 Event: Process query to provide 

laboratory test result location(s)

3.5.2.0 Event: Process query to provide 

laboratory test result location(s)

3.5.2.0 Event: Process query to provide 

laboratory test result location(s)

3.5.2.1 Action: Authenticate clinician 

requesting laboratory test results

3.5.2.2 Action: Clinician and locator system 

agree on patient identity

3.5.2.2 Action: Clinician and locator system 

agree on patient identity

3.5.2.2 Action: Clinician and locator 

system agree on patient identity

LI15 agreement on patient identity

3.5.2.3 Action: Receive request for lab test 

results based on lab order number or other unique lab test identifier

3.5.2.3 Action: Receive request for lab test 

results based on lab order number or other unique lab test identifier

3.5.2.3 Action: Receive request for lab 

test results based on lab order number or other unique lab test identifier

LI25 lab report request (from care 

provider to locator)

3.5.2.3a Alternate Action: Provide lab result 

availability information based on clinician query/browse

3.5.2.3a Alternate Action: Provide lab result 

availability information based on clinician query/browse

3.5.2.3a Alternate Action: Provide lab 

result availability information based on clinician query/browse

3.5.2.4 Action: Authorize data release3.5.2.5 Action: Send lab result location (links) 

pointers to authorized clinician.

3.5.2.5 Action: Send lab result location 

(links) pointers to authorized clinician.

3.5.2.5 Action: Send lab result location 

(links) pointers to authorized clinician.

LI17 send lab result identifier

3.5.2.6 Action: Log interaction with clinician3.5.3.0 Event: Notify provider(s) of care of new 

laboratory test results

3.5.3.0 Event: Notify provider(s) of care of 

new laboratory test results

3.5.3.0 Event: Notify provider(s) of care 

of new laboratory test results

 LI24 publish lab result availability

3.5.3.1 Action: Send notification to clinician 3.5.3.1 Action: Send notification to clinician 3.5.3.1 Action: Send notification to 

clinician

LI4 EHR identificationLI9 EHR delivery

Harmonized Use Case for Electronic 

Health Records (Laboratory Result Reporting) 

March 19, 2006

Healthcare Information Technology 

Standards Panel Technical Committees 

Selected Standards June 29, 2006 Version 

2.0

HITSP Interoperability Specification: EHR 

Laboratory Results Reporting

August 18, 2006

Version 1.0

Draft definition of ADF artifacts

ADF report 
Appendix C – Comparison of architectures 

The figures that follow show comparisons of the conceptual architectures presented in this 

report with the architectures shown in the NHIN contractors’ presentations. 

Our Solution

 

Figure C1a. Accenture architecture 

Patient Clinician Laboratory Repository Locator EHR

Patient

Patient

Clinician

Clinician

Laboratory

Laboratory

Figure C1b. ADF model of Accenture architecture 

ADF report 48
CFH NHIN Architecture Prototype

Mendocino 

HRE

Consolidated Tribal 

Health Project

UVPMCG

CareGroup Boston 

Medical 

Center

IHIE

Clarian

St.Francis

St. Vincent

Ukiah 

Valley

Wishard

Community 

Hospitals

Indiana 

University

ISB

ISB

Master 

Locator

CDX Gate

way

AACS

AEGIS

MA-SHARE

CDX Gate

way

Data 

Repository

Data 

Mirrors

Data 

Mirrors

Data 

Mirrors

Mendocino

HRE: Health Records Exchange

RLS: Record Locator Service

RES: Records Exchange Service

AACS: Authentication and Access Control Service

IHIE

Master Locator = Record Locator Service

MA-SHARE

RLS: Record Locator Service

Registry: Database of names and addresses of network nodes

CDX Gate

way

RLS

RES

SNO 

Registry

I

S

B

SNO: Sub Network Organization 

ISB: Inter-SNO Bridge

SNO Enterprise

NHIN 

Specified 

Services

NHIN 

Specified 

Components

EHR 

Registry

RLS

Centrally 

Persisted 

Data *

* Not specified by NHIN - 

SNO specific implementation 

Figure C2a. CSC architecture 

Patient Clinician Laboratory Repository Locator EHR

Patient

Patient

Clinician

Clinician

Laboratory

Laboratory

Patient Clinician Laboratory Repository Locator EHR

Patient Clinician Laboratory Repository Locator EHR

Community 1

Community 2

Community 3

Figure C2b. ADF model of CSC architecture 

ADF report 49
The NHIN Prototype – Landscape

Figure C3a. IBM architecture 

Patient Clinician Laboratory Repository Locator EHR

Patient Clinician Laboratory Repository Locator EHR

Patient Clinician Laboratory Repository Locator EHR

Community 1

Community 3

Community 2

Figure C3b. ADF model of IBM architecture 

(for clarity, links between services are not shown) 

ADF report 50
Figure C4a. Northrop Grumman architecture 

Patient Clinician Locator

Repository Locator EHR

Patient Clinician Laboratory

Laboratory

Locator

Patient Clinician Laboratory Repository Locator EHR

NHIN services

Independent entity

Open entity

Closed entity

Figure C4b. ADF model of Northrop Grumman architecture 

(for clarity, links between services within entities are not shown) 

ADF report 51