business archetypes and archetype patterns from …investigating interoperability of clinical...

Procedia Computer Science 63 ( 2015 ) 553 – 560

Available online at www.sciencedirect.com

1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).Peer-review under responsibility of the Program Chairsdoi: 10.1016/j.procs.2015.08.384

ScienceDirect

The 2nd International Workshop on Meta-modelling for Healthcare Systems (MMHS15)

Business Archetypes and Archetype Patterns from the HL7 RIM and openEHR RM Perspectives: Towards Interoperability and

Evolution of Healthcare Models and Software Systems Gunnar Pihoa,*, Jaak Tepandia, Douglas Thompsonb, Andreas Woernerc , Marko Parmand

aDepartment of Informatics, Tallinn University of Technology, Akadeemia St. 15A, Tallinn 12618, Estonia bClinical and Biomedical Proteomics Group, University of Leeds, Beckett St, Leeds LS9 7TF, UK

cSysTek GmbH, Softwareentwicklungen, Bad Meinberger Str. 1, D-32760 Detmold, Germany bMedisoft AS, Räägu 35a, 13417 Tallinn, Estonia

Abstract

Business archetypes and archetype patterns were originally introduced by Arlow and Neustadt. Business archetype patterns (Product, Party, Order, Inventory, Quantity and Rule), composed of business archetypes (e.g., Person’s Name, Address, Phone Number) are the universal information models describing the universe of discourse of businesses. We have redesigned these archetypes and archetype patterns and are using the redesigned version of archetypes and archetype patterns in the development of real life healthcare software. In this paper we compare the redesigned archetypes and archetype patterns with the HL7 Version 3: Reference Information Model and openEHR Reference Model. In our comparison we emphasize semantical aggregation of health data across heterogeneous data sources, as well as the interoperability and evolution of models and software. © 2014 The Authors. Published by Elsevier B.V. Peer-review under responsibility of the Program Chairs.

Keywords: modelling and meta-modelling in healthcare; business archetypes and archetype patterns; HL7 Version 3: Reference Information Model (RIM); openEHR RM (Reference Model); interoperability and evolution of healthcare models and software systems;

1. Introduction

HL7 (Health Level Seven International, ANSI-accredited) is an organization that provides standards for the execution, management, and integration of patients clinical data1. HL7 Version 3: Reference Information Model (RIM)

* Corresponding author. Tel.: +372 511 1236; fax: +372 620 2311.

E-mail address: [email protected]

© 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).Peer-review under responsibility of the Program Chairs

http://crossmark.crossref.org/dialog/?doi=10.1016/j.procs.2015.08.384&domain=pdf

http://crossmark.crossref.org/dialog/?doi=10.1016/j.procs.2015.08.384&domain=pdf

554 Gunnar Piho et al. / Procedia Computer Science 63 ( 2015 ) 553 – 560

forms the foundation for all information modelling within HL72. It uses object-oriented modelling techniques, identifies the life cycle of the events that HL7 messages will carry3 and consists of 4 primary subject areas, 35 classes, 181 attributes, 9 associations and 28 generalizations4. openEHR is a virtual community5. Its focus (interoperability and computability of patient data) as well as the methodology is quite similar to HL7: mapping clinical data onto the model. Both openEHR and HL7 use a multi-level modelling approach with a simple reference model and constraint rules6. The openEHR RM (Reference Model) includes EHR (Electronic Health Record) and EHR Extract, Demographic, Common, Data Structure, Data types, Support and Integration information models7.

Business archetypes and archetype patterns (AAP) were originally introduced by Arlow and Neustadt8. Business archetype patterns (namely Product, Party, Order, Inventory, Quantity and Rule), composed of business archetypes (e.g., Person’s Name, Address, Phone Number) are the universal information models describing the universe of discourse of businesses. The archetypes and archetype patterns presented in this paper are implemented as part of Sentry (sample entry) software for CBPG (Clinical and Biomedical Proteomics Group, Leeds Institute of Cancer and Pathology, University of Leeds)9, 10.

We provide analysis of the business AAP from the HL7 RIM and openEHR RM perspectives in order to subsume HL7 and openEHR reference models into AAP. This analysis demonstrates that archetypes and archetype patterns may provide the important capability to semantically aggregate health data across heterogeneous data sources. An important property of AAP is to support second order evolutionary changes10. This makes it possible to change requirements and even domain models easily and safely at runtime without damaging the working systems and causing losses for businesses. Related work comprises analysis of HL7 RIM usage challenges3, analysis of EHR standards6, investigating interoperability of clinical applications11, analysis of semantic heterogeneity12,13,14, building semantic mappings of HL7 and OpenEHR standards15 and others.

This paper is organized as follows. In sections 2 and 3 we give an overview of the HL7 RIM and openEHR RM. In section 4 we introduce the redesigned system of AAP. In section 5 we compare the redesigned AAP-s with the HL7 RIM and openEHR RM and we conclude in section 6. We use Visual Studio (integrated development environment from Microsoft) class diagram notations in all our models: (blue) box indicates a class (e.g., Entity in Fig.1); single arrow indicates an attribute (e.g., in Fig.2. class Ehr has the attribute Id); double arrow indicates an attribute which is a collection (e.g., in Fig.1 class Entity has a collection attribute Roles); similarly to the UML, the hollow arrow indicates inheritance (e.g., in Fig.3. class Section is inherited from class ContentItem).

2. HL7 Reference Information Model

HL7 RIM is a domain model of healthcare by modelling entities (things, beings, and organizations), entity roles and actions. HL7 RIM core classes3,4,11 are shown in Fig.1.

Fig. 1. HL7 RIM core classes

In HL7 RIM any physical thing (e.g., material, place, device), being (e.g., person) or organization is represented by the Entity class and any happening (e.g., procedure, observation, financial act, account) is represented by the Act class. Any entity either plays or scopes different roles (e.g., patient, specimen) in healthcare events. The roles are represented by the Role class. The Participation class represents the relationship between Act and Role classes by


determining the context (e.g., author, performer, location). The relationships between two acts and two roles are represented by the ActRelationship (e.g., composition, preconditions) and RoleLink classes (e.g., patient in hospital) respectively. Acts are the most essential things in the HL7 RIM and everything revolves around the acts. For instance the patient’s medical record in terms of the HL7 RIM is the list of diagnosis, treatment, care and etc. which all are the acts.

3. openEHR Reference Model

openEHR RM16 presents a domain model of a document (EHR – Electronic Health Record) by modelling the document structure, content (composition), status, access rights, and changes (contribution) to the document. Fig.2 illustrates the core classes of openEHR EHR document. Any EHR in repository is uniquely identified by EhrId. Access class is for storing policies and rules, in accordance with which all the access decisions to data in the EHR must be made. Contribution class is for storing information about changes in the EHR document and audit trail of all changes in the EHR document is listed in the Contributions attribute of the Ehr class.

Fig. 2. openEHR EHR IM core classes

Fig. 3. openEHR EHR IM content classes

The content of the EHR document is stored using the collection of Composition class objects. Each Composition has Items attribute which is a collection of ContentItem class objects. ContentItem is either a Section or an Entry (Fig.3). While Entry is for storing either administrative or care (e.g., observation, evaluation, action) related data, the


Section class is for the structuring of EHR content items. The EventContext attribute is for storing the context information of a healthcare event involving the subject of care and the health system. In openEHR the patient’s medical and cure related data (stored as entries in the EHR document) and patient’s personal data (e.g., names, addresses, identifiers, health care institutions) are separated, so that the EHR document in isolation gives no information about the patient it belongs to. For each patient’s personal data there is the openEHR Demographic IM for which the base classes are shown in Fig.4.

Fig. 4. openEHR Demographic IM classes

Fig. 5. The essence of archetypes and archetype patterns

Each Party, either Role (e.g., patient, employee) or Actor (Person, Organization, Group – e.g., cardiology team, or Agent – device or software), has a unique PartyId (Fig.4). In Fig.2, the Patient (to whom this EHR document belongs) in Status class, the Composer (the person who is primarily responsible for the content of EHR document) in the Composition class, the Facility (health care facility under whose care the event took place), as well as the Participants (parties involved in the healthcare event) all use the PartyId as a non-personalized reference to the particular party. The Subject (any clinically relevant person other than particular patient: organ donor, family member, foetus, etc.), Provider (optional id of provider: e.g., patient, patient agent, clinician, device or software), and Participants (other participations) in Entry class are modelled similarly (Fig.3). A link between PatientId and patient’s personal data is ensured by the various secure access methods. Other attributes of Party class are a collection of identities (Identity) and a collection of addresses (Fig.4). Identity class is for storing different registered identifiers (e.g., passport, VAT number) including names. Party addresses (postal address, phone number, e-mail address, etc.) are stored through Contact class which identifies valid date and time intervals and purpose (e.g., emergency, day-time phone) for the specified collection of addresses. PartyRelationship class is a generic description of a relationship between two parties


identified as Source and Target. However, these names are neutral, and have no meaning in the relationships. Capability of a Role class is used to store professional qualifications or official rights (e.g., EHR modifier, health care provider).

4. System of archetypes and archetype patterns

The essence of archetypes and archetype patterns illustrated in Fig.5 is based on full AAP descriptions from9. Any Entity (person, organization, product, thing or living being) can be in various Roles and participate in various Relationships. For instance persons and organizations (both are entities) can be in different roles (e.g., the same person may be mother, patient) in different relationships (e.g., she may be mother of Paul, patient of Leeds Clinical Infirmary).

The Role archetype is used to store the information that belongs only to the role (e.g., observations and diagnoses if person is in role of patient) and the Relationship archetype (describes a binary relationship between two parties where each party has a specific role) is used to store only the information that belongs to the relationship (e.g., patient’s hospital or ward number). In addition to Entity, Role and Relationship archetypes, which are used to store operational level data, there are RoleType and RelationshipType archetypes to store knowledge level data. In particular, the RoleType class has an internal property Constraints (not shown on Fig. 5 due to article length limitations) which is used to describe the rules for a role (e.g., only female persons can be in the role of the mother). The RelationshipConstraint class is used to describe the rules for the relationship types (e.g., in a ChildsMother relationship one person is in the role of Mother and the other is in the role of the role of Child).

Fig. 6. Archetypes, model (knowledge level information) and data (operational level information)

As an example, in Fig.6 the object Sirje (person) is in two relationships. Sirje is the mother of Paul (also person) and Sirje is a patient in LeedsInf (organization). We have archetypes (grey), model objects describing knowledge (underlined and grey) and we have data (underlined and white). Here only archetypes are classes (design time artefacts) in terms of object-orientations and therefore hardcoded. All other elements exemplified in Fig.6, can be objects (run-time artefacts) and therefore can be specified even at runtime based on data from a database.

The redesigned system of archetypes and archetype patterns is implemented as part of Sentry (sample entry) software for CBPG (Clinical and Biomedical Proteomics Group, Leeds Institute of Cancer and Pathology, University of Leeds) and presented in detail in9. This implementation includes Rule, Quantity, Money, Party, Party Relationship, Product, Order, Inventory and Process archetype patterns. Comparing to original archetype patterns by Arlow and Neustadt8 we have a Process archetype pattern (Fig.7) instead of CRM (Client Relationship Management). Both the Process and CRM archetype patterns can be viewed as concretizations of the relationship pattern illustrated in Fig.5. In particular, the relationship and relationship type are among the basic components of the Process archetype pattern.


The archetypes and archetype patterns for the Sentry software are developed for clinical laboratories and can be used both for operational purposes in the healthcare systems or for scientific healthcare data management.

5. AAP from the HL7 RIM and openEHR RM perspectives

Both HL7 RIM and openEHR RM are modelling the domain of EHR (Electronic Health Records). In addition there is at least two more EHR initiatives: CEN/ISO EN13606 standard17 and industry initiative called Integrating the Healthcare Enterprise (IHE)18. openEHR and CEN EN 13606 are maintaining compatibility19.

Fig. 7. Process archetype pattern

One of the problems with domain models developed by different independent parties is semantic heterogeneity12. Semantic heterogeneity means that models and data schemes describing the same or similar universe of discourse are different. Such semantic heterogeneity is an obstruction when developing interoperable software systems13. This is especially critical in distributed healthcare systems, where semantic interoperability is mission critical14. Common solutions for dealing with semantic heterogeneity are data mapping tools similar to Microsoft BizTalk Server20 or MIRTH Connect21. However, it would be useful if different patterns describing one and the same domain could be combined into one, or at least be subsumed by one, pattern22.


In the HL7 RIM everything revolves around the acts (Fig.1). This means that the patient’s medical record in terms of HL7 RIM is the list of observations, diagnosis, treatment, care and etc. which all are the acts. In the openEHR RM terms the observations, diagnosis, treatment, care and etc. are all EHR entries (Fig.2 and Fig.3). In AAP lingua all these observations, diagnosis, treatment, care and etc. are tasks (Fig.7, ITask - I comes from interface; there is one to one relation between the interfaces shown in figure 7 and classes – e.g. Task) – a relationship between two roles called Consumer and Provider. It is important to note, that task is a report from a subordinate party role (Provider) to some supervisor party role (Consumer) and neither Consumer nor Provider roles in AAP process model are used for identifying patients. There can be many actions (IAction) in one task and in each action there may be many outcomes (IOutcome). For instance if the task is a “laboratory measurement”, then the consumer can be an ordering doctor and the provider can be a laboratory. “Sending an order”, “sample collecting” and “receiving a report” can be the actions, and results reported by the laboratory can be the outcomes of the “receiving a report” action.

Other process archetype pattern archetypes (Fig.7) are the following. The process manager archetype (IProcessManager) records all possible processes (IProcess) of allowed process types (IProcessType) described by the process manager type (IProcessManagerType). In EHR context the process manager type can be EHR. Examples of allowed process types in EHR can be “visit to the general practitioner”, “visit to the special doctor”, “outpatient treatment”, “hospital treatment”, “surgery” etc. Each process consists of one or more threads (IThread). A thread is described by a thread type (IThreadType). Allowed thread types are listed in a process type. Examples of thread types in a surgery can be “preoperative care”, “operation” and “postoperative care”. One and the same thread (e.g., postoperative care) can include more than one task (e.g., measurements, observations, treatment, care, and etc.). As processes vary and can be changed often, the process archetype pattern is designed to be managed by rule. By using the rule archetype pattern’s9 rule set (IRuleSet) and rule context (IRuleContect) archetypes, we can formally describe and validate the wide variety of different processes needed in healthcare. This means, that each process element type (IProcessType, IThreadType, ITaskType, IActionType and IOutcomeType - inherited from IProcessElementType) has RuleSet property that defines the rules, and each process element (IProcess, IThread, ITask, IAction and IOutcome - inherited from IProcessElement) has RuleContext property that gives the context (data) for that rule. Also in process pattern only the archetypes (Task, TaskType, Action, ActionType, etc.) are classes (design time artefacts) in terms of object-orientations and therefore hardcoded. All domain elements (EHR, surgery, measurement, care, and etc.) are objects (run-time artefacts) and therefore can be specified even at runtime based on data from a database.

Fig. 8. Archetypes and archetype patterns as the possibility to subsume different healthcare protocols and their interpretations

6. Conclusion

Scientific data management is one of today's key challenges23. Fig. 8 presents a view of how medical research could be revolutionized if researchers were able not only to use, share and distribute worldwide their research results in the


form of scientific papers, but were also able to publish their valuable (peer-reviewed) scientific data (including depersonalized clinical data of patients) for others to analyse. Also very useful would be the capability to use data from the different datasets and other systems including data from hospitals and other healthcare institutions.

The preceding chapters of the paper provided analysis of the business AAP from the HL7 V.3 RIM and openEHR RM perspectives in order to subsume HL7 and openEHR reference models into AAP. This analysis demonstrates that archetypes and archetype patterns may provide the needed capability to semantically aggregate health data across heterogeneous data sources. Hospitals, medical laboratories, research institutions, and other interested parties may use their internal data models based either on the HL7 set of standards, openEHR specifications, or on any other formats. When they decide to publish the data, they only have to describe the data in the AAP based DSL (Domain Specific Language). On the other hand the medical researchers can describe the data they need for the research using the same AAP based DSL.

The biggest difference besides semantic heterogeneity of these models is that redesigned AAP support second order evolutionary changes thus enabling the software system to provide for history and evolutionary changes both in data and in models10. This makes it possible to change requirements and even domain models easily and safely at runtime without damaging the working systems and causing losses for businesses.

Acknowledgements

This work is supported by Estonian Ministry of Education and Research; by Tallinn University of Technology (Estonia); by University of Leeds (United Kingdom). We thank reviewers for their helpful comments.

References

1. HL7. Health Level Seven (HL7). http://www.hl7.org/. 2. HL7 Version 3: Reference Information Model (RIM). http://www.hl7.org/implement/standards/product_brief.cfm?product_id=77. 3. Fernandez E, Sorgente T. An analysis of modeling flaws in HL7 and JAHIS. In: CM Symp on Appl Comp, Santa Fe, USA, 2005. 4. Beeler G. Introduction to HL7 RIM. https://www.hl7.org/documentcenter/public_temp_41742117-1C23-BA17-

0C55BF266DF06DB8/calendarofevents/himss/2009/presentations/Reference%20Information%20Model_Tue.pdf. 5. openEHR. http://openehr.org/. 6. Eichelberg M, Aden T, Riesmeier J. A Survey and Analysis of Electronic Healthcare Record Standards. ACM Cmp Surv 2005: 37(4); 277–315. 7. openEHR. Release 1.0.2. http://www.openehr.org/programs/specification/releases/1.0.2. 8. Arlow J, Neustadt I. Enterprise Patterns and MDA: Building Better Software With Archetype Patterns and UML, Addisson-Wesly, 2003. 9. Piho G. Archetypes Based Techniques for Development of Domains, Requirements and Software: Towards LIMS Software Factory. TUT

Press, Tallinn, 2011. 10. Piho G, Tepandi J, Thompson D, Tammer T, Parman M, Puusep V. Archetypes based meta-modeling towards evolutionary, dependable and

interoperable healthcare information systems. Procedia Computer Science 2014: 37; 457–464. 11. Yuksel M, Dogac A. Interoperability of Medical Device Information and the Clinical Applications: An HL7 RMIM based on the ISO/IEEE

11073 DIM. IEEE Transctions on Information Technology in Biomedicine 2011: 15(4); 557-566. 12. Halevy A. Why Your Data Won't Mix: Semantic Heterogeneity. Queue 2005: 3(8); 50-58. 13. Wache H. Solving Semantic Interoperability Conflicts. In:Methodology workshop: Modelling eGovernment entities Methodologies and

Experiences under review. Brussel, 02 February 2009. 14. Heard S, Beale T, Freriks G, Mori AR, Pishev O. Templates and Archetypes: how do we know what we are talking about? 2003.

http://www.openehr.org/publications/archetypes/templates_and_archetypes_heard_et_al.pdf. 15. Khan W, Khattak AM, Lee S, Hussain M, Amin B, Latif K. Achieving interoperability among healthcare standards: building semantic

mappings at models level. In: Proc of the 6th Int Conf on Ubiquitous Information Management and Communication, Article No. 101, 2012. 16. Beale T, Heard S. openEHR Architecture overview. http://www.openehr.org/releases/1.0.2/architecture/overview.pdf. 17. EN 13606 Association. The CEN/ISO EN13606 standard. http://www.en13606.org/the-ceniso-en13606-standard. 18. IHE International. Integrating the Healthcare Enterprise. http://ihe.net/. 19. openEHR org. 15 Relationship to Standards. http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/standards.html. 20. Microsoft. Microsoft BizTalk Server. http://www.microsoft.com/biztalk/en/us/default.aspx. 21. Mirth. Mirth Connect. https://www.mirth.com/Products-and-Services/Mirth-Connect#tab_overview. 22. Beydoun G, Low G, Henderson-Sellers B, Mouratidis H, Gomez-Sanz JJ, Pavon J, Gonzalez-Perez C.FAML: A Generic Metamodel for MAS

Development. IEEE Trans on SE 2009: 35(6); 841-863. 23. Science 2020. Towards 2020 Science. 2005. http://research.microsoft.com/towards2020science/background_overview.htm.

business archetypes and archetype patterns from …investigating interoperability of clinical...

Documents