EHR standards

Electronic Patient Records

EHR standards

Challenges:

Health care and patient mobility is increasingly global

Urgent need for standards to enable the sharing or EHR information

1. procuring and building health infrastructure to communicate clinical data across regions and health services
1. initial results likely to be just summaries and subsets than complete records, or
2. defining local standards or limiting choice to a small number of systems in joining clinical systems at a national level.
2. Global agreements on how to share and analyze EHRs bring cost down and improve patient safely.

Class of standard	class of standard	example standards
Electronic health record (EHR)	functional requirements, EHR models, continuity of care record (CCR), patient summary record, personal health record	HL7, ASTM, openEHR, CEN

EHR requirements:

1. Offer a flexible framework for recording the consultation process & accommodate the individuality of the clinical as well as the patient.
2. Capture faithfully the original meaning intended by the author
3. Framework that suite the needs of professionals and enterprises to analyze and interpret EHRs.
4. Incorporate the needs of medico-legal constructs to support the safe and relevant communication of EHR entries between professionals working on different sites, whilst respecting the privacy wishes of each[individual] patients.

Contexts associated with EHR records

Compositional	record entry names to provide a label for each content value compounding hierarchies of clinical concepts to express complex concepts group hierarchies for sets of clinical concepts with common headings to: preserve the content originally organized by the author identify the way in which the clinical concepts relate to the health care activities and processes surrounding the patient
Context value	formal representation for all data types, including text, quantities, time, persona and multimedia names of term sets, versions and registering agencies natural language used for recording accuracy, precision and units for quantities normal ranges
Clinical Interpretation	presence/ absence certainty severity site and laterality prevailing clinical circumstances justification, clinical reasoning additional explanatory comments by the author knowledge reference
Ethical and Legal	authorship and duty of care responsibilities subject of care dates and times of healthcare actions and of their recording version control access rights emphasis preservation of meaning on transferring the record to another site
Care process	cause and effect request and result process status to a defined problem to an episode of care to a stage in a protocol to a decision support system

Value of the EHR architectural approach:

1. representation and communication of diverse health care information can be standardized, scalable and maintainable
2. The combination of the reference model and the use of Archetypes helps to ensure the clinical shared care can be delivered safely, underpinned by complete and unambiguous information

The Archetype Model

Archetype:

1. Formal definition of prescribed combination of the building combinations of the building block cases defined in theReference Model for particular clinical domains or organizations
2. Express the rules that can be used to construct useful clinical templates from Reference Model in consistent and interoperable ways.
3. A formal and stable model that archetypes conform to:
1. Archetype evolve (and revised) with clinical practice
2. version control to ensure new revisions do not invalidate data created with previous versions.

Archetype can be used to:

1. Govern the EHR data held within a repository
2. Ensure a consistency mapping between EHR systems not using archetypes

Archetype repositories:

1. Number of archetypes depends on the range of clinical activities
2. Sources of knowledge for developing archetype definitions:
3. the data schemata (models) of existing clinical systems;
4. the layout of computer screen forms used by these systems for data entry and for the display of analysis performed.
5. data entry templates , pop-up list and look up tables used by these systems
6. shared-care data sets, messages and reports used locally and nationally
7. structure of templates and forms used for the documentation of clinical consultations or summaries within paper records;
8. the pre-coordinated terms in terminology systems

EN 13606

task force appointed by the Health Informatics Technical COmmittee of European Committee for Standardization

To produce a rigorous and durable Ix architecture for representing the EHR

support interoperability of sys. and components that may interact with EHR services

adopted by the ISO

EN 13606: 5-part standard

1. Reference model	Comprehensive, generic EHR model Mapped to the HL7 RIM and Clinical Document architecture
2. Archetype Interchange spec.	An Ix model and exchange syntax for communicating archetypes An adoption of the openEHR archetypes approach Compatible with the HL7 templates specification
3. Reference Archetype and term list	Contain a set of vocabularies and term lists to support the reference model Guidance on how to use the Reference Model classes and attributes, and how to design archetypes
4. Security	Define measures to support access control, consent and audibility of EHR communications
5. Exchange models	Defines messages and service interfaces to enable EHR and archetype communication

EN 13606 Reference model:

1. Define a core hierarchy of building blocks to which any EHR can be mapped
2. As the persistent longitudinal and potentially multi-enterprise or multi-national record of health and care provision relating to a single client (patient)
3. Records are created and stored in one or more physical systems in order to
1. inform the subject’s future health care &
2. provide a medico-legal record of care that has been provided.

In each layer of the EN 13606 hierarchy, the model defines:

1. A formal data structure [classes and attributes, expressed as a UML model]
2. The ability to include the relevant additional contextual information that:
1. is usually be save along with the main data within clinical systems,
2. needs to be communicated to any future recipients.

Example of contextual information

persons:

• who committed the data, composed the information, legally responsible for the clinical acts documented, to whom the clinical findings relate if not the patient (for example if to a family member).

Dates and times:

- when data was recorded, the care events took place, the life events happened to the patient, a goal or prognosis

Clinical settings (care or self-care)

Particular clinical circumstances relating to an observation

• standing or fasting measurement
• relational behind clinical decisions, and links and pointers between parts or an EHR
• Negative findings, changes of opinions or links to join various description of an evolving clinical picture
• Indications if data has been modified, and the kinds of reason to whom it is (or is not) intended to be made available.

HL7

• The Health Level seven organization was formed in US in 1987.
• initial goal: define interface requirements of large healthcare enterprises
• NOw engage with healthcare systems at regional and national level
• The HL7 protocol:
• a collection of standard formats specifying the interfaces for electronic data exchange in healthcare environments between computer applications from different vendors.

HL7 version 2

• developed and refined to reflect standardized reporting data sets for several aspects of a patient’s care in hospital.
• most widely used internationally within a hospital information system
• Problem:
• inconsistent implementations of version 2 messages and unsystematic growth of message segment definitions limit the realization of interoperability.

HL7 version 3

• The key feature: Reference Information Model (RIM)
• a means to specify the information content of messages through an information model that clarifies the definitions and ensures that they are used consistently.
• a formal information model representing the core classes and attributes that will be required (in various combinations) by the different HL7 version 3 messages
• RIM defines 4 major classes of information
• Entities
• person, organizations, places and devices
• Roles
• roles of patient or employee
• PArticipation relationships
• relationships between a patient and a clinician
• Acts
• recording of appointments, patient encounters, observations, procedures

HL7 CDA

• Clinical document architecture
• generic message structure for the communication of a clinical document
• derived as a message model from HL7 RIM
• CDA release 1
• XML-based standard that comprises a header with document authorship information, organizational origin and patient identifiers, and a body whose basic structure is defined at a “fairly high level”
• CDA release 2
• specifies the structural organization of fine-grained information inside a document
• close in scope to that of the inner hierarchies of the DEN 13606 EHR architecture
• a cross-mapping has been developed between HL7 and EN 13606.

IHE: integration the Healthcare Environment

• an industry sponsored organization to prompt interoperability between systems within specialist departments (CD) and the conventional hospitals systems
• example: radiology department, used to order such investigations and to receive imaging study reports
• work closely with CEn and HL7 and other standard orgs.
• Cross-document sharing (XDS)
• define registry and repository services that can function as a centralized or distributed warehouse for clinical documents.
• capable of supporting HL7 CDA documents and EHRcom (13606) equivalent structures
• Primarily a storage, indexing and distribution mechanism, and it a practical complement to these other standards.

ISO standard:

• ISO technical committee 215 (Health informatics)
• formed in late 1999
• activities:
• parallel to CEN 13606
• definition of standard data types that can be adopted by other standards as an id to their interoperability

openEHR foundation

• an independent not-for-profit organization and community founded in 2000 by the UCL, UK and Ocean Informatics, Australia
• work originated as the convergence of the European and Australian experience since 1991.
• to facilitate the creation and sharing of health records by consumers and clinicians via open source, standards-based implementations.
• becoming regarded internationally as the most complete and best-validated EHR information architecture.

The openEHR technical specifications define:

• design principle, reference and archetype models and other middleware service specifications
• work closely with the standards bodies to
• ensure that its own designs conform to current standards
• contributes its experience and designs to future standards
• founded upon formal software engineering methods. Activities include:

1. proceed with domain and problem analysis
2. formulate requirements and design principles
3. develop architectural specifications
4. initiate implementation projects (through iterative refinement and testing) that are used validate and improve the architecture and requirements [ExProgramming model]

• The process and deliverables are all managed by a formal change control process and version management tools.