Difference between revisions of "2009 TSC Product Visibility"

From HL7 TSC
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
===Project Objectives and Deliverables===
 
===Project Objectives and Deliverables===
 
# Create workable definitions of HL7 PRODUCTS
 
# Create workable definitions of HL7 PRODUCTS
−
#*Develop Product matrix for TSC review
+
#*DELIVERABLE: Draft material for the Web Site on Products (this page)
−
#*Draft material for the Web Site on Products (definitions and descriptions)
+
#**Health Information '''''Exchange''''' Standards
−
#** start with 10-20 products
+
#***Messaging, Documents, and Services
−
#***Concept of 'Featured' products
+
#**Health Information '''''Knowledge Representation''''' Standards
−
#*** include ANSI - approved products
+
#***Arden Syntax, SPL, GELLO
−
#*** include DSTU
+
#**'''''Modeling''''' Standards
−
#**intended use
+
#***RIM, CTS, EHR Lifecycle FM
−
#**who are the intended customers,
+
#**Application '''''Functional Specifications'''''
−
#**who are the actual users,
+
#***EHR-S FM, PHR-S FM, EIS SFM, RLUS SFM, DSS SFM, CRFQ SFM
−
#**what education is available.
+
#**'''''Visual Integration Messages'''''
 +
#***Clinical Context Management Specification (CCOW)
 +
#**Other
 +
#***SAEAF, Practical Guide for SOA in Healthcare
 
#**Anticipate input from Education Committee, NHS Product Descriptions, WG having responsibility for product, and other sources
 
#**Anticipate input from Education Committee, NHS Product Descriptions, WG having responsibility for product, and other sources
−
#*Evaluate future application of Products List to group by “Product Category”
 
 
#**Define purpose and maintenance of categories list.
 
#**Define purpose and maintenance of categories list.
 
#*Evaluate future reference by Product to:
 
#*Evaluate future reference by Product to:
Line 38: Line 40:
 
* PI ID # [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=439 439], also Roadmap Task #37: HL7 Website to list HL7 IGs, scope, language, Affiliate, link, etc.  
 
* PI ID # [http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=439 439], also Roadmap Task #37: HL7 Website to list HL7 IGs, scope, language, Affiliate, link, etc.  
  
 +
===Product List (Tentative)===
  
 +
====Health Information '''''Exchange''''' Standards====
 
{|border="1"
 
{|border="1"
−
|+Tentative Product List and Template Descriptions
+
|+Tentative Product List  
 
|-
 
|-
−
!width="10%"| Product
+
!width="15%"| Integration paradigm
−
!width="25%"| Summary
+
!width="15%"| Product
−
!width="25%"| Description (<500 words)
+
!width="70%"| Summary
−
!width="10%"| Business Case
+
 
−
!width="10%"| Benefits
 
−
!width="10%"| Implementation/ Case Studies
 
−
!width="10%"| Resources
 
 
|-
 
|-
 +
|
 +
Health Information '''''Exchange''''' Standards- '''Messaging'''
 
|
 
|
 
[[TSC_Product_List_V3| V3]] - Version 3 Normative Edition
 
[[TSC_Product_List_V3| V3]] - Version 3 Normative Edition
Line 55: Line 58:
 
Version 3 is HL7’s family of standards developed with a model-driven methodology.  The release of HL7’s Version 3 Normative Edition marks a quantum leap in the functionality and interoperability of messaging standards. Version 3 is one of the first in the industry to embrace XML. Several countries throughout the world have already begun significant Version 3 implementations, including the United Kingdom, Canada, the Netherlands, Mexico, Germany and Croatia.
 
Version 3 is HL7’s family of standards developed with a model-driven methodology.  The release of HL7’s Version 3 Normative Edition marks a quantum leap in the functionality and interoperability of messaging standards. Version 3 is one of the first in the industry to embrace XML. Several countries throughout the world have already begun significant Version 3 implementations, including the United Kingdom, Canada, the Netherlands, Mexico, Germany and Croatia.
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Messaging'''
 
|
 
|
−
: c
+
[[TSC_Product_List_CGPED| Clinical Genomics Pedigree Topic]]
−
|  
 
−
: d
 
 
|
 
|
−
From HIMSS 2009 <br/>
+
The HL7 Clinical Genomics Pedigree Topic includes the Family History Model describing a patient’s pedigree with genomic data. It has the ability to transmit complete family history information for clinical decision support. This model is ANSI-approved and is the HITSP-accepted standard. This standard allows EHR/PHR interoperability, and is in use by the Surgeon General in his family history collection website: My Family Health Portrait. It is also in the process of becoming of an international standard through ISO.
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS-2009-V3_Mon%20and%20Wed.pdf The Essence of Model-driven Standards]
 
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/Reference%20Information%20Model_Tue.pdf Intro to HL7 RIM]
 
 
|
 
|
 
|-
 
|-
 +
|
 +
Health Information '''''Exchange Standards'''''- '''Messaging'''
 
|
 
|
 
[[TSC_Product_List_V2| V2]] Version 2 Messaging Standard
 
[[TSC_Product_List_V2| V2]] Version 2 Messaging Standard
Line 73: Line 74:
 
The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. First released in October 1987 as An Application Protocol for Electronic Data Exchange in Healthcare Environments, Version 2 is a messaging standard that allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Version 2.6, representing the latest update to the Version 2 Standard, was published in January 2008. Version 2.7 is in the final stages of balloting and is expected to be released later this year.
 
The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. First released in October 1987 as An Application Protocol for Electronic Data Exchange in Healthcare Environments, Version 2 is a messaging standard that allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Version 2.6, representing the latest update to the Version 2 Standard, was published in January 2008. Version 2.7 is in the final stages of balloting and is expected to be released later this year.
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Messaging'''
 
|
 
|
−
: c
+
[[TSC_Product_List_V2_XML | XML Encoding Syntax for Version 2]]
−
|  
 
−
: d
 
 
|
 
|
 +
HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix.
 
|
 
|
−
 
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_CDA|CDA]] (R1)
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 +
|
 +
[[TSC_Product_List_CDA|CDA]]  
 
|
 
|
 
The Clinical Document Architecture (CDA) is a specification for the exchange of electronic clinical documents. It can contain coded data and narrative and is compatible with the electronic health record and document management systems. CDA is at the core of virtually all standards-based exchange networks in the US and abroad and is adaptable for dictated notes and highly-structured public health and quality reporting.  
 
The Clinical Document Architecture (CDA) is a specification for the exchange of electronic clinical documents. It can contain coded data and narrative and is compatible with the electronic health record and document management systems. CDA is at the core of virtually all standards-based exchange networks in the US and abroad and is adaptable for dictated notes and highly-structured public health and quality reporting.  
 
|
 
|
−
Clinical documents are the core of a patient's lifetime health record. HL7’s CDA standard provides an exchange model for clinical documents such as discharge summaries and progress notes. A consistent approach to electronic clinical documents means that critical information contained in the documents can be used independently of the application on which it was produced. For example, CDA documents can be displayed using XML-aware Web browsers or wireless applications on mobile devices.
+
|-
 
|
 
|
−
: a
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: b
+
[[TSC_Product_List_CCD | CCD]]
−
|  
 
−
:  c
 
 
|
 
|
−
Contacts: Liora Alschuler, Calvin Beebe, Keith Boone, Bob Dolin
+
HL7 and ASTM International created the Continuity of Care Document (CCD) to integrate two complementary healthcare data specifications ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA). The CCD is endorsed by the Healthcare Information Technology Standards Panel (HITSP) as the harmonized format for the exchange of clinical information, including patient demographics, medications and allergies.
 
|
 
|
−
 
 
|-
 
|-
 
|
 
|
−
CDA R2
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
Clinical documents are the core of a patient's lifetime health record. HL7’s CDA standard provides an exchange model for clinical documents such as discharge summaries and progress notes. A consistent approach to electronic clinical documents means that critical information contained in the documents can be used independently of the application on which it was produced. For example, CDA documents can be displayed using XML-aware Web browsers or wireless applications on mobile devices.
+
[[TSC_Product_List_Attachments | Claims Attachments]]
 
|
 
|
−
: a
+
In response to the federal mandate under HIPAA, HL7 and ASCX12 collaborated for a number of years to develop standards for claims attachments. This joint development effort has resulted in standards for attachments to healthcare claims, and pre-certification / pre-authorization transactions. HL7 attachments standards are based on the Clinical Document Architecture (CDA) and have been proposed by the Department of Health and Human Services (HHS) as the standard for claims attachments under HIPAA. In the HHS proposal, six attachment types developed by HL7 have been put forward for adoption: clinical reports; rehabilitation services; laboratory results; medications; ambulance services; and emergency department.
 +
See [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS_2009_WPS%20Insurance_Claims%20Attachments_final_Mon.pdf HIMSS 2009 presentation on WPS case study]
 
|
 
|
−
: b
+
|-
 
|
 
|
−
: c
+
Health Information '''''Exchange''''' Standards
−
|
 
−
: d
 
 
|
 
|
−
From HIMSS 2009 <br/>
+
HL7 V3: Registries; Real Time Location Tracking, R1
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS2009_Bob_CDA_Sunday.pdf CDA presentation]
+
|DSTU
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS2009_Bob_What's%20New%20with%20CDA_Tue.pdf What's new with CDA?]
 
−
<br/> Contacts: Liora Alschuler, Calvin Beebe, Keith Boone, Bob Dolin
 
 
|
 
|
 
|-
 
|-
 
|
 
|
−
CCD
+
Health Information '''''Exchange''''' Standards
 +
|
 +
HL7 V3: Clinical Statement Pattern, R1
 
|
 
|
−
HL7 and ASTM International created the Continuity of Care Document (CCD) to integrate two complementary healthcare data specifications ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA). The CCD is endorsed by the Healthcare Information Technology Standards Panel (HITSP) as the harmonized format for the exchange of clinical information, including patient demographics, medications and allergies.
+
DSTU
 
|
 
|
−
The HL7/ASTM Continuity of Care Document (CCD) is an implementation guide for sharing Continuity of Care Record (CCR) patient summary data using the HL7 Clinical Document Architecture (CDA). CCD establishes a rich set of templates representing the typical sections of a summary record and expresses these templates as constraints on CDA. These same templates—for vital signs, family history, plan of care, and so on—can then be reused in other CDA document types, establishing interoperability across a wide range of clinical use cases. The CCD is the basis for interoperability in the US Health Information Technology Standards Panel (HITSP) and Integrating the Healthcare Enterprise (IHE) use cases.
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards
 
|
 
|
−
: c
+
HL7 V3: Reuseable Information Constraint Templates, R1
−
|
 
−
: d
 
 
|
 
|
−
[http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS2009_Bob_CCD_Monday.pdf HIMSS 2009 CCD Presentation] <br/>
+
DSTU
−
Contacts: Liora Alschuler, Calvin Beebe, Keith Boone, Bob Dolin
 
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_SPL| SPL]]
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 +
|
 +
HL7 IG for CDA R2: Healthcare Associated Infection Reports, R1
 
|
 
|
−
Structured Product Labeling (SPL) defines the content of human prescription drug labeling in an XML format. This format is defined within the SPL schema and is displayed in a web browser using the SPL stylesheet. It is approved by Health Level Seven (HL7) and has been adopted by FDA as a mechanism for exchanging medication information. (from [http://en.wikipedia.org/wiki/Structured_Product_Labeling Wikipedia])
+
DSTU, IG
 
|
 
|
−
SPL documents contain both the content of labeling (all text, tables and figures) for a product along with additional machine readable information (drug listing data elements). Drug listing data elements include information about the product (product and generic names, ingredients, ingredient strengths, dosage forms, routes of administration, appearance, DEA schedule) and the packaging (package quantity and type).
+
|-
 
|
 
|
−
: a
+
Health Information '''''Exchange''''' Standards-
 
|
 
|
−
The benefits that accrue to all stakeholders in the drug regulatory process by adoption of Structured Product Labeling (SPL) make the business case for implementation of SPL overwhelming. The benefits of SPL derive from use of standard, universally adopted information standards such as XML, from the specific aspects of the SPL model for describing prescription drug content, and from adoption of an open standard for SPL. (from [http://www.fda.gov/oc/datacouncil/SPL_Release_2a_3_25.pdf FDA Publication], see Appendices)
+
HL7 V3: Immunization, R1
−
|
 
−
[http://www.fda.gov/oc/datacouncil/spl.html US FDA]
 
 
|
 
|
−
* [http://www.hl7.org/Special/committees/rcrim/index.cfm RCRIM WG]
+
DSTU
−
* SPL [http://wiki.hl7.org/index.php?title=Structured_Product_Labeling Project Wiki]
 
−
* SPL [http://spl-work-group.wikispaces.com/ Work Group Wiki]
 
−
*Contacts: Randy Levin, Gunther Schadow, Mead Walker
 
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_EHR_FM| EHR FM]]
+
Health Information '''''Exchange''''' Standards- '''Messages'''
 +
|
 +
HL7 V3: Clinical Genomics; Genotype, R1
 
|
 
|
−
The healthcare industry will reap tremendous benefits by adopting a common standard for electronic health record systems (EHR-S). The HL7 EHR-S Functional Model outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. To date, HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting. The EHR-S Functional Model is also in the final stages of vetting as an international standard through ISO.
+
DSTU
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: c
+
HL7 IG for CDA R2: Consult Notes, R1
−
|
 
−
: d
 
 
|
 
|
−
From HIMSS 2009 <br/>
+
DSTU, IG
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HL7_EHR_2009_HIMSS_presentation1_Sunday.pdf EHR-S FM and Standard]
 
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/Tutorial%20-%202007EHR-S_Advanced-HIMSS09-April_Wed.pdf Advanced EHR-S FM and Standard: Profiles Against the EHR & PHR S FM]
 
−
*Contacts: Don Mon, Linda Fischetti
 
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_PHR-S_FM| PHR-S FM]] - Personal Health Record System Functional Model
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 +
|
 +
HL7 IG for CDA R2: History and Physical (H&P)
 
|
 
|
−
The PHR-S FM defines the set of functions for Personal Health Record (PHR) systems and offers guidelines that facilitate health information exchange among different PHR systems and between PHR and Electronic Health Record systems. The PHR-S FM is was published as a Draft Standard for Trial Use (DSTU) in December 2008. During the period of trial use, consumers can begin requesting standards-based functionality when they select PHR systems for their use, vendors can begin incorporating the model’s requirements into their products and organizations that certify PHR systems can begin using the model’s conformance criteria for certification development and testing purposes. Groups such as the Certification Commission for Healthcare Information Technology (CCHIT) and the Centers for Medicare and Medicaid Services have already begun using components of the PHR-S FM
+
DSTU, IG
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: c
+
HL7 IG for CDA R2: Reference Profile for EHR Interoperability, R1
−
|
 
−
: d
 
 
|
 
|
−
From HIMSS 2009 <br/>
+
DSTU, IG
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/PHR%202009%20HIMSS%20presentation_Monday.pdf PHR-S FM and Standard]
 
−
* Contacts: Don Mon
 
 
|
 
|
 +
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_EAS| SAEAF]]
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 +
|
 +
HL7 IG for CDA R1, Personal Healthcare Monitoring Report, R1
 
|
 
|
−
The HL7 SOA-Aware Enterprise Architecture provides a framework for specification of standardized services that can be used by the HL7 community. It identifies artifacts and a constraint pattern that provides traceability from requirements. These specifications align with different levels of conformance that aid HL7 consumers in adopting standards in different contexts, and supports specific integration patterns between collaborators as they seek to achieve computable semantic interoperability.
+
DSTU
 
|
 
|
−
 
+
|-
−
 
 
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: c
+
HL7 IG for CDA R2, Operative Notes, R1
−
|
 
−
: d
 
 
|
 
|
−
Contacts: John Koisch, Charlie Mead, John Quinn
+
DSTU, IG
 
|
 
|
 
|-
 
|-
 
|
 
|
−
Claims Attachments
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 +
|
 +
HL7 IG for CDA R2, Level3: Healthcare Associated Infection Reports, R2 (US Realm)
 
|
 
|
−
In response to the federal mandate under HIPAA, HL7 and ASCX12 collaborated for a number of years to develop standards for claims attachments. This joint development effort has resulted in standards for attachments to healthcare claims, and pre-certification / pre-authorization transactions. HL7 attachments standards are based on the Clinical Document Architecture (CDA) and have been proposed by the Department of Health and Human Services (HHS) as the standard for claims attachments under HIPAA. In the HHS proposal, six attachment types developed by HL7 have been put forward for adoption: clinical reports; rehabilitation services; laboratory results; medications; ambulance services; and emergency department.
+
DSTU, IG
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: c
+
HL7 IG for CDA R2: CDA Framework for Questionnaire Assessments, R1
−
|
 
−
: d
 
 
|
 
|
−
[http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HIMSS_2009_WPS%20Insurance_Claims%20Attachments_final_Mon.pdf HIMSS 2009 presentation on WPS case study]
+
DSTU, IG
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_CGPED| Clinical Genomics Pedigree Topic]]
+
Health Information '''''Exchange''''' Standards - '''Services (SOA)'''
 +
|
 +
HL7 V3: Decision Support Service (DSS), R1
 
|
 
|
−
The HL7 Clinical Genomics Pedigree Topic includes the Family History Model describing a patient’s pedigree with genomic data. It has the ability to transmit complete family history information for clinical decision support.  This model is ANSI-approved and is the HITSP-accepted standard.  This standard allows EHR/PHR interoperability, and is in use by the Surgeon General in his family history collection website:  My Family Health Portrait. It is also in the process of becoming of an international standard through ISO.
+
DSTU, IG
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Documents'''
 
|
 
|
−
: c
+
HL7 IG for CDA R2: Quality Reporting Document Architecture (QRDA), R1
−
|
 
−
: d
 
 
|
 
|
−
From HIMSS 2009 <br/>
+
DSTU, IG
−
* [http://www.hl7.org/documentcenter/public/calendarofevents/himss/2009/presentations/HL7HIMSS%20Master_Pedigree_Family_History_Tue.pdf HL7 Pedigree Model for Family History]
 
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_Arden| Arden Syntax]]
+
Health Information '''''Exchange''''' Standards- '''Messages'''
 +
|
 +
HL7 V3: Claims & Reimbursement; Special Authorization, R1
 
|
 
|
−
The Arden Syntax for Medical Logic Modules (MLMs) is a language for representing and sharing medical knowledge among personnel, information systems and institutions.
+
DSTU
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Health Information '''''Exchange''''' Standards- '''Messages'''
 
|
 
|
−
: c
+
HL7 V3: Care Provisions, R1
−
|
 
−
: d
 
 
|
 
|
−
resources
+
DSTU
 
|
 
|
 
|-
 
|-
 
|
 
|
−
[[TSC_Product_List_CCOW | CCOW ]] – Clinical Context Management Specification
+
|}
 +
 
 +
 
 +
====Health Information '''''Knowledge Representation''''' Standards====
 +
{|border="1"
 +
|+Tentative Product List
 +
|-
 +
!width="10%"| Integration paradigm
 +
!width="15%"| Product
 +
!width="65%"| Summary
 +
 
 +
|-
 
|
 
|
−
Aimed at facilitating the integration of applications at the point of use, the Clinical Context Management Specification (CCOW) is an end-user-focused standard that complements HL7's traditional emphasis on data interchange and enterprise workflow, by synchronizing and coordinating applications so that they automati¬cally follow the user's context.
+
Health Information '''''Knowledge Representation''''' Standards
 
|
 
|
−
: a
+
[[TSC_Product_List_Arden| Arden Syntax]]
 
|
 
|
−
: b
+
The Arden Syntax for Medical Logic Modules (MLMs) is a language for representing and sharing medical knowledge among personnel, information systems and institutions.
 
|
 
|
−
: c
+
|-
−
|  
 
−
: d
 
 
|
 
|
−
resources
+
Health Information '''''Knowledge Representation''''' Standards
 
|
 
|
−
|-
+
[[TSC_Product_List_SPL| SPL]]
 
|
 
|
−
[[TSC_Product_List_CTS | CTS ]] Common Terminology Services
+
HL7 Version 3 Standard: Structured Product Labeling (SPL) defines the content of human prescription drug labeling in an XML format. This format is defined within the SPL schema and is displayed in a web browser using the SPL stylesheet. It is approved by Health Level Seven (HL7) and has been adopted by FDA as a mechanism for exchanging medication information. (from [http://en.wikipedia.org/wiki/Structured_Product_Labeling Wikipedia])
 
|
 
|
−
The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can be used by HL7 Version 3 software when accessing terminological content.
+
|-
 
|
 
|
−
The Common Terminology Services (CTS) specification was developed as an alterna¬tive to a common data structure. Instead of specifying what an external terminology must look like, HL7 has chosen to identify the common functional charac¬teristics that an external termi¬nology must be able to provide. As an example, an HL7 compli¬ant terminology service will need to be able to deter¬mine whether a given concept code is valid within the particular resource. Instead of describing a table keyed by the resource identifier and concept code, the CTS specification describes an Application Programming Interface (API) call that takes a resource identifier and concept code as input and returns a true/false value. Each terminology developer is free to implement this API call in whatever way is most appropriate for them.
+
Health Information '''''Knowledge Representation''''' Standards
 
|
 
|
−
: b
+
GELLO
 
|
 
|
−
: c
+
HL7 Version 3 Standard: GELLO, A Common Expression Language is intended to be a standard query and expression language for decision support. GELLO is a class-based, object-oriented (OO) language that is built on existing
−
|
+
standards. GELLO includes both query and expression sublanguages, which we refer to collectively as the GELLO language (for succinctness we will also refer to the two sublanguages simply as languages). GELLO is based on the Object Constraint Language (OCL), developed by the Object Management Group. Relevant components of OCL have
−
: d
+
been selected and integrated into the GELLO query and expression languages to provide a suitable framework for manipulation of clinical data for decision support in health care.
 +
The GELLO language can be used to:
 +
* Build up queries to extract and manipulate data from medical records.
 +
* Construct decision criteria by building up expressions to reason about particular data features/values. These criteria can be used in decision-support knowledge bases such as those designed to provide alerts and reminders, guidelines, or other decision rules.
 +
* Create expressions, formulae, and queries for other applications.
 
|
 
|
−
resources
+
|}
 +
 
 +
 
 +
 
 +
===='''''Modeling''''' Standards====
 +
{|border="1"
 +
|+Tentative Product List
 +
|-
 +
!width="10%"| Integration paradigm
 +
!width="15%"| Product
 +
!width="65%"| Summary
 +
 
 +
|-
 
|
 
|
−
|-
+
'''''Modeling Standards'''''
 
|
 
|
−
RIM
+
[[TSC_Product_List_RIM | RIM]]
 
|
 
|
 
The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. It is the combined consensus view of information from the perspective of the HL7 working group and the global HL7 affiliates. The RIM is the ultimate source from which all HL7 Version 3 protocol specification standards draw their information-related content.
 
The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. It is the combined consensus view of information from the perspective of the HL7 working group and the global HL7 affiliates. The RIM is the ultimate source from which all HL7 Version 3 protocol specification standards draw their information-related content.
 
|
 
|
−
The RIM is a static model of health and healthcare information as viewed within the scope of HL7 standards development activities. It is an object model and graphically represents the clinical data (domains) and identifies the life cycle of events that a message or groups of related messages will carry. As a shared model between all the domains and the model from which all domains create their messages, the RIM is essential to HL7’s ongoing mission of increasing precision of data. The RIM became an ANSI-approved standard in late 2003 and was published as an International Organization for Standardization (ISO) standard in September 2006.
+
|-
 
|
 
|
−
: b
+
'''''Modeling Standards''''' - V3 Foundational Vocabulary Domains 
 
|
 
|
−
: c
+
[[TSC_Product_List_CTS | CTS ]] Common Terminology Services
−
|  
 
−
: d
 
 
|
 
|
−
resources
+
The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can be used by HL7 Version 3 software when accessing terminological content.
 
|
 
|
 
|-
 
|-
 
|
 
|
−
XML Encoding Syntax for Version 2
+
'''''Modeling Standards'''''
 +
|
 +
HL7 EHR Lifecycle Model (EHR/LM), R1
 
|
 
|
−
HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix.
+
DSTU
 
|
 
|
−
: a
+
|}
 +
 
 +
 
 +
 
 +
 
 +
====Application '''''Functional Specifications'''''====
 +
{|border="1"
 +
|+Tentative Product List
 +
|-
 +
!width="10%"| Integration paradigm
 +
!width="15%"| Product
 +
!width="65%"| Summary
 +
 
 +
|-
 
|
 
|
−
: b
+
Application '''''Functional Specifications'''''
 
|
 
|
−
: c
+
[[TSC_Product_List_EHR_FM| EHR FM]]
−
|  
 
−
: d
 
 
|
 
|
−
resources
+
The healthcare industry will reap tremendous benefits by adopting a common standard for electronic health record systems (EHR-S). The HL7 EHR-S Functional Model outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. To date, HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting. The EHR-S Functional Model is also in the final stages of vetting as an international standard through ISO.
 
|
 
|
 
|-
 
|-
 
|
 
|
−
Practical Guide for SOA in Healthcare
+
Application '''''Functional Specifications'''''
 
|
 
|
−
The Practical Guide for SOA in Healthcare is an informative document that was produced jointly by the HL7 SOA Working Group in collaboration with the OMG Healthcare Domain Task Force under the auspices of the Healthcare Services Specification Project (HSSP). The Practical Guide was created to help assist organizations that are either considering or are doing projects involving SOA to make effective decisions and to understand how SOA might fit into their organizational landscape. Many people find that it difficult to determine “how to get started” and lack an approach for doing so— a void this document is hoping to address.
+
[[TSC_Product_List_PHR-S_FM| PHR-S FM]] - Personal Health Record System Functional Model
 
|
 
|
−
: a
+
The PHR-S FM defines the set of functions for Personal Health Record (PHR) systems and offers guidelines that facilitate health information exchange among different PHR systems and between PHR and Electronic Health Record systems. The PHR-S FM is was published as a Draft Standard for Trial Use (DSTU) in December 2008. During the period of trial use, consumers can begin requesting standards-based functionality when they select PHR systems for their use, vendors can begin incorporating the model’s requirements into their products and organizations that certify PHR systems can begin using the model’s conformance criteria for certification development and testing purposes. Groups such as the Certification Commission for Healthcare Information Technology (CCHIT) and the Centers for Medicare and Medicaid Services have already begun using components of the PHR-S FM
 
|
 
|
−
: b
+
|-
 
|
 
|
−
: c
+
Application '''''Functional Specifications''''' - '''Services (SOA)'''
−
|
 
−
: d
 
 
|
 
|
−
resources
+
[[TSC_Product_List_SFM#Product_Brief_-_Entity_Identification_Service_Functional_Model_.28EIS_SFM.29| Entity Identification Service Functional Model]] (EIS SFM)
 +
|
 +
The Entity Identification Service Functional Model (EIS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for managing identities, such as would be used in a Master Patient Index (MPI). Not limited to use for Patients, the EIS SFM can be equally applied to manage identities for staff, providers, facilities, or any other “entities” needing identity management. The EIS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG) whom has adopted a technical specification complementing this SFM.
 
|
 
|
 
|-
 
|-
 
|
 
|
−
Entity Identification Service Functional Model (EIS SFM)  
+
Application '''''Functional Specifications''''' - '''Services (SOA)'''
 +
|
 +
[[TSC_Product_List_SFM#Product_Brief_-_Retrieve.2C_Locate.2C_Update_Service_Functional_Model_.28RLUS_SFM.29| Retrieve, Locate, Update Service Functional Model]] (RLUS SFM)
 
|
 
|
−
The Entity Identification Service Functional Model (EIS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for managing identities, such as would be used in a Master Patient Index (MPI). Not limited to use for Patients, the EIS SFM can be equally applied to manage identities for staff, providers, facilities, or any other “entities” needing identity management. The EIS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG) whom has adopted a technical specification complementing this SFM.  
+
The Retrieve, Locate, Update Service Functional Model (RLUS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component capable of querying information and returning data and metadata between systems. Although fairly abstract in nature, RLUS is actually very simple to understand—it provides a generic query and retrieval mechanism that can be used for a multitude of information content via a standard access mechanism, promoting consistency within a heterogeneous environment.  
 
|
 
|
−
: a
+
|-
 
|
 
|
−
: b
+
Application '''''Functional Specifications'''''- '''Services (SOA)'''
 
|
 
|
−
: c
+
[[TSC_Product_List_SFM#Product_Brief_-_Decision_Support_Service_Functional_Model_.28DSS_SFM.29|Decision Support Service Functional Model]] (DSS SFM)
−
|  
 
−
: d
 
 
|
 
|
−
resources
+
The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.
 
|
 
|
 
|-
 
|-
 
|
 
|
−
Retrieve, Locate, Update Service Functional Model (RLUS SFM)
+
Application '''''Functional Specifications'''''- '''Services (SOA)'''
 +
|
 +
HL7 V3: Regulated Studies; Clinical Research Filtered Query (CRFQ) Service Functional Model (SFM), R1
 
|
 
|
−
The Retrieve, Locate, Update Service Functional Model (RLUS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component capable of querying information and returning data and metadata between systems. Although fairly abstract in nature, RLUS is actually very simple to understand—it provides a generic query and retrieval mechanism that can be used for a multitude of information content via a standard access mechanism, promoting consis¬tency within a heterogeneous environment.
+
DSTU
 
|
 
|
−
: a
+
|}
 +
 
 +
===='''''Visual Integration Messages'''''====
 +
{|border="1"
 +
|+Tentative Product List
 +
|-
 +
!width="10%"| Integration paradigm
 +
!width="15%"| Product
 +
!width="65%"| Summary
 +
 
 +
|-
 
|
 
|
−
: b
+
'''Visual Integration Messages '''
 
|
 
|
−
: c
+
[[TSC_Product_List_CCOW | CCOW ]] – Clinical Context Management Specification
−
|  
 
−
: d
 
 
|
 
|
−
resources
+
Aimed at facilitating the integration of applications at the point of use, the Clinical Context Management Specification (CCOW) is an end-user-focused standard that complements HL7's traditional emphasis on data interchange and enterprise workflow, by synchronizing and coordinating applications so that they automatically follow the user's context.
 
|
 
|
 +
|}
 +
 +
 +
 +
 +
====Other Products====
 +
{|border="1"
 +
|+Tentative Product List
 +
|-
 +
!width="10%"| Integration paradigm
 +
!width="15%"| Product
 +
!width="65%"| Summary
 +
 
|-
 
|-
 
|
 
|
−
Decision Support Service Functional Model (DSS SFM)
+
Messaging, Documents, Services (SOA)
 
|
 
|
−
The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first health¬care standards targeted to support a service-ori¬ented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.
+
[[TSC_Product_List_EAS| SAEAF]]
 
|
 
|
−
: a
+
The HL7 SOA-Aware Enterprise Architecture provides a framework for specification of standardized services that can be used by the HL7 community. It identifies artifacts and a constraint pattern that provides traceability from requirements. These specifications align with different levels of conformance that aid HL7 consumers in adopting standards in different contexts, and supports specific integration patterns between collaborators as they seek to achieve computable semantic interoperability.
 
|
 
|
−
: b
+
|-
 
|
 
|
−
: c
+
'''Services (SOA)'''
−
|
 
−
: d
 
 
|
 
|
−
resources
+
[[TSC_Product_List_PracGuidSOA | Practical Guide for SOA in Healthcare]]
 +
|
 +
The Practical Guide for SOA in Healthcare is an informative document that was produced jointly by the HL7 SOA Working Group in collaboration with the OMG Healthcare Domain Task Force under the auspices of the Healthcare Services Specification Project (HSSP). The Practical Guide was created to help assist organizations that are either considering or are doing projects involving SOA to make effective decisions and to understand how SOA might fit into their organizational landscape. Many people find that it difficult to determine “how to get started” and lack an approach for doing so— a void this document is hoping to address.
 
|
 
|
 +
|}

Latest revision as of 19:29, 9 June 2009

2009 TSC Product Visibility

Project Objectives and Deliverables

  1. Create workable definitions of HL7 PRODUCTS
    • DELIVERABLE: Draft material for the Web Site on Products (this page)
      • Health Information Exchange Standards
        • Messaging, Documents, and Services
      • Health Information Knowledge Representation Standards
        • Arden Syntax, SPL, GELLO
      • Modeling Standards
        • RIM, CTS, EHR Lifecycle FM
      • Application Functional Specifications
        • EHR-S FM, PHR-S FM, EIS SFM, RLUS SFM, DSS SFM, CRFQ SFM
      • Visual Integration Messages
        • Clinical Context Management Specification (CCOW)
      • Other
        • SAEAF, Practical Guide for SOA in Healthcare
      • Anticipate input from Education Committee, NHS Product Descriptions, WG having responsibility for product, and other sources
      • Define purpose and maintenance of categories list.
    • Evaluate future reference by Product to:
      • Standards and artifacts (what makes up this product),
      • projects (searchable database),
      • work groups (who works on what product),
      • users (I am a ___, how do these products meet my needs?),
      • and other organizations’ standards (JIC).
  2. Draft process for Governance of Products list: ongoing and annual review, maintenance, and endorsement of Product Definitions
    • New product request
    • Updates to products
    • Evaluate potential for expired products or standards
  3. Evaluate perception of ‘visibility’ (using a survey, perhaps)
    • Can “users of the standards” find what HL7 Products are available?
    • Validate perception of “who are our customers”,
    • Are we getting the word out? (Genomics, ICSR, CDA [vs XDS], Services)
    • Are we able to track what is needed in the market?

Project Dependencies and Relationships

  • Project Insight ID (PI ID) #404, also Roadmap Task #34: Document the various HL7 standards and their application to interoperability
  • PI ID # 413, also Roadmap Task #48: Develop an updated HL7 Product Strategy
  • PI ID # 412, also Roadmap Task #46: HL7 Standards and Implementation Guide Inventory Report
  • PI ID # 439, also Roadmap Task #37: HL7 Website to list HL7 IGs, scope, language, Affiliate, link, etc.

Product List (Tentative)

Health Information Exchange Standards

Tentative Product List
Integration paradigm Product Summary

Health Information Exchange Standards- Messaging

V3 - Version 3 Normative Edition

Version 3 is HL7’s family of standards developed with a model-driven methodology. The release of HL7’s Version 3 Normative Edition marks a quantum leap in the functionality and interoperability of messaging standards. Version 3 is one of the first in the industry to embrace XML. Several countries throughout the world have already begun significant Version 3 implementations, including the United Kingdom, Canada, the Netherlands, Mexico, Germany and Croatia.

Health Information Exchange Standards- Messaging

Clinical Genomics Pedigree Topic

The HL7 Clinical Genomics Pedigree Topic includes the Family History Model describing a patient’s pedigree with genomic data. It has the ability to transmit complete family history information for clinical decision support. This model is ANSI-approved and is the HITSP-accepted standard. This standard allows EHR/PHR interoperability, and is in use by the Surgeon General in his family history collection website: My Family Health Portrait. It is also in the process of becoming of an international standard through ISO.

Health Information Exchange Standards- Messaging

V2 Version 2 Messaging Standard

The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. First released in October 1987 as An Application Protocol for Electronic Data Exchange in Healthcare Environments, Version 2 is a messaging standard that allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Version 2.6, representing the latest update to the Version 2 Standard, was published in January 2008. Version 2.7 is in the final stages of balloting and is expected to be released later this year.

Health Information Exchange Standards- Messaging

XML Encoding Syntax for Version 2

HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix.

Health Information Exchange Standards- Documents

CDA

The Clinical Document Architecture (CDA) is a specification for the exchange of electronic clinical documents. It can contain coded data and narrative and is compatible with the electronic health record and document management systems. CDA is at the core of virtually all standards-based exchange networks in the US and abroad and is adaptable for dictated notes and highly-structured public health and quality reporting.

Health Information Exchange Standards- Documents

CCD

HL7 and ASTM International created the Continuity of Care Document (CCD) to integrate two complementary healthcare data specifications ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA). The CCD is endorsed by the Healthcare Information Technology Standards Panel (HITSP) as the harmonized format for the exchange of clinical information, including patient demographics, medications and allergies.

Health Information Exchange Standards- Documents

Claims Attachments

In response to the federal mandate under HIPAA, HL7 and ASCX12 collaborated for a number of years to develop standards for claims attachments. This joint development effort has resulted in standards for attachments to healthcare claims, and pre-certification / pre-authorization transactions. HL7 attachments standards are based on the Clinical Document Architecture (CDA) and have been proposed by the Department of Health and Human Services (HHS) as the standard for claims attachments under HIPAA. In the HHS proposal, six attachment types developed by HL7 have been put forward for adoption: clinical reports; rehabilitation services; laboratory results; medications; ambulance services; and emergency department. See HIMSS 2009 presentation on WPS case study

Health Information Exchange Standards

HL7 V3: Registries; Real Time Location Tracking, R1

DSTU

Health Information Exchange Standards

HL7 V3: Clinical Statement Pattern, R1

DSTU

Health Information Exchange Standards

HL7 V3: Reuseable Information Constraint Templates, R1

DSTU

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: Healthcare Associated Infection Reports, R1

DSTU, IG

Health Information Exchange Standards-

HL7 V3: Immunization, R1

DSTU

Health Information Exchange Standards- Messages

HL7 V3: Clinical Genomics; Genotype, R1

DSTU

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: Consult Notes, R1

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: History and Physical (H&P)

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: Reference Profile for EHR Interoperability, R1

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R1, Personal Healthcare Monitoring Report, R1

DSTU

Health Information Exchange Standards- Documents

HL7 IG for CDA R2, Operative Notes, R1

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R2, Level3: Healthcare Associated Infection Reports, R2 (US Realm)

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: CDA Framework for Questionnaire Assessments, R1

DSTU, IG

Health Information Exchange Standards - Services (SOA)

HL7 V3: Decision Support Service (DSS), R1

DSTU, IG

Health Information Exchange Standards- Documents

HL7 IG for CDA R2: Quality Reporting Document Architecture (QRDA), R1

DSTU, IG

Health Information Exchange Standards- Messages

HL7 V3: Claims & Reimbursement; Special Authorization, R1

DSTU

Health Information Exchange Standards- Messages

HL7 V3: Care Provisions, R1

DSTU


Health Information Knowledge Representation Standards

Tentative Product List
Integration paradigm Product Summary

Health Information Knowledge Representation Standards

Arden Syntax

The Arden Syntax for Medical Logic Modules (MLMs) is a language for representing and sharing medical knowledge among personnel, information systems and institutions.

Health Information Knowledge Representation Standards

SPL

HL7 Version 3 Standard: Structured Product Labeling (SPL) defines the content of human prescription drug labeling in an XML format. This format is defined within the SPL schema and is displayed in a web browser using the SPL stylesheet. It is approved by Health Level Seven (HL7) and has been adopted by FDA as a mechanism for exchanging medication information. (from Wikipedia)

Health Information Knowledge Representation Standards

GELLO

HL7 Version 3 Standard: GELLO, A Common Expression Language is intended to be a standard query and expression language for decision support. GELLO is a class-based, object-oriented (OO) language that is built on existing standards. GELLO includes both query and expression sublanguages, which we refer to collectively as the GELLO language (for succinctness we will also refer to the two sublanguages simply as languages). GELLO is based on the Object Constraint Language (OCL), developed by the Object Management Group. Relevant components of OCL have been selected and integrated into the GELLO query and expression languages to provide a suitable framework for manipulation of clinical data for decision support in health care. The GELLO language can be used to:

  • Build up queries to extract and manipulate data from medical records.
  • Construct decision criteria by building up expressions to reason about particular data features/values. These criteria can be used in decision-support knowledge bases such as those designed to provide alerts and reminders, guidelines, or other decision rules.
  • Create expressions, formulae, and queries for other applications.


Modeling Standards

Tentative Product List
Integration paradigm Product Summary

Modeling Standards

RIM

The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. It is the combined consensus view of information from the perspective of the HL7 working group and the global HL7 affiliates. The RIM is the ultimate source from which all HL7 Version 3 protocol specification standards draw their information-related content.

Modeling Standards - V3 Foundational Vocabulary Domains

CTS Common Terminology Services

The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can be used by HL7 Version 3 software when accessing terminological content.

Modeling Standards

HL7 EHR Lifecycle Model (EHR/LM), R1

DSTU



Application Functional Specifications

Tentative Product List
Integration paradigm Product Summary

Application Functional Specifications

EHR FM

The healthcare industry will reap tremendous benefits by adopting a common standard for electronic health record systems (EHR-S). The HL7 EHR-S Functional Model outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. To date, HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting. The EHR-S Functional Model is also in the final stages of vetting as an international standard through ISO.

Application Functional Specifications

PHR-S FM - Personal Health Record System Functional Model

The PHR-S FM defines the set of functions for Personal Health Record (PHR) systems and offers guidelines that facilitate health information exchange among different PHR systems and between PHR and Electronic Health Record systems. The PHR-S FM is was published as a Draft Standard for Trial Use (DSTU) in December 2008. During the period of trial use, consumers can begin requesting standards-based functionality when they select PHR systems for their use, vendors can begin incorporating the model’s requirements into their products and organizations that certify PHR systems can begin using the model’s conformance criteria for certification development and testing purposes. Groups such as the Certification Commission for Healthcare Information Technology (CCHIT) and the Centers for Medicare and Medicaid Services have already begun using components of the PHR-S FM

Application Functional Specifications - Services (SOA)

Entity Identification Service Functional Model (EIS SFM)

The Entity Identification Service Functional Model (EIS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for managing identities, such as would be used in a Master Patient Index (MPI). Not limited to use for Patients, the EIS SFM can be equally applied to manage identities for staff, providers, facilities, or any other “entities” needing identity management. The EIS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG) whom has adopted a technical specification complementing this SFM.

Application Functional Specifications - Services (SOA)

Retrieve, Locate, Update Service Functional Model (RLUS SFM)

The Retrieve, Locate, Update Service Functional Model (RLUS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component capable of querying information and returning data and metadata between systems. Although fairly abstract in nature, RLUS is actually very simple to understand—it provides a generic query and retrieval mechanism that can be used for a multitude of information content via a standard access mechanism, promoting consistency within a heterogeneous environment.

Application Functional Specifications- Services (SOA)

Decision Support Service Functional Model (DSS SFM)

The Decision Support Service Functional Model (DSS SFM) Draft Standard for Trial Use (DSTU) is a draft functional standard defining the functions, responsibilities, inputs, outputs, and expected behavior of a system component for evaluating patient data to reach patient-specific conclusions. A DSS, for example, can evaluate a patient’s health summary as encoded in a Continuity of Care Document (CCD) and provide structured recommendations regarding the patient’s health maintenance and chronic disease management needs. The DSS SFM is among the first healthcare standards targeted to support a service-oriented architecture (SOA), and is at the basis for an unprecedented collaboration with the Object Management Group (OMG), which has adopted a technical specification complementing this SFM.

Application Functional Specifications- Services (SOA)

HL7 V3: Regulated Studies; Clinical Research Filtered Query (CRFQ) Service Functional Model (SFM), R1

DSTU

Visual Integration Messages

Tentative Product List
Integration paradigm Product Summary

Visual Integration Messages

CCOW – Clinical Context Management Specification

Aimed at facilitating the integration of applications at the point of use, the Clinical Context Management Specification (CCOW) is an end-user-focused standard that complements HL7's traditional emphasis on data interchange and enterprise workflow, by synchronizing and coordinating applications so that they automatically follow the user's context.



Other Products

Tentative Product List
Integration paradigm Product Summary

Messaging, Documents, Services (SOA)

SAEAF

The HL7 SOA-Aware Enterprise Architecture provides a framework for specification of standardized services that can be used by the HL7 community. It identifies artifacts and a constraint pattern that provides traceability from requirements. These specifications align with different levels of conformance that aid HL7 consumers in adopting standards in different contexts, and supports specific integration patterns between collaborators as they seek to achieve computable semantic interoperability.

Services (SOA)

Practical Guide for SOA in Healthcare

The Practical Guide for SOA in Healthcare is an informative document that was produced jointly by the HL7 SOA Working Group in collaboration with the OMG Healthcare Domain Task Force under the auspices of the Healthcare Services Specification Project (HSSP). The Practical Guide was created to help assist organizations that are either considering or are doing projects involving SOA to make effective decisions and to understand how SOA might fit into their organizational landscape. Many people find that it difficult to determine “how to get started” and lack an approach for doing so— a void this document is hoping to address.

Retrieved from "https://tscwiki.hl7.org/w/index.php?title=2009_TSC_Product_Visibility&oldid=5027"