Someone asked me for my opinion on adopting STU3 resources in an environment that presently supports STU2. At first this seems to be quite challenging. But then, as I thought about it, the following idea occurred to me:
It would be a simple matter of engineering to take an STU3 StructureDefinition, and re-write it as an STU2 StructureDefinition that is a profile on an STU2 Basic resource. Such a structure definition would be ideally suited for transfer to an STU3 environment when it is available, but would work in an existing STU2 environment today.
It eliminates one of my objections to pre-adoption of new resources, uses the Basic resource in a way it is intended to be used (to prototype new stuff), and provides a useful way to test new stuff in existing environments.
I don't have the time personally to write such a tool, but would love to see someone take up this gauntlet I just threw down.
-- Keith
P.S. Such a tool could also support changed resources, if the tooling was smart enough to understand certain kinds of changes. It could create extensions for new fields added, restrict fields that are removed, and ignore those for which there were simple name changes (detectable perhaps through a combination of w5, V2 and V3 mappings).
It would be a simple matter of engineering to take an STU3 StructureDefinition, and re-write it as an STU2 StructureDefinition that is a profile on an STU2 Basic resource. Such a structure definition would be ideally suited for transfer to an STU3 environment when it is available, but would work in an existing STU2 environment today.
It eliminates one of my objections to pre-adoption of new resources, uses the Basic resource in a way it is intended to be used (to prototype new stuff), and provides a useful way to test new stuff in existing environments.
I don't have the time personally to write such a tool, but would love to see someone take up this gauntlet I just threw down.
-- Keith
P.S. Such a tool could also support changed resources, if the tooling was smart enough to understand certain kinds of changes. It could create extensions for new fields added, restrict fields that are removed, and ignore those for which there were simple name changes (detectable perhaps through a combination of w5, V2 and V3 mappings).
the Java reference implementation already includes exactly the tool you're thinking of, and it will be in the next HAPI release. See here: http://gforge.hl7.org/svn/fhir/trunk/build/implementations/java/org.hl7.fhir.convertors/src/org/hl7/fhir/convertors/VersionConvertor.java. It will convert in either direction, and we're already using it routinely
ReplyDeleteWell, it doesn't do the [new resource] <-> Basic bit. I could, I suppose, but I don't need it; I'll let someone else contribute that bit
Delete