Skip to main content

Abstract

Perhaps the biggest impediment to achieving reliable and interoperable healthcare information systems is the absence of widespread standards adoption; and not just standards, but standards that are clear and unambiguous. These standards must provide precise specifications in a language that can be universally understood and interpreted—the language of conformance. This conformance language provides the means and constructs for defining requirements and solutions exactly and consistently so that systems, products, etc. can achieve conformance that ultimately leads to interoperability. These means and constructs are embodied in the principles of conformance, the subject and focus of this book.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 219.00
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 279.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info
Hardcover Book
USD 279.99
Price excludes VAT (USA)
  • Durable hardcover edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    Specified separately and independently.

  2. 2.

    It is hard to assign a definitive value to the savings, but typical estimates found in the literature conservatively place the amount spent when issues are discovered during the operations phase at 100 times the amount spent for discovering and resolving the issues during the requirements definition phase. See the [2] study for details on the subject.

  3. 3.

    Meaning the normative standard; intermediate standards for trial use  (STU ) are integral parts of the standard’s development life-cycle.

  4. 4.

    Although the term “required” is quite common in various data exchange standards, the detailed semantics varies. Sometimes it includes null values, sometimes not. Sometimes it refers to the presence of real data, sometimes the presence of the element (without) data is sufficient.

  5. 5.

    In general, the concept of “RE” means that an implementation must support the capability but operationally data may or may not be present. The subtleties of this concept will be explained in-depth over the course of this book.

  6. 6.

    In HL7 v2.x a methodology is provided for documenting constraints on a message. In other standards no such methodology is provided; authors are left to ad hoc solutions.

  7. 7.

    IHE and other organizations most relevant to healthcare are introduced in greater depth in Chap. 3 (Healthcare Standards Landscape).

  8. 8.

    Centers for Disease Control and Prevention in the United States.

  9. 9.

    Office of the National Coordinator in the United States.

  10. 10.

    The knowledge an actor such as a physician must have acquired through education and experience in the medical domain in order to participate in the information cycle is a different type of knowledge than the knowledge one can derive from receiving an appropriate amount of data (which is another topic and is certainly interesting and important).

  11. 11.

    An example is the simple statement of a blood pressure measurement. An interpretation of “190/120” as “normal” is only possible if the interpreter knows that the patient is cycling on an ergometer. The simple observation value is meaningless or even misleading without the accompanying context.

  12. 12.

    The term interface in this book refers to the software employed to exchange data between systems. Other notions of interfaces, such as a user interface, will be explicitly called out.

  13. 13.

    For a non-trivial interface, proof of conformance is unattainable even with exhaustive testing. Thus, typically a tester will declare “a system is conformant with respect to a given set of tests”. Conformance testing strives to establish a degree of confidence in the conformity of a given entity based on the quantity and the quality of the tests performed.

  14. 14.

    Compliance in this context has a different meaning as used in Sect. 1.9.

  15. 15.

    Logical Observations Identifiers Names and Codes; See https://loinc.org.

  16. 16.

    Indeed, this waterfall process model allows for repeating and updating every step, but to keep the figure simple, these aspects of the process are not made explicit.

  17. 17.

    We use the term “derived specification” to denote a technical documentation that is based on another technical document or set of technical documents. Often the derived specification places constraints on the base specification.

  18. 18.

    Often systems will implement to the same specification, and in such cases compatibility is not of concern.

  19. 19.

    Even in the case of compatibility and interoperability, it can’t be assumed that the system implemented the specification correctly.

  20. 20.

    Conformance is not a concept that can be proven except for the most simplistic specifications; see Chap. 11 for an in-depth discussion on this topic.

  21. 21.

    The terms “required” and “mandatory” are used in most of the standards, but not always with the same meaning. The differences are explained in chapters that follow. An overview of different standards is provided in Chap. 4.

  22. 22.

    Meaning the final normative standard; certainly draft standards are necessary as part of the standards development life-cycle.

  23. 23.

    The different conformance constructs span a multi-dimensional test space where each point within must be tested individually, which is practically impossible.

  24. 24.

    Automated test generation can help; however, in the opinion of the authors, this technology has not been proven to be reliable and comprehensive beyond a limited set of trials.

  25. 25.

    Implementation is also a suitable term; however, a narrower focus is sought here.

References

  1. Object Management Group. http://www.omg.org/

  2. Stecklein, J, et al.: Error Cost Escalation Through the Project Life Cycle, International Council on Systems Engineering (INCOSE) Foundation14th Annual International Symposium; 19-24 Jun. 2004; Toulouse; France, http://ntrs.nasa.gov/search.jsp?R=20100036670, June 2004.

  3. Digital Imaging and COmmunication in Medicine. The DICOM Standard 2013. http://medical.nema.org/standard.html, last accessed June 18th, 2014.

  4. Oemig F. IHE internal technical terminology, v0.6. http://www.ihe.net, http://groups.google.com/group/iheterminology/attach/7804505ee72e6ed9/IHE+Terminology+v07.zip?hl=en&part=2, last accessed Feb. 14 2010. http://www.hl7.org/documentcenter/public/wg/ictc/IHE%20Terminology%20v06.zip, last accessed Feb. 14 2014.

  5. Blobel B. Educational Challenge of Health Information Systems Interoperability. Methods Inf Med 2007, 46, S. 52-56.

    Google Scholar 

  6. Oemig F, Platter W: Semantische Interoperabilitat - Kommunikation im Gesundheitswesen, in Proceedings “Prozessoptimierung, eHealth und Vernetzung im Gesundheitswesen”, Jahrbuch Gesundheitswirtschaft 2007, 5.Dez. 2006, Berlin, S.162ff, ISBN: 3-932661-57-5

    Google Scholar 

  7. Schulz von Thun, F. Kommunikationsquadrat. http://www.schulz-von-thun.de/mod-komquad.html, last accessed April 22, 2008.

  8. Schulz von Thun, F. Four-Sides Model. http://en.wikipedia.org/wiki/Four_sides_model, last accessed June 18th, 2014.

  9. Merriam Webster Dictionary, derived on the term Conformity. http://www.merriam-webster.com/dictionary/, 1970.

  10. ISO Reference - ISO/IEC 17000 Conformity assessment - Vocabulary and general principles, first edition 2004-11-02.

    Google Scholar 

  11. Glossary of Conformance Terminology, Interoperability and Conformance Technical Committee, OASIS. http://www.oasis-open.org/committees/ioc/glossary.htm

  12. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

    Google Scholar 

  13. Benson T. Principles of Health Interoperability HL7 and SNOMED. Health Informatics Series, Springer-Verlag, London Limited 2010.

    Book  Google Scholar 

  14. Blobel B. Introduction into Advanced eHealth - The Personal Health Challenge. In: Blobel B, Pharow P, Nerlich M (Edrs.): eHealth: Combining Health Telematics, Telemedicine, Biomedical Engineering and Bio-informatics to the Edge - Global Experts Summit Textbook, pp. 3-14. Series “Studies in Health Technology and Informatics”, 2007, Vol. 134. IOS Press, Amsterdam, Berlin, New York, Tokyo. ISBN-978-1-58603-835-9.

    Google Scholar 

  15. DIN ISO 7498. Informationsverarbeitung Kommunikation Offener Systeme, Basis-Referenzmodell. DIN EN ISO 7498-1 ISO/OSI-Modell, Beuth Verlag, 1982.

    Google Scholar 

  16. International Organization for Standardization (1996) ISO/IEC 10746 - 2. Information technology - Reference Model for Open Distributed Processing: Foundations. Geneva. ISO/IEC IS 10746 / ITU-T x.901, ISO/IEC IS 10746/ITU-T x.901, http://www.rm-odp.net, last accessed 17.3.09.

  17. Blobel B: Assessment of Middleware Concepts Using a Generic Component Model. Proceedings of the Conference “Toward An Electronic Health Record Europe ’97”, 1997, pp. 221-228. London.

    Google Scholar 

  18. Blobel B: Application of the Component Paradigm for Analysis and Design of Advanced Health System Architectures, International Journal of Medical Informatics 2000, 60, 3: pp. 281-301.

    Google Scholar 

  19. Blobel B. Analysis and Evaluation of EHR Approaches. Methods Inf Med 2009; 48, 2: pp 162-169.

    Google Scholar 

  20. Blobel B, Oemig F. Ontology-driven health information systems architectures. In: Adlassnig K-P, Blobel B, Mantas J, Masic I (Edrs.) Medical Informatics in a United and Healthy Europe - Proceedings of MIE 2009, pp 195-199. Series Studies in Health Technology and Informatics, Vol. 150. IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, IOS Press, ISBN: 978-1-60750-044-5.

    Google Scholar 

  21. Blobel B. Architectural approach to eHealth for enabling paradigm changes in health. Methods Inf Med 2010; 49, 2: 123-134.

    Article  Google Scholar 

  22. Blobel B, Goossen W, Brochhausen M. Clinical modeling - A critical analysis. Int J Med Inform 2014; 83, 1: 57-69.

    Article  Google Scholar 

  23. Snelick R, Taylor S. Understanding Meaningful Use with a Focus on Testing the HL7 V2 Messaging Standards. HL7 May 2013 Newsletter. http://www.hl7.org/documentcenter/public_temp_46CE1189-1C23-BA17-0C847B8B1C5ED33F/newsletters/HL7_NEWS_20130506.pdf.

  24. National Institute of Standards and Technology (NIST) Meaningful Use Tools Portal. http://healthcare.nist.gov/NIST-TOOLS/MU/index.html

  25. Network Working Group. Key words for use in RFCs to Indicate Requirement Levels. March 1997. http://tools.ietf.org/html/rfc2119.

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Frank Oemig .

Rights and permissions

Reprints and permissions

Copyright information

© 2016 Springer International Publishing Switzerland

About this chapter

Cite this chapter

Oemig, F., Snelick, R. (2016). Introduction. In: Healthcare Interoperability Standards Compliance Handbook. Springer, Cham. https://doi.org/10.1007/978-3-319-44839-8_1

Download citation

  • DOI: https://doi.org/10.1007/978-3-319-44839-8_1

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-319-44837-4

  • Online ISBN: 978-3-319-44839-8

  • eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics