View source for IPS implementationguide 1

__NOTOC__
{{Infobox_Document
|Title     = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short     = International Patient Summary
|Namespace = cdaips 
|Type      = Implementation Guide
|Version   = 0.10
|Submitted = HL7 International
|Date      = 21. March 2017
|Status    = Draft
|Period    = Draft
|OID       = n.n.
|Realm     = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>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_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}

The international patient summary is a minimal and non-exhaustive patient summary, specialty-agnostic, condition-independent, but readily usable by all clinicians for the unscheduled (cross-border) care of a patient.

==Purpose==

See PSS

The goal of this Implementation Guide is to identify the required clinical data with associated vocabulary bindings and value sets for patient summary, in the context of specific use cases, and to build an international document and associated templates based on HL7 CDA R2 (or a future CDA release), and evenually FHIR , with value sets to support data elements within those templates. The initial use case will be providing support for cross-border emergency and unplanned care.

These templates/profiles aim to:
*Serve for cross-jurisdictional patient summaries (through adaptation/extension for multi-language and realm scenarios, including translation).
*Support emergency and unplanned care in any country, regardless of language
*Define value sets based on international vocabularies that are usable and understandable in any country 

The deliverable(s) will address the requirements of an international patient summary:
*For the exchange of structured and coded information (section headings, entries)
*For administrative data in order to support content commitment, audit/logging/provenance

The Implementation Guide has received input from the EHR WG regarding the specification of functional requirements on patient summaries.

This Implementation Guide includes a compilation of the required clinical data, based on results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC, Trillium Bridge, eHealth Exchange), rules and recommendations for the use and maintenance of associated vocabulary bindings and value sets (in multilingual settings), and templates for the implementation of international patient summary documents. 

Therefore this Implementation Guide has its primary focus on provisions for semantic interoperability. 

Templates/profiles should take in consideration, where applicable, legal, organizational, security and infrastructure requirements based on experiences of pilot implementations (such as Trillium Bridge).

The white paper on Comparative Analysis Between HL7 C-CDA R1.1 CCD and epSoS PS v1.4 informed the development of the harmonized template and associated value sets.

=== Background ===
In 2010 a MoU was signed between EU and US to strengthen global cooperation in eHealth/Health. As a result, the ONC S&I “Interoperability of EHR” work group was launched in US in 2013 (http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative) and the Trillium Bridge Project (www.trilliumbridge.eu) in Europe to compare the CDA templates specified at that time in Europe (epSOS PS V1.4) and in US (MU – C-CDA CCD v1.1) for Patient Summaries (PSs) and to build a Trans-Atlantic exchange proof of concept. Both initiatives resulted identifying the need for a common template and vocabularies for the Patient Summary, in particular the following recommendation was offered and endorsed by all members of the Joint Initiative Council and by the HL7 International Council: “to advance an International Patient Summary (IPS) standard and enable people to access and share their health information for emergency or unplanned care anywhere and as needed. At minimum the IPS should include immunizations, allergies, medications, clinical problems, past operations and implants.”

Meanwhile
*A new version of the EU/US MOU Transatlantic eHealth/health IT Cooperation Roadmap entered consultation in November 2015 , ;
*(US) a Shared Nationwide interoperability roadmap was published in November 2015 ;
*The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization, initiated the standard sets project with patient summary as its pilot ;
*A maintenance process for the European Patient Summary Guidelines  is in progress (expected release on Nov 2016);
*The European eHealth Digital Service Infrastructure (project for the operational deployment of the EU cross-borders services) has been launched (2016-2018) 
*ART-DECOR® and the HL7 DSTU (now STU) template exchange format are being more and more used by European countries, including for the European Patient Summary templates (aka epSOS PS template). ART DECOR is also connected to the IHE

==Scope==
scope text from PSS

==Ballot Status of the Document==
This Implementation Guide is a draft.

==Audience==
==Relationships with other projects and guides==
*Connection with CEN IPS - quote/cite HL7/CEN agreement
*epSOS/eHDSI; C-CDA; IHE-PCC
===Prerequisite Knowledge===
CDA template concepts/terminology

==How to read this document==
Slowly

==Conventions==
==Contributions==
what does this cover? secton authorship?

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}
* See Paris slides
*Usage of negations
*The choice for negation it is not that of using negation indicator @negationInd but rely on the terminologies to do this
*To do: add a description in the introduction
*@negationInd in CDA has been superseded in V3 later by two other negation indicators: actNegationInd valueNegationInd
*Alignment with FHIR

The representation of “condition/activity unknown” and of “condition/activity known absent”is normalized for the IPS by leveraging the expressiveness of SNOMED CT as opposed to relying on specific mechanisms of the underlying syntactical standard (such as nullFlavor and negationInd for CDA). The main rationale for this choice is 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. The other rationale is 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).

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions 

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

=Functional requirements and high-level use cases=
{{Responsible|NN}}
*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.

<!--{{:Alltemplates}} UNCOMMENT THIS FOR FULL ART-DECOR CONTENT-->

=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables == 

=Examples (in progress)=
{{Responsible|NN}}