Hi Tzahi, Thanks! P.S. - It's "Outburn" :)

Creating separate files for the resources in a bundle is not a very common practice, though it can easily be done with a little scripting. The main purpose of a bundle, and of FHIR resources in general is to represent states of entities in a Restful framework. So for example you can POST the transaction bundle to a public FHIR server like http://hapi-fhir.outburn.co.il/ so the individual resources will be saved on the server. This will allow you to search for them and with the appropriate Accept header you can ask the server to return them as XML. You can also perform a Bulk export and get them as NDJSON. Another option is to POST the bundle to the /Bundle endpoint (i.e. http://hapi-fhir.outburn.co.il/Bundle) - this will only create the Bundle on the server and not the individual resources. You can still do a GET request for that bundle and ask it to be returned in XML.

Hi, I don't know of any place where you can find what you are looking for. Usually what people do is edit the resource to make invalid in the way you want. There are endless possibilities to make a resource invalid, so it depends on what you are trying to do. Also there is a difference between a resource being entirely invalid (according to the base specs) or just invalid according to profile X

Hi Hilla, If you are referring to Observation.code or Observation.component.code than a short answer will be yes, of course you can, since those elements are of the type CodeableConcept that contains an array of the Coding datatype specifically for this reason. One thing that is not clear from your question is why the additional coding you want to use is a urn:oid, since this is usually used to identify objects, not concepts (at least as far as I know). So I would suggest you make sure the OID you are trying to use is really a concept identifier, and not an object/instance identifier. The different codings used in a single CodeableConcept SHALL mean the same thing. Usually the use of this is for local code systems, and those usually are not composed of OID's. If you can make clear exactly how you want to use oid's here and what is the semantic meaning behind them, it would be great.

Hello, it seems you are confusing two separate concepts - the bundle type and the List resource. We have chosen the list resource to represent the medication list since it is less strict than the Composition resource, that requires sections with narratives and has it's own rules regarding the lifecycle of the document. Also it makes it easier for the client to edit the list - removing or adding medications. The Composition is more appropriate for true documents, where there are sections, narratives, and the need to package everything in a way that can be reproduced byte-for-byte on demand. In the first versions we did use the Composition but quickly realized it introduces unnecessary complexities. As for the Bundle.type - if we were to use the Composition it would have been "document". Since we use the List instead, the Bundle.type can be one of the following: collection, transaction, batch. It appears that we would use transaction, since we need all of the resources in the Bundle to be processed successfully. A collection (the value that is currently in the specs) is the least strict, since it does not imply any rules about the processing of the Bundle - it is entirely in the hands of the server to decide what to do with it. A batch means that partial processing is allowed (where one of the resources fail while others succeed) so it not appropriate for our use case. Hope this makes sense :)

For those who need to record sex at birth, there is a us-core extension that can be used: http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex

I would like to share a deliberation we have in one of the RFP projects. Since we need to record this information ('Aliya' date) we are trying to find the best standard way to do it, and we found the HL7 citizenship extension that allows the recording of the country and the date of the citizenship. We are hesitant to continue with this approach since we are not sure that the date of Aliya and the date of citizenship have the same meaning. A standard immigration extension does not exist, so this means that if the citizenship approach is ruled out - we are going to need to create our own extension for this. In that case we would prefer an Israeli Core extension rather that our own. Please advise.

1. After looking at other cores and also consulting the FHIR community, it seem like we are the first to try and handle foreign passports with a dynamic URI. We found an open ticket mentioning the issue and it contained a suggested solution. 2. After consulting with Lloyd we decided to adopt that suggestion and added a dedicated slice for it. The system URI is bounded to a ValueSet holding all countries URI's. The pattern is: http://hl7.org/fhir/sid/passport-[xxx] where [xxx] is the country's ISO-3166 3-letter code. Examples: http://hl7.org/fhir/sid/passport-AUS http://hl7.org/fhir/sid/passport-USA http://hl7.org/fhir/sid/passport-ISR

A fetus can be represented as a BodyStructure resource. There's an example showing exactly how: https://www.hl7.org/fhir/bodystructure-example-fetus.json.html To connect this to e.g. an Observation resource, you can use the standard extension BodySite: https://www.hl7.org/fhir/extension-bodysite.html

An important consideration regarding the address.line - It should be noted that you cannot populate the line extensions without populating the line itself, or else it will not be valid. Also, it should be noted that since the line element is an array, implementers must make sure that the extension for e.g house number is linked to the same line in the array that holds the actual house number. Same for the street etc. Be careful not to make contradictions between the information in the extension and the information in the corresponding line. Such contradictions SHALL be treated as modifierExtension, which makes the element useless for most applications.