FHIR Chat · v2 <--> Mapping · implementers

Stream: implementers

Topic: v2 <--> Mapping

Grahame Grieve (Aug 19 2016 at 02:27):

one of the things I intended to work on in the lead in to Baltimore is using the mapping language for v2 --> FHIR mapping (or reverse)

Grahame Grieve (Aug 19 2016 at 02:29):

to do that, I need a FHIR logical model for v2. (actually, it doesn't need to be explicit, but making it explicit helps us communicate)

Grahame Grieve (Aug 19 2016 at 02:29):

there's 2 choices for the logical model. The first is some structure like this:

Grahame Grieve (Aug 19 2016 at 02:29):

message
  segment 0..*
    code 1..1
    field 0..*
      element 1..1
        component 0..*
          subcomponent 0..*

Grahame Grieve (Aug 19 2016 at 02:30):

the alternative is something like this:

Grahame Grieve (Aug 19 2016 at 02:31):

ADT_A01
  MSH
    MSH-1
  EVN
    EVN-1
    EVN-2
      EVN-2-1

Grahame Grieve (Aug 19 2016 at 02:31):

etc

Grahame Grieve (Aug 19 2016 at 02:32):

in the first, the message structures would be constraint profiles on the generic structure. Whereas in the second, you make the message structures explicit

Grahame Grieve (Aug 19 2016 at 02:35):

I think that the first approach is superior. I say that because this makes any v2 infrastructure we build more robust against variations from the spec - which are uibiqutious, and because the mappings would be robust across versions, even though it does make the mapping language a little more indirect

Grahame Grieve (Aug 19 2016 at 02:36):

this was kind of thinking out loud, but wanted to see if anyone had any opinions on this.

James Butler (Aug 19 2016 at 02:39):

Seems like the first might make it easier to express the uses of particular Z-segments, which would be nice

Grahame Grieve (Aug 19 2016 at 02:51):

yes first option would be more friendly to z segments

Stephen Royce (Aug 19 2016 at 03:20):

I prefer the first because it properly expresses a metamodel. I would have thought that would be more useful.

Grahame Grieve (Aug 19 2016 at 03:28):

it may be useful, but it's possible to have both models, and map on the basis of the second

Grahame Grieve (Aug 19 2016 at 03:28):

still, I prefer the first

Peter Jordan (Aug 19 2016 at 05:31):

From an OO perspective, the first looks like a class definition, the second an instance of that class. Which one is easier to use for mapping might depend on whether you're mapping to/from another class or another instance artifact - and whether the instances have additional attributes.

Grahame Grieve (Aug 19 2016 at 05:53):

well, the instances can't have additional attributes. Not in v2. It is the classical Reference Model/Constraint pattern. In v3 that had multiple layers and you picked which layer you wanted to treat as concrete.

Grahame Grieve (Aug 19 2016 at 05:53):

in v2, there's only 2 choices

Grahame Grieve (Aug 19 2016 at 05:53):

I suppose there's more, really, because you could define your own profile on the messages and make that concrete....

Peter Jordan (Aug 19 2016 at 06:18):

Looking at my old v2 message readers, I took a 2-stage approach. The first created a generic message object similar to your first model, the second parsed the message elements into recognisable business layer objects - patient, provider, observation, referral, etc. Those handlers work on the segment type which seemed more efficient than being concerned about the structure of the 100+ message types. However, if you're mapping to v2 then, of course, you have to create those structures. Still an each-way bet from me.

Lloyd McKenzie (Aug 19 2016 at 16:46):

I think the first is the only thing that's going to support z-messages, which we want to support too. It'll also easily work across past and future versions.

Eric Haas (Aug 26 2016 at 00:46):

Here is the FHIR logical model for v2
pasted image

Eric Haas (Aug 26 2016 at 00:47):

credits go to GG.

Grahame Grieve (Aug 26 2016 at 00:54):

thx Eric. So that's a candidate. I've generated profiles for all the segments for all the versions. I can send them to any one who's interested. In a couple of days time, I'll work on the data types. and then I'll look at doing standard mappings

Grahame Grieve (Aug 26 2016 at 00:55):

.component is a reference back to .content

Eric Haas (Aug 27 2016 at 06:06):

I've posted this model here

Eric Haas (Aug 27 2016 at 06:08):

click on the differential tab

David Fallas (Aug 30 2016 at 19:42):

Grahame - I'd be interested to have a look at those profiles you have generated. I'd be very grateful if you could send me a link.

Grahame Grieve (Aug 30 2016 at 20:56):

sent

Last updated: Apr 12 2022 at 19:14 UTC