3.0 Design

Case Reports

Drug Safety

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Device Safety

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Drug admin management

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Vaccine AE report

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Case Report (VAERS)

Food safety

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Reportable disease reports

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Case Report (Public Health Case Report)

HAI

Release 1 (HITSP/C75)

NA

Case Report (HAI)

Other HC safety reports other than Infection (e.g. falls) (including Sentinel events; all never-events, anything that may become a never-event; AHRQ)

Release 2

Immature, standards in progress. Pending harmonization of case reporting content

Case Report (Patient Safety, AE)

Standard Case Report Construct

Release 2

NOTE: There are currently multiple studies underway to propagate the information about an adverse event from source to the recipient. Specification will be deferred to leverage the outcome of these efforts

Case Report (all)

Case Report Pre-populate

Mapping of common data elements to EHR data

Release 1 (HITSP/C76)

Case Report Pre-populate

Reporting Criteria Content

Common/basic

Release 1 (HITSP/C82, HITSP/T63)

NA

Case-specific

Release 2

Immature, standards in progress

Reporting Criteria

Clinical Decision Support Content

Trigger Events

Clinical Decision Support Content(Report triggers, prioritization)

Release 2

(Domain TC to flesh out)

CDS:

Reporting Criteria

Triggers

Prioritization

Generic Alert to Identified Clinicians

Clinical Report

Release 2+

Immature Standards

Basic Clinical (scanned) Report

Release 1

(HITSP/C82, HITSP/T63)

Public Report

Release 2+

Immature Standards

Basic Public (scanned) Report

Release 1

(HITSP/C82, HITSP/T63)

Patient-specific Report Document

Basic (scanned) Content, Transport

Release 1 (see Alert and Reporting Criteria discussion below)

(HITSP/C62)

Structured Content, Transport

Release 2 pending CDS

Pending CDS support

Identify Communication Recipients

Support communication of non-PHI alerts and notifications

Release 1

(HITSP/T64)

Terminology Service

Support value set communication to support translation from local vocabulary to standard vocabulary

Release 1

(HITSP/T66)

7.1.1.1 This event for AE invokes an investigation by regulation

1: AE

7.1.1.1 For PH the decision to investigate may be more subjective

1: PH

7.1.1.1 Assume that AE is limited to post-marketing not to clinical trials (note Drug Safety report from IHE is ICHE E2b is pre/post market)

1: AE

7.1.1.1 Data may not apply to AE

Requires a HC provider or someone in the care process to make judgment that an AE occurred

1:AE

7.1.1.1 For AE if it meets regulatory definition for AE, then there must an investigation. For PH the decision to investigate may be more subjective

1:all

7.1.1.1 Medical judgment may need attestation from the clinician; post-marketing situations may have certain tracking/PH response or severity-based decisions (e.g. syphilis VDRL lab generates a report to PH in a 72yr old man clinician may look at this and determine other potential reasons for a false positive and rules out a case). May need clinician validation/human judgment to kick off a next step. There may be a cascade of trigger events there may be limited knowledge as to how to respond to a trigger event.

Same would apply well to patient safety

1:all

7.1.1.2, 7.1.1.3 Forms is a very ambiguous word we may have assumptions surrounding the interpretations. The common aspect is XML

1: All

7.1.1.2, 7.1.1.3 Requires Communicate trigger events from 7.1.1.1

1:All

7.1.1.3 This IS needs to refer to this in an architecturally neutral way. In some states, it may be varied or perhaps regulated (funding, distribution, schedule) differs. (expression of schedule is in 7.4.1)

1:All

7.1.2.1, 7.1.2.2 Handling between PH/AE may be different

1:All

7.1.2.2 Need to consider reporting workflow: ID, review, report

1:All

7.1.3.2, 7.1.5.1 Auto-report option needed

1:All

7.1.3.2, 7.1.5.1 Need to consider workflow management: optionality for human review; review /comment/ modification option before sending

1:All

7.1.3.2 Need to support various reporting users: User may be clinician or office staff/hospital staff (e.g.stand-alone infection control applications, clinical registries, etc.)

1:All

7.1.4.1 Behavior and Policy of PSO is defined by jurisdiction

1: AE

7.1.4.1 Need to consider Case Report workflow: preliminary report with detailed follow-up

1: All

7.1.4.2 Human review: Communication to report outside institution clinician input as to whether or not to report

1: All

7.1.5.3 The Use Case description does not necessarily represent the workflow of what actually happens

1: All

7.1.6.1 Linked/case-associated records (e.g. mom/baby supplement data, food borne outbreak, vaccine failure)

1: All

7.1.6.1 Case finding vs. case investigation are not well distinguished from this step/Use Case data requirements consideration

1: All

7.1.6.2 Authorizations for capture of supplemental data are defined by jurisdiction

1: All

7.1.6.2, 7.1.6.3 Augmentation mechanisms require appropriate authorizations: Not just PH agencies, but clinicians that may be reaching out in various way s to capture data that may not have been available in original data source

1: All

7.1.7.1 Lab reporting to PH is included despite the lack of specified actor in scenario 1: State reporting requirements for condition reporting when a lab value results in a required report

1: PH

7.1.7.1 Assume that confirm means that clinician confirms transmission in that point in time. Clinician may be able to gather info from a PHR

1: All

7.2.1.1 This perspective also represents that of other agencies and professional societies receiving PH information; and agencies AE/patient safety reports (e.g. CDC, CSTE, FDA, AHRQ)

1: All

7.2.1.4 Human readable and machine readable problematic to choose which is wanted for certain classes should have commonality e.g. define ph case a standard way to represent that definition e.g. text sections, list of standards/data elements

1: All

7.2.2.1 if it is a required report, the report is filed; if not required (e.g. AE is not required), does not exist until it is reported

1: All

7.2.2.1 Until the case is reported, the AE or event is not known

1: AE

7.2.2.1 An unreported event may fall under Quality Use Case

1: All

7.2.2.1 The entity that needs to receive/file the report is determined by jurisdiction or domain policy agreements

1: All

7.2.2.1 Trans-border communication expectations/specifications and mutual reporting are specified by policy

1: PH

7.2.2.1 Need to distinguish preliminary notification from confirmed case

1: All

7.2.2.1 PH does not receive initial notification all notifications are to be considered

1: PH

7.2.3.1 PH (FDA and AHRQ are also PH agencies in this case along with state/local/tribal PH)

1,2: All

7.2.3.1 State-level responses are in place for many state preparedness planning

1,2: PH

7.2.3.1 Criticality may require no response other than tallying no investigation typically conducted (e.g. Chlamydia)

1,2: PH

7.2.3.2 Workflow considerations: Feedback loop to go back and clarify with clinician

1,2: All

8.1.1 Assumption is made that this is operating in an acceptably secure environment

2: All

8.1.1.1 There is a triage system; (e.g. there are some conditions that do not trigger a case investigation such as chlamydia)

2: PH

8.1.1.1 Workflow considerations

2: All

8.1.1.1 HepB example need trans-aminase to verify can leverage HIE rather than going back to the clinician for this detail

2: PH

8.1.1.2 Implies inter-jurisdiction exchanges

2: All

8.1.1.2 Same type of information is appropriate to AEs. This is how AEs often work;

Odds of information coming in an electronically standardized fashion is not good (follow-up may be an autopsy report e.g. validating cause of death not necessarily mortality report autopsy report may be used for contributing factors or organ systems/biological changes, discharge summary); no need to have a standardized autopsy report for a data requirement; notification of death is of interest

2: All

8.1.1.3 Implication is that the prior information collection events include collection of data that can represent: PH Cases onset, symptoms, risk factors, laboratory results, procedures, diagnosis, health status, counts, trends, patterns, etc

2: PH

8.1.2.1 Case definition can be defined and can be provided in an unambiguous format

2: All

8.2.1.1 Workflow issue human interaction

2: All

8.1.2.2 PH event may impact a community; from EHR point of view, may not be enough cases to trigger the PH event at community level can detect the event

2: PH

8.1.2.2 Implication that there is an oversight mechanism for refining the definitions; if want a national definition, this needs to be handles with professional society oversight

2: All

8.1.2.2 For AE, process is not as formal

2:AE

8.1.3.1 PH investigation purpose is to identify populations at risk and to contact patients to see if they need to be investigated. Also to do queries on population characteristics

2: All

8.1.3.1 Drug manufacturer may need to ID patients that are similar for Medical devices/drugs; need to add language to extend the definition of contact tracing to apply to population characteristic for drug/med devices etc (e.g. teens/antidepressants; implant in a population at risk)

2: AE

8.1.3.1 Contact Tracing applies to both cases, may be the same in some instances and different in others: AE, Devices, Notification via clinician, Manufacturer

2: All

8.1.3.2 Case count is not the priority/purpose here goal is to manage/contain event not to produce a case count

2: All

8.1.3.2 PH case workers may act in notification process from 7.1; these exposures may not be identified by a clinician may be identified by PH and referred to clinician for treatment

2: PH

8.1.4.1 Assume that the perspective addresses both National and local jurisdiction; Local PH jurisdiction perspective may differ from CDC perspective:

Local PH jurisdiction will have internal tools based on standardization of input data (using CHI vocabularies); Passes through local PH jurisdiction to CDC data are using CHI standards; Many of these cases are cross-jurisdiction; e.g. in CA: if LA county PH in a train derailment chlorine gas issue, may cross multiple counties/jurisdictions need to transfer case reports

2: PH

8.1.4.1 Possibly (for AE is likely locally defined process/edge system issue). Need standard way to transfer the case reports standards for inter-jurisdiction case report/transfer message; from management perspective, issues of If a protocol is needed the protocol may need interoperability (e.g. CAP protocol between networks between HANs)

2:AE

8.1.4.2 Management plan is not an interoperability requirement; AE will not be the same as PH; depending on the nature of event, the management plan will be different depending upon event; This step is not necessarily an automated process and it depends on the issue/agency involved (e.g. FBI)

Multiple agencies may be involved, may be an inter-agency management plan involved;

This is outside scope of HITSP effort

2: All

8.1.4.2 Assumption: Needs human intervention for a management plan

2: All

8.1.4.2 Assumption: Agency-specific, situation-specific determination and is not yet a candidate for automation

2: All

8.1.5.1 The initial communication may differ in the level of detail (depending on PH and AE) confirmation of the 'disease'; for PH it may already be well defined during report event; for AE it may still be undefined that there is an event and this may be a simple confirmation

2: All

8.1.5.2 An example would be TB: Need to represent cases identified by a clinician to researchers looking to investigate a particular strain

2: PH

8.1.5.2 Policy considerations apply to exposure notifications and IRB/research authorization

2: All

8.2.1.1 Jurisdiction or HIE Policy may impose information exchange restrictions for some of these communications if electronic

2: All

8.3.1.2 Lab report content constraints are defined by policy

2: All

8.3.1.2 The feed for the results reporting is not necessarily the same as the report to PH be sure this note is included in the IS

2: All

8.3.2.1 Currently private sector labs are excluded from this information

2: All

Assumption for different types of reports, assume report creators will create a sufficiently unique code assumption that assigning authority would want something unique

2: All

This Use Case assumes the developing presence of electronic systems such as Electronic Health Records (EHRs), Personal Health Records (PHRs), and other local or Web-based solutions supporting consumers and clinicians, while recognizing the issues and obstacles associated with these assumptions. This approach helps promote the development of longer-term efforts. Reference: HITSP Immunizations and Response Management Use Case Requirements, Design and Standards Selection, pg 10, Section 2.2

1, 2: All

HITSP/T16 - Consistent Time SHALL be implemented for each system grouping of actors

1 and 2

HITSP/T17 - Secured Communication Channel SHALL be implemented for each system grouping of actors

1 and 2

The policy of the implementation environment MAY require HITSP/C26 - Nonrepudiation of Origin for one or more information sources initiating a HITSP Transaction with a payload of

Case Report

Reporting Criteria

Unstructured Document (HITSP/C62)

1 and 2

HITSP/T15 - Collect and Communicate Audit Trail SHALL be implemented for each information source initiating a HITSP Transaction with a payload of

Case Report

Reporting Criteria

Unstructured Document (HITSP/C62)

1 and 2

The policy of the implementation environment MAY require HITSP/C19 - Entity Identity Assertion

1 and 2

The policy of the implementation environment MAY require HITSP/C87 - Anonymize for analytical data uses

1 and 2

The policy of the implementation environment MAY require HITSP/T24 - Pseudonymize for analytical data uses

1 and 2

The policy of the implementation environment MAY require the HITSP/TP20 - Access Control

1 and 2

The policy of the implementation environment WILL require the HITSP/TP30 - Manage Consent Directives wherever access to IIHI is required

1 and 2

Support the technical measures to ensure Security and Privacy of consumer/patient health information

All

Authentication service to authenticate requestors and/or data submissions from various locations

All

Security and Privacy policies, procedures and practices are commonly implemented to support acceptable levels of consumer/patient security and privacy

All

Legal and governance issues regarding data access authorizations, data ownership, and data use are in effect

All

Support the following HITSP Security and Privacy constructs:

HITSP/C19 Entity Identity Assertion

HITSP/T16 - Consistent Time Maintain time

HITSP/T17 - Secured Communication Channel Authenticate node

HITSP/T15 - Collect and Communicate Security Audit Trail Record audit event in repository

HITSP/TP30 - Manage Consent Directives Capture/Request consent directive

HITSP/TP20 - Access Control Access control request

All

All pre-conditions from the lower level constructs are incorporated

All

When needed, the patient is uniquely registered with the Patient Identity Cross-Referencing service

All

Patient Identities (name, demographics etc.) are known and are consistent with policies

All

There is an existing electronic record from which reports can be generated

All

8.1.1.1 Pre-condition (for this scenario, there are rules in place that guide the prioritization and workflow considerations)

NOTE: Challenging pre-condition as these do not exist in any electronic processable format; cases subject to investigation are designated notifiable would be the pre-condition may be some cases (AE included) where it is always subject to a case investigation

2

Scenario 1 Cases for investigation have been communicated

2

Immunizations and Response Management Use Case reporting of an adverse event

2

Appropriate case report information has been communicated and acted upon by Public Health

1

The case investigation has been concluded

2

Informing the PH decision making process

2

Various sources may communicate information which assists public health in determining criteria including: trigger data and reporting specifications:

An update to the decision process rules. These may be event-driven or routine updates

1

Clinicians may initially notify Public Health of possible PH Cases or Adverse Events through information exchange activities or in an ad-hoc manner. Clinicians may also notify Manufacturers of possible AEs through information exchange activities or in an ad-hoc manner

A possible reportable event is detected or suspected. Human review is performed on possible events to make the final decision on reporting

Lab:

Requirement for reporting to public health met typically either a positive result or a required measured result (e.g. blood lead)

1

Possible AEs may be communicated to clinicians which may be internal or external to a public health setting. Specifics are addressed in the 2008 Immunizations and Response Management Detailed Use Case

An external report was received by Public Health that indicates a detected or suspected adverse event. Human review is performed by public health on possible events to make the final decision on reporting

1

Possible PH Cases or AE reports may be communicated via information exchange activities to public health

A possible reportable event is detected or suspected. Human review is performed on possible events to make the final decision on reporting

NOTE: Triggers for AE, may have a broad category and add human intervention; sensitivity is high, and specificity is low - err on the side of false positives; Re-training the workforce will enable more specificity

1

Public Health accesses additional information to assist in their investigations. Therefore, additional Information is requested by PH, the request is received by clinicians, and additional information is provided to Public Health via health information exchange activities

Information reported to Public Health is sufficient to begin a case investigation. Public Health investigates the report and finds that it needs additional information to develop the case investigation

2

Public Health communicates case and/or patient specific information to clinicians and laboratories via health information exchange activities

Public Health decides it needs to communicate information to the clinician community and chooses the appropriate means to do community

2

Public Health communicates specific information supporting clinical care to other public health agencies/ organizations via information exchange activities

Public Health decides it needs to communicate information to the public health community and chooses the appropriate means to do community

NOTE: Intra-government issues trigger events may cause the need to involve another federal agency same issue for state/local government

2

Public Health communicates publicly available information to other entities via information exchange activities

Public Health decides it needs to communicate information to the general public and chooses the appropriate means to do community

2

Based on Public Health information received via health information exchanges, clinicians may manage and treat PH Cases. Specifics are addressed in the 2008 Immunizations and Response Management Detailed Use Case

The clinician has patients or patients with contacts that are subject to a Public Health notification

2

Access Control Service (ACS)

The enterprise security service that supports and implements user-side and/or service side access control capabilities. This service would be utilized by the Service User, and/or Service Provider

HITSP/TP20

Alert Message Receiver

This actor receives notifications and emergency data from the Message Transmitter

HITSP/T63

Alert Message Transmitter

The holder of emergency data that is communicating that data to the message receiver

HITSP/T63

Audit Record Repository

This actor provides a repository for audit events

HITSP/T15

Audit Record Source

The actor that, on behalf of another actor that performs an action requiring logging, creates and communicates an Audit Record to the Audit Record Repository

HITSP/T15

Clinical Data Consumer

A clinical data consumer makes use of clinical patient data

HITSP/TP21

Clinical Data Source

Maintains patient information about vital signs, problem and allergies, results from diagnostic tests (e.g., Lab, Imaging, or other test results), medications, immunizations or historical or planned visits and procedures

HITSP/TP21

Consent Directive Requestor

Accesses consent directive located through a Consent Registry from Consent Repositories, (lack of definition in current public comment version)

HITSP/TP30

Consent Originator

Captures consent directives and may publish the consent directive as a document. It is responsible for sending Manage Consent Directive Requests to a Consent Repository. It also supplies Metadata to the Consent Repository for subsequent registration of the Consent within a Consent Registry

HITSP/TP30

Consent Registry

Responsible for providing location information and sender notification regarding consent directives. The Consent Registry receives a Manage Consent Directive Metadata Request

HITSP/TP30

Consent Repository

Responsible for both the persistent storage of consent directives as well as for their registration with the appropriate Consent Registry. It assigns a Uniform Resource Identifier (URI) and Metadata such as confidentiality codes to the Consent Directive for subsequent retrieval by an authorized consumer, e.g., for association with published personal health information or for evaluation at a policy decision point

HITSP/TP30

Content Consumer

Responsible for viewing, import, or other processing of content created by a Content Creator Actor

HITSP/C32

HITSP/C48

HITSP/C35

HITSP/C36

HITSP/C37

HITSP/C62

HITSP/C75

HITSP/C76

HITSP/C80

HITSP/C83

HITSP/C87

HITSP/C26

HITSP/C82

HITSP/TP30

Content Creator

Responsible for the creation of content and transmission to a Content Consumer

HITSP/C32

HITSP/C48

HITSP/C35

HITSP/C36

HITSP/C37

HITSP/C62

HITSP/C75

HITSP/C76

HITSP/C80

HITSP/C83

HITSP/C87

HITSP/C26

HITSP/C82

HITSP/TP30

Diagnostic Data Repository

A Diagnostic Data Repository maintains results from diagnostic tests (e.g., Lab, Imaging, or other test results)

HITSP/TP21

DNS Server

This actor has authoritative location information

HITSP/T64

Document Consumer

The Document Consumer queries a Document Registry for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors

HITSP/TP13

Document Recipient

This actor receives a set of documents sent by another actor. Typically this document set will be made available to the intended recipient who will choose to either view it or integrate it into a Health Record

HITSP/TP31

Document Registry

The Document Registry maintains metadata about each registered document in a document entry. This includes a link to the Document in the Repository where it is stored. The Document Registry responds to queries from Document Consumer actors about documents meeting specific criteria. It also enforces some healthcare specific technical policies at the time of document registration

HITSP/TP13

Document Repository

Responsible for both the persistent storage of these documents as well as for their registration with the appropriate Document Registry. It assigns a Uniform Resource Identifier (URI) to documents for subsequent retrieval by a Document Consumer

HITSP/TP13

Document Source

Producer and publisher of documents. It is responsible for sending documents to a Document Repository Actor. It also supplies metadata to the Document Repository Actor for subsequent registration of the documents with the Document Registry Actor

HITSP/TP13

HITSP/T31

Form Archiver

The actor responsible for receiving form instance data for archival purposes. For Quality, supports the option to enable manual or cut/paste information capture of patient level quality data content

HITSP/TP50

Form Filler

The actor responsible for retrieving a form from a Form Manager and for submitting form instance data to a Form Receiver. The mechanism by which a unique identification of a form is obtained is outside the scope of the Retrieve Form for Data Capture profile. For Quality, used as an option to enable manual or cut/paste information capture of patient level quality data content. For Quality, Option for CIS to enable manual or cut/paste information capture

HITSP/TP50

Form Manager

The actor that supplies a form based upon a request that supplies unique form identification. For Quality, used as an option to enable manual or cut/paste information capture of patient level quality data content

HITSP/TP50

Form Receiver

The actor that receives form instance data. For Quality, supports the option to enable manual or cut/paste information capture of patient level quality data content

HITSP/TP50

Identity Provider

Receives the credentials and identifier from the Entity (principal). It may perform authentication at that point or may require additional authentication from another source (the Service Provider)

HITSP/C19

Immunizations Data Repository

Maintains patient immunization data

HITSP/TP21

Knowledge Requestor

System that formulates and sends a contextual request for ancillary information about a medical concept. Takes the parameters and sends to the resource available

HITSP/T81

Knowledge Resource

The system that holds the information requested and responds to the request from the Knowledge Requestor

HITSP/T81

Laboratory Result Message Receiver

An authorized entity that is receiving a laboratory result message

HITSP/T14

Laboratory Result Message Sender

The holder of a laboratory result who is communicating a laboratory result message to another actor

HITSP/T14

Medications Data Repository

A Medications Data Repository maintains patient medication data

HITSP/TP21

Node

The originating or terminating point of information or signal flow in a telecommunications network. This actor is equivalent to the Secure Node in the IHE-ITI-TF ATNA Transaction

HITSP/T17

Notification Receiver

Receives notifications of availability for documents in an XDS registry, and may optionally send acknowledgments of them

HITSP/T29

Notification Sender

Sends notifications of availability for documents in an XDS registry, and receives acknowledgements of these notifications

HITSP/T29

Patient Demographics Consumer

Queries the Patient Demographics Supplier for a list of patient demographic information, if any, and receives a list of corresponding patient demographic information from the Patient Demographics Supplier

HITSP/T23

Patient Demographics Supplier

Receives the query for a list of corresponding patient demographics from the Patient Demographics Consumer, sends a list of corresponding patient demographic information to the Patient Demographics Consumer, maintains one or more Patient Information Sources of patient demographics data

HITSP/T23

Patient Identifier Cross-Reference Consumer

Queries the Patient Identifier Cross-Reference Manager for a list of corresponding patient identifiers, if any and receives a list of corresponding patient identifiers from the Patient Identifier Cross-Reference Manager

HITSP/TP22

Patient Identifier Cross-Reference Manager

Receives the query for a list of corresponding patient identifiers from the Patient Identifier Cross-Reference Consumer. Sends a list of corresponding patient identifiers to the Patient Identifier Cross-Reference Consumer. Receives patient demographic information from the Patient Identity Source

HITSP/TP22

Patient Identity Source

Sends patient demographic information when requested, assigns a unique identifier to each instance of a patient, and maintains a collection of identity traits

HITSP/TP22

HITSP/T24

Person Identification Service

System that maintains a cross-domain person and/or patient index including all known identifiers (real and pseudo) for each person and/or patient, within all domains with which it communicates

HITSP/T24

Personnel White Pages Consumer

This actor has a use for information that can be found in the Personnel White Pages Directory

HITSP/T64

Personnel White Pages Directory

This actor has authoritative Personnel White Pages information on the human workforce members of the enterprise

HITSP/T64

Portable Media Creator

The Portable Media Creator writes the selected information to media (CD-ROM, USB-Memory, e-Mail) following the directory structure outlined by XDMThe Portable Media Creator writes the selected information from a consumers PHR to media following the directory structure outlined by XDM

HITSP/T33

Portable Media Importer

The Portable Media Importer reads the selected information from media (CD-ROM, USB-Memory, e-Mail) following the directory structure outlined by XDMThe Portable Media Importer processes all the contents written by a Portable Media Creator on the physical media. The Portable Media Importer must successfully process all documents

HITSP/T33

Problems and Allergies Data Repository

Maintains patient problems and allergy data

HITSP/TP21

Professional Services Data Repository

A Professional Services Data Repository maintains data about historical or planned visits and procedures

HITSP/TP21

Pseudonymization Service

Supplier of alternative identification information that permits a patient to be referred to by a key that suppresses his/her actual identification information

HITSP/T24

Service Provider (SP)

The Service Provider represents the system providing a protected resource and relies on the provided security service

HITSP/TP20

HITSP/C19

Service User

The entity represents any individual entity (such as a clinician or an EHR/PHR system) that needs to make a service request of a Service Provider. The Entity may also be known as a principal and/or entity, which represents an end user, an application, a machine, or any other type of entity that may act as a requester in a transaction. A principal is typically represented in a transaction with a digital identity and the principal may have multiple valid digital identities to use with different transaction

HITSP/TP20, HITSP/C19

Time Client

Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers

HITSP/T16

Time Server

Provides NTP time services to Time Clients. It is either directly synchronized to a UTC master clock (e.g. satellite time signal) or is synchronized by being grouped with a Time Client to other Time Server(s)

HITSP/T16

Value Set Consumer

An actor that receives a specific, new, or updated terminology based on its OID, and possibly its version if the latter is available

HITSP/T66

Value Set Repository

A Vital Signs Data Repository maintains patient vital signs data

HITSP/T66

Laboratory Information Systems (Message Sender/Bio Data Sender, Document Source)

Content Creator

R

HITSP/C35

Lab Result Terminology

R

C ^{[ 105 ]}

HITSP/C36

Lab Result Message

R

C ^{[ 105 ]}

HITSP/C37

Lab Report Document Component

R

C ^{[ 10 7]}

HITSP/T24

Pseudonymization Request

R

C ^{[ 10 8]}

HITSP/C87

Anonymize

R

Patient Demographic Consumer

C ^{[ 101 ]}

HITSP/T23

Patient Demographics Query

R

Patient Identity Source

C ^{[ 101 ]}

HITSP/TP22

PIX Identity Feed

R

PIX Consumer

C ^{[ 101 ]}

HITSP/TP22

PIX Query

R

PIX Update Notification

O

Document Source

C ^{[ 102 ]}

C ^{[ 105 ]}

HITSP/TP13

Provide & Register Document Set-b

C ^{[ 20 2]}

Provide & Register Document Set

C ^{[ 20 2]}

HITSP/C19

Convey Assertion

O

Document Consumer

O

HITSP/TP13

Registry Stored Query

C ^{[ 20 3]}

Retrieve Document Set

C ^{[ 20 3]}

Stored Query

C ^{[ 20 3]}

Retrieve Document

C ^{[ 20 3]}

HITSP/C19

Convey Assertion

O

Document Repository

O

HITSP/TP13

Provide and Register Document Set-b

C ^{[ 20 4]}

Register Document Set-b

C ^{[ 20 4]}

Retrieve Document Set

C ^{[ 20 4]}

Register Document Set

C ^{[ 20 4]}

Provide & Register Document Set

C ^{[ 20 4]}

Retrieve Document

C ^{[ 20 4]}

HITSP/C19

Convey Assertion

O

Document Registry

O

HITSP/TP13

Patient Identity Feed

R

Registry Stored Query

C ^{[ 205 ]}

Provide & Register Document Set-b

C ^{[ 205 ]}

Stored Query

C ^{[ 205 ]}

Provide & Register Document Set

C ^{[ 205 ]}

Provide & Register Document Set (offline mode)

C ^{[ 205 ]}

HITSP/C19

Convey Assertion

O

Laboratory Result Message Sender

C ^{[ 104 ]}

C ^{[ 105 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Laboratory Result Message Receiver

C ^{[ 104 ]}

C ^{[ 106 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Audit Record Source

R

HITSP/T15

Record Audit Event in Repository

R

Audit Record Repository

O

HITSP/T15

Record Audit Event in Repository

R

Time Client

R

HITSP/T16

Maintain Time

R

Time Server

O

HITSP/T16

Maintain Time

R

Node

R

HITSP/T17

Secured Communication Channel

R

Identity provider

C ^{[11 3 ]}

HITSP/C19

Provide Assertion

R

Verify Assertion

O

Consent Originator

O

HITSP/TP30

Provide and Register Document Set

R

Consent Registry

O

HITSP/TP30

Register Document Set

R

Stored Query

R

Consent Repository

O

HITSP/TP30

Provide and Register Document Set

R

Register Document Set

R

Consent Directive Requestor

R

HITSP/TP30

Stored Query

R

Retrieve Document Set

R

Service User

R

HITSP/TP20

Access Control Request

O

Access Control Service

R

HITSP/TP20

Access Control Request

O

Service Provider

C ^{[ 102 ]}

HITSP/TP20

Access Control Request

O

Electronic Health Record (EHR) System

Patient Identity Source

C ^{[ 101 ]}

HITSP/T23

Patient Demographics Query

R

PIX Consumer

C ^{[ 101 ]}

HITSP/TP22

PIX Identity Feed

R

PIX Query

R

Patient Demographics Consumer

C ^{[ 101 ]}

HITSP/T23

Patient Demographics Query

R

Laboratory Result Message Sender

C ^{[ 104 ]}

C ^{[ 105 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Laboratory Result Message Receiver

C ^{[ 104 ]}

C ^{[ 106 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Document Source

C ^{[ 102 ]}

C ^{[ 105 ]}

HITSP/TP13

Provide & Register Document Set-b

C ^{[ 20 2]}

Provide & Register Document Set

C ^{[ 20 2]}

HITSP/C19

Convey Assertion

O

Document Consumer

C ^{[ 102 ]}

C ^{[ 106 ]}

HITSP/TP13

Registry Stored Query

C ^{[ 20 3]}

Retrieve Document Set

C ^{[ 20 3]}

Stored Query

C ^{[ 20 3]}

Retrieve Document

C ^{[ 20 3]}

HITSP/C19

Convey Assertion

O

Document Repository

O

HITSP/TP13

Provide and Register Document Set-b

C ^{[ 20 4]}

Register Document Set-b

C ^{[ 20 4]}

Retrieve Document Set

C ^{[ 20 4]}

Register Document Set

C ^{[ 20 4]}

Provide & Register Document Set

C ^{[ 20 4]}

Retrieve Document

C ^{[ 20 4]}

HITSP/C19

Convey Assertion

O

Document Registry

O

HITSP/TP13

Patient Identity Feed

R

Registry Stored Query

C ^{[ 205 ]}

Provide & Register Document Set-b

C ^{[ 205 ]}

Stored Query

C ^{[ 205 ]}

Provide & Register Document Set

C ^{[ 205 ]}

HITSP/C19

Convey Assertion

O

Portable Media Creator

C ^{[ 105 ]}

C ^{[ 10 9]}

HITSP/T33

Distribute Document Set on Media

R

Portable Media Importer

C ^{[ 106 ]}

C ^{[ 10 9]}

HITSP/T33

Distribute Document Set on Media

R

Document Source

C ^{[ 103 ]}

C ^{[ 105 ]}

C ^{[ 110 ]}

HITSP/T31

Provide & Register Document Set.b (online mode)

R

HITSP/C19

Convey Assertion

O

Document Recipient

C ^{[ 106 ]}

C ^{[ 110 ]}

HITSP/T31

Provide & Register Document Set.b (online mode)

R

HITSP/C19

Convey Assertion

O

Clinical Data Consumer

O

HITSP/TP21

Query Existing Data

C ^{[ 20 2]}

HITSP/C19

Convey Assertion

O

Clinical Data Source

O

HITSP/TP21

Query Existing Data

R

HITSP/C19

Convey Assertion

O

Knowledge Requestor

O

HITSP/T81

Retrieve Topic Medical Knowledge

R

Value Set Consumer

O

HITSP/T66

Retrieve Value Set

R

Form Filler

R

HITSP/TP50

Retrieve Form

R

HITSP/TP50

Submit Form

R

HITSP/TP50

Archive Form

O

HITSP/TP50

Retrieve Clarifications

O

Form Manager

O

HITSP/TP50

Retrieve Form

R

Retrieve Clarifications

R

Form Receiver

O

HITSP/TP50

Submit Form

R

Form Archiver

O

HITSP/TP50

Archive Form

R

Content Creator

O

HITSP/C75

Adverse Event Reports: CDC Healthcare Associated Infection Reporting

C ^{[ 201 ]}

R

HITSP/TP30

Consent Document

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

O

HITSP/C76

Case Report Pre-Populate

R

C ^[111]

HITSP/C35

Lab Result Terminology

R

O

HITSP/C36

Lab Result Message

R

O

HITSP/C37

Lab Report Document Component

R

C ^{[ 10 7]}

HITSP/T24

Pseudonymization Request

R

C ^{[ 10 8]}

HITSP/C87

Anonymize

R

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C82

Emergency Common Alerting Protocol

R

Content Consumer

R

HITSP/C62

Unstructured Document

O

R

HITSP/TP30

Consent Document

R

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C82

Emergency Common Alerting Protocol

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

Audit Record Source

R

HITSP/T15

Record Audit Event in Repository

R

Audit Record Repository

O

HITSP/T15

Record Audit Event in Repository

R

Time Client

R

HITSP/T16

Maintain Time

R

Time Server

O

HITSP/T16

Maintain Time

R

Node

R

HITSP/T17

Secured Communication Channel

R

Identity Provider

C ^{[11 3 ]}

HITSP/C19

Provide Assertion

R

Verify Assertion

O

Consent Originator

O

HITSP/TP30

Provide and Register Document Set

R

Consent Registry

O

HITSP/TP30

Register Document Set

R

Stored Query

R

Consent Repository

O

HITSP/TP30

Provide and Register Document Set

R

Register Document Set

R

Consent Directive Requestor

R

HITSP/TP30

Stored Query

R

Retrieve Document Set

R

Service User

R

HITSP/TP20

Access Control Request

O

Access Control Service

R

HITSP/TP20

Access Control Request

O

Service Provider

C ^{[ 102 ]}

HITSP/TP20

Access Control Request

O

Health Information Exchange (HIE)

Patient Demographic Supplier

C ^{[ 101 ]}

HITSP/T23

Patient Demographics Query

R

PIX Manager

C ^{[ 101 ]}

HITSP/TP22

PIX Identity Feed

R

PIX Query

R

Laboratory Result Message Sender

C ^{[ 104 ]}

C ^{[ 105 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Laboratory Result Message Receiver

C ^{[ 104 ]}

C ^{[ 106 ]}

HITSP/T14

Send Lab Result Message

R

HITSP/C35

Lab Result Terminology

R

HITSP/C36

Lab Result Message

R

Person Identification Service

C ^{[ 10 7]}

HITSP/T24

Person Identity Feed

R

Person Identity Cross-Reference Query

R

PIX Update Notification

R

Pseudonymization Request

R

Document Source

R

HITSP/TP13

Provide & Register Document Set

R

HITSP/C19

Convey Assertion

O

Document Consumer

R

HITSP/TP13

Query Registry

R

Retrieve Documents

R

HITSP/C19

Convey Assertion

O

Form Manager

O

HITSP/TP50

Retrieve Form

R

Retrieve Clarifications

R

Form Receiver

O

HITSP/TP50

Submit Form

R

Form Archiver

O

HITSP/TP50

Archive Form

R

Content Creator

O

HITSP/C75

Adverse Event Reports: CDC Healthcare Associated Infection Reporting

C ^{[ 201 ]}

R

HITSP/TP30

Consent Document

R

O

HITSP/C76

Case Report Pre-Populate

R

C ^[111]

HITSP/C35

Lab Terminology

R

O

HITSP/C36

Lab Message

R

O

HITSP/C37

Lab Report Document Component

R

C ^{[ 10 7]}

HITSP/T24

Pseudonymization Request

R

C ^{[ 10 8]}

HITSP/C87

Anonymize

R

O

HITSP/C62

Unstructured Document

R

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C82

Emergency Common Alerting Protocol

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

Alert Message Transmitter

O

HITSP/T63

Send Alert Message

R

HITSP/C82

Non Patient Notification Message

C ^{[ 201 ]}

HITSP/C19

Convey Assertion

O

Pseudonymization Service

O

HITSP/T24

Pseudonymize

R

Personnel White Pages Directory

O

HITSP/T64

Query Personnel White Pages

R

Knowledge Source

O

HITSP/T81

Retrieve Topic Medical Knowledge

R

Value Set Repository

O

HITSP/T66

Retrieve Value Set

R

Content Consumer

R

HITSP/C62

Unstructured Document

O

R

HITSP/TP30

Consent Document

R

O

HITSP/C76

Case Report Pre-Populate

R

O

HITSP/C75

Adverse Event Reports: CDC Healthcare Associated Infection Reporting

C ^{[ 201 ]}

O

HITSP/C62

Unstructured Document

R

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C82

Emergency Common Alerting Protocol

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

Audit Record Source

R

HITSP/T15

Record Audit Event in Repository

R

Audit Record Repository

O

HITSP/T15

Record Audit Event in Repository

R

Time Client

R

HITSP/T16

Maintain Time

R

Time Server

O

HITSP/T16

Maintain Time

R

Node

R

HITSP/T17

Secured Communication Channel

R

Identity Provider

C ^{[11 3 ]}

HITSP/C19

Provide Assertion

R

Verify Assertion

O

Consent Originator

O

HITSP/TP30

Provide and Register Document Set

R

Consent Registry

O

HITSP/TP30

Register Document Set

R

Stored Query

R

Consent Repository

O

HITSP/TP30

Provide and Register Document Set

R

Register Document Set

R

Consent Directive Requestor

R

HITSP/TP30

Stored Query

R

Retrieve Document Set

R

Service User

R

HITSP/TP20

Access Control Request

O

Access Control Service

R

HITSP/TP20

Access Control Request

O

Service Provider

C ^{[ 102 ]}

HITSP/TP20

Access Control Request

O

Public Health Information System

Patient Demographic Consumer

O

HITSP/T23

Patient Demographics Query

R

Patient Identity Source

O

HITSP/TP22

PIX Identity Feed

R

PIX Consumer

O

HITSP/TP22

PIX Query

R

Personnel White Pages Directory

O

HITSP/T64

Query Personnel White Pages

R

Personnel White Pages Consumer

O

HITSP/T64

Find Personnel White Pages

O

Query Personnel White Pages

R

Notification Sender

O

HITSP/T29

Send Notification

R

Notification Receiver

O

HITSP/T29

Send Notification

R

Document Recipient

O

HITSP/T31

Receive Document

R

HITSP/C19

Convey Assertion

O

Alert Message Transmitter

O

HITSP/T63

Send Alert Message

R

HITSP/C82

Non Patient Notification Message

C ^{[ 201 ]}

HITSP/C19

Convey Assertion

O

Value Set Repository

O

HITSP/T66

Retrieve Value Set (response)

R

Pseudonymization Service

O

HITSP/T24

Pseudonymize

R

Knowledge Resource

O

HITSP/T81

Retrieve Topic Medical Knowledge

R

Alert Message Receiver

O

HITSP/T63

Send Alert Message

C ^{[ 201 ]}

HITSP/C82

Emergency Common Alerting Protocol

C ^{[ 201 ]}

HITSP/C19

Convey Assertion

O

Laboratory Message Receiver

C ^{[ 104 ]}

C ^{[ 106 ]}

HITSP/IS06

Receive Message

R

Send Ack

R

Document Source

C ^{[ 103 ]}

C ^{[ 105 ]}

HITSP/TP13

Provide & Register Document Set

R

HITSP/C19

Convey Assertion

O

Document Consumer

C ^{[ 103 ]}

C ^{[ 106 ]}

HITSP/TP13

Query Registry

R

Retrieve Documents

R

HITSP/C19

Convey Assertion

O

Portable Media Creator

C ^{[ 105 ]}

C ^{[ 10 9]}

HITSP/T33

Distribute Document Set on Media

R

Portable Media Importer

C ^{[ 106 ]}

C ^{[ 10 9]}

HITSP/T33

Distribute Document Set on Media

R

Document Source

C ^{[ 105 ]}

C ^{[ 110 ]}

HITSP/T31

Provide & Register Document Set.b (online mode)

R

HITSP/C19

Convey Assertion

O

Document Recipient

C ^{[ 103 ]}

C ^{[ 106 ]}

C ^{[ 110 ]}

HITSP/T31

Provide & Register Document Set.b (online mode)

R

HITSP/C19

Convey Assertion

O

Form Manager

O

HITSP/TP50

Retrieve Form

R

Retrieve Clarifications

R

Form Receiver

O

HITSP/TP50

Submit Form

R

Form Archiver

O

HITSP/TP50

Archive Form

R

Content Creator

R

HITSP/C62

Unstructured Document

O

C ^{[ 10 7]}

HITSP/T24

Pseudonymization Request

R

C ^{[ 10 8]}

HITSP/C87

Anonymize

R

R

HITSP/C62

Unstructured Document

R

R

HITSP/TP30

Consent Document

R

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

Content Consumer

R

HITSP/C82

Emergency Common Alerting Protocol

R

R

HITSP/TP30

Consent Document

R

O

HITSP/C76

Case Report Pre-Populate

R

O

HITSP/C75

Adverse Event Reports: CDC Healthcare Associated Infection Reporting

C ^{[ 201 ]}

R

HITSP/C35

Lab Result Terminology

R

C ^{[ 105 ]}

HITSP/C36

Lab Result Message

R

C ^{[ 105 ]}

HITSP/C37

Lab Report Document

R

R

HITSP/C62

Unstructured Document

O

O

HITSP/C26

Nonrepudiation

R

O

HITSP/C82

Emergency Common Alerting Protocol

R

O

HITSP/C32

Summary Documents Using HL7 Continuity of Care Document (CCD)

R

O

HITSP/C48

Encounter Document Using IHE Medical Summary (XDS-MS)

R

Audit Record Source

R

HITSP/T15

Record Audit Event in Repository

R

Audit Record Repository

O

HITSP/T15

Record Audit Event in Repository

R

Time Client

R

HITSP/T16

Maintain Time

R

Time Server

O

HITSP/T16

Maintain Time

R

Node

R

HITSP/T17

Secured Communication Channel

R

Identity Provider

C ^{[11 3 ]}

HITSP/C19

Provide Assertion

R

Verify Assertion

O

Consent Originator

O

HITSP/TP30

Provide and Register Document Set

R

Consent Registry

O

HITSP/TP30

Register Document Set

R

Stored Query

R

Consent Repository

O

HITSP/TP30

Provide and Register Document Set

R

Register Document Set

R

Consent Directive Requestor

R

HITSP/TP30

Stored Query

R

Retrieve Document Set

R

Service User

R

HITSP/TP20

Access Control Request

O

Access Control Service

R

HITSP/TP20

Access Control Request

O

Service Provider

C ^{[ 102 ]}

HITSP/TP20

Access Control Request

O

101

Shall support (Patient Identity Source plus PIX Consumer) and/or Patient Demographics Consumer where shared patient identity management interoperability is to be supported

102

Required if Access Control Request Transaction is not supported

103

Required when a Document Repository and/or a Document Registry is supported

104

Required for message-based functional flow

105

Business Actor shall support at least one of these technical actors to communicate outbound content

106

Business Actor shall support at least one of these technical actors to receive or retrieve inbound content

107

Required where pseudonymization is required by the jurisdiction or information sharing agreements or selected by PHR

108

Required where anonymization is required by the jurisdiction or information sharing agreements or selected by PH

109

Required for Portable Media support

110

Required for Document Reliable Interchange support

111

Required where C36 or C37 is supported

112

Required where C32, C48, or C75 is supported

113

There must be at least one in a group of business actors

201

Shall support either form filler or case report construct

202

The Actor shall support at least one of these transactions

203

The Document Consumer shall support either XDS.a transactions, XDS.b transactions, or both. Where Identity Assertion is required, the Document Consumer shall support XDS.b (Registry Stored Query, Retrieve Document Set)

204

The Document Repository shall support either XDS.a transactions, XDS.b transactions, or both. Where Identity Assertion is required, the Document Repository shall support XDS.b (Provide & Register Document Set-b, Register Document Set-b, Retrieve Document Set)

205

The Document Registry shall support either XDS.a transactions, XDS.b transactions, or both. Where Identity Assertion is required, the Document Repository shall support XDS.b to query the registry (Registry Stored Query)

HITSP/T63 - Emergency Message Distribution Element

HITSP/T64 Identify Communication Recipients

Pre-condition

Retrieve communication parameters

HITSP/C62 Unstructured Document

HITSP/T64 Identify Communication Recipients

Pre-condition

Retrieve communication parameters

HITSP/C62 Unstructured Document

HITSP/T29 - Notification of Document Availability

Pre-condition

Communicate notification of document availability and location

HITSP/C62 Unstructured Document

HITSP/TP13 or HITSP/T31 or HITSP/T33

Pre-condition

Transport mechanism for notification

HITSP/C76 Case Report Pre-Populate

HITSP/TP50 Retrieve Form for Data Capture

Pre-condition

RFD form pre-population is supported by C76

Contact Person: The name of the person to be contacted for further information

HITSP/TP50

HL7 Name

General

Coded interoperable content

Contact Phone Number: The telephone number for the contact person

HITSP/TP50

HL7 Phone

General

Coded interoperable content

Report Date: The date that the Case Report is being sent

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Reported Previously: Indication if the information is supplemental to update in event already reported

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Report sent to FDA: Indication if the report is submitted to the Food and Drug Administration (FDA)

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Date User Facility/ Importer Became Aware of Event: The date the event was first recognized by an observer

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Date report sent: The date the report is submitted

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Date sent to FDA: The date the report was submitted to the FDA U.S.

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Report Source: The originator of the report

HITSP/TP50

Where possible, use HL7 Table 0235 Report source Value

CClinical trial

LLiterature

HHealth professional

RRegulatory agency

D Database/r egistry/ poison control center

NNon-healthcare professional

PPatient

MManufacturer/ marketing authority holder

EDistributor

OOther -

General

Coded interoperable content (may be updated in future IS11 Releases pending additional C80 review)

Reporter Name: The name of the person or facility sending the Case Report

HITSP/TP50

HL7 Name

General

Coded interoperable content

Occupation of Reporter: The role of the reporter (e.g., physician, nurse, administrator, etc.)

HITSP/TP50

North American Industry Classification System

General

Coded interoperable content

Telephone: The phone number of the person or facility sending the Case Report

HITSP/TP50

HL7 Phone

General

Coded interoperable content

Reporter Email: The email contact information for the reporter

HITSP/TP50

HL7 email

General

Coded interoperable content

Patient Country: The country of the address of the subject of the case report

HITSP/TP50

ISO 3166-1

General

Coded interoperable content

Occupation: The occupation of subject of the case report

HITSP/TP50

North American Industry Classification System

General

Coded interoperable content

Location where Event Occurred: The location of the event e.g., home, hospital, other facility, etc

HITSP/TP50

HAI Service Delivery Location HL7, Home, Work

General

Coded interoperable content

Event Abated after use stopped or dose reduced: Indication that the event resolved/ abated after usage stopped or dose reduced

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Event Reappeared after reintroduction: Indication if the reaction reoccurred after rechallenging the patient to the suspected substance

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Immunization Services Funding Eligibility: Indication of vaccination source (e.g., special program such as Vaccine for Children, state or provincial programs, etc)

HITSP/TP50

C80 data element for financial class 2.2.3.5.5Immunization Services Funding Eligibility

General

Coded interoperable content

Product Diagnosis for Use: The reason the product was initially used

HITSP/TP50

Shall be coded as specified in HITSP/C80 Section 2.2. 3.1.3 Diagnosis

General

Coded interoperable content

Expiration Date: The expiration date of the product

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Manufacturer name, City and State: Manufacturer of the device

HITSP/TP50

The State component shall be coded as specified in HITSP/C80 Section 2.2.1.1.1 State

General

Coded interoperable content

Operator of Device: The individual managing the device (e.g. Health professional, lay user, patient, other)

HITSP/TP50

North American Industry Classification System

General

Coded interoperable content

If implanted give date: Date of implantation of the device (if implanted)

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

If explanted give date: Date device was removed (if removed)

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Is this a single use device that was reprocessed and reused on patient?: Indication if the device is a single-use device that was cleaned/reprocessed and is reused on the affected patient

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Administration of Treatment: Was treatment administered?

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Name and Address of Reprocessor: Name and address of the individual/organization reprocessing the single use device

HITSP/TP50

The State component shall be coded as specified in HITSP/C80 Section 2.2.1.1.1 State

General

Coded interoperable content

Product available for evaluation: Indication if the product is still available to be evaluated

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Date product returned to manuf.: If returned to the manufacturer, date of return

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Concomitant Medical Products & Therapy Dates: Other medical products and treatment used proximal to the event

HITSP/TP50

Medications should reference NDC and RxNorm as identified in HITSP/C80. Vaccines are represented by CVX codes (also identified in HITSP/C80). Non-medication product terms are to be represented with ICSR 3 and therefore, these are a GAP for this release. In the user interface, the user will need to select one or more (n) of a list.

General

Coded interoperable content

AE Following Prior Vaccination: Description of the adverse event

HITSP/TP50

In HITSP/C80, the VA/KP SNOMED Subset identifies adverse events (e.g., hives, difficulty breathing) and is selected for reporting adverse events (from the Allergy/Adverse Event section of a document).

General

Coded interoperable content

Suspect Product Name: Product name

HITSP/TP50

Medications should reference NDC and RxNorm as identified in HITSP/C80. Vaccines are represented by CVX codes (also identified in HITSP/C80). Non-medication product terms are to be represented with ICSR 3 and therefore, these are a GAP for this release. In the user interface, the user will need to select one or more (n) of a list.

General

Coded interoperable content

Reporting Laboratory Identifier: Identifier for laboratory that is sending the result. This laboratory may be sending results received back from reference laboratories

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Performing Laboratory: Laboratory that produced the test result. This may be a reference laboratory identifier

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Ordered Test Code: The identifier code for the requested observation/test/battery

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Date of Test: The date that the laboratory test was performed for the subject of the Case Report

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Specimen Collection Date: The date that the specimen for the laboratory test was taken from the subject of the Case Report

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Source of Specimen: The physical body location from where the specimen for the lab report was taken from the subject

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Name of Organization Collecting Specimen: Name of organization collecting specimen which may be different from the organization performing the laboratory analysis

HITSP/TP50

See HITSP/C35

General

Coded interoperable content

Diagnosis Date/Time: The date that the subject of the Case Report was diagnosed with Condition above

HITSP/TP50

HL7 Timestamp

General

Coded interoperable content

Previous Event Report Details

HITSP/TP50

Shall be coded as specified in HITSP/C80 Section 2.2. 3.1.1 Problem

General

Coded interoperable content

Hospitalization: If the subject of the case report was hospitalized

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

Recovered: Did the subject recover from the disease?

HITSP/TP50

Boolean datatype Y/N/U

General

Coded interoperable content

All

HITSP/C35, HITSP/C36, HITSP/C37

Constraints as per CDC/CSTE sponsored calls for electronic lab reporting (ELR) are expected to be in the optionality rather than in the vocabulary. No new data elements expected

Pre-condition

Allow for communications with destination of Public Health rather than clinicians

NA

Require Acknowledgement

HITSP/T31, HITSP/TP30 : Need to be sure business actor binding messenger with sender needs to bind with an Xform response back to the human

General

Enable Acknowledgement receipt for submission of case report

NA

Generic Alert to identified providers

This construct cannot be a targeted communication as this would entail risks of disclosure of PHI

General

Support PHI Protection

N/A

HITSP/TP13 Manage Sharing of Documents (Provide and Register)

Data sent to the shared document repository and recorded in the shared registry used for analytical purposes must be Anonymized and Pseuonymized unless otherwise permitted through legal and out-of-band arrangements

Pre-condition

Required to protect the confidentiality of the patients whose personal health information is sent to the Public Health Information System such that the patients can be re-identified as needed to manage public health threats

NA

HITSP/TP13 Manage Sharing of Documents (Shared Document Resource)/

Query Registry Transaction

Stored Query Transaction

Retrieve Document Transaction

Support queries and stored queries for documents which do not require a patient id as a query parameter

General

Asserted to enable public health information retrieval support to enable pull of repository data to the Public Health Information System or to ask public health questions of the data

NA

HITSP/TP13 Manage Sharing of Documents (Query Registry)

HITSP/TP30 should be referenced to record the OID of the authorization policy under which the patient data are disclosed to the authorized public health authority

Post-condition

Asserted to record authorized disclosure in compliance with HIPAA

NA

HITSP/TP13 Manage Sharing of Documents (Provide and Register)

HITSP/TP30 should be referenced to record the OID of the authorization policy under which the patient data are disclosed to the authorized public health authority

Pre-condition

Asserted to record authorized disclosure to public health authority in audit logs

NA

HITSP/T15 Collect and Communicate Security Audit Trail

HITSP/T15 should be constrained to record the OID of the authorization policy under which the patient data are disclosed to the authorized public health authority

Post-condition

Asserted to record authorized disclosure to public health authority in audit logs

NA

HITSP/TP22 Patient Identity Cross-Referencing (Uniquely identify a Patient across enterprises)

Constrain to return single value for pseudonymization steps

General

In order to link pseudo identifiers across entities

XDSDocumentEntry.eventCodeList

HITSP/TP13 Manage Sharing of Documents (Provide and Register)

The metadata element should be required when there is a known condition as required by or of interest to public health authorities, and must contain a value from a controlled vocabulary describing the reportable condition.

Pre-condition

The list of codes aims to represent the main clinical acts documented

XDSDocumentEntry confidentialityCode

HITSP/TP13 Manage Sharing of Documents (Provide and Register)

Extend the usage to signify when patient information in the document and corresponding metadata has been pseudonymized

Attribute: confidentialityCode Optionality: R2

Vocabulary: Need to assign a unique OID and code values to indicate pseudonymization

Pre-condition

This code indicates the level of confidentiality for the corresponding document

XDSDocumentEntry.eventCodeList

R [4]

See 3.2.5.1

Coded in Affinity Domain with Transform (CADT)

XDSDocumentEntry.confidentialityCode

R

See 3.2.5.2

Fixed by Affinity Domain (FAD)

XDSDocumentEntry.patientID and XDSSubmissionSet.patientID

R

See 3.2.5.3

Source document Attribute with Transformation (SAT)

XDSDocumentEntry.sourcePatientID and XDSSubmissionSet.sourcePatientID

R

See 3.2.5.4

Source document Attribute with Transformation (SAT)