suppl_template
Integrating the Healthcare Enterprise
IHE <Domain Name>
Technical Framework Supplement
<Profile Name
(Profile Acronym) >
<For FHIR based profiles, indicate the FHIR release & the FMM levels of the contents. Delete otherwise.>
HL7® FHIR® STU x
Using Resources at FMM Level n-n
Revision x.x – Draft in Preparation for Public Comment (or Trial Implementation)
<The IHE Documentation Specialist will change the title to just “Draft for Public Comment” or “Trial Implementation” upon publication. Leave “as is” until then.>
Date: <Month xx, 20xx>
Author: <Domain> Technical Committee
Email: <[email protected]>
Please verify you have the most recent version of this document. See here for Trial Implementation and Final Text versions and here for Public Comment versions.
<Instructions to authors are encapsulated in angled brackets as “< … >” and denoted with italicized text. These instructions should be deleted entirely prior to publication.>
<Use of capitalization: Please follow standard English grammar rules-only proper nouns and names are upper case. For example, “Modality Actor” is upper case, but “an actor which fulfills the role of a modality” is lower case. Do not use upper case to emphasize a word/topic. Examples:
<Note: Before creating a draft supplement, please review the editing conventions, which include information such as section, table and diagram numbering and how to use Microsoft Word tools, at http://wiki.ihe.net/index.php?title=Writing_Technical_Frameworks_and_Supplements. This guidance is especially useful for first time authors.>
<This supplement template is intended for developing new profiles or making significant changes to profiles, such as adding formal options. Simple changes to existing supplements or profiles should be made using the Change Proposal (CP) process. See the Technical Framework Development section at http://wiki.ihe.net/index.php?title=Process#Technical_Framework_Development for more guidance on supplements vs. CPs.>
<All of the sections in this document are required. Sections may not be deleted. The outline numbering is intended to be consistent across profiles and across domains, so do not adjust the outline numbering. If there is no relevant content for a section, simply state “Section not applicable”, but leave the numbering intact. Sub-sections may be added for clarity.>
<This supplement template includes templates for Volumes 1 (Profiles), 2 (Transactions), 3 (Content Modules), and 4 (National Extensions).>
<Volumes 1, 2, and/or 3 are developed together for Public Comment and Trial Implementation submission. Volume 4, National Extensions, is typically developed at a later point in time, usually at Trial Implementation or later. Templates for all four volumes are included in this document for the sake of completeness. If you are beginning a new profile, you are strongly discouraged from using National Extensions and should instead focus on optional data sets or other alternatives. For more information, see http://wiki.ihe.net/index.php?title=National_Extensions_Process.>
Foreword
This is a supplement to the IHE <Domain Name> Technical Framework <VX.X>. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
<For Public Comment:> This supplement is published on <Month XX, 201x> for Public Comment. Comments are invited and can be submitted at http://www.ihe.net/Public_Comment/#domainname. In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by <Month XX, 201X>.
<For Trial Implementation:> This supplement is published on <Month XX, 201X> for Trial Implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the <Domain Name> Technical Framework. Comments are invited and can be submitted at http://www.ihe.net/Public_Comment/#domainname.
This supplement describes changes to the existing technical framework documents.
“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.
Amend section X.X by the following:
Where the amendment adds text, make the added text bold
underline. Where the amendment removes text, make the removed text
bold strikethrough. When entire new sections are added,
introduce with editor’s instructions to “add new text” or similar, which
for readability are not bolded or underlined.
General information about IHE can be found at www.ihe.net.
Information about the IHE <Domain Name> domain can be found at ihe.net/IHE_Domains.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at http://ihe.net/IHE_Process and http://ihe.net/Profiles.
The current version of the IHE <Domain name>Technical Framework can be found at http://ihe.net/Technical_Frameworks.
<Comments may be submitted on IHE Technical Framework templates any time at http://ihe.net/Templates_Public_Comments. Please enter comments/issues as soon as they are found. Do not wait until a future review cycle is announced.>
CONTENTS
Introduction to this Supplement 8
General Introduction and Shared Appendices 10
Appendix A – Actor Summary Definitions 10
Appendix B – Transaction Summary Definitions 10
<Domain-specific additions> 12
X <Profile Name (Acronym)> Profile 13
X.1 <Profile Acronym> Actors, Transactions, and Content Modules 13
X.1.1 Actor Descriptions and Actor Profile Requirements 16
X.2 <Profile Acronym> Actor Options 17
X.3 <Profile Acronym> Required Actor Groupings 19
X.4 <Profile Acronym> Overview 22
X.4.2.1 Use Case #1: <simple name> 22
X.4.2.1.1 <simple name> Use Case Description 22
X.4.2.1.2 <simple name> Process Flow 23
X.5 <Profile Acronym> Security Considerations 25
X.6 <Profile Acronym> Cross Profile Considerations 25
Appendix A – <Appendix Title> 28
Appendix B – <Appendix Title> 29
3.Y <Transaction Name [Domain Acronym-#]> 30
3.Y.4.1.2 Message Semantics 32
3.Y.4.2.2 Message Semantics 33
3.Y.5 Protocol Requirements 33
3.Y.6 Security Considerations 33
3.Y.6.1 Security Audit Considerations 33
3.Y.6.(z) <Actor> Specific Security Considerations 34
Appendix A – <Appendix Title> 36
Appendix B – <Appendix Title> 37
Volume 2 Namespace Additions 38
5 IHE Namespaces, Concept Domains and Vocabularies 40
5.3 IHE Format Codes and Vocabularies 41
5.3.2 IHEActCode Vocabulary 41
5.3.3 IHERoleCode Vocabulary 42
6.3.1 CDA Document Content Modules 43
6.3.1.D <Content Module Name (Acronym)> Document Content Module 44
6.3.1.D.3 Referenced Standards 44
6.3.1.D.4 Data Element Requirement Mappings to CDA 45
6.3.1.D.5 <Content Module Name (Acronym, if applicable)> Document Content Module Specification 46
6.3.1.D.5.1 <Header Element or Section Name> <Vocabulary Constraint or Condition> 48
6.3.1.D.5.2 <Header Element or Section Name> <Vocabulary Constraint or Condition> 48
6.3.1.D.5.3 <Header Element or Section Name> <Vocabulary Constraint or Condition> 48
6.3.1.D.5.4 <Header Element or Section Name> <Vocabulary Constraint or Condition> 49
6.3.1.D.5.5 <Template Title name> <Vocabulary Constraint or Condition> 51
6.3.1.D.5.6 <Template Title name> <Vocabulary Constraint or Condition> 51
6.3.1.D.6 <Document and Acronym Name> Conformance and Example 52
6.3.2 CDA Header Content Modules 53
6.3.2.H <Header Element Module Name> Header Content Module 53
6.3.2.H.2 <Description Name> <Specification Document OR Vocabulary Constraint> 54
6.3.2.H.3 <Description Name> <Specification Document OR Vocabulary Constraint> 54
6.3.3 CDA Section Content Modules 56
6.3.3.10.S <Section Module Name> - Section Content Module 56
6.3.3.10.S Medical History - Cardiac Section 11329-0 58
6.3.4 CDA Entry Content Modules 60
6.3.4.E <Entry Content Module Name> Entry Content Module 61
6.3.4.E.1 Simple Observation (wall motion) Vocabulary Constraints 62
6.3.4.E.2 Simple Observation (wall morphology) Constraints 62
<e.g.,6.3.4.E Result Observation - Cardiac 63
6.5 <Domain Acronym> Value Sets and Concept Domains 66
6.5.x <Value Set Name/Concept Domain Name> <oid> 66
<e.g.,6.5.1 Drug Classes Used in Cardiac Procedure 1.3.6.1.4.1.19376.1.4.1.5.15 66
6.5.1 UV_CardiacProcedureDrugClasses 67
Appendix A – <Appendix Title> 69
Appendix B – <Appendix Title> 70
Volume 4 – National Extensions 71
4.I National Extensions for <Country Name or IHE Organization> 71
4.I.2 <Profile Name> <(Profile Acronym)> 71
4.I.2.1 <Profile Acronym> Value Set Binding for US Realm Concept Domains 72
4.I.2.1.1 US_CardiacProcedureDrugClasses (1.3.6.1.4.1.19376.1.4.1.5.15) 72
4.I.2.2<Profile Acronym> <Type of Change> 72
4.I+1 National Extensions for <Country Name or IHE Organization> 72
Appendix A – <Appendix Title> 74
Appendix B – <Appendix Title> 75
<If this is a FHIR based profile, include the following box and complete the table within; otherwise, delete it.>
<Provide a brief overview of the volumes/sections of the Technical Framework that get changed/ added by this supplement. Provide 200 words or less describing this supplement.>
Brief Overview Text goes here…..
<List the open issues/questions that need to be addressed. These are particularly useful for highlighting problematic issues and/or specifically soliciting public comments.>
<List the closed issues/questions with their resolutions. These are particularly useful for recording the rationale for closed issues to forestall unnecessary rehashing in the future and/or to make it easier to identify when a closed issue should be re-opened due to new information.>
The IHE Technical Framework General Introduction and Shared Appendices are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate.
Update the following appendices to the General Introduction as indicated below. Note that these are not appendices to Volume 1.
Add the following actors to the IHE Technical Frameworks General Introduction Appendix A:
<Add any actor definitions for new actors defined specifically for this profile. These will be added to the IHE TF General Introduction Appendix A after publication for trial implementation.. Verify that any actors added here are not already contained in the IHE General Introduction Appendix A.>
| Actor Name | Definition |
|---|---|
| <Verb-Noun format (e.g., Store Image, Register Document Set)> | |
Add the following transactions to the IHE Technical Frameworks General Introduction Appendix B:
<Add any transaction definitions for new transactions defined specifically for this profile. These will be added to the IHE TF General Introduction Appendix B after publication for trial implementation. Verify that any transactions added here are not already contained in the IHE General Introduction Appendix B.>
<After determining that a suitable transaction does not already exist, please note that the “verb-noun” construction for transaction names is preferred were possible. For additional guidance, see the IHE wiki at http://wiki.ihe.net/index.php/IHE_Profile_Design_Principles_and_Conventions#Transactions.
| Transaction Name and Number | Definition |
|---|---|
| <Verb-Noun formation (e.g., Send Data [DOM-xx]}> | |
Add the following new glossary terms to the IHE Technical Frameworks General Introduction Appendix D.
<Add any new glossary additions associated with the profile here. Verify that any glossary terms added here are not already contained in the IHE Glossary. Also, please review the Glossary Rules for terms that should/should not be added to the IHE Glossary>
| Glossary Term | Definition |
|---|---|
<Note: The sections following this Introduction will eventually be added as Final Text to Volumes 1 – 4 of the Technical Framework. The material above this note (the Introduction to this Supplement, Open and Closed Issues and General Introduction and Shared Appendices sections) will be deleted when this supplement is moved to Final Text.>
Volume 1 – Profiles
<General copyright licenses and permissions are listed in the IHE Technical Frameworks General Introduction. Add information on any standards referenced in the profile that are not already addressed in the General Introduction (see Section 9.0).>
<Some domains have specific sections, added as subsections to Sections 1 or 2, in their Technical Frameworks. These types of additions are allowed as long as they do not adjust the overall numbering scheme which needs to remain consistent across domains. If there are such additions, they should be included here; if none enter NA.>
Add new Section #
<Reserve a subsequent section number in the current domain Technical Framework Volume 1 (DOM TF-1). Replace the letter “X” with that section heading number. This number should not change when this supplement is added to the Final Text Technical Framework. In this manner, references should be able to be maintained going forward.>
<Provide an end-user friendly overview of what the profile does for them. Keep it brief (a paragraph or two, up to a page). If extensive detail is needed, it should be included in Section X.4- Use Cases.>
<Explicitly state whether this is a Workflow, Transport, or Content Module (or combination) profile. See the IHE Technical Frameworks General Introduction for definitions of these profile types. The IHE Technical Frameworks General Introduction is published at http://ihe.net/Technical_Frameworks.
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at http://ihe.net/Technical_Frameworks/#GenIntro
<Workflow/Transport Instructions>
<If this profile does not define workflow or transport transactions, delete the following text and diagram until the “Content Module Instructions” below.>
<Continue here for workflow and/or transport profiles:>
Figure X.1-1 shows the actors directly involved in the <Profile Acronym> Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a required grouping are shown in conjoined boxes (see Section X.3).
Figure X.1-1: <Profile Acronym> Actor Diagram
Table X.1-1 lists the transactions for each actor directly involved in the <Profile Acronym> Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
<Actors from other profiles represented in dotted boxes, such as Actor C in the example above, should not be listed in Table X.1-1. They are documented in Section X.3.>
Table X.1-1: <Profile Acronym> Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
| Actor A | Transaction 1 | R | <Domain Acronym> TF-2: 3.Y1 | |
| Transaction 2 | R | <Domain Acronym> TF-2: 3.Y2 | ||
| Actor F | Transaction 1 | R | <Domain Acronym> TF-2: 3.Y1 | |
| Transaction 2 | R | <Domain Acronym> TF-2: 3.Y2 | ||
| Actor D | Transaction 1 | R | <Domain Acronym> TF-2: 3.Y1 | |
| Actor E | Transaction 2 | R | <Domain Acronym> TF-2: 3.Y2 | |
| Transaction 3 | O ( See Note 1) | <Domain Acronym> TF-2: 3.Y3 | ||
| Transaction 4 | O ( See Note 1) | <Domain Acronym> TF-2: 3.Y4 | ||
| Actor B | Transaction 3 | R | <Domain Acronym> TF-2: 3.Y3 | |
| Transaction 4 | O ( See Note 2) | <Domain Acronym> TF-2: 3.Y4 |
Note 1: <For example, a note could specify that at least one of the transactions shall be supported by an actor or other variations. For example: Note: Either Transaction Y3 or Transaction Y4 shall be implemented for Actor E. >
Note 2: <For example, could specify that Transaction Y4 is required if Actor B supports XYZ Option, see Section X.3.X.>
<Content Module Instructions:>
<If this profile does not define Content Modules, delete the following diagram, text, and table. <Note that this figure number has to change if this profile describes both transactions and content modules (or there will be two figures entitled X.1-1).>
The recommended Content Creator/Content Consumer diagram is given below. If this is not applicable to this profile, it is up to the author’s discretion to modify/replace. Authors are encouraged to maintain the neutrality of the content modules and incorporate transport by specifying grouping of the actors in the content module with actors from transport transactions.>
Figure X.1-1 shows the actors directly involved in the <Profile Acronym> Profile and the direction that the content is exchanged.
A product implementation using this profile may group actors from this profile with actors from a workflow or transport profile to be functional. The grouping of the content module described in this profile to specific actors is described in more detail in Required Actor Groupings <DOM> TF-1: X.6 or in Cross Profile Considerations <DOM> TF-1: X.6.
Figure X.1-1: <Profile Acronym> Actor Diagram
Table X.1-1 lists the content module(s) defined in the <Profile Acronym> Profile. To claim support with this profile, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”).
<Note that this table number has to change if this profile describes both transactions and content modules (or there will be two tables entitled X.1-1).>
<Note that the abbreviation in the column “Reference” the letter “D” will be incremented for every content module document defined in this profile (e.g., For example D1, D2).>
<In general, one supplement template will only contain one required content module document, but the example here shows multiple with one optional, just for illustration purposes.>
Table X.1-1 <Profile Acronym> – Actors and Content Modules
| Actors | Content Modules | Optionality | Reference |
|---|---|---|---|
| Content Creator | Content Module 1 Name and Template ID | R | <Domain Acronym> TF-3: 6.3.1.D |
| Content Module 2 Name and Template ID | O See Note 1 | <Domain Acronym> TF-3: 6.3.1.D | |
| Content Consumer | Content Module 1 Name and Template ID | O See Note 1 | <Domain Acronym> TF-3: 6.3.1.D |
| Content Module 2 Name and Template ID | R | <Domain Acronym> TF-3: 6.3.1.D |
Note 1: <For example, a note could describe that one of two possible transactions could be supported by an actor or other variations.
For example - Note 1: Either Content Module 2 or Content Module 3 shall be implemented for the Content Creator or Content Consumer.
For example- Note 1: At least one of Content Module 2, Content Module 3, or Content Module 4 shall be implemented for Content Consumer.>
<For Workflow Profile:>
Most requirements are documented in <DOM> TF-2 Transactions. This section documents any additional requirements on profile’s actors.
<Enter here “No additional requirements needed.”, if none.>
<For Content Module Profile:>
Most requirements are documented in <DOM> TF-3 T Content Modules. This section documents any additional requirements on profile’s actors.
<Enter here “No additional requirements needed.”, if none.>
<Do not repeat the definitions of the actors that are maintained in the TF General Introduction Appendix A (Actors). Include text in this section to describe the actor in the context of this profile.>
<This section is empty unless there is a need for specific descriptions or requirements. Actors without additional requirements or elaborate descriptions need not be listed here. >
<If this is a Workflow Profile the sequence of transactions often require data from an inbound transaction to be carried forward to subsequent transactions . Individual transactions, which are designed to be reusable, do not define this data mapping and it must be documented here. If this is a long technical mapping, consider including this material in an appendix to Volume 2. For an example, see Radiology Scheduled Workflow RAD TF-2: Appendix A.>
<This section may also define system behavior. For example, in the PIX Profile, an ADT message is first received by the PIX Manager. The PIX Manager should then use this data to respond to subsequent queries. Although this may be implied, it should be explicitly documented in this section.>
<Note that for actors in, bindings to other transport or workflow modules are referenced in the Required Actor Groupings section below. >
<If the summary description of the actor in Appendix A is insufficient to understand its role in this profile, elaborate here.>
<Requirements on actors are predominantly contained inside transactions in Volume 2. The main requirement on actors contained in Volume 1 is to support the transactions identified in Table X.1-1 and the content modules identified in Table Z. Requirements that do not fit in those locations may be placed here.>
<Modify the following table, listing all the actors in this profile, the options available for each, and references to sections that state requirements for compliance to each option. For actors with no options, state “No options defined” in column 2.>
<Note: Options are directly carried over to the integration statements which are published by vendors for review by buyers. Too many options can be confusing for readers, so try to minimize options for actors and only use if necessary.>
<Several options for Content Consumers are defined in PCC TF-2: 3.1.1-3.1.4. It is recommended that these options are reused, if applicable, but read the option definitions thoroughly to be certain that they apply. If they do not apply in their entirety, you will need to define a corresponding option in this profile. The recommended naming convention for a similar, but different, option is, for example, “View Option - <profile acronym>, etc., “View Option – CIRC”.>
Options that may be selected for each actor in this profile, if any, are listed in the Table X.2-1. Dependencies between options, when applicable, are specified in notes.
Table X.2-1: <Profile Name> – Actors and Options
| Actor | Option Name | Reference |
|---|---|---|
| Actor A | <Option 1 name> Option | <reference to applicable X.2.x sub-section below table> |
| Actor B | No options defined | -- |
| Actor C | <Option 2 name> Option | <reference to applicable X.2.x sub-section below table> |
| Actor D |
<Option 1 name> Option <Note that it is OK to have the same option apply to more than one actor. The option adds specific functionality in a profile. The actors will have different requirements identified in Section X.2.X to enable that functionality.> |
<reference to applicable sub-section below table, e.g., Section X.2.1> |
| Actor E, <e.g., Content Consume> (See Note) | View Option | PCC TF-2: 3.1.1 |
| Document Import Option | PCC TF-2: 3.1.2 | |
| Section Import Option | PCC TF-2: 3.1.3 | |
| Discrete Data Import Option | PCC TF-2: 3.1.4 |
Note: <Conditional or required options must be described in this short note, for longer notes use Section X.2.1.>
<Add a sub-section below for every new option defined in Table X.2-1.>
<First, include a sentence with a high-level description of the option. What capability does this option enable in the profile? Then, enumerate the specific requirements for the actor(s) that support this option.>
An <actor name> that supports this option shall <Describe the requirements associated with this option.>
<Sometimes an option requires that an optional transaction becomes mandatory. In that case, list the transaction as Optional in Table X.1-1, but indicate in this section that it is required, e.g., Transaction [DOM-Y4 is required for Actor-B that supports this option.”>
<Sometimes an option requires that the actor be grouped with an actor in another profile. In that case, describe that here and also refer to the Required Grouping table in the next section. E.g., “An Actor-A that supports the Really Secure Option shall be grouped with an Secure Node or Secure Application in the ATNA Profile. See Table X.3-1.”>
<Repeat this section (and increment numbering) as needed for additional options.>
<Describe any requirements for actors in this profile to be grouped with other actors.>
<Note that this section effectively combines sections from previous versions of the template: “Profile Dependencies” section (formerly Vol. 1, Section 2.1) and the “Groupings” section.>
<This section specifies all REQUIRED Actor Groupings (although “required” sometimes allows for a selection of one of several). To SUGGEST other profile groupings or helpful references for other profiles to consider, use Section X.6 Cross Profile Considerations. Use Section X.5 for security profile recommendations.>
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2) (Column 3 in alternative 2).
If this is a content profile, and actors from this profile are grouped with actors from a workflow or transport profile, the Reference column references any specifications for mapping data from the content module into data elements from the workflow or transport transactions.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation.
Section X.5 describes some optional groupings that may be of interest for security considerations and Section X.6 describes some optional groupings in other related profiles.
<Two alternatives for Table X.3-1 are presented below.
-
If there are no required groupings for any actor in this profile, use alternative 1 as a template.
-
If an actor in this profile (with no option), has a required grouping, use alternative 1.
-
If any required grouping is associated with an actor/option combination in this profile, use alternative 2.>
<alternative 1> Table X.3-1: <Profile Name> - Required Actor Groupings
<All actors from this profile should be listed in Column 1, even if none of the actors has a required groupings. If no required grouping exists, “None” should be indicated in Column 2. If an actor in a content profile is required to be grouped with an actor in a transport or workflow profile, it will be listed with at least one required grouping. Do not use “XD*” as an actor name.>
<In some cases, required groupings are defined as at least one of an enumerated set of possible actors; to designate this, create a row for each potential actor grouping and merge column one to form a single cell containing the profile actor which should be grouped with at least one of the actors in the spanned rows. In addition, a note should be included to explain the enumerated set. See example below showing Document Consumer needing to be grouped with at least one of XDS.b Document Consumer, XDR Document Recipient or XDM Portable Media Importer>
<The author should pay special consideration to security profiles in this grouping section. Consideration should be given to Consistent Time (CT) Client, ATNA Secure Node or Secure Application, as well as other profiles. For the sake of clarity and completeness, even if this table begins to become long, a line should be added for each actor for each of the required grouping for security. Also see the ITI document titled ‘Cookbook: Preparing the IHE Profile Security Section’ at http://ihe.net/Technical_Frameworks/#IT for a list of suggested IT and security groupings.>
| <this Profile Acronym> Actor | Actor(s) to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Actor A |
<external Domain Acronym or blank> <profile acronym>/<Actor> <e.g., ITI CT / Time Client> |
<TF Reference; typically from Vol 1> <e.g., ITI-TF-1: 7.1> |
-- |
| Actor B | None | -- | -- |
|
Actor C <In this example, Actor C shall be grouped with all three actors listed in column 2> |
<external Domain Acronym or blank> <profile acronym>/<Actor> |
-- | See Note 1 |
| <external Domain Acronym or blank> <profile acronym>/<Actor> | -- | See Note 1 | |
|
<external Domain Acronym or blank> <profile acronym>/<Actor> |
-- | See Note 1 | |
|
Actor D (See note 1) <In this example, the note is used to indicate that the Actor D shall be grouped with one or more of the two actors of the two actors in column 2.> |
<external Domain Acronym or blank> <profile acronym>/<Actor> |
-- | See Note 1 |
|
<external Domain Acronym or blank> <profile acronym>/<Actor> |
-- | See Note 1 | |
|
Actor E <In rare cases, the actor to be grouped with must implement an option. An example is in column 2.) |
<external Domain Acronym or blank> <profile acronym> <Actor> <e.g., ITI RFD Form Filler with the Archive Form Option> |
<TF Reference to the Option definition; typically from Vol 1> <(e.g., ITI TF-1: 17.3.11)> |
|
| <e.g., Content Consumer (See Note 1) | ITI XDS.b / Document Consumer | ITI TF-1: 10.1 | PCC TF-2:4.1 (See Note 2)> |
| ITI XDR / Document Recipient | ITI TF-1: 15.1 | PCC TF-2:4.1 (See Note 2)> | |
| ITI XDM / Portable Media Importer | ITI TF-1: 16.1 | PCC TF-2:4.1 (See Note 2)> | |
| <e.g., Content Consumer | ITI CT / Time Client | ITI TF-1: 7.1> | -- |
Note 1: <This is a short note. It may be used to describe situations where an actor from this profile may be grouped with one of several other profiles/actors.
Note 2: <A note could also be used to explain why the grouping is required, if that is still not clear from the text above.>
<alternative 2> Table X.3-1: <this Profile Acronym> Profile
- Required Actor Groupings
<All actors from this profile should be listed in Column 1. If no required grouping exists, “None” should be indicated in Column 3. >
<Guidance on using the “Grouping Condition” column:
-
If an actor has no required grouping, Column 2 should contain “--“. See Actor A below.
-
If an actor has a required grouping that is not associated with a profile option (i.e., it has no condition), column 2 should contain “Required”. See Actor B below.
-
Sometimes an option requires that an actor in this profile be grouped with an actor in another profile. That condition is specified in Column 2. See Actor C below.>
| <this Profile Acronym> Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
| Actor A | -- | None | -- |
| Actor B | Required |
<external Domain Acronym or blank> <profile acronym>/<Actor> <e.g., ITI CT / Time Client> |
<TF Reference; typically from Vol 1> <(e.g., ITI TF-1: 7.1)> |
| Actor C | With the <Option name in this profile> Option | <external Domain Acronym or blank> <profile acronym>/<Actor> | Where the Option is defined in this profile <Section x.3 z> |
|
Actor D <if an actor has both required and conditional groupings, list the Required grouping first> |
Required | <external Domain Acronym or blank> <profile acronym>/<Actor> | <TF Reference; typically from Vol 1> |
| If the <Option name in this profile> Option is supported. | <external Domain Acronym or blank> <profile acronym>/<Actor> | <TF Reference; typically from Vol 1> | |
| If the <other Option name in this profile> Option is supported. | <external Domain Acronym or blank> <profile acronym>/<Actor> | <TF Reference; typically from Vol 1> | |
|
Actor E (In rare cases, the actor to be grouped with must implement an option, an example is in column 3) |
Required |
<external Domain Acronym or blank> <profile acronym>/<Actor> with the <option name> <e.g. ITI RFD Form Filler with the Archive Form Option> |
<TF Reference to the Option definition; typically from Vol 1> <(eg ITI TF-1:17.3.11)> |
<Volume 2 documents each transaction/content module in isolation. This section shows how the transactions/content modules of the profile are combined to address the use cases.>
<Use cases are informative, not normative, and “SHALL” language is not allowed in use cases.>
<If needed, this section provides an overview of the concepts that provide necessary background for understanding the profile. If not needed, state “Not applicable.” For an example of why/how this section may be needed, please see ITI Cross Enterprise Workflow (XDW).>
<It may be useful in this section but is not necessary, to provide a short list of the use cases described below and explain why they are different.>
<One or two sentence simple description of this particular use case.>
<Note that Section X.4.2.1 repeats in its entirety for additional use cases (replicate as Section X.4.2.2, X.4.2.3, etc.).>
<Describe the key use cases addressed by the profile. Limit to a maximum of one page of text or consider an appendix.>
<Diagram and describe the process flow(s) covered by this profile in order to satisfy the use cases. Demonstrate how the profile transactions are combined/sequenced. To provide context and demonstrate how the profile interacts with other profiles, feel free to include transactions and events that are “external” to this profile (using appropriate notation.)
The set of process flows will typically be exemplary, not exhaustive (i.e., it will address all the use cases, but will not show all possible combinations of actors, or all possible sequencing of transactions).
If there are detailed behavioral rules that apply to a specific process flow or multiple process flows, an appendix may be added as needed.>
<The roles at the top of the swimlane diagram should correspond to actor names, include the profile acronym:actor name if referencing an actor from a different profile.>
<Modify the following “Swimlane Diagram”.>
Figure X.4.2.2-1: Basic Process Flow in <Profile Acronym> Profile
<If process flow “swimlane” diagrams require additional explanation to clarify conditional flows, or flow variations need to be described where alternate systems may be playing different actor roles, document those conditional flows here.>
<Delete the material below if this is a workflow or transport profile. Delete the material above if this profile is a content module only profile.>
Pre-conditions:
<Very briefly (typically one sentence) describe the conditions or timing when this content module would be used.>
Main Flow:
<Typically in an enumerated list, describe the clinical workflow when, where, and how this content module would be used.>
Post-conditions:
<Very briefly (typically one sentence) describe the state of the clinical scenario after this content module has been created including examples of potential next steps.>
<Describe profile-specific security considerations. This should include the outcomes of a risk assessment. This likely will include profile groupings, and residual risks that need to be assigned to the product design, system administration, or policy. See the ITI document titled ‘Cookbook: Preparing the IHE Profile Security Section’ at http://ihe.net/Technical_Frameworks/#IT for suggestions on risk assessment, risk mitigation, and IT and security profiles.>
<If this is not a content module, delete the sentence below. If this is a content module profile, you may want to expound upon the security considerations provided by grouped actors.>
The security considerations for a content module are dependent upon the security provisions defined by the grouped actor(s).
<This section is informative, not normative. It is intended to put this profile in context with other profiles. Any required groupings should have already been described above. Brief descriptions can go directly into this section; lengthy descriptions should go into an appendix. Examples of this material include ITI Cross Community Access (XCA) Grouping Rules (Section 18.2.3), the Radiology associated profiles listed at wiki.ihe.net, or ITI Volume 1 Appendix E “Cross Profile Considerations”, and the “See Also” sections Radiology Profile descriptions on the wiki such as http://wiki.ihe.net/index.php/Scheduled_Workflow#See_Also. If this section is left blank, add “Not applicable.” >
<Consider using a format such as the following:>
<other profile acronym> - <other profile name>
A <other profile actor name> in <other profile name> might be grouped with a <this profile actor name> to <describe benefit/what is accomplished by grouping>.
Appendices
<Add appendices to Volume 1 for this profile here. Examples of an appendix include HITSP mapping to IHE Use Cases or long use case definitions.>
<If there are no Volume 1 appendices, enter “Not applicable” and delete the Appendix A and Appendix B placeholder sections.>
<Volume 1 appendices are informational only. No “SHALL” language is allowed in a Volume 1 Appendix.>
Appendix A text.
Appendix A.1 text.
Appendix A.1.1 text.
Appendix B text.
Appendix B.1 text.
Appendix B.1.1 text.
Volume 2 – Transactions
Add Section 3.Y
<The “Y” in the heading should be the same as the # in the [Domain Acronym -#] title>
This transaction is used to <…describe what is accomplished by using the transaction. Remember that by keeping transactions general/abstract, they can be re-used in a variety of profiles>
<Alternative 1> Table 3.Y.2-1: Actor Roles
| Actor: | <Official actor name; list every actor in this transaction.> |
|---|---|
| Role: | <Very brief, one phrase, description of the role that this actor plays in this transaction.> |
| Actor: | |
| Role: | |
| Actor: | |
| Role: |
<The assignment and use of role names in transaction specifications has proved to be very effective/efficient in Radiology, especially when existing transactions are re-used by additional actors. Following is an alternative example of the Role section. Delete whichever form of the role section you choose not to use.>
The roles in this transaction are defined in the following table and may be played by the actors shown here:
<Alternative 2>Table 3.Y.2-1 Actor Roles
| Role: | <Role Name:><Only unique within this transaction. Typically one word. The Role Name is analogous to SCU or SCP in DICOM Services.> |
|---|---|
| Actor(s): |
The following actors may play the role of <Role Name>: <Actor Name>: <optionally, the situation where the actor would play this role if needed for clarity.>” |
| Role: |
<e.g., Requestor: Submits the relevant details and requests the creation of a new workitem.> |
| Actor(s): |
<e.g., The following actors may play the role of Requestor: Workitem Creator: when requesting workitems Workitem Performer: when performing unscheduled workitems> |
| Role: |
<e.g., Manager: Creates and manages a Unified Procedure Step instance for the requested workitem.> |
| Actor(s): |
<e.g., The following actors may play the role of Manager: Workitem Manager: when receiving a new workitem for its worklist.> |
Transaction text specifies behavior for each role. The behavior of specific actors may also be specified when it goes beyond that of the general role.
-
<e.g., HL7 2.3.1 Chapters 2, 3>
-
<e.g., DICOM 2008 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD>
-
<e.g., applicable sub-sections in ITI TF-2x: Appendix Z on HL7 FHIR>
<The interaction diagram shows the detailed standards-based message exchange that makes up the IHE transaction.>
<One or two sentence summary of what Message 1 accomplishes typically relating the message to the relevant standard. Avoid shall language in this upper level section. Do not duplicate the triggers, encoding, semantics, standards used, or expected actions. Those belong in the following sections.>
<Explicitly state if the multiplicity of an actor may be greater than one; i.e., if an actor (whether it is a client or server) can expect this message from a single source or multiple sources.>
<Description of the real world events that cause the sender (Actor A) to send Message 1 (e.g., an operator or an automated function determines that a new workitem is needed).>
<Detailed description of the meaning, structure and contents of the message, including any IHE specific clarifications of the message format, attributes, etc.>
<Start by describing the standard underlying the message and how the participating actors are mapped (e.g., “This message is a DICOM C-FIND Request. Actor A is the SCU. Actor D is the SCP.”).>
<Continue profiling the message by providing guidance or constraints on how the message parameters are populated, how the payload is encoded, how the message is structured and what the contents mean. These message semantics should both help the sender to construct the message and the receiver to interpret the message.>
<Description of the actions expected to be taken as a result of sending or receiving this message.>
<Describe what the receiver is expected/required to do upon receiving this message. >
<Avoid re-iterating the transaction sequencing specified in the Profile Process Flows as expected actions internal to the transaction. Doing so prevents this transaction being re-used in other contexts.>
<Explicitly define any expected action based on the multiplicity of an actor(s), if applicable.>
<One or two sentence summary of what Message 2 accomplishes typically relating the message to the relevant standard. Avoid shall language in this upper level section. Do not duplicate the triggers, encoding, semantics, standards used, or expected actions. Those belong in the following sections.>
<Explicitly state if the multiplicity of an actor may be greater than one; i.e., if an actor (whether it is a client or server) can expect this message from a single source or multiple sources.>
<Repeat this section as necessary based on the number of messages in the interaction diagram.>
<Description of the real world events that cause the sender (Actor A) to send Message 1(e.g., an operator or an automated function determines that a new workitem is needed).>
<Detailed description of the meaning, structure and contents of the message, including any IHE specific clarifications of the message format, attributes, etc.>
<Start by describing the standard underlying the message and how the participating actors are mapped (e.g., “This message is a DICOM C-FIND Request. Actor A is the SCU. Actor D is the SCP.”).>
<Continue profiling the message by providing guidance or constraints on how the message parameters are populated, how the payload is encoded, how the message is structured and what the contents mean. These message semantics should both help the sender to construct the message and the receiver to interpret the message.>
<Description of the actions expected to be taken as a result of sending or receiving this message.>
<Describe what the receiver is expected/required to do upon receiving this message. >
<Avoid re-iterating the transaction sequencing specified in the Profile Process Flows as expected actions internal to the transaction. Doing so prevents this transaction being re-used in other contexts.>
<Explicitly define any expected action based on the multiplicity of an actor(s), if applicable.>
<In this section, the selected protocol bindings of the transactions are explained in detail (like SOAP or HTTP bindings).For an example, see the QRPH DEX Profile or ITI TF-2b:3.34.5, 3.35.5. Indicate NA if not used.>
<Description of the transaction specific security consideration; such as use of security profiles.>
<This section should identify any specific ATNA security audit event that is associated with this transaction and requirements on the encoding of that audit event. >
<This section should specify any specific security considerations on an actor-by-actor basis.>
Appendices
<Detailed cross transaction relationships or mapping details are described in an appendix in Volume 2x. Volume 2 appendices may be informational or normative. Immediately after the title of a Volume 2 appendix, provide a very explicit statement defining whether this new appendix is informative or normative.
If there are no Volume 2 appendices, enter “Not applicable” and delete the Appendix A and Appendix B placeholder sections.>
Appendix A text.
Appendix A.1 text.
Appendix A.1.1 text.
Appendix B text.
Appendix B.1 text.
Appendix B.1.1 text.
<For Public Comment, please explicitly identify all new OIDs, UIDs, URNs, etc., defined specifically for this profile. These items should be collected from the sections above, and listed here as additions to the applicable domain OID Registry. This section will be deleted prior to inclusion into the Technical Framework as Final Text, but should be present for publication of Public Comment and Trial Implementation.>
At Trial Implementation publication, the domain technical committee must ensure that all new OIDs, UIDs, URNs, etc., defined specifically for this profile have been recorded in their OID Registry. This section will be deleted prior to inclusion into the Technical Framework Volumes as Final Text but should be present for publication of Public Comment and Trial Implementation.>
The <domain name> registry of OIDs is located at <link to your OID registry(ies)
Additions to the <Domain Name> OID Registry are:
Volume 3 – Content Modules
<The current version of the supplement template only addresses HL7 v3 CDA Content Modules. All CDA Content Modules will go in Section 6 of Volume 3 of each domain’s Technical Framework document. In the future, this supplement template may have additional sections for DICOM Content Modules (section 7 of Volume 3) and other types of Content Modules (section 8, etc., of Volume 3).
<Please note that prior to the release of the new template set, some domains may have defined CDA Content Modules in Volume 2 (e.g., PCC); however, going forward CDA Content Modules will be defined in Volume 3.>
Add to Section 5 IHE Namespaces, Concept Domains and Vocabularies
<For Public Comment publication, please explicitly identify all new OIDs, UIDs, URNs, etc., defined specifically for this profile. These items should be collected from the sections within this supplement and listed here as additions to the applicable domain OID Registry. The tables within this section will be deleted prior to inclusion into the Technical Framework as Final Text, but should be present for publication for Public Comment.>
<For Trial Implementation publication, the domain technical committee must ensure that all new OIDs, UIDs, URNs, etc., defined specifically for this profile (and listed here for public comment publication have now been recorded in their OID Registry. The tables within this section will be deleted prior to inclusion into the Technical Framework Volumes as Final Text but should be present for publication for Trial Implementation.>
<Ensure the domain’s registry of OIDs is linked to from the following wiki page. It may be another wiki page, a document on the ftp site, etc.>
The <domain name> registry of OIDs is located at http://wiki.ihe.net/index.php/OID_Registration#IHE_Domain_Namespaces
Additions to the <Domain Name> OID Registry are:
| codeSystem | codeSystemName | Description |
|---|---|---|
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
<Concept Domains are named categories of things that are used when it isn’t possible to bind to a specific set of codes. There are a number of reasons you might not be able to define and bind to a specific set of codes, one of the most common being that the codes set needs to vary depending on locale or context.>
For a listing of the <Domain Acronym> Concept Domains see <enter location of the domains Concept Domains or NA if none>
| conceptDomain | conceptDomainName | Description |
|---|---|---|
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
| <oid or uid> | <code system name> | <short description or pointer to more detailed description> |
List in the table below any new format codes to be added to the IHE Format Codes wiki page at http://wiki.ihe.net/index.php/IHE_Format_Codes. For public comment, the additions must be listed in the table below. The domain technical committee must ensure any new codes are also added to the wiki page prior to publication for trial implementation.
| Profile | Format Code | Media Type | Template ID |
|---|---|---|---|
| <Profile name (profile acronym)> | <urn:ihe: > | <oids> | |
List in the table below, any new additions to the IHEActCode Vocabulary wiki page at http://wiki.ihe.net/index.php/IHEActCode_Vocabulary. For public comment, the additions must be listed in the table below. The domain technical committee must ensure any new codes are also added to the wiki page prior to publication for trial implementation.
| Code | Description |
|---|---|
| <Code name> | <short one sentence description or reference to longer description (not preferred)> |
| <Code name> | <short one sentence description or reference to longer description (not preferred)> |
| <Code name> | <short one sentence description or reference to longer description (not preferred)> |
List in the table below any new additions to the IHERoleCode Vocabulary wiki page at http://wiki.ihe.net/index.php/IHERoleCode_Vocabulary. For public comment, the additions must be listed in the table below. The domain technical committee must ensure any new codes are also added to the wiki page prior to publication for trial implementation.
| Code | Description |
|---|---|
| <name of role> | <Short, one sentence description of role or reference to more info.> |
| <name of role> | <Short, one sentence description of role or reference to more info.> |
| <name of role> | <Short, one sentence description of role or reference to more info.> |
<Authors’ notes: This section of the supplement template is only for HL7 v3 CDA Content Module definitions. Please delete the entire section 6.3.1 if the Content Module is based on DICOM or another standard.
Please note that the template for DICOM or other types of content modules (other than CDA) has not yet been defined, although DICOM modules will eventually go into Volume 3 Section 7; yet another type of content module will go into Volume 3 Section 8, etc.>
<Authors’ instructions: The understanding of content module grouping, options, and bindings are critical to CDA content modules. It is strongly recommended that the author review the IHE Technical Frameworks General Introduction section 10.3 and the Patient Care Coordination (PCC) Technical Framework Volume 2 sections 3 and 4 (PCC TF-2:3 and 4) prior to continuing. A critical understanding of CDA definitions for cardinality, optionality, coded terminology values, and CDA content module structure, as well as IHE CDA formatting conventions is also necessary. It is strongly recommended that the author is also conversant with the IHE Technical Frameworks General Introduction Appendix E “Conventions”.>
<This CDA Content Module template is divided into four parts:
D – Document –“D” will be replaced with a sub-section number when added to the Technical Framework
H – Header - “H” will be replaced with a sub-section number when added to the Technical Framework
S – Section - “S” will be replaced with a sub-section number when added to the Technical Framework
E – Entry - “E” will be replaced with a sub-section number when added to the Technical Framework
It is expected that the author will replicate each of these four parts as necessary within a supplement.>
All examples should be deleted after the example has been read and understood.>
Add to section 6.3.1.D Document Content Modules
<Authors’ Note: Replicate section 6.3.1.D for every CDA Document defined in this profile. Number as 6.3.1.D1, 6.3.1.D2, etc.>
The XDSDocumentEntry format code for this content is urn:ihe:dom:name:year
<where dom is the domain abbreviation; name is an identifying profile, transaction, etc. name; and year is the year the profile is expected to reach trial implementation. For example, urn:ihe:card:imaging:2011>
<The following text is common, so it is left here for consistency. If it is not relevant, then change the text to the accurate information, but retain the formatting convention. Be sure to include all parent templates.>
<e.g., This document is a specialization of the IHE PCC Medical Document template (OID = 1.3.6.1.4.1.19376.1.5.3.1.1.1).>
<e.g., Note: The Medical Document includes requirements for various header elements; name, addr and telecom elements for identified persons and organizations; and basic participations record target, author, and legal authenticator.>
<e.g., This document is a specialization of the HL7 Procedure Note template (OID = 2.16.840.1.113883.10.20.18.1).>
<e.g., Note: This document is not a specialization of the HL7 Basic Diagnostic Imaging Report template due to conflicts with two Procedure Note requirements (format of serviceEvent/effectiveTime, and title on DICOM Catalogue section). When and if these are resolved, an instance may also comply to the Diagnostic Imaging Report.>
<Identify all standards referenced by this content module.>
All standards which are reference in this document are listed below with their common abbreviation, full title, and link to the standard.
Table 6.3.1.D.3-1: <Document Name> - Referenced Standards
| Abbreviation | Title | URL |
|---|---|---|
| <abbreviated name of standard> | <full name of standard> | <link to standard> |
| <abbreviated name of standard> | <full name of standard> | <link to standard> |
| <e.g., CDA-PN> | <e.g., HL7 Implementation Guide for CDA Release 2: Procedure Note (Universal Realm) (DSTU)> | <e.g., http://www.hl7.org/documentcenter/public/standards/dstu/CDAR2\_IG\_PROCNOTE\_DSTU\_R1\_2010JUL.zip> |
This section identifies the mapping of data between referenced standards into the CDA implementation guide.
<Any required data mappings should be listed in this section (mark NA if not needed). Delete SAMPLE table before publishing.>
<To complete Table 6.3.1.D.4-1, the author should add the referenced standards abbreviations in the first row/title bar. Add or delete columns and sub-rows as necessary. If this table is more than 8 to 10 rows long, consider putting this table into an appendix of this supplement. A brief sample follows.>
SAMPLE
| ACC Key Data Element (KDECI) | CDA-DIR |
|---|---|
| DICOM Object Catalog (5) | |
|
Administrative Facility (5) Data Source (1) Priority (1) Accreditation (2) Insurance (1) |
CDA Header General (10) Document (19) Participants (20) Order (1) Service Event (12) Encounter (10) |
| Study Referral Data (2) | Request |
|
History and Risk Factors Vital Signs (4) Labs (2) Problems (14) Chest Pain (5) Family History (1) Tobacco Use (1) Risk Estimates (6) |
History |
>
Table 6.3.1.D.4-1: < Document Name Acronym> - Data Element Requirement Mappings to CDA
| Clinical Data Element <source> | < this document acronym> |
|---|---|
<Very important note: From this point forward, the author may select one of two formats to represent the same data. The first format is a tabular format as was implemented in the Cardiology CIRC profile. The advantages to this format include that large amounts of data may be represented more concisely and that it is sometimes visually easier to determine if any information is missing. The second format is more similar to the current Consolidated CDA (C-CDA format). This format may be more verbose but may also be more recognizable to implementers familiar with other HL7 CDA Implementation Guides and may be easier for implementers to design and test with discrete conformance assertions.
The format that you select must be consistent through this supplement (do not mix and match formats). The format changes are identified by ###Begin Tabular format ###End CDA Tabular format and ###Begin Discrete Conformance format ###End Discrete Conformance format. Delete all references to the format which was not selected between the hash marks. Also, a domain may decide on a single format for all new supplements within that domain.>
This section specifies the header, section, and entry content modules which comprise the <Content Module Name (Acronym)> Document Content Module, using the Template ID as the key identifier.
Sections that are used according to the definitions in other specifications are identified with the relevant specification document. Additional constraints on vocabulary value sets, not specifically constrained within the section template, are also identified.
<Authors’ note: A critical understanding of CDA definitions for cardinality, optionality, coded terminology values, and CDA content module structure, as well as IHE CDA formatting conventions is necessary. It is strongly recommended that the author is also conversant with the IHE Technical Frameworks General Introduction Appendix E “Conventions”. >
###Begin Tabular format - Document
Table 6.3.1.D.5-1 <Content Module Name (Acronym)> Document Content Module Specification
| Template Name | <Template Name (Acronym, if applicable)> | ||||
| Template ID | <oid/uid> | ||||
| Parent Template |
<Parent Template Name oid/uid [Domain Reference]> <Parent Template Name oid/uid [Domain Reference]> <delete 2nd/additional parent template if not applicable> <Enter NA if none> |
||||
| General Description | <short textual description> | ||||
| Document Code | <MAY or SHALL> be < code/oid/uid, Code System, “Value Set name”> | ||||
| Opt and Card | Condition | Header Element or Section Name | Template ID | Specification Document | Vocabulary Constraint |
| Header Elements | |||||
| x [?..?] | <Header Element name> | <oid> | <reference to section of TF or supplement document for details> | <reference to section of TF or supplement document for explanation, if applicable> | |
| <e.g., R [0..1] | Order | 1.3.6.1.4.1.19376.1.4.1.3.2 | CARD TF-3 6.3.2.H> | ||
| <e.g., M [1..1] | Patient Demographics | 1.3.6.1.4.1.19376.1.4.1.3.3 | CARD TF-3 6.3.2.H | CARD TF-3 6.3.1.D.5.1> | |
| Sections | |||||
| x [?..?] | <Section name> | <oid> | <reference to section of TF or supplement document for details> | <reference to section of TF or supplement document for explanation, if applicable> | |
| <e.g., M [1..1] | Medications | 1.3.6.1.4.1.19376.1.5.3.1.3.19 | PCC TF-2 | CARD TF-3 6.3.1.D.5.2> | |
| <e.g., R [1..1] | Coded Social History | 1.3.6.1.4.1.19376.1.5.3.1.3.16.1 | CARD TF-3 6.3.3.S | CARD TF-3 6.3.1.D.5.3> | |
| <e.g., O [0..1] | Physical Examination | 2.16.840.1.113883.10.20.2.10 | CDA-PN> | ||
| <e.g., C [1..1] | CARD TF-3 6.3.1.D.5.4 | DICOM Object Catalog | 1.3.6.1.4.1.19376.1.4.1.2.15 | CDA-PN> |
<For each (1:1 correspondence) Vocabulary Constraint or Condition listed in the table above, create an additional section/reference below. Add the Header Element or Section Name and then select either “Vocabulary Constraint” or “Condition” and delete the other word.>
<Note that every Conditional element MUST have an explanatory paragraph referenced below.>
<It is required to use SHALL, SHOULD, or MAY in each definition as defined in Appendix E of the Technical Frameworks General Introduction.>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., The value for serviceEvent / code SHOULD be drawn from value set 1.3.6.1.4.1.19376.1.4.1.5.2 Cardiac Imaging Procedures.
OR
The value for serviceEvent/code SHOULD be drawn from the value set bound to the concept domain UV_CardiacImagingProcedures.>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., Within the Medications section the Content Creator SHALL be able to create a Medications entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.7 [PCC TF-2]) for each of the cardiac relevant medications identified in Value Set 1.3.6.1.4.1.19376.1.4.1.5.14 Cardiac Drug Classes, encoding the value in substanceAdministration/consumable/ManufacturedProduct/Material/code.
OR
Within the Medications section the Content Creator SHALL be able to create a Medications entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.7 [PCC TF-2]) for each of the cardiac relevant medications identified in the value set bound to the concept domain UV_CardiacRelevantMedications, encoding the value in substanceAdministration/consumable/ManufacturedProduct/Material/code.
>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., Within the Allergies and Other Adverse Reactions section the Content Creator SHALL be able to create an Allergies and Intolerances Concern Entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.5.3 [PCC TF-2]) for each of the cardiac imaging agent classes identified in Value Set 1.3.6.1.4.1.19376.1.4.1.5.10 Contrast Agents Classes for Adverse Reactions, encoding the value in observation/participant/participantRole/playingEntity/code.
OR
Within the Allergies and Other Adverse Reactions section the Content Creator SHALL be able to create an Allergies and Intolerances Concern Entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.5.3 [PCC TF-2]) for each of the cardiac imaging agent classes identified in value set bound to the concept domain UV ContrastAgentsClasses, encoding the value in observation/participant/participantRole/playingEntity/code.
>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., A DICOM Object Catalog Section SHALL be present if other document sections contain references to DICOM SOP Instances (images, structured report measurements, or other information objects), and MAY be present otherwise.>
###End Tabular Format - Document
###Begin Discrete Conformance Format - Document
<Delete the example information contained in the material below (from Cardiology CRC)>
<e.g., The complete set of body constraints, including those from C-CDA section/entry definitions are:
SHALL contain exactly one [1..1] component (CONF:9588).
A Cath Report Content SHALL have a structuredBody (CONF:9589-CRC).
A Cath Report Content SHALL conform to CDA Level 3 (structuredBody containing sections that contain a narrative block and coded entries). In this template (templateId 2.16.840.1.113883.10.20.22.1.6), coded entries are optional. (CONF:9590-CRC).
The component/structuredBody SHALL conform to the section constraints below (CONF:9595-CRC).
Each section SHALL have a title and the title SHALL not be empty (CONF:9937).>
<The following table shows relationships among the templates in the body of a Cath Report Content document.>
Table 6.3.1.D.5-1 <Content Module Name (Acronym)> Document Content Module Specification
| Template Title | Opt and Card | Condition | Template Type | templateId |
Vocabulary Constraints |
|---|---|---|---|---|---|
| Delete this row and the example information in the rows below. | |||||
| <e.g., Cath Report Content | R[1..1] | document | 1.3.6.1.4.1.19376.1.4.1.1.2 | 6.3.1.D.5.1 | |
| Document Summary-Cardiac Section | O[0..1] | Section | 1.3.6.1.4.1.19376.1.4.1.2.16 | ||
| Medical History - Cardiac Section | R[1..1] | Section | 1.3.6.1.4.1.19376.1.4.1.2.17 | ||
| Procedure Activity Observation | O[0..*] | Entry | 2.16.840.1.113883.10.20.22.4.13 | ||
| Procedure Activity Procedure | O[0..*] | Entry | 2.16.840.1.113883.10.20.22.4.14 | ||
| Problem Observation - Cardiac | O[0..*] | Entry | 2.16.840.1.113883.10.20.22.4.4 | ||
| Age Observation | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.31 | ||
| Health Status Observation | O[0..1] | 6.3.1.D.5.2 | Entry | 2.16.840.1.113883.10.20.22.4.5 | |
| Problem Status | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.6 | ||
| Severity Observation | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.8 | ||
| Allergies Section | R[1..1] | Section | 2.16.840.1.113883.10.20.22.2.6 | ||
| Allergy Problem Act | O[0..*] | Entry | 2.16.840.1.113883.10.20.22.4.30 | ||
| Allergy Observation | R[1..*] | Entry | 2.16.840.1.113883.10.20.22.4.7 | ||
| Allergy Status Observation | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.28 | ||
| Reaction Observation | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.9 | ||
| Severity Observation | O[0..1] | Entry | 2.16.840.1.113883.10.20.22.4.8 | ||
| Family History – Cardiac Section | O[0..1] | Section | 1.3.6.1.4.1.19376.1.4.1.2.18 | ||
| Problem Observation - Cardiac | O[0..*] | Entry | 2.16.840.1.113883.10.20.22.4.4 | ||
| Social History Section | O[0..1] | Section | 2.16.840.1.113883.10.20.22.2.17 | ||
| Physical Exam Section | R[1..1] | Section | 2.16.840.1.113883.10.20.2.10 | ||
| Vital Signs | R[1..1] | Section | 2.16.840.1.113883.10.20.22.2.4.1 | ||
| Vital Signs Organizer | R[1..*] | Entry | 2.16.840.1.113883.10.20.22.4.26 | ||
| Vital Sign Observation | R[2..*] | Entry | 2.16.840.1.113883.10.20.22.4.27> |
<For each (1:1 correspondence) Vocabulary Constraint or Condition listed in the table above, create an additional section/reference below. Add the Header Element or Section Name and then select either “Vocabulary Constraint” or “Condition” and delete the other word.>
<Note that every Conditional element MUST have an explanatory paragraph referenced below.>
<It is required to use SHALL, SHOULD, or MAY in each definition as defined in Appendix E of the Technical Frameworks General Introduction.>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., The value for serviceEvent / code SHOULD be drawn from value set 1.3.6.1.4.1.19376.1.4.1.5.2 Cardiac Imaging Procedures.
OR
The value for serviceEvent / code SHOULD be drawn from the value set bound to the concept domain UV_CardiacImagingProcedures
>
<add vocabulary constraint or condition definition>
<remove example below prior to public comment:>
<e.g., Within the Medications section the Content Creator SHALL be able to create a Medications entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.7 [PCC TF-2]) for each of the cardiac relevant medications identified in Value Set 1.3.6.1.4.1.19376.1.4.1.5.14 Cardiac Drug Classes, encoding the value in substanceAdministration/consumable/ManufacturedProduct/Material/code.
OR
Within the Medications section the Content Creator SHALL be able to create a Medications entry (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.7 [PCC TF-2]) for each of the cardiac relevant medications identified in the value set bound to the concept domain UV_CardiagDrugClasses, encoding the value in substanceAdministration/consumable/ManufacturedProduct/Material/code.
>
###End Discrete Conformance Format - Document
<This section is the same, independent of whether the tabular or discrete conformance formats were chosen.>
<Describe the conformance of this document in terms of inheritance from other templates. Use the OIDs of those templates for clarity. A complete example of this document MUST be placed on the IHE ftp server as part of the Public Comment process of a Content Module supplement at ftp://ftp.ihe.net/TF\_Implementation\_Material/. The file naming convention for these files should be <Domain Acronym>_<Profile Acronym>_CDA-sample_<version number>.xml where version number is the version number of the profile>.
CDA Release 2.0 documents that conform to the requirements of this document content module shall indicate their conformance by the inclusion of the <templateId> XML elements in the header of the document.
A CDA Document may conform to more than one template. This content module inherits from the <template name(s) and template ID(s)> <e.g., CDA-PN, 2.16.840.1.113883.10.20.18.1, and the PCC TF Medical Document, 1.3.6.1.4.1.19376.1.5.3.1.1.1, content modules> and so must conform to the requirements of those templates as well this document specification, <templateName and templateID> <e.g., Cardiac Imaging Report template, 1.3.6.1.4.1.19376.1.4.1.1.1>.
A complete example of the <Content Module Name and Acronym> Document Content Module is available on the IHE ftp server at: <indicate location here>.
Note that this is an example and is meant to be informative and not normative. This example shows the <templateId (OIDs)> elements for all of the specified templates.
Add to section 6.3.2 Header Content Modules
<Authors’ Note: Replicate section 6.3.2.H for each Header Content Module defined in this profile. Number as 6.3.2.H1, 6.3.2.H2, etc.>
###Begin Tabular Format - Header
<Either the Parent Template OR the Header Element may constrain this Header Element, not both. One should be “N/A”.>
<The values in the column “Participations and Act Relationships” must come from the defined terms in the CDA schema. See the IHE Technical Frameworks General Introduction, Appendix E: CDA Conventions.>
Table 6.3.2.H-1 <Content Module Name (Acronym)> Header
| Template Name | <Template Name> | ||||
| Template ID | <oid> | ||||
| Parent Template | <Name and oid of parent template or NA> | ||||
| Header Element |
<CDA Header Elements participant or componentOf or NA> e.g., componentOf / encompassingEncounter |
||||
| General Description | <short textual description. Short paragraph at most.> | ||||
| Opt and Card | Participation/ Act Relationship | Description | Template | Specification Document | Vocabulary Con-straint |
| x [?..?] | <select from defined part /act relationship terms; App E> | <Header Content description name> | <oid> | <document reference, if applicable> | <Vocab constraint, if applicable> |
| <e.g., R [1..1] | RESP | Responsible Party | CARD TF-3: 6.3.2.H.1> | ||
| <e.g., R [1..1] | LOC | Health Care Facility | CARD TF-3: 6.3.2.H.2> | ||
| <e.g., O [0..1] | REF | Referring Provider | CARD TF-3: 6.3.2.H.3> | ||
| <e.g., C [0..1] | ATND | Physician of Record | 2.16.840.1.113883.10.20.6.2.2 | CDA-DIR | CARD TF-3: 6.3.2.H.4> |
<For each Vocabulary Constraint or Specification Document listed in the table above, create an additional section/reference below. Add the Description Name and then select either “Vocabulary Constraint” or “Spec Document” and delete the other word.>
<It is required to use SHALL, SHOULD, or MAY in each definition as defined in Appendix E of the Technical Frameworks General Introduction.>
<Also note that the Specification Document link can be a link to an outside document/reference. Do not replicate (cut and paste) sections of other documents into this document since they could become out of sync.>
6.3.2.H.1 <Description Name> <e.g., Responsible Party> <Specification Document or Vocabulary Constraint>
<Describe constraints or other info. This specification may include more information on conditions or cardinality, additions elements, data mappings, or data types, or other information.>
<Delete the example below prior to publishing for Public Comment.>
<e.g., The responsible party element represents only the party responsible for the encounter, not necessarily the entire episode of care.>
<e.g., The responsibleParty element MAY be present. If present, responsibleParty/ assignedEntity SHALL have at least one assignedPerson or representedOrganization element present.>
<e.g., Note: This is identical to CDA-DIR CONF-DIR-67>
<e.g., responsibleParty assignedEntity id SHALL be present with the responsible physician’s identifier.>
<e.g., assignedEntity code SHOULD be present with the responsible physician’s specialty.>
<e.g., assignedEntity MAY include an accreditation element from the urn:ihe:card namespace to provide physician accreditation status.>
<e.g., The accreditation element SHALL use the character string (ST) data type.
The accreditation element SHALL appear after the defined elements of the Role class, and before any scoper or player entity elements.>
<e.g., assignedEntity assignedPerson name SHALL be present with the responsible physician’s name.>
###End Tabular Format – Header
###Begin Discrete Conformance Format – Header
The header for the <Document Name> document shall support the following header constraints as noted in this section. Note that this content profile is realm agnostic. These header constraints are based on the C-CDA header constraints but all references to US Realm specific types have been removed.
<An example is provided to demonstrate the desired consistent use and format. Delete this example prior to publication for Public Comment. The statement must be numbered, begin with SHALL/SHOULD/MAY, identify the cardinality using [n..n], the name of the element, and a subitem which describes the value or source of the information.>
<e.g.,
-
SHALL contain exactly one [1..1] typeId (CONF:5361).
-
This typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).
-
This typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).
-
-
SHALL contain exactly one [1..1] templateId (CONF:5252) such that it
- SHALL contain exactly one [1..1] @root="1.3.6.1.4.1.19376.1.4.1.1.2" for the Cath Report Content document template (CONF:CRC-xxx).
-
SHALL contain exactly one [1..1] id (CONF:5363).
- This id SHALL be a globally unique identifier for the document (CONF:9991).
-
SHALL contain exactly one or two [1..2] code (CONF:5253-CRC).
- SHALL be selected from ValueSet ProcedureNoteDocumentTypeCodes 2.16.840.1.113883.11.20.6.1 DYNAMIC (CONF:8497). Either or both of the following codes should be included:
|
Value Set: ProcedureNoteDocumentTypeCodes 2.16.840.1.113883.11.20.6.1 DYNAMIC Code System: LOINC 2.16.840.1.113883.6.1 |
|||
|---|---|---|---|
| LOINC Code | Type of Service ‘Component’ | Setting ‘System’ | Specialty/Training/Professional Level ‘Method_Type’ |
| 18745-0 | Study report | Heart | Cardiac catheterization |
| 34896-1 | Interventional procedure note | {Setting} | Cardiology |
-
SHALL contain exactly one [1..1] title (CONF:5254).
- Can either be a locally defined name or the display name corresponding to clinicalDocument/code (CONF:5255).>
###End Discrete Conformance Format – Header
Add to section 6.3.3.10 Section Content Modules
< Authors’ Note: Replicate section 6.3.3.10.S for each Section Content Module defined in this profile. Number as 6.3.3.10.S1, 6.3.3.10.S2, etc.>
<Authors’ notes: Section naming instructions: If a section is a specialization of an existing section, begin the name with the original section name. For example, if Cardiology is creating a specialization of the “Medical History Section”, the new section should be named “Medical History Section – Cardiac” and not “Cardiac Medical History Section”.>
###Begin Tabular Format - Section
<Delete examples in rows of table below prior to Public Comment.>
Table 6.3.3.10.S-1 <Section Module Name> Section
| Template Name | <exact same Section Module name listed above> | ||||
| Template ID | <oid> | ||||
| Parent Template | <Parent Template Name oid/uid [Domain - Reference] or NA> | ||||
| General Description | <brief textual description, one paragraph> | ||||
| Section Code | <Code, Code Scheme, “Section Code Name”> | ||||
| Author | <If inherited from encompassing content module use “current recordTarget”, unless otherwise specified. Role and entity must be specified if not inherited. > | ||||
| Informant | <If inherited from encompassing content module use “current recordTarget”, unless otherwise specified.> | ||||
| Subject | <If inherited from encompassing content module use “current recordTarget”, unless otherwise specified.> | ||||
| Opt and Card | Condition | Data Element or Section Name | Template ID | Specification Document |
Vocabulary Constraint |
| Subsections | |||||
| x [?..?] | <ref or link to cond section below, if applicable> | <name of subsection> | <oid> | <reference or link to specification document location, if applicable> | <reference or link to vocab constraint, if applicable> |
| <e.g., O [0..1] | Active Problems | 1.3.6.1.4.1.19376.1.5.3.1.3.6 | PCC TF-3> | ||
| <e.g., O [0..1] | History of Present Illness | 1.3.6.1.4.1.19376.1.5.3.1.3.4 | PCC TF-3> | ||
| <e.g., O [0..1] | History of Past Illness | 2.16.840.1.113883.10.20.2.9 | CDA-PN> | ||
| Entries | |||||
| x [?..?] | <ref or link to cond section below, if applicable> | <name of entry> | <oid> | <reference or link to specification document location, if applicable> | <reference or link to vocab constraint, if applicable> |
| <e.g., C [1..*] | CARD TF-3 6.3.3.x.S.1 | Problem Concern Entry | 1.3.6.1.4.1.19376.1.5.3.1.4.5.2 | PCC TF-3> | |
| <e.g., C [1..1] | Diabetes Problem Entry | 1.3.6.1.4.1.19376.1.4.1.4.1 | CARD TF-3 6.3.3.1> | ||
| <e.g., C [1..1] | Angina Problem Entry | 1.3.6.1.4.1.19376.1.4.1.4.2 | CARD TF-3 6.3.3.1> | ||
| <e.g., C [1..*] | CARD TF-3 6.3.3.x.S.1 | Simple Observation | 1.3.6.1.4.1.19376.1.5.3.1.4.13 | PCC TF-3 | CARD TF-3 6.3.3.x.S.2> |
6.3.3.10.S.1 <Data Element or Section Name> <Condition, Specification Document, or Vocabulary Constraint>
<Describe constraints; refer to other Specification Document, condition, or other info. This specification may include more information on conditions or cardinality, additions elements, data mappings, or data types, or other information.>
<Delete the example below prior to publishing for Public Comment.>
<e.g., The Medical History Section SHALL contain at least one Problem Concern Entry or at least one Simple Observation.
Note: Problems MAY be recorded directly in the Medical History Section, or in one or more subsections such as Active Problems, History of Present Illness, or History of Past Illness.>
6.3.3.10.S.2 <Data Element or Section Name> <Condition, Specification Document, or Vocabulary Constraint>
<Describe constraints, refer to other Specification Document, condition, or other info. This specification may include more information on conditions or cardinality, additions elements, data mappings, or data types, or other information.>
<Delete the example below prior to publishing for Public Comment.>
<e.g., A Content Creator SHALL be able to include a Problem Concern Entry for each of the conditions identified in Value Set 1.3.6.1.4.1.19376.1.4.1.5.4 Cardiac Problems/Concerns, encoding the value in act/entryRelationship/observation/code.
A Problem Concern Entry for {73211009, SNOMED CT, diabetes} SHALL use the specialized Diabetes Problem Entry (OID = 1.3.6.1.4.1.19376.1.4.1.4.1).
A Problem Concern Entry for {194828000, SNOMED CT, angina} SHALL use the specialized Angina Problem Entry (OID = 1.3.6.1.4.1.19376.1.4.1.4.2).
OR
A Content Creator SHALL be able to include a Problem Concern Entry for each of the conditions identified in the Concept Domain UV_CardiacProblems (See section X.X for the description/list of concepts in this domain), encoding the value in act/entryRelationship/observation/code.
A Problem Concern Entry for “diabetes” SHALL use the specialized Diabetes Problem Entry (OID = 1.3.6.1.4.1.19376.1.4.1.4.1).
A Problem Concern Entry for “angina” SHALL use the specialized Angina Problem Entry (OID = 1.3.6.1.4.1.19376.1.4.1.4.2).
>
6.3.3.10.S.3 <Data Element or Section Name> <Condition, Specification Document, or Vocabulary Constraint>
###End Tabular Format – Section
###Begin Discrete Conformance Format – Section
<An example is provided to demonstrate the desired consistent use and format. Delete this example prior to publication for Public Comment. The statements must be numbered, begin with SHALL/SHOULD/MAY identify the cardinality using [n..n], the name of the element, and a subitem which described the value or source of the information.>
<e.g.,
[section: templateId 1.3.6.1.4.1.19376.1.4.1.2.17(open)]
[section: templateId 2.16.840.1.113883.10.20.22.2.39(open)]
The Medical History section describes all aspects of the medical history of the patient even if not pertinent to the current procedure, and may include chief complaint, past medical history, social history, family history, surgical or procedure history, medication history, and other history information. The history may be limited to information pertinent to the current procedure or may be more comprehensive. The history may be reported as a collection of random clinical statements or it may be reported categorically. Entries for History of Past Illness and History of Present Illness have been consolidated into this section. Social and Family History are discussed in their own sections. For this Cath Report Content profile, this section may also contain history about specific relevant problems as problem observations.
In the event that the patient was transferred from another facility where there was a problem indication that the patient was determined to need a cath procedure, this will be noted as a problem observation in this medical history section as text in the narrative for now until there is a code representing this.
-
SHALL contain exactly two [2..2] templateId (CONF:8160) such that it
-
SHALL contain exactly one [1..1] @root="1.3.6.1.4.1.19376.1.4.1.2.17" (CONF:10403-CRC).
-
SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.2.39" (CONF:10403).
-
-
SHALL contain exactly one [1..1] code/@code="11329-0" Medical (General) History (CodeSystem: LOINC 2.16.840.1.113883.6.1) (CONF:8161).
-
SHALL contain exactly one [1..1] title (CONF:8162).
-
SHALL contain exactly one [1..1] text (CONF:8163).
-
MAY contain zero or more [0..*] entry (CONF:CRC-xxx) such that it
- SHALL contain exactly one [1..1] Problem Observation - Cardiac (1.3.6.1.4.1.19376.1.4.1.4.9) (CONF:CRC-xxx).
-
MAY contain zero or more [0..*] entry (CONF:CRC-xxx) such that it
- SHALL contain exactly one [1..1] Procedure Activity Observation (2.16.840.1.113883.10.20.22.4.13) (CONF:CRC-xxx).
-
MAY contain zero or more [0..*] entry (CONF:CRC-xxx) such that it
- SHALL contain exactly one [1..1] Procedure Activity Procedure (2.16.840.1.113883.10.20.22.4.14) (CONF:CRC-xxx).
<section>
<templateId root="1.3.6.1.4.1.19376.1.4.1.2.17"/>
<templateId root="2.16.840.1.113883.10.20.22.2.39"/>
<code code="11329-0" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"
displayName="MEDICAL (GENERAL) HISTORY"/>
<title>MEDICAL (GENERAL) HISTORY</title>
<text>
<list listType="ordered">
<item>Patient has had a recent issue with chest pain that does not seem to be related to any particular cause.</item>
<item>Previous concerns of heart disease were actually related to other causes.</item>
<item>Patient had recent weight gain due to sedentary lifestyle and
new job.</item>
</list>
</text>
<entry>
<observation classCode=”OBS” moodCode=”EVN”>
<templateId root=”1.3.6.1.4.1.19376.1.4.1.9”/>
<id root=”xyz”/>
…
</observation>
</entry>
</entry>
<observation classCode="PROC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.14"/>
<!-- Procedure Activity Procedure template -->
...
</observation>
</entry>
</entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.13"/>
<!-- Procedure Activity Observation template -->
...
</observation>
</entry>
</section>
Figure Example: Example Section example>
###End Discrete Conformance Format - Section
Add to section 6.3.4.E Entry Content Modules
<Authors’ Note: Replicate section 6.3.4.E for each Entry Content Module defined in this profile. Number as 6.3.4.E1, 6.3.4.E2, etc.>
<If this entry has subsidiary/child entries, these entries are referenced in the table below. Create one row for each subsidiary/child entry.>
### Begin Tabular Format - Entry
Table 6.3.4.E-1 <Entry Module Name> Entry
| Template Name | <Template name> | ||||
| Template ID | <oid> | ||||
| Parent Template | <Parent Template Name oid/uid [Domain - Reference]> or NA | ||||
| General Description | <brief textual description, one paragraph> | ||||
| Class/Mood | Code | Data Type | Value | ||
| <use one of defined Class/Mood see General Intro App E> | <Code, code system, code meaning e.g., 18118-0, LOINC, “LV Wall Motion Segmental Findings”> | <Applies only if the Class/ Mood is OBS/EVN. Enumerated in HL7 V3 Data Types R1.> | <If the Class/Mood is OBS/EVN, then this Value field is the constraint on Observation Value. Otherwise, this field should be “N/A”.> | ||
| Opt and Card | entryRelationship | Description | Template ID | Specification Document | Vocabulary Constraint |
| <e.g., x [?..?]> | Simple Observation | oid | reference to document e.g., PCC-TF-3 | <reference/link to definition of constraint, often in next paragraph/ subsection e.g., CARD TF-3 6.3.3.4.9.10> | |
| <e.g., C [1..*] | COMP | Simple Observation | 1.3.6.1.4.1.19376.1.5.3.1.4.13 | PCC TF-2 | CARD TF-3 6.3.4.E.1 (Wall morphology)> |
| <e.g., O [0..1] | COMP | Simple Observation | 1.3.6.1.4.1.19376.1.5.3.1.4.13 | PCC TF-2 | CARD TF-3 6.3.4.E.2 (Viability)> |
| <e.g., O [0..1] | COMP | observationMedia Entry | 1.3.6.1.4.1.19376.1.4.1.4.7 | CARD TF-3 6.3.1.6> |
<Describe constraints, refer to other Specification Document, condition, or other info. This specification may include more information on conditions or cardinality, additions elements, data mappings, or data types, or other information.>
<Can be in a tabular format or textual description.>
<Delete the example below prior to publishing for Public Comment.>
<e.g., The conditional entries specified in this table SHALL be present based on the exam type as specified in the CDA Header in the documentationOf / serviceEvent / code element.>
| Opt and Card | Condition | observation/code | Data Type | Unit of Measure |
Value Set/ Concept Domain |
|---|---|---|---|---|---|
| <e.g., C [1..*] |
<Identifies the predicate and the if the predicate evaluates as true, then indicate whether mandatory, required or optional e.g., Required if “exam type” is “LVG” (left ventriculogram)> R: LVG |
60797005, SNOMED CT, “Cardiac Wall Motion” <”+” = May be post-coordinated with priorityCode, methodCode, targetSiteCode . See HL7 V3. Include a value directly or include a link to a value set, if applicable.> e.g., + targetSiteCode from 1.2.840.10008.6.1.219 DICOM CID 3718 Myocardial Wall Segments in Projection |
CD | n/a unless the Data Type is PQ or IVL<PQ> |
<include link to value set, e.g., 1.3.6.1.4.1.19376.1.4.1.5.20 Wall motion OR, include value directly as e.g., <The Observation Value may also have a post-coordinated interpretation such as:> +interpretationCode +negationInd > |
| <e.g., C [1..*] |
R: SPECT, TTE, TEE, CMR O:CCTA |
60797005, SNOMED CT, “Cardiac Wall Motion” + targetSiteCode from 1.2.840.10008.6.1.218 DICOM CID 3717 Myocardial Wall Segments |
CD | n/a | UV_WallMotion > |
<Describe constraints; refer to other Specification Document, condition, or other info. This specification may include more information on conditions or cardinality, additions elements, data mappings, or data types, or other information.>
<Can be in a tabular format or textual description.>
<Delete the example below prior to publishing for Public Comment.>
<e.g., The conditional entries specified in this table SHALL be present based on the exam type as specified in the CDA Header in the documentationOf / serviceEvent / code element.>
| Opt and Card | Condition | observation/code | Data Type | Unit of Measure |
Value Set/ Concept Domain |
|---|---|---|---|---|---|
| <e.g., C [1..*] | R: Cath with LVG |
72724002, SNOMED CT, “Morphology findings” + targetSiteCode from 1.2.840.10008.6.1.219 DICOM CID 3718 Myocardial Wall Segments in Projection |
CD | n/a | 1.3.6.1.4.1.19376.1.4.1.5.19 Myocardium Assessments> |
| <e.g., C [1..*] |
R: SPECT, echo, CMR O:CCTA |
72724002, SNOMED CT, “Morphology findings” + targetSiteCode from 1.2.840.10008.6.1.218 DICOM CID 3717 Myocardial Wall Segments |
CD | n/a | UV_MyocardiumAssessments> |
<e.g., The observation/value MAY be a null flavor.>
<e.g., morphological assessment observation MAY have a subsidiary Severity observation (templateID 1.3.6.1.4.1.19376.1.5.3.1.4.1 [PCC TF-2]).>
### End Tabular Format - Entry
### Begin Discrete Conformance Format – Entry
<An example is provided to demonstrate the desired consistent use and format. Delete this example prior to publication for Public Comment. The statements must be numbered, begin with SHALL/SHOULD/MAY identify the cardinality using [n..n], the name of the element, and a subitem which described the value or source of the information.>
[observation: templateId 1.3.6.1.4.1.19376.1.4.1.4.16 (open)]
A result observation is a clinical statement that a clinician has noted during the Cath Lab procedure. This entry is used to describe the specific procedure findings that were observed during the specific Cath Lab procedure.
The specific result observations are defined in 1.3.6.1.4.1.19376.1.4.1.5.38 Procedure Findings Constraints/ValueSet.
-
SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6) (CONF:7130).
-
SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001) (CONF:7131).
-
SHALL contain exactly one [1..1] templateId (CONF:7136) such that it
- SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.4.2" (CONF:9138).
-
SHALL contain at least one [1..*] id (CONF:7137).
-
The first id represents this specific globally unique result observation.
-
The second id represents the lesion ID which should be an assigned numeric code that identifies lesions within a specific targetSiteCode.This lesion ID is used to link lesion specific data in this Result Observation – Cardiac with Procedure Activity Procedure - Cardiac.
-
-
SHALL contain exactly one [1..1] code (CONF:7133).
- SHOULD be from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or SNOMED CT (Value Set: 1.3.6.1.4.1.19376.1.4.1.5.38) (CONF:7166-CRC).
-
SHOULD contain zero or one [0..1] text (CONF:7138).
-
The text, if present, SHOULD contain zero or one [0..1] reference/@value (CONF:7139).
- This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1) (CONF:9119).
-
-
SHALL contain exactly one [1..1] statusCode="completed" Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14) (CONF:7134).
-
SHALL contain exactly one [1..1] effectiveTime (CONF:7140).
- represents clinically effective time of the measurement, which may be when the measurement was performed (e.g., a BP measurement), or may be when sample was taken (and measured some time afterwards) (CONF:7141).
-
SHALL contain exactly one [1..1] value with @xsi:type="ANY" (CONF:7143).
-
SHOULD contain zero or more [0..*] interpretationCode (CONF:7147).
-
MAY contain zero or one [0..1] methodCode (CONF:7148).
-
MAY contain zero or one [0..1] targetSiteCode (CONF:7153).
- The targetSiteCode, if present, SHALL contain exactly one [1..1] code where the @code SHALL be selected from ValueSet Body Site 1.3.6.1.4.1.19376.1.4.1.5.32 STATIC (CONF:CRC).
-
MAY contain zero or one [0..1] author (CONF:7149).
-
SHOULD contain zero or more [0..*] referenceRange (CONF:7150).
-
The referenceRange, if present, SHALL contain exactly one [1..1] observationRange (CONF:7151).
- This observationRange SHALL NOT contain [0..0] code (CONF:7152).
-
-
SHOULD contain zero or one [0..1] entryRelationship (CONF:CRC-xxx) such that it
-
SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002) (CONF:CRC-xxx).
-
SHALL contain exactly one [1..1] @inversionInd="true" TRUE (CONF:CRC-xxx).
-
SHALL contain exactly one [1..1] Severity Observation (2.16.840.1.113883.10.20.22.4.8) (CONF:CRC-xxx).
-
<observation classCode="OBS" moodCode="EVN">
<templateId root="1.3.6.1.4.1.19376.1.4.1.4.16"/>
<!-- Result Observation template -->
<id root="c6f88321-67ad-11db-bd13-0800200c9a66"/>
<!-- This second ID represents the lesion ID -->
<id root="107c2dc0-67a5-11db-bd13-0800200c9a66" extension="1"/>
<code code="233970002"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Post procedure stenosis"/>
<text><reference value="1"/></text>
<statusCode code="completed"/>
<effectiveTime value="19991114"/>
<targetSiteCode code="41879009" codeSystem="1.3.6.1.4.1.19376.1.4.1.5.32"
displayName="Distal RCA"/>
<value xsi:type="PQ" value="0" unit="%"/>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"/>
</observation>
e.g., Figure 6.3.4.E-1: Result observation example >
### End Discrete Conformance Format - Entry
Not applicable
<This heading is not currently used in a CDA document and remains here for section numbering integrity. Do not remove it or renumber sections following it. >
Add to Section 6.5 Value Sets
<Replicate the Value Set 6.5.x section as many times as needed for this supplement.>
<It is preferable to use tabular format. Add notes as needed. Be aware of potential national licensing issues of coding schemes.>
<Add description or clarifications here if necessary.>
|
Coding Scheme Concept |
<Coding Scheme Name> |
|---|---|
Note: <as necessary, applicable>
OR
| <Concept Domain Name> |
|---|
<Delete the example below prior to publication for Public Comment.>
|
Coding Scheme Concept |
SNOMED CT | NDF-RT |
|---|---|---|
| Calcium channel blockers | 48698004 | N0000029119 |
| Beta-blockers | 33252009 | N0000029118 |
| Nitrates | 31970009 | N0000007647 |
| Aminophylline | 55867006 | N0000146397 |
Note: As described in Section 6.1.2.4, the selection of the appropriate coding system for use may be based on local policy or national regulation.
OR
This Concept Domain holds a list of Drug Classes used in Cardiac Procedures. The concepts in this domain must be bound to a value set at implementation.
| Concept Name |
|---|
| Calcium channel blockers |
| Beta-blockers |
| Nitrates |
| Aminophylline |
>
Appendices
<Add any applicable Volume 3 appendices below.
<If there are no Volume 3 appendices, enter “Not applicable” and delete the Appendix A and Appendix B placeholder sections.>
Appendix A text.
Appendix A.1 text.
Appendix A.1.1 text.
Appendix B text.
Appendix B.1 text.
Appendix B.1.1 text.
Volume 4 – National Extensions
Add appropriate Country section
4.I National Extensions for <Country Name or IHE Organization>
<A template for Volume 4 is included in this document for completeness; however, National Extensions are typically developed after a profile has been published for Trial Implementation. If you are developing a new profile for Public Comment, it is recommended that this section be marked “Not Applicable”.>
<Avoid using this section if you can, this is “only if absolutely necessary”. Differences add cost to implementation and testing and can reduce interoperability. Review carefully to determine if the national use case truly requires a difference in the profile mechanisms rather than just differences in system configuration.>
< National Extensions can add requirements above and beyond IHE, but not relax requirements. This would prevent Connectathon results based on national testing being recognized elsewhere. For more information, see http://wiki.ihe.net/index.php?title=National_Extensions_Process.>
The format of this section is not strongly specified due to the varying nature of national extensions. For an example of National Extensions, see RAD TF 4.>
4.I.1 Comment Submission
This national extension document was authored under the sponsorship and supervision of <sponsor name>, who welcome comments on this document and the IHE <country> initiative. Comments should be directed to:
<Name, organization, title, email address>
4.I.2 <Profile Name> <(Profile Acronym)>
<Add info or tables>
4.I.2.1<Profile Acronym> Value Set Binding for <Country Name or IHE Organization> Realm Concept Domains
<This section defines the actual value sets and code systems for any coded concepts that were described by concept domains in the main profile and binds the value set to the coded concepts.>
<Add info or tables>
<Delete the example below prior to publication for Public Comment.>
<e.g.,
4.I.2.1 <Profile Acronym> Value Set Binding for US Realm Concept Domains
| UV Concept Domain | US Realm Vocabulary Binding or Single Code Binding | Value Set OID |
| UV_CardiacProcedureDrugClasses | US_CardiacProcedureDrugClasses | 1.3.6.1.4.1.19376.1.4.1.5.15 |
|
Coding Scheme Concept |
SNOMED CT | NDF-RT |
|---|---|---|
| Calcium channel blockers | 48698004 | N0000029119 |
| Beta-blockers | 33252009 | N0000029118 |
| Nitrates | 31970009 | N0000007647 |
| Aminophylline | 55867006 | N0000146397 |
>
<Add info or tables>
4.I+1 National Extensions for <Country Name or IHE Organization>
<Repeat (and increment) the section above as needed for additional National Extensions>
Appendices
<Add any applicable Volume 4 appendices below>
<If there are no Volume 4 appendices, enter “Not applicable” and delete the Appendix A and Appendix B placeholder sections.>
Appendix A text.
Appendix A.1 text.
Appendix A.1.1 text.
Appendix B text.
Appendix B.1 text.
Appendix B.1.1 text.