fhir-profiling online workshop 11. maj 2020 kl. 09.30-11
TRANSCRIPT
FHIR-profiling online workshop
11. maj 2020
- Kl. 09.30-11.30
- Kl. 12.30-14.30
Hvis du har brug for at læse dette dokument i et keyboard eller skærmlæservenligt format, så klik venligst på denne knap.
2
Welcome
Kommuneteam Standardteam
Torben Mejlvang Hagensen, Mjølner
Jens Kristian Villadsen, Trifork
Agenda forenoon
• Welcome
• Announcements
• The process between May and December 2020– Version 0.9 related actions
• Testscripts on Touchstone
• UI Test protocol
• ”Connectathon”
– Version 1.0 related actions• Testscripts on Touchstone
• UI Test protocol
• Certification
– Feedback
• FHIR-messages in the Danish VANS infrastructure– The flows
– The VANS envelope
– The FHIR Acknowledgments
– Mappings (OIO XML til FHIR)
– Feedback
Agenda afternoon
• Welcome
• (continuation of forenoon agenda?)
• Presentation of FHIR IG solution
• Presentation of FHIR-profile ClinicalEmail
– Sections in FHIR KM
– ZULIP follow-up
– Feedback
• Presentation of FHIR-profile for HospitalNotification
– ZULIP follow-up
– Feedback
• Evt.
5
Announcements
6
Announcements
• Simplifier news v/Irene
• FHIR server(e) v/Irene
• Touchstone v/Ole
7
The process from now to October & December 2020
Ole Vilstrup, MedCom
8
The process from now until October 2020
• Medio/ultimo June – MedCom: Version 0.9 and examples
– MedCom: Version 0.9 of Clinical/UI Test Requirements protocol based on use cases
– Vendors: start development of 0.9 profiles including• Sending and receiving ClinicalEmail & HospitalNotification
• Sending and receiving acknowledgment
• August/September– MedCom: Touchstone/testscripts
• First testscripts on Touchstone ultimo August
• More testscripts on Touchstone ultimo September
– Hands-on workshop ultimo august/primo september on sending/receiving FHIR resources embedded in VANS Envelope based on the version 0.9
– MedCom & vendors: planning of October Connectathon and December certification
• October event(s)Feedback on Version 0.9 and examples
• Update requests for the profiles
– Feedback on working with Touchstone/testscripts• Update requests for the testscripts
– Feedback on working with Clinical/UI Test Requirements protocol• Update requests for the Clinical/UI Test Requirements protocol
– ”Connectathon”• Vendor systems exchange of profiles with each other
9
The process from November until December 2020
• November– MedCom: Version 1.0 and examples medio/ultimo November
– MedCom: Version 1.0 of Clinical/UI Requirements based on use cases medio/ultimo November
– Vendors: updating development of profiles accordingly including• Sending and receiving ClinicalEmail & HospitalNotification
• Sending and receiving acknowledgment
– MedCom: Touchstone/testscripts• Final testscripts/testscenarios on Touchstone early November
– Vendors: fullfilling expectations of testscripts/testscenarios
– MedCom & vendors: detailed planning of December certification
• December– December certification:
• Vendor systems fulfilling Technical requirements through testscripts in Touchstone
• Vendor systems fulfilling Clinical/UI requirements through visual presentation of system
10
Feedback
• EPJ leverandører:
– Systematic + brugerrepræsentanter
– EPIC + brugerrepræsentanter
• EOJ leverandører
– KMD Nexus + brugerrepræsentanter
– Cura + brugerrepræsentanter
– DXC Vitae + brugerrepræsentanter
– EG Sensum + brugerrepræsentanter
• KOMBIT beskedfordeler:
– MultiMed
– KMD
11
Message Communication
Envelope
Receipts/Acknowledgments
Ole Vilstrup, MedCom
12
Sygehus afsender FHIR
advis om sygehusophold
i VANS Envelope
EPJ 5
EPJ 1
EPJ 2
EPJ 3
EPJ 4
Regionale sygehuse(og privat hospitaler, hospices)
KOMBIT BeskedAgent
(MultiMed) 1.0
Udpakker FHIR advis fra VANS
Envelope og indpakker FHIR advis i KOMBIT beskedkuvert
KOMBIT Besked
Fordeler1.0
(KMD)
Advis er tilgængelig for modtager
systemer på KOMBIT beskedfordeler i
KOMBIT beskedkuvert
EOJ 1
EOJ 2
EOJ 3
EOJ 4 osv.
Kommuner
SAPA 1
SAPA 2
EOJ (og SAPA) modtager/henter
FHIR advis i KOMBIT beskedkuvert
SAPA 3
SAPA 4 osv.
Afsendelse af FHIR advis om sygehusophold
13
EOJ afsender FHIR kvittering i VANS
Envelope.SAPA kvitterer ikke
til afsender
EPJ 5
EPJ 1
EPJ 2
EPJ 3
EPJ 4
Regionale sygehuse(og privat hospitaler, hospices)
KOMBIT BeskedAgent
(MultiMed) 1.0
KOMBIT Besked
Fordeler1.0
(KMD)
EOJ 1
EOJ 2
EOJ 3
Kommuner
SAPA 1
SAPA 2
SAPA 3
EOJ 4 osv.
SAPA 4 osv.
Afsendelse af FHIR kvittering og VANS Envelope kvittering for sygehusadvis
KOMBIT Besked Agent sender positiv VANS
Envelope kvittering
14
Identifiers and sent time
Term OIO-XML FHIR VANS Envelope Comment
Envelope Identifier Emessage.Envelope.Identifier Bundle.Identifier VANSEnvelope.EnvelopeIdentifier
VANSEnvelope.EnvelopeIdentifier<>Bundle.Identifier !!!!!
Message Identifier Emessage.Envelope.<Messagetype>.Letter.Identifier
Bundle.MessageHeader.Identifier
VANSEnvelope.Message.MetaInformation.Identifier
VANSEnvelope.Message.MetaInformation.Identifier<>Bundle.MessageHeader.Identifier !!!!!
Envelope Sent Date & Time
Emessage.Envelope.Sent.DateEmessage.Envelope.Sent.Time
Bundle.Timestamp VANSEnvelope.SentDateTime
Message Date & Time Emessage.Envelope.<Messagetype>.Letter.Authorization.DateEmessage.Envelope.<Messagetype>.Letter.Authorization.Time
Bundle.MessageHeader.Identifier
N/A
Acknowledgment Emessage.Envelope.AcknowledgmentCode
VANSEnvelope.Message.MetaInformation.Transport.Type.value=reliable
15
Sender & Receiver
Term OIO-XML FHIR VANS Envelope Comment
Sender Emessage.Envelope.<Messagetype>.Sender
Bundle.entry:messageHeader.resource.sender -> Bundle.entry:messageOrganization
VANSEnvelope.SenderID.value
Receiver Emessage.Envelope.<Messagetype>.Receiver
Bundle.entry:messageHeader.resource.destination:primary -> Bundle.entry:messageOrganization
VANSEnvelope.ReceiverID.value
CCReciever Emessage.Envelope.<Messagetype>.CCReceiver
Bundle.entry:messageHeader.resource.destination:cc -> Bundle.entry:messageOrganization
VANSEnvelope.ReceiverID.value
In a separate copy of the message
16
Message metadata
Term OIO-XML FHIR VANS Envelope Comment
Messagetype Emessage.Envelope.<Messagetype>
Bundle.entry:messageHeader.resource.event[x]
N/A
Messagetype code Emessage.Envelope.<Messagetype>.Letter.TypeCode
<not decided upon yet> VANSEnvelope.Message.MetaInformation.Document.Name
Message version code Emessage.Envelope.<Messagetype>.Letter.VersionCode
<not decided upon yet> VANSEnvelope.Message.MetaInformation.Document.Version
Message statistical code Emessage.Envelope.<Messagetype>.Letter.VersionCode
<not decided upon yet> N/A
17
Acknowledgement (FHIR Level)(code system http://terminology.hl7.org/CodeSystem/v3-AcknowledgementType)
Code Display Definition
AAApplication Acknowledgement Accept
Receiving application successfully processed message.
AEApplication Acknowledgement Error
Receiving application found error in processing message. Sending error response with additional error detail information.
ARApplication Acknowledgement Reject
Receiving application failed to process message for reason unrelated to content or format. Original message sender must decide on whether to automatically send message again.
18
Acknowledgement (VANSEnvelope Level)(code system http://terminology.hl7.org/CodeSystem/v3-AcknowledgementType)
Code Display Definition
CAAccept Acknowledgement Commit Accept
Receiving message handling service accepts responsibility for passing message onto receiving application.
CEAccept Acknowledgement Commit Error
Receiving message handling service cannot accept message for any other reason (e.g. message sequence number, etc.).
CRAccept Acknowledgement Commit Reject
Receiving message handling service rejects message if interaction identifier, version or processing mode is incompatible with known receiving application role information.
20
”Bordet rundt” - tilbagemeldinger
• EPJ leverandører:
– Systematic + brugerrepræsentanter
– EPIC + brugerrepræsentanter
• EOJ leverandører
– KMD Nexus + brugerrepræsentanter
– Cura + brugerrepræsentanter
– DXC Vitae + brugerrepræsentanter
– EG Sensum + brugerrepræsentanter
• KOMBIT beskedfordeler:
– MultiMed
– KMD
21
FHIR Implementation Guide
Jens Kristian Villadsen, Trifork
22
FHIR Profile
ClinicalEmail
Torben Hagensen, Mjølner
23
Message Structure
Resources in the message are all placed in the entry element. This slide illustrates how they reference each other.
Message
• Sender
• Destination(s)
Content
• Patient
• Category
• Title
• Text(s)
• Author(s)
• Attachment
24
Questions from the Team
• The profile allows multiple text segments with separate timestamp and author
in the same message. This is a recommendation in XDIS91, but embedded in
the text.
– Is multiple text segments a known and useful use case?
– Is this recommendation supported in the systems?
25
Questions from chat.fhir.org #1
• Why is som elements constrained away in the profile?
– We try to keep the profile as open as possible for clinical information. The
composition has been constrained, because it specifies the structure. Having a
more constrained structure should ease the implementation in the systems.
– Please let us know if we should change this constraint on a specific element
• Why use a Composition and not a DocumentReference for clinical emails?
– DocumentReference is intended for metadata about a document, while a
composition is intended for structuring of the content.
• Is it correct that the “Signeret af” information in XDIS91 is represented by the
author references in the composition?
– Correct, employment (stillingsbetegnelse) and department (afdeling) is work in
progress
26
Questions from chat.fhir.org #2
• What are the expected linkages in Composition.relatesTo?
– relatesTo is allowed, but not constrained by the profile. Do not expect the recipient
to understand it unless you have made a bilateral agreement with the recipient
defining the how to use it.
• What is the intended use of type, category, and title?
– The type and title are mandatory elements in FHIR. We have chosen fixed values
to indicate that this is a clinical email. The category is a value set with the new
categories for clinical emails.
• Is the current ClinicalEmail/Letter/Authorization information to be sent in
Composition.section.section.extension.date?
– The date holds the date when the text section was authored
– The author holds the information about the author
27
Questions from chat.fhir.org #3
• Are the following no longer necessary? (Priority and EpisodeOfCareIdentifier)
– Priority is removed from the message, but might reappear in the general
messaging profile
– EpisodeOfCareIdentifier is present as an lpr-identifier
• What content types are expected? Are both JSON and XML allowed? Which
party determines the content type that should be used? The sender or the
receiver?
– We expect both types to be allowed. The sender thus decides the content type. It is
recommended to use a FHIR reference implementation to handle the format.
28
”Bordet rundt” - tilbagemeldinger
• EPJ leverandører:
– Systematic + brugerrepræsentanter
– EPIC + brugerrepræsentanter
• EOJ leverandører
– KMD Nexus + brugerrepræsentanter
– Cura + brugerrepræsentanter
– DXC Vitae + brugerrepræsentanter
– EG Sensum + brugerrepræsentanter
• KOMBIT beskedfordeler:
– MultiMed
– KMD
29
FHIR Profile
HospitalNotification
Irene Zuschlag, MedCom
30
Message Structure
Resources in the message are all placed in the entry element. This slide illustrates how they reference each other.
Message
• Sender
• Destination
Content
• Patient
• Responsible organization
• EpisodeOfCare identifiers
• Class and Status
• Period(s)
31
Questions from the Team
• The “AnswerTo” organization, is it always the responsible department ?
32
Questions from chat.fhir.org #1
• Question: Possible to map between OIOXML-FHIR ?
• Response:
Please refer to
http://svn.medcom.dk/svn/drafts/Standarder/HL7/FHIR/HospitalNotification/Baggr
undsmateriale/Map%20OIOXML%20FHIR.xlsx for a draft version for both
HospitalNotification and ClinicalEmail
33
Questions from chat.fhir.org #2
• Question: What is MedCom’s approach regarding FHIR profile mapping ?
• Response:
The Implementation Guide will be added information regarding the principles for
choosing some elements and eliminating others.
34
Questions from chat.fhir.org #3
• Question: Is it possible to have FHIR examples representing the different use-
cases ?
• Response:
On their way…
35
Questions from chat.fhir.org #4
• Question: Why is episodeOfCare Identifier not part of the messagHeader ?
• Response: The lpr3 identifier is related to an episodeOfCare identifier of an
Encounter, which is supported as is in FHIR
• Question: Is the cardinality of
Bundle.entry.MedComHospitalNotificationEncounter correct ?
• Response: No, it is on the to-do list for version 0.9
36
Questions from chat.fhir.org #5
• Question: Do you have any plans regarding how the FHIR profiles shall
replace the old OIOXML and Edifact messages ?
• Response: This question will be handled in another track
37
Questions from chat.fhir.org #6
• Question: Has patient consent requirements to send these notifications changed?
• Response: No, Danish law allows for sending HospitalNotification without consent
• Question: For leave of absence begin/end notification, is a treatment
complete/treatment resume sent just prior to it?
• Response: No, the treatment is not necessary ended because a patient is sent on
leave and therefore a treatment resumed is not transmitted.
38
Questions from chat.fhir.org #7
• Question: Should pending discharge datetime be sent in admission
notification if known?
• Response: Yes
39
Questions from chat.fhir.org #8
• Question What other recipients can these notifications be sent to besides municipalities?
• Response: At present only the municipalities are receiving the HospitalNotification
• Question: How is a referral hotel represented as a recipient organization?
• Response: ?
40
Questions from chat.fhir.org #9
• Question: For corrections and cancelations, is the "forløbsID" in "Der anvendessamme forløbsID, som ved det først sendte advis[STIN]." the Encounter.EpisodeOfCare.identifier?
• Response: The “forløbsID” is the Encounter.EpisodeOfCare.identifier
• Question: Are there plans for a MedCom test system to use for testing FHIR messages?
• Response: Yes! Please hang on….
41
42
43
ClinicalEmail cont.
44
FHIR Map – Version and Message Id
XD9134L
XDIS91
45
FHIR Map – Autorisation Date and Time
MessageHeader?
???
46
FHIR Map – Answer To
MessageHeader.responsible?
Encounter.serviceProvider?
47
FHIR Map – Sender Department
Encounter.serviceProvider?
MessageHeader.sender.organisation.endpoint?
???
48
FHIR Map – Episode Of Care Status
Encounter.class?
???
49
Mapping of HospitalNotification Codes
- allOprindelig
kode DK EnglishEncounter.Class Encounter.Status Encounter.-
ClassHistory.Class
Encounter.-
StatusHistory.Status
Patient.-
Deceased
STAA Start emergency Emergency in-progress N/A N/A
STIN Start inpatient encounter inpatient in-progress N/A N/A
SLHJ End inpatient encounter emergency/inpatient finished emergency/inpatient finished
STOR Start leave of absence emergency/inpatient on-leave emergency/inpatient in-progress
SLOR End leave of absence emergency/inpatient in-progress emergency/inpatient on-leave
MORS Deceased emergency/inpatient finished emergency/inpatient ”Any status” true
AN_STAA Cancellation of start emergencyEmergency cancelled
/entered-in-error
Emergency cancelled
/entered-in-error
RE_STAA Update of start emergency emergency in-progress emergency in-progress
AN_STINCancellation of start patient
encounter
inpatient cancelled
/entered-in-error
inpatient cancelled
/entered-in-error
RE_STINUpdate of start patient
encounter
inpatient in-progress inpatient in-progress
AN_SLHJCancellation of end inpatient
encounter
emergency/inpatient in-progress emergency/inpatient in-progress
RE_SLHJUpdate of end inpatient
encounter
emergency/inpatient finished emergency/inpatient finished
AN_STORCancellation of start leave of
absence
emergency/inpatient in-progress emergency/inpatient in-progress
RE_STOR Update of start leave of absence emergency/inpatient on-leave emergency/inpatient on-leave
AN_SLORCancellation of end of leave of
absence
emergency/inpatient on-leave emergency/inpatient on-leave
RE_SLORUpdate of end of leave of
absence
emergency/inpatient in-progress emergency/inpatient in-progress
AN_MORS Cancellation of deceased emergency/inpatient in-progress emergency/inpatient in-progress
RE_MORS Update of deceased emergency/inpatient finished emergency/inpatient finished true
50
Mapping of HospitalNotification Codes
- inpatient
Oprindelig
kode DKDansk English Encounter.Class Encounter.Status
Encounter.
ClassHistory.Class
Encounter.
StatusHistory.Status
STINStart sygehusophold - Akut
AmbulantStart emergency
inpatient in-progress n/a n/a
AN_STIN Annullering af hospitalsopholdCancellation of start
emergency
Inpatient cancelled
/entered-in-error
inpatient in-progress
RE_STINRettelse af akut ambulant
ophold
Update of start
emergency
inpatient in-progress inpatient in-progress
SLHJSlut sygehusophold - afsluttet
til hjemmetEnd inpatient encounter
inpatient finished inpatient in-progress
AN_SLHJAnnullering Slut
sygehusophold
Cancellation of end
inpatient encounter
inpatient finished inpatient finished
RE_SLHJ Rettelse Slut sygehusopholdUpdate of end inpatient
encounter
inpatient finished inpatient finished
51
Mapping of HospitalNotification Codes
- emergency
Oprindelig
kode DKDansk English Encounter.Class Encounter.Status
Encounter.
ClassHistory.Class
Encounter.
StatusHistory.Status
STAAStart sygehusophold - Akut
AmbulantStart emergency
emergency in-progress n/a n/a
AN_STAA Annullering af hospitalsopholdCancellation of start
emergency
emergency cancelled
/entered-in-error
emergency in-progress
RE_STAARettelse af akut ambulant
ophold
Update of start
emergency
emergency in-progress emergency in-progress
SLHJSlut sygehusophold - afsluttet
til hjemmetEnd inpatient encounter
emergency finished emergency in-progress
AN_SLHJAnnullering Slut
sygehusophold
Cancellation of end
inpatient encounter
emergency finished emergency finished
RE_SLHJ Rettelse Slut sygehusopholdUpdate of end inpatient
encounter
emergency finished emergency finished
52
Mapping of HospitalNotification Codes
- leave of absence
Oprindelig
kode DKDansk English
Encounter.Clas
sEncounter.Status
Encounter.
ClassHistory.Class
Encounter.
StatusHistory.Status
STOR Start orlov Start leave of absence inpatient on-leave n/a n/a
SLOR Slut orlov End leave of absence inpatient in-progress inpatient on-leave
AN_STORAnnullering start
orlov
Cancellation of start
leave of absence
inpatient in-progress inpatient on-leave
RE_STOR Rettelse Start orlovUpdate of start leave of
absence
inpatient on-leave Inpatient on-leave
AN_SLORAnnullering Slut
orlov
Cancellation of end of
leave of absence
inpatient on-leave inpatient on-leave
RE_SLOR Rettelse Slut orlovUpdate of end of leave
of absence
inpatient in-progress inpatient in-progress
53
Mapping of HospitalNotification Codes
- deceased
Oprindelig
kode DKDansk English Encounter.Class Encounter.Status
Encounter.
ClassHistory.Class
Encounter.
StatusHistory.Status
MORS Død Deceasedemergency
/inpatient
finished emergency
/inpatient
any
AN_MORS Annullering af DødCancellation of
deceased
emergency
/inpatient
in-progress emergency
/inpatient
any
RE_MORS Rettelse af Død Update of deceasedemergency
/inpatient
finished emergency
/inpatient
finished
54
”Bordet rundt” - tilbagemeldinger
• EPJ leverandører:
– Systematic + brugerrepræsentanter
– EPIC + brugerrepræsentanter
• EOJ leverandører
– KMD Nexus + brugerrepræsentanter
– Cura + brugerrepræsentanter
– DXC Vitae + brugerrepræsentanter
– EG Sensum + brugerrepræsentanter
• KOMBIT beskedfordeler:
– MultiMed
– KMD
55
Thanks for today