Dual model methodology can be applied to FHIR in order to get all the advantages that the archetypes provide.
This was presented on MIE2015. Full paper can be found here
(http://ebooks.iospress.nl/volumearticle/39320)
All transformations were made with LinkEHR Studio
(http://www.linkehr.com/)
Russian Call Girl Brookfield - 7001305949 Escorts Service 50% Off with Cash O...
Combining Archetypes and FHIR for Future-Proof Health Systems
1. Combining Archetypes with FHIR in Future-proof
Health Information Systems
Diego Boscá, David Moner, Jose Alberto Maldonado, Montserrat Robles
Biomedical Informatics Group (IBIME)
Institute for the Application of Advanced Information and Communication Technologies (ITACA)
Universitat Politècnica de Valencia, Spain
diebosto@upv.es
2. Objective
• Can archetype methodology be used seamless in FHIR
workflow and FHIR used in archetype systems?
1. Create archetypes based on FHIR model
2. Use the archetypes for the generation of data transformation
programs between archetype-based standards and FHIR (and vice
versa)
3. Use archetypes and their transformations alongside FHIR Resources
in a FHIR server.
Achieve semantic interoperability between the most
future-proof clinical information exchange standards.
3. What are archetypes?
• A reference model provides the
pieces and basic structure to
represent any clinical data and
its context information (dates,
authorship, etc.).
3
Reminder
about
archetypes
• A dual model architecture separates the
representation of data structures from their
formal definitions.
ISO EN 13606
HL7 CDA FHIR
• An archetype represents the
instructions about how to
combine those pieces into a
data structure schema that also
has a clinical defined meaning
(e.g. a discharge report or a
medication instruction).
openEHR
4. What is FHIR?
• FHIR is a brand new HL7 DSTU for the electronic
exchange of healthcare information.
– FHIR is based on a set of basic modular components called Resources,
which are reusable patterns defined and represented in a common
way, based on a set of data types.
– Resources can be used by themselves, extended, or combined to
satisfy the majority of common user cases.
• FHIR approach is similar to the dual model approach
used in ISO13606 and openEHR.
– Both define reusable clinical models to describe clinical information.
– Main difference: Archetypes describe maximal datasets, as they aim
to document all the information about a given clinical domain. FHIR is
based on the 80-20 principle where an element will be included only
if 80% of the systems implement it.
5. 1. FHIR Resources as Archetypes
• For the generation of FHIR archetypes we must define a
Reference Model (RM) first.
• We derive FHIR RM automatically from the FHIR definition
(Ecore/XML Schemas)
6. 1. FHIR Resources as Archetypes
• The creation of the RM allows us to define FHIR archetypes
• These archetypes can be seen as FHIR Profiles or extended
Resources.
8. 2. Mapping to FHIR archetype
• Having available the FHIR RM allows us to generate data
transformation programs from the archetypes.
• Our data transformation programs assure the data follows
both the archetype constraints and the RM constraints.
– The mapping is made over an automatically created merged
archetype (archetype + RM). This merged archetype can be mapped
to a data source or another archetype.
9. 2. Mapping to FHIR archetype
XQuery program
Archetype-based data
FHIR data
10. 2. Mapping from FHIR archetype
• We can apply exactly the same methodology for the
transformation of FHIR resources and profiles to other
standards.
– FHIR archetypes can be used as a source of the mapping process.
• Seamless integration of FHIR data into current archetype-
based systems
11. 3. FHIR + Archetypes data server
• We reuse FHIR REST API for interacting with an archetype-
based server.
– In the parts of the API where the Resource name is used, the identifier
could be used in their place.
– Resources can define additional query parameters in the profiles. We
take advantage of this to support the definition of query parameters
for archetypes.
FHIR
Server
HL7 CDA
Server ISO13606
Server
FHIR
Wrapper
FHIR
RESTQuery
FHIR REST Query
FHIR REST Query
openEHR
Server
FHIR REST Query
12. 3. FHIR + Archetypes data server
• Proof of concept FHIR server
– Query using FHIR Resources or archetype identifiers
– Profiles can be generated from the archetypes in order to tell the
server the available query parameters.
• Test queries:
http://diebosto2.pc.upv.es:8080/FHIRServer/rest/test/openEHR-EHR-
OBSERVATION.blood_pressure.v1?systolic=>80&diastolic=<100
http://diebosto2.pc.upv.es:8080/FHIRServer/rest/test/openEHR-EHR-
EVALUATION.problem-diagnosis.v1?diagnosis=195967001
http://diebosto2.pc.upv.es:8080/FHIRServer/rest/test/Patient?
gender=M
13. Advantages
• Being able to check if a resource is valid against the reference
model (useful for evolving specifications as FHIR DSTU).
• Profile consistency is already solved.
• Lock down modeling optionality and vocabularies.
• Knowledge reuse.
• Multilinguality.
• Generation of derived reference materials (such as schematron,
JSON-Schema, mindmaps, sample formularies or implementation
guides).
• Use of AQL to query FHIR archetype based data.
• Reuse of current tooling for:
– Resource creation.
– Data transformation (legacy & non-legacy).
– Profile sharing and evolution.
14. Disadvantages
• In addition to XML, FHIR makes heavy use of JSON which is
not yet supported natively in our XML oriented
implementation.
• The narrative parts of FHIR (constraints over pseudo-HTML
code) are difficult to handle in archetypes
• Further upgrades and testing are needed to be compliant
with FHIR DSTU2.
15. Archetypes are in FHIR
• FHIR can be used in archetype based systems, using already
available methodologies and tools
• Archetype based systems can easily provide FHIR APIs to
create, retrieve, update, delete, and query an archetype
based system.
• This can be beneficial for both FHIR and archetype based
systems as allows FHIR enabled applications to use already
defined clinical models but also helps archetype based
systems to get more visibility in the HL7 world.
16. Diego Boscá Tomás
Grupo de Informática Biomédica (IBIME)
Instituto ITACA, Universitat Politècnica de Valencia, Spain
diebosto@ibime.upv.es
http://www.ibime.upv.es/