Jump to content

Health Level 7: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
→See also: per WP:SEEALSO, this section must not contain red links - the linked article was deleted 4 years ago
 
(39 intermediate revisions by 32 users not shown)
Line 1: Line 1:
{{short description|Set of standards for transfer of clinical and administrative data}}
{{Short description|Data sharing standards}}
{{About|the family of standards|the organization that created them|Health Level Seven International}}
{{About|the family of standards|the organization that created them|Health Level Seven International}}


⚫
'''Health Level Seven''', abbreviated to '''HL7''', is a range of global standards for the transfer of clinical and administrative health data between applications with the aim to improve patient outcomes and health system performance. The HL7 standards focus on the application layer, which is "layer 7" in the [[OSI model|Open Systems Interconnection model]]. The standards are produced by [[Health Level Seven International]], an international [[standards organization]], and are adopted by other standards issuing bodies such as [[ANSI|American National Standards Institute]] and [[ISO|International Organization for Standardization]]. There are a range of primary standards that are commonly used across the industry, as well as secondary standards which are less frequently adopted.


== Purpose ==
⚫
'''Health Level Seven''' or '''HL7''' refers to a set of international standards for transfer of clinical and administrative data between software applications used by various healthcare providers. These standards focus on the application layer, which is "layer 7" in the [[OSI model]]. The HL7 standards are produced by [[Health Level Seven International]], an international [[standards organization]], and are adopted by other standards issuing bodies such as [[ANSI|American National Standards Institute]] and [[ISO|International Organization for Standardization]].
⚫
Health organizations typically have many different computer systems used to process different patient administration or clinical tasks, such as billing, medication management, patient tracking, and documentation. All of these systems should communicate, or "interface", with each other when they receive new information or when they wish to retrieve information. [[Health Level Seven International|HL7 International]] specifies a number of flexible standards, guidelines, and methodologies by which these healthcare systems can communicate with each other. The standards allow for easier 'interoperability' of healthcare data as it is shared and processed uniformly and consistently by the different systems. This allows clinical and non-clinical data to be shared more easily, theoretically improving patient care and health system performance.<ref>{{cite book|author=Joel Rodrigues|title=Health Information Systems: Concepts, Methodologies, Tools, and Applications, Volume 1|url=https://books.google.com/books?id=WnBJsRtfVbYC&pg=PR39|publisher=IGI Global|isbn=978-1-60566-988-5|year=2010|page=xxxix}}</ref>

Hospitals and other healthcare provider organizations typically have many different computer systems used for everything from billing records to patient tracking. All of these systems should communicate with each other (or "interface") when they receive new information, or when they wish to retrieve information, but not all do so.

⚫
[[Health Level Seven International|HL7 International]] specifies a number of flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with each other. Such guidelines or data standards are a set of rules that allow information to be shared and processed in a uniform and consistent manner. These data standards are meant to allow healthcare organizations to easily share clinical information. Theoretically, this ability to exchange information should help to minimize the tendency for medical care to be geographically isolated and highly variable.<ref>{{cite book|author=Joel Rodrigues|title=Health Information Systems: Concepts, Methodologies, Tools, and Applications, Volume 1|url=https://books.google.com/books?id=WnBJsRtfVbYC&pg=PR39|publisher=IGI Global|isbn=978-1-60566-988-5|year=2010|page=xxxix}}</ref>


== Primary standards ==
[[Health Level Seven International|HL7 International]] considers the following standards to be its primary standards – those standards that are most commonly used and implemented:<ref name="HL7 Primary Standards">{{cite web|title=HL7 Primary Standards|url=http://www.hl7.org/implement/standards/product_section.cfm?section=1|publisher=[[Health Level Seven International]]}}</ref>
[[Health Level Seven International|HL7 International]] considers the following standards to be its primary standards – those standards that are most commonly used and implemented:<ref name="HL7 Primary Standards">{{cite web|title=HL7 Primary Standards|url=http://www.hl7.org/implement/standards/product_section.cfm?section=1|publisher=[[Health Level Seven International]]}}</ref>
* Version 2.x Messaging Standard – an interoperability specification for health and medical transactions
* Version 2.x Messaging Standard – an interoperability specification for health and medical transactions
Line 16: Line 15:
* [[Structured Product Labeling]] (SPL) – the published information that accompanies a medicine, based on HL7 Version 3
* [[Structured Product Labeling]] (SPL) – the published information that accompanies a medicine, based on HL7 Version 3
* [[Clinical Context Object Workgroup]] (CCOW) – an interoperability specification for the visual integration of user applications
* [[Clinical Context Object Workgroup]] (CCOW) – an interoperability specification for the visual integration of user applications

Other HL7 standards/methodologies include:<ref>{{cite web|title=HL7 Standards|url=http://www.hl7.org/implement/standards/index.cfm?ref=nav|publisher=[[Health Level Seven International]]}}</ref>
Other HL7 standards/methodologies include:<ref>{{cite web|title=HL7 Standards|url=http://www.hl7.org/implement/standards/index.cfm?ref=nav|publisher=[[Health Level Seven International]]}}</ref>
* [[Fast Healthcare Interoperability Resources]] (FHIR) – a standard for the exchange of resources
* [[Fast Healthcare Interoperability Resources]] (FHIR) – a standard for the exchange of resources
* [[Arden Syntax]] – a grammar for representing medical conditions and recommendations as a [[Medical logic module|Medical Logic Module]] (MLM)
* [[Arden Syntax]] – a grammar for representing medical conditions and recommendations as a [[Medical logic module|Medical Logic Module]] (MLM)
* Claims Attachments – a Standard Healthcare Attachment to augment another healthcare transaction
* Claims Attachments – a Standard Healthcare Attachment to augment another healthcare transaction
* Functional Specification of [[Electronic Health Record]] (EHR) / [[Personal health record|Personal Health Record]] (PHR) systems – a standardized description of health and medical functions sought for or available in such software applications
* Functional Specification of [[Electronic Health Record]] (EHR) and [[Personal health record|Personal Health Record]] (PHR) systems – a standardized description of health and medical functions sought for or available in such software applications
* [[Gello Expression Language|GELLO]] – a standard expression language used for clinical decision support
* [[Gello Expression Language|GELLO]] – a standard expression language used for clinical decision support


==Primary standards==
===HL7 Version 2===
{{Technical|date=April 2024|section}}
HL7's primary standards are those standards that [[Health Level Seven International]] considers to be most commonly used and implemented.<ref name="HL7 Primary Standards"/>

===Version 2 messaging===
The HL7 version 2 standard (also known as Pipehat) has the aim to support hospital workflows. It was originally created in 1989.<ref>{{cite web|title=HL7 FAQs|url=http://www.hl7.org/about/FAQs/index.cfm?ref=nav|publisher=[[HL7]]}}</ref>
The HL7 version 2 standard (also known as Pipehat) has the aim to support hospital workflows. It was originally created in 1989.<ref>{{cite web|title=HL7 FAQs|url=http://www.hl7.org/about/FAQs/index.cfm?ref=nav|publisher=[[HL7]]}}</ref>


HL7 version 2 defines a series of electronic messages to support administrative, logistical, financial as well as clinical processes. Since 1987 the standard has been updated regularly, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1 and 2.8.2. The v2.x standards are [[Backward compatibility|backward compatible]] (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6).
HL7 version 2 defines a series of electronic messages to support administrative, logistical, financial as well as clinical processes. Since 1987 the standard has been updated regularly, resulting in more than ten iterations. The v2.x standards are [[Backward compatibility|backward compatible]], meaning a message based on version 2.3 will be understood by an application that supports version 2.6.


HL7 v2.x messages use a non-[[XML]] encoding syntax based on segments ([[Line (text file)|line]]s) and one-character [[delimiter]]s.<ref>{{cite web|title=Understanding HL7 Messages|url=http://www.interfaceware.com/understanding_hl7_messages.html|publisher=iNTERFACEWARE}}</ref> Segments have composites ([[Field (computer science)|field]]s) separated by the composite delimiter. A composite can have sub-composites (components) separated by the sub-composite delimiter, and sub-composites can have sub-sub-composites (subcomponents) separated by the sub-sub-composite delimiter. The default delimiters are [[carriage return]] for the segment separator, vertical bar or pipe (<code>|</code>) for the field separator, caret (<code>^</code>) for the component separator, ampersand (<code>&</code>) for the subcomponent separator, and number sign (#) for the default truncation separator. The tilde (<code>~</code>) is the default repetition separator. Each segment starts with a 3-character string that identifies the segment type. Each segment of the message contains one specific category of information. Every message has <code>MSH</code> as its first segment, which includes a field that identifies the message type. The message type determines the expected segment types in the message.<ref>{{cite web|title=HL7 Messages and Descriptions|url=http://healthstandards.com/blog/2007/09/24/hl7-separator-characters/|publisher=Health Standards}}</ref> The segment types used in a particular message type are specified by the segment grammar notation used in the HL7 standards.
HL7 v2.x messages use a non-[[XML]] encoding syntax based on segments ([[Line (text file)|line]]s) and one-character [[delimiter]]s.<ref>{{cite web|title=Understanding HL7 Messages|url=http://www.interfaceware.com/understanding_hl7_messages.html|publisher=iNTERFACEWARE}}</ref> Segments have composites ([[Field (computer science)|field]]s) separated by the composite delimiter. A composite can have sub-composites (components) separated by the sub-composite delimiter, and sub-composites can have sub-sub-composites (subcomponents) separated by the sub-sub-composite delimiter. The default delimiters are [[carriage return]] for the segment separator, vertical bar or pipe (<code>|</code>) for the field separator, caret (<code>^</code>) for the component separator, ampersand (<code>&</code>) for the subcomponent separator, and number sign (#) for the default truncation separator. The tilde (<code>~</code>) is the default repetition separator. Each segment starts with a 3-character string that identifies the segment type. Each segment of the message contains one specific category of information. Every message has <code>MSH</code> as its first segment, which includes a field that identifies the message type. The message type determines the expected segment types in the message.<ref>{{cite web|title=HL7 Messages and Descriptions|url=http://healthstandards.com/blog/2007/09/24/hl7-separator-characters/|publisher=Health Standards}}</ref> The segment types used in a particular message type are specified by the segment grammar notation used in the HL7 standards.


The following is an example of an admission message. <code>MSH</code> is the header segment, <code>PID</code> the Patient Identity, <code>PV1</code> is the Patient Visit information, etc. The 2nd field in the <code>PID</code> segment is the patient's name, in the order, family name, given name, second names (or their initials), suffix, etc. Depending on the HL7 V2.x standard version, more fields are available in the segment for additional patient information.
The following is an example of an admission message. <code>MSH</code> is the header segment, <code>PID</code> the Patient Identity, <code>PV1</code> is the Patient Visit information, etc. The 5th field in the <code>PID</code> segment is the patient's name, in the order, family name, given name, second name (or their initials), suffix, etc. Depending on the HL7 V2.x standard version, more fields are available in the segment for additional patient information.


{{pre2|scroll|
{{pre|
<nowiki>MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5
<nowiki>MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5
EVN||200605290901||||200605290900
EVN||200605290901||||
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
Line 47: Line 44:
}}
}}


HL7 v2.x has allowed for the [[interoperability]] between electronic Patient Administration Systems (PAS), Electronic Practice Management (EPM) systems, Laboratory Information Systems (LIS), Dietary, Pharmacy and Billing systems as well as [[Electronic Medical Record]] (EMR) or [[Electronic Health Record]] (EHR) systems. Currently, the HL7 v2.x messaging standard is supported by every major medical information systems vendor in the United States.<ref>{{cite web|title=Standards Organizations|url=http://aspe.hhs.gov/sp/nhii/standards.html|publisher=Assistant Secretary for Planning and Evaluation (ASPE), [[Health and Human Services]] (HHS)}}</ref>
HL7 v2.x has allowed for the [[interoperability]] between the plethora of digital health systems, from Patient Administration Systems, to Electronic Health Records, and specialised Laboratory and Radiology Information Systems. Currently, the HL7 v2.x messaging standard is supported by every major health informatics vendor in the United States.<ref>{{cite web|title=Standards Organizations|url=http://aspe.hhs.gov/sp/nhii/standards.html|publisher=Assistant Secretary for Planning and Evaluation (ASPE), [[Health and Human Services]] (HHS)}}</ref>


===Version 3 messaging===
===HL7 Version 3===
The HL7 version 3 standard has the aim to support all healthcare workflows. Development of version 3 started around 1995, resulting in an initial standard publication in 2005. The v3 standard, as opposed to version 2, is based on a formal methodology (the HDF) and object-oriented principles.
The HL7 version 3 standard has the aim to support all healthcare workflows.<ref name="V3">{{cite web|title=HL7 V3 Standard - A High Level Overview|date=26 May 2020|url=https://saravanansubramanian.com/hl7V3intro/}}</ref> Development of version 3 started around 1995, resulting in an initial standard publication in 2005. The v3 standard, as opposed to version 2, is based on a formal methodology (the HDF) and object-oriented principles.


'''RIM - ISO/HL7 21731'''
'''RIM - ISO/HL7 21731'''
Line 58: Line 55:
'''HL7 Development Framework - [[International Organization for Standardization|ISO]]/HL7 27931'''
'''HL7 Development Framework - [[International Organization for Standardization|ISO]]/HL7 27931'''


The HL7 Version 3 Development Framework (HDF) is a continuously evolving process that seeks to develop specifications that facilitate interoperability between healthcare systems. The HL7 RIM, vocabulary specifications, and model-driven process of analysis and design combine to make HL7 Version 3 one methodology for development of consensus-based standards for healthcare information system [[interoperability]]. The HDF is the most current edition of the HL7 V3 development methodology.
The HL7 Version 3 Development Framework (HDF) is a continuously evolving process that seeks to develop specifications that facilitate interoperability between healthcare systems. The HL7 RIM, vocabulary specifications, and model-driven process of analysis and design combine to make HL7 Version 3 one methodology for the development of consensus-based standards for healthcare information systems [[interoperability]]. The HDF is the most current edition of the HL7 V3 development methodology.


The HDF not only documents messaging, but also the processes, tools, actors, rules, and artifacts relevant to development of all HL7 standard specifications. Eventually, the HDF will encompass all of the HL7 standard specifications, including any new standards resulting from analysis of electronic health record architectures and requirements.
The HDF not only documents messaging, but also the processes, tools, actors, rules, and artifacts relevant to the development of all HL7 standard specifications. Eventually, the HDF will encompass all of the HL7 standard specifications, including any new standards resulting from the analysis of electronic health record architectures and requirements.


HL7 specifications draw upon codes and vocabularies from a variety of sources. The V3 vocabulary work ensures that the systems implementing HL7 specifications have an unambiguous understanding of the code sources and code value domains they are using.
HL7 specifications draw upon codes and vocabularies from a variety of sources. The V3 vocabulary work ensures that the systems implementing HL7 specifications have an unambiguous understanding of the code sources and code value domains they are using.
Line 68: Line 65:
The HL7 version 3 messaging standard defines a series of Secure Text messages (called ''interactions'') to support all healthcare workflows.
The HL7 version 3 messaging standard defines a series of Secure Text messages (called ''interactions'') to support all healthcare workflows.


HL7 v3 messages are based on an XML encoding syntax, as shown in this example:<ref>{{cite web|editor-last=Spronk|editor-first=René|title=HL7 Message examples: version 2 and version 3|url=http://www.ringholm.de/docs/04300_en.htm|work=Ringholm|publisher=Ringholm bv|date=16 November 2007|ref=harv}}</ref>{{rp|2.2.1}}
HL7 v3 messages are based on an XML encoding syntax, as shown in this example:<ref>{{cite web|editor-last=Spronk|editor-first=René|title=HL7 Message examples: version 2 and version 3|url=http://www.ringholm.de/docs/04300_en.htm|work=Ringholm|publisher=Ringholm bv|date=16 November 2007}}</ref>{{rp|2.2.1}}


<!--Sample code from Spronk 2007, CC BY-SA 3.0-->
<!--Sample code from Spronk 2007, CC BY-SA 3.0-->
Line 105: Line 102:
</POLB_IN224200></syntaxhighlight>
</POLB_IN224200></syntaxhighlight>


===Clinical Document Architecture (CDA)===
===Clinical Document Architecture===
{{main|Clinical Document Architecture}}
{{main|Clinical Document Architecture}}


The HL7 [[Clinical Document Architecture]] (CDA) is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange.<ref>{{cite book|title=The CDA Book|url=https://books.google.com/books?id=rwa6DDB4jY8C}}</ref> The standard was jointly published with ISO as ISO/HL7 27932.
The HL7 [[Clinical Document Architecture]] (CDA) is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange.<ref>{{cite book|title=The CDA Book|isbn = 9780857293367|url=https://books.google.com/books?id=rwa6DDB4jY8C|last1 = Boone|first1 = Keith W.|date = 20 May 2011| publisher=Springer }}</ref> The standard was jointly published with ISO as ISO/HL7 27932.


===Continuity of Care Document (CCD)===
===Continuity of Care Document===
{{main|Continuity of Care Document}}
{{main|Continuity of Care Document}}
CCD is a US specification for the exchange of medical summaries, based on CDA.
The Continuity of Care Document framework is a US-specific standard for the exchange of medical summaries, based on the Clinical Document Architecture standard.


===Structured Product Labeling (SPL)===
===Structured Product Labeling===
{{main|Structured Product Labeling}}
{{main|Structured Product Labeling}}


SPL describes the published information that accompanies a medicine, based on HL7 Version 3.
Structured Product Labeling describes the published information that accompanies a medicine, based on HL7 Version 3.


===Clinical Context Object Workgroup===
===CCOW===
{{main|CCOW}}
{{main|CCOW}}
[[CCOW]], or "Clinical Context Object Workgroup," is a standard protocol designed to enable disparate applications to share user context and patient context in real-time, and at the user-interface level. CCOW implementations typically require a CCOW vault system to manage user security between applications.
[[CCOW]], or "Clinical Context Object Workgroup," is a standard protocol designed to enable disparate applications to share user context and patient context in real-time, and at the user-interface level. CCOW implementations typically require a CCOW vault system to manage user security between applications.
Line 126: Line 123:


===Fast Healthcare Interoperability Resources (FHIR)===
===Fast Healthcare Interoperability Resources (FHIR)===
{{main|Fast Healthcare Interoperability Resources}}
{{main|Fast Healthcare Interoperability Resources}}{{Update section|date=April 2024|reason=FHIR has matured significantly and is now at version 5 of the specification.}}
Fast Healthcare Interoperability Resources is a draft standard from [[Health Level Seven International|HL7 International]] designed to be easier to implement, more open and more extensible than version 2.x or version 3. It leverages a modern web-based suite of API technology, including a [[HTTP]]-based [[RESTful]] protocol, [[HTML]] and [[Cascading Style Sheets]] for user interface integration, a choice of [[JSON]] or [[XML]] for data representation, [[OAuth]] for authorization and [[ATOM]] for query results.<ref name=forbes>{{cite news
Fast Healthcare Interoperability Resources is a modern interoperability specification from [[Health Level Seven International|HL7 International]] designed to be easier to implement, more open, and more extensible than HL7 versions 2.x or 3.x. It leverages a modern web-based suite of API technology, including a [[HTTP]]-based [[RESTful]] protocol, [[HTML]] and [[Cascading Style Sheets]] for user interface integration, a choice of [[JSON]] or [[XML]] for data representation, [[OAuth]] for authorization and [[Atom (web standard)|ATOM]] for query results.<ref name="forbes">{{cite news
| url=https://www.forbes.com/sites/danmunro/2014/03/30/setting-healthcare-interop-on-fire/
| url=https://www.forbes.com/sites/danmunro/2014/03/30/setting-healthcare-interop-on-fire/
| title=Setting Healthcare Interop On Fire
| title=Setting Healthcare Interop On Fire
Line 133: Line 130:
| author=Dan Munro
| author=Dan Munro
| date=2014-03-30
| date=2014-03-30
| accessdate=2014-11-22 }}
| access-date=2014-11-22 }}
</ref> The main purpose of the FHIR standard is to ensure interoperability between different computer systems. It defines the data format and protocol for exchanging medical information, regardless of how it is stored in these systems.<ref>{{cite journal
</ref>
|last1=Kryszyn |first1=Jacek
|last2=Smolik |first2=Waldemar T.
|last3=Wanta |first3=Damian
|last4=Midura |first4=Mateusz
|last5=Wróblewski |first5=Przemysław
|journal=International Journal of Electronics and Telecommunications
|title=Comparison of OpenEHR and HL7 FHIR Standards
|url=https://journals.pan.pl/dlibra/publication/144330/edition/126538/content
|date=2023 |volume=69 |issue=1 |pages=47–52
|doi=10.24425/ijet.2023.144330
|access-date=2024-01-08}}</ref>


===Services Aware Interoperability Framework===
===Services Aware Interoperability Framework===
Line 141: Line 149:
The HL7 Services-Aware Enterprise Architecture Framework (SAIF) provides consistency between all HL7 artifacts, and enables a standardized approach to Enterprise Architecture (EA) development and implementation, and a way to measure the consistency.
The HL7 Services-Aware Enterprise Architecture Framework (SAIF) provides consistency between all HL7 artifacts, and enables a standardized approach to Enterprise Architecture (EA) development and implementation, and a way to measure the consistency.


SAIF is a way of thinking about producing specifications that explicitly describe the governance, conformance, compliance, and behavioral semantics that are needed to achieve computable semantic working interoperability. The intended information transmission technology might use a messaging, document exchange, or services approach.
SAIF is a way of thinking about producing specifications that explicitly describe the governance, conformance, compliance, and behavioral semantics that are needed to achieve computable semantic working interoperability. The intended information transmission technology might use a messaging, document exchange, or service approach.


SAIF is the framework that is required to rationalize interoperability of other standards. SAIF is an architecture for achieving interoperability, but it is not a whole-solution design for enterprise architecture management.
SAIF is the framework that is required to rationalize interoperability of other standards. SAIF is an architecture for achieving interoperability, but it is not a whole-solution design for enterprise architecture management.
Line 148: Line 156:
{{main|Arden syntax}}
{{main|Arden syntax}}
The [[Arden syntax]] is a language for encoding medical knowledge. [[Health Level Seven International|HL7 International]] adopted and oversees the standard beginning with Arden syntax 2.0. These [[Medical logic module|Medical Logic Modules]] ([[Medical logic module|MLM]]s) are used in the clinical setting as they can contain sufficient knowledge to make single medical decisions.{{Citation needed|date=August 2007}} They can produce alerts, diagnoses, and interpretations along with quality assurance function and administrative support. An [[Medical logic module|MLM]] must run on a computer that meets the minimum system requirements and has the correct program installed. Then, the MLM can give advice for when and where it is needed.
The [[Arden syntax]] is a language for encoding medical knowledge. [[Health Level Seven International|HL7 International]] adopted and oversees the standard beginning with Arden syntax 2.0. These [[Medical logic module|Medical Logic Modules]] ([[Medical logic module|MLM]]s) are used in the clinical setting as they can contain sufficient knowledge to make single medical decisions.{{Citation needed|date=August 2007}} They can produce alerts, diagnoses, and interpretations along with quality assurance function and administrative support. An [[Medical logic module|MLM]] must run on a computer that meets the minimum system requirements and has the correct program installed. Then, the MLM can give advice for when and where it is needed.

===Clinical Quality Language===
'''Clinical Quality Language''' (CQL) is a [[ANSI]] certified<ref>{{Cite web|url=https://cql.hl7.org/|title=Clinical Quality Language (CQL)|website=cql.hl7.org}}</ref> clinically focused high-level expression language standard curated by Health Level 7.<ref>{{Cite web|url=https://cql.hl7.org/01-introduction.html|title=1. Introduction|website=cql.hl7.org}}</ref> It is designated for clinical knowledge sharing in the domains of electronic clinical quality measurement and [[Clinical decision support system|clinical decision support]].<ref>{{Cite web|url=https://ecqi.healthit.gov/cql|title=CQL - Clinical Quality Language &#124; eCQI Resource Center|website=ecqi.healthit.gov}}</ref>

Clinical quality language is being used for a variety of clinical applications including [[World Health Organization|WHO]] SMART guidelines where it is used for encoding decision logic and performance indicators.<ref>{{Cite web|url=https://www.who.int/tools/CCC/l3-implementation-guide|title=L3 Implementation Guide|website=www.who.int}}</ref> The [[Centers for Medicare & Medicaid Services]] adopted CQL for clinical quality measure specifications since 2019.<ref name="cms" /><ref>[https://www.jointcommission.org/measurement/pioneers-in-quality/pioneers-in-quality-resources/piq-expert-to-expert-series/-/media/22f989e00f4e4492abc04ad2b6049e5d.ashx Pioneers in Quality. Electronic Clinical Quality Measure (eCQM). Clinical Quality Language (CQL) Basics for Hospitals] jointcommission.org</ref>

CQL allows modular and flexible expression of logic and is both human-readable and machine processable.<ref name="cms">[https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/MMS/Downloads/Overview-of-Technical-Specifications-for-electronic-Clinical-Quality-Measures-eCQMs.pdf Measures management system] cms.gov Retrieved 3 April 2024</ref>

An implementation of CQL was [[Open-source software|open sourced]] and published by the [[National Committee for Quality Assurance]] in 2023 with the aim of encouraging adoption of the language.<ref>{{Cite web|url=https://www.hcinnovationgroup.com/policy-value-based-care/value-based-care-quality-measurement/news/53060218/ncqa-makes-clinical-quality-language-software-open-source|title=NCQA Makes Clinical Quality Language Software Open Source|first=David|last=Raths|date=May 11, 2023|website=Healthcare Innovation}}</ref>


===MLLP===
===MLLP===
A large portion of HL7 messaging is transported by Minimal Lower Layer Protocol (MLLP), also known as Lower Layer Protocol (LLP).<ref>{{cite web|title=LLP - Lower Layer Protocol|url=http://www.interfaceware.com/llp.html|publisher=iNTERFACEWARE}}</ref> For transmitting via TCP/IP, header and trailer characters are added to the message to identify the beginning and ending of the message because TCP/IP is a continuous stream of bytes. Hybrid Lower Layer Protocol (HLLP) is a variation of MLLP that includes a checksum to help verify message integrity. Amongst other software vendors, MLLP is supported by Microsoft,<ref>{{cite web|title=MLLP Receive and Send Components|url=http://msdn.microsoft.com/en-us/library/ee409260%28BTS.10%29.aspx|publisher=[[MSDN]]}}</ref> Oracle<ref>{{cite web|title=Oracle Application Server Integration B2B User's Guide, Supported Protocols|url=http://download.oracle.com/docs/cd/B14099_19/integrate.1012/b19370/supp_protos.htm#BACIFDJG|publisher=[[Oracle Corporation|Oracle]]}}</ref> and [[Cleo (company)|Cleo]].<ref>{{cite web|title=Which Secure Managed File Transfer Protocol is Right for You?|url=https://www.cleo.com/solutions/compare-protocols/|publisher=[[Cleo (company)|Cleo]]|access-date=2015-01-23|archive-url=https://web.archive.org/web/20150607155326/http://www.cleo.com/solutions/compare-protocols/|archive-date=2015-06-07|url-status=dead}}</ref>
A large portion of HL7 messaging is transported by Minimal Lower Layer Protocol (MLLP), also known as Lower Layer Protocol (LLP)<ref>{{cite web|title=LLP - Lower Layer Protocol|url=http://www.interfaceware.com/llp.html|publisher=iNTERFACEWARE}}</ref> or Minimum Layer Protocol (MLP).<ref>{{cite web|title=Minimum Layer Protocol|date=13 January 2020|url=https://www.lyniate.com/knowledge-hub/mlp-minimum-layer-protocol|publisher=LYNIATE}}</ref> For transmitting via TCP/IP, header and trailer characters are added to the message to identify the beginning and ending of the message because TCP/IP is a continuous stream of bytes.<ref name="mllp-spec">{{cite web |last1=Spronk |first1=Rene |title=Transport Specification: MLLP, Release 1 |url=https://www.hl7.org/documentcenter/public/wg/inm/mllp_transport_specification.PDF |website=hl7.org |publisher=Health Level Seven Inc. |access-date=5 September 2022}}</ref> Hybrid Lower Layer Protocol (HLLP) is a variation of MLLP that includes a checksum to help verify message integrity. Amongst other software vendors, MLLP is supported by Microsoft,<ref>{{cite web|title=MLLP Receive and Send Components|url=http://msdn.microsoft.com/en-us/library/ee409260%28BTS.10%29.aspx|publisher=[[MSDN]]}}</ref> Oracle,<ref>{{cite web|title=Oracle Application Server Integration B2B User's Guide, Supported Protocols|url=http://download.oracle.com/docs/cd/B14099_19/integrate.1012/b19370/supp_protos.htm#BACIFDJG|publisher=[[Oracle Corporation|Oracle]]}}</ref> [[Cleo (company)|Cleo]].<ref>{{cite web|title=Which Secure Managed File Transfer Protocol is Right for You?|url=https://www.cleo.com/solutions/compare-protocols/|publisher=[[Cleo (company)|Cleo]]|access-date=2015-01-23|archive-url=https://web.archive.org/web/20150607155326/http://www.cleo.com/solutions/compare-protocols/|archive-date=2015-06-07|url-status=dead}}</ref>

MLLP contains no inherent security or encryption but relies on lower layer protocols such as [[Transport Layer Security]] (TLS) or [[IPsec]] for safeguarding [[Protected health information]] outside of a secure network.


===Functional EHR and PHR specifications===
===Functional EHR and PHR specifications===
Line 158: Line 177:


===The OBR segment===
===The OBR segment===
An OBR Segment carries information about an exam, diagnostic study/observation.<ref>{{cite web|title=The HL7 OBR segment|url=https://corepointhealth.com/resource-center/hl7-resources/hl7-obr-segment/|publisher=Corepoint Health | accessdate=2018-11-13}}</ref> It is a required segment in an ORM (order message)<ref>{{Cite web|url=https://www.hl7.org/documentcenter/public/calendarofevents/FirstTime/Glossary%20of%20terms.pdf|title=HL7 Glossary of Terms|website=www.hl7.org|access-date=2018-11-13}}</ref> or an ORU (Observation Result) message<ref>{{cite web|url=http://healthstandards.com/blog/2006/10/05/what-is-an-oru-message/|title=What Is an ORU Message?|publisher=Health Standards|accessdate=2018-11-13}}</ref>.
An OBR Segment carries information about an exam, diagnostic study/observation.<ref>{{cite web|title=The HL7 OBR segment|url=https://corepointhealth.com/resource-center/hl7-resources/hl7-obr-segment/|publisher=Corepoint Health|access-date=2018-11-13|archive-date=2019-06-18|archive-url=https://web.archive.org/web/20190618065730/https://corepointhealth.com/resource-center/hl7-resources/hl7-obr-segment/|url-status=dead}}</ref> It is a required segment in an ORM (order message)<ref>{{Cite web|url=https://www.hl7.org/documentcenter/public/calendarofevents/FirstTime/Glossary%20of%20terms.pdf|title=HL7 Glossary of Terms|website=www.hl7.org|access-date=2018-11-13}}</ref> or an ORU (Observation Result) message.<ref>{{cite web|url=http://healthstandards.com/blog/2006/10/05/what-is-an-oru-message/|title=What Is an ORU Message?|publisher=Health Standards|access-date=2018-11-13}}</ref>


==See also==
==See also==
Line 171: Line 190:
* [[Health Informatics]]
* [[Health Informatics]]
* [[Health Informatics Service Architecture]] (HISA)
* [[Health Informatics Service Architecture]] (HISA)
* [[Healthcare Services Specification Project]] (HSSP)
* [[Integrating the Healthcare Enterprise|Integrating the Healthcare Enterprise(IHE)]]
* [[Integrating the Healthcare Enterprise|Integrating the Healthcare Enterprise(IHE)]]
* [[ISO TC 215]]
* [[ISO TC 215]]
* [[LOINC]]
* [[LOINC]]
* [[NextGen Connect]]
* [[NextGen Connect]]
* [[openEHR|openEHR Foundation]]
* [[Public Health Information Network]]
* [[Public Health Information Network]]
* [[SNOMED]], [[SNOMED CT]]
* [[SNOMED]] and [[SNOMED CT]]
* [[NPU terminology|Nomenclature for Properties and Units terminology]]


==References==
==References==
Line 207: Line 223:


[[Category:International standards]]
[[Category:International standards]]
[[Category:Multi-agent systems]]
[[Category:Agent-based software]]
[[Category:ANSI standards]]
[[Category:American National Standards Institute standards]]
[[Category:Standards for electronic health records]]
[[Category:Standards for electronic health records]]
[[Category:Data coding framework]]
[[Category:Data coding framework]]
[[Category:Health informatics]]

Latest revision as of 19:09, 29 September 2024

This article is about the family of standards. For the organization that created them, see Health Level Seven International.

Health Level Seven, abbreviated to HL7, is a range of global standards for the transfer of clinical and administrative health data between applications with the aim to improve patient outcomes and health system performance. The HL7 standards focus on the application layer, which is "layer 7" in the Open Systems Interconnection model. The standards are produced by Health Level Seven International, an international standards organization, and are adopted by other standards issuing bodies such as American National Standards Institute and International Organization for Standardization. There are a range of primary standards that are commonly used across the industry, as well as secondary standards which are less frequently adopted.

Purpose

[edit]

Health organizations typically have many different computer systems used to process different patient administration or clinical tasks, such as billing, medication management, patient tracking, and documentation. All of these systems should communicate, or "interface", with each other when they receive new information or when they wish to retrieve information. HL7 International specifies a number of flexible standards, guidelines, and methodologies by which these healthcare systems can communicate with each other. The standards allow for easier 'interoperability' of healthcare data as it is shared and processed uniformly and consistently by the different systems. This allows clinical and non-clinical data to be shared more easily, theoretically improving patient care and health system performance.[1]

Primary standards

[edit]

HL7 International considers the following standards to be its primary standards – those standards that are most commonly used and implemented:[2]

  • Version 2.x Messaging Standard – an interoperability specification for health and medical transactions
  • Version 3 Messaging Standard – an interoperability specification for health and medical transactions
  • Clinical Document Architecture (CDA) – an exchange model for clinical documents, based on HL7 Version 3
  • Continuity of Care Document (CCD) – a US specification for the exchange of medical summaries, based on CDA.
  • Structured Product Labeling (SPL) – the published information that accompanies a medicine, based on HL7 Version 3
  • Clinical Context Object Workgroup (CCOW) – an interoperability specification for the visual integration of user applications

Other HL7 standards/methodologies include:[3]

HL7 Version 2

[edit]

The HL7 version 2 standard (also known as Pipehat) has the aim to support hospital workflows. It was originally created in 1989.[4]

HL7 version 2 defines a series of electronic messages to support administrative, logistical, financial as well as clinical processes. Since 1987 the standard has been updated regularly, resulting in more than ten iterations. The v2.x standards are backward compatible, meaning a message based on version 2.3 will be understood by an application that supports version 2.6.

HL7 v2.x messages use a non-XML encoding syntax based on segments (lines) and one-character delimiters.[5] Segments have composites (fields) separated by the composite delimiter. A composite can have sub-composites (components) separated by the sub-composite delimiter, and sub-composites can have sub-sub-composites (subcomponents) separated by the sub-sub-composite delimiter. The default delimiters are carriage return for the segment separator, vertical bar or pipe (|) for the field separator, caret (^) for the component separator, ampersand (&) for the subcomponent separator, and number sign (#) for the default truncation separator. The tilde (~) is the default repetition separator. Each segment starts with a 3-character string that identifies the segment type. Each segment of the message contains one specific category of information. Every message has MSH as its first segment, which includes a field that identifies the message type. The message type determines the expected segment types in the message.[6] The segment types used in a particular message type are specified by the segment grammar notation used in the HL7 standards.

The following is an example of an admission message. MSH is the header segment, PID the Patient Identity, PV1 is the Patient Visit information, etc. The 5th field in the PID segment is the patient's name, in the order, family name, given name, second name (or their initials), suffix, etc. Depending on the HL7 V2.x standard version, more fields are available in the segment for additional patient information. 

MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5
EVN||200605290901||||
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F
OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F
AL1|1||^ASPIRIN
DG1|1||786.50^CHEST PAIN, UNSPECIFIED^I9|||A

HL7 v2.x has allowed for the interoperability between the plethora of digital health systems, from Patient Administration Systems, to Electronic Health Records, and specialised Laboratory and Radiology Information Systems. Currently, the HL7 v2.x messaging standard is supported by every major health informatics vendor in the United States.[7]

HL7 Version 3

[edit]

The HL7 version 3 standard has the aim to support all healthcare workflows.[8] Development of version 3 started around 1995, resulting in an initial standard publication in 2005. The v3 standard, as opposed to version 2, is based on a formal methodology (the HDF) and object-oriented principles.

RIM - ISO/HL7 21731

The Reference Information Model[9] (RIM) is the cornerstone of the HL7 Version 3 development process and an essential part of the HL7 V3 development methodology. RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.[10]

HL7 Development Framework - ISO/HL7 27931

The HL7 Version 3 Development Framework (HDF) is a continuously evolving process that seeks to develop specifications that facilitate interoperability between healthcare systems. The HL7 RIM, vocabulary specifications, and model-driven process of analysis and design combine to make HL7 Version 3 one methodology for the development of consensus-based standards for healthcare information systems interoperability. The HDF is the most current edition of the HL7 V3 development methodology.

The HDF not only documents messaging, but also the processes, tools, actors, rules, and artifacts relevant to the development of all HL7 standard specifications. Eventually, the HDF will encompass all of the HL7 standard specifications, including any new standards resulting from the analysis of electronic health record architectures and requirements.

HL7 specifications draw upon codes and vocabularies from a variety of sources. The V3 vocabulary work ensures that the systems implementing HL7 specifications have an unambiguous understanding of the code sources and code value domains they are using.

V3 Messaging

The HL7 version 3 messaging standard defines a series of Secure Text messages (called interactions) to support all healthcare workflows.

HL7 v3 messages are based on an XML encoding syntax, as shown in this example:[11]: 2.2.1  

<POLB_IN224200 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <id root="2.16.840.1.113883.19.1122.7" extension="CNTRL-3456"/>
  <creationTime value="200202150930-0400"/>
  <!-- The version of the datatypes/RIM/vocabulary used is that of May 2006 -->
  <versionCode code="2006-05"/>
  <!-- interaction id= Observation Event Complete, w/o Receiver Responsibilities -->
  <interactionId root="2.16.840.1.113883.1.6" extension="POLB_IN224200"/>
  <processingCode code="P"/>
  <processingModeCode nullFlavor="OTH"/>
  <acceptAckCode code="ER"/>
  <receiver typeCode="RCV">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id extension="GHH LAB" root="2.16.840.1.113883.19.1122.1"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="ELAB-3"/>
        </location>
      </asLocatedEntity>
    </device>
  </receiver>
  <sender typeCode="SND">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id root="2.16.840.1.113883.19.1122.1" extension="GHH OE"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="BLDG24"/>
        </location>
      </asLocatedEntity>
    </device>
  </sender>
  <!-- Trigger Event Control Act & Domain Content -->
</POLB_IN224200>

Clinical Document Architecture

[edit]
Main article: Clinical Document Architecture

The HL7 Clinical Document Architecture (CDA) is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange.[12] The standard was jointly published with ISO as ISO/HL7 27932.

Continuity of Care Document

[edit]
Main article: Continuity of Care Document

The Continuity of Care Document framework is a US-specific standard for the exchange of medical summaries, based on the Clinical Document Architecture standard.

Structured Product Labeling

[edit]
Main article: Structured Product Labeling

Structured Product Labeling describes the published information that accompanies a medicine, based on HL7 Version 3.

Clinical Context Object Workgroup

[edit]
Main article: CCOW

CCOW, or "Clinical Context Object Workgroup," is a standard protocol designed to enable disparate applications to share user context and patient context in real-time, and at the user-interface level. CCOW implementations typically require a CCOW vault system to manage user security between applications.

Other standards and methods

[edit]

Fast Healthcare Interoperability Resources (FHIR)

[edit]
Main article: Fast Healthcare Interoperability Resources

Fast Healthcare Interoperability Resources is a modern interoperability specification from HL7 International designed to be easier to implement, more open, and more extensible than HL7 versions 2.x or 3.x. It leverages a modern web-based suite of API technology, including a HTTP-based RESTful protocol, HTML and Cascading Style Sheets for user interface integration, a choice of JSON or XML for data representation, OAuth for authorization and ATOM for query results.[13] The main purpose of the FHIR standard is to ensure interoperability between different computer systems. It defines the data format and protocol for exchanging medical information, regardless of how it is stored in these systems.[14]

Services Aware Interoperability Framework

[edit]
Main article: HL7 Services Aware Interoperability Framework

The HL7 Services-Aware Enterprise Architecture Framework (SAIF) provides consistency between all HL7 artifacts, and enables a standardized approach to Enterprise Architecture (EA) development and implementation, and a way to measure the consistency.

SAIF is a way of thinking about producing specifications that explicitly describe the governance, conformance, compliance, and behavioral semantics that are needed to achieve computable semantic working interoperability. The intended information transmission technology might use a messaging, document exchange, or service approach.

SAIF is the framework that is required to rationalize interoperability of other standards. SAIF is an architecture for achieving interoperability, but it is not a whole-solution design for enterprise architecture management.

Arden syntax

[edit]
Main article: Arden syntax

The Arden syntax is a language for encoding medical knowledge. HL7 International adopted and oversees the standard beginning with Arden syntax 2.0. These Medical Logic Modules (MLMs) are used in the clinical setting as they can contain sufficient knowledge to make single medical decisions.[citation needed] They can produce alerts, diagnoses, and interpretations along with quality assurance function and administrative support. An MLM must run on a computer that meets the minimum system requirements and has the correct program installed. Then, the MLM can give advice for when and where it is needed.

Clinical Quality Language

[edit]

Clinical Quality Language (CQL) is a ANSI certified[15] clinically focused high-level expression language standard curated by Health Level 7.[16] It is designated for clinical knowledge sharing in the domains of electronic clinical quality measurement and clinical decision support.[17]

Clinical quality language is being used for a variety of clinical applications including WHO SMART guidelines where it is used for encoding decision logic and performance indicators.[18] The Centers for Medicare & Medicaid Services adopted CQL for clinical quality measure specifications since 2019.[19][20]

CQL allows modular and flexible expression of logic and is both human-readable and machine processable.[19]

An implementation of CQL was open sourced and published by the National Committee for Quality Assurance in 2023 with the aim of encouraging adoption of the language.[21]

MLLP

[edit]

A large portion of HL7 messaging is transported by Minimal Lower Layer Protocol (MLLP), also known as Lower Layer Protocol (LLP)[22] or Minimum Layer Protocol (MLP).[23] For transmitting via TCP/IP, header and trailer characters are added to the message to identify the beginning and ending of the message because TCP/IP is a continuous stream of bytes.[24] Hybrid Lower Layer Protocol (HLLP) is a variation of MLLP that includes a checksum to help verify message integrity. Amongst other software vendors, MLLP is supported by Microsoft,[25] Oracle,[26] Cleo.[27]

MLLP contains no inherent security or encryption but relies on lower layer protocols such as Transport Layer Security (TLS) or IPsec for safeguarding Protected health information outside of a secure network.

Functional EHR and PHR specifications

[edit]

Functional specifications for an electronic health record.

Message details

[edit]

The OBR segment

[edit]

An OBR Segment carries information about an exam, diagnostic study/observation.[28] It is a required segment in an ORM (order message)[29] or an ORU (Observation Result) message.[30]

See also

[edit]

References

[edit]

 This article incorporates text from a free content work. Licensed under Creative Commons Attribution-ShareAlike 3.0 license. Text taken from Spronk 2007.

  1. ^ Joel Rodrigues (2010). Health Information Systems: Concepts, Methodologies, Tools, and Applications, Volume 1. IGI Global. p. xxxix. ISBN 978-1-60566-988-5.
  2. ^ "HL7 Primary Standards". Health Level Seven International.
  3. ^ "HL7 Standards". Health Level Seven International.
  4. ^ "HL7 FAQs". HL7.
  5. ^ "Understanding HL7 Messages". iNTERFACEWARE.
  6. ^ "HL7 Messages and Descriptions". Health Standards.
  7. ^ "Standards Organizations". Assistant Secretary for Planning and Evaluation (ASPE), Health and Human Services (HHS).
  8. ^ "HL7 V3 Standard - A High Level Overview". 26 May 2020.
  9. ^ "HL7 Reference Information Model". HL7.
  10. ^ "Tools & Resources – V3 Modeling & Methodology Tools". HL7.
  11. ^ Spronk, René, ed. (16 November 2007). "HL7 Message examples: version 2 and version 3". Ringholm. Ringholm bv.
  12. ^ Boone, Keith W. (20 May 2011). The CDA Book. Springer. ISBN 9780857293367.
  13. ^ Dan Munro (2014-03-30). "Setting Healthcare Interop On Fire". Forbes. Retrieved 2014-11-22.
  14. ^ Kryszyn, Jacek; Smolik, Waldemar T.; Wanta, Damian; Midura, Mateusz; Wróblewski, Przemysław (2023). "Comparison of OpenEHR and HL7 FHIR Standards". International Journal of Electronics and Telecommunications. 69 (1): 47–52. doi:10.24425/ijet.2023.144330. Retrieved 2024-01-08.
  15. ^ "Clinical Quality Language (CQL)". cql.hl7.org.
  16. ^ "1. Introduction". cql.hl7.org.
  17. ^ "CQL - Clinical Quality Language | eCQI Resource Center". ecqi.healthit.gov.
  18. ^ "L3 Implementation Guide". www.who.int.
  19. ^ a b Measures management system cms.gov Retrieved 3 April 2024
  20. ^ Pioneers in Quality. Electronic Clinical Quality Measure (eCQM). Clinical Quality Language (CQL) Basics for Hospitals jointcommission.org
  21. ^ Raths, David (May 11, 2023). "NCQA Makes Clinical Quality Language Software Open Source". Healthcare Innovation.
  22. ^ "LLP - Lower Layer Protocol". iNTERFACEWARE.
  23. ^ "Minimum Layer Protocol". LYNIATE. 13 January 2020.
  24. ^ Spronk, Rene. "Transport Specification: MLLP, Release 1" (PDF). hl7.org. Health Level Seven Inc. Retrieved 5 September 2022.
  25. ^ "MLLP Receive and Send Components". MSDN.
  26. ^ "Oracle Application Server Integration B2B User's Guide, Supported Protocols". Oracle.
  27. ^ "Which Secure Managed File Transfer Protocol is Right for You?". Cleo. Archived from the original on 2015-06-07. Retrieved 2015-01-23.
  28. ^ "The HL7 OBR segment". Corepoint Health. Archived from the original on 2019-06-18. Retrieved 2018-11-13.
  29. ^ "HL7 Glossary of Terms" (PDF). www.hl7.org. Retrieved 2018-11-13.
  30. ^ "What Is an ORU Message?". Health Standards. Retrieved 2018-11-13.
[edit]

Critical reviews

[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Health_Level_7&oldid=1248480466"