Difference between revisions of "IPS implementationguide 1"
(→Project Background) |
(→Medicinal Product Identifications) |
||
| Line 205: | Line 205: | ||
Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description. | Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description. | ||
| − | Medicines data | + | Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, that includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs. |
| + | |||
| + | [[File:IPS_CDA_SBDAM.png|700px]] | ||
| + | |||
| + | <ref group=figure">Representation of medicines in CDA</ref> Representation of medicines in CDA | ||
Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET. | Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET. | ||
| + | |||
The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead. | The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead. | ||
| Line 216: | Line 221: | ||
The figure shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes. | The figure shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes. | ||
| − | [[File:IPS_CMP_model.png| | + | [[File:IPS_CMP_model.png|700 px]] |
| + | |||
| + | <ref group=figure">CDA model has been enhanced with the Common Product Model</ref>CDA model and the Common Product Model | ||
==Medication Statement== | ==Medication Statement== | ||
Revision as of 14:55, 7 July 2017
This document contains: Implementation Guide International Patient Summary (0.10). The text materials belong to category cdaips.
based on Clinical Document Architecture Release 2
© 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.
The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.
If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.
A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.
INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.
B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.
C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.
Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing.
Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
| Terminology | Owner/Contact |
|---|---|
| Current Procedures Terminology (CPT) code set | American Medical Association https://www.ama-assn.org/practice-management/cpt-licensing |
| SNOMED CT© | SNOMED CT® International http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org |
| Logical Observation Identifiers Names & Codes (LOINC©) | Regenstrief Institute, Inc. |
| International Classification of Diseases (ICD) codes | World Health Organization (WHO) |
| NUCC Health Care Provider Taxonomy code set | American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services) |
Obtaining a CPT Sublicense from HL7
Contact hq@hl7.org about how to obtain a sublicense from HL7 for non-production use of CPT for (i) the development and publication of value sets, profiles, and other artifacts as part of the HL7 Implementation Guides, (ii) as part of defined VSAC value sets, and (iii) to support HL7's terminology services within the Territory.
Flow Down Clauses for CPT Sublicense from HL7
CPT content is copyrighted by the American Medical Association and CPT is a registered trademark of the AMA.
HL7, as a party to a license agreement with the AMA, is authorized to grant user a limited, non-exclusive, non-transferable, non-sublicensable license for user to use CPT content for (i) the development and publication of value sets, profiles, and other artifacts as part of the HL7 Implementation Guides, (ii) as part of defined VSAC value sets, and (iii) to support HL7's terminology services within the Territory, each of which shall be considered a non-production use. The sublicense granted hereunder shall automatically terminate upon termination of the agreement between HL7 and AMA, unless prior written consent of AMA is obtained.
The provision of updated CPT content is dependent on a continuing contractual relationship between HL7 and the AMA.
User acknowledge a separate license agreement shall be required, and shall govern any proposed use, including any distribution of CPT content for any other purposes not expressly permitted under this Agreement, and the terms of such agreement will govern such use (e.g., a separate license agreement shall govern production use and commercial purposes). AMA reserves the right to accept or reject licenses based on AMA's evaluation of the proposed use of the CPT content.
User acknowledge that User's development and commercialization of CPT-informed works developed with reference to Licensed Products may only be implemented in the Territory.
User is prohibited from making CPT content publicly available, creating derivative works (including translating), transferring, selling, leasing, licensing, or otherwise making available to any unauthorized party the CPT content, or a copy or portion of CPT content to any unauthorized party, including a subsidiary, affiliate, or other legal entity, however designated, for any purpose whatsoever except as expressly permitted under a separate agreement.
User expressly acknowledges and agrees to the extent permitted by applicable law, use of CPT content is at User's sole risk and CPT content is provided "as is" without warranty of any kind. The AMA does not directly or indirectly practice medicine or dispense medical services. Fee schedules, relative value units, conversion factors and/or related components are not assigned by the AMA, are not part of CPT, and the AMA is not recommending their use. CPT content herein does not replace the AMA's Current Procedural Terminology book or other appropriate coding authority. The coding information contained in CPT content should be used only as a guide.
U.S. Government End Users. CPT is commercial technical data, which was developed exclusively at private expense by the American Medical Association (AMA), 330 North Wabash Avenue, Chicago, Illinois 60611. This agreement does not grant the Federal Government a direct license to use CPT based on FAR 52.227- 14 (Data Rights - General) and DFARS 252.227-7015 (Technical Data - Commercial Items).
User expressly consents to the release of its name to the AMA.
| Primary Editor | Giorgio Cangioli, PhD Consultant, HL7 Italy giorgio.cangioli@gmail.com |
| Primary Editor | Rob Hausam Hausam Consulting LLC rob@hausamconsulting.com |
| Primary Editor | Dr Kai U. Heitmann Heitmann Consulting and Services, HL7 Germany, ART-DECOR Open Tools GmbH info@kheitmann.de |
| Primary Editor | François Macary Phast francois.macary@phast.fr |
| Contributor | Dr Philip Scott HL7 UK philip.scott@uwtsd.ac.uk |
| Contributor | Dr Christof Geßner Gematik christof.gessner@gematik.de |
| Contributor | Dr Stefan Sabutsch ELGA, HL7 Austria stefan.sabutsch@elga.gv.at |
| Contributor | Gary Dickinson CentriHealth gary.dickinson@ehr-standards.com |
| Contributor | Catherine Chronaki HL7 International Foundation chronaki@gmail.com |
| Contributor | Dr Stephen Chu HL7 Australia chuscmi88@gmail.com |
| Contributor | Didi Davis The Sequoia Project ddavis@sequoiaproject.org |
| Other Contributors | Alexander Berler (a.berler@gnomon.com.gr) ; Carina Seerainer (carina.seerainer@elga.gv.at); John Roberts (John.A.Roberts@tn.gov); Julie James (julie_james@bluewaveinformatics.co.uk); Mark Shafarman (mark.shafarman@earthlink.net); Fernando Portilla (fportila@gmail.com); Ed Hammond (william.hammond@duke.edu); Steve Kay (s.kay@histandards.net) |
Contents
Introduction
The International Patient Summary (IPS) is a minimal and non-exhaustive patient summary, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.
Purpose
The goal of this Implementation Guide is to identify the required clinical data, vocabulary and value sets for an international patient summary. The international patient summary is specified as a templated document using HL7 CDA R2. The primary use case is to provide support for cross-border emergency and unplanned care.
This specification aims to support:
- Cross-jurisdictional patient summaries (through adaptation/extension for multi-language and realm scenarios, including translation).
- Emergency and unplanned care in any country, regardless of language.
- Where possible, value sets based on international vocabularies that are usable and understandable in any country.
- Data and metadata for document-level provenance.
Project Background
This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.
The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative[1]. These initiatives identified the need for common templates and vocabularies for the patient summary.
The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”[2].
The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from both the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries. Since the beginning of this new phase, the initiatives were envisaged as a single common IPS project supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.
To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) "The Patient Summary for Unscheduled, Cross-border Care" (the CEN/TC 251 EN PS in the figure); the HL7 ones on its implementation based on HL7 CDA R2 - this guide - and hopefully on FHIR (the HL7 IPS IGs in the figure). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.
[Figure 1] Standards in the HL7 SAIF Interoperability Matrix
A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification”); and that “the IPS specification shall focus on a minimal and non-exhaustive Patient Summary, which is specialty-agnostic and condition-independent, but still clinically relevant.”.
Scope
to be written
...a minimal and non-exhaustive patient summary, which is specialty-agnostic and condition-independent, but still clinically relevant. ...global use
General Principles for this Specification
With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.
- The standards specification for the IPS will be implementable
- Promote (the evolution and convergence of) existing standards
- Rely on solutions that are already implemented or ready for implementation
- Consider new or additional solutions as they become available
- The standards specification for the IPS will be applicable for global use
- Strive for global accessibility of standards for free
- Strive for a core set of globally accessible and usable terminologies and value sets
- Include free text in addition to the structured codes as needed
- Do not include local solutions in the core specification that are not available in other jurisdictions
- The standards specification will be extensible and open to future use cases and solutions
- The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
- The IPS is open to emerging solutions for unresolved issues or improvements
- The standards specifications and their implementation must be sustainable through:
- A robust maintenance and update process for the IPS
- A process to ensure clinical validity of the IPS, meeting:
- clinical requirements (including workflow)
- clinical documentation requirements
- information quality requirements
Moreover HL7 International and CEN/TC 251 will manage the expectations of the IPS standards specifications among stakeholders, by
- stipulating the role of the IPS as a foundation for others to extend
- justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.
The more relevant consequences of these principles in the template design are:
- The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementers;with that of optimizing the fitness for purpose within the IPS scope. All this trying to avoid a pure technical exercise of templates harmonization; or, on the other hand, an academic exercise that does not take in account what is already implemented.
- Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
- When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
- Select a set of reference global terminologies, leaving however space for the inclusion of the locally used terminologies.
- Do not choose solutions (e.g. identifiers, terminologies, standards) , even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. When possible, the IPS has been however already designed in order to be ready when these solutions will be made available for real use (e.g. the IDMP identifiers) or to support since now the parts of those solutions that could be used today.
- Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates in order that the IPS templates might be hopefully extensible to support new scenarios; or specific specialties or conditions; through templates specialization or adaptation mechanisms.
Structuring Choices
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR represents equivalent concepts and in some cases has followed a FHIR style of representation rather than a conventional CDA style. The variations from CDA R2 are explained in the relevant detail sections. The mechanism for negation, unknown data and known absent data does not follow the CDA conventions and is explained here.
To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in a later section) and it is used for the majority of value sets. Other primary terminologies used by this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure and EDQM for dose forms and routes.
This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.
Ballot Status of the Document
This Implementation Guide is STU with the intention to go normative.
Audience
The audience for this Implementation Guide includes:
Public
- Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
- Policy makers such as healthcare payers or government agencies.
- Healthcare information governance authorities and regulatory bodies.
Clinical
- Healthcare providers that offer unscheduled and emergency care.
- Healthcare providers that populate regional and national patient summaries.
Technical
- Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
- System integrators.
- Organizations that manage regional and national patient summaries.
Relationships with other projects and guidelines
- CEN/TC 251 Project International Patient Summary (add explicit refernce to the CEN /TC 251 work items (Giorgio))
- epSOS/EXPAND/eHDSI
- GUIDELINE on the electronic exchange of health data under Cross-. Border Directive 2011/24/EU. Release 2 (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf)
- Consolidated CDA (C-CDA)
- IHE-PCC
- Input from the EHR work group about how to define the source(s) of the IPS content, described in the provenance section .
How to read this document
- Kai to write a paragraph
- Balloter instructions
Design conventions and principles
How to use terminologies (preferred binding)
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the primary terminologies of this specification.
Nethertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local inteface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.
In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
- The Primary Code of a codeable element should be populated.
- If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
- The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
- When the Primary Code is not populated, the Original Text shall be populated with a textual expression representing the meaning for the producer.
- One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.
Primary Code
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
Alternate Code
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
Original Text
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.
Representing "known absent" and "not known"
In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
- condition or activity unknown;
- condition or activity known absent.
Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed; have been considered beyond the set of essential data for an IPS, even if it is not precluded to provide them.
This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of the underlying syntactical standard (such as nullFlavor and negationInd attributes for CDA).
The main reasons for this choice are:
- @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
- To have a representation of the clinical content of the patient summary which is less dependent on a particular format or syntax, enabling a more practical path to transforming and exchanging data from one standard format (e.g., CDA R2) to another (e.g., FHIR).
- to provide one single method to express either the presence or absence of a particular condition (e.g., an allergy) or activity (e.g., an immunization), or the lack of knowledge regarding this kind of condition or activity, resulting in a more robust and easily implementable specification.
In some cases this required the creation of new SNOMED CT concepts. For example, a known absent Allergy/Intolerance would be represented by "716186003 |No known allergy (situation)|" (or any combination of its descendants), whereas no information about Allergy/Intolerance would be represented by a code with the meaning "Allergic disposition not known (situation)". For these cases an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.
For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach. Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.
Medicinal Product Identifications
The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.
The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.
Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).
Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.
Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.
Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.
Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, that includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.
[figure" 1] Representation of medicines in CDA
Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.
The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.
This choice has been made:
- considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
- to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).
The figure shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.
[figure" 2]CDA model and the Common Product Model
Medication Statement
Provenance
In the development of this Implementation Guide, consideration was given to the HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 - US Realm Draft Standard for Trial Use (December 2015). That guide provides a matrix offering a thorough and systematic analysis of provenance characteristics of electronic health records. Given the agreed scope principle that the IPS be minimal and implementable, and the variable maturity and operational methods of existing national patient summaries, the proposal is that this first version should not attempt to require the full detail of that provenance specification.
The approach proposed for this version of the IPS is to:
- Require document-level, not section level, provenance.
- Define IPS document provenance as one of two types: human-curated or software-assembled.
- The classification is based on whether the IPS document is constructed by a human or an automated process, regardless of whether the IPS contains some content of both kinds.
- Require the IPS source system to identify the IPS document provenance type and "author".
- The "author" shall be a human, if the IPS provenance type is "human-curated", or a device or system if the IPS provenance type is "software-assembled".
- In the case of a "software-assembled" IPS that is then verified by a human, the document provenance type shall be "software-assembled" and the author shall be the device or system that constructed the IPS document, but an additional "verifier" identity shall name the human who performed this check. For the avoidance of doubt, this is not the same as legalAuthenticator. However, in cases where the verifying person intentionally wishes to sign the document, this shall be recorded as a legalAuthenticator.
- Allow optional section level author, provenance type, verifier and informant identification, for IPS source systems that can support this.
- Not attempt to implement the US Realm CDA data provenance templates.
The discussions with the EHR work group suggest that a possible future project should be an IPS functional profile, once there is greater clarity and operational experience of using the IPS.
General Implementation Guidance
- How to populate IDs in an CDA XML instance, e.g. ClinicalDocument.id, setId
- Where I can get IDs
- Relevant times for a patient summary
- Description of the different status definitions (condition, concern, observation) --> Giorgio
- (Authorship is probably a part to go to Provenance)
Conformance clause
This section references the requirements, criteria, or conditions to be satisfied in order that a product (tangible) or a service may claim conformance about this guide, and how other artefacts may claim compliance with it. (Note: The concept of conformance and compliance are used coherently with the HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2 [1] see glossary below] . The fulfilment of these clauses indirectly assure that a product that is subject of a “conformity assessment” satisfies the business or the design requirements this specification complies to. It should be however clear that the compliance with specified business or the design requirements, for example in the future with the CEN prEN IPS, doesn’t imply that the compliant implementations are technically interoperable. A “conformity assessment” is a process that assesses that any proposition that is true in a given specification, it is also true in the service or product that implements it. In most real-world cases conformance testing objects are used to technically validated the products. These objects provide a great help in the validation of the instances, even if it is not often these kind of validation is not self-sufficient to guarantee the functional/ semantic conformity: many real-life examples can be made about instances that are technically valid, but not clinically meaningful or correct. Figure XYZ below depicts how this concept applies to the business requirements, the current and hopefully future IPS projects standards (CEN/TC 251 and HL7) and other related artefacts involved in this assessment chain. (see section ZZZ for a description of the standards developed by the CEN/TC 251 IPS project )
Figure XYZ - The IPS World
The "rules" and processes for refining the standard through constraint and extension, including which standard artifacts are subject to constraint or extension; the definition of constraint and localization profiles; the criteria for establishing a conformance statement; and the principles guiding who may define extensions to the standards and under what circumstances that applies to the CDA standards are defined in § 1.3 CDA Conformance of the CDA and detailed in the HL7 V3 Refinement, Constraint and Localization section. (See the CDA R2 Standard [2] ) There are no additional requirements to be applied for this guide for what concern the Recipient and the Originator Responsibilities. The formal representation used in this implementation guide for expressing the conformance statement is described in section ZZZ of this guide and makes use of a tabular representation that may include also computable or textual constraints. The template rules are formalized using the computable format defined by the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 [3] in order to facilitate also the automatic generation of consistent testing objects.
This standard (i.e. the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 ) defines also how derived templates may relate to the templates defined in this guide for example:
- Specialization: “A specialized template is a narrower, more explicit, more constrained template based on a “parent” template.
- Adaptation: “The adapted template is “based on” the original template which means it can be an extension or a specialization (restriction) of the original template design.”
- Equivalency: “two templates have the same purpose and the same design; however, their governance and/or metadata and/or details of their design may be different.”
Based on this the following way to use this guide may be considered :
- IPS as a document: the conformance is asserted at the document level, all the rules defined by this guide, or by an IPS specialized document level template, are fulfilled. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
- IPS as a library: the conformance is asserted at the section or the entry level. The templates are used as a library to build, for example, new cross-border documents. For example the immunization section may be used to build an electronics implementation of the WHO yellow card for vaccinations; or the used section to send back a cross border encounter report after the Patient Summary has been used. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
- IPS as a reference: the implementation is conformant with templates that are adaptation or equivalent to those defined by this guide. In this case some of the rules defined by this guide are not fulfilled and the conformance cannot be asserted. However differences may be limited and the effort required to achieve the harmonization be not so huge. Typical examples are templates in which alternatives vocabularies are used.
Jurisdiction may also decide to impose the closure of the template in order to limit the implementation optionality, this should be carefully evaluated in term of flexibility of the solution.
Functional requirements and high-level use cases
- Add a reference to the CEN prEN. (to be analyzed)
- PSS
- Add a reference to the data set included in the html package
- Include in the functional area that no assumption on transport has been made…
- PS comes from one source, and covers different cases.
- Specify, how the provenance could be managed without going into details) to be included in next versions.
- To be further discussed, in any case add a paragraph in which explain the problem and how it might be faced.
Reading Guide
Description of formalisms used, symbols, icons, how to read ART-DECOR artefacts
Appendix
Acronyms and abbreviations
Glossary
Compliance: Compliance of one standard or specification is compliant with another standard or specification if all propositions true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conformant implementations of the target are also conformant with the source. (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
Conformance: Conformance relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
Conformance Assessment: A process whereby a given implementation instance is evaluated to determine which f its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
Conformance Statement : A conformance Statement is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
Conformance assertion: Conformance assertion is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
Conformance points: Conformance points are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
Licenses
- for the artifacts used, for the code systems, etc.
Integrated examples
- links to example instances in the publication package
Validation artifacts
- links to xsd
- links to schematrons
Links to platforms, binaries, software libraries
- This should go away?!
Operational information
- share the ips HL7 email list address
- also offer info at international-patient-summary.net email address for inquiries regarding the specification
- actual endpoints or user interfaces for testing/validation
FAQ’s
References / Literature
How to reuse this template
List of all artifacts used in this guide
Datatypes
(This will be a list from ART-DECOR)
System OIDs / IDs
Code systems
CDA Templates (list of)
Value Sets
Summary tables
Examples (in progress)
( a set of link with explanations)
Plan:
- Create one or more storyboards (Stephen?)
- Turn the storyboards into real IPS example CDA instances
- Allow for multilingual CDA (Italian, German)
- Offer all XSD in the publication package
- include schematrons (generated by ART-DECOR)
References
- ↑ Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784
- ↑ Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123
Cite error: <ref> tags exist for a group named "Figure", but no corresponding <references group="Figure"/> tag was found, or a closing </ref> is missing
Cite error: <ref> tags exist for a group named "figure"", but no corresponding <references group="figure""/> tag was found, or a closing </ref> is missing
