1 of 48

Please stop buying yesterday’s �'all inclusive' Health IT-systems!�

HI Conversations

13 Jun 2024 @ Karolinska Institutet (online lunch seminar)

Erik Sundvall,

PhD Medical Informatics, MSc Information Technology / Computer Science

Affiliated researcher @ HIC, LIME, Karolinska Institutet (My role during this seminar, and e.g. when teaching at KI)

Information architect @ Karolinska University Hospital, Region Stockholm (Main job)

Adjunct Senior Lecturer in Medical Informatics @ IMT, Linköping University

2 of 48

Scaling things. Sustainability?�What limits adoption/use?

  • Patient overviews�(need standardisation of data structure and terminology use - to be possible at all & to be adopted at scale)
  • Scaling storage solutions
  • Scaling local ecosystem beyond one vendor �– openEHR RESTful APIs to simplify vendor neutral ecosystem (2010, before FHIR…)��
  • Now: Why are scalable solutions not used? �How go from research to practical use at healthcare providers?
    • Lack of knowledge? Cure: Education (?)
    • Purchasing/procuring based on yesterday’s assumptions? Cure: ???How can we help buyers (and the market/ecosystem) in a sustainable direction?

2

My journey as a researcher…

3 of 48

Interoperability basics: Agree where?

Karolinska Institutet – A medical university

3

16 December 2021

See presentation Introduction to openEHR, part 1: What & Why” by Silje & Erik at Vitalis/MIE2023 https://youtu.be/KgXVsIsr_Ts?feature=shared&t=774

EHR = Electronic Health Record

4 of 48

What can conversion/reinterpretaion solve?

Karolinska Institutet – A medical university

4

16 December 2021

5 of 48

Reinterpretation problems, Type I, II & III

Example

System A

System B

Type I�A <-- --> B �Can be done with algoritm/program

Birth weight: 3300g�Date: 1954-03-13

Body weight: 3,3 kg�Timepoint: 13 Mar 1954

Type II

A --> B�Semantic loss and distortion �due to reinterpretations.

Hard, dangerous or impossible with algorithm/program…

…but often done manually �by medically skilled staff�over and over for each transfer…

B --> A�Missing information�impossible with algorithm/program

Needs surgery at latest: 2018-01-30�Surgery scheduled: 2018-01-20 15:30�Main diagnose*:

323291000119108 | Osteoarthritis of left hip joint|�Other Diagnosis*: �25343008 | Secondary localized osteoarthrosis of pelvic region|�299308007 | Hip joint painful on movement | �Procedure*: �19954002 | Reconstruction of hip with use of methyl methacrylate|�Surgery type**: Lubinus SP II �Preferred anesthesia*: 18946005 | Epidural anesthesia |�NEWS2-score at admission: 1�Anesthesia assessment:�- Fitness: can handle light physical exercise�- Cardiovascular: OK�- Lungs: OK�- Throat: OK�- Gastrointestinal*: 16331000 | Heartburn

Surgery date: 2018-01-20�Diagnosis code: M16.7 | Other secondary coxarthrosis�Surgery code***: NFB49 | Primär total höftledsplastik med cement (Primary total hip arthroplasty with cement)�Anesthesia code***: ZXH50 | Epiduralanestesi (epidural anestesia)�ASA-classification: ASA I = normal healthy patient�

*)  Codes from Snomed CT�**) special kind of hip replacement� with cement�***) Codes from the Swedish ”KVÅ”� terminology

Type III�Reinterpretaion impossible (even for skilled humans) due to aggregations etc.

Number of cigarettes smoked per week: 6-10�…specified in a system with the options:�0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+

Number of cigarettes per week: ?�…specified in a system with the options:

0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

6 of 48

Reinterpretation problems, Type I, II & III

Example

System A

System B

Type I�A <-- --> B �Can be done with algoritm/program

Birth weight: 3300g�Date: 1954-03-13

Body weight: 3,3 kg�Timepoint: 13 Mar 1954

Type II

A --> B�Semantic loss and distortion �due to reinterpretations.

Hard, dangerous or impossible with algorithm/program…

…but often done manually �by medically skilled staff�over and over for each transfer…

B --> A�Missing information�impossible with algorithm/program

Needs surgery at latest: 2018-01-30�Surgery scheduled: 2018-01-20 15:30�Main diagnose*:

323291000119108 | Osteoarthritis of left hip joint|�Other Diagnosis*: �25343008 | Secondary localized osteoarthrosis of pelvic region|�299308007 | Hip joint painful on movement | �Procedure*: �19954002 | Reconstruction of hip with use of methyl methacrylate|�Surgery type**: Lubinus SP II �Preferred anesthesia*: 18946005 | Epidural anesthesia |�NEWS2-score at admission: 1�Anesthesia assessment:�- Fitness: can handle light physical exercise�- Cardiovascular: OK�- Lungs: OK�- Throat: OK�- Gastrointestinal*: 16331000 | Heartburn

Surgery date: 2018-01-20�Diagnosis code: M16.7 | Other secondary coxarthrosis�Surgery code***: NFB49 | Primär total höftledsplastik med cement (Primary total hip arthroplasty with cement)�Anesthesia code***: ZXH50 | Epiduralanestesi (epidural anestesia)�ASA-classification: ASA I = normal healthy patient�

*)  Codes from Snomed CT�**) special kind of hip replacement� with cement�***) Codes from the Swedish ”KVÅ”� terminology

Type III�Reinterpretaion impossible (even for skilled humans) due to aggregations etc.

Number of cigarettes smoked per week: 6-10�…specified in a system with the options:�0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+

Number of cigarettes per week: ?�…specified in a system with the options:

0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

7 of 48

Reinterpretation problems, Type I, II & III

Example

System A

System B

Type I�A <-- --> B �Can be done with algoritm/program

Birth weight: 3300g�Date: 1954-03-13

Body weight: 3,3 kg�Timepoint: 13 Mar 1954

Type II

A --> B�Semantic loss and distortion �due to reinterpretations.

Hard, dangerous or impossible with algorithm/program…

…but often done manually �by medically skilled staff�over and over for each transfer…

B --> A�Missing information�impossible with algorithm/program

Needs surgery at latest: 2018-01-30�Surgery scheduled: 2018-01-20 15:30�Main diagnose*:

323291000119108 | Osteoarthritis of left hip joint|�Other Diagnosis*: �25343008 | Secondary localized osteoarthrosis of pelvic region|�299308007 | Hip joint painful on movement | �Procedure*: �19954002 | Reconstruction of hip with use of methyl methacrylate|�Surgery type**: Lubinus SP II �Preferred anesthesia*: 18946005 | Epidural anesthesia |�NEWS2-score at admission: 1�Anesthesia assessment:�- Fitness: can handle light physical exercise�- Cardiovascular: OK�- Lungs: OK�- Throat: OK�- Gastrointestinal*: 16331000 | Heartburn

Surgery date: 2018-01-20�Diagnosis code: M16.7 | Other secondary coxarthrosis�Surgery code***: NFB49 | Primär total höftledsplastik med cement (Primary total hip arthroplasty with cement)�Anesthesia code***: ZXH50 | Epiduralanestesi (epidural anestesia)�ASA-classification: ASA I = normal healthy patient�

*)  Codes from Snomed CT�**) special kind of hip replacement� with cement�***) Codes from the Swedish ”KVÅ”� terminology

Type III�Reinterpretaion impossible (even for skilled humans) due to aggregations etc.

Number of cigarettes smoked per week: 6-10�…specified in a system with the options:�0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+

Number of cigarettes per week: ?�…specified in a system with the options:

0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

8 of 48

Agree on what, where? How wide is the focus of the procurement?

Karolinska Institutet – A medical university

8

16 December 2021

Type I can be �solved here

Type II & III must �be solved here�also solves type I

Type II & III must �be solved here�also solves type I

9 of 48

Agree on what, where?

9

Type I can be �solved here

Type II & III must �be solved here�also solves type I

Type II & III must �be solved here�also solves type I

Fax is a common workaround today

10 of 48

Agree on what, where?

10

Type I can be �solved here

Type II & III must �be solved here�also solves type I

Type II & III must �be solved here�also solves type I

Many reinterpretation problems remain even if fax is replaced by PDF sharing…

…but may become less visible

11 of 48

Different knowledge and assumptions of possible…�standardisation & integration strategies� …enable different procurement strategies

  • Core system strategy
  • Mapping/conversion-based strategy
  • Shared, model-driven strategy ☺

Karolinska Institutet – A medical university

11

12 of 48

Agree on what, where?

Karolinska Institutet – A medical university

12

13 June 2024

Type I can be �solved here

Type II & III must �be solved here�also solves type I

Type II & III must �be solved here�also solves type I

Data capture�(openEHR etc)

Data transfer�(HL7 FHIR etc.)

Data capture�(openEHR etc)

13 of 48

Standardisation strategies 🡪 procurement assumptions

  • 1. Core system strategy
    • Buy the same system, install the same way at all organizations that will share or exchange information.Pretend “there is no system B”
  • 2. Mapping/conversion based strategy
    • Translate, where possible from system specific semantics and structures to a standardized exchange format (message format, API, etc.). �Only works for ”type 1” differences

  • 3. Shared model-driven strategy
    • Handle data (semantics and information structure) the same way �within systems using open standardization of the content.��

Source: The Swedish ”StandIN”-projects

Data capture�(openEHR etc)

Data transfer�(HL7 FHIR etc.)

Supplier’s proprietary models

14 of 48

1. Core system strategy

Buy the same system, install the same way at all organizations that will share or exchange information. Pretend “there is no system B”

Consequence: Causes vendor dependency and anti-competitive effects at the level where the strategy is applied. A single system rarely does everything well.

It is a common strategy locally/regionally: Large systems exist, but they are not comprehensive and thus need to be combined with other strategies �… and then the interoperability problems usually reappear!

Example: A region procures large EHR system + encourages municipalities and others within the geographic area to use the same system for the information to be shared.

Stockholm started but cancelled a core system procurement, but now in practice started a �”smaller” core system procurement again.... VGR (Gothenburg etc) and Skåne (Malmö etc) �have bought and are now installing Cerner Millenium as a core system but will also use �other systems.

15 of 48

2. Mapping/conversion based strategy

Translate, where possible (only works for ”type 1” differences), from system specific semantics and structures to a standardized exchange format (message format, API, etc.).

Consequences:

  • Reinterpretations increase risk of loss or distortion of information, �Data that is too different may need to be omitted (Sometimes no data may be better than incorrect data…)
  • Can sometimes require health-IT systems to be rebuilt internally to be able to capture and export required shared data in some agreed form (This can be expensive, time/resource consuming, and dependent on vendors’ priorities).

It is a common strategy today in national cross-regional information exchanges.

Examples: HL7 v2, HL7 v3 CDA, HL7 FHIR, certain applications of ISO 13606, Swedish national "service contracts" in the service platform coordinated by SKR/Inera.

16 of 48

3. Shared model-driven strategy

Handle data (semantics and information structure) the same way �within systems using open standardization of the content.

Consequences:

  • facilitates vendor independence
  • limits selection to products that can internally use the open standardized models, or that can be configured flexibly enough to broadly match the standardized

Used today in the Nordic region in components of several EHR systems (but is rarely a requirement in procurements). Further development is underway at several suppliers, including open-source alternatives

Main example: openEHR

Will Region Stockholm choose this? Karolinska University Hospital already uses an openEHR based system for some use cases and will change openEHR- system supplier soon.��Most Swedish regions use or will use Cambio Cosmic that is piece by piece converting�modules to openEHR (Norwegian DIPS started such a transition several years ago.)

17 of 48

The three integration strategies combined

Not mutually exclusive and can be combined depending on e.g.

  • Geographical granularity �(international, national, regional and local)
  • Timeframe – gradual changes�(1 year, 5 years, 20 years)

Karolinska Institutet – A medical university

17

16 December 2021

18 of 48

Source: Martin Grundberg, Cambio, https://www.cambio.se/

Data capture�(openEHR etc)

Supplier’s proprietary models

Data transfer?�(HL7 FHIR etc.)

Supplier’s proprietary models

+

1. Core system strategy

(”Monolith”/all-inclusive)

2. Mapping/conversion based strategy

3. Shared model-driven strategy

19 of 48

Let’s compare!

Best of Breed 2.0 already partially done for medical images (PACS) etc

Karolinska Institutet – A medical university

19

16 December 2021

20 of 48

The way it used to be…

Documents�(Scanned, fax, PDF etc)

Image data�(X-ray, ultrasonic imaging, �MR, potos etc.)

Structured data�(from EHR forms etc)

Illustrations based on images from Better, https://www.better.care/

21 of 48

The way it used to be…

Illustrations based on images from Better, https://www.better.care/

22 of 48

Then we shared image and document storage…

Structured data�(from EHR forms etc)

often still not standardised

and thus stuck in

each different system

Illustrations based on images from Better, https://www.better.care/

23 of 48

A goal

Illustrations based on images from Better, https://www.better.care/

24 of 48

Another reason: Speed! ..by sharing the workload�Information models take time to create - if they are to work well for everyone.

24

Library and collaboration portal for archetypes, templates, etc. https://ckm.openehr.org/

Positive side effects:

  • Easier to share decision support, applications and data (e.g. for research)
  • Reduces supplier lock-in
  • Faster updates

Reuse!�Share the requirements gathering, analysis and information modeling. (globally!

25 of 48

Archetypes (arketyper)�Reusable documentation patterns

Template (mall)�Specific to a use case.�Combines and configures multiple archetypes.

Form (formulär/gränssnitt)�Autogenerated from template, then manually adjusted

26 of 48

Illustration based on content from:�Rector AL, Rogers J, Taweel A. �Models and inference methods for clinical systems: a principled approach. �Stud Health Technol Inform. 2004;107(Pt 1):79-83

2004

Generally applicable knowledge

Terminology systems. �ICD-10, SNOMED CT etc.

Documentation of what has been done, observed, planned etc. �openEHR, FHIR etc.

Decision support rules, AI etc.

27 of 48

SNOMED CT, an example of a polyhierarchy, where every concept can have multiple ”parents”…

…and many other kinds of relations between concepts

Rector AL, Rogers J, Taweel A. �Models and inference methods for clinical systems: a principled approach. �Stud Health Technol Inform. 2004;107(Pt 1):79-83

28 of 48

How Karolinska University Hospital views standards in the data life cycle. Any may be useful for a given purpose, depending on the need and relevant constraints.

28

“Gartner believes that truly effective and sustainable open architectures will need a capability for vendor-neutral data persistence, such as utilizing a common schema or set of openEHR archetypes and rules for managing structured and unstructured data (for example, a VNA, openEHR or IHE XDS repository in combination with services for trust/consent, ecosystem governance and oversight, and reuse of data and processes for secondary purposes, such as research and population health).

Providing open messaging standards (for example, FHIR, HL7) for data exchange in specific use cases will only go so far in meeting the architectural challenges of digital citizen-centric care delivery”

Healthcare Provider CIOs Need to Rally Their Enterprise Architects Around Citizen-Centric Care Delivery, Gartner 2017

Extended from a slide by Patrik Georgii-Hemming, CMIO at Karolinska University Hospital

OMOP etc.

Most of the proprietary �EHR internal models

All these standards can be combined with

29 of 48

Public Procurement – avoids corruption?�Not simpler (not always cheaper)

The basic procurement principles are: 

    • non-discrimination
    • equal treatment
    • proportionality
    • transparency
    • mutual recognition

They mean that procuring organisations must always remain objective and neutral to the stakeholders that wish to become suppliers, and the entire procurement process must be characterised by transparency and proportionality.

29

30 of 48

Public Procurement – avoids corruption?�Not simpler (not always cheaper)

Too common today:

  • What did others pick (without getting fired)?
  • The procurement (ir)responsible just want to finish the procurement project and go on to new positions/projects… �…but the harder implementation, integration and maintainance work is dumped on others [Stockholm 3rd/4th attempt now…]
  • Pick your favourite and bend the procurement requrements to fit it? [High corruption risk masked as !]

More sustainable:

Maintaining long term healthty competition – we want many experienced suppliers to pick from

Dilemmas - risks to handle/mitigate:

Encourage new suppliers� vs �Not become alpha testers of�immature products

30

31 of 48

If going for ”Shared model-driven strategy” – are there any good ”open” systems to buy?��(Spoiler: Yes!)

31

32 of 48

openEHR is nowadays a well established possibility

32

33 of 48

2023, seven Swedish regions, RFI (Request for information)

  • Very low legal risks for all parties…
  • …but still consumes time/resources from all parties, including suppliers
  • Collaborate to save time/resources that could be used for important things!

33

34 of 48

What did the RFI 2023 participants do next?

  • Region Skåne will 2024 start a proof of concept focused on laboratory results.
  • Region Stockholm + Gotland procurement 2023/2024 (see next slide)��
  • An idea was born about the possibility of a national freamework agreement or similar for platforms (with tools/accessories) for standardization (openEHR, Snomed CT, FHIR)

35 of 48

Stockholm/Gotland procurement, coordinated by Karolinska, �Three (3) procurement areas

  1. openEHR-based Software.
  2. Software for openEHR content Creation and Transformation
  3. Consulting Services
  4. https://discourse.openehr.org/t/karolinska-stockholm-procurement-of-digital-health-platform-cdr-tools-services-consultants/4457
  5. Was based on collaboration! Cross-regional question-bank based on previous work in Sweden, Germany, Great Britain. Will be openly published.

35

36 of 48

Catalonia, Spanish region, 8 million inhabitants

Procurement-related activities

Contrast: (Stockholm) risk for old style ”all inclusive”, 12-16 years? I hope I am wrong in�https://www.linkedin.com/feed/update/urn:li:activity:7057401873397334018/

Catalan 25-year retrospective https://preprints.jmir.org/preprint/58933

37 of 48

Managing lock-in effects - A telephone analaogy

  1. Telecom operator (Vodaphone, Telia, …)
    • Number portability (keep your old phone number when switching) crucial!
    • Minor capability differences (but sometimes important, like rural coverage)
  2. Operating system (iOS, Android, …)
    • Not as standardised as GSM/3G/4G/5G
  3. Important applications
    • Things with very standardised content, like mail clients, can be switched
    • App versions for each operating system can be made
      • By others, e.g. for commercial apps like Spotify, LinkedIn, …
      • By yourself for ”homegrown” apps
      • By you and others in collaboration (e.g. open source apps)

  1. openEHR CDR (used via standard APIs) …and having control of your own template- and archetype usage
  2. Form/Low-code tools, integration tools, portals etc*
    • Very limited openEHR standardisation for this now, but SMART on openEHR (draft) and some simplified integration formats are available
  3. Important applications
    • App versions or components for each vendor specific portal/framework can be made
      • By others
      • By yourself for ”homegrown” apps
      • By you and others in collaboration (e.g. open source apps)

  • *) Freestanding apps using the CDR via APIs can skip using tools and some parts of portals/frameworks (in #2 above)

37

38 of 48

What if you/someone bought an �”all inclusive” system anyway?

38

39 of 48

Not necessarily evil, it’s just very hard to maintain and quickly improve a giant system

39

…but openEHR system content is 100% open by design 🡪 no need to increase APIs by 300%

40 of 48

  • Actors betting on long term sustainable, scalable solutions
  • Educated citizens (consumers?), willing to contribute to solutions!
  • Educated leaders daring to choose and support sustainiable solutions?

How change?

41 of 48

41

years

months

Health IT organizations & vendors are often slower than Gartners average system examples (perhaps due to complexity, regulations etc?)

Region Östergötland

41

42 of 48

Reliability+Agility? Quality+Speed/Innovation? Bimodal IT (1+2)�Finding suitable abstraction layers and suitable management (people+process)…

Specifications, e.g.: XML,

XML Schema (the ”language”),

XPath & XQuery

General XML database systems

XML Schema V (national?)

XML Schema U

General XML Tools (editors, processors etc)

XML Schema Y using V+W

X instances

Software manipulating/using X instances

XML Schema X using U+V

XML Schema W (international?)

Y instances

Rule engines

Rules & data flows

Spreadsheet

Software

(e.g. Excel)

Spreadsheet

template, e.g.

time report

for company X

Mr Smith’s

time report

for June

(an instance)

Specifications, e.g.:

-Reference Model (RM),

-Archetype Model (AM),

-AQL (query language)

-GDL (decision support lang.)…

EHR storage system RM+AQL+…

Archetype V (national?)

Archetype U

Archetype W (international?)

Template Y using V+W

Template X using U+V

Tools, editors…

http://www.gartner.com/it-glossary/bimodal/

GUIs generating/reading/querying instances

Region Östergötland

42

43 of 48

Support

Sys. admin

Customer group

Delivery

Release mgmnt. Programming

Test

Configuration

Roll-out (during planned service ”windows”)

Find/create archetypes�Create template

Create form/GUI�incl. dynamic via ”low code”

Sometimes: Modify or create CDS rules

Upload to system�(”live” in an active system)

Test and quality control

Sometimes: Extra programming & optimisations

Mode 1

”Marathonl”

Mode 2

”Sprint”

Adjusting related systems (integrations

Statistical reports etc)

Custromer repr.�Investigation

Prioritisation

Pre-study

GUI/client-design

API-design

Database design

Objekt-modelling

Mode 1

”Maratonlöpare”�Stabil informatik och teknisk grundplattform

Tech sys. administration and improvement�of CDR and tools

Mode 2

”Sprinter”, delar�konfigurerbara av verksamhet

44 of 48

Support

Förvaltning

Kundgrupp

Leverans

Releasehantering�Programmering

Test

Konfiguration

Utrullning (servicefönster för planerade driftstopp)

Leta/skapa arketyper�Skapa template

Skapa formulär/GUI och ”task planning” �inkl. dynamik m. ”low code”

Ev. Modifiera/skapa beslutsregler

Ladda in i system�(”live” i aktivt system)

Test/granskning�Ev. kompletterande programmering och optimering

Mode 1

”Maratonlöpare”

Mode 2

”Sprinter”

Anpassning av kringsystem

(integrationer

Statistik, uppföljning)

Kundkontakt�Utredning

Prioritering

Förstudie

GUI/klient-design

API-design

Databasdesign

Objekt-modellering

Mode 1

”Maratonlöpare”�Stabil informatik och teknisk grundplattform

Teknisk förvaltning av grundplattform och ”verktygslåda”

Mode 2

”Sprinter”, delar�konfigurerbara av verksamhet

https://youtu.be/RYTmMQJFpAc?t=718

"...still many organizations choosing ... traditional route and we know that this will be the last cohort adopting this… already a legacy technology… not going to be what we use in the future"

  • Actors betting on long term sustainable, scalable solutions
  • Educated clinicians…?, willing to contribute to solutions…?
  • Educated leaders daring to choose and support sustainable scalable solutions…?

https://youtu.be/RYTmMQJFpAc

How change?

45 of 48

45

46 of 48

’all-inclusive side effects’

The transition to a monolith EHR usually uses up resources and stalls most other development during years. An “all-inclusive effect” often starts already when buying a monolith is considered, and then continues during the lifetime of the contract. The “all-inclusive effect” is a combination of economic lock-in, transition fatigue and integration difficulties. It is often expressed in terms like

“Yes, the monolith does not support your clinical IT-need X very well yet, but the system supplier has promised to improve, please don’t suggest/consider any objectively better competing solution. We are already bound in a 12-year contract paying for the monolith’s (possibly inferior) functionality covering need X. Also, it was a pain to do the transition and integrations so we won’t have energy and resources even if the competing solution would be free or cheap.”

46

47 of 48

Questions? Discussion!��(Swedish slide about integration details follows)

47

48 of 48

Mer om långlivad data t.ex. från system som avvecklas

PoC TakeCare

Färgkodning av sannolik destinationsmodell: �CKM-arketyper, Blandning, Integrationsarketyper, FHIR

  • Läkemedel - Exchange: MedicationHistory (XML), tydligt API
  • Journaltext - Exchange: CasenoteRead (XML), tusentals mallar+sökord
  • Kemlabb - Juno (JSON), finns en hel del modellering och mappning klar.
  • Mätvärden - Juno (JSON) använder mallar, 1000-tals olika mätvärdesmallar i prod
    • Automatgenerera integrationsarketyper för alla mätvärden samt kopiera även över vissa till CKM-arketyp-baserat format inklusive länk tillbaka till motsvarande integrationsarketyp-baserade?
    • Potentiell specialare: räkna ut NEWS totalpoäng vid konvertering?
  • Aktiviteter (använder bara termkatalogen, inte mallar) - Juno REST (JSON)
  • "Råa" bokningar - Juno (JSON) Rådata-dump kan nås kan passa i FHIR

48

”Integrations-arketyper”

”CKM-arketyper”

”klassisk” manuell mappning

System som ska avvecklas

Översikt/visualiseringar (ev. specialanpassade)

API & verktyg

Journalhandlings-visare m. sökfunktion

Datauttag, arkivärenden etc.

Kan göras senare, vid behov. AI-stött?

Tekniska implementationsdetaljer: delarna märkta ”Switch” och ”EHR Repostory” kan, om så önskas, vara del av samma CDR, men flaggade/märkta på ett sätt så att man enkelt vid anrop (exempelvis AQL-sökfrågor) kan välja om man vill ha svar bara från en specifik del eller båda.