Patient Summary Sample Clauses

Patient Summary. The Patient Summary is understood as a minimum set of patient’s data which would provide a health professional with essential information needed in case of unexpected or unsched- uled care. Some countries have developed “small” emergency data sets typically including patient data such as patient demographics, contact info, insurance data, allergies and prescription data. In some countries like Spain and Scotland such a minimum data set are officially defined by means of a previous process necessary to reach the consensus. There is a wide variation of contents, from a small set in the case of Scotland to a set as wide as almost a whole health record in the case of Slovenia. In the middle point it contains only the most relevant data for unscheduled situations (although they were not urgent) like Spain, Germany, Netherlands and other countries. Similar differences between countries are found for coding and classification methods. • Document identification • Patient identifying info • Health Care Provider • Own doctor • Relatives • Insurance info • Allergies • Current medication Emergency data plus… • Chronic conditions • Main and minor diagno- ses • Main problems • Advance directives • inoculations • Care Plan Recommenda- tion • Patient history • Medical notes • Patient notes • Lab-results and proce- dures. • Document identifying • Health Care Provider • Reason for referral • Patient identifying infor- mation • Insurance and financial Info • Patient health status • Diagnoses • Allergies • Current medication, Im- munization • Xxxxx xxxxx • Lab-results and proce- dures. • Care Documentation in text • Care Plan Recommenda- tion Also outside Europe types of patient summary are being developed. In the United States the American standardization organization ASTM has defined a “large” mandatory minimum dataset named “CCR – Continuity of Care Record” for communication between different health organizations. For a comparison, see Table 1 above. The precise terminological content of the different parts of the Patient Summary are going to be defined in the LSP project. This work will be done in close cooperation with the participat- ing member states and industry. The work process will include the following steps: • Analyzing semantic data content and use of codes and classifications in the partici- pating national implementations. • Define a modular minimum Europe Patient Summary dataset to be used in the LSP. • Define needed (and realistic) translation and classifica...

Patient Summary. In this analysis it is assumed that it is a local choice to decide if (a) the cross-border PS is directly generated by the local PS creator; or (b) it is generated converting “centrally” the local PS into the cross-border format. Note: this section focuses on the product identification Clinical information (e.g. posology) associated to the medications is therefore not covered in this section even though essential in a Patient Summary. As known the mechanics adopted for generating a Patient Summary can strongly vary depending on the jurisdiction: PS as an outcome of a Clinical decision of a GP; PS as an automatic collection of data from one or more EHRs; mixed approaches etc. Therefore, the functional requirements to support this process can strongly change depending on the applied approach. The following requirements try to generalize as possible this multiplicity. [1] The system producing the local PS (hereafter called PS creator system) has to be able to integrate the medication data, defined in that jurisdiction, included in the PS (e.g. brand name, local identifier, class of products, substances) with the applicable IDMP identifiers and attributes needed for allowing a safe characterization of the product by the receiver. This may include substances and strengths; the applicable PhPID and PhP name, the pharmaceutical substance (ATC), the route of administration, and so on. To obtain this data, the PS creator system relies on the information provided by a local implementation of the Medicinal Product Dictionary used in that jurisdiction. Note: this capability implies that the specifications defined in that jurisdiction for the PS have to enable the communication of such a kind of information: that is, the implemented PS has to be aware of the IDMP model. Some Examples: (a) the medicine is identified per ATC code, a PhPID Level 1 should be added to the PS; (b) the medicine is identified a SNOMED CT VMP (Virtual Medicinal Product) code the PS should include all the identification attributes (e.g. substance, presentation form) as defined by the IDMP implementation guide and optionally the associated IDs (e.g. PhPID level 4). [8] A conversion service may be provided in a jurisdiction to enable the conversion of the local PS format into the cross-border one (IDMP aware), when needed; and the addition of the applicable IDMP identifiers and attributes needed for allowing a safe characterization of the product, if not already included. This service relies on th...